年寄りらしく、昔話と現在、そして（見ることが無さそうな）近い未来のデータ交換について、危うい記憶と妄想を書いてみました。

1990年頃、AutoCADのデータ形式としてDXFは存在していましたが、未対応のソフトが多く、使用しているソフトでも未対応であった頃です。

意匠図などが手書きで、社内のCADで建築図入力をするのが最初の仕事だった頃です。手書き図面のスキャナによる読込にも挑戦していましたが、実務に使用できるレベルではありませんでした。

建築側のCAD化は進んでいませんでしたが、その中で出てきた2D建築CADがあり、出力する白図（テキストデータ）を読み込んで設備CADのデータに変換する機能を開発しました。当該建築CADの普及が期待ほどではなく、実際の利用の広がりは少ない結果になりました。

設備CADで作成した竣工図を、客先が機器製造に使用していたホストベースの2DCAD（CADAM）にデータ変換して提出する要請があり、対応した事例です。

客先のCADが読めるデータ形式は、製造業で使われているIGES形式でした。このため、設備CADデータをIGES化するソフトを自社開発しました。

データ形式以外にも、お互いの違いを解消するための作業が必要でした。

IGESはテキスト形式でしたが、文字コードをIBMのEBCDIC形式にする必要があったため、変換を行いました。

提出に使用するメディアもオープンリールテープにする必要がありました。元データであるフロッピーディスク（データ）を送るために、当時はスタンドアロンで使用していたPCを、3D−CAD用に使用していたEthernetネットワークに接続し、データを3D-CAD用に使用していたエンジニアリングワークステーション（EWS）経由で3D-CADの初期システムのあるミニコンピュータに送り、そこでオープンリールテープに書き込みを行いました。

データ形式、文字コード、保管メディアの３種の変換が必要でした。

現在はネットワークの進展でメディアの問題は解消されています。文字コードもUnicode化の進展で、時々引っかかる位になってきました。データ形式の問題は満足とは言えませんが、2DはDWG(DXF)、3DはIFCで交換できる場面が増えてきました。

データ交換に使用できる仕様が使える状態ではなかった頃に、社内利用を前提として、自社（または特定企業間）のルールで中間ファイルを決定して運用した独自形式などでの交換を行った事例を、最近の例も含めて幾つか紹介します。

社内で、設備CAD作図データを元に配管プレハブ化を支援するソフトを開発しました。その際に、設備CADからデータを読み込むソフトを開発しました。図形だけではなく、配管としての属性、管材、弁種類などを読み込む機能を開発しました。

配管プレハブ化支援ソフトのアイソメ図面等の出力結果を他のCADに2Dで渡すために、DXF形式での出力機能を付加しました。

また、プレハブ配管加工会社との間で管一品情報や組み立て情報を交換するための交換仕様を取り決めてソフト化し、実際に加工を行う試行を実施しました。

これは、試行レベルで終了してしまいました。社内で作成していた作図データは、図面としての見た目は実務に使用できても、属性の正確性や管路の接続状態などのデータレベルの面で不十分であり、プレハブ支援ソフトでのケアがかなり必要であったことが要因で、普及には至りませんでした。

PCベースの設備CADデータを3D化して動画化するなどの処理をするために、PC-CADの施工図データを3D-CADの部材入力コマンド列に変換するソフトを開発しました。その出力をネットワークで3D-CADを実装しているEWSに送り、そこでコマンドとして実行し、3Dモデルを生成しました。この結果を3Dの静止画や動画として作成し、プレゼンに使用しました。

Revitの設備データを社内の技術計算プログラムで使用するための開発を行いました。

Revitアドインとして、主として属性情報を取得して社内で設定したXML形式で出力するソフトを作成しました。技術計算プログラム側にXML形式データの読み込み機能を追加し、これにより、IFC連携と同様に静圧・揚程計算などに使用できるようにしました。

1990年代中期に、C-CADECの成果として図面単位に設備部材の属性付き交換を行うBE-Bridgeが設定され、当時のCADベンダーの多くが対応しました。図面単位ではありますが、異なったCAD間での属性付きの情報交換や共有が可能になりました。BE-Bridgeは初期はダクト・配管部材のみが対象でしたが、建物部材や電気部材の追加、制気口の追加が行われました。

IFCは1990年代より検討がなされ、1995年のIFC1.5の仕様公開から段階的な拡張を経て、2007年のIFC2x3が国際的に広く利用されるようになりました。現在はIFC4の利用が進んでいます。国内でも2010年頃よりIFC利用が立ち上がりました。最初に建築（意匠）の情報が作成されるようになり、設備CADベンダー各社が読み込み対応を個別に開始しました。

設備CADでの建築データ読込み対応が進む中で、設備データ交換の要望が出始めましたが、建築データ対応では建築側のソフト（Revit、ArchiCADなど）によってIFC出力に異なった表現の部分がありました。

設備のデータ交換を行う際に、ベンダーごとの対応ではIFCを使っていても交換性が確保できない可能性がありました。bSJ（buildingSMART Japan）で行った海外CADのIFC出力の調査でも、属性出力部分が非互換であることが確認されました。

2011年には、bSJの設備・FM分科会（現在は設備環境小委員会）で国内向けのIFC表現の標準「設備IFCデータ利用標準」が、複数の設備CADベンダーが協力する体制で策定されました。

IFCは仕様が広範囲であるため、用途に応じたIFCの利用範囲の取り決めを行う必要があります。（IDM、MVD）その取り決めのなかで、機器・ダクト・配管部材に付加する属性項目などが取り決められます。

設備IFCデータ利用標準では、その取り決めのベースを、機器についてはSTEM、ダクト・配管・電気などの部材についてはBE-Bridgeという国内標準によっています。既に存在している標準を使用したことで、IFC対応の負荷を比較的少なくすることができました。

参加ベンダーが自社ソフトでIFC対応したことで、国内ベンダー間の設備データ交換は交換性良く実施できるようになりました。この利用標準は現在も対応が維持され、現場での利用が普通に行われています。

IFCでのデータ交換が普通に行われる状態にはなっていますが、交換できる範囲の制限がBIMの適用範囲の拡大に向けて足枷になっている部分も見えてきました。

また、機器や部材の定義の古さも顕在化しています。ベースに使用しているBE-BridgeやSTEMは1990年代に主要な定義が行われました。20年以上が経過し、新しい機器や配管部材が多く出てきたことで、BIMソフトは対応していても交換できない状態が生じています。

IFCは建築関連のみの定義から土木を含んだ大きな標準になっています。表現できる情報は多いですが、特定の建物、特定の用途、特定の利用者にとっては、不足する情報も顕在化しています。当社でも建物の運用段階での利用などでは、交換対象外となっている情報が見えてきています。

1990年代頃までの交換標準では、標準の中で設定している情報のみが交換/共有の対象でした。IFCはPropertySetという属性定義の概念で、独自情報を定義してIFCで交換する仕組みが導入されています。情報を出す側と読む側で対応がなされていなければ交換/共有はできませんが、仕組みとしては特殊な情報の交換も可能になっています。設備IFCデータ利用標準でも、この機能を使って部材の定義を行っています。

bSI(buildingSMART International)ではIDS（Information Delivery Specification)という仕組みが検討され、提供されています。これは、建築分野のIFCファイルにどのような情報が必要かを、コンピュータ処理可能なXML形式で定義するものです。これによれば、設備IFCデータ利用標準のように固定されたIFC表現ではなく、利用者自身のニーズに合ったIFCの取り決めを作ることができます。IDSを編集し出力するソフトも提供されてきています。

ただし、関連ソフトがこの取り決めを理解して対応する機能を持たなければなりません。開発者にとっては大きな負荷になると思いますが、ライブラリ化などの進展で、読み書き部分の開発負荷への影響は低減できると考えられます。しかし、ソフトに読んだ後でのデータ項目の利用は難しそうです。

私自身も助けてもらっているAIさんが助けてくれる時代になりましたので、近い将来は、データ構造や仕組みをIFCなどにするにしても、それを意識しないで情報の交換や共有ができるようになるかもしれません。

※　今回も略語表記の説明は行っていませんので、興味のある方は調べてみてください。