BCS工程計画データ交換ガイドライン

■第一版(2009/11/5)
BCS工程計画データ交換ガイドライン
2009 年 11 月
社団法人
建築業協会
IT推進部会
目次
1.
2.
3.
4.
はじめに ...................................................................................................................................... 2
1.1.
ガイドラインの概要 .............................................................................................................. 2
1.2.
工程データ交換への取り組みの背景..................................................................................... 3
1.3.
工程データ交換の必要性....................................................................................................... 3
1.4.
工程計画ソフトの各社動向 ................................................................................................... 5
データ交換の為の手法について ................................................................................................ 23
2.1.
本ガイドブックでデータ交換対象とする範囲 .................................................................... 23
2.2.
工程データのモデル化に用いる手法................................................................................... 25
IFC による工程データの表現 .................................................................................................... 30
3.1.
IFC 仕様における工程情報の構造 ...................................................................................... 30
3.2.
利用する仕様について ........................................................................................................ 34
3.3.
工程表要素を ifcXML で表現する上での運用ガイド .......................................................... 34
おわりに .................................................................................................................................... 46
4.1.
今後の方向性....................................................................................................................... 46
4.2.
将来の可能性....................................................................................................................... 47
4.3.
実現に向けて....................................................................................................................... 48
1
1.
はじめに
1.1.
ガイドラインの概要
工程表は、様々なノウハウやスキルが詰め込まれ、また契約書代わりの合意文書として使用されるこ
ともあるが、現状では、図表として作成、参照されており、流用性に欠け、再利用が難しい。工程表を
図表としてではなく、データとして保存、活用し、日程のみならず、過去のノウハウ、スキルまでをも
転用することで、業務を効率化することが求められている。
また、工程表作成ツールは、多くのメーカーから様々なアプリケーションが販売されているが、それぞ
れ、独自の機能をもち、そのデータは独自の仕様に従い構成されているため、データの互換性は、ほぼ
ない。各社、各現場では、多種多様の工程表作成ツールが用いられており、現状では上記の目的を達成
することはできない。現場、会社を超えて、工程データを共有し、情報を有効利用するためには、工程
表作成ツールのデータに互換性をもたせることが必要である。
本書では、工程計画データを交換するためのガイドラインとして、「データ交換のための手法」、「IFC に
よる工程データの表現」
、「今後の方向性と最終目標」について記述する。
「データ交換のための手法」(第 2 章)では、「データ交換の対象とする範囲」と「工程データのモデル
化に用いる手法」について記述する。
「データ交換の対象とする範囲」は、工程表を構成する要素に分類し、各要素の中から実際の工程表で
使用されている要素を抽出し、そこから交換対象となるデータの絞り込みを行うこととし、その詳細に
ついて記述する。
「工程データのモデル化に用いる手法」としては、工程 WG の活動で実証実験を行った XML フォーマ
ット、国際標準である建設業向け XML フォーマット(IFC)について説明し、これらを採用する理由お
よび課題と対策について記述する。
「IFC による工程データの表現」(第 3 章)では、「IFC 仕様における工程情報の構造」について解説し、
本ガイドラインで利用する仕様について説明する。また、実際に工程表要素を IFCXML で表現するための
運用およびタグの要素について説明する。
「おわりに」
(第 4 章)では、工程データ交換の今後の方向性と最終目標について述べる。
工程データ交換が可能になることで、建築生産に関係する全ての会社に業務の省力化と効率化、確実な
工程計画と情報伝達、新たな協調的発想等のメリットが生まれ、これによって工程データ交換の活用範
囲の拡大が可能となる。さらに、建設業における、業務改善、顧客満足度の向上、業務環境の向上など
の目標について記述する。
2
1.2.
工程データ交換への取り組みの背景
建築工事に用いられる工程表の種類は、ネットワーク工程表とバーチャート工程表とがある。使用す
る工程表の種類は、それぞれの目的により使い分けているのが現状である。
また、同じネットワーク工程表でも使用目的により全体工程表、月間工程表、週間工程表に使い分けて
作成されている。工程管理を目的として作成する場合には、各作業を定量的なアプローチから作業時間
を求め、それを積み上げるが、関係者への情報伝達の観点から作成する場合は、各マイルストーンを視
覚的に見やすいように図化する形式が取られている。この場合、描画が可能な Excel や CAD で間接的に
作図される場合が多かった。
しかし、建築生産の効率化、標準化を考えた場合、工程管理を目的とした工程表の作成が必要とされ
てきており、かつ、各マイルストーンがわかりやすい表現ができる工程表作成ツールが普及してきてい
る。
工程表作成ツールを用いて作成された工程データは、各ソフトウェアアプリケーション毎にしか活用
することができず、いかなるソフトウェアアプリケーションでも利用可能な工程データの共通フォーマ
ット形式が要望されている。
1.3.
工程データ交換の必要性
原価管理
(Cost)
建築工事における生産活動においては、品質、
原価、安全、工程の 4 項目についての管理を如
何にスムーズに行うかにかかっている。なかで
工程管理
(Delivery)
も工程管理は、その他の事項と綿密に係ってい
るため全体工程表・月間工程表・週間工程表を
作成し緻密な工程管理を行うことで、品質、原
安全管理
(Safety)
品質管理
(Quality)
価、安全についても的確に管理できることとな
る。
工程管理のツールとして、工程表がある。現
在、作業所で作成している工程表のほとんどが、コンピュータにより作成されている。使用しているソ
フトウェアアプリケーションは様々で、キャドソフトウェアアプリケーション、表計算ソフトウェアア
プリケーション、工程表作成ツール等がある。
工程表作成の目的は、工事全体の流れを関係
者に周知することであり、紙を媒体とした情
報伝達では、現行の方式でも良いが、元工程
作業所作成工程表
施主
元請会社
・月間工程表
に関係者それぞれの情報を付加したり、デー
・週間工程表
タ交換により元工程を修正したりする場合
等は、元工程表のデータを利用できないのが、
・全体工程表
作業所内交換
設計
現状である。これを解決ために、各ソフト間
・時系列交換
・各工区間交換
・JV 企業間交換
でデータ交換をできる標準 XML スキーマの
プロトタイプを提示し、各ベンダーが実装す
る手法を提案する。
3
下請会社
各ソフトウェアアプリケーション間でデータ交換が可能になることにより、元工程に情報を付加しな
ければならないような業務や、関連部署とデータ交換により工程表を作成しなければならない業務等の
効率化が図れる。また、工程データが互換性を持つことで図表作成に特化したソフトから、効率化の効
果が大きい PM ソフトまで、それぞれの作業所のニーズやリテラシレベルに応じて最適なソフトウェア
アプリケーションを購入・利用しやすくなる。
BCS 標準フォーマットに対応することにより、以下のメリットがある。
・ 工程表作成ツールの自由な導入がしやすくなり、マーケットの活性化につながる。
・ 各会社において工程表作成ツールを切り替えても過去のデータが使えるようになる。
・ ユーザーレベルに合わせた最適な工程表作成ツールを導入することができる。
・ 工程表作成ツールに多くの機能を持たせる必要がなく、各ユーザーのニーズに合わせた工程表作成ツ
ールを開発できるため各ベンダーは得意な分野を充実させることができる。
4
1.4.
工程計画ソフトの各社動向
建築工事の工程表を表現するために、各社から様々な製品が発表されている。それらの持つ機能を分類
して解説する。
※
すべての製品がすべての機能を実現できるということではない。
(1) 図表表現機能
①工程表のタイプ
工程表には、大きく分けて、ネットワーク工程とガントチャートの 2 タイプがある。
それぞれの工程表例を挙げる。
● ネットワーク工程の工程表例(CDPM2007)
● ガントチャートの工程表例(CDPM2007)
5
● ネットワーク工程とガントチャートを重ねた工程表例(CDPM2007)
● ネットワーク工程とガントチャート混在の工程表例(CDPM2007)
6
● ネットワーク工程とガントチャート混在の工程表例(現場ナビ工程)
●工程表例(工程
s)
7
②工程の表現(色、形状)
製品毎に、工程の表現として、様々な色、形状が用意されている。
色、形状に独自の意味をもたせることで、よりわかりやすい工程表となる。
色、形状の例を挙げる。
● 工程シンボルの色と形状例(工程
s)
(実際の描画例)
8
● 工程シンボルの色と形状例(CDPM2007)
9
③図面の挿入、貼り込み
表計算ソフトの操作感覚で、図面、オブジェクト(直線、円弧、四角、丸、楕円、テキストボック
ス等)を挿入し、工程表に必要な情報を織り込むことができる。
● 図面挿入例(CMS 建設工程システム)
挿入メニューで、簡単に図形を挿入できる。
10
● 図面挿入例(CDPM2007)
● オブジェクト挿入例(現場ナビ工程)
11
● 表オブジェクト挿入例(現場ナビ工程)
● サイクル工程表オブジェクト挿入例(現場ナビ工程)
工程表の中に工程表を取り込める。
12
(2) 印刷レイアウト機能
利用各社ごとの文化、慣習に合わせたフォーマットで出力することができる。
また、工程のデータを変更することなく、印刷書式のみを切り替えて表示・印刷が可能である。
● 印刷レイアウト例(現場ナビ工程)
13
● 印刷レイアウト例(工程
s)
14
● 印刷レイアウト例(CDPM2007)
15
(3) 日程計算機能
工程間の関連付けを設定することで、いつでも日程を再計算することができ、計画の変更などに簡単
に対応することができる。後づめの計算もでき、調達などの計画をたてることができる。
また、クリティカルパス(工程の遅れが工事全体の終了日に影響を与える経路)を赤色などで目立た
せる表示をすることができ、重点的に管理する工程が一目でわかるようになる。
● 日程計算例(工程
s)
● 日程計算例「述べ日」(現場ナビ工程)
16
● クリティカルパス表示例(工程
s)
● クリティカルパス表示例(CDPM2007)
17
(4) 数量・コスト計算機能、グラフ化
工程に割り当てた必要資源量(工数、機械数など)を工程ごと、階層ごと(集計)に表示することが
できる。
● 必要資源数表示例(工程
s)
また、簡易入力または工種毎の達成率や査定金額に基づき出来高を入力し、出来高曲線として描画す
ることができる。
● 出来高曲線描画例(CMS 建設工程システム)
18
●
出来高曲線描画例(CDPM2007)
● 出来高グラフ(上限、下限、予定、実績)描画例(現場ナビ工程)
19
(5) 他システム連携
工程表を、CAD データや Windows のファイル形式(DXF、DWG、EMF、BMP、GIF、TIF、JPG、
PNG など)に出力し、他のアプリケーションで読み込むことができる。
また、工程データを XML ファイル、CSV ファイルなどで入出力することで、外部システムとデー
タ連携を行うことができ、基幹システム、その他のシステムの工程表フロントエンドとして使用する
ことができる。
● 外部システム連携例(Prosion)
Microsoft Visio
Microsoft Visio と
Microsoft Projectを連携
Microsoft Project
● 外部システム連携例(CDPM2007)
CDPM の XML データからマイルストンを抽出し、書類の達人へ渡す。
(三井住友建設様でご利用)
20
● 外部システム連携例(工程
s)
工程表を Excel 出力
作業バー、名称を 1 つ 1 つオブジェクトに変換
21
● XML ファイル出力例(CMS 建設工程システム)
22
2.
データ交換の為の手法について
2.1.
本ガイドブックでデータ交換対象とする範囲
データ交換対象とする範囲を選定するにあたり、工程表を構成する要素を挙げてみる。
工程表は主に図 1 に示すように、大きく「書類的な要素」
、「工程に関わる要素」、
「工種・行(縦軸)に
関わる要素」
、「時系列(横軸)に関わる要素」にて構成されている。
時系列(横軸)に関わる要素
書類的な要素
図 1‑工程表の情報概要
工種・行(縦軸)に関わる要素
工程に関わる要素
次に、分類した各要素にはどのような要素が含まれるか実際に現場で使用されている工程表をサンプ
ルとして利用し、実際に記載されている要素を挙げてみる。
表 1 では、工程表に記載されている要素に「○」印を付けどの要素が多く記載されているかを調べて
みた。
表1-工程表を構成する要素
書類的な要素
工事名称 作成日 工程表タイトル
工程表1
工程表2
工程表3
工程表4
工程表5
工程表6
工程表7
工程表8
工程表9
工程表10
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
工程に関わる要素
開始日 終了日
タスク名
マイルストン
印鑑欄 備考欄 キープラン
開始日時 終了日時
(着工日) (竣工日)
(作業名)
(行事予定)
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
23
工種・行(縦軸)
に関わる要素
時系列(横軸)
に関わる要素
工種名
(項目名)
○
○
○
○
○
○
○
○
○
○
カレンダー
休日カレンダー
(日付要素)
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
工程 XML ワーキンググループでは、データ交換の対象とする範囲についてまずは、全てのソフトウ
ェアアプリケーションで共通する部分のみを包含する最大公約数的なものでアプローチしたいと考える。
工程表の書式に類する部分については、一度作成すれば使いまわすことができるので書式については
優先度を下げる。
データ交換による再利用の効果が高いものは、情報量が多く、更新も頻繁な工程であると思われるた
め、月間工程自体を主なターゲットとする。
2.1.1
工程を構成する対象
データ交換対象とする範囲について絞り込みを行う。
工程表を構成するうえで、どの要素が必要か。表 1 の結果から、挙げられた要素の中で「○」印が多
くついた要素については、工程表を構成するうえで必要であると考えられる。
必要な要素を工程表を構成するうえで「コア」となる要素として定義し、今回のデータ交換の対象範囲
とする。
コア部分として定義した要素を、IFC の用語に合わせ表 2 に示す。
表 2−工程表を構成するコア要素
分類要素
項目
書類的な要素
プロジェクト要素・工程計画要素・工程表要素
工程に関わる要素
タスク要素
工種・行(縦軸)に関わる要素
行要素・レイヤ要素
時系列(横軸)に関わる要素
スケジュール要素・日付と時刻要素・日付要素・時刻要素
休日カレンダー要素・休日スケジュール要素
表現に関わる要素
2.1.2
タスク表現要素
色、形について
工程の色や形については、工程表作成ソフトにより様々な表現が可能となっている。
他社間で異なる形状がある場合は、”四角”、”丸”、”赤”、”青”等の抽象的な表現を既定し各社が近似さ
せる。
将来的には詳細化も考えられるが、第一段階として簡略化しモデル化したい。
色・形状については、最小限に留める。
2.1.3
書類的要素について
工事概要や図面などの書類的な要素については、本ワーキンググループと同様、建築業協会の IT 推進
部会における建築情報標準化専門部会に設けられた文書ワーキンググループの成果に従う。
2.1.4
その他工程表を構成する要素について
今回コア部分として定義したデータ交換の対象範囲以外の工程表を構成する要素については、今後検
討をしていく。
24
2.2.
工程データのモデル化に用いる手法
2.2.1. IFC と XML を利用する
昨年度までの活動にて、データ交換として多方面にて活用され、多くの利点を持つ XML フォーマット
を採用し、ソフト間での実証実験を行ってきた。XML 規格を調査した結果、ソフトベンダー独自の出力
機能としての XML フォーマット、製造業向け XML フォーマット(PSLX)、そして国際標準である建設
業向け XML フォーマット(IFC)などがあることがわかった。既往の規格で活用できるものは極力利用
する方針とし、工程データばかりでなく建物全体も定義している IFC を採用することとした。
2.2.2. BIM とは
BIM とは、Building Information Model および Building Information Modeling の略で、建築物を形
状だけでなく、建物ライフサイクルの全体で生成および保持される性能・コスト・スケジュールといっ
た様々な属性を含んだオブジェクトの集合体として表現する概念のことをいう。
この言葉の由来については 2 つの説があり、1 つ目は、「3D オブジェクト指向建築 CAD」を表すため
に Autodesk 社によって発案されたとするもの。2 つ目は、米国ジョージア工科大学の Charles M.
Eastman 教授が発案したとするもの。この説は、「ビルディングインフォメーションモデル」が「ビルディ
ングプロダクトモデル」と基本的に同義であるという見方に基づいており、1970 年代後半から Eastman
教授が書籍や報告で頻繁に使用している(「プロダクトモデル」とは、エンジニアリングにおける「データモ
デル」あるいは「インフォメーションモデル」を指す)。いずれにせよ、この言葉は、Jerry Laiserin によっ
て、デジタル形式による情報の変換および相互運用を支援するための建設工程のデジタル表現を指す一
般的な名前として認知されている。
企画・計画
検証・モデルチェック
プレゼンテーション
敷地計画・ゾーニング
空間計画チェック
GIS(地理情報システム)連携
日影・逆日影・天空率
事業計画シミュレーション
3Dメタバース
部材干渉
3Dレビュー
構造BIMモデリング
設備BIMモデリング
鉄骨モデリング
構造解析
環境シミュレーション
エネルギーシミュレーション
照明シミュレーション
LCC
SL
構造
意匠BIMモデリング
設備
PAL
アニメ
意匠
自動モデルチェッカー
CFD
フォトリアリスティック
バーチャル・リアリティ
一貫構造解析
応力解析
部材断面計算
FEM
CEC
LCA
施工
積算
自動数量拾い
コスト見積もり
在庫管理・調達システム
維持管理
維持管理
不動産
FM
AM
デューデリジェンス
4Dシミュレーション
部材生産・加工
仮設計画・施工
図1:建築全体の BIM 活用イメージ
現在では、これまで分業があたり前であった建設業において、設計、施工、維持管理のコストや工期、
25
品質情報までも全てが統合されたデータを活用して業務を進めることを BIM という。多くの場合が 3 次
元モデルを使って表現している。図1に建築全体の BIM 活用イメージを図2に工程計画での BIM 活用
イメージを示す。
リンク
BIMデータ
スケジュール情報
時間軸
図2:工程計画での BIM 活用イメージ
BIM には、形状、空間の関係、地理情報、数量、建物要素の属性(例えばメーカー情報など)を含んでおり、
BIM においては、計画,設計,施工,さらに竣工後の維持管理等,建物ライフサイクル全般において3
次元建物情報モデルデータが活用され,設計者のみならず,発注者,コンサルタント,維持管理者,不
動産会社など様々なステークホルダーが3次元建物モデルと関わりあっている。そして作成されたモデ
ルデータをソフトウェアアプリケーション間で共有する必要がある。その際の標準データモデル,デー
タ交換フォーマットとして3次元建物情報オブジェクトデータモデルである IFC を活用する動きがでて
きており、実際、海外では以下のような BIM/IFC 要求による事例が増えてきている。
・ アメリカ:GSA(連邦調達庁)
¾
2007 年度予算のプロジェクトから BIM/IFC 提出
¾
USCG(沿岸警備隊)・USACE(陸軍工兵隊)・NASA 等が同様な動き
・ デンマーク:公共工事分野
¾
2007 年 1 月から BIM の採用・IFC を要求
・ フィンランド:大手不動産管理 Senate Properties 社
¾
2007 年 10 月から BIM の採用・IFC を要求
・ ノルウェー(建設局)
¾
建築確認分野(ゾーニング計画審査)に IFC と GIS 活用を展開中
¾
ノルウェー版 e-PlanCheck 計画
・ シンガポール(建設局)
26
¾
2002 年に建築確認の完全電子化
¾
IFC による自動建築確認 Web ポータル(e-PlanCheck)展開を準備中
2.2.3. IFC とは
IFC(Industrial Foundation Classes)とは非営利な国際組織 IAI(International Alliance for
Interoperability)が策定・普及活動を行ってきた3次元建物情報オブジェクトデータモデルの標準仕様
のことをいう。
IAI は、1994 年米国で設立した民間の団体であるが、現在では全世界に 13 の支部と約 500 の企業・
団体が加盟している大きな組織である。その目的は IFC を普及させることであり、現在は国際標準化機
構 で あ る ISO(International Organization for Standardization) の PAS ( Publicly Available
Specification:公に利用可能な仕様)になっているが、
この標準の IS 化(ISO16739)を数年の内に計画してい
る。そして、IAI よりも理解しやすい活動イメージとす
るために、building + smart =buildingSMART という
新しいブランド名として移行し、最近では、他支部にな
らい日本支部でも BIM 体験の場としてのインターネッ
トで競うバーチャル設計プロジェクト「Build Live
Tokyo」の開催を主催するなど活発に活動している。
IFC が定義している建物情報モデルの概要について
述べると、ソフトウェアアプリケーションが建物情報モ
デルデータに対して何らかの処理を行う際には,建物の
図3:部屋内 IFC モデル
様々な部位の幾何形状,部材の種類,材質,寸法等の属性をコンピ
ュータが理解する形でデータ化することが必須となる。たとえば,建物のある空間の用途に関しての法
規チェックを行う場合,該当する部屋という単位の情報が必要でである。IFC ではこれを壁,スラブ等
で区切られた空間として定義し,IfcSpace というオブジェクトによって,
「部屋」という概念を表現して
いる。部屋オブジェクト(IfcSpace)には,部屋空間の3次元形状,名称,種別,面積,体積,空調に関
する情報等を関連付けることができる。部屋を囲んでいる壁は IfcWall オブジェクトとして表現され,3
次元および2次元形状,種別,面積,体積,材質層等の属性が関連付けられている。また IFC の定義で
は,これらの壁は空間境界(IfcRelSpaceBoundary)により IfcSpace とどの面で接しているかの情報や,
他の建物要素との接続情報,壁にある開口部分との包含関係の情報も保持している。窓,ドア等のオブ
ジェクトは,その親にあたる壁との関係,部屋との関係性を持つので,部屋と部屋がどのドアで接続さ
れているか,という情報を取得することができる。このような建物の様々な部位の属性や,空間的な配
置,部材同士の接続関係が IFC で表現されることにより,構造計算,避難経路計算,空調熱負荷計算,
積算等を行うことが可能となっている。
27
図4:建物 IFC モデル
また、IFC では敷地(IfcSite)、建物(IfcBuilding)、階(IfcBuildingStorey)、部屋(IfcSpace)等の空間構
造要素が IfcSpatialStructureElement のサブクラスとして定義されている。IfcSite には敷地の緯度経度
情報が設定でき、IfcBuilding は親座標系として IfcSite の局所座標を参照している。同様に階を表現す
る IfcBuildingStorey は IfcBuilding の局所座標系を親座標系として参照し、各階に含まれる建物要素は
親座標系として IfcBuildingStorey の局所座標系を参照することにより、幾何形状の座標は相対座標とし
て設定されている。
そして IFC では、建物形状を定義するだけでなく、その建物要素と時間軸を関連させる工程情報も定
義されている。建物要素と工程情報の IFC クラス関連図の1例を下図(図3)に示す。
図5:建物要素と工程情報の IFC クラス関連図
参考までに、IFC で定義されている主要な情報と関連 IFC クラスの一覧を以下に示す。
• 建築プロジェクト情報:IfcProject
• 建物要素(壁、ドア、窓、屋根、階段等):IfcBuildingElement サブクラス
• 建物要素間の接続・包含関係(開口、ゾーン等):IfcRelationship, IfcGroup サブクラス
• 空間構造(敷地、建物、階、部屋等):IfcSpatialStructureElement サブクラス
• 設備機器(空調機、ポンプ、建物制御システム、センサー等):IfcDistributionElement サブクラス
28
• 通り芯:IfcGrid, IfcGridAxis, IfcGridPlacement 等
• 幾何形状 (2D, 3D):IfcRepresentationItem
• コスト情報(単価、積算):IfcControl サブクラス
• 工程(4D: 3D + 時間):IfcControl サブクラス
• アクター情報(プロジェクトメンバー、組織、連絡先住所):IfcActor, IfcOrganization 等
• 指示書(設計変更、購入指示等):IfcProcess
• 資産台帳・在庫:IfcInventory
• 保守履歴・配置管理(FM):IfcProjectOrderRecord, IfcMove,
• 分類・外部ライブラリへの参照:IfcClassification
そして IFC データは、これらの情報を STEP/P21 形式のフォーマットで表現している。こここで
STEP/P21 形式とは、STEP の規格の一つであり、
「Part21 交換構造のクリアテキスト符号化 (Clear text
encoding of the exchange structure) 」に準拠している。
2.2.4. XML とは
XML とは、インターネット上などで異なったアプリケーション間でのデータ交換等を容易に行うため
の技術として W3C(World Wide Web Consortium)により 1998 年に開発されたものである。XML に先立
ち同様な技術として SGML(Standard Generalized Markup Language)や、HTML(Hyper Text Markup
Language)があった。SGML は、異なるアプリケーション間の電子的なデータ交換のための文書の論理
や意味構造などの汎用的なフォーマットを作成するための技術として 1986 年に ISO によって開発され
た。また、SGML の簡易版として、インターネット等で広く使用されている HTML が 1990 年代に W3C
により策定された。SGML は、その仕様が膨大で複雑であるためインターネット上では HTML が使われ
てきた。しかし、HTML は文書構造が固定されているため、複雑な構造のアプリケーションを開発する
場合や、異なる組織間での電子商取引などの情報交換・共有を行うためには文書構造を目的に応じ決め
られる機能が必要とされ、XML が開発された。
XML は、SGML と同様に作成者が文書構造を定義する機能があるが、専門的な知識がなくても利用で
きるように考えられている。このため、XML では汎用的な部分に関しては事前に定義が行われ、利用者
は目的に応じ定義を追加するだけで作成が可能なものとなっている。また、ネームスペースという機能
を利用しインターネット等で公開されている、第三者が作成した XML 文書を組み合わせて自らの文書と
して利用することも可能となっている。
2.2.5. ifcXML とは
XML はその IFC に対して、以下に示すような利点を与えている。
・IFC モデルを XML のスキーマに定義し直すことで、Web 上での利用が可能となる。
(図-IFC と XML
利用例を参照)
このことは、IFC モデルの e コマースでの利用等、EDI での利用に有効な手段といえ、今後ますます
推進されることになると思われる。
IAI では建物を概念モデル化し、IFC というクラスライブラリで定義してる。その表現手段として利用
されているのが、STEP の EXPRESS 形式であり、今まで概念モデルを表現する唯一の手段であった。
それに加えて現在では概念モデルを表現する 2 番目の方法として XML の利用が考えられている。それが、
29
"ifcXML"である。
図6:ifcXML 概念図
この ifcXML には 2 つの意味がある。
・IAI の概念モデルを XML 表記するためのスキーマ
・EXPRESS 表記から XML 表記へのコンバータ
すなわち、EXPRESS で表現された概念モデルを XML 表記することで、aecXML 等で記述されたデー
タベースとのマッピングを可能とする。このように ifcXML が、IFC モデルを WEB 上で利用する手段と
なる。
2.2.6. 課題と対策
工程データ交換として IFC を採用し仕様を策定したが、その中で考えられる課題が存在する。ここで、
考えられる課題とその対策を述べる。
・抽象的な表現にとどまっている部分がある。
→抽象的で解釈が必要な物については当ガイドライン(第 3 章)で記載し実装時の違いを防ぐこと
とした。
・対象が多岐に渡り解釈が困難である。
→必要なタグのみ利用する。当ガイドブック(第 3 章)である程度絞り込むこととした。
・テキストデータが膨大になりやすい。
→今後、Microsoft Office2007 形式にあるような圧縮済みのファイル形式を標準フォーマットとする
方向で検討する。
3.
IFC による工程データの表現
3.1.
IFC 仕様における工程情報の構造
本章では IFC 仕様の内、工程表を ifcXML で表現する際に必要な情報のみを抽出して解説する。
・ifcXML におけるタグ入れ子構造(ネスト)
入れ子構造の階層は表.1に示す通り5階層で構成されている。参照関係を除き、異なる要素がツリ
ー構造上に入れ子になることはなく、全て並列に並んでゆく。また、工程とその開始日時といった要素
間相互の関連付けを表現する為に id 属性と ref 属性を利用している。
id 属性は各要素タグに”i1”から始まる番号を割り当てていき、相互に参照が行えるように定義されてい
る。子要素タグや参照用の要素タグには番号は振られない。
参照を行う場合には、内容レベルにおかれる参照用の要素タグに nil 属性として”true”を宣言し ref 属
30
性で参照先タグの id 番号を宣言する。
・ifcXML における要素間の関連付け
ネットワーク工程における前工程→後工程や工種による工程の分類を表現する等の場合には、上述の
ref 属性で直接相手の要素タグを参照することはなく、必ず関連付専用の要素タグを介して結びつけられ
る。(表.2)
工程要素タグ<ifcTask>と工程要素タグ<ifcTask>の前後関係を示すネットワークを表現する場合には、
<ifcRelSequence>というタグが双方の要素タグを参照することによって表現される。
この為、XML の情報量としては冗長になる傾向があるが、これにより対象を問わない自由な関連付け
が可能になっている。
31
ifcXML タグの入れ子構造(ref 属性と id 属性による参照関係)
表.1
XML,ST
EP仕様
宣言レ
ベル
IFC仕
要素 子要素
様
内容レベル
宣言 レベル レベル
レベル
解説
XML規格であることの宣言
※実際にはスキーマ宣言等が詳細に表
記されるが省略
STEP‑XML規格であることの表現
※実際にはスキーマ宣言等が詳細に表
記されるが省略
IFC仕様のUnit Of Serialization、
ファイル変換されたデータであること
の表現
一つのプロジェクト(設計、施工、維
持管理等)を表現する<IfcProject>要
素タグ。全ての要素タグにはid属性で
1から始まる通し番号を振る。
Project要素の<name>子要素タグ(プ
ロジェクト名称として利用)
<?XML version="1.0" ?>
<ex:iso̲10323̲28>
<ifc:uos>
<IfcProject id="i1">
<Name>
Tビル新築工事
</Name>
<Name>子要素の内容はここで終了する
<IfcProject>要素タグ内の子要素、内
容はここで終了する
</IfcProject>
<IfcRelSequence id="i54">
<RelatingProcess>
<IfcTask xsi:nil="true" ref="i55" />
工程間のネットワークを表現する
<IfcRelSequence>要素タグ
前工程を表現する<RelatingProcess>
子要素タグ
id=i55の<IfcTask>要素タグを参照し
ているタグ
</RelatingProcess>
<RelatedProcess>
<IfcTask xsi:nil="true" ref="i56" />
後工程を表現する<RelatedProcess>子
要素タグ
id=i56の<IfcTask>要素タグを参照し
ているタグ
</RelatedProcess>
工程間のネットワークの性質を表現す
る<SequenceType>子要素タグ
前工程が終了すると後工程が開始でき
る関係である事を表現する文字列。
<SequenceType>
FINISH̲START
</SequenceType>
</IfcRelSequence>
一本の工程を表現する<IfcTask>要素
タグ
<Name>子要素。工程名称(作業名)と
して利用する。
<IfcTask id="i55">
<Name>
外型枠建て込み
</Name>
マイルストン(行事予定等)であるか
どうかを表現する子要素タグ
工程を表現する場合はFALSEとなる。
<IsMilestone>
FALSE
</IsMilestone>
</IfcTask>
<IfcTask id="i56">
<Name>
壁配筋
</Name>
<IsMilestone>
FALSE
</IsMilestone>
</IfcTask>
</uos>
</iso̲10323̲28>
32
表.2
要素タグ相互の関連付け(工程:”型枠建込 1/11 開始-1/20 終了”の場合)
構成要素の関連付けの例
凡例
タスク−スケジュール間の関連付要素タグ
<IfcRelAssignsTasks>
・自分のID="i23"
・関連するタスク要素ID="i55"
・関連するスケジュール要素ID="i150"
タグの目的 <タグ名>
・タグ内に持つ情報1(属性)
・タグ内に持つ情報2(要素)
・タグ内に持つ情報3(要素)
スケジュール要素タグ
<IfcScheduleTimeControl>
・自分のID="i150"
・開始日="i151"
・終了日="i154"
日時要素タグ
<IfcDateAndTime>
・自分のID="i151"
・日付="i152"
・時刻="i153"
日付要素タグ
<IfcCalenderDate>
・自分のID="i152"
・年="2009"
時刻要素タグ
・月="1"
<IfcLocalTime>
・日="11"
・自分のID="i153"
・時="0"
・分="0"
グループ−タスク間の関連付要素タグ
<IfcRelAssignsToGroup>
・自分のID="i10"
・関連するグループ要素ID="i7"
・関連するタスク要素ID="i55"
日時要素タグ
<IfcDateAndTime>
・自分のID="i154"
・日付="i155"
・時刻="i156"
日付要素タグ
<IfcCalenderDate>
・自分のID="i155"
・年="2009"
時刻要素タグ
・月="1"
<IfcLocalTime>
・日="21"
・自分のID="i156"
・時="0"
・分="0"
グループ(行)要素タグ<IfcGroup>
・自分のID="i7"
・用途="グループ(行)"
・画面最上段からの座標="4"
・グループ名(項目名)="2F"
タスク要素タグ<IfcTask>
・自分のID="i55"
・作業名="型枠建込"
躯体工事
型枠建込
2F
1/11
1/20
1F
33
1
2
3
4
5
6
7
8
9
3.2.
利用する仕様について
本ガイドブックでは、適用する IFC 仕様のバージョンを IFC2x
Edition 3 Technical Corrigendum 1
としている。今後 IFC 仕様が改訂された際には、工程 XML の仕様としても再検討を行う予定である。
但し、大幅な仕様変更等による影響は少ないものと思われる。
ソフトウェアへの実装にあたっては上記バージョンの ifcXML スキーマを用いることになる。スキーマ定
義自体は IAI の Web ページより入手することが可能になっている。
http://www.iai-tech.org/products/ifc_specification/ifcxml-releases/ifcxml2x3-release/summary
上記サイトには2つの XML スキーマが用意されている。
ex.xsd:
EXPRESS モデルの為の汎用スキーマで、IFC 専用の物ではない。これには EXPRESS 形式から XML
へ変換される際のファイルのヘッダ部分と一般的なデータ型部分が対象となっている。またこれは
ISO10303-28 ed2 の一部分でもある。
IFC2X3.xsd:
上記以外の IFC2x3 仕様をファイル変換(uos)した部分のスキーマ。これにはクラス、リレーションシ
ップ、属性、データ型等の全ての IFC 仕様の XML スキーマが含まれる。
上記2つに加え、設定ファイルも存在するが、これらはソフトウェアへの実装の際に利用される事は少
ない。EXPRESS ファイルを XSD ファイルへどう変換するかを定める設定ファイルであり、静的な物で
あるからである。
Configuration.xml:
ifcXML2x3 の為に選択された設定ファイル
Configuration.xsd:
スキーマ定義。ISO10303-28ed2 の一部。
XML の名前空間やスキーマの位置も上記ページにて紹介されているので、実装に際してはその情報に準
ずるものとする。。
3.3.
工程表要素を ifcXML で表現する上での運用ガイド
3.3.1. 説明
本章では IFC 仕様の内、工程表を表現するにあたり必要となる要素のみを抄訳として示す。
また IFC 仕様では工程表の表現に不足する以下の部分を補足する。補足の方法は、仕様の拡張ではな
く、IFC 仕様内に用意されている汎用の定義を行う為の要素を利用するものとする。
その主な項目を以下に示す。
・工程の Y 座標に関する部分
・工種、分類に関する部分
・工程の色、形状に関する部分
その他、実装に関連するのに必要と思われる仕様について以下に示す。
34
・名前空間は下記の通り(IAI の HP より引用)
http://www.iai-tech.org/products/ifc_specification/ifcxml-releases/ifcxml2x3-release/summary
ex.xsd
name space:
urn:iso.org:standard:10303:part(28):version(2):xmlschema:common
name space alias: ex
XSD schema location: http://www.iai-tech.org/ifcXML/IFC2x3/FINAL/ex.xsd
IFC2X3.xsd
name space:
http://www.iai-tech.org/ifcXML/IFC2x3/FINAL
name space alias: ifc
XSD schema location: http://www.iai-tech.org/ifcXML/IFC2x3/FINAL/IFC2X3.xsd
・拡張子
*.ifc.xml を利用する
・文字コードは UTF-8 を利用する。
(XML の標準)
3.3.2. 要素型(Entities)タグについての説明
本章では、ifcXML の主な構成要素となる要素タグとその中の子要素タグについて示す。
IFC に定義されている要素の内、工程表の表現に用いる為に必要な物を表.1に示す。
35
表.1
工程表の構成要素と ifcXML の要素タグとのマッチング
3 工程表を構成する要素
4
書類的な要素
5
プロジェクト要素
6
・プロジェクト名
7
工程計画要素
8
・工事名称
9
・着工日
10
・竣工日
11
工程表要素
12
・工程表タイトル
13
・工程データ範囲(開始日時)
14
・工程データ範囲(終了日時)
15
工程に関わる要素
16
タスク要素
17
・工程名
18
・マイルストンかどうか
19
工種・行(縦軸)に関わる要素
20
行要素
21
・工種分類名称
22
・オブジェクト種別
23
レイヤ要素
24
・レイヤ名
25
・オブジェクト種別
26
時系列(横軸)に関わる要素
27
スケジュール要素
28
・開始日時
29
・終了日時
30
・所要時間
31
日付と時刻要素
32
・日付
33
・時刻
34
日付要素
35
・年
36
・月
37
・日付
38
時刻要素
39
・時刻
40
・分
41
休日カレンダー要素
42
・カレンダー名
43
・オブジェクト種別
44
休日スケジュール要素
45
・開始日時
46
・終了日時
47
要素と要素を関連づける要素
48
工程計画要素と工程計画の関連付要素
49
・主工程計画要素
50
・関連する工程表要素
51
タスクとスケジュールの関連付要素
52
・関連するタスク要素
53
・関連するスケジュール要素
54
タスクとタスクの前後関係の関連付要素
55
・前工程
56
・後工程
57
・時間間隔
58
・順序の性質
59
タスクと行の関連付要素
60
・関連するタスク要素群
61
・関連する行要素
62
タスクとレイヤの関連付要素
63
・関連するタスク要素群
64
・関連するレイヤ
65
タスクと休日カレンダの関連付要素
66
・関連するタスク要素群
67
・関連する休日カレンダー要素
68
行のグループ化要素
69
・子になる行要素群
70
・親となる行要素
71
休日スケジュールとカレンダの関連付要素
72
・関連する休日スケジュール要素群
73
・関連する休日カレンダー要素
74
IFC仕様外の情報を追加する為の要素
75
プロパティセット要素
76
・プロパティセット名
77
・関連するプロパティ要素群
78
プロパティ要素
79
・プロパティ名
80
・値
81
・単位
82
プロパティセットと要素の関連付要素
83
・関連する要素群
84
・関連するプロパティセット
85
36
利用するifcXMLタグ名
<IfcProject>
<IfcWorkPlan>
<IfcWorkSchedule>
<IfcTask>
<IfcGroup>
<IfcGroup>
<IfcScheduleTimeControl>
<IfcDateAndTime>
<IfcCalendarDate>
<IfcLocalTime>
<IfcGroup>
<IfcScheduleTimeControl>
<IfcRelAggregates>
<IfcRelAssignsTasks>
<IfcRelSequence>
<IfcRelAssignsToGroup>
<IfcRelAssignsToGroup>
<IfcRelAssignsToGroup>
<IfcRelAssignsToGroup>
<IfcRelAssignsToGroup>
<IfcPropertySet>
<IfcPropertySingleValue>
<IfcRelDefinesByProperties>
以下に表.1で示された ifcXML タグの IFC 仕様における解説の抄訳と補足事項を示す。また各要素
タグは以下の凡例のレイアウトに従って示される。
凡例:
-----------------------------<要素タグ名>
IAI による定義:
IFC 仕様に記述されている定義の抄訳
工程 XML での運用:
工程表を表現する XML として運用する際の補足事項
属性:
属性名
:
内容
子要素:
<子要素タグ名>
:
子要素タグ内に持つ内容表現の IFC 仕様
子要素タグの用途
:
工程 XML としての運用上表現する内容
--------------------------------------
<IfcProject>
IAI による定義:
設計、施工、維持保全等の、成果物へとつながる諸活動の着手、開始を表現する。プロジェクトとは
情報が交換、共有されるものとして定義される。またこれは建築行為を表現する場合もあるが、必ずし
もそうである必要はない。
工程 XML での運用:
工事名称を保持させる為に利用する。
属性:
id
:
<uos>タグ内の各要素タグに“i1”から始まる連番を振る。
子要素タグや参照用の要素タグには番号は振られない。
子要素:
<Name>
:
OPTIONAL IfcLabel;
建物名称
:
(任意)255 文字以内で表現する
<IfcWorkPlan>
IAI による定義:
建設プロジェクト、あるいはファシリティマネジメントプロジェクトにおける作業計画を表現するも
37
のである。WorkPlan は、それぞれ用途の違いにより複数の WorkSchedule を含むことができる。
工程 XML での運用:
プロジェクト全体を通しての工程計画全体を表現する。一つ一つの工程表は<IfcWorkSchedule>で表
現される。将来的にはデータベース、ファイル内に複数の工程表を持つこともあり得る。現状は、工程
XML 文書中には一つの Project、一つの WorkPlan と一つの WorkSchedule を持つものとする。
属性:
id
子要素:
<Name>
:
OPTIONAL IfcLabel;
工事名称
:
(任意)255 文字以内で表現する
<StartTime>
:
IfcDateTimeSelect;
工事の着工日時
:
関連する<IfcDateAndTime>タグを参照する。
※IfcDateTimeSelect 型は、日を表現する
IfcCalendarDate、日時を表現する IfcDateAndTime、時刻
を 表 現 す る IfcLocalTime 、 の 三 種 類 か ら 任 意 の 型 を 選 択 で き る が 、 工 程 XML の 運 用 上 全 て
IfcDateAndTime に固定する。
<FinishTime>
:
OPTIONAL IfcDateTimeSelect;
工事の竣工日時
:
関連する<IfcDateAndTime>を参照する
<IfcWorkSchedule>
IAI による定義:
Workplan の中で、一つの工程計画を表現する。WorkPlan はそれぞれの目的に応じて複数の工程計画
を持つ事ができる。
工程 XML での運用:
一つの工程表を表現する。
属性:
Id
子要素:
<Name>
:
OPTIONAL IfcLabel;
工程表タイトル
:
(任意)255 文字以内で表現する
<StartTime>
:
IfcDateTimeSelect;
工程表の開始日時:
関連する<IfcDateAndTime>タグを参照する。
<FinishTime>
OPTIONAL IfcDateTimeSelect;
:
工程表の終了日時:
関連する<IfcDateAndTime>を参照する
<IfcTask>
IAI による定義:
建築プロジェクトにおける作業の構成単位の中で、独立して実施されることが認識できる作業の単位。
工程 XML での運用:
38
工程表における一本のアロー、バー、タスク、アクティビティ、いわゆる一本の工程を表現する。ま
た、マイルストン(行事予定)もこのタグで表現する。
属性:
id
子要素:
Name
:
OPTIONAL IfcLabel;
作業名
:
(任意)255 文字以内で表現する
Ismilestone
:
BOOLEAN;
マイルストン
:
Task がマイルストン(行事予定)の場合は”true”、工程の場合は”false”
<IfcScheduleTimeControl>
IAI による定義:
プロセスに関する時間関連の情報を取り込むクラスである。この中には開始、終了時間、プロセスの
期間、余裕時間(フロート)についてそれぞれ計画値と実施値を含む。
工程 XML での運用:
工程の開始日時・終了日時の情報を表現する。IfcTask とは IfcRelAssignsTasks を介して関連付けを
行う。また、IfcTask 以外にも、カレンダーや工期の設定にも IfcScheduleTimeControl を利用する。
属性:
id
子要素:
ActualStart
:
OPTIONAL IfcDateTimeSelect;
開始日時
:
関連する<IfcDateAndTime>を参照する
ActualFinish
:
OPTIONAL IfcDateTimeSelect;
終了日時
:
関連する<IfcDateAndTime>を参照する
ActualDuration :
作業時間
:
OPTIONAL IfcTimeMeasure;
STEP 仕様上 REAL(実数)型の秒数で表記する
※ソフトウェア間の整合性上、カレンダー等の互換性の問題で作業時間と終了日時に矛盾が生じるケー
スが考えられる。工程表の図表としての再現度を考慮した場合には、作業時間よりも終了日時を優先す
る手法が考えられる。
<IfcDateAndTime>
STEP による定義:
特定の日と時刻を表現する
工程 XML での運用:
工程や工期、マイルストンの(開始・終了)に使われる日時を表現する。
※IFC には日付だけの指定、時刻だけの指定を行うクラスもあるが、工程 XML としての運用上時間軸の
指定は<IfcDateAndTime>に統一する。
属性:
39
id
子要素:
<DateComponent>
:
IfcCalendarDate;
日付部分
:
<IfcCalenderDate>タグを参照する
<TimeComponent>
:
IfcLocalTime;
時刻部分
:
<IfcLocalTime>タグを参照する
<IfcCalendarDate>
STEP による定義:
年/月/日で定義された日付
工程 XML での運用:
IfcDateAndTime 内の日付部分を表現する
属性:
id
子要素:
・<DayComponent>
:
IfcDayInMonthNumber;
日部分
:
1−31 の数値で表現する
・<MonthComponent>
:
IfcMonthInYearNumber;
月部分
:
1−12 の数値で表現する
・<YearComponent>
:
IfcYearNumber;
年部分
:
グレゴリオ暦(西暦)で表現する
<IfcLocalTime>
STEP による定義:
時/分/秒で定義された時刻。24 時間制で表現される。
工程 XML での運用:
IfcDateAndTime 内の時刻部分を表現する
子要素:
<HourComponent>
:
IfcHourInDay;
時間部分
:
0−23の数値で表現する
<MinuteComponent>
:
OPTIONAL IfcMinuteInHour;
分部分
:
(任意)0−59の数値で表現する
※STEP による定義の仕様上、24時という表現ができないので、24時は全て翌日0時になる。
時刻を使用せず日付のみの表記とした場合、期間が0日の工程(マイルストン)と1日の工程の区別が
できない。
<IfcGroup>
40
IAI による定義:
「グループ」という考え方を一般化して定義したもの。グループはオブジェクト群の論理的な集合で
ある。これ自体は場所や形を持つ事はない。それゆえにグループは位置的、位相的なグループ化には用
いられない。
工程 XML での運用:
下記の各用途に用いる。
①工程表の Y 方向の座標、
「行」の表現に用いる。多くの工程計画ソフトウェアでは、工程を配置する上
で等間隔に横方向の罫線を引いた「行」を座標の単位としている。
一つの<IfcGroup>インスタンス(タグ)が一つの行、あるいはグループを表現する。
一つの行に複数の Y 座標を持つ場合には最小単位の Y 座標を一つの行として表現する。、また複数の行を
一つのグループが持つ場合には行とグループそれぞれを一つの<IfcGroup>で表現する。行やグループの
入れ子構造は<IfcRelAssignsToGroup>にて表現する。
工程表上での Y 座標は id 属性の数値順とする。(IfcXML ファイル内での出現順)
②カレンダーと休日の定義に用いる
休日を表現する<IfcScheduleTimeControl>を定義する。
例:
4 月 26 日(日)を休日とする場合
開始日時=2009/4/26 00:00:00
終了日時=2009/4/27 00:00:00
5 月3日〜5月6日を休日とする場合
開始日時=2009/5/3 00:00:00
終了日時=2009/5/7 00:00:00
複数の<IfcScheduleTimeControl>を<IfcRelAssignsToGroup>を利用して一つの<IfcGroup>にグルー
プ化する。ソフトにより複数のカレンダーを持つ場合、複数の<IfcGroup>を定義する。IfcXML ファイ
ル上、最初に出現するカレンダーをデフォルトとする。
③レイヤ定義に用いる
レイヤを持つソフトウェアの場合に用いる。複数の<IfcTask>を<IfcRelAssignsToGroup>を利用して一
つの<IfcGroup>にグループ化する。レイヤ名は<Name>子要素を用いる。
属性:
id
子要素:
Name:
:
OPTIONAL IfcLabel;
グループ名
:
(任意)255 文字以内で表現する
41
工程表の Y 座標 :
工種分類を持つ行・グループの場合表記する。
カレンダーの休日:
休日カレンダー名とする。1つしかない場合は不要。
レイヤ定義
レイヤ名とする。
ObjectType
:
Group タグの用途:
:
OPTIONAL IfcLabel;
下記の文字列から選択する
工程表の Y 座標 :
”RowGroup”とする。
カレンダーの休日:
”HolidayGroup”とする
レイヤ定義
“LayerGroup”とする
:
<IfcRelAggregates>
IAI による定義:
集合体と集合要素間の関連付け。一般的な全体/部分関係の関連付け IfcRelDecomposes の特殊タイプ。
工程 XML での運用:
<IfcWorkSchedule>と <IfcWorkPlan>の関連付けを行う為に用いる。 Ifc の仕様上は、ひとつの
<IfcWorkPlan>に複数の<IfcWorkSchedule>を関連付けることができるが、工程表を表現するファイル
としての運用上関連付けは1:1とする。
属性:
id
子要素:
RelatingObject
:
IfcObjectDefinition;
集合体オブジェクト
:
<IfcWorkPlan>を参照する
RelatedObject
:
SET [1:?] of IfcObjectDefinition;
集合要素オブジェクト
:
(運用としては一つの)<IfcWorkSchedule>を参照する
<IfcRelAssignsTasks>
IAI による定義:
<IfcTask> を <IfcWorkControl> へ と 関 連 付 を 割 り 付 け る 為 の ク ラ ス 。 割 り 付 け は さ ら に
<IfcScheduleTimeControl>を割りつけることによって、work plan あるいは schedule に割り当てられた
時に、時間的な制約を作業タスクに割りつけることができる。
工程 XML での運用:
<IfcTask>に開始時間・終了時間を割り当てる為に用いる。
属性:
id
子要素:
RelatedObjects
:
SET [1:?] OF IfcObjectDefinition;(IfcTask)
関連する Task
:
関連する<IfcTask>タグを参照する。
※複数の<IfcTask>が同じ<IfcScheduleTimeControl>を参照する場合、タグ内に参照する<IfcTask>タグ
42
を複数列記する。
TimeForTask
:
OPTIONAL IfcScheduleTimeControl;
Task の日時
:
関連する<IfcScheduleTimeControl>タグを参照する
<IfcRelSequence>
IAI による定義:
この
関連性
を表現するオブジェクトは、作業プロセスの時間軸上の接続を取り扱う。
<IfcRelSequence>は2つの作業プロセス間の関連性として定義される。前後プロセス間の時間間隔も
<IfcRelSequence>にて設定される。SequenceType は<IfcRelSequence>において、時間差をどの様に適
用するかを定義する。
工程 XML での運用:
工程を結合するネットワーク、ダミーアローを表現する。描画スタイル(曲線の向き、色、形等)は
IfcTask 等ど同様に他のクラスにて定義する。
属性:
id
子要素:
RelatingProcess
前工程
:
IfcProcess;
:
RelatedProcess
:
関連する<IfcTask>タグを参照する
IfcProcess;
後工程
:
関連する<IfcTask>タグを参照する
TimeLag
:
IfcTimeMeasure;
時間間隔
:
工程間の時間間隔を表す。STEP 仕様上 REAL(実数)型の秒数で表記する。
通常は0である。
SequenceType
:
順序の形式
:
IfcSequenceEnum;
<IfcRelSequence>における前後の工程(IfcTask)の関係を示す。下記の何れか
の文字列となる。前工程の終了が後工程の開始に繋がる通常のネットワークは START_FINISH となる。
START_START
START_FINISH
FINISH_START
FINISH_FINISH
NOTDEFINED
<IfcRelAssignsToGroup>
IAI による定義:
このオブジェクトでは、オブジェクトのグループへの割り当てを取り扱う。これにより任意のオブジ
ェクト群を一つのグループにまとめることができる。またこれは中に他のグループを含めることができ
る。グループ化の関連性は再帰的に定義することができる。
RelatedObjects にてグループを構成するオブジェクト群を参照し、RelatingGroup がその各要素から構
43
成されるグループを指す。
工程 XML での運用:
<IfcGroup>と、<IfcGroup>によってグループ化されるタグ群の関連付けを表現する
属性:
id
子要素:
RelatedObjects
:
SET [1:?] OF IfcObjectDefinition;
関連するタグ
:
関連するタグを参照する(IfcTask、IfcScheduleTimeControl、IfcGroup)
RelatingGroup
:
IfcGroup;
関連するグループ:
関連するグループを参照する
<IfcPropertySet>
IAI による定義:
<IfcPropertySet>は全ての動的で拡張可能なプロパティ(性質・特性)を定義する。<IfcPropertySet>
は Property 群をツリー構造で保持する為のコンテナ(入れ物)クラスである。これらの Property 内容
はそれらの Name 要素に従って変換される。
工程 XML での運用:
Ifc 仕様にて定義されていない内容を各タグに付加する為に利用する。
例:<IfcTask>の形状、色
ソフト固有のユニーク ID との関連付け
各ソフト固有の情報を IfcXML ファイル上でも保持する
属性:
id
子要素:
・Name
:
OPTIONAL IfcLabel;
プロパティセット名:
(任意)255 文字以内で表現する
・HasProperties :
SET [1:?] OF IfcProperty;(IfcPropertySingleValue)
プロパティ要素
関連する<IfcPropertySingleValue>を参照する。IfcProperty にはテーブル型
:
等、他のサブクラスが存在するが運用上 IfcPropertySingleValue を利用するものとする。
<IfcPropertySingleValue>
IAI による定義:
一つの値を持ったプロパティ(性質・特性)を定義する。これは一つのプロパティ名に一つの値が与
えられているものである。
工程 XML での運用:
一組のプロパティを表現する。プロパティを持つタグが、一組のプロパティを持つ場合、あるいは複
数 の プ ロ パ テ ィ を 持 つ 場 合 ど ち ら の 場 合 で も 、 <IfcPropertSet> で グ ル ー プ 化 を 行 い 、
<IfcRelDefinesByProperties>でタグとの関連付を行う。
44
属性:
id
子要素:
・Name
:
OPTIONAL IfcLabel;
プロパティ名
:
255文字以内で表現する
・NominalValue :
OPTIONAL IfcValue;
プロパティ値
:
値を表現する(数値、文字列、Boolean)
・Unit
:
OPTIONAL IfcUnit;
単位
:
(任意)単位を表現する<IfcUnit>を参照する(説明省略)
<IfcRelDefinesByProperties>
IAI による定義:
このオブジェクト化された”関連付け”はプロパティセット定義とオブジェクト間の関連付けを定義す
る。プロパティはプロパティセットに纏められ、プロパティセットはオブジェクト型への定義へと纏め
られる。
工程 XML での運用:
IfcXML だけでは表現できない情報をタグにプロパティとして付加する為に用いる。
<IfcPropertySet>と各タグを関連づける為に用いる。
属性:
id
子要素:
RelatedObjects
:
SET[1:?] OF IfcObject;
関連するタグ
:
関連する(複数の)タグを参照する
RelatingPropertyDefinition
:
IfcPropertySetDefinition;(IfcPropertySet)
関連するプロパティセット:
関連する<IfcPropertySet>タグを参照する
45
4.
おわりに
4.1.
今後の方向性
現在、建設現場の管理技術者は、最小限の人数で施主の厳しい条件に対応しながら、顧客満足を求め
数多くの業務を遂行している。そこで展開される工程計画、工程管理は、コスト、品質、安全に密接に
関係し現場運営を左右し、各社各様の工程表作成ツールを使用して行われている。現在は、各ソフトメ
ーカーの工程表作成ツール間におけるデータ互換が出来ないため、各ツールで同じ情報(データ)を再
入力して工程表を作成している。しかし、工程表作成ツールが当該データ交換ガイドブックを準拠する
ことによって、各工程表作成ツール(以後、当該ガイドラインに準拠したものを BCS−工程 XML 準拠
ツールと呼ぶ)の間で工程データ交換が行うことが出来きるようになる。協力業者が、元請け会社の全
体工程表のデータを自社が使用している BCS−工程 XML 準拠ツールに読み込み、そこで表示された全
体工程表を基に、自分が請け負う工事の計画業務の工程を描き加えることが出来る。建設現場の管理技
術者は、協力業者と工程データの交換が行えることによって、タイトな時間における業務効率を向上さ
せ、ヒューマンエラーをなくし、工程情報を正確に伝えることよってコストダウン、品質と安全の確保
に結びつけることが可能になる。例えば、BCS−工程 XML 準拠ツールを使用することによって、次のシ
ナリオが考えられる。
【シナリオ1】
工事を受注する際、企画部署は、発注者への説明あるいは概算コストを算出するための概略全体
工程表を、競争に勝つために短時間での作成が要求される。そこで、施工数量、歩掛、施工条件を
入力すると自動的に工程表を作成する機能を持つ BCS−工程 XML 準拠ツールで短時間に作成す
る。そして、竣工日に間に合うように工程調整して概略全体工程表を作成する。
受注後、工事計画を行う部署においては、現場の周辺環境、地域の雨天日、強風日等の作業不能
日を考慮して、述べ日で工程表を描く機能を持つ BCS−工程 XML 準拠ツールに、受注する際に作
成した概略全体工程表のデータをインポートして、更に詳細に工程計画を行いながら全体工程表を
作成する。今までは、各部署で使用している工程表作成ツールの違いによって、概略全体工程表を
入力しなおしてから、全体工程表の作成を行っていたが、BCS−工程 XML 準拠ツールを使用する
ことによって再入力の手間が減り作業時間が短縮され、入力の人為的ミスも無くなる。
実施現場では、所内の工事担当者、協力会社、作業員に確実に工程情報を分かりやすく確実に伝
える必要があり、そのため工程表の書式、表記方法が、現場ごとあるいは工程表作成担当者ごとに
工夫されている。そうした書式、表記に対応する機能を持つ BCS−工程 XML 準拠ツールに、前記
の全体工程表をインポートして更に詳細な全体工程を作成し、そして、備考欄等を挿入してそこに
確実に伝えたい情報、管理したい情報等を分かりやすく表記し、全体実施工程表を作成する。次に、
全体実施工程表を基にして月間工程表を作成する。協力会社においても BCS−工程 XML 準拠ツー
ルを使用することによって、元請け会社が作成した月間工程表のデータをインポートして、協力会
社の工程計画を行う。このように各工程表作成ツールにおいて、シームレスにデータ交換が行われ
る。
46
【シナリオ2】
元請け会社によって全体工程表で鉄骨の建方工事が計画され、建方開始日が決まる。ファブリケ
ータは、元請け会社より受け取った全体工程表のデータを自社の BCS−工程 XML 準拠ツールに読
み込み、鉄骨建方の開始日を基に鉄骨製作・建方要領書、鉄骨建方計画図、鉄骨製作図、現寸検査、
製品検査等の計画業務工程を描きながら、計画、検討、調整を行う。そして、計画業務工程が描き
加えられた全体工程表データを元請け会社に送る。元請け会社は、ファブリケータから計画業務工
程が描き加えられた全体工程表データを受け取り、自社が使用している BCS−工程 XML 準拠ツー
ルに読み込み、要領書や図面等のチェック、修正、承認の計画を立て、ファブリケータに確認を行
う。また、外壁が PCa カーテンウォールとなると、こちらの協力会社もファブリケータの作成し
た工程データを読み込み、鉄骨の製作に合わせた工程計画、検討、調整を行う。PCa カーテンウォ
ールがタイル貼りであると、タイルの決定、割付図、製造搬入工程を同じ要領で行うこととなる。
工程表データ交換が出来ることによって、各協力会社が全体工程表データを基に計画業務工程
を付加し、更に立案された計画業務工程に係る協力業者が、その工程表データを読み計画業務工程
を付加するといった計画の連携、協調が行える。即ち、建築生産に関係する会社の全てにとって、
業務の省力化と効率化、確実な工程計画と情報伝達、新たな協調的発想等のメリットが生まれる。
これによって工程表データ交換の活用範囲が広がることとなる。
上記以外に、BCS−工程 XML 準拠ツールによって、大規模現場における各担当者のデータ交換、JV
や分割発注工事における各社のデータ交換、図表としての工程表から工程データとしての2次利用等で、
業務の省力化と効率化、確実な工程計画と情報伝達、新たな協調的発想等のメリットが考えられる。
4.2.
将来の可能性
当該データ交換ガイドブックでは、IAI における IFC 仕様を参照し XML における工程データの仕様を
示している。前述したように、IAI は、IFC によって建物の形状、性能、コスト、スケジュールなどのオ
ブジェクトの集合体である BIM を共有し全世界における建築業界の相互運用を目指している。即ち、将
来において、BCS−工程 XML 準拠ツールは、BIM との連携が出来る可能性がある。そして、次のよう
なことが可能になると考えられる。
①BCS−工程 XML 準拠ツールで作成した工程データが BIM に取り込まれることができれば、
BIM
の建物オブジェクトと工程データによって、3 次元 CAD あるいはプレゼンツールで時系列に 3
次元の躯体や仮設足場等の状況が表示可能となり、受注活動、施主説明、施工計画、現場打合せ
等に利用できる。
②BCS−工程 XML 準拠ツールが BIM の建物オブジェクトの数量を利用して、概算の全体工程表
を自動的に生成できる。この工程データを BIM に取り込み、他の BCS−工程 XML 準拠ツール
において計画業務工程を立案することができる。
③BCS−工程 XML 準拠ツール間で連携し計画決定された発注情報は、BIM を通じて EDI ツール
によって発注業務が行える。
47
はじめにも述べたように、工程計画業務においては時間という定量的な物を管理する業務にも関わら
ず、1+1=2と計算するような数量的なアプローチはその処理の複雑さ故に実務上避けられてきた経
緯がある。しかしこの問題は、昨今著しい業務の IT 化により解決されつつある。この機会を逃さず業務
のデータ交換が活発になる環境を整える事により、この変革のスピードをさらに促し、建築産業におけ
るさらなる効率化を成し遂げることが当活動における目的の一つである。
4.3.
実現に向けて
今後は、当該データ交換ガイドブックを基に、更に XML による仕様を固めて各社の工程表作成ツール
に実装し、次のステップによって検証する予定である。
第1ステップ:BCS−工程 XML にて作成された工程表モデルの検証を行い、BCS−工程 XML 準
拠ツール間において工程表を加工、修正しないでデータ正しく交換される検証を行
う。
第2ステップ:BCS−工程 XML 準拠ツール間においてデータ交換を行う際に、交換を行う工程表
に加工や修正を行い、その工程データが正しく交換されたかの検証を行う。
第3ステップ:実際の現場においてデータ交換実験を行う。このステップでは、データ交換の検証
を行うだけでなく、実務レベルにおける業務効率等の検証を行う。
建設業は、建設投資の減少の傾向にあり、また利益率も厳しい環境にある。そうした中、建築生産に
おける重要な項目である工程計画、管理業務を、BCS−工程 XML 準拠ツールを使用した工程表のデータ
連携によって、業務改善、関係者間の協調と新たな発想の触発を行って顧客満足の向上を図り、また、
ITを使用して業務効率を改善し、現場管理技術者のよりよい業務環境の実現を目指していく。
48
執筆委員
・大成建設(株) 秋葉高志
・東急建設(株) 鶴田賢二
・(株)ウェッブアイ
・(株)かねこ
吉田一彦
・(株)ギャラクシー
・(株)構造ソフト
・マイスター
宮沢寛子
土肥稔幸
古坂利治
田村慎治
参考文献
・フリー百科事典『ウィキペディア(Wikipedia)』
・3次元建物情報モデル IFC の概要および4D シミュレーションへの応用について
・建設業界における XML の活用―3次元建築モデルデータ IFC への XML 技術応用に関して
建築コスト研究 2009SPRING 特集 BIM
(IAI 日本技術検討分科会リーダ
セコム株式会社 IS 研究所
足達嘉信
・BIM/IFC に関する国際動向
(IAI 日本技術統合委員長溝口直樹)
・IAI ウェブサイト(http://www.buildingsmart.com/)
・IFC Released Specifications(http://www.iai-tech.org/products/ifc_specification/ifc-releases/summary)
謝辞
・本ガイドライン作成にあたり、情報提供いただきましたセコム株式会社 IS 研究所
の意を表します。
本書に関する問い合わせ先
(社)建築業協会 E-mail : [email protected]
IT 推進部会 http://www.bcs.or.jp/bcs_it/top.html
49
足達嘉信様に感謝