*平成13年度に開催されたサンフランシスコ会議で、AP217: Ship Pipingが正式にcancelされ、AP227 2^nd EditionにてShip Pipingの開発が行われることになった。

　

　プロセスプラント、プラントシステム、シップ（船）システムの空間構成情報を交換するためのアプリケーションプロトコルを規定する。この情報には配管、HVAC（熱、換気、空調）、電装システム構成部品とともに、他の関連するプラントシステム（機器、制御装置、構造等）の形状や空間配置特性が含まれる。なお、このAPの概要を図3.2.4に示す。

　

　「プラントおよび船の配管を設計するときに適用される規格でその範囲」（適用範囲）は次のようになる。

　

　適用範囲の対象から外れるものを以下に示す。

　

　「系がもつ空間配置の情報を交換するための要件」（情報要件）が定義されている。

　アプリケーションオブジェクトと呼ばれる機能の最小単位およびアプリケーションオブジェクト間の関係をアプリケーションアサーションとして定義していて次のものがある。

　

　STEPはアプリケーションプロトコルのより上位の概念にリソースという統合化された概念をもつ。

　適合性クラスはこのリソースへの要件を定義する。

　以下に適合性クラスを示す。

　

　適合性クラスは次のように機能単位と関連をもつ。

　

　

　

　適合性クラスはリソースで実装されるAIMへの対応をもち下図のようになる。

　

　

　これまでに提案されたシナリオの例を以下に示す。

　

　

　下図は直径3-inchの円柱状の管（P1）と押し出し加工の構成部品（PLE1）が干渉している例である。

　

　

　ARMはP1のタイプをStraight pipe、ラベルをP1-1、PLE1のタイプをstructural_component、ラベルをPLE1-1としてもつ。

　ARMがもつstraight_pipeエンティティは次のような階層でplant_itemが特化されたエンティティである。

　ここで｜は上段が汎化であり下段が特化を表し、（）内はエンティティがもつ属性である。

　

plant_item(description name plant_item_id status）

|piping_system_component(coating_reference lining）

||piping_component(side_connector standard_point pmi_record mill_sheet_number）

|||pipe(end_1_connector end_2_connector additional_length）

||||straight_pipe(end_to_end_length end_to_end_cut_length）

　

　下図において#10および#11はP1のインスタンスである。

　ところでstraight_pipeエンティティはpiping_system_componentおよびpiping_componentの特化エンティティであるにも関わらず#10および#11のインスタンス図にはこれらのエンティティがない。

　これはplant_itemの特化エンティティにplant_item_definitionが存在していてis_defined_byの役割（role）が実装されているためである。

　干渉という物理的な特性はARMのplant_item_interferenceによって表現される。下図の#1がそれになる。

　#5、6、7、8および#12、13、14、15は#3および#10のspatially describesの役割を切片として形状の情報をもつ。

　#9および#16は干渉が生じた部分を朱色で指定するための機能的なインスタンスである。

　

　

　

　

　AP226 Ship Mechanical Systemsは、英国LRのZabi Bazar氏を中心に開発が進められ2002年4月にCD投票に入ったが、この1〜2年位前からLRによる資源の供給がままならぬ状態になり、非常に苦戦していた。結果としてCDドキュメント、特にディクショナリの完成度は甚だ良くなく、またCDの時点ではDIS、ISと継続していけるだけのファイナンスの裏付けがない状態に陥った。

　一方、我が国は船舶のAPの中でも機関部が尤も現実のビジネス現場に近いという判断から、ここ数年力を入れて来た。初期よりマッピングの開発ワークショップへの参加やプロトタイプの開発などに取り組み、ドキュメントの解読も最も進んでいた。その様な背景からCD投票に当たっては、ディクショナリの部分が現実にそぐわないことを指摘し、この個所をformativeからinformativeにすべきと主張した。

　これに対してヨーロッパ勢は、（ファイナンスの枯渇を最大の原因として）これ以上現行のAP226の開発を継続する事は出来ないという判断やRDLを使いたいという半ば政治的な判断^注1から、AP226開発の中止とPLiBからRDLへの変更を持ち掛けてきた。そしてその解決策としてAP227 Plant spatial configurationの一部として組み込むことを主張し、結果的に米国がこれに応じたことで、方向性は決定的なものとなった。日本は規格開発に直接関与するだけの人・資金的な裏付けを持たない現実に基づいてこの方向転換に従わざるを得ない状況になった。

　ところで、Ship Mechanical Systemsの要件をAP227 2^nd Editionに組み入れる作業は難航を続け（技術的かつ資金的な両面で）、当初の思想であったライブラリの明示的な組み込みは断念され、AP227の最終版では、緩やかな形で外部のライブラリと連携が取れる口を設けるだけの方向に向かった。予定では今年度中にその新しいドキュメントが発行される事になっていたが、2004年2月現在では未だ公開されていない。その意味において、Ship Mechanical Systemsを的確に表現するShip APは未だ完成してない状態である。ただ2^nd Editionで実現される内容が上記の程度であれば、船舶のビジネスとしては大きな影響は受けないものと判断される。そもそもライブラリを用いた機器表現は電子機器を筆頭に既にいろんな先進事例があり、その規格及び利用体系はほぼ確立されていると思われるからである。なお、AP227におけるShip Mechanical Systemsの位置付けは、AP226のフルスペックをカバーする方向で示されていた（SMS = Ship Mechanical Systemsと呼ばれていた）が、途中でこれをSimple Mechanical Systemと呼びなおすなどの策も講じられていた。最終ドキュメントではこの呼び名が使われるはずである。

　

　AP227でShip Mechanical Systemsを実現するに当たって、問題になったのはAP226が骨格として持っていたパーツライブラリ（PLiB）による表現形式の扱いであった。ライブラリによる表現方法を取るのは当然として、その方法を、AP226を継承してPLiBによるか、Oil&Gasなどの流れをくむRDLにするかの議論が華々しく展開されたのは記憶に新しい。しかしながら開発リソースという観点から見ればこれらのライブラリの開発は極めて問題が多いというか、多大な労力と時間を要するものであり、未だにOil&GasやAP221で完了していない事実からみても自明である。

　その結果、AP227の最終版では、ライブラリを限定することなく、またそのコンテンツは棚上げにして、いわば玉虫色の解決策が取られようとしている。その問題をどう考えるかは極めて難しいが、規格としては大きな構造を表現して、実際の利用のストーリには、自由度を持たせているという考えもありうるものとも思える。