BIM・IFCブログに戻る
これまでに書かれたほぼすべての EIR には「すべてのドアに耐火等級を記載すること」といった一文があります。そしてどのプロジェクトでも、その一文は同じ方法でチェックされます。誰かがモデルを開き、ドアをいくつかクリックして「たぶん大丈夫」と判断する。要件は厳密なのに、チェックは雰囲気です。
IDS（Information Delivery Specification）は、このギャップを埋めるために存在します。buildingSMART が IDS 1.0 として標準化した小さな XML 形式で、情報要件を機械がテストできる形で記述します。要件を一度書き、.ids ファイルを各受注者に渡せば、「たぶん大丈夫」は「418 枚中 412 枚のドアが合格。不合格の 6 枚はこれです」に変わります。
この記事のポイント
- IDS が検査するのは形状ではなく情報です。クラス、属性、プロパティ、分類、材料、関係。
- すべての仕様は 2 つの部分からなります。どの要素に適用するか、そしてそれらの要素が何を持つべきか。壊れた IDS ファイルの多くは前半で間違えています。
- IDS は契約図書です。BEP の隣にバージョン管理して置き、最初の差し戻しの後ではなく、モデリング開始前に受注者へ送ります。
仕様の構造
IDS の仕様は 1 つの文として読めます。適用範囲に当てはまるすべての要素に、要件を求めます。
IDS ファイルは仕様のリストです。各仕様は主語と述語を持つ文のように読めます。「これに該当するすべての要素について、あれを要求する」。主語が適用範囲、述語が要件です。
<specification name="Doors carry a fire rating" ifcVersion="IFC4">
<applicability minOccurs="1">
<entity><name><simpleValue>IFCDOOR</simpleValue></name></entity>
</applicability>
<requirements>
<property dataType="IFCLABEL">
<propertySet><simpleValue>Pset_DoorCommon</simpleValue></propertySet>
<baseName><simpleValue>FireRating</simpleValue></baseName>
</property>
</requirements>
</specification>
声に出して読むと、まさに EIR の一文です。すべての IfcDoor は Pset_DoorCommon に label として FireRating を持たなければならない。適用範囲にある minOccurs="1" は、見落とされがちな 2 つ目の条件を加えます。モデルには少なくとも 1 枚のドアが含まれていなければならない、ということです。これがないと、ドアが 1 枚もないモデルも合格してしまいます。それを意図する人はまずいません。
6 つのファセットと、それぞれが実際に検査するもの
| ファセット | 検査内容 | 典型的な要件 | よくある落とし穴 |
|---|
| Entity | IFCクラスと定義済みタイプ | 壁は IfcBuildingElementProxy ではなく IfcWall | サブタイプを忘れる：IFC2x3 では IfcWallStandardCase も IfcWall |
| Attribute | 直接の IFC 属性（Name、Description、Tag…） | すべてのスペースに Name と LongName がある | 空文字列は「欠落」ではなく「存在するが無効」 |
| Property | プロパティセット内のプロパティ（データ型と値つき） | Pset_WallCommon.IsExternal が TRUE または FALSE | 値は正しいがデータ型が違う（ブール値の要求に label） |
| Classification | 分類参照とそのコード | すべての要素に Uniclass Ss コードがある | コードだけ確認し、所属する分類体系を確認しない |
| Material | 関連付けられた材料名またはカテゴリ | 構造柱に材料が定義されている | 材料がオカレンスではなくタイプに付いている |
| PartOf | 親要素との関係 | すべての要素がいずれかの階に含まれている | 集約と空間的包含を混同する |
各ファセットは、適用範囲（要素の選択）にも要件（要素への要求）にも使えます。このうち 2 つの落とし穴は詳しく見る価値があります。初めて IDS を実行したときに報告される誤検出の大半は、この 2 つが原因だからです。
タイプとオカレンス
プロパティはオカレンスではなくタイプにあることがあります。IDS チェッカーがタイプをたどらないと、正しい要素を不合格にします。
Revit、ArchiCAD、Tekla は、プロパティや材料を各壁ではなくタイプオブジェクト（IfcWallType）に書き込むのが一般的です。IDS のセマンティクスは明確で、タイプから継承された情報はオカレンスにも有効です。オカレンスしか見ないチェッカーは、まったく問題のないモデルのすべての壁を不合格にします。プロパティパネルで見えているプロパティが要素の 100% で欠落していると IDS が報告したら、原因はほぼ確実にこれです。悪いのはチェッカーで、あなたではありません。
USERDEFINED の定義済みタイプ
定義済みタイプが USERDEFINED の場合、実際のタイプは ObjectType（オカレンス）または ElementType（タイプ）に入っています。定義済みタイプ PARAPET の IFCWALL を要求する entity ファセットは、PredefinedType が USERDEFINED で ObjectType が PARAPET の壁に一致しなければなりません。列挙値をそのまま比較するチェッカーは、これをすべて見逃します。
IDS を役に立たなくする 5 つの間違い
- 適用範囲が広すぎる。「すべての要素に Uniclass コードが必要」とすると、誰も分類しない開口部や注記、空間要素まで巻き込みます。各仕様は、要件が本当に対象とするクラスに絞りましょう。
- データ型のない値。FireRating =「EI 60」という要件は、どう保存すべきかを何も言っていません。同じ文字列が別の pset の説明として保存されていても不合格になります。データ型も含めて、意図を明記しましょう。
- パターンにすべきところを完全一致にする。実データには「EI60」「EI 60」「EI-60」が混在します。xs:pattern か列挙を使い、正式な表記を BEP で合意しましょう。
- 巨大な 1 つの仕様。1 つの仕様に 40 の要件を詰め込むと、要素ごとに合否が 1 つしか出ず、誰も対処できないレポートになります。1 仕様 1 要件、分かりやすい名前をつけることで結果が読めるようになります。
- モデルの後に IDS を書く。最初の差し戻しと一緒に送られた IDS は新しい要件です。発注時に送られた IDS こそが要件です。強制できるのは後者だけです。
最後の点の契約面、つまりどの条項で IDS に拘束力を持たせ、納品が満たさない場合にどうなるかは、質の悪い IFC 納品を本当に防ぐ BEP 条項とIFC の受け入れ基準で解説しています。
モデルに対して IDS を実行する手順
- IFC を開く モデルをビューアにドラッグします。解析はブラウザ内で行われ、何もアップロードされません。
- .ids ファイルを読み込む IDS パネルを開いてファイルを選択します。まず形式を見たい場合は、付属のサンプル仕様から始めることもできます。
- チェックを実行する すべての仕様が 6 つのファセットで評価されます。大きなモデルでは段階ごとに進捗が表示され、いつでもキャンセルできます。
- 仕様・要素・クラス別に結果を読む 修正の進め方に合わせて不合格項目をグループ化します。各項目には理由が平易な言葉で示されます。プロパティ欠落、値の誤り、データ型の誤り、クラスの誤り。
- 3D で確認する 「ハイライト」で不合格の要素をモデル上で着色し、「分離表示」でそれ以外を非表示にします。どちらもワンクリックです。こうして GlobalId のリストが、モデラーとの会話に変わります。
リビジョンをまたいだ IDS
1 回の IDS 実行はスナップショットにすぎません。コーディネーターが本当に必要とするのは推移です。リビジョン 7 はリビジョン 6 で指摘された不合格を修正したか、新たな問題を持ち込んでいないか。結果は GlobalId をキーにしているため、同じ仕様をモデルの 2 つのバージョン間で比較できます。ただしそれは、エクスポートごとに GlobalId が安定している場合に限ります。そうでなければ、まずそれを直しましょう：IFC の GUID がエクスポートのたびに変わる理由。比較そのものはIFC モデルの 2 つのバージョンを比較する方法で解説しています。
IDS が扱わないもの
IDS は形状を検査しません。2 本のダクトが干渉していること、ドアが車椅子には狭すぎること、モデルが測量基準点から 2km 離れていることは教えてくれません。IFC が構造的に健全かどうかもチェックしません。GlobalId が重複していたり配置が壊れていたりするファイルでも、IDS には完璧に合格し得ます。
これは弱点ではなく、範囲の問題です。情報要件には IDS、構造と形状にはモデルチェッカーを使い、両方のレポートを並べて納品しましょう。全体の流れはIFC ファイルを検証する方法にあります。
IDS 解説：Information Delivery Specification で IFC モデルをチェックする方法
