ソフトウェア開発 建築 記事

構造BIM(ST-BRIDGE)の課題を解決する3つの技術

投稿日:

構造BIMに関する課題

BIM(Building Information Model)の普及は急速に進んできています。一方で、一貫構造計算プログラムが中心となっている日本の構造設計において構造データのBIMデータ連携はまだ多くの課題があります。

意匠用の建物情報と構造設計用の情報はデータの考え方が異なるため、構造のことを考えずに作成された意匠用のBIMデータはそのまま構造設計に使うことは難しくなります。

それを吸収するために作成されたのが、日本の構造設計用BIMフォーマットである「ST-Bridge」です。この仕様により、建物躯体情報を各アプリケーション間でやりとりすることがスムーズになりました。

ですが、実務上はまだまだいくつかの課題が残されていることも事実です。

そこで本記事では、残された課題を解決しうる、私達の取り組んでいる技術を紹介します。

技術① GUIDに頼らない、ST-Bridgeの差分抽出「STB-NoGUID-Diff」

設計工程においては、意匠設計者と構造設計者が並行して作業を進めることがほとんどです。

構造躯体の設計を行った後、ST-Bridgeによるデータ連携で構造躯体の情報を意匠用のモデルに反映することということはよく行われています。

ここで問題になるのは、設計工程では構造モデルの取り込みが頻繁に起こりうるということです。

当然、まっさらな状態でST-Bridgeのデータから構造躯体のモデルをアプリ間連携するのは多くの場合うまく行きます。ですが、その後ちょっとした変更があった場合、意匠側での変更もあるため、それを上書きしないように差分だけ読み込みたくなります。では、「差分」とはどのように抽出すればいいのでしょうか?

一般的には、ST-Bridgeには各部材に「GUID」と言われるユニークなIDを付与することができるので、GUIDを照合して部材の同一性を確認し、同一GUIDを持つ部材について差分があるかどうか確認するというアプローチが取られます。しかし、この方法には以下の問題があります。

  • 様々なアプリケーションが付与するGUIDをST-Bridge内に保持・継承しつづけなければならない
  • 同じ部材でも、誤って一度削除したりすると、二度と同じ部材としてみなされない

アプリケーションAで生成された部材に対してGUIDが付与されていたとすると、これをアプリケーションBが読み込んだときに、GUIDをプログラムが保持し続ける必要があります。これを更にアプリケーションC、アプリケーションDとデータを渡していった場合にも、GUIDを引き継ぎ続けていなければどこかでデータの整合が失われます。また、一見モデル的に差がなくても、部材が一度削除したりされると、削除された部材のGUIDが失われ、部材の同一性が照合できなくなる事も考えられます

GUIDによる差分抽出の課題

そこで考えたのが、「階、軸名称を元に部材の一意性を特定する」手法(以下、STB-NoGUID-Diffと表記)です。

よくよく考えれば、2次元の図面でコミュニケーションをとる場合には、「2階のX3-Y2通りの柱を、、」「4階のX2-X3,Y2-Y3間床の、X2通り大梁に取り付くY2通り寄りの小梁を、、」など、階と軸名称を元に同じ部材のことを説明できていたはずです。これは、GUIDのような複雑な決め事がなくても、部材の一意性が特定できることを意味します。

STB-NoGUID-Diffでは、GUIDが振られていなくても、上記のようなルールにより同一の部材を特定することが可能です。それにより、部材の生成、削除、移動を検出できます。さらには、部材の属性に変化はなくても、参照している断面のサイズが変われば部材が変更されたと見なし、差分として抽出する事もできます。

STB-NoGUID-DiffではGUIDによる課題を解決

技術② BIMデータにトレーサビリティを付与する「BIM-Chain」

アプリケーション間でST-Bridgeを用いてデータ連携を行う場合、受け渡したデータがいつ、どの時点のデータなのかわからなくなり、混乱することがあります。たとえば、最新だと思ったら少し古い時点のデータを渡してしまったとか、プランAのデータを渡したつもりが、プランBのデータを渡してしまっていた、というようなことです。

データが複数のアプリケーションに受け渡されていくと、あとからこのデータの流れをトレースすることは非常に難しくなります。

この問題を解決する手段としては、履歴を管理するようなデータベースを構築し、データベースを介してデータのやりとりすることが考えられます。ですが、多くの場合大掛かりなシステムとなりがちです。

それを解決する手段の一つとして考案したのが、「BIM-Chain(※特許取得済)」です。BIM-Chainは、ブロックチェーン技術に着想を得たアイディアです。履歴管理を中央集権的なデータベースで行うのではなく、各BIMデータの中に含めてしまう、分散管理型の仕組みです。これにより、ルールに従って各ファイルに付加情報を含めるだけで、BIMデータのトレーサビリティを付与することが可能になります

従来のデータフロー管理の課題
BIM-Chainが付与するトレーサビリティ

なお、BIM-Chainはアプリケーション名ではなく、定められた規約の名称です。したがって、ST-BRIDGEに限らず、理論上はどのような種類のデータでも組み込むことが可能な仕組みです

BIM-Chainを使ったファイル追跡結果の例

技術③ リモートでのBIMコラボレーションを円滑にする「BCF-API」

BIMは複雑な建物情報の整合を保つ上で非常に有用な技術ですが、図面として意思疎通していたときよりもコミュニケーションが複雑化する場合もあります。図面では2次元の情報に落とし込まれた状態でコミュニケーションを取っていましたが、BIMでは3次元データとしてコミュニケーションを取ることになります。3次元データは同じディスプレイを見ながら、その場で視点を切り替えつつ議論するには有用ですが、同じ空間にいない人に情報を伝達するのは少し面倒な場合があります。2次元の図面であれば、当該図面の着目箇所にマークをつけてコメントを書き込むという手段がよく取られますが、3次元だとそのような情報伝達が気軽に行いづらかったりします。

そこで活用できる技術が、「BCF(BIM Collaboration Format)」です。

BCFは、buildingSMARTによって策定されている、BIMによるコミュニケーションを円滑化するためのフォーマットです(https://www.buildingsmart.org/standards/bsi-standards/bim-collaboration-format-bcf/)。

3次元データに対する視点の情報や、そのビューに対するコメントなどを表現することができます。

KKEが開発した情報共有のためのグループウェアであるBimClip(https://wm.kke.co.jp/bimclip-lp/)はBCF-APIに対応していますので、下図に示すようにBimClipを経由してインターネット越しに3次元モデルに対する議論を行うことができます。

近年はWeb会議も浸透しましたので、Web会議で画面共有しながらコミュニケーションを取ると同等のことは行なえますが、BCF-APIを活用したシステムでは会議よりも頻繁に行われるメールやチャットのようなコミュニケーションを効率化することができます。メールでは表現しきれない詳細まで瞬時に伝わるので、コミュニケーションコストが減少します。

さいごに

構造計画研究所では、BIMに関する受託開発を行っています。

本記事では構造BIMに着目し、現状の課題を解決できる可能性のある技術を紹介いたしました。同様の課題が業務のネックになっている場合には、ぜひご相談ください。

また、今回ご紹介した技術に限らず、BIM関連システム開発は多くの実績がございますので、ご興味があれば以下もご参照ください。

https://bim.kke.co.jp/

本記事に関するお問い合わせ、開発のご相談は以下のURLから行えますので、お気軽にお問い合わせください。

https://kaiseki-kke.jp/contact/

参考になった! (まだ評価がありません)
読み込み中...

問い合わせ先

各種ご相談は下記連絡先でお受けしております。

  • 解析コンサルティングのご依頼
  • ソフトウェアのご購入、レンタルのご相談
  • プログラム、システム受託開発のご相談

株式会社構造計画研究所 エンジニアリング営業部


クリックすると、お問い合わせフォームが別ウィンドウで開きます。

-ソフトウェア開発, 建築, 記事
-, ,

Copyright Ⓒ 2019 KOZO KEIKAKU ENGINEERING Inc. All Rights Reserved.