室蘭工業大学大学院工学研究科

(1)

トンネルのライフサイクルマネージメントに供するプロダクトデータモデルの研究

第２０１０-１３号

室蘭工業大学大学院工学研究科

教授板倉賢一

平成２３年１１月

(2)

（４）覆工コンクリート施工管理ファイル ···３０３．３．２トンネル進行管理ＸＭＬファイルのデータクラス···３０３．４切羽観察データの処理···３３３．４．１切羽観察データ管理のためのＸＭＬファイル···３３３．４．２切羽観察データ管理のためのＸＭＬファイルのデータクラス···３４

４． GENESIS/THQ作動の実際···３７ 4．１概説···３７４．２トンネル進行管理···３８４．２．１トンネル進行管理の初期画面と地質縦断図···３８４．２．２トンネル進行データ···３９４．２．３トンネル進行管理データ入力···４２４．２．４切羽観察データ入力···４７４．３ 3次元表示画面···４９

５．まとめ···５１

Appendix A 東北中央自動車道栗子トンネル（山形側）工時の概要

Appendix B 三井住友建設栗子トンネル作業所におけるディスカッション･メモ

Appendix C トンネル施工管理XMLスキーマ

(4)

１．はじめに１．１概論

本研究グループは、これまで大規模地下開発の設計・施工・維持補修を一気通貫で支援することのできるシステムの設計と構築に取り組んできた。このシステムは、

WEB

３

D¹

の

CG

技術

と

RDBMS²

のデータ検索･処理機能を融合することで、

PC

上に仮想の地下空間を構築し、そ

の仮想空間内をユーザーが自由に動き回り、必要とするデータにアクセスし、処理を行うシステムである。以下では、当該システムを

GENESIS/THQ(Geo-Engineering Network Sensors and Intelligent Synthesis /Tunnel Head Quarter)

と仮称する。

これまで、本研究グループは、

(

財

)

日本建設情報総合センターより以下の研究助成を受け、

GENESIS/THQ

の機能の拡充とデータ処理機能の整備、ならびにプロダクトデータモデル化

を図るとともに、瑞浪超超深地層研究所立坑工事において試験運用を実施し、ほぼ実用に供することのできるレベルに達したものと考える。

第

2006-03 Web3D

と

RDBM

を援用した大規模地下開発支援システムの開発

第

2007-02

柔軟な時間管理概念を導入した

4

次元

GIS

による大規模地下開発支

援システムの構築

第

2009-01

レーザースキャナーによる地下構造物のプロダクトデータモデル構築と、

その設計･施工・維持管理への適用に関する研究

GENESIS/THQ

は、当初、地下開発とその運用全期間で発生する膨大なデータを処理する

ことを目的としたため、高性能なコンピュータの利用を前提として開発された。このため、地下発電所、石油･ガス備蓄基地、鉱山開発等の情報管理に高額な投資を行うことのできる大規模プロジェクトにその適用範囲が限定されてきた。

しかしながら、

(

財

)

日本建設情報総合センター研究助成事業第

2009-1

において、

GENESIS/THQ

を分散処理型のクラウドコンピューティング

³

化したことにより、あらゆる地下構

造物施工現場で

GENESIS/THQ

を汎用的に利用することが可能になった。すなわち、中央に高性能なデータ処理能力と大容量データ記憶容量を持つ情報処理センターを構築し、各工事事務所、あるいは施工現場事務所からネットを介して

GENESIS/THQ

を利用し得るため、中

1 Web3Dとは、Web上での3次元グラフィックスの表示とその仕組みの総称である。特に、3次元物体をユーザーが自由に操作して、拡大や縮小、全方向への回転などが可能であるような技術を指す場合が多い。Cult3D、

Pulse3D、Viewpoint、Shockwave3DなどがWeb3Dに該当し、オンラインショッピングなどで活用され始めている。

2 リレーショナルデータベースマネジメントシステム (relational database management system, RDBMS) とは、エドガー・F・コッドが提唱した関係モデル (リレーショナルモデル) に基づいた、コンピュータのデータベースマネジメントシステム (DBMS) である。 RDBMS によって構築するデータベースを、リレーショナルデータベースという。

関係モデルにおける「関係」(リレーション) は、一般には「表」(テーブル) と呼ばれることが多い。 2007年現在、

RDBMS は最も一般的に使われているデータベースマネジメントシステムである。いくつかの RDBMS では、オブジェクト指向の機能拡張を行っている。このような RDBMS は、ORDBMS と呼ばれる (オブジェクト関係データベース) 。RDBMS とされるシステムの多くは、データベース言語として SQL を採用している。

3 従来のコンピュータ利用は、ユーザー（企業、個人など）がコンピュータのハードウェア、ソフトウェア、データなどを、自分自身で保有・管理していたのに対し、クラウドコンピューティングでは「ユーザーはインターネットの向こう側からサービスを受ける形になる。ユーザーが用意すべきものは最低限の接続環境のみである。

(5)

小規模の地下開発、例えば交通トンネルや農工業用水トンネル等の工事においてもこれを運用することが可能となった。

本研究（

(

財

)

日本建設情報総合センター研究助成事業第

2010-13

）は、その成果を応用し、

わが国の建設投資の中で大きな比重を占める中小トンネル施工現場への同システムの導入と、

構築されたデータベースのトンネル維持管理への適用を目的として実施している。

GENESIS/THQ

の中小トンネル工事への適用に当たっては、上記のハードウェア投資以外

にも大きな問題が二つある。一つは、システムのプラットフォームとなる

CG

モデル作成に要する工数と費用の問題であり、もう一つは日常業務の煩雑化の問題である。一般に、トンネルの

3

次元

CG

作成には、習熟した技術者が数週間の作業時間を要し、発生する費用も多大なものとなる場合が多く、これが前者の問題である。ある程度の技能を有する技術者が、簡便な作業で、かつ低コストで

3

次元

CG

が作成できるようにならなければ、トンネル施工現場へ汎用的に当該システムを導入することは難しい。

一方、トンネルの施工管理業務は、現在でも多忙を極めているため、データベース構築という新しい業務を負担させることは、施工品質の低下、ならびに施工の安全管理の不徹底という新たな問題を生じさせかねない。さらに、データベース構築には、ある程度のデータベース言語や

XML

等に関する知識が必要となるが、これを満たした技術者を各現場に配置することは現実的に難しい。これが後者の問題である。

本報告書は、上記の２つの問題を解決し、トンネル施工現場に汎用的に

GENESIS/THQ

を普及することを目的として実施した、平成

23

年

4

月末時点までの助成研究の成果を取りまとめたものである。前者の問題解決に関しては、

CALS/EC

の普及により、配布されるようになった

CAD

データと

GENESIS/THQ

の

RDBMS

機能を援用することでトンネルの

3

次元

CG

モデル

を汎用的、かつ効率的に作成する手法を開発し、マニュアル化した。その手法と実際を第

2

章に示す。

また、後者の問題解決に関しては、日常の施工管理業務そのものを

GENESIS/THQ

のシステム内で実施することで、これまでの管理業務と同等の作業でデータベースを構築するシステムを志向した。今日、トンネルの施工管理業務のほとんどは現場事務所の

PC

上にある各種ソフトで処理されるが、このソフトに対するデータ入力とソフト処理の間にデータベースを介することで、日常のデータ入力業務がそのままデータベース構築につながるシステムの設計に着手した。

しかし、平成

23

年

3

月

11

日の東日本大震災により、当初、モデル現場としていたトンネルが

工事中止になり、急遽モデル現場を変更せざるを得なかった。このため、大幅なスケジュール

変更が懸念されたが、三井住友建設株式会社が施工する複数のトンネル現場からの多大な

支援を受け、研究終了時には、ほぼ当初の目標を達成できた。

(6)

１．２ GENESIS/THQ の概要

前述のように、

GENESIS/THQ(Geo-Engineering Network Sensors and Intelligent System /

Tunnel Head Quarter)

は、地下開発の設計・施工・維持補修を一気通貫で支援することを目的

とした施工管理支援システムである。その特徴は、

WEB

３

D⁴

の

CG

技術と

RDBMS⁵

のデータ検索･処理機能を融合することで、

PC

上に仮想の地下空間を構築し、その仮想空間内をユーザーが自由に動き回り、必要とするデータに直感的にアクセスし、処理を行うことが可能な点にある。これまでのデータベースは、データ検索にキーワード入力を用いていたため、適切なキーワードを入力しなければ必要とするデータにアクセスすることができなかった。当システムではデータベース上にデータが格納されている箇所の仮想空間にタグ（

_Map_Symbol）

が現れ、これをクリックすることで必要な情報に容易にアクセスすることができる。図-1.1 は、瑞浪超超深地層研究所立坑工事の仮想空間上で、ボーリングコア写真にアクセスする手順の概略を示したものである。また、

Fuzzy

理論に基づく柔軟な時間軸をデータ管理に導入したことにより、あいまいな時間記憶に対してもデータアクセスを容易とした。図-1.2 は、あいまいな時間記憶から立坑掘削進行を特定する手続きを示したものである。

Map Symbol

図-1.1 仮想空間上からのデータ呼び出し

図-1.2 あいまいな時間記憶からの立坑掘削振興の同定

4 Web3Dとは、Web上での3次元グラフィックスの表示とその仕組みの総称である。特に、3次元物体をユーザーが自由に操作して、拡大や縮小、全方向への回転などが可能であるような技術を指す場合が多い。Cult3D、

Pulse3D、Viewpoint、Shockwave3DなどがWeb3Dに該当し、オンラインショッピングなどで活用され始めている。

5 リレーショナルデータベースマネジメントシステム (relational database management system, RDBMS) とは、エドガー・F・コッドが提唱した関係モデル (リレーショナルモデル) に基づいた、コンピュータのデータベースマネジメントシステム (DBMS) である。 RDBMS によって構築するデータベースを、リレーショナルデータベースという。

関係モデルにおける「関係」(リレーション) は、一般には「表」(テーブル) と呼ばれることが多い。 2007年現在、

RDBMS は最も一般的に使われているデータベースマネジメントシステムである。いくつかの RDBMS では、オブジェクト指向の機能拡張を行っている。このような RDBMS は、ORDBMS と呼ばれる (オブジェクト関係デー

(7)

現在、

GENESIS/THQ

は、図-1.3 および写真-1.1 に示す分散処理型のクラウドコンピューティング

⁶

化がなされており、ネットを介しての利用が可能となっている。なお、本年度研究に関しては、情報管理の観点からスタンドアローンの

PC

で開発を行っている。

図-1.3

GENESIS/THQ

の分散処理型クラウドコンピューティングシステム構成図

(a)

データ処理・インデックス・

(b)Web

データ提供

(c)

並列分散データベース

ScreenWall

（

Linux PC 12

台）

（

Linux PC 4

台）

（

Mac

１２台）

写真-1.1

GENESIS/THQ

の分散処理型クラウドコンピューティング構成（室蘭工業大学）

6 従来のコンピュータ利用は、ユーザー（企業、個人など）がコンピュータのハードウェア、ソフトウェア、データなどを、自分自身で保有・管理していたのに対し、クラウドコンピューティングでは「ユーザーはインターネットの向こう側からサービスを受ける形になる。ユーザーが用意すべきものは最低限の接続環境のみである。

(8)

最後に、

GENESIS/THQ

の超大容量データ処理能力を示すため、瑞浪超超深地層研究所立坑工事において採取されたレーザースキャナーによる立坑壁面形状データ処理例を図-1.4 に示す。

(a)

(3D

モデル

)

(b)

(

テクスチャ

)

(c)

(

点群

)

(d)

(3D

モデル

)

と

(

テクスチャ

)

の複合表示

図-1.4

GENESIS/THQ

による立坑壁面形状データ処理例

(9)

２． RDBMS 機能を援用した３DCG モデル作成システム２．１概要

CALS/EC

の普及により、施工図面等が

CAD

データで配布されることが一般的になった。し

たがって、３

D

モデルの作成は、配布された

CAD

データを基に実施することが合理的であり、

大幅な効率化が期待されることは言を俟たない。

しかしながら、土木製図では第三角法

¹

が用いられていないため、

CAD

データを用いたとしても自動的に３

D

モデルを作成することは難しい。このため、ある程度の人力作業が必要となるが、対象をトンネルに限定することで、トンネルの３

DCG

モデル作成過程をマニュアル化が可能となり、大幅な効率化が可能となると考えた。

一般に、三次元のトンネルモデルを作成する手順は、断面図や支保パターン図、トンネル線形図を参照し、トンネル掘削断面をトンネル線形に合わせて展開し、ベースとなるトンネル３

D

モデルを作成した後、これに合わせて覆工コンクリートや吹付けコンクリート、ロックボルト、鋼製支保工等の支保部材を配置するというものである。このような三次元モデルは、トンネル延長が大きければ大きいほどデータ量が大きくなるだけでなく、その操作に膨大な記憶容量が要求され、その処理速度が大きく低下するという問題が発生する。また、切羽進行に合わせて三次元のトンネルモデルを作成する場合、ほぼ同じ作業を繰り返さなければならないという問題もある。

単位支保パターンモデルデータ

トンネル線形データ

支保パターン分割データ

RDBMS

トンネル３Dモデル

図-2.1

RDBMS

機能を援用したトンネル３

D

モデル作成概念

このため、本研究では

GENESIS/THQ

のＲＤＢＭＳ機能をトンネル３Ｄモデル作成に援用することで上記の問題の解決を図るとともに、モデル作成の効率化を試みた。すなわち、各トンネル支保パターンの一掘削長を一つの単位としたトンネル３Ｄモデルをデータベース上に登録するとともに、トンネル線形データ、および支保パターン分割データをデータベース上に登録

1 第三角法による図面は、正面図（前から見た図）、平面図（上から見た図）、および側面図（横から見た図）から構成され、それらを描く位置は厳密にさだめられている。すなわち、正面図の真上に平面図を描き、正面図の真横に側面図を描く。また、正面図は品物の最も代表的な面とすることが決められている。一般的な図面は3方向からの図面で立体の形状を適切に表すことができ、そのような図面を三面図と呼ぶ。なお、円柱などの場合は2方向からの図面ですむ場合もある。

(10)

し、参照したいトンネル区間に応じた支保パターンの単位３Ｄモデルを組み合わせることにより、

トンネル３Ｄモデルを作成しようとするものである。

以下では、

2.2

節に

CAD

データを基にマニュアル化した単位支保パターンモデルデータの

作成法を、また

2.3

節にトンネル線形データの作成手順を示す。

(11)

２．２単位支保パターンモデル作成のマニュアル化

わが国で配布される施工図面等の

CAD

フォーマットはオートデスク社が策定した

DWG

形式

2

であることがほとんどであるため、

3D

モデリングソフトにインポートできない場合が多い。このため、

DXF

形式

³

に変換する作業が必要となる。また、

CAD

データはポリラインで描画されているため、３

D

として実体化するためには、描画ソフト等で線間に面等の要素を挿入しなければならない。以下の単位支保パターンモデル作成作業では市販の

3DS MAX

と

Metasequioa

を描画ソフトとして、また

CAD

ソフトとして

AutoCAD civil 3D

を使用した。

以下に作業手順を示す。なお、｛｝は各ソフトのコマンド等を示すものである。

(1) CAD データのインポート

ＤＸＦに変換された

CAD

データを３ＤＳＭＡＸ上にインポートすると、３

DS MAX

上で編集可能なスプラインの集まりが図-2.2 のように表示される。

図-2.2 ３D MAX

上に読み込まれたトンネル支保パターン図

（２）不要データの削除とワールド座標原点への移動

インポート後、三次元トンネルモデルの作成に必要なデータ以外を削除するとともに、ワールド座標系状で以降の作業を行うため、レイヤ：Ｂ－ＤＭＫの軸（黄色の線）を参考に、ワールド座標原点とトンネル中心を図-2.3 のように一致させる。

2 バイナリ形式で二次元、もしくは三次元のベクトルデータ、レイヤ、線種等の図面データ、およびメタデータ等の情報を含む CAD ファイル形式。DWG 形式は AutoCAD のバージョン間で差異があり、古いバージョンで読み込めた場合でも、編集などの操作によって一部の情報が脱落する場合がある。また、オートデスク製品以外から保存された DWG ファイルには、データ構造上に欠損のあるものがあり、編集中のソフトウェアを不安定にすることもある。

3他の CAD ソフトウェアとのファイル交換を容易にするため、オートデスクが定義した CAD ファイル形式。DXF は公開された仕様と可読性の高いテキスト形式という特徴により、サポートするサードパーティ製のソフトウェアも開発しやすくなっている。

(12)

図-2.3 不要データを削除し、ワールド座標系に原点を一致させる

(3)二次元トンネル断面の作成

図-2.4 のように、ロックボルトや鋼製支保工のトンネル断面にかかわる以外のポリゴンを消去した後、残ったポリゴンを図-2.5 のように｛編集可能ポリゴン｝に変換することによって３ＤＳＭＡＸ上での処理が可能となる。なお、変換後のデータ形式は点群データである。

図-2.4 トンネル断面以外のポリゴンデータの削除

図-2.5 点群データへの変換

(13)

（4）コンクリート部材二次元モデルの作成

(3)

で作成したトンネル断面の点群に沿って、コンクリート部材厚さに相当する面を張ることで、

コンクリート部材の二次元モデルを作成する。なおここでは、吹付コンクリートは青、覆工コンクリートは赤、インバートは緑系のマテリアルで統一することとした。

図-2.6 コンクリート部材二次元モデルの作成

(5)トンネルモデルの立体化

コンクリート部材の二次元モデルを作成後、それぞれの面を押し出して立体化を行う。また、

押し出した側と反対方向に鏡面を生成し、立体モデルとして閉じる。なお、押し出し寸法は、

各支保パターンの一掘削長とする。図-2.7 に、ベースとなる立体化した三次元トンネルモデルを示す。

図-2.7 立体化したトンネルモデル

(14)

（6）ロックボルト・モデルの作成

ロックボルトや鋼製支保工等の支保部材は離散的に配置されるため、トンネル断面やコンクリート部材とは別途にモデルを作成する。

ロックボルトの作成では、

(1)(2)

の手順を踏襲した後、図-2.8 のように｛編集可能スプライン｝

で認識されるロックボルト以外のポリゴンを消去する。この状態で、｛レンダメッシュを表示（編集タブ

/

レンダリング）｝をチェックすると、その各ロックボルトのポリゴンを軸とした多角柱ができる。

ここでは、多角柱を

12

角柱とし、その半径をロックボルト径とし、マテリアルは黄系とした。なお、

フォアポーリングも同様の手法で作成することが出来る。

図-2.8

{

編集可能スプライン

}

で抽出されたロックボルト要素

（7）鋼製支保工モデルの作成

構成支保工モデルの作成方法は、

H

型鋼部位と継ぎ手板・底板部で異なり、別々に作成した部位を合体することで構成支保工モデルとした。

具体的には、

H

型項部位のモデル作成は、

(1)(2)(3)

の作業を踏襲し、図-2.9 のようにワールド座標原点とトンネル中心を一致させ、不要なポリゴンを消去し、さらに｛編集可能ポリゴン｝への変換等の下準備を行った後、構成支保工の点群に沿って図-2.10 のように面を挿入してゆく。

モデルの押し出しは設計図の値にのっとって、リブ部とフランジ部を別々に押し出す。この時

点では、図-2.11 のようにＨの形（エの形）になるように押し出す。なお、この時点では図-2.11

のように、マテリアルを一時的に水色とした。

(15)

図-2.9 構成支保工モデル作成の下準備図-2.10 構成支保工モデル面要素の挿入

図-2.11

H

型項部位モデルの押し出し図-2.12

Metasequoia

上の継ぎ手板モデル作成

継ぎ手板モデルと底板モデルは、

3D

モデル作成ソフト

Metasequoia

を使用し、図-2.12 のように通常の手法で作成し、拡張子を

.3ds

としたファイルに保存する。このファイルを

3DS

ＭＡＸ側でインポートし、図-2.13 の要領で

H

型項部位のモデルに継ぎ手板と底板を設置し、

{

アタッチ

}

により、一つの同じオブジェクトとする。このため、合体前のマテリアルは、全ての部位で水色とした。なお、合体後のマテリアルは赤茶色とした。

(a)継ぎ手板の設置 (b)底板の設置 (c)

{

アタッチ

}

コマンド

図-2.13 構成支保工モデルの合体

(16)

(8)鋼管長尺フォアパイリングモデルの作成

鋼管長尺フォアパイリングに相当するポリゴンを他のポリゴンと区別するため四角形に変換し、

鋼管長尺フォアパイリングの打設角に合わせて回転させた後、｛編集可能ポリゴン｝に変換する。変換後、長尺フォアパイリングの打設長に合わせ、打設開始位置を図-2.14 のように単位支保パターンモデルのワールド座標系

y=0.0

に移動する。

図-2.14 鋼管長尺フォアパイリングモデルの作成

(9)各部材モデルの合成

各支保パターンに関連する全てのモデルデータを一つに合成する。鋼製支保工やロックボルト等の支保部材は、設計図に明記された距離に配置する。なお、合成後の単位支保パターンモデルのマテリアルの不透明度などの調整が必要になる。

図-2.15 各部材モデルの合成

(17)

以上のような手順に従い作成した

K

トンネル、および

S

トンネルの単位支保部材モデルを図 -2.16、および図-2.17 にそれぞれ示す。

(a)DⅢa (b)DⅢb (c)DⅠ

(d)DⅠ(series)

(e)CⅠ (f)CⅡb

(g)

CⅡL

(h)

DⅢa(front view)

(i) DⅢa(Bird eye’s view)

図-2.16

K

トンネルの単位支保部材モデル例

(18)

(a)

C

Ⅰ

-2

(b)

C

Ⅱ

-2b

(c)

C

Ⅱ

-2i

(d)C

Ⅱ

-RandL (e)D

Ⅰ

-2b (f)D

Ⅱ

-2

(g)

D

Ⅲ

-2

(h)

D

Ⅲ

-2a

(i)

D

Ⅲ

-2p

(j)

D

Ⅱ

-2

フォアポーリング部拡大 (k)

D

Ⅲ

-2p

ウィングリブ部拡大

図-2.17

S

トンネルの単位支保部材モデル例

(19)

２．３トンネル線形データの作成

トンネル線形データは、トンネルの平面線形、ならびに縦断勾配等の情報を与えるデータで、

GENESIS/THQ

の

RDBMS

機能を利用して、このトンネル線形上に単位支保パターンモデル

を配置することで、３

D

トンネルモデルを形成することができる。

トンネル線形データを作成するために必要な基本データはトンネル中心線のみでよいが、将

来的な

GENESIS/THQ

の機能拡張を考慮し、ここでは、トンネル中心線、道路中心線、トンネ

ル幅、坑口切土形状ならびに計測点もトンネル線形データとしてトンネル平面線形の

CAD

データから取り込むこととした。

トンネル工事で配布されるトンネル平面線形の

CAD

データには、トンネル線形データに必要なデータ以外にも、等高線や土地所有データ等の多様なデータが含まれている。しかし、公共事業で作成される

CAD

データは地物オブジェクト毎に異なるレイヤに作画されているため、

トンネル線形データの作成は比較的容易な作業で行うことが出来る。その作成手順は、以下のようなものである。なお、以下の作業では

CAD

ソフトとして

AutoCAD civil 2011

を使用した。

（１）必要レイヤの抽出

配布された

DWG

形式のトンネル平面線形の

CAD

データを

AutoCAD civil 2011

上で展開すると、図-2.18 のようにトンネル線形以外の多様な情報が画面上に描画される。ここで、図 -2.19 のようにレイヤ情報をもとに、不必要な情報を非表示にし、この状態でファイルを

DXF

形式で保存すると、非表示データは出力されないからファイルは線形データに必要なデータだけが保存されることとなる。

図-2.18

AutoCAD civil 2011

上で展開したトンネル平面

CAD

データ

図-2.20 は、このようにして保存したファイルを、再度、

AutoCAD civil 2011

上で展開した画

面である。図に示されるように、トンネル中心線、道路中心線、トンネル幅、坑口切土形状なら

びに計測点のみが表示されていることが分かる。

(20)

図-2.19 レイヤ選択画面

(a)道路線形全体

（ｂ）トンネル坑口部拡大

図-2.20 トンネル線形データに必要な情報のみを保存したファイル展開画面

(21)

(2)Z 軸情報補正

図-2.19 に示したトンネル線形データに必要な情報のみを保存した

CAD

ファイルは、平面上にトンネル中心線、道路中心線、トンネル幅、坑口切土形状等高線等が描画された二次元データであり、トンネル縦断勾配等の

Z

軸方向の情報が含まれていない。したがって、このままでは立体的なトンネルモデルを作成することはできても、

3

次元プロダクト･データ･モデルとして供すことはできない。

このため、トンネル中心線の

z-

座標をスプリングラインのトンネル縦断勾配に併せて補正する。

この作業は手動で行うしかないが、一般にトンネルの縦断勾配形状は単純なため、さほどの労力を要することはない。図-2.21 に

z-

軸情報を補正後し、単位支保部材モデルを連結したトンネル３

D

モデルを示す。図において、黄土色のマークは切羽観察を実施位置を示し、これをクリックすると、切羽観察情報が現れるといった形で、

GENESIS/THQ

データ管理機能と同様の情報管理機能を持たせるようにしている。

図-2.21

z-

軸情報を補正し、単位支保部材モデルを連結した三次元トンネルモデルの例

(22)

３．トンネル施工管理のためのデータ構造の設計とその入力システム３．１概説

本章では、

GENESIS/THQ(Geo-Engineering Network sensors and Information Synthesis)

上にトンネル施工管理データを展開するための具体的なデータ構造設計とその入力システムの実装を行う。

トンネル施工管理においては、切羽進行データを適切に管理することが最も重要となる。これはトンネル施工に関わるほとんどの作業、および変状等のイベントが切羽進行に付随して発生するためであり、切羽前方、あるいは切羽到着前に何らかの作業やイベントが発生することはほとんどない。したがって、切羽進行データは対象とするトンネルの施工管理データの

Mile

Stone

となり、そのトンネルで発生する全ての作業やイベントは切羽到達位置、あるいは到着日

時との整合性を保って管理されなければならないためである。本章では、トンネル施工管理システムのプラットフォームとなる

GENESIS/THQ

の概要を

3.2

節に示し、

3.3

節において上半切羽進行データ、ならびにこれに付帯する下半切羽、インバート施工、覆工コンクリート施工の進行を管理するデータ構造を設計するとともに、日々これをトンネル施工の現場で管理するためのシステムを実装する。

また、

3.4

節では、トンネル施工管理データの利用例として、切羽観察データ、ならびにこれを基にした岩判定データの検索･処理システムの設計と実装をおこなう。これらのデータは、

NATM

においてトンネル支保パターン等の決定に供せられる最も重要な管理データの一つである。

なお、本章で設計・実装したシステムは、国土交通省東北地方整備局福島河川国道事務所と三井住友建設株式会社栗子トンネル作業所のご協力を得、東北中央自動車道栗子トンネル（山形側工事）をモデルとして作成した。また、実装した機能やユーザーインターフェース等は、三井住友建設株式会社栗子トンネル作業所職員とのディスカッションにより決定したものである。

Appendix A

に東北中央自動車道栗子トンネル（山形側工事）の概要を、また

Appendix B

に栗子トンネル作業所職員とのディスカッションメモを示す。

(23)

３．２ GENESIS/THQ の概要 (1) GENESIS/THQ の基本構造

トンネル施工管理支援システムのプラットフォームとなる

GENESIS/THQ

の基本構造概念を図-3.1 に示す。図において、

A

の仮想空間は

VRML/X3D

によって構築された仮想の地下空間である。この仮想空間内を、ユーザーはマウス等の操作によって視点を制御することで、あたかも歩行するかのように移動することが可能となる。そして、この操作により、求める情報が発生した地点へと移動することとなる。

Genarating Web3D Objects

JAVA Uplet Internet

C: Logic Engine Data

Base

A：4-dimension Virtual Reality Space

B：Interactive Transaction Data Request

図-3.1 システム構造の基本概念図

このとき、この仮想空間が時間情報と連動するならば、仮想空間は指定された日時に応じた形状に変化する。すなわち、指定した日時における掘削延長や施工段階に応じた形状の仮想空間が現出する。

次に、

B

の両矢印は情報処理の要求とその表示を示すものであり、ここでは対話型情報処理を想定している。すなわち、ユーザーは情報を取得したい仮想空間上へ移動したのち、その地点で情報の呼び出しや処理の要求を行うこととなるが、その操作を表したものが

B

の両矢印である。ユーザーから要求を受けると、

C

の情報処理エンジンがデータベース上を検索し、必要な情報を収集するとともに、要求に応じた演算を実施し、その結果を表示する。

このような処理は、検索するデータの主キーとして位置情報、ならびに時間情報を採用し、

RDBMS

との連携を確保することで可能となる。

Internet Browser HTML Pages VRML Plug-in VRML scenes

Web/Application Server

IIS Web Server Web Service

DatBase Data

Service Data

Service

Presentation &

Visualization

Process & Analysis Request

HTML VRML XML

図-3.2 システムのフレームワーク

(24)

以上のようなシステム開発アプローチは図-3.2 のように図化することができる。図に示すように、システムは大きく ①

DataBase

、 ②

Process

＆

Analysis

、ならびに ③

Presentation

＆

Visualization

の機能に分類される。このうち、①および②の機能は

RDBMS

で提供される機能

を援用して具現化され、③は

Web3D

の機能そのものである。

また、システムは

Web

上に構築されるため、各機能間のデータのやり取りは

XML(eXtensible Markup Language)

を介して行うものとした。

XML

を用いることの利点は、簡

単な構文で多様な形式を取り扱えるだけでなく、ネットワーク上で種々のサービスを可能とする点にある。すなわち、リモート経由で他のコンピュータのサービスを呼び出したり、

Web

上でベクター画像の表現を行う等の機能をシステムに実装することが可能となる。

(2) GENESIS/THQ の時間フレームワークとデータベース構造

地下開発に関わる情報には、地質環境や地理情報等のように時間経過にほとんど影響されない情報だけではなく、切羽進行や現場計測データ等のように時間経過に大きく依存する情報も含まれる。静的な情報は、今日の

RDBMS

と親和性が高く、

RDBMS

によって提供される機能をそのまま使用することが可能である。しかしながら、動的な情報に対しては

RDBMS

の機能と時間概念を連動させることのできる機構の設計が必要となる。このため、

GENESIS/THQ

では分散型のタイム･セグメント方式を採用し、これに関連付けたデータベース

構造を考えた。

トンネル施工の場で発生･変化する膨大な情報群をすべてメモリー上にロードし、演算処理することは

CPU

やメモリーに過大な負荷を与え、効率的なデータ処理が困難である。このため、

図-3.3 に示す要領で、時間軸を適当なタイム・セグメントに分割し、必要なデータのみをロードする時間データ構造を採用した。

ti

-∞ ti+1 +∞

si

ti-1 ti+2

si-1 si+1

Segment Initial State

Full Copy I Full copy II

T: time S: time segment

Full copy III

図-3.3 時間情報参照系とタイム・セグメントの分割

すなわち、時間軸を任意のスパンで多数のタイム・セグメントに分割し、各セグメントの初期状態ではその時刻で有効なオブジェクトに関するすべての情報がフルコピーされるものとする。

そして、各タイム・セグメント間で発生する情報の生成･変化･消滅は、その変動だけが記録さ

れるものとする。

(25)

このタイム・セグメント分割において、各タイム・セグメントの間隔は一様である必要はなく、それぞれのタイム・セグメントが持つ情報の特性に応じて、その間隔を定めればよく、またその時間境界も厳密である必要はない。したがって、地下構造物に特有の地質情報、すなわち、地層、地質構造、化石等の地質オブジェクトに関する時間情報管理は地質年代や年代的層序区分等を用いて行うことが可能となる。例えば、カンブリア紀末、ジュラ紀中期等のような表現である。

このような時間区分は正確な時間境界を定義することが難しく、いわば曖昧

(Fuzzy)

な時間概念である。地質年代について言えば、研究者によって地質時間の参照系が異なり、今日もその統一した定義は成されていない。当該システムにおいては、このように曖昧な時間概念に特定の定義付けを行うことなく、曖昧のまま処理することを考えた。ただし、時間軸上における順序の整合性は担保しなければならない。しかし、これも厳密なものではなく、ジュラ紀前期はジュラ紀中期よりも古いというような、常識的な順序が確保されれば良い。

このような時間管理を可能とするためには、データベース上で表記可能な時間領域を大きく取る必要がある。このため、

GENESIS/THQ

では時間情報を表-3.1 のようにダブルや

64

ビット整数によって表記することを提案する。このような標記を用いることの利点は、地質年代を含む広範囲な時間領域の取り扱いを可能とするだけでなく、時間情報と座標データとを同じ数値型で取り扱うことが可能なため、時間データに対して空間データと同じインデックスを用いることができる点にある。

表-3.1 当該システムのデータベース時間表記データタイプ表現可能空間

DATETIME 1000-01-01 00:00:00 to

9999-12-31 23:59:59 DATE 1000-01-01 to 9999-12-31 TIMESTAMP 1970-01-01 00:00:00 to partway t

through the year 2037 TIME -838:59:59 to 838:59:59

(3)GENESIS/THQ のデータモデル定義と SQL によるデータモデルの記述

以上の空間概念と時間概念の定義に従い、地学データの世界をテーマによって分類することを考える。いま、すべての地学テーマは、空間情報

SD(Spatial Data)

、時間的に鋭敏な特性

FCA(Frequently Changing Attribute)

、ならびに時間的に安定な特性

SA(Stable Attribute)

の関係ス

キーマ

(Relation Scheme)

によって記述されるものとし、それぞれのテーブルが次のような見出

し

(Heading)

を持つものとする。

SD(OID, SD, SMBB, TMBB) FCA(OID , TMBB, A) SA(OID , TMBB, A)

(26)

すなわち、

SD

、

FCA

、ならびに

SA

は

OID(Object Identifier)

、

SMBB(Spatial Minimum Bounding Box)

、

TMBB(Temporal Minimum Bounding Box)

、および

A(Attribute)

の変数群によって表現されるものと考える。ここで

OID

は、地学オブジェクトの

ID

であり、関係データモデルの関係の主キーとなる。また、

SMBB

と

TMBB

は

SD

を表記する上で最小限必要な空間領域、ならびに時間領域をそれぞれ規定する外部キーである。

さらに、

A

は地学データの属性を示す変数であるが、

FCA

と

SA

とでその属性は異なり、互いに排他的な属性変数が用いられることに注意が必要である。これは、一つの地学オブジェクトに対して、静的な情報と動的な情報とに分離されるためであり、いうまでもなく静的な情報は

SA

の属性となり、動的な情報は

FCA

の属性となる。たとえば、任意の位置に設置された計測センサーの空間位置は静的な属性であるが、その測定された値は動的な属性である。また、

坑道内を移動する車両の空間位置は動的な属性であり、車両の運転者は静的な属性である。

これらの例にみられるように、同じ空間位置でも地学オブジェクトによって、動的属性になったり、静的属性になったりすることに注意が必要である。

また、このように静的な属性と動的な属性を峻別して情報管理することの利点は、動的な属性の変化だけを更新することで任意の地学オブジェクトの変化を記述することにあり、データ

の冗長

(Redundancy)

を減少することが可能な点にある。

(4)検索演算

前節に示したデータモデルの記述を用いれば、以下のような検索演算が可能となる。今、

現場計測データのうちから、オブジェクト

ID=1

の測定機器が

2007

年

1

月

1

日

(Ts)

から

2007

年

12

月

31

日

(Te)

の間に測定したデータを選択する問題を考える。このとき、時間区間を

tj=20070101，_t_j+1_=20071231

とすると、以下の操作によってそれぞれのテーブルでこの条件に該当する要素を抽出することができる。すなわち、

SA SA

SA

FCA FCA

FCA

SD SD

SD

tj tj TMBB OID

tj tj

tj tj TMBB OID

tj tj

tj tj TMBB OID

tj tj

] 1 , [ ]

1 [ 1

] 1 , [

] 1 , [ ]

1 [ 1

] 1 , [

] 1 , [ ]

1 [ 1

] 1 , [

















(1)

ここで、

Aｋ_[m,m+1]

はテーブル

A

のうち、

OID=1

かつ

m≦_TMBB≦_m+1

の期間内にある要素の集合を示す。また、

δ_L[nn]A

は、テーブル

A

において見出し

L

の条件

[nn]

に適合する要素を抽出する演算子を、また○

^×

は自然結合の演算子を示す。

このように抽出された要素群を、さらに次式のように自然結合することで、目的とするデータ

の選択が可能となる。

(27)

T^C SD_[¹_tj_,_tj_₁_]FCA_[¹_tj_,_tj_₁_]SA_[¹_tj_,_tj_₁_] (2)

上記のように、すべての地学テーマを空間情報

SD

、時間的に鋭敏な特性

FCA

、ならびに時間的に安定な特性

SA

の関係スキーマによって記述することにより、

FCA

のみに動的な情報が記述されることになり、データ構造が非常に単純化される。このデータ構造では、データ選択作業に複数以上の段階を要することになるが、データ構造が単純なためテーブル結合操作も単純化され、テーブル結合操作によるシステム性能低下を回避し得るものと考える。

は幾何学データ

SD,

時間変化する特性

FCA,

ならびに時間的に静的な特性

SA

の一次結合

として表すことができる。したがって、本研究で設計したデータベース構造を仮想空間構築に

適用することが可能となる。この考えに従えば、ユーザーは必要な幾何学ユニットをデータベ

ースから抽出し、それらを組み合わせることで所要の仮想空間を構築することが可能となる。

(28)

３．３トンネル進行管理データの構造

3.3.1 トンネル進行管理のための XML ファイル

GENESIS/THQ

上でトンネル進行管理を行うことは、時間的に鋭敏な特性

FCA(Frequently

Changing Attribute)

を作成することに他ならない。すなわち、

FCA

を同定する因子

OID(Object Identifier)

、

TMBB(Temporal Minimum Bounding Box)

、および

A(Attribute)

を、トンネル施工に応じて入力することとなる。

一般に、トンネル進行管理は、一般に上半切羽の到達日時によって管理されが、包括的にトンネル施工管理を行うためには、これに随伴して施工される下半切羽進行やインバート施工、

覆工コンクリート施工も正しく管理しなければならない。ここでは、これらを加背進行やイベントを個別の

XML

管理することとし、実務的にはトンネル進行に合わせて、各

XML

ファイルを入力・作成・保存するシステムを考えた。表-3.2 に、実際に作成する

XML

ファイルとその格納フォルダの一覧を示す。なお、表-3.2 には、トンネル施工管理データの利用例として実装する切羽観察データの

XML

ファイルも併せて示している。

表-3.2 トンネル進行管理のために作成される

XML

ファイルとその格納フォルダ

加背割/イベント XMLファイル格納上半掘削 upperHalf.xml xml/upperHalfフォルダ下半掘削 lowerHalf.xml xml/lowerHalfフォルダ

全面 invert.xml xml/invertフォルダ左側 invertL.xml xml/invertLfフォルダインバート掘削

右側 invertR.xml xml/invertRフォルダ覆工コンクリート lining.xml xml/liningフォルダ切羽観察 workingFace.xml xml/workingFaceフォルダ

表-3.3 既存の切羽進行管理ファイルサンプル

掘削進捗率

日進累計日進累計日進累計 ^{（上半分とする）}

（ｍ）（ｍ） STA. + （ｍ）（ｍ） STA. + （ｍ）（ｍ） STA. + （％）

月日曜日支保工 No. 支保工 No. 支保工 No.

1.0 4.0 No.5 3.0 7.0

No.8 3.0 10.0 No.11

ｲﾝﾊﾞｰﾄ吹付け

STA.201+45.0

距離程

上半距離程下半距離程

STA.201+42.0

備　　　　考

0.66 STA.201+49.0

昼・夜方掘削 F-Sﾎﾞﾙﾄ　N=11本支保

ﾊﾟﾀｰﾝ

ＤⅢa-A

25 平成21年

月

火 8

水 8 26

STA.201+49.0 ＤⅢa-A

STA.201+39.0

STA.201+49.0

STA.201+49.0 24

8

0.27

ＤⅢa-A 0.46

STA.201+49.0

表-3.3 は、今日、一般的に作成される切羽管理ファイルの例を示したものである。掘削工法等によって若干の違いはあるが、表-3.3 に示されるように各加背毎にその日の進行長と累計延長が示される。上半掘削の進行は、支保工の基数から（支保工基数×支保工間距離）で日掘削長を計算することもあるが、支保パターン変更点や突発的な切羽変状等で支保鋼管距離が調整されることがあるため、累計の施工延長は必ず距離低で管理される必要がある。

表-3.3 を例に、各

XML

ファイルの構造を以下に示す。

(29)

（１）上半掘削進行管理 XML ファイル

表-3.3 中の

2009

年

8

月

24

日の上半掘削進行管理

XML

ファイルが平成

21

年（

2009

年）

8

月

24

日

8:00:00

時点の進行データであるとすると、この

XML

ファイルは

20090824080000.xml

として保存される。すなわち、入力時の西暦年月日時分秒を

first name

とする

XML

ファイルが

xml/upperHalf

フォルダ内に作成される。この

XML

ファイルの構造は図-3.4 に示すものであ

る。

<?xml version="1.0" encoding="utf-8"?>

</tunnelProgress>

図-3.4 上半掘削進行管理

XML

ファイルの構造

図-3.4 において、

タグは、トンネル進行を示すタグであり、その属性は表 -3.4 に示すものである。また、

タグは、入力年月日、曜日、ならびに時刻を、

タグは、対象とする区間の支保パターンをそれぞれ管理するタグである。さら

に、

タグは、当該入力時における備考を管理するタグであり、表-3.3 の備考欄に対

応する。

表-3.4

タグの属性

id 入力ID番号。各加背割り、もしくはイベント毎にユニークであること。

type 上半掘削を示すコード =”upperHalf”

progress 各入力における進行距離

total 累計の進行距離

RoadDistanceNo 入力時の最終進行のステーション番号 RoadDistanceDelt 入力時の最終進行のステーション内距離

daytime 入力時刻yyyy(西暦年4桁)mm（月2桁）dd（日2桁）hh（時2桁）mm（分2桁）ss（秒2桁）

（２）下半掘削進行管理 XML ファイル

下半掘削進行管理

XML

ファイルの構造を図-3.5 に示す。図に示すように、下半掘削進行管理

XML

ファイルは、上半掘削進行管理

XML

ファイルから

タグ、

タグ、ならびに

タグを省いたものであり、

タブと

<timeAndDay

>

タグだけで構成されており、

タブの属性は表-3.5 に示しすものである。また、

ファイル名も上半掘削進行管理

XML

ファイルと同一の名付け方を採用した。

</tunnelProgress>

図-3.5 下半掘削進行管理

XML

ファイルの構造

(30)

表-3.5

タグの属性

type 下半掘削を示すコード =”lowerHalf”

RoadDistanceNo 入力時の最終進行のステーション番号 RoadDistanceDelt 入力時の最終進行のステーション内距離

（３）インバート施工管理 XML ファイル

トンネル施工において、インバート施工の進捗は最も管理が難しい工種である。これは、インバート施工の進捗が一方向に進むのではなく、切羽側から坑口側に向けて施工されることもあれば、飛び飛びに施工されることもあるためである。また、左右別々に施工されることもある。

このように複雑なインバート施工を管理するためには、当該入力におけるインバート施工の開始位置と終了位置、および全断面施工、左右分割施工の違いを把握しなければならない。

これをできるだけ簡便に効率よく管理するためのインバート施工管理

XML

ファイルの構造を考えた。図-3.6 にインバート施工管理

XML

ファイルの構造を、また表-3.6 に

の属性を示す。

< tunnelProgress id="0" type=”invert” progress = "2" total=”24” fromNo=”201” fromMeter=”25” endNo=”201” endMeter=”23”

dayTime=”20090922080000” >

</tunnelProgress >

図-3.6 インバート施工管理 XML ファイルの構造

表-3.6 インバート施工管理 XML ファイル

タグの属性

invert インバート全断面施工 invertL インバート左断面施工

type インバート施工の種別

invertR インバート左断面施工 progress 各入力における進行距離

fromNo 入力時のインバート施工開始点のステーション番号 fromMeter 入力時のインバート施工開始点のステーション内距離

endNo 入力時のインバート施工終了点のステーション番号

endMeter 入力時のインバート施工終了点のステーション内距離

図-3.6 に示すように、インバート施工管理

XML

ファイルは、下半掘削進行管理

XML

の

<tunnelProgress>タグに、fromNo・fromMeter

属性、と

endNo・endMeter

属性を追加した構造と

なっており、これらはぞれぞれ入力時のインバート施工開始点と終了点のステーション番号、

ならびにステーション内での距離を管理する属性である。

また、type 属性はインバート施工の種別に応じて、invert(全断面インバート掘削)、invertL（左

(31)

断面インバート施工）、

invertR

（右断面インバート施工）に分類される。この

fromNo

・

fromMeter

属性、

endNo

・

endMeter

属性、および

type

属性により、複雑なインバート施工を柔軟に管理す

ることが可能となる。なお、ファイル名は他の加背割りと同一の名付け方を採用した。

（４）覆工コンクリート施工管理ファイル

覆工コンクリートの施工管理は、インバート施工ほど複雑ではないが、非常駐車帯区間等で施工順序が変更になる場合があるため、注意を要する。このため、インバート施工管理ファイルの構造を参考に覆工コンクリート構造の施工管理ファイル構造を作成した。図-3.7 に覆工コンクリート施工管理

XML

ファイルの構造を、また表-3.7 に

の属性を示す。

<tunnelProgress id="0" type="lining" liningNo ="1" progress = "3" total="3" fromNo="201" fromMeter="49" endNo="201" endMeter="46"

dayTime="20090907080000"/>

図-3.7 覆工施工管理 XML ファイルの構造

表-3.7 覆工施工管理 XML ファイル

タグの属性

type 覆工施工を示すコード =”lining”

fromNo 入力時の覆工施工開始点のステーション番号

fromMeter 入力時の覆工施工開始点のステーション内距離

endNo 入力時の覆工施工終了点のステーション番号

endMeter 入力時の覆工施工終了点のステーション内距離

図-3.7、表-3.7 に示されるように覆工施工管理

XML

ファイルでは、インバート施工管理

XML

ファイルにおいて採用した

fromNo

・

fromMeter

属性、

endNo

・

endMeter

属性の概念を踏襲した。

これにより非常駐車帯区間等で施工順序が変更になる場合でも柔軟に管理することが可能となった。なお、ファイル名は他の加背割りと同一の名付け方を採用した。

3.3.2 トンネル進行管理 XML ファイルのデータクラス

図-3.8 に、トンネル進行管理

XML

ファイルのデータクラス図を示す。図中で赤く囲まれた箇所にある

upperHalf, lowerHalf, lining, invert, invertL, invertR

の

XML

ファイルは、

3.2.2

節で記したトンネル進行を管理するための

XML

ファイル単体を示すものであり、それぞれのファイルには一回分で入力された進行データが記録されている。既に述べたように、これらのファイル名には入力時の日時間(datyTime 要素)が付与されることに注意が必要である。

また、青く囲まれた箇所にある

upperHalfAll, lowerHalfAll, liningAll, invertAll, invertLAll,

invertRAll

の

XML

ファイルは赤い枠中の各データにおいて、プログラム上でよく使うデータを

(32)

抽出し保存したファイルである。この

Class

を設けることにより、プログラムによる検索･処理が大幅に効率化することが可能となる。

図-3.8 トンネル進行管理のための

XML

ファイル群クラス図

さらに、緑枠中の

tunnelData

は、第

2

章で述べたトンネル

3

次元

CG

モデルを管理する

XML

ファイルで、その

patsType

要素には青枠内にある

XML

室蘭工業大学大学院 工学研究科

トンネルのライフサイクルマネージメントに 供するプロダクトデータモデルの研究

トンネルのライフサイクルマネージメントに 供するプロダクトデータモデルの研究

第２０１０-１３号