初期と詳細な船舶設計モデルのギャップを埋める

この論文は、オランダのアムステルダムで開催された第15回国際海洋設計会議（IMDC-2024）で初めて発表されました。

序論

船舶設計プロセスにおいて、初期概念化から詳細設計への移行は重要な分岐点となります。これは、関係者の変化を伴う「転換点」を意味します。初期設計モデルは船舶の基本的な特徴、船舶建築および機能面に重点を置きます。詳細設計および生産設計はレイアウトの詳細に取り組み、生産および建造データの生成を扱います。この焦点の違いにより、使用されるツールに違いが生じ、データモデルの調整が必要となります。

本論文では、海事用途におけるデータ標準、PIAS（SARCによる）およびCADMATICという二つの特定のソフトウェアシステムのデータモデル、およびSEUS3プロジェクトにおけるこれらのモデルの統合の方向性を探ります。SEUSは、設計が進展するにつれてデータフローを取り込み、造船のための一連の計算ツールを提供する高い技術準備レベルのソリューションを作成することを目指しています。また、異なる関係者が単一の真のデータソースにアクセスできる包括的なツールセットを提供します。しかし、従来の中立モデルや業界標準は、このタスクに対する適合性を一般的に示していません。そのため、本論文で取り上げる研究課題は、ライフサイクル全体で生成されるデータの一貫性を提供する造船のためのデータモデルを見つけることです。

SEUSにとって重要なのは、予想される影響です。例えば、a) PLMのためのプラットフォームソリューション、b) デジタルトランスフォーメーションの促進、c) 初期設計の全体的な設計プロセスへの統合（Gaspar et al., 2023を参照）などであり、これらの多くは設計とエンジニアリングの間のソフトウェア統合を必要とします。しかし、人類の歴史の中でこのような試みが行われたのはこれが初めてではありません。次のセクションでは、既存の海事製品データ標準の適用性を調査します。

海事用途のためのデータ標準

著者らは、海事ソフトウェアの開発において100年以上の経験を共有しており、インターフェースや（ソフトウェアの）協調の側面が重要な役割を果たすことが度々ありました。その文脈において、なぜ既存の多くのデータ交換標準のうちの一つを使用しないのかと尋ねられるたびに、他者が驚くことに驚かされることがよくありました。（遅ればせながらの）返答として、これについてはこのセクションの後半で取り上げます。まず、完全を期すことはせずに、適用可能性のある標準の概要を簡単に紹介します。

適用可能性のある中立モデルおよびデータ標準の概要

中立モデルの明白なアイデアは図1で示されています。特定の規定がない場合、8つの独立したコンピュータプログラムA..Hはデータを共有するために8 x 7 = 56のインターフェースを必要としますが、何らかの中央形式を使用すると8つのインターフェースのみで済みます。

中立モデルのパラダイムは、この目的で使用されるいくつかの中立ファイル形式に反映されています。製品情報に関する各種（ファイル）標準の人気度に関する最新の概要を探しましたが、何も得られませんでしたので、Srinivasan (2008) の調査に頼ることにします。最も頻繁に使用されるデータ交換標準は、DXF、IGES、およびISO 10303（一般的にSTEP、製品モデルデータ交換標準として知られる）で、合計で60%の利用率を占めています。残りの40%は、例えばPDFがリストされているように、3Dデータの汎用交換には適していません。PDFは非常に便利ですが、「単なる」ドキュメント形式です。DXFはデータ転送に広く使用されているものの、単なる図面交換形式であり、製品モデルデータの交換には特に適していません。IGESは1980年に遡り、その名前が示す通り（初期グラフィックス交換仕様）3D形状の交換を目的としており、製品モデルの交換にはあまり向いていません。Kirkwood and Sherwood (2020) ではIGESよりSTEPが推奨されていますが、IGESは依然として広く使用されています。例えば、NURBS曲線または表面表現をエンコードするIGESタイプ126または128で船体の形状を交換するために使用されています。

これは後に広い意味で遭遇する現象を示しています。IGESは、線、曲線、平面、表面、固体など、形状のあらゆる種類の数学的表現に対応する数百種類のタイプを含んでいます。したがって、IGESファイルを生成するコンピュータプログラムの製作者は、お気に入りの表現をいくつか選ぶことができ、すべてをサポートする必要はありません（実際、誰もすべてをサポートしていません）。

STEPは製品データ交換のための最も有力な代替案であるかもしれません。この結論は多くの論文で導かれています。例えば、Kim et al. (2008) では、3D形状の交換だけでなく、設計意図（例：パラメータ、フィーチャ、制約および履歴）を拡張するためにSTEPを使用することが提案されています。さらに、STEPは特定の産業分野のいわゆるアプリケーションプロトコル（AP）に特化しており、海事用途にはAP215（船の配置、ISO (2004a)参照）、AP216（船の成形形状、ISO (2003)）、およびAP218（船の構造、ISO (2004b)）があります。

ここで関連する短い逸話があります。オランダ標準化協会からSTEP標準を注文したところ、AP215、216、および218が含まれていない一式が届きました。問い合わせたところ、それらはすでに期限切れであると言われました。幸いにも、スイスのISOで購入できましたが、その正確な状況は今も完全には把握できていません。それはともかくとして、複数の研究者が海事用途にSTEPを推奨しており、例えばWhitfield et al. (2011) や Shiplys (2019) が挙げられます。Qin et al. (2017) はSTEPのいくつかの欠点について報告し、Web Ontology Language (OWL) の手法と組み合わせることで改善を提案しています。

これらすべての標準は、形状のモデルを目指しており、製品モデリングに向けて成長しようという野心を持っています。これらは、人間の言語の辞書のように、あらかじめ考慮されたあらゆる変種を網羅する広範な書籍に進化しています。しかし、ライフサイクルサポート、明示的なセマンティクス、エンティティ間の関係が欠けているため、限られたものと見なされることもあります。この認識は徐々に新しい標準であるISO 15926に導かれました。後者は、a) グローバルなセマンティック相互運用性、およびb) プラントライフサイクル情報のアーカイブ、収集、統合という二重の目標を報告しています。この用語からもわかるように、この標準はプロセスプラントに向けられており、船舶設計分野での適用性が制限される可能性があります。それにもかかわらず、Koelman (2024) に報告されているように、船上の統合配管システムではISO 15926に触発されたデータ構造が用いられました。また、オランダの10年前の海事研究プログラム「Integraal Samenwerken」では、ISO 15926-11（ISO (2023) 参照）を使用したパイロットプロジェクトが開始され、「トリプル」および「Gellish」というキーワードが使われましたが、それは進展しませんでした。

製品とその形状だけにとどまらない、より広範な範囲を持つもう一つの興味深い産業標準は、ISO 81346です（ISO (2022) 参照）。ここでは、製品の多面的な特性に対処し、製品に異なる側面を割り当てます。各側面には独自の階層と分類法があります。図2では、次の3つの側面が示されています。a) コンポーネントとの構造的関係、b) 機能的関係、c) 空間的関係（例：場所）。これら3つに限定されず、他の側面（例えば、財務的または物流的）も考慮される場合があります。Leclerc et al. (2022) で主張されているように、このフレームワークはシステムズエンジニアリングアプローチ（MBSE: Model-Based Systems Engineering）に非常によく適合します。これは、海事セクターの生産性を向上させると期待されている手法です（Maritiem Masterplan (2023) 参照）。

議論されている標準は、製品の設計および建設段階における特性に関連しています。新興分野として、運用データを含めることが取り組まれており、その中でもセンサーデータが重要な貢献をしています。このアプリケーションはISO 19848（ISO (2023) 参照）によって対象とされており、Fonseca et al. (2022) によって船のスケールモデルのデジタルツインの実験に使用されました。もう一つの新興標準はXMLベースのOpen Class 3D Exchange（OCX）です（Zerbst (2023) 参照）。ただし、これは私たちの適用領域の端に位置しています。「OCXは分類協会による情報ニーズを対象とした船舶固有の標準です。」

これで、データ標準と中立データ形式に関する多少印象的な概要を終えます。続くセクションでは、適用可能性や落とし穴について議論しますが、その前に典型的な海事プロジェクトにおけるデータフローを概説します。

海事プロジェクトにおけるデータフローと成長

KirkwoodとSherwood（2021年）は、CADとCAEの持続的な統合を簡略化する興味深いアプローチを含んでいます。このアプローチは、CAEアプリケーションがFEM解析であることに動機付けられており、実際にその表現は元のCADモデルよりもやや詳細が少ない場合があります。しかし、海事界ではCAEは主に生産の前段階と見なされており、これはデータがより詳細で豊かになっていることを意味します。例えば、船の防水横隔壁。最初の段階では、これはGAプランの一部としての線（または3D CADモデルの平面）であり、防水性があり、タンクや区画の間の隔壁として機能します。この限られた情報は、タンク容量表や損傷安定性計算の作成に十分です。設計プロセスの後半では、この横隔壁のデータには板の厚さ、パネル、ビーム、補強材、および塗装の詳細などが追加され、重量、重心、コストなどの派生データも含まれます。そして、すべてが最初はGAプランの一部として線だった横隔壁に属しています。したがって、設計の更新で横隔壁が1つのフレーム位置に移動すると、これらの特性の一部はそれに応じて変更されなければなりません。

ある意味では、この問題は図2の具体例であり、機能的、建設的、財務的、物流的な側面が含まれ、それぞれが独自の分類体系やコーディングシステムを持っています。しかし、これはまた、詳細度（LOD）の問題でもあります。例えば、一般建設計画の段階では主要な構造要素のみが含まれており、最終的な生産準備段階ではブラケットや溶接が追加されます。もしもこのようなシステムを第三世代（3G）プログラミング言語で形成しようとする場合、永続的な保存やインターフェースを考慮せずにRAM内でのみ操作する場合、エンティティ間を接続する配列、クラス、およびポインターを持つ構造が役立つでしょう。

図3に示されている内容は以下の通りです:

• 横隔壁は「横隔壁」のサブシステムの一部です（これはさらに「船体構造」の一部となる可能性があります）。
• 各横隔壁にはGUID[1]/UUID[2]が含まれており、これは一意で恒久的な識別子として機能します（これはKirkwoodとSherwood (2021)で仮想永続識別子と呼ばれています）。別のソース（例えば、サポートデータ管理システムからの一意の識別子）がGUIDの代替として利用されることもあります。
• 各横隔壁には以下の3種類のサブクラス情報が含まれています：
• 1. トポロジーとジオメトリー。
  2. 両側の区画への参照（「区画」のシステム内）。
  3. パネルのリスト。

• CADシステムは1と2を管理しますが、3を「見る」ことはありません。
• CAEシステムは1と2を使用し、3を管理します。

Please understand that this 3G solution is only presented to elucidate the process around and with the data. Practical considerations, such as the lack of a common 3G programming language, prevent its actual implementation.

この例は、設計とエンジニアリングプロセス全体で情報の連続的な完全性の増加を示しています。この観察は、かつては設計段階（概念、予備、契約、詳細）を区別することが有用であったという考え方とはやや異なります。明確な段階という概念の没落は実践で見ることができ、例えば典型的な「予備設計」要件である十分な損傷安定性は、パイプ、バルブ、換気口の存在と位置に大きく影響されます。これらの詳細は通常、設計プロセスの後の段階で対応されます。また、文献においてもこの傾向が見られます。例えば、船舶設計方法論の最新の状況報告であるErikstadとLagemann (2022)では、「設計段階」という言葉のエントリーはゼロです。しかし、本論文のタイトルはギャップを扱っており、それは設計段階の間のギャップではなく、モデル間のギャップです。初期設計モデルはやや包括的であり（シミュレーション結果などの非物質的な側面を含む）、詳細なモデルよりもサイズが小さいです。モデル間のギャップを埋めるということは、接続されたツールがすべての設計活動に統一されている必要があることを意味します。実際、船の設計の初期段階の目標は後の段階とは異なりますが、これはAndrews (2018)で巧みに説明されています。

最後に、データトラフィックの双方向性と単方向性の問題があります。中立モデルの理想は常に、すべての接続されたアプリケーションが中央のストレージから読み書きできることです。図1の右側に示されている双方向の矢印がそれを表しています。情報が単純な場合、例えば単一の数値であれば、双方向性を簡単に実現できます。しかし、複雑なロジックや機能が関与する場合、すべてのアプリケーションがモデリングの変更を行うことができない場合があります。例えば、区画と横隔壁・甲板の間の二重性は1つのアプリケーションのみが管理することができ、他のアプリケーションはその情報を特定のツールなしで読み取り、使用することができます。もう1つの例として、船体形状モデリングがあります。1つの親アプリケーションが特定のモデリングツールを持ち、親表現に基づいて作用する一方、他の表現（例えばSTL、VRML、X3D、3Dワイヤフレーム）は各設計変更ごとに即座に派生して中立形式で保存されます。これにより、他のアプリケーションが形状変更ツールを持たなくても使用できる準備が整います。異なるアプリケーションが地理的に分散している場合、単方向性は少し不自然かもしれませんが、同じモニター上の2つのウィンドウで2つのアプリケーションが開かれている場合、1つのアプリケーションしか使用できないことはそれほど自然ではなく、時間がかかることもありません。HVACエンジニアがバルブスボウの形状を変更できないという場合には、むしろ利点を提供することさえあります。

船舶設計とエンジニアリングにおける中立モデルとデータ標準の適用性について

この段階で、この論文は自己盗用の問題に直面しています。次に続くのは、著者の一人が過去20年間で何度も語ってきた逸話である可能性が高いからです。Owen (1997)によると、STEPは「完全性」を目指しており、それが必然的に「変換」につながりました。これは、2Dの円弧の9つの異なる表現が例示されており、例えばa) 中心 + 半径 + 開始角度 + 終了角度、b) 中心、半径、開始点、終了点、またはc) ポリラインなどです。もしアプリケーションがこれらすべての表現をサポートしようとし、内部でそれらのうちの1つを使用している場合、それには8つの変換アルゴリズムが必要とされます。アイテムa)は単純な数学で行うことができますが、アイテムc)はすでに数値解析が必要であり、丸め誤差が生じる可能性があります。

同様の例がSTEP AP 216、Ship Moulded Formにも見られます。ここでは、オフセットテーブル、ワイヤフレーム、サーフェスという3つの代替表現がサポートされています。したがって、もしコンピュータプログラムが内部でNURBSサーフェス表現を使用し、STEPファイルでオフセットテーブルを受け取った場合、それを変換できる必要があります。この例ではこれは簡単な課題ではなく、KoelmanとVeelo (2013)を参照してください。

これらは「表現の多様性」の例であり、これはGielingh (2008)の画期的な論文でも取り上げられています。そこでは、図1のニルヴァーナを目指していましたが、表現の大きな変動のため、実際にはサポートされているのはそのサブセットに過ぎず、DXF、IGES、またはSTEPでこれらの表現が保存されたり通信されたりするかに関係なく、あらゆる種類の特定の表現変換の状況に至ります。これがどんな中立モデルの運命であるかです。いかなる場合でも基本的な表現を変換する必要があります。その世界（または実用的な世界のサブセット）が、すべてのエンティティに対して単一の表現を使用することを決定しない限り、この問題は解決されないでしょう。

他の標準規格（例えばIGES、DXF、および従来のSTEP）に関する別の問題は、それぞれが幾何データのみを含んでいるということです。Qinら（2017）によると、「STEP AP 203/AP 214の中立ファイルベースの交換方法のよく知られた問題は、この方法が幾何データの交換に限定されており、設計意図に関連する非幾何データ（例えば構築履歴、パラメータ、制約、および特徴など）が交換後完全に失われることである」と述べています。従来の中立フォーマットの実用上の問題は、それが常に正しく機能しないことです。そのため、それらの使用はエラーや情報の喪失を引き起こす可能性があります。STEPファイルをアプリケーションに読み込ませた後、Gielingh（2008）は「これらのファイル間には重大な違いが見られました：いくつかのエンティティが消失し、他のエンティティが出現し、また他のエンティティが変更されていました」と指摘しています。この観察は最近、Kuryloら（2023）でも確認されました。

特にSTEP AP 215はかなり広範囲ですが、それでもすべてをカバーしているわけではありません：

- 実際には完全な状態と損傷状態で透過性が異なるが、STEP AP 215では区画ごとに1つの透過性しかサポートしていない。
- 3種類のブロック係数が指定されているが、Holtropの抵抗予測に必要な設計満水線長に基づくブロック係数は含まれていない。標準にこのような派生情報であるブロック係数を含める理由に疑問が投げかけられている。各アプリケーションは、その特定のアプリケーションにとって関連性のある変形体で、体積を長さ、幅、および喫水で分けることができる必要がある。
- 測深管の高さは含まれているが、その形状は含まれていない。
- タンクの総容積とそれに対応する重心は含まれているが、その自由表面または完全なタンク表は提供されていない。再び、ここでの疑問は、簡単に導出可能な情報をなぜ保存するのかということです。
- エンティティ間の一部の関係はサポートされているが、エンティティ間の明示的な依存関係や関係の一般的なサポートはない。

結論として、STEP AP 215は一方では過度に広範であり、他方では完全ではないと言えます。おそらく、これがどんなグローバルな中立モデルにも運命となるでしょう。さらに、STEP AP 215は辞書と見なすことができ、オントロジーではありません。それでも、この標準の開発には多大な努力が払われ、多くのパラメータとエンティティに名前と意味が与えられています。したがって、少なくともインスピレーションとして利用する理由はなぜないでしょうか。

ISO 81346（ISO、2022）の魅力的な特徴は、オブジェクトの多面性を明示的に扱う点ですが、それは実装可能な解決策を提供するよりもフレームワークを定義しています。さらに、オブジェクトの位置のコーディングに関する標準も含まれていますが、これは建物のモデリングに合わせたものであり、船舶に直接適用することはできません。

建設情報モデリング（BIM）の標準については、中立モデルのセクションで議論されていない理由は、その標準の大容量、複雑さ、および多様性のためです。著者らはBIMを詳細に研究していませんが、BIM ISO標準23386および19650は一般的な構造を提供することが多く、関連する詳細よりも高レベルでの指針を提供しているようです。多くの応用分野については、これらが国や地域のスケールでさらに詳細に解説されています（例えば、www.etim-international.com/には、電気技術、HVAC、配管部品のコーディングが含まれています）。これらのコンポーネントは船舶の装備段階で重要ですが、設計およびエンジニアリング活動との関連性は比較的限定的です。

SEUSデータモデルに向けて

現時点では、すべての既存のモデルや標準の中から、私たちの目的に直接適用可能なものはありません。具体的な目的が明示的に定義されていないため、次のサブセクションでこれに取り組みます。

SEUSの目的に対する要件

上記の分析と議論から最低限の要件を導き出すことができ、それは以下の通りです：

1. エンティティ間の名前と暗黙の関係の辞書。現段階で解決策を言及するのは少し早いかもしれませんが、STEP AP215はこれに役立つ基盤を提供しており、すべてを採用する必要はなく、必要に応じて拡張する必要があることを知っています。
2. エンティティ間の明示的な関係のサポート。
3. 表現のバリエーションのサポート。これらは単方向のため、オブジェクトは一つの親アプリケーションによって定義され、各設計変更から他の子表現が生成され、システムの他のアプリケーションからは読み取り専用となります。
4. 多面的な特性のサポート、つまり、エンティティが複数の分類体系や他のデータ構造の一部であることができること。

さらに、非常に厳密に言えば最低限必要ではないが、実際には非常に有用である可能性のある機能として、データに加えて関数のサポートがあります。関数は手続き、サブルーチン、すべての接続アプリケーションから呼び出すことができる処理ソフトウェアの一部であり、DLL、APIまたはリモートプロシージャコール（RPC）として実装されます。このようなツールの利点については、Koelmanら（2015）で「リクエスト/リプライ」という名前で議論されています。

最後に、厳密に必要ではないが有用性が証明される可能性があるいくつかの望ましい機能があります：

1. エンティティと関係の本質と特性を文書化するツール。これは一般的にはWordなどのテキストエディタで行うことができますが、それは最もユーザーフレンドリーなツールではなく、現在のタブルや参照作業にとってはさらに役立たないことがあります。文書化ツールは、データ管理ツールと統合されていることが望ましいです。なぜなら、両者はデータ、構造、および関係を扱うため、人間やコンピュータによって理解される必要があるからです。

2. データの整合性と認証の明示的なサポート。

3. システムのパフォーマンスの側面、例えば処理速度やデータサイズの制限。ただし、これは当初から数量化を始めるのは少し早いと考えられますが、最終的には忘れてはならない点です。

SEUSプロジェクトの野心は設計およびエンジニアリングフェーズを超えており、運用データとエンジニアリングのデータモデルのリンクを見つけるための類似した取り組みが別途進められています。現在の論文ではこのフェーズは含まれていませんが、後のプロジェクト段階でこれに適用できるアプローチが検討されています。PDMの観点から、本論文の焦点は「設計段階」と「エンジニアリング段階」のデータモデルをリンクさせることにあり、将来的には「建設時」と「運用中」のデータモデルにも拡張される可能性があります。したがって、現在はデータモデルのリンクに焦点を当てることで、さまざまなアプリケーションがデジタルスレッドを形成できるデジタルツインプラットフォームソリューションへの適用が後で考慮されます。

グラフデータベースによる初の実験

図3に示されている関係を表現する共有データ形式をXMLやJSONを基に実装することは可能ですが、それは困難な作業となるでしょう。なぜなら、各要素にはそれぞれ独自のGUIDが必要であり、関係はそれらの用語で表現される必要があるからです。これには多くの協力が必要であり、広範な形式仕様とデータ検証も必要です。その結果得られるテキストファイルは非常に大きく、人間の設計者による解釈が難しくなります。自然言語テキストであるという利点は薄れるでしょう。ファイルでデータを共有する代わりに、データベースを共有するという選択肢があります。

伝統的な関係データベースは、行と列の表から成り立っており、各行が1つのデータエントリを表し、そのエントリの各プロパティはそれぞれ専用の列に存在します。これによりデータの構造化が強制されます：各列には特定のタイプと意味のデータのみが含まれ、表の各エントリには同じ数とタイプのプロパティがあります。エントリ間の関係は、他のテーブルの行を参照するプロパティとしてエンコードされます；これを外部キーと呼びます。例えば、ユーザーテーブルと注文テーブルがあり、各注文が注文を行ったユーザーを参照している場合がこれに該当します。これは「1対多」の関係をエンコードし、特定のユーザーが行ったすべての注文を収集するには、テーブル全体をユーザーのキーで検索する必要があります。外部キーはこのデータベース形式の厳格な構造に従っており、多数の関係や任意の関係を持つシステムをモデル化するのには適していません。これには社会ネットワークや金融システムなどが該当します。

別のタイプのデータベースが現れており、完全に非構造化のデータをモデル化することが可能です。これをグラフデータベースと呼びます。異なるアプローチが存在しますが、共通しているのは、グラフデータベースが情報のノードとそれらのノードがどのように接続されるかを記述することです。したがって、「グラフ」という用語はトポロジと離散数学を指し、グラフデータベースは関係データベースよりも高いパフォーマンスを発揮し、クエリが容易でシステムを構築する自由度が高いことがあります。また、重要な点として、グラフはテーブルの集合よりも明確に意味が表現されるため、AIを使用したトレーニングがより簡単である場合があります。

最後に、グラフデータベースを使用する必要性は必ずしもないことに留意する必要があります。グラフデータベースは、解決策の探索に重要な自由度と柔軟性を提供します。実験が成功すれば、それはある程度実装可能であることを示すものとなるでしょう。SEUSコンソーシアムのパートナーであるContact SoftwareのPLMソフトウェアが埋めることができる概念が好ましいです。

2024年初頭、人気ランキングサイトdb-engines.comには41種類のグラフデータベース管理システム（graph DBMS）と、二次モデルとしてグラフを表現できる13種類の追加DBMSがランキングされています。これらの多くはオープンソースの実装を基盤としており、いくつかは追加の商用サービスを提供しており、純粋な商用ソリューションよりも魅力的とされています。これらすべてを徹底的に評価する必要や希望はなく、以下のグラフDBMSが考慮されました：Neo4j、NebulaGraph、Memgraph、ArangoDB、Redis、GraphDB、Virtuoso。Neo4jとArangoDBの両方をインストールし、プログラム化しましたが、後者がより適切なDBMSとして浮かび上がりました。ArangoDBはパフォーマンス重視であり、必要に応じてデータの構造化が可能です。グラフ内のノードとエッジは、JSONドキュメントに相当し、配列を含めることができます。ノード間の関係はエッジとしてエンコードされ、ノード識別情報を含む「from」と「to」プロパティが必須です。エッジは「最短パス」などの典型的なグラフアルゴリズムの適用を可能にし、ダングリングエッジを防止するための妥当性保証を促進します。また、関係はノード自体のプロパティとして参照としてエンコードすることもできます。このようにして、ArangoDBはグラフデータベースとドキュメントストアのミックスを提供します。

こうして、図3に示されたケースをArangoDBを用いて表現する実験が開始されました。この実験のソースコードはGitHub[1]で公開されています。DBMSとクライアントプログラム間の通信はHTTPを介して行われます。これにより、データベースとクライアントが異なる地理的位置にあっても通信できるようになり、実験が開発された方法です。また、Dockerコンテナでの実験実行オプションも含まれており、これにより再現性が向上し、すべての処理が同じハードウェア上で実行される際のネットワークオーバーヘッドが軽減されます。この場合、クエリごとのレスポンス時間は60ミリ秒から10ミリ秒未満に短縮されました。規模に応じた処理速度の評価はこの初期実験の一部ではありませんが、グラフのサイズを100万ノードに増やした場合、遅延は測定可能ですが重大ではありませんでした。VelocyPackバイナリ輸送[1]は利用されていませんが、これによりスループットが向上する可能性があります。

この実験が取り組んだ主な問題は、設計モデルのデータをグラフデータベースでどのように合理的に整理するかです。データベース自体がすべての必要な機能をカバーする必要はないことがわかりました。なぜなら、統治アプリケーション内のルールやロジックがデータベースの整合性を保証するからです。データベースが不正なシステムや人間によって直接的に充填されない限り、無意味な関係は実践上防止されるべきです。同様に、認可の側面はアプリケーションによって処理されることができます。

アプリケーションの観点を考慮すると、船舶モデルはバルクヘッドのみを考慮して単純化できます。設計ソフトウェアでは、バルクヘッドは主に空間の仕切りを定義し、それによって船室の容積が決まります。一方、エンジニアリングソフトウェアでは、バルクヘッドは主に構造オブジェクトと見なされます。この実験の目的は、設計とエンジニアリングソフトウェアが相互に干渉せずに同じバルクヘッドで作業できるようにすることでした。この実験のアプローチ（図5）は、バルクヘッドの抽象的な概念を表すノードから始めることです。このノードにはその識別情報のみが含まれます。これに接続されるのは、設計とエンジニアリングのための特化した別々のノードです。この原理は、コスト見積りや建設プロセスの物流、保守などの追加システムにもスケーラブルです。

それぞれの特化ノードには、その特化に固有のプロパティが含まれ、図6に示されているように、その表現に特化したノードでグラフを拡張することができます。

実験のソースコードには、与えられた数のバルクヘッドでデータを合成する手順[1]が含まれており、各バルクヘッドはグラフのエンジニアリング側にあるパネルの数で構成され、設計側のグラフでは区画の境界が定義されています。図6は、2つのバルクヘッド、3つの区画、および6つのパネルのノードと接続を示しています。接続は方向性を持っていますが、どの方向でもトラバースできます。以下は、ArangoDBクエリ言語（AQL）のソースコードの抜粋であり、グラフをトラバースし、区画の名前とその境界バルクヘッドの位置をリストアップするものです：

FOR c IN Design_Compartment
        FOR db IN INBOUND c Design_BulkheadAdjacentCompartment
                 RETURN [ c.name, db.position ]

実験では、あるバルクヘッドを新しい位置に移動させた際に出力がどのように変化するかを示しました。

実際には、グラフに追加情報を拡張する可能性は無限です。設計ソフトウェアは、制約管理システムからの制約（De Koningh et al. (2011)を参照）や、現在別々のファイルに格納されているその他のモデルデータを含めることができます。エンジニアリングソフトウェアは、パネルデータ（識別番号、寸法、適切なローカル座標系に対する位置）を格納し、他の部品や製造詳細を表すノードとの接続も可能です。さらに、ノードのプロパティを単純に更新するのではなく、完全なノードの新しいバージョンをノードバージョンのスタックの上にプッシュし、バージョン間のエッジには変更の日付、上司の承認などが含まれるようにバージョニングを実装することもできます。

原則として、完全なグラフはエンジニアリングクライアントと設計クライアントの両方がトラバース可能です。たとえば、エンジニアリングソフトウェアがバルクヘッドの位置を必要とする場合、抽象的なバルクヘッドを見つけ、対応する設計用バルクヘッドにトラバースし、そこから位置を読み出すことができます。しかし、これにはエンジニアリングソフトウェアが設計側のグラフのトポロジーを理解している必要があり、また設計ソフトウェアの開発者はエンジニアリングソフトウェアの開発者と協調せずに自身のグラフの変更を行うことはできないということを意味します。興味深いことに、ArangoDBではFoxxマイクロサービスと呼ばれるものをインストールすることができます。これらは、潜在的に動的なサブグラフをクエリするための安定したAPIを提供するために使用されます。Foxxマイクロサービスは、本質的にはJavaScriptのスニペットであり、これをグラフDBMSにアップロードした後、特定のURLでアクセスできます。クライアントがそのURLにアクセスすると、マイクロサービス内のコードがDBMS内で実行され、結果データが返されます。マイクロサービスはグラフクエリを実行することができます。このようにして、特定のシステムの開発者は、自身のグラフのレイアウトを変更する場合にはマイクロサービスを適応させることで自由になり、他のシステムは変更、協調、同期なしで使用を継続することができます。

実験は示したとおり、22行のJavaScript[1]でマイクロサービスを実装することで、バルクヘッドの位置を名前でクエリできます。例えば、http://localhost:8529/_db/seus/bulkhead_position/B1 を入力すると、出力は [10] となります。ArangoDBのHTTP APIはOpenAPI仕様に従い、Swagger 2.0と統合されています。これにより、データベースサーバーは自身のAPIドキュメントを提供し、APIをインタラクティブにテストできるWebフォームも提供します。この機能はマイクロサービスにも適用されます。したがって、マイクロサービスには、返される値がバルクヘッドの後部面と後部垂線の間の縦断距離（正の値は前進、負の値は後退）であることを含むドキュメントを含めることができます。

マイクロサービスには、追加のロジックも含めることができます。したがって、バルクヘッドの重量は、エンジニアリング表現のバルクヘッドに格納されている離散的なプロパティである必要はありません。代わりに、マイクロサービスによって動的に決定される値です。設計の初期段階では、バルクヘッドの構造が未確定であり、パネルやスティフナーを表すノードが接続されていない場合、マイクロサービスは信頼度の低い推定重量を返すことができます。しかし、パネルの定義がされ、板の厚さと寸法が判明し、素材が判明し、スティフナーが定義されると、重量は高い信頼度で計算できます。モジュールの重量が要求されるとき、マイクロサービスはモジュールを構成するすべての部品に再帰的にアクセスし、部品の重量を累積します。

この実験からの結論は、グラフデータベースが共有データモデルの実装において大きなポテンシャルを持っているということです。グラフデータベースによって柔軟性と拡張性が提供され、マイクロサービスによるドキュメンテーション（タクソノミー）とRPCのニーズも一定程度まで対応します。船舶設計部門とエンジニアリング部門が異なる地理的場所で同じモデルに取り組んでいる場合でも、またすべてのシステムが同じコンピュータで動作している場合でも、DBMSのHTTPインターフェースはどちらの状況にも適用可能です。

SEUSのデータモデル

このセクションの目的は、SEUSからのデータ、関係、およびサービスのモデルを概念化することです。その前に、設計およびエンジニアリングソフトウェアスイートの既存のデータモデルが概説されます。

設計ソフトウェアの既存のデータモデル

船舶設計データモデルの基礎は、船体形状によって形成されます。その形状には二つの表現があります。最も完全なものは、閉曲面を持つ実体モデルであり、プロプライエタリなH-Rep表現です（Koelman (2003) 参照）。別の表現にはワイヤーフレームが含まれ、断面および船首/船尾及び甲板輪郭が含まれており、すべての計算には十分です。実体/表面モデルは、PIASのワイヤーフレーム、およびIGES、NURBSサーフェス、およびIGES/DXF 3D曲線に変換可能です。ワイヤーフレームモデルは、人間の介入を必要としますが、実体/表面に変換可能です。

船体内部の空間は、構成面（バルクヘッドおよびデッキ）と区画（タンクおよび他の空間）で満たされており、これらは双対性を形成します。面が区画を形作り、空間は面によって境界付けられます。この双対性はプロプライエタリな方法によってモデル化されています（De Koningh et al. (2011) 参照）、これはバイナリ空間分割（BSP）に基づいています。これらの構成面は船体内部を凸空間に分割し、これらはサブコンパートメントと呼ばれます。複数のサブコンパートメントが一つの区画の一部として割り当てられることがあります。この構造では、空間は「論理的な」建築ブロックであり、一方で区画は物理的で、すなわち防水です。非構成面を考慮に入れることでより細かな区分が得られる場合もありますが、これらは明示的にモデル化されておらず、通常は8つの頂点によってサブコンパートメントをモデル化することによってその存在が実現されます。これらの二つの区画モデリング手法は混合することができ、一般的なPIASユーザーは、大きな系統的な区分面に対して面ベースの方法を適用し、小さなタンクや空隙に対しては頂点ベースの方法を適用します。どちらのモデリング方法が使用されていたとしても、最終的な区画形状は船体との交差によって計算されます。区画の形状は区画の中心的な特性ですが、その他にも名前、透過性、設計密度、位置および外部開口部のタイプ、およびサウンディングパイプの位置と形状などの特性も保存されます。

水圧および（損傷）安定性の観点から、区画間のパイプ、内部開口部、およびダクトなどの接続は、その形状と同様に重要です。これはPIASのデータモデルの一部を形成しますが、これはすでに別の会議論文であるKoelman (2024)のトピックであり、ここではさらに議論しません。

これには、設計とエンジニアリングの多くの段階で共有される船舶設計の幾何学的およびトポロジカルデータが含まれます。しかし、喫水、積載能力、消費電力、安定性、強度などのあらゆる種類の技術的特性を正確に予測するには、船体の重量とその分布も重要です。明らかに、PIASはこれを支援し、基本的には部品の長いリスト、その重量、三次元座標、およびその船尾と船首の境界で提供します。

「設計」ソフトウェアは、船の設計段階だけでなく、シミュレーションおよび納品書類の作成にも使用されます。これにはタンク容量の表、（損傷）安定性の評価、縦強度および操船特性が含まれます。これらのレポートは現在、ASCII、XML、またはWord形式にエクスポートされていますが、これらの計算の多くはRPC形式で提供できます。

さらに、すべてのエンティティには仮想永続識別子、おそらくGUIDが付けられる可能性があり、これは以前に注目された概念です。これにより、オブジェクトを一意に永続的に識別し、変更の追跡と処理が容易になります。

エンジニアリングソフトウェアの既存のデータモデル

CADMATIC Hullの既存のデータモデルは、関係性に基づいており、形状や位置の変更が他の要素に直接影響し、他に連鎖反応を提供する要件を直接サポートしています。さらに、エンド形状、穴、カットアウト、ラグなどの標準は機能として含まれ、その形状ではなく、参照ライブラリに記録されます。また、本体と厚さ方向はオブジェクトのパラメータとして割り当てられており、そのためCLおよび逆フレームが最終的な2Dおよび3Dプレゼンテーションに直接影響を与えます。複数の要素（プレートおよびプロファイル）は、サブデータベース全体として記録され、これらの部分はパラメータ化されたグリッド定義にリンクされ、またx、y、z方向または面として定義された平面定義を示します。全体（船）はこれらのサブデータベースのコレクションであり、柔軟に交換できるため、大規模なモデルでの同時作業を容易にし、プロジェクトのデータベースを複数の物理サーバにレプリケートしてリモートワークチームとユーザーにシームレスな体験を提供します。これがHullアプリケーションの基礎であり、これによって2D断面図、3Dビュー、重量、長さ、材料などの派生情報、および切断、ロボットおよび折り曲げデータなどの生産データが派生します。すべてのオブジェクトにはユニークなGUIDがあり、これらはすべての関係のリンクとして使用されます。

CADMATICアプリケーションにはHull、P&ID、Plant Modeller、Piping Isometrics & Spoolsがあります。すべてのコンポーネント、部品、シンボル、および設計指示はライブラリ＆プロジェクトデータベースに格納され、管理されます。これらのデータベースにはシート、リスト、およびレポートのフォーマット制御も含まれます。すべてのアプリケーションが同じデータベースを使用するため、デザインプロジェクト全体で情報が一貫しています。アクセスはCADMATICオブジェクトストレージ（COS、図7参照）環境によって管理され、データは複数のサイトで同時に変更されるのを防ぎます。したがって、リモートデザインチームは衝突なく共通のモデルデータベースを使用して分散プロジェクトで作業できます。プロジェクトはブロックに分割され、一般プロジェクトデータ、船殻ラインサブセット、および2Dシンボルが含まれ、これらはすべて個別にCOSサーバーに保存できます。P&IDでは、デザイナーは事前に定義されたシンボルとメタデータ情報を使用してプロセスを2D形式で模式的に説明します。Plant ModellerとPiping Isometrics＆Spoolsでは、パイプ、継手、機器、構造部品などを使用して船を現実的に表現するために、プロセス図が3D形式で再構築されます。

さまざまなアプリケーションは、それらが提供する学問分野に応じてわずかに異なる方法で機能しますが、全体のプロジェクトデータはCOSデータベースで統合されます。CADMATICは、設計者の仕事の船舶建造性に焦点を当てた「意図駆動型」CADソリューションを代表しています（Dush et al. (2017)参照）。各アプリケーションには、設計分野の特定の統合ニーズをサポートするための独自のAPIがありますが、COS Web APIは全体的なプロジェクトデータの統合ニーズをサポートします。

SEUSサービス倉庫の概要

CADMATICとPIASのインターフェースについて学んだ教訓として、Koelman et al. (2015) で述べられている次の点が挙げられます：a）共有データベースではなくTCP/IP経由での直接通信、b）データ同期が連続的ではなく要求に応じて行われる、c）STEPの意味論に基づく高レベルのデータエンティティの交換、つまり、基本的には最も深いデータ表現は共有されなかったという点です。例えば、両システムともに「デッキ」という概念を持っていましたが、その基本的な表現はかなり異なっていました。したがって、そのソフトウェアの協力関係は印象的であり、2つの異なるアプリケーションで同じモデルを示す2つのウィンドウが開かれ、ボタンを押すだけで片方からもう片方に変更が転送されました。しかし、直接的なTCP/IP通信には1つの欠点がありました：中央の永続的なストレージの不在。もしアプリケーションの1つが接続されていない場合、他からの同期アクションは消滅してしまいました。この結論と、この論文での他の分析や実験と合わせて、次の機能とサービスを備えたSEUS倉庫が構想されました：

1. データとその関係の保管は拡張可能であり、異なる詳細レベルや複数の側面を提供します（つまり、エンティティは異なる種類や目的を持つ複数のタクソノミーの一部になることができます）。
2. 海洋STEPアプリケーションプロトコルに基づくデータセマンティクスで、必要に応じて拡張されます。
3. もし辞書としてこのことを捉える場合、人間が使用するための統合されたドキュメンテーションシステムが望まれます。
4. このストレージシステムとの間で、APIやRPCを含む簡単な通信が可能です。これには、高水準のプログラミング言語やスクリプティングツールなど、さまざまなタイプのシステムが含まれます。
5. それは、データ表現の変換を含む一連のシステム全体のサービスで拡張されています。
6. データへのアクセス制御が可能です。

このことがデータに限定されないことを強調するために、これは物理倉庫に対するアナロジーで、物品に関連するサービスが提供されると呼ばれます。

しかし、過去の抽象的な計画や大きな設計が溢れていますので、このSEUSサービス倉庫の実現可能性をどのように評価するか？ 最初の2つの項目が長年のボトルネックとなってきましたが、この論文で述べられている実験は解決策が存在することを示唆しています。現在は、既存のソフトウェアソリューションが第3および第4の要件をどのように満たすかについても調査が進行中です。

最後に、このサービス倉庫の運用方法について言及します。設計およびエンジニアリングプログラムはサービス倉庫を使用しないため、内部表現とサービス倉庫との同期が時々必要とされます。この同期は自動的に行われる（一定の時間間隔で）、またはユーザーの指示によるか、あるいは認可されたユーザーに限定されるか、という問題は後で回答できる実用的な問題です。必要に応じて、この設定が存在するかもしれません。

Conclusions 

この論文では、設計とエンジニアリングの船舶建造プログラムスイートの統合に向けた背景、要件、および希望について概説しました。海事データ標準の調査の後、これらのいずれも我々の目的に直接適用可能ではないことが結論づけられました。主に、設計とエンジニアリングデータの多面的性をサポートしていないためです。最近登場したグラフデータベースのカテゴリがこのギャップを埋める可能性がありますが、最初の調査として、一連のバルクヘッドとコンパートメントを用いた実用的な実装が作成され、評価されました。結果は非常に有望であり、ライセンスやコストなどの非技術的な側面はまだ考慮されていません。それでも、これらの実験は、SEUSの設計およびエンジニアリングアプリケーションの既存のデータモデルの分析と組み合わせて、SEUSの中央サービス倉庫のスケッチ設計につながりました。考慮事項と実験は、ソフトウェア統合の重要な側面を解決するための有効なツールと方法が存在することを示しました。SEUS開発の将来のステップは次のとおりです：

• グラフデータベースが提供する機能の魅力的な代替手段の探索。
• RPCの統合サポートの対応。
• (STEPベースの) 辞書の管理、あるいは辞書と倉庫ソフトウェアの実装の統合。
• パイピング、関連部品、およびそれらが装置とコンパートメントに接続する第二のデモンストレーションケースの開発。

ACKNOWLEDGEMENTS

SEUSプロジェクトは、Horizon Europe枠組みプログラム（HORIZON）EUプログラムの助成契約番号101096224の下で資金提供を受けています。詳細はhttp://seus-project.eu/で更新されています。この記事は著者の見解のみを反映しており、欧州委員会はその情報の利用について一切の責任を負いません。

References

Andrews, D. (2018). The Sophistication of Early Stage Design for Complex Vessels. Trans RINA, Special Edition, IJME, 160, (SE 18).

De Koningh, D., Koelman, H.J. & Hopman, J.J (2011). A Novel Ship Subdivision Method and its Application in Constraint Management of Ship Layout Design. Journal of Ship Production and Design, 27(3), 137-145.

Dusch, T., Franke, B., Grau, M. & Zerbst, C. (2017), Intent-driven CAD vs. Mechanical CAD in Shipbuilding – A review and Solution Outline, ICCAS 2017.

Erikstad, S.O. & Lagemann, B (2022). Design Methodology State-of-the-Art Report. 14th International Marine Design Conference (IMDC), Vancouver, Canada, June 28.

Fonseca, Í.A., Gaspar, H.M., de Mello, P.C. & Sasaki, H.A.U. (2022). A Standards-Based Digital Twin of an Experiment with a Scale Model Ship. Computer-Aided Design, 145, 103191.

Gaspar, H.M., Seppälä, L, Koelman, H.J. & Agis, J.J.G. (2023). Can European Shipyards be Smarter? A Proposal from the SEUS Project. COMPIT’23. Drübeck, Germany, May 23-25.

Gielingh, W. (2008). An assessment of the current state of product data technologies. Computer-Aided Design, 40(7), pp. 750-759.

ISO (2003). ISO 10303. Industrial Automation Systems and Integration: Product Data Representation and Exchange. Part 215: Application Protocol: Ship Moulded Form.

ISO (2004a). ISO 10303. Industrial Automation Systems and Integration: Product Data Representation and Exchange. Part 215: Application Protocol: Ship Arrangement.

ISO (2004b). ISO 10303. Industrial Automation Systems and Integration: Product Data Representation and Exchange. Part 218: Application Protocol: Ship Structures.

ISO (2005). ISO-15926-1. Industrial Automation Systems and Integration - Integration of Life-Cycle Data For Process Plants Including Oil and Gas Production Facilities - Part 1: Overview and Fundamental Principles.

ISO (2018). ISO 19848. Ships and marine technology - Standard data for shipboard machinery and equipment.

ISO (2022). ISO/IEC 81346-1. Industrial Systems, Installations and Equipment and Industrial Products - Structuring Principles and Reference Designations - Part 1: Basic Rules.

ISO (2023). ISO-15926-11. Industrial Automation Systems and Integration - Integration of Life-Cycle Data for Process Plants Including Oil and Gas Production Facilities - Part 11: Simplified Industrial Usage of Reference Data Based on RDFS Methodology.

Kahn, M.T.H. & Rezwana, S. (2021). A review of CAD to CAE integration with a hierarchical data format (HDF)-based solution. Journal of King Saud University - Engineering Sciences, Vol 33 (4). pp 248-258,

Kim, J., Pratt, M.J., Iyer, R.G. & Sriram, R.D. Standardized Data Exchange of CAD Models with Design Intent. . ComputerAided Design, 40(7), pp. 760-777.

Kirkwood, R. & Sherwood, J.A. (2021). Sustained CAD/CAE Application Integration: Supporting Simplified Models. J. Comput. Inf. Sci. Eng. 21(1).

Koelman, H.J. (2003). Application of the H-rep Ship Hull Modelling Concept. Ship Technology Research. 50 (4), pp. 172181.

Koelman, H.J. (2024). Piping Layout Integrated in Ship Design and Stability Assessment. 15^th International Marine Design Conference (IMDC), Amsterdam, Netherlands, June 3-6.

Koelman, H.J., van de Zee, J. & de Jonge, T. (2015). A Virtual Single Ship-Design System Composed of Multiple Independent Components. COMPIT’15. Ulrichshusen, Germany, May 11-13.

Koelman, H.J. & Veelo, B.N. (2013). A technical note on the geometric representation of a ship hull form, Computer-Aided Design 45(11), pp. 1378-1381

Kuryło, P., Frankovský, P., Malinowski, M., Maciejewski, T., Varga, J., Kostka, J., Adrian, Ł., Szufa, S. & Rusnáková, S. Data Exchange with Support for the Neutral Processing of Formats in Computer-Aided Design/Computer-Aided Manufacturing Systems. Appl. Sci. 2023, 13, 9811.

Leclerc, J-C., Keraron, Y., Fauconnet, C., Chauvat, N. & Zelm, M. (2022). New ways of using standards for semantic interoperability towards integration of data and models in industry. 11^th International Conference on Interoperability for Enterprise Systems and Applications (I-ESA 2022), Valencia, Spain, March 23-25.

Maritiem Masterplan (2023). Aanvraag nationaal groeifonds (in Dutch). maritiemmasterplan.nl/wpcontent/uploads/sites/3/2023/10/230203_Maritiem-Masterplan_Verkorte-versie-zonder-appendices.pdf 

Owen, J. (1997). STEP, an introduction. Information geometeers, Winchester, UK.

Qin, Y., Lu, W., Qi, Q., Liu, X., Zhong, Y., Scott, P. & Jiang, X.. (2017). Status, Comparison, and Issues of ComputerAided Design Model Data Exchange Methods Based on Standardized Neutral Files and Web Ontology Language File. Journal of Computing and Information Science in Engineering. 17.

Shiplys (2019). Ship Lifecycle Software Solutions (SHIPLYS). D9.7 SHIPLYS Software and its Functionality in Relation to Existing Standards and Potential for Inputs to Future Standards. www.shiplys.com/library/deliverables/d97-shiplys-softwareand-its-functionality-in-relation-to-existing-standards-and-potential-for-inputs-to-future-standards/ 

Srinivasan, V. (2008). Standardizing the specification, verification, and exchange of product geometry: Research, status and trends, Computer-Aided Design 40(7), pp. 738-749.

Whitfield, R., Duffy, A., York, P., Vassalos, D. & Kaklis, P. (2011). Managing the Exchange of Engineering Product Data to Support Through Life Ship Design. Computer-Aided Design 43(5), pp. 516-532.

Zerbst, C. (2023). OCX on the Way from Research to Industry Practice. COMPIT’23. Drübeck, Germany, May 23-25.