Industry Foundation Classes Release 2.0

IAI ＆ IFC イントロダクション

平成 11 年 4 月 15 日

International Alliance for Interoperability

建設業界の相互運用を目指してCopyright 

1996-99 - International Alliance for Interoperability

Mailing address:

2960 Chain Bridge Road – Suite 143
Oakton, Virginia 22124

Email address:

IAI＠interoperability.com

Web Address:www.interoperability.com

IAI & IFC イントロダクション– IFC Release 2.0

もくじ
今日の建設業界の状況････････････････････････････････ ･････････････････････ 1
他の業界との比較 ･････････････････････････････････････････････････････････････････2

IAI (International Alliance for Interoperability) ･･････････････････････････････ 2
IAI について ･･････････････････････････････････････････････････････････････････････2
IAI のビジョン，ミッションおよびバリュー ････････････････････････････････････････････････3

IAI の組織 ････････････････････････････････････････････････････････････････････････4
支部 ･･･････････････････････････････････････････････････････････････････････････････････4
会員資格 ･･･････････････････････････････････････････････････････････････････････････････4
会費 ･･･････････････････････････････････････････････････････････････････････････････････4分科会 ･････････････････････････････････････････････････････････････････････････････････5
国際組織 ･･･････････････････････････････････････････････････････････････････････････････5

モデルについて････････････････････････････････ ･･･････････････････････････ 7
モデルの定義 ･････････････････････････････････････････････････････････････････････7プロセス・モデル ･･･････････････････････････････････････････････････････････････････････7
オブジェクト・モデル ･･･････････････････････････････････････････････････････････････････7

IFC (Industry Foundation Classes） ････････････････････････････････ ･･･････ 8
IFC の実装 ･･･････････････････････････････････････････････････････････････････････9
IFC のリリースサイクル ･････････････････････････････････････････････････････････ 10
IFC の開発方法 ･････････････････････････････････････････････････････････････････ 10
IFC リリースの配布物 ･･･････････････････････････････････････････････････････････ 15

IFC リリースとリリース予定････････････････････････････････ ･･････････････ 16
リリース 1.0 ････････････････････････････････････････････････････････････････････ 16
リリース 1.5 ････････････････････････････････････････････････････････････････････ 16
リリース 1.5.1 ･･････････････････････････････････････････････････････････････････ 17
リリース 2.0 ････････････････････････････････････････････････････････････････････ 17
リリース 3.0 ････････････････････････････････････････････････････････････････････ 17

IAI に関するその他の情報････････････････････････････････ ･････････････････ 18
Web サイト ････････････････････････････････････････････････････････････････････ 18
支部の Web サイト ･･････････････････････････････････････････････････････････････ 18
FTP サイト ･････････････････････････････････････････････････････････････････････ 18
E-mail リスト ･･･････････････････････････････････････････････････････････････････ 18
公式言語 ･･･････････････････････････････････････････････････････････････････････ 18

IAI と STEP について････････････････････････････････ ･････････････････････ 18

Copyright  1996-1999 International Alliance for Interoperability
Page iIAI & IFC イントロダクション– IFC Release 2.0

Copyright  1996-1999 International Alliance for Interoperability
Page ii

IAI & IFC イントロダクション– IFC Release 2.0

今日の建設業界の状況
今日の建設業界は、多くの業種で構成されています。それぞれの業種は、独自の専門用語，技術
そして情報の表現と伝達方法を使用し独立して発達してきました。結果として、各業種間で情報を共有する場合に多くの問題を引き起こしてきました。同じ業種の中でさえ、プロジェクト情報の損失やコミュニケーション上での困難が存在します。共同作業をする場合、プロジェクト費用の追加が莫大になっています。この問題を早急に解決するために IAI(International Alliance forInteroperability）が発足しました。
現在、建設業界の CAD アプリケーションは、これら業種の情報の共有化ということに対して、ほとんど機能を持ちあわせていません。例えば、最近完成したデンバー国際空港において、プロジェ
クト実施中に発生した問題点が新聞紙面で大きく取り上げられ、この点が指摘されました。それは、設計者が作業を開始した時点で、20 以上の異なる業種が、さまざまなプラットフォームの CADとサードパーティーのアプリケーションを使用していたという事実です。これによって各業種間でのデータ交換ができないことから、つぎの 2 つの解決策が考え出されました。
1． ソフトウェアのプラットフォーム統一による方法
この方法は、いくつかの設計会社にとっては、新しいソフトウェア、さらにはハードウェアの購入にかなりの出費が必要となり、しかも、スタッフは、新しいツールに熟練する必要が生じます。

建築
土木

構造

施主

設備

制御

ＦＭ
施工

図 1 建築分野の複雑なコミュニケーシ

建築

2． アプリケーション間共通部での情報交換による方法
この方法は、会社にとっては最も慣れた方法で作業をすることができますが、一部データ欠落などの問題があります。(例
えば、DXF ファイルによる変換)

土木

構造

共有
プロジェクトモデル

施主

設備

結局、経済的な理由で後者の解決策が選ばれまし
た。
制御

ＦＭ

上記のデンバー国際空港プロジェクトは、今日の建設業界の代表的な状況を示しています。

施工

データ共有化による相互運用（Interoperability）
図 2 相互運用の概念図
をソフトウェア上で解決できてないということは、いろいろな面で生産性工場の障害となっています。このことは、建築ライフサイクル、すなわち、設計，施工，および保守管理において、非効率的な作業過程をもたらします。多くの担当者はライフサイクルの中で同じような作業状況に遭遇し、何度も情報の追加や検索を行わなければなり
Copyright  1996-1999 International Alliance for Interoperability
Page 1IAI & IFC イントロダクション– IFC Release 2.0

ません。しかしながら、高度情報化時代にありながら、ほとんどの作業で多くの無駄が発生しています。
以上のことから IAI では、データを共有化し、相互運用するための活動を行います。具体的には、コンピュータを利用した高度情報化に対し、標準化を図り、異なるソフトウェア・アプリケーシ
ョンでも利用できるデータの共有化とその活用の実現を目的としています。

他の業界との比較
建設業界は、他の業界からは多くの点を学ぶことできます。特に一品生産という点では、プラントや造船業界と大変類似しています。しかし、技術の進展においては、建築よりも他の業界のほうがはるかに大きな期待があります。
建設と他の業界との間で技術的な進展で異なる点は：• 他の業界は、技術進展に対して莫大な予算を投じることができる。
• 他の業界は、業界ニーズを実現する「技術」に対してバックアップする中心的組織がある。
• 他の業界は、建設業界に比べてそれほど複雑な他業種との連携を持たない。
などをあげる事ができます。
実際に予算と組織という点において、プラント業界は、STEP（ISO 10303 の Part 221 と 227）で情報共有の標準化を推進する EPISTLE と PIBASE を設立しました。また、造船業界においても欧米が中心となり、同様に STEP（ISO 10303 の Part 215、216 そして 217）で標準化を進めています。

IAI (International Alliance for Interoperability)
IAI についてIAI は、建物のライフサイクルを通して、利用するソフトウェア間で、有効な相互運用を可能にするための標準化を目的としています。
当初 IAI は、建設業界に携わる北米 12 の会社によって設立されました。
これらの会社は、相互運用の問題点の解決策を示すために、1995 年 6 月のジョージア州アトランタで開催された A/E/C Systems Show で、一連のプロトタイプ・アプリケーションを展示しました。
これらのプロトタイプは、理想とする相互運用が実現できることを立証しました。
この公開デモンストレーションの成功により、当初の 12 社は 1995 年 9 月、世界中の建設業界に対して、この活動への参加を募りました。こうして、国際的な IAI が誕生しました。

Copyright  1996-1999 International Alliance for Interoperability
Page 2

IAI & IFC イントロダクション

North America

United Kingdom– IFC Release 2.0

NordicJapan

FranceKorea

German Speaking

Singapore

Australasia

図 3 IAI 国際支部

Austria

Australia

Belgium

CanadaDenmark

FinlandFranceGermany

Hungary

Ireland

Japan

Korea

Netherlands

New Zealand

NorwaySingapore

Switzerland

South Africa

SwedenUK

USA

IAI のビジョン，ミッションおよびバリュー
ビジョン
建設業界の相互運用を可能にすること。
ミッション
プロジェクトのライフサイクルを通して、各業種とソフトウェア・アプリケーションで使用する共有データの仕様の定義，利用の推進、そして広報活動すること。
バリュー• 非営利団体• オープンな会員資格• 協調組織• コンセンサスによる意志決定• 研究成果を適宜公表
Copyright  1996-1999 International Alliance for Interoperability
Page 3

IAI & IFC イントロダクション– IFC Release 2.0• 国際的なソリューション
• ソフトウェア専門家と建設業界専門家の共同作業による標準仕様の定義• 仕様公開• 拡張性のある仕様• 最新技術対応

IAI の組織
IAI は、国際的組織で支部組織を構成して活動しています。

支部
各支部は、IFC の統合を運営する国際評議会とともに、各支部独自の組織構造を持ちます。各支部の組織構造は、事務局、幹事会、技術統合委員会、および各分科会を組織します。各支部は、支部で行われるそれぞれの組織の運営を行います。

会員資格
IAI 参加資格制度は、オープンになっています。このことは、建築家，エンジニア，施工業者，建物の所有者および管理者，建築製品製造者，ソフトウェア・ベンダー，情報プロバイダ，政府機関，研究室そして大学を含めた、建設業界の様々な組織が自由に参加できるようになっています。
IAI 加盟会社の代表者は、大きくは 2 つの業種に携わる専門家です。1 つは、建設業界の専門家で、建築家，エンジニア，施工業者および設備管理者といった建築業界で日常の専門業務に携わる人
で、エンドユーザの立場となります。 もう 1 つは、技術専門家で、ソフトウェア開発を行うデベ
ロッパーの立場となります。
建設業界専門家は、IAI と IFC の仕様に準拠したアプリケーションを利用することによって、莫大な利益を享受することができるエンドユーザです。
ソフトウェア技術専門家は、研究，ソフトウェア設計および工学にバックグラウンドをもつ個人で、一般的に建設業界で経験を持っています。
これらの 2 つの専門家グループは、共有プロジェクト･モデルを定義するという共通のゴールに向かって協力していきます。

会費
IAI は、会員の会費により運営される非営利団体組織です。
この会費は、以下のような目的に使用しています。
• 支部の各分科会と技術統合委員会の開催費用• 国際会議への参加費用• ドキュメントの翻訳費用• 広告宣伝• IFC 仕様書の配布

Copyright  1996-1999 International Alliance for Interoperability
Page 4

IAI & IFC イントロダクション– IFC Release 2.0

分科会
各分科会は、業種別のそれぞれの専門領域で経験を持つメンバによって構成されます。
技術統合委員会は、選ばれた業種の専門家により統括され，技術専門家により協同で運営されます。
各分科会ごとに、全体の共有プロジェクト・モデルに適用する特定の業種別のモデルの仕様作成を行います。建材メーカーやソフトウェア・ベンダーも分科会のメンバとなり、各業種の専門家との調整を行っていきます。分科会間の会議や調整は、技術統合委員会で運営しています。

幹 事 会

分 科 会

事 務 局

技術統合委員会

図 4 IAI 支部組織

国際組織
IAI の国際組織は、各支部から構成される非営利団体です。IAI の活動を推進するための国際評議会を年 2 回開催しています。
国際組織は、以下の委員会を統括します。
• 国際評議会（IC：International Council）
各支部から任命された 2 名で構成される IAI を運営する最高機関。
• 国際幹事委員会（EXCOM：International Executive Committee）
国際的な各国のビジネス動向を調整したり国際会議の活動や基金を管理するグループ。
EXCOM のメンバは、国際ビジネス・マネージャ（IBM：International Business Manager）、
国際技術委員長（ITD：International Technical Director）と必要に応じて国際組織が要請するメンバで構成されます。
• 国際技術委員会（ITM：International Technical Management）
国際的技術活動を統合し、全 IFC プロジェクトの整合性をとり、各支部で使用可能な世界標準を作成するグループ。
Copyright  1996-1999 International Alliance for Interoperability
Page 5IAI & IFC イントロダクション– IFC Release 2.0

国際技術統合委員会は、各支部の技術統合委員長、国際プロジェクト・リーダーおよび国際技術委員長で構成されます。
• 仕様開発タスク・フォース（STF：Specification Task Force）
IFC オブジェクト・モデルと仕様書開発する技術者の専門グループ。
• ソフトウェア・インプリメンテーション委員会（SIC：Software Implementation Committee）
IFC を実装するソフトウェア会社の要望をまとめるグループ。
• 学術諮問委員会（RAC：Research/Advisory Committee）
今後の IFC 戦略の指針を定めるための委員会内顧問グループ 。

事務局

支 部 組 織国 際 技 術 委 員 会International Technical Director

仕様開発タスク・フォース
ソフトウェア・インプリメンテーション委員会

学術諮問委員会
国 際 幹 事 委 員 会International Business Manager

国 際 組 織図 5 IAI の国際組織

Copyright  1996-1999 International Alliance for Interoperability
Page 6

国際

評議Technical Coordinator会

技術統合委員会

幹 事 会

分 科 会

Business Manager

IAI & IFC イントロダクション– IFC Release 2.0

モデルについてIAI の目的は、IFC オブジェクト・モデルの仕様を定義することです。IAI で使用する IFC のモデ
ルとは、ソフトウェア・アプリケーションで使用するオブジェクト・モデルの定義です。

モデルの定義モデルは、現実のもの（オブジェクト）を情報技術の上で模式的に定義した概念です。実際に解析したり、システムを設計する上で、様々なモデルを定義します。建設業界では、特にプロセス・
モデルとオブジェクト・モデルが重要です。

プロセス・モデル
プロセス・モデルとは、タスク（処理）のモデル化を定義するものです。そして、各タスク間の情報交換で必要な情報を明確にします。プロセス・モデルは、業務の流れを定義する重要な基本ツールです。
プロセス・モデルはさまざまな図形表記で定義されます。IDEF0 形式は FIPS（Federal Information
Processing Standard）183 形式に準拠しています。「IFC 仕様開発ガイド（Guideline for the Specificationof IFCs）」の付録では IDEF0 の説明をしています。

オブジェクト・モデル
オブジェクト・モデルは、データ交換／共有に必要な内容と構造を表現します。各々のプロジェ
クトは、プロセスに必要なデータ構造を持つオブジェクト・モデルを定義します。IAI の仕様開発
タスク・フォース（STF）のメンバは、IFC オブジェクト・モデルの定義を作成します。
IFC オブジェクト・モデルには、さまざまな表現法があります。
• 基本的表現
IFC モデル・リファレンスで示されている表形式のモデル表現です。この基本的表現では、
スプレッドシートを用いて、IFC オブジェクト・モデルに直接変換できる形式です。
• 図形表現
EXPRESS-G という図形表記方法を使用したモデル表現です。これにより、モデルのレビ
ューが容易になります。
• 仕様表現国際標準のデータ記述言語（EXPRESS）を使用し、情報交換／共有に使用されるデータ構
造を定義したモデル表現です。

• インタフェース表現
OMG（Object Management Group）が定義する IDL（Interface Definition Language）を使用するモデル表現です。将来、クライアント／サーバー・システムの情報の交換／共有の実
現に有効な表現となるでしょう。

Copyright  1996-1999 International Alliance for Interoperability
Page 7IAI & IFC イントロダクション– IFC Release 2.0

IFC (Industry Foundation Classes）
IAI は、建物を構成する全てのオブジェクト (例えば ドア， 窓，壁などのような要素)のシステ
ム的な表現方法の仕様を定義します。これらの仕様を IFC（Industry Foundation Classes）と呼びます。アプリケーションで用いるプロジェクト・モデルのデータ構造も合わせて提示します。
定義されるそれぞれの仕様は、「クラス」と呼ばれます。「クラス」は共通の特性をもつものとして扱われます。例えば、「ドア」は、部屋（空間）に出入りする開口、そして「窓」はそこを通して外を見ることができる透明さをもつ開口としてそれぞれの特性が定義されています。この「ドア」，「窓」はともに「クラス」となります。
IFC で定義される「クラス」は、「IFCxxx」と表記されます。
このような「IFCxxx」という表記は以下のような 3 つの理由からです。
• IFCxxx」は建設業界の定義である• 共有のプロジェクト・モデルの基礎である• 構築するための「共通語」を発達させるために合意されたオブジェクト・クラスの定義である
IFC で定義される「送風機」は、単純な図形情報だけではなく、「送風機」として認識できる特性も持ちます。実際の設計業務では、様々なタイプの「送風機」が使用されます。それぞれの「送風機」は、用途によって異なる形状となりますが、「送風機」クラスの特性仕様は同じとなります。
ある「送風機」は吸込み口径が 900mm、またもう一方は吸込み口径が 1200mm というような場合、どちらの送風機も「送風機」として認識することができます。そして、IFC 仕様で定義されている「送風機」の特性を持っています。
「クラス」は、共通の特性を定義したもので、それに対してそれぞれの実体にあたるものを「オブジェクト」と呼びます。
IFC に準拠した「オブジェクト」は、建設業界の各業種で使用されるプロジェクト・モデルの共有を可能にしますが、各業種の情報を十分に満たしているとは言えません。しかしながら設計者が設計した「送風機」は、他の業種の担当者が「送風機」として扱うことができます。こうした継承によって、設備設計、積算、施工そして施設管理を効率化します。
IFC は、建設業界のソフトウェア・アプリケーション間のデータ共有化とその相互運用を可能にします。ここでの IFC 仕様書は、このソフトウェア・アプリケーション開発者向けに、オブジェ
クト指向プログラミングに基づくクラス・ライブラリを定義します。ある 1 つのアプリケーショ
ンで作成される「送風機」オブジェクトは、他の IFC 準拠のアプリケーションと情報を交換することができます。他のアプリケーションは、暗黙的に「送風機」オブジェクトを自動的に認識します。
つまりここでの「送風機」オブジェクトの特徴は、オブジェクト指向で表現すれば、つぎのようになります。
「自分が送風機で、そして遠心送風機であることを認識しています。またダクト系の抵抗に対抗して送るべき風量・吸込み口径と吐出サイズも認識しています。さらにどのように操作され、どのような形状かとういことを認識しています。」
他のアプリケーションは、これらの特徴を理解し、IAI で定義された IFC 仕様を使用して、オブジ
ェクトに情報を付加することも可能です。
さらに、IFC 準拠のアプリケーションにより、電子情報によるデータ(図面，レポートおよび仕様書などのような)を共有することを可能にします。これは、データの一貫性と整合性の保証を意味
Copyright  1996-1999 International Alliance for Interoperability
Page 8IAI & IFC イントロダクション– IFC Release 2.0

します。さらに、この共有データは、設計終了後の施工においても発展し続けます。設計者によって作成された情報は、知的で電子的なフォーマットにより、IFC 準拠のソフトウェアを通して、施工や保守管理に利用されます。
現在、IAI の加盟会社は、多くの業種にまたがって協同で IFC の仕様書をまとめています。IAI は、
ソフトウェアの作成ではなく、ソフトウェア会社と共に建設業界に IFC 標準を促進すること、そして建設業界でコンピュータの新しい可能性をもつソフトウェア・アプリケーションを作り出すことを意味しています。

IFC の実装OWNED BY IMPLEMENTERS

VENDOR "A"
IMPLEMENTATION"A"
Flavor APIs

OPEN FOR IAI MEMBE RS

"A"
IFC
STORE

VENDOR "B"
IMPLEMENTATION"B"
Technology

IFC IMPLEMENTATION

"B"
IFC
STORE

VENDOR "C"
IMPLEMENTATION"C"Technology

IFC DEFINITION

"C"
IFC
STORE

AEC PROCESSESIFC PROJECT MODEL

IFC
MODEL
EXCHANGE

MODEL EXCHANGE(FILE = STATIC)MODEL INTERFACES(RUNTIME = DYNAMIC)

図 6 IFC のベンダー実装

IAI が作成した仕様に基づき、ソフトウェア・ベンダーはそれぞれのアプリケーション開発を行います。IAI は、IFC 建物モデル（ IFC building model）を含む IFC 仕様を作成します。したがってアプリケーション・ソフトウェアはそれぞれのソフトウェア・ベンダーごとに開発されます。
EXPRESS,IDL 定義

アプ リ ケ ーシ ョ ン

ソフトウェア・
インタフェース

物理ファイルClient/Server

SDAI Database
図 7 実装のシナリオ
Copyright  1996-1999 International Alliance for Interoperability
Page 9IAI & IFC イントロダクション– IFC Release 2.0

IFC 仕様のデータ交換／共有方法は 3 つあります。
1． ネットワークによるか、電子メールによるか、またはフロッピーディスクのような物理的メ
ディアによって、共有されるような物理ファイルを生成する方法。ファイルの構造は、IFC
オブジェクト・モデルは EXPRESS 言語により定義され、ファイルの構文は、ISO 10303 の Part21
で定義されています。現在は、ほとんどのソフトウェア・アプリケーションはこのような物
理的ファイルを使用してデータの共有を実現しています。
2． ISO 10303 の Part22 に準拠したインタフェースのデータベースを使用する方法。データベースとのデータ授受には、EXPRESS で定義された IFC オブジェクト・モデルを使用します。
現在は、いくつかのソフトウェア・アプリケーションはこの共有データベースを使用しています。
3． オブジェクトの属性グループ情報を公開したソフトウェア・インタフェースを使用する方法。
ソフトウェア・インタフェースは、中間ファイルやデータベースを使用せずにアプリケーシ
ョン間のダイレクトなデータ共有を可能にします。ソフトウェア・インタフェースの使用は
現在開発途中です。
IAI と建設業界ソフトウェアの組織は、それぞれこのようなモデルの定義をしていますが、ソフト
ウェア・ベンダーが IFC 仕様を実装し、マーケット用にアプリケーションを提供するまでには至っていません。

IFC のリリースサイクル
IAI は IFC オブジェクトモデルの主要リリースを年 1 回のペースで行います。また、中間リリース
は、アプリケーション側での緊急要望への対応と、ベンダー／ユーザのフィードバックにより修正が必要となる場合に発行されます。
IFC のリリースは数字の表記の方法でアップデートのレベルを表現します。
・整数（例 2、3 など）

プロセスの拡張や概説・活動紹介を含めた IFC モデルの仕様書の全般的な更新の主要リリース。更新される仕様書一式は全ての会員に公開されます。

・ドット（例 2.5、3.1 など）

IFC のオブジェクト・コア・モデル拡張の際に発行される主要リリース。ドメイン・プロセスの拡張は含まれません。モデルの正式仕様に関係した仕様書が更新されます。更新された
仕様書は全ての会員に公開されます。

モデルを修正する中間リリース。修正分はソフトウェアのベ・ドット−ドット（例 2.5.1、3.1.2 など） ンダーに発行されます。会員には IAI の FTP サイトを介して公開されます。仕様書は発行されません。

IFC の開発方法
IFC 仕様の開発は、建設業の専門家とソフトウェアの専門家の共同作業で行われ、IFC オブジェク
ト・モデルが定義されています。建設業界の一般的な視点でまとめられたモデルが、ソフトウェ
ア・アプリケーションの詳細なモデルへと展開されます。プロセスとそれに伴う形状の定義は、「IFC 開発ガイドライン」の中で次のように説明されています。
Copyright  1996-1999 International Alliance for Interoperability
Page 10IAI & IFC イントロダクション•– IFC Release 2.0

ユーセージ・シナリオ ：プロセスの説明です。たとえば設備管理では、どのように建物の資産（エアハンドリングユニットなど）を維持管理しているかを説明します。このユーセージ・
シナリオは、プロセスの各ステップ間で必要となる情報と必要な判断の説明です。
Valves x4
Pumps x2

BoilerValves x4

Valves x2
Air Handling Unit

図 8 ユーセージ・シナリオ図•

プロセス・ダイアグラム ：プロセス・ダイアグラムはユーセージ・シナリオを図式化（ダイ
アグラム）したものです。たとえば維持管理の計画プロセスは次のように表現されます。

ClimateDemandConditionRequirement
Requirement

Risk

Identified
Asset
Identify Asset to
be Maintained

Asset
Register

M11
PlannedActionRecordDrawings

RecordDocuments

Calendar

Assigned
Action

M11
Assign Action to
Asset
M13

Identify
MaintenanceActionM12

O&M Instructions

PlannedRequirement

PrepareScheduled Work
Order
M14

Task
Library

MaintenanceFrequency

Schedule
Maintenance
M15

Human Resources

Maintenance
Libraries

Maintenance
Schedule
STEC

Asset
History

図 9 IDEF0 表現によるプロセス・モデル

Copyright  1996-1999 International Alliance for Interoperability
Page 11IAI & IFC イントロダクション•– IFC Release 2.0

クラス ： オブジェクト指向定義で使用されるプログラムの構成要素です。クラスはプロセスの要望に合わせて設計されますので、建設業界のデータ・オブジェクトを簡明に定義したものです。
クラスは遠心送風機のような形状のあるものや、価格や設置方法といった抽象的なものもあります。
Centrifugal Fan

Class = CentrifugalFan–----Attributes
LengthWidth
HeightLocation
Cost
BaseDate
InletRadius
OutletWidth
OutletDepth
SupplyVolume
ResistanceClass = CentrifugalFan–----Attributes
Length = 2.000m
Width = 1.500m
Height = 1.500m
Location = Plant Room 1
Cost = £3642.65
BaseDate = 14-09-98
InletRadius = 600mm
OutletWidth = 1450mm
OutletDepth = 750mm
SupplyVolume = 9cu.m/s
Resistance = 10kPa

Centrifugal Fan

図 10 IDEF0 表現によるプロセス・モデル•

ObjectOther Objects

図 11 クラスの値とオブジェクト

属性 ： クラスまたはインタフェースの情報としてオブジェクトに付加されます。たとえば遠心送風機には、送風量とこれを供給するための抵抗値などがあります。これらの属性は、遠心送風機のクラスに保存されます。

Centrifugal Fan
ObjectObjectArtefact
Class = Process–----Identity = abc123xyz43-------Attributes
StartDate = 20-10-98
EndDate = 24-10-98
Duration = 4 days-------Behaviours
ChangeStart ()ChangeEnd ()Class = CentrifugalFan–----Attributes
Length = 2.000m
Width = 1.500m
Height = 1.500m
Location = Plant Room 1
InletRadius = 600mm
OutletWidth = 1450mm
OutletDepth = 750mm
SupplyVolume = 9cu.m/s
Resistance = 10kPa
Class = Cost–----Identity = abc123xyz44-------Attributes
Amount = 3642.65
Currency = GBP
BaseDate = 14-09-98-------Behaviours
NewAmount ()NewCurrency()

Object

図 12 抽象化された概念によるクラスのブレークダウン

Copyright  1996-1999 International Alliance for Interoperability
Page 12IAI & IFC イントロダクション•– IFC Release 2.0

リレーション・シップ ： クラス間に定義されます。たとえば「送風機」は、「スタータ」とリレーション（関係）があります。「スタータ」は、「送風機」を起動させます。言い換え
れば。「送風機」は「スタータ」によって起動するという関係です。リレーション・シップ（関係）は、実際のオブジェクトの動作を定義する上で大変重要です。

startsstartsstartsStarter
Centrifugal Fans

図 13 オブジェクト間の関係•

インタフェース ：オブジェクトへのアクセスを可能にするものです。IFC のインタフェース
は、建設業界のプロセスをサポートするように設計されていますから、ソフトウェア・ベンダ
ーによる IFC オブジェクトの実装を可能にします。たとえば送風機オブジェクトは、積算、構造、騒音対策など様々な建設業界の業種に対応しなければなりません。

Structural weight
Interface location
StructuralEngineerArchitectural
Interfaceshapelocation

ArchitectServices
Interfacelocation
inlet connection size
outlet connection sizes
distribution characteristics

Services
Engineer

Cost interface
cost
location

Cost
Manager

図 14 オブジェクトの視点

図 15 オブジェクトのインタフェース

Copyright  1996-1999 International Alliance for Interoperability
Page 13

IAI & IFC イントロダクション•– IFC Release 2.0

オブジェクト・モデル ：クラス，インタフェース，属性，リレーション・シップ（関係）で定義されたものです。IAI は作成したオブジェクト・モデルの図化には、モデル記述ができる
EXPRESS-G 等を使用します。

IfcProcessExt.IfcWorkTaskOrGroupSelectIfcProductExt.IfcElement

IfcProcessExt.IfcWorkSchedule

IFCMaintenanceSchedule

IfcKernel.IfcProcess

IfcTimeDuration

Maintains S[1:1?

TaskDuration

Includes L[1:?]SchedulesWorkOrders L[1:?]IFCMaintenanceTask
Tools B[0:?]IfcAsset

Assets S[1:?]Spares B[0:?]STRING

IfcEquipmentUse

WorkOrderID
Plant S[0:?]STRINGSTRINGSTRING

HealthAndSafetyIssues S[0:?]IFCWorkOrder
Consumables S[0:?]ServiceLevel

IfcMaterialUse

Hazards S[0:?]LeadCraft
STRING

IfcTimeDuration

AssetDowntime

1
RequiresPermitToWork

IfcMasterWorkOrder

IfcPermitToWork

Instantiates
Labor

IfcLaborUse

Frequency
Assignor
IfcInstanceWorkOrder

SignOff

IfcPerson

IfcTimeDuration
WorkOrderCompletionNotes S[0:?]IfcAssetHistory

WorkOrderPriority

Records L[1:?]図 16 オブジェクト・モデルの EXPRESS-G 表現

Copyright  1996-1999 International Alliance for Interoperability
Page 14STRINGWorkOrderPriority

IAI & IFC イントロダクション•

テストケース：具体的な建物を使って定義されたデータとなります。このテストケースにより、ソフトウェア・ベンダーが開発した IFC
準拠のアプリケーションの性能をテストすることができます。テストケースは、オブジェ
クト，インタフェース，属性，関連を含むデータを提供します。右図は、サンプル・テス
ト・データの内容です。

要素/属性
表示
部屋１
面積
部屋番号
壁１
材質
方向
壁面積
窓１
材質
開口面積
ブラインド

– IFC Release 2.0

入力値

単位

26.6261
室１

平方メータ
文字

レンガ
180
12.36

文字
度
平方メータ

厚さ3mm
透明ガラス
7.2
なし

文字
平方メータ
文字

図 17 サンプル・テスト・データ

IFC リリースの配布物
以下の IFC のドキュメントは、建設業界とソフトウェア業界の専門家を対象にしています。

IAI/IFC イントロダクション（レベル：紹介

対象：一般）

このドキュメントは、IAI と IFC を紹介したものです。建設業界の専門家を対象とする IFC 共有
プロジェクト・モデルのコンセプトを説明しています。IFC 準拠のアプリケーションがエンドユーザにとって如何に有益であるかを説明し、さらに IFC、IAI の概要と IFC の開発プロセスを要約したものです。

IFC モデル・ガイド（レベル：技術

対象：一般）IFC モデル・ガイドは、IFC オブジェクト・モデルの定義について説明しています。
主な内容としては、• IFC オブジェクト・モデルが、どのように組立てられているかを説明しています。
• IFC オブジェクト・モデルの開発規約について説明しています。
• IFC オブジェクト・モデルの凡例を説明しています。
このガイドは、IFC の開発に興味をもつオブジェクト・モデルの専門家と IFC オブジェクト・モ
デルの定義方法を理解する必要があるソフトウェア開発者のための説明書です。

IFC 仕様書のガイドライン（レベル：建設業界の専門家

対象：一般）IFC の仕様書の開発ガイドラインは、IFC の仕様の開発方法について詳しく説明しています。プロ
ジェクトの要求定義の方法や、プロセス，クラス，全 IFC オブジェクト・モデルと整合性をとったドメイン・オブジェクト・モデルの開発について説明しています。
Copyright  1996-1999 International Alliance for Interoperability
Page 15

IAI & IFC イントロダクション– IFC Release 2.0

IFC によるの建設プロセスサポート（レベル：建設業界の専門家

対象：一般）

このドキュメントは、IFC オブジェクト・モデルがサポートする建設業界のドメイン・プロセスを説明しています。このドキュメントでは、現在 IFC でサポートする建設業界の範囲を説明しています。

IFC モデル・リファレンス（レベル：技術者

対象：IAI 会員のみ）

IFC モデル・リファレンスは、「クラス」と IFC のオブジェクト・モデルで定義されている「データのタイプ」を詳細に説明したものです。さらに建設プロセスの要求定義、詳細なオブジェクト・
クラス・データ、リレーション（関係）、標準インタフェース、データタイプの定義、そして形状を定義する幾何スキーマの情報の構築についても説明しています。また、EXPRESS で定義されているデータ・モデルのビューと IDL で定義されている標準インタフェースについても説明しています。

IFC ソフトウェア実装ガイド（レベル：技術者

対象：IAI 会員のみ）

ソフトウェア実装ガイドは、IFC 準拠のアプリケーションを実証する方法論を詳細に説明しています。この中では、評価の概要、IFC モデルのサブセット・データ変換の定義、認証テストで使用されるテスト一式などを説明しています。

IFC 実装認証ガイド（レベル：技術者

対象：IAI 会員のみ）

IFC 実装認証ガイドでは、IFC 準拠のソフトウェア・アプリケーションが証明するプロセスとどのようにデモンストレーションをするかを説明しています。ツールキットの使用方法と入手方法についても説明しています。

IFC リリースとリリース予定
リリース 1.0
IFC リリース 1.0 は、建物のライフサイクルを通して使用される共有プロジェクト・モデルを定義することを目的としています。初期のリリースとして、意匠設計，空調設備，工事管理，およびFM(ファシリティ・マネージメント:施設管理）をサポートしていますが、共有プロジェクト・モ
デルの一部の定義しかされていません。
IFC 仕様書のリリースは、達成可能な範囲に限定しています：• ｢コア｣モデルとプラグイン拡張機能のサポートします。
この機能では IFC モデルの拡張を保証しています。
• 4 つの業種（設計，空調設備，工事管理，FM）のみを記述します。
4 つの業種で使用されるプロセスの一部がサポートされます。

リリース 1.5
IFC 仕様書のリリース 1.5 は、リリース 1.0 で開発された業種の適応範囲の拡張はありません。
ただし、リリース 1.0 の実証実験の建物や IFC モデルのアーキテクチャ（構成）は改良されました。また、IFC のオブジェクト・モデルの「コア」は範囲が拡張され、ソフトウェア開発のプラ
Copyright  1996-1999 International Alliance for Interoperability
Page 16

IAI & IFC イントロダクション– IFC Release 2.0

ットフォームとして提供できるようになりました。

リリース 1.5.1
リリース 1.5 モデルの実装の問題を解消するためにリリースされました。主に、「コア」とモデルの構成要素の改良となっています。

リリース 2.0
IFC 仕様書のリリース 2.0 は、IFC のオブジェクト・モデルの適応範囲が拡張され、下図に示される各業種分野が含まれます。
その他

意匠

プロジェクト文書管理

意匠モデルの拡張

拡張機能（表、ネットワーク他）（コア、外観、屋根、トイレ）

IFC 2.0

設備
空調システム設計

避難経路の為の空間設計

積算（ダクト・配管）

原価計算

経路調整、熱負荷計算

法規と標準

ＦＭ

法規遵守チェック（エネルギー、

占有計画（人員、空間配置）

身障者アクセス、避難経路）

シュミレーション

財産保守（建物オーナーの視点）

フォトリアリスティックなビジュアル化図 18 IFC R2.0 適応範囲

リリース 3.0
現時点では、リリース 3.0 作業として下図の業種分野が提案されています。リリース 3.0 では、IFC
オブジェクトモデルの適応範囲の拡張を計っています。
クロスドメイン意匠

外部ライブラリ参照

外構設計

法的問題、材料性能属性

設計意図

設備

IFC 3.0

動力・証明
空調システム、設計拡張

積算
コスト計算

ＦＭ

衛生設備、性能計測

予防保全

法規と標準

（資産台帳、作業リスト、履歴）

法規照合

施主

土木／構造

プロセスモデル参照

鉄骨構造、鉄筋コンクリート

施工

建物基礎、荷重定義

仮設計画（足場、揚重機）

図 19 IFC R3.0 適応範囲
Copyright  1996-1999 International Alliance for Interoperability
Page 17

IAI & IFC イントロダクション– IFC Release 2.0

IAI に関するその他の情報
Web サイトIAI の活動全般の情報を入手することができます。

IAI のアドレス：

http://www.interoperability.com

支部の Web サイト
各支部は、それぞれの Web サイトを管理しています。アクセス方法は、上記の Web サイトからそれぞれの支部のサイトにアクセスできます。日本支部もホームページを開設し、支部の活動状況などを紹介しています。

日本支部のアドレス： http://www.interoperability.gr.jp

FTP サイトIAI の会員用のサイトです。IFC の最新情報や各支部の分科会活動を載せています。
FTP サイトのアクセスにはパスワードが必要です。パスワードは、事務局と技術統合委員会のメンバが管理しています。パスワードは 6 ヶ月ごとに更新されます。

E-mail リスト
IAI は、通常 E-mail での意見交換をします。各支部はメイリングリストを作成して活動を広めて
います。

公式言語
IAI は、英語を公式言語としています。アメリカ英語の表記方法を採用します。

IAI と STEP について
IAI は、他の組織とも強調して活動しています。現在 ISO TC184/SC4（STEP と称します）と覚え書きを交わし、1997 年にフローレンスおよびシンガポールにて IAI と STEP との合同ミーティン
グが開催されました。次ページにその覚え書き（Memorandum of Understanding between ISO
TC184/C4 and IAI）を添付します。

Copyright  1996-1999 International Alliance for Interoperability
Page 18

IAI & IFC イントロダクション– IFC Release 2.0

Memorandum of Understanding between ISO TC184/SC4 and IAI
This Memorandum of Understanding establishes collaborative working practices between the International
Standards Organization Technical Committee 184 Sub Committee 4 (SC4) and the International Alliance forInteroperability (the IAI).
Both SC4 and the IAI support developing neutral definitions of information that can be electronically shared. Theinterests of SC4 concern all industry sectors including building construction whilst the interests of the IAI are
focussed on building construction.

The objectives of this Memorandum of Understanding are:••to strengthen development efforts for building construction within SC4 through technical input and participation
by IAI member companies;
to strengthen the development of Industry Foundation Classes (IFCs) within the IAI through technical input anduse of technologies and appropriate standards (completed and developing) within the scope of SC4.

In support of these objectives:
SC4 will:
•
•
•
•
•

invite the nominated liaison officer between the IAI and SC4 to participate in SC4 meetings to report on relevant
IAI activities;
hold joint sessions with members of the IAI during its international meetings;
invite representatives of the IAI to participate in SC4 Working Group meetings;
share information about developing standards, technical reports, standing documents and other material as
appropriate to the interests of the IAI;
respect the copyright of IAI and confidentiality of selected IAI materials as requested.

IAI will:
•
•
•
•
•
•
•

invite the nominated liaison officer between SC4 and the IAI to participate in international meetings of theInternational Technical Management Committee to report on relevant SC4 activities;
collaborate with related industry groups within SC4;
identify requirements for information sharing within building construction to SC4;
share information about developing IFC specifications, guides and other material as appropriate to the interestsof SC4;
provide information on developing and testing of IFCs to the benefit of SC4;
provide technical input to developing standards within SC4;
respect the copyright of ISO and confidentiality of selected ISO material as requested.

Both SC4 and the IAI see the potential for a natural progression of industry validated specifications towards formal
standards. The IAI recognizes that SC4 is the appropriate ISO committee for which the work of the IAI is most
relevant as input to developing formal industry standards.
Both SC4 and IAI will encourage their participants to present the work being undertaken by its counterpart in apositive manner and will encourage further participation by industry within each other's activities.

Mutually agreed Collaboration Guidelines that set out the procedures for achieving the objectives
stated above form part of this Memorandum of Understanding

Copyright  1996-1999 International Alliance for Interoperability
Page 19

IAI 日本支部事務局
お問い合わせ、ご入会のお申し込みなど、詳しくは IAI 事務局まで

E-mail：iaijapan@interoperability.gr.jp
TEL：03-5676-8471
また、IAI 日本支部ホームページには、日本支部参加企業一覧、年間スケジュール、IFC ドキュ
メントなど掲載しております。

http://www.interoperability.gr.jp