【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、オブジェクトを階層構造にしてプロダクトモデルとプロセスモデルを合わせて構築したプロジェクトモデルを核とする統合的生産プロジェクト情報管理システムに関する。

【０００２】

【従来の技術】計画から設計、施工を経て施設の管理に至る建設プロジェクトのライフサイクルの中で、膨大な量の情報が作られ利用されている。 このような建設プロジェクトの実現に際しては、個々の担当者が各々の視点・役割分担からこれらのプロジェクトデータを共有し維持しているが、それぞれの業務が複雑に絡み合い、情報の共有化は非常に困難な問題である。 というのも、このプロジェクトデータは、プロジェクトの進捗に従い個々の担当者の情報に対する視点によって蓄積され、検索され、計算され、更新されていくからである。

【０００３】建築生産システムの高度化を実現してゆくために、工業化・複合化・自動化生産等の建築生産技術の革新と共に、上記のような生産に係わる情報を各建設プロジェクトの規模や形態に合わせて管理し、設計・計画・管理を統合的に支援してゆくシステムの構築が必要とされる。 このようなシステムは、建築生産に係わる情報をコンピュータを利用して一元的に管理できると共に、生産の各段階で発生する生産情報を適宜次工程に伝達してゆくことを目的とするものであり、新しい設計と施工の機能分担に基づく建築生産の枠組みの送出を目指すものでなければならない。

【０００４】

【発明が解決しようとする課題】上記のような状況の中で、各種のＣＡＤシステムや解析システム、シミュレーションシステム等のコンピュータシステムが建設各社によって開発、導入されている。 しかしながら、それらのシステムの多くは、非常に狭いアプリケーション領域の中でのみ有効であり、各領域間の情報の伝達は、それらのアプリケーションのリンクによって実現されているのが実情である。 したがって、異なる領域で業務を行っている担当者間でのプロジェクトデータの交換は、十分に行われているとは言いがたい。

【０００５】本発明は、上記の課題を解決するものであって、建築生産における情報の一元管理と建築生産の高度化、統合化を実現することができ、建物に関するプロダクトモデルの独立性を保ち、生産業務内での業務内容や組織の変更、システムの変更等にも柔軟に対応できる統合的生産プロジェクト情報管理システムを提供することを目的とするものである。

【０００６】

【課題を解決するための手段】そのために本発明の統合的生産プロジェクト情報管理システムは、物理的な要素や機能的な要素を用いて製品を定義したプロダクトモデルと製品に関する業務を定義したプロセスモデルとを合わせ、かつプロセスモデルの中を業務に沿ったビューで階層構造のオブジェクトとして記述して構築したプロジェクトモデル、該プロジェクトモデルと他のシステムやデータベースとのインターフェース、及びユーザインターフェースを備えたことを特徴とする。

【０００７】また、オブジェクトは、単純にデータを持つデータオブジェクト、次に見にゆく関数が入るスコープビューオブジェクト、他のオブジェクトの評価を行うエバリュエイトビューオブジェクト、及び新たなオブジェクトをつくり出すことができるクリエイトビューオブジェクトのタイプを有することを特徴とし、プロセスモデルの中に各業務を遂行する上で必要とされる個別情報と共にプロダクトモデルのデータから必要情報を取り出してくる情報参照の方法や実際に業務と関連するアプリケーション等をスロットの値として埋め込むようにしたことを特徴とする。

【０００８】さらに、制約条件の視点を有し、他のビューへ継承するための値をスロットに持つようにし、ビューへのアクセス権をリストの関数で記述してビュー単位で当該ビューより下層のビューへアクセスできるように構成し、アプリケーションをスロットに関数として埋め込み起動できるように構成したことを特徴とする。

【０００９】そして、プロジェクト全体を管理する管理ビュー、プロジェクト情報を蓄積する概要情報ビューを有することを特徴とするものである。

【００１０】

【作用】本発明の統合的生産プロジェクト情報管理システムでは、製品を定義したプロダクトモデルと業務に沿ったビューで階層構造のオブジェクトとして記述したプロセスモデルとを合わせて構築したプロジェクトモデルを核としてシステムが構成されるので、プロダクトモデルとプロセスの間の独立性を保つことができ、プロダクトモデルの設計が容易になる。 しかも、プロセスモデルは、業務に沿ったビューで階層構造のオブジェクトとして記述されているので、それぞれがデータと各種の関数等を持つことができ、業務に応じた必要な情報のアクセス、利用を有機的に行うことができる。

【００１１】また、オブジェクトは、単純にデータを持つデータオブジェクト、次に見にゆく関数が入るスコープビューオブジェクト、他のオブジェクトの評価を行うエバリュエイトビューオブジェクト、及び新たなオブジェクトをつくり出すことができるクリエイトビューオブジェクトのタイプを有し、プロセスモデルの中に各業務を遂行する上で必要とされる個別情報と共にプロダクトモデルのデータから必要情報を取り出してくる情報参照の方法や実際に業務と関連するアプリケーション等をスロットの値として埋め込むので、建設施設の生産業務の中で幅広く応用できるプロジェクトモデルを構築し、協調的設計・施工計画の環境を実現することができる。

【００１２】さらに、制約条件のビューを有し、他のビューへ継承するための値をスロットに持つようにし、ビューへのアクセス権をリストの関数で記述してビュー単位で当該ビューより下層のビューへアクセスできるように構成したので、制約条件が上位から伝播され、モデルの中で受渡しをして管理を行うことができ、アプリケーションをスロットに関数として埋め込み起動できるように構成したので、ユーザがあるビューに入ってアプリケーションを動かしその結果を見ることもできる。 そして、プロジェクト全体を管理する管理ビュー、プロジェクト情報を蓄積する概要情報ビューを有するので、より広範な情報を表現することができる。

【００１３】

【実施例】以下、図面を参照して本発明の実施例を説明する。

【００１４】図１は本発明に係る統合的生産プロジェクト情報管理システムの１実施例を示す図である。

【００１５】本発明の統合的生産プロジェクト情報管理システムは、図１に示すように多視点をもつオブジェクト指向建物モデル１をその核として構成したものであり、多視点をもつオブジェクト指向建物モデル１は、オブジェクトの固まり毎に区分けして階層構造で作ったプロセスモデルとプロダクトモデルを合わせて１つのプロジェクトを表現したプロジェクトモデルである。

【００１６】従来のコンピュータシステムでは、プログラムとデータがあり、データを使ってプログラムが処理を行っているが、本発明のオブジェクトの考え方は、この考え方と違って対象物を１つのオブジェクトとするものである。 例えば人間が食事をするというのを１つのオブジェクトと定義すれば、人間と食事をする動作と何を食べるというデータが１つの固まりの中に入って、それをオブジェクトという。 したがって、オブジェクトは、
様々なデータを持ったりプログラムを内蔵したりする機能を持ったものである。

【００１７】１つのオブジェクトは、データの定義の項目として複数のスロットをもち、スロットの値は、アトム、シンボル、リストという形式で表現される。 例えばＡや１０の数字はアトムで表現され、名前のようなキャラクタ列はシンボルやストリングで表現され、複数のデータ関数や式はカッコを使ってリスト式で表現される。
例えばクライアントの名前や住所は、表現の仕方によってリストになったりアトムになったりし、この持ち方次第で属性が変わる。 また、メソッドは、オブジェクトやフレーム構造の中で何をしなさいというような定義された関数的な手続きをいう。

【００１８】例えばＣｌｉｅｎｔｓ１（施主１）は、一種のオブジェクトでフレームとも呼ぶが、この中に得意先の名前や、住所、業務、資本金、企業グループ等の情報がある。 これらの名前をスロットといい、それぞれのスロットに値が対応するが、その値が文字列であればストリングであり、複数の情報が入ってくればリスト式で表現する。 これらを１つの固まりとしてオブジェクトとしてとらえ、この単位で処理を行う。 したがって、各オブジェクト毎に項目を定義して項目の値を与えてやると、ここで１つのオブジェクトが完成する。

【００１９】また、本発明のモデルでは、オブジェクトをそれぞれの機能を明確にするためグループ化している。 オブジェクトのタイプは、単純にデータしか持っていないデータオブジェクトと、次に何を見にいきなさいというような関数が入っているスコープビューオブジェクトと、他のオブジェクトをシミュレーションしたりしてエキスパートシステムでいわれている評価を行うことができるエバリュエイトビューオブジェクトと、新たにオブジェクトを作りだせるようなクリエイトビューオブジェクトの４つに分けている。 したがって、オブジェクトは、階層構造を作ると、上から下へこの情報を自動的に属性継承することができ、この機能を使って制約条件を継承することができる。

【００２０】プロダクトモデルは、建物を柱や梁等の物理的な要素と、階や部屋等の機能的な要素とを用いて製品モデルとして定義し、プロセスモデルは、各生産業務を分析し業務モデルとして定義したものである。 本発明は、このモデルによりデータ入力部分やアプリケーションの領域を限定せずに、建設施設の生産業務の中で幅広く応用できるプロジェクトモデルを構築し、協調的設計・施工計画の環境を実現するものである。

【００２１】ＣＡＤシステム２は、柱や梁 壁、部屋等を定義するインターフェース、建物モデルに設計情報を提供するためのファイルを作成するファイルインターフェース、施工性を評価するエキスパートシステムに設計情報を提供するためのファイルを作成するファイルインターフェース等、各種のインターフェースを有するものである。

【００２２】サブシステム３は、幾つかのエキスパートシステムその他のアプリケーションからなるものである。 そのエキスパートシステムの１つは、例えばオブジェクト指向建物モデル１の各業務段階で利用し得る最新の情報を利用して建築生産の流れに応じて概算の工期を評価し算定するシステムであり、情報が不足している場合にはユーザにデータを要求する。 このシステムは、単独で利用できると共に、プロセスモデルのオブジェクトの中からも自動的にデータを利用できるようにするものである。

【００２３】また、他のエキスパートシステムは、オブジェクト指向建物モデル１の情報を利用して施工計画作成を支援するシステムであり、施工計画用ビューの中から利用されたときには、オブジェクト指向建物モデル１
が自動的にプロダクトモデルから情報を取り出し、それぞれのシステム用にサブモデルを作成し、システムに起動をかける。 このシステムが単独で利用される場合には、システムのメニューからサブモデルだけを作成できるようになっている。

【００２４】リレーショナルデータベース４は、各建築部材の仕上げ用コスト情報、得意先情報、過去実績情報、人事情報等がテキスト的に格納されており、オブジェクト指向建物モデル１との間でインターフェースによりオブジェクト指向建物モデル１の中に取り込まれ、各種の業務で利用できるように構成される。

【００２５】ユーザインターフェース５は、ユーザの宣言する業務に応じた階層構造のビューへのアクセスを制御するものである。

【００２６】次に、オブジェクト指向建物モデルについて説明する。 図２は本発明で採用されるプロジェクトモデルの階層図、図３は各ビューの下位に展開したモデル階層図である。

【００２７】プロジェクトモデルは、図２に示すようにプロジェクト単位にあって、一般的ビュー、プロセスモデルの部分のプロジェクトビュー、プロダクトモデルの部分の建物ビューがある。 この場合、１つのプロジェクトで複数の棟を建てる場合もあるが、１つの棟でも複数の案を立てなければならない場合もあるので、この固まりはいくつも作れる構造になっている。

【００２８】一般的ビューは、社会的ビュー、単価ビュー、労務ビューのように世間一般の動向が入っている情報群からなるものであり、そのうち、例えば単価ビューの下には、図３（イ）に示すように概要単価ビュー、詳細単価ビューがあり、さらに詳細単価ビューの下にも仕上げ単価ビュー等が下層情報としてある。

【００２９】プロジェクトビューは、管理者用ビュー、
概要情報ビュー、企画担当者用ビュー、営業担当者用ビュー等があり、１個１個がオブジェクトビューとして定義され、さらにその下層にも図３（イ）乃至（ト）に示すように適宜ビューが定義される。 このように業務の流れに合わせて担当者がいて、それぞれの視点をもって業務を行うような構成となっている。

【００３０】建物ビュー（建物そのものを表すプロダクトモデルの部分）は、図３（チ）に示すように建物１、
建物２の名の下に柱や壁、梁等が定義されていて、実際の個々のプロジェクトに合わせて情報が入っている。

【００３１】ビューは、プロセスモデルの中で業務に沿って１つ１つがオブジェクトとして定義された視点である。 例えば管理者用ビューというのは、図３（ロ）に示すように管理者用での視点があって、その視点での１つのオブジェクトと考えられ、さらにそのオブジェクトの下にはいろいろなビューが考えられる。 すなわち管理者の観点によれば、戦略的に、進捗状況をみることもあり、費用管理、組織管理、リスクというビューがサブビュー、つまり下層の情報として展開される。 同様に概要情報ビューは同（ハ）、企画担当者用ビューは同（ニ）、営業担当者用ビューは同（ホ）、設計担当者用ビューは同（ヘ）、施工担当者用ビューと同（ト）にそれぞれ示されているようにそれぞれの観点から下層のビューが展開される。

【００３２】また、１つのプロジェクトで複数の棟をたてる場合もあるが、１つの棟でも複数の案をたてなければならない場合もあるので、プロダクトモデルの固まりはいくつもつくれるような構造になっている。 それはプロジェクトの進み方によって先に述べたクリエイトオブジェクトビューを使って作られる。 例えば施工者用のビューであれば施工計画と施工管理の視点があり、施工計画の下には、例えば構工法や作業計画、それぞれの視点があって、進捗状況によってとってくるデータが変わり評価が変わる。 施工担当者用ビューの場合には、図３
（ト）に示すようにこの下で、施工計画と施工管理に分けてあり、さらにその下にそれぞれ施工計画と施工管理の階層構造が作られる。 このように施工計画と管理の業務に対応した視点が用意してあるが、実際のプロジェクトによっては使われないものもある。 また、これらの視点以外のことを行う場合には、建物の用途によって例えばユーザが自分で実際にこのデータをどの組み合わせで見たいかを定義し、新しくオブジェクト視点を造ることもできる。 これが先に述べたクリエイトオブジェクトビューであり、新しくオブジェクトをつくる機能の最も大きなものである。

【００３３】プロダクトモデルは、コンピュータ上で製品をモデル化する時に現実に製造業で使われている言葉であり、実際に最終的な製品が３次元のデータ構造でコンピュータ上にモデル化されたものをそう呼んでいる。
本発明は、先に述べたように建築物の建物そのものを製造業と同じプロダクトモデルという考え方で表すと同時に、建築物ができるまでの過程、つまり営業から、企画設計、見積、施工という、その流れを一種の業務のモデルとしてプロセスモデルという考え方で表している。

【００３４】すなわち、プロダクトモデルは、建物そのものを例えば柱や梁の表現でモデル化し、プロセスモデルは、実際にフロアがあった時に、意匠設計、アーキテクトの人はどうこの建物をみるか、構造設計の人はどうみるか、それぞれの業務に応じてこの建物をどうみるかという視点でプロセスのモデルを定義している。 これが本発明の特徴である。

【００３５】さらに、具体的な例によりビューの構成やビューへのアクセスについて説明する。 図４は管理者用ビューと概要情報ビューの具体的な構成例及び制約条件の継承関係の例を示す図である。

【００３６】管理者用ビューの建物モデル階層図は図３
（ロ）で説明したが、さらに具体的な例で説明すると、
例えば図４（イ）に示すように管理者用（Ｍａｎａｇｅ
ｍｅｎｔ）ビューの中には、戦略的（Ｓｔｒａｔｅｇｉ
ｃ）ビュー、進捗状況（Ｐｒｏｇｒｅｓｓ）ビュー、コスト（Ｐｒｏｊｅｃｔ Ｃｏｓｔ）ビュー、組織（Ｐｒ
ｏｊｅｃｔ Ｏｒｇａｎｉｚａｔｉｏｎ）ビュー、リスク（ＰｒｏｊｅｃｔＲｉｓｋ）ビュー、制約条件（Ｃｏ
ｎｓｔｒａｉｎｔｓ）ビューがある。 さらに、戦略的ビューの下には、技術戦略と管理戦略の各ビューがあり、
技術戦略ビューでは、新しい構工法や、新素材、新建築、ロボット、情報技術等の各ビューがある。 下の進捗状況ビューは、例えば企画設計段階で評価する中途の得意先からの要求工期や、さらに設計が終わった段階で施工に入る前に施工計画をたててフィックスする工期の情報があり、これに対応する値がスロットに関数で入っている。 このようにそれぞれの進捗状況でどのデータを使ってどういうルールで評価するかが適宜ビューの中に関数として埋め込んである。 これに対し、進捗状況ビューは、項目と値を対応してもっているが下層のビューはない。 コストビューも同様であり、全体の予算があって、
土地取得コスト、建物コスト、設計コスト、施工コストに分かれていて、さらにアザーコストがあり、それらが連動するように構成されている。

【００３７】上記のように中間のビューはサブオブジェクトであって、自分でスロットとデータを持ちながらかつ下層情報も持ち、スロットを持っていない場合もあるが、最後のビューはスロットを持っている。 そして、ブロジェクトが限定された時に、他の評価項目からここを参照し、このプロジェクトがどれを採用するか評価システムが動くように構成されている。

【００３８】また、図４（ロ）に示すようにプロジェクトビューには、プロジェクトコードと名前とスタートデート、エンドデートが書いてある。 そして、この下位のビューの１つとして概要情報（Ｇｅｎｅｒａｌ）ビューがあり、さらにその下には得意先（Ｐｒｏｊｅｃｔ Ｃ
ｌｉｅｎｔ）ビューがある。 ここは値として例えばクライアントが何人かが入り、複数のクライアントであればこの数が２とか３とか４になる。 この数に対応して自分の下層情報の数が決まり、数が決まれば自動的にその情報が作られる。 例えばクライアントが１人であれば１つだけ下層情報を持ってクライアントに関する情報を持ち、３人であれば３つの下層情報を持ってそれぞれのクライアントに関する情報を持つ。 この機能もオブジェクトが持っている。 敷地ビュー（Ｐｒｊｅｃｔ Ｓｉｔｅ
Ｖｉｅｗ）についても、敷地の情報があると同時に、
さらに敷地の地盤の情報とか近隣の情報、特殊の法規とかの情報をこの下層情報として持つ。

【００３９】制約条件では、図４（ハ）に示すように例えば構造設計用制約条件ビュー（Ｓｔｒｕｃｔｕｒｅ
Ｃｏｎｓｔｒａｉｎｔｓ Ｖｉｅｗ）であれば、概要情報ビュー（Ｇｅｎｅｒａｌ Ｖｉｅｗ）の制約条件ビュー（Ｐｒｏｊｅｃｔ Ｃｏｎｓｔｒａｉｎｔｓ Ｖｉｅ
ｗ）や設計担当者用ビュー（Ｄｅｓｉｇｎ Ｖｉｅｗ）
の設計業務用制約条件ビュー（Ｄｅｓｉｇｎ Ｃｏｎｓ
ｔｒａｉｎｔｓ Ｖｉｅｗ）等、上位のビューにアクセスするための値をスロットに持っている。

【００４０】このように概要情報ビューの中にプロジェクトの制約条件があるが、それが継承され例えば敷地や得意先が決まると、設計に対する制約条件がつくられてしまう。 つまり、どういうことを基に設計するか、さらに設計が進んでゆくと、その設計内容のもとに施工側に対してどういう条件で施工するか、という制約条件がどんどんできてくる。 あるところで例えば工期がオーバーしたりコストがオーバーしたりすると、それをもどして考えなければならなくなる。 この場合、制約条件のビューを持っているため、内部的に例えばこれは営業から設計見積り施工まで関連する制約条件であることがスロットの値として入るようになり、これをモデルの中で受渡しをして制約条件の管理を行う。 例えば設計のビューでは、企画設計があり、意匠、構造、設備、電気、それから全体をコーディネーションするビュー、及びそれぞれの間で競合するものがあったときにコーディネーションするビュー等があり、あとは制約条件が上位から伝播されてくる。

【００４１】次に、ユーザのアクセスについて説明する。 図５はユーザーのアクセス権定義を含む建物モデルの利用フローを示す図である。

【００４２】本発明の統合的生産プロジェクト情報管理システムでは、建設業務の流れをモデル化したプロセスモデルと、建物の構成要素をモデル化したプロダクトモデルによって構成されているため、各ユーザが簡単に自分の業務を遂行でき、必要な他の業務の情報を検索でき、モデルそのもののセキュリティー管理を簡単に行うことができる。 アクセス権は、そのためにシステムが各ユーザに合わせて設定しているものである。

【００４３】システムのアクセスに際しては、図５
（イ）に示すようにユーザが、まず、プロジェクトコード、プロジェクト名を入力し、（ロ）に示すような表示画面より「プロジェクトマネージャー」等のユーザ業務を定義する。 そして、参照のみか書き替え（更新）のいずれか、アクセス条件を設定する。 ここまでの設定が行われると、システムは、アクセス条件にしたがってアクセス可能構造を定義し、アクセスできるデータを提示する。 これにより、直接データ処理や属性継承によるデータ処理、各種アプリケーションによるデータ処理、各種エキスパートシステムによるデータ処理、データベースの利用等、メニュー形式によるデータへのアクセスを行う。

【００４４】参照モードでのユーザのアクセス権は、例えば次のように定義される。 プロジェクト管理者であればプロジェクト以下のすべてのビュー、営業担当者であれば一般的ビュー、管理者用ビュー、概要情報ビュー及び営業担当者用ビュー以下のすべてのビュー、主任設計者であれば一般的ビュー、概要情報ビュー及び設計担当者用ビュー以下のすべてのビュー、見積担当者であれば概要情報ビュー及び見積担当者用ビュー以下のすべてのビュー、施工担当者であれば施工担当者用ビュー以下のすべてのビュー、メンテナンス担当者であればメンテナンス担当者用ビュー以下のすべてのビュー、施主であれば、一般的ビュー、管理者ビュー、概要情報ビューの一部及び施設管理担当者用ビュー以下のすべてのビューが参照モードでアクセスできる。

【００４５】また、更新モードでのユーザのアクセス権は、例えば次のように定義される。 プロジェクト管理者であればプロジェクト以下のすべてのビュー、営業担当者であれば管理者用ビュー、概要情報ビュー及び営業担当者用ビュー以下のすべてのビュー、主任設計者であれば設計担当者用ビュー以下のすべてのビュー、見積担当者であれば見積担当者用ビュー以下のすべてのビュー、
施工担当者であれば施工担当者用ビュー以下の一部のビュー、メンテナンス担当者であればメンテナンス担当者用ビュー以下のすべてのビューが参照モードでアクセスできる。

【００４６】ユーザインタフェイスからモデルのどこ（ビュー）へ入れるかは、ビューのリストの関数で記述される。 例えば営業の人間であれば営業がとってきた情報は自分で加えることができるが、設計内容について営業が直接変更を加えたりすることはできないようになっている。 実際にデータを取り込むには、グラフィックインターフェースがあって、ある情報がほしい場合には、
例えば柱の位置の情報その他の単位の情報を持ってくることができる。 その情報は階層構造で表すが、営業がアクセスできるものと、設計がアクセスできるものでは階層構造が変わってくる。

【００４７】各ユーザのアクセスできる階層構造はプログラムの中で持ち、ブロセスモデルでは、プロジェクトごとに新しくオブジェクトが追加される。 そして、モデルの階層構造自体は変わることがあるので、その度毎にプログラムを書き換えるか、内部的に自分でチェーンを持っている。 各オブジェクトは、下に新しく作られているオブジェクトがわかるので、あるユーザは、１つのオブジェクトに対してアクセス権が与えられると、それより下のものにはアクセスできる。 しかし、それより上のものにはアクセスできないように内部的にプログラムをもっている。 そのアクセスはビュー単位である。 特殊なものについては、ビューに入り中身は見ることができてもさわれないというようなアクセス権の付与も行われる。 この場合には、新たなビューを作ると、プログラムが、入れるだけ、読みだけのような付与を行う。 具体的に新たなビューを作る場合には、自分がアクセスする下にしか作れず、新たにビューを作った人がアクセスできる。

【００４８】各ユーザが自分のアプリケーションを持っていれば、そのインターフェースを用意することによってそのアプリケーションをアクセスすることができる。
ユーザインターフェースとの関係は、そのアプリケーションのインターフェースからアクセスでき、どこのビューからアクセスできるかは規制される。 各インターフェースからモデルの中のデータを変えることもでき、取り込んで処理をしたり、あるビューを使って総合的なやりとりを行うこともできる。

【００４９】したがって、ユーザは、自分がどんな立場であるか明言すると、自分が入れるビューがシステムから与えられる。 例えば営業の人間であれば管理者用ビューや概要情報ビューを見に行くことができ、また、営業担当者用ビューから入って自分に必要な情報を書き換えることが可能となる。

【００５０】このようにユーザは、自分がプロジェクトマネージャか営業かデザイナーか、どういう位置付けでこのプロジェクトに参加しているかを宣言すると、どの立場で入るかで階層構造のビューのどこまでアクセスできるかが左右される。 すなわち、本発明では、単なるデータベースでなく１つのプロジェクトモデルという考え方をしているので、モデルの中でどの部分に誰がどのようにアクセスできるかというアクセス権をインターフェースとしてもっている。 これがモデルにおけるユーザに対する１つのインターフェースの役割である。 したがって、ユーザの立場を定義してやれば、どこに入れるかシステムでわかっている。

【００５１】また、設計者がＣＡＤを使ってプロジェクトのデータを定義すれば、プロダクトの部分は、ＣＡＤ
の情報から自動的に生成される。 そのインターフェースもＣＡＤに限定して持っている。 ほかのアプリケーションであっても、例えば簡単な見積りのシステムで営業情報のシステムであればインターフェースを持ち、そこからデータを取り込むことによって、モデルはプロジェクトが進むにつれて大きくなり、プロジェクトに関連するデータが蓄えられる。 逆にそれぞれの担当者が上流で与えられた情報を見たい場合には、ここから全部引っ張ってくることによって、プロジェクトに関する情報は、このモデルによって一元管理される。

【００５２】施工計画の支援システムや仕上げの評価のシステムその他いくつかのエキスパートシステムにもこのアプリケーション用のサブモデルを使って利用することができる。 このモデルは、外からデータを取り込むと共に、他のアプリケーションに対してデータを提供するものであり、そのインターフェースは、全部モデルが自分でもっている。 したがって、アプリケーションが増えればそのインターフェースを追加するなりアプリケーション側で持つことによってモデルは拡大することができ、仕上げの単価や施工実績の情報等は、データーベースとのインターフェースで取り込むことができる。

【００５３】関数によるアプリケーションの起動は次のようになされる。

【００５４】ユーザがあるビューに入ってきてアクセスできれば、そこに埋め込まれた関数は自動的に動く。 この場合には、そこを見に行く時にその関数を動かしなさいという命令をもっている。 したがって、その関数が動いてほかのデータを見に行って評価しその値をユーザに提供することができる。

【００５５】例えば概算工期の算定に外で定義したアプリケーションがある場合に、あるユーザが概算工期の算定に入ってきて関数を見に行き自動的にこのアプリケーションを動かして概算工期の算定結果をみることができる。 この場合、アプリケーションには、モデルの中に関数名として埋め込まれているものがあって、ユーザがある条件で入ってくれば、それを動かすことができるところまで定義されている。 モデルとユーザとの関係から幾つかのアプリケーションが動くというところまで定義され、モデルにおける関数の規定の中でアプリケーションが動くということになる。 勿論アプリケーションはモデルから動かせるだけでなく、単独でも動かすことができる。

【００５６】次に、アクセスするパスの構成例について説明する。 図６は建物の平面図と記述とこれに対して意匠の設計者と構造の設計者がアクセスするパスの例を説明するための図である。

【００５７】例えば図６（イ）に示すような平面図の建物の場合には、同（ロ）に示すように建物の利用、所在、クライアントに関する記述があって、構造は、地下がＳＲＣで、地上がＲＣで、地下１階地上４階、地盤状況がよいという記述がある。 また、フロアに関しては、
２階はオフィスとして使われ、１４００平方フィートの床面積で、ＲＣの構造であり、部屋をみると、２つの外壁、２つの内壁、４つの柱、４本の梁、１つのスラブ、
２個の窓、１個のドアで構成され、それぞれのサイズの記載がある。 そこで、例えば意匠の設計者が意匠系の情報を見たいときには、同（ハ）に示すようにまず部屋の情報を見に行って、その部屋から壁、窓という情報に到達できる。 窓にも直接行けるがその窓が特定できないときに部屋から壁、窓と行くことができる。 逆に部屋のオブジェクトから構造の設計者は、部屋から壁に行って壁につながっている柱にささえられている梁という構造の情報のパスで見に行くことができる。

【００５８】このようにそれぞれの業務を担当している人の視点によってパスが変わってくるが、これは、入口のユーザインターフェースで自分の担当業務を宣言し、
見たいビューを定義したときにそのパスが自動的に設定されるからである。 例えば構造設計者と定義してデザインビューの中のストラクチャーデザインで、さらにストラクチャーストレスビューに入っていくと、所定のパスで見れるスロットが用意されている。 したがって、ユーザインターフェースでストラクチャーエンジニアと入れると、ユーザインターフェースのプログラムでそのビューに入ってくることができ、そのビューの定義にしたがったパスでデータを見ることができる。 例えば図示のスペースはＣｏｎｓｉｓｔ ｂｙで、４つの壁が定義され、柱と梁は壁から引っ張られてくる。 そして、接続関係の項目があって自動的にそれらを引っ張ってくるようになっている。 このように個々の建築プロジェクトに対して情報の一元管理を行うので、逆にこれを使って全てのユーザが自分の欲しい情報を欲しいときに欲しい形で得ることができる。

【００５９】生産業務の流れに沿って、本発明のモデルがどのように作り込まれ、また、このモデルがどのように各担当者によって利用されていくかを説明する。

【００６０】（イ）プロジェクトリーダーによるプロジェクトの定義（プロジェクトコード、プロジェクト名等）。

【００６１】（ロ）営業担当者による発注者名の入力（埋め込まれた関数が自動的に動き、リレーショナルデータベース内の得意先情報データベースから必要な情報を取り出しモデル内に格納する）。

【００６２】（ハ）営業担当者による現場情報の入力（埋め込まれた関数が自動的に動き、リレーショナルデータベース内の都市情報データベースから必要な情報を取り出しモデル内に格納する）。

【００６３】（ニ）営業担当者による発注者ニーズ入力（建物用途、工期、コスト等）。

【００６４】（ホ）埋め込まれた関数が自動的に動き、
事業収支等を評価。

【００６５】（ヘ）既存の情報を利用したプロジェクトリーダーによるプロジェクトの評価（プロジェクト全体の方針決定、採用可能構工法、材料等の選定、概算工期の設定等。これらの情報は、各オブジェクトに格納されて各担当者によって利用される。）。

【００６６】（ト）建物用途選定システム等を利用して営業担当者による得意先への提案。

【００６７】（チ）プロジェクト情報及び人事情報を利用したプロジェクトメンバーの選定。 （リ）意匠設計者による概算設計（ＣＡＤシステム等）
と設計情報からプロダクトモデル構築。

【００６８】（ヌ）設計情報を利用した概算工期、コストの評価。

【００６９】（ル）意匠、構造、設備担当者による企画、基本設計（ＣＡＤ利用）と、プロダクトモデルの更新。

【００７０】（オ）プロダクトモデルの見積担当者による利用。

【００７１】（ワ）プロダクトモデルと採用可能構工法情報を利用した施工担当者の構工法選定、工期評価、コスト評価等（評価された情報はプロセスモデル内に格納される。また、各種の提案がモデルを利用して設計担当者に対してなされる。）。

【００７２】（カ）施工担当者の提案等を参考にした実施設計とプロダクトモデルの更新。 さらにプロダクトモデルからの施工図ＣＡＤシステム等各種ＣＡＤシステムへの情報提供。

【００７３】（ヨ）早い段階での見積、施工計画。

【００７４】さらに、現場作業のための詳細計画作成と現場で活用できるためのサブモデルの作成や、運用・保全のためのサブモデル作成及び建物モデルを利用した総合的なプロジェクト評価、等がある。 これらのように、
プロジェクトの流れに沿ってプロジェクトモデルが拡張され、プロジェクトデータベースとして建築生産に携わる各担当者によって共有され、利用されてゆく。 その中で、プロジェクトモデルは、単に情報の納入先としてだけでなく、各種の関数やルールを内蔵し、より有機的に働くようになっている。

【００７５】次にプロセスモデルの特徴を説明する。

【００７６】プロセスモデルでは、企画、営業、設計、
見積り、施工、運用、保全等の生産業務の流れと、それぞれの担当業務をオブジェクトとして定義し、必要な情報や建物をどのように各業務の中で評価しているかをオブジェクト内にもつので、プロダクトモデルの独立性を保ち、生産業務内での業務内容や組織の変更、システムの変更等にも柔軟に対応できる。

【００７７】従来のプロダクトモデルの研究では、プロダクトモデル内に各担当業務に必要な情報や関係、手続き等を全て格納しようとしている。 そのため、プロダクトモデル自体の設定が困難であり、プロダクトモデルの情報が特定の業務領域に偏りがちで、業務内容やシステムの変更に伴い、プロダクトモデルの構造を変更しなければならない場合がある等の問題がある。

【００７８】これに対して、本発明のプロセスモデルを構築することにより、プロダクトモデルとプロセス（建築生産の流れ）の間の独立性を保つことができるので、
プロダクトモデルの設計が容易になる、広範な業務領域をカバーするプロダクトモデルの構築が可能になり、業務内容や組織、システムの変更がプロセスモデル側で解決し、プロダクトモデルにはあまり影響を与えない、顧客情報や現場周辺の情報、単価の情報等もプロダクトモデル側に格納することができる等の特徴がある。

【００７９】また、業務の流れに沿ったオブジェクトだけでなく、プロジェクト全体を管理する管理用ビューや、プロジェクト情報を蓄積する概要情報ビュー等をプロジェクトモデル内に定義しているので、より広範な情報を表現することができる。 例えばプロジェクトの進捗状況や、コスト、リスク等に関する情報は、管理者用ビューの中のサブビューの中に定義され、各業務から必要に応じて参照することができる。

【００８０】統合的なプロジェクトデータベースを考える場合、情報のセキュリティを確保しながら、各担当者に最大限の情報を提供しなければならない。 そのため、
本発明のシステムでは、システムがユーザの担当業務とアクセスモードを確認することにより、ユーザに参照又は更新可能なトップレベルのビューを画面上に提示し、
これらの問題を解決している。

【００８１】例えば営業の担当者の場合を例にすると、
検索モードでは社会的ビュー、管理者用ビュー、概要情報ビュー、企画担当者用ビュー、営業担当者用ビューをアクセスし、情報を検索することができるが、更新モードでは営業担当者用ビューと概要情報ビューにしかアクセスすることができない。 本発明のシステムでは、このような制限が全ての担当者に課せられており、これによって情報の保護や管理を行うことができるようになっている。

【００８２】プロセスモデルとして定義されている各オブジェクトは、それぞれデータと各種の関数やシステム・ルール等をその内容に持つことができる。 この機能により、各担当者は、自分の業務に必要な情報をプロダクトモデルや他の担当者のオブジェクトから自由に取り出し、自分の業務に利用することができる。

【００８３】そして、各オブジェクトの中で定義されている関数やルールによって、プロダクトモデル内のオブジェクトで定義されている関係を自由に自分用に変えて利用することが可能である。

【００８４】例えば柱と梁は、プロダクトモデル内でＳ
ｕｐｐｏｒｔｅｄという関係で表現されている。 構造設計者がこの情報を利用する場合には柱の梁の関係はこのままでよいが、施工担当者からみるとこの関係は適切でない。 その際、プロセスモデル内で、Ｓｕｐｐｏｒｔｅ
ｄという関係をＡｆｔｅｒという関係に読み変えると定義することにより、梁の工事は支えている柱の工事の後に来るという情報を得ることができる。 もし、プロセスモデルを使わずにプロダクトモデルだけで建物生産に関する情報を表現しようとすると、これら考え得る関係すべてをプロダクトモデル内に記述しておかなければならない。

【００８５】このように建物そのものの情報をプロダクトモデルとして、建築生産業務の流れをプロセスモデルとして考え、オブジェクト指向表現を利用してコンピュータ上にプロジェクトモデルを実現することにより、従来の枠組みを越えた建築生産の高度化、統合化が達成可能なシステムを構築できる。

【００８６】設計計画においては、意匠、構造、設備の各担当者が同一の設計情報を共有し、他の設計者の設計行為を考慮しながら各自の設計を進めてゆくという協調型設計（横のレベルでの情報の共有）の実現が必要であり、さらに、施工計画においては、設計計画の進捗に伴いプロジェクトモデルを通じて提供される制約条件をもとに、構工法計画、仮設計画、工程計画を概略、基本、
詳細の各レベルで検討し、これらの検討結果をモデルを通して設計計画に反映する（縦のレベルでの情報の共有）と共に、施工管理段階における管理情報を設定してゆくことが重要である。

【００８７】例えば意匠設計の設計者が建物の設計をしている時、企画設計の段階では、それぞれの階の床面積、スパン割りや実際の用途等を考えるが、一歩進んだ基本設計や実施設計の段階では、部屋の内装の色や内装の仕上げそのものをみる。 本発明では、協調型エンジニアリングの実現により設計者が設計作業している段階で施工担当者が自分のビューから現在進捗状況がどこまでいっているかという設計の情報や、決められた設計情報から施工計画を評価することができる。 したがって、設計から施工間でのリードタイム短縮を図ることができ、
手戻りも減少できるというメリットがある。 モデルには、そのためのデータが沢山あるが、誰がどういう立場でどういう時点で入ったかによって提供するデータが全部変わってくる。 建築生産の過程の中で、数多くの情報が作成され制約条件として定義され、下流の業務へ影響を与えていく。 制約条件の推移のサイクルは、図７に示すように 生成−＞伝達−＞参照（説明）−＞評価−＞交渉−＞変更 という形で行われるが、このサイクルをコンピュータ上で表現することは非常に困難であった。

【００８８】本発明のモデルでは、制約条件自体をオブジェクトとして定義し、プロセスの流れに合わせて情報を継承する機能を持たせているため、上記のサイクルの中の 制約条件の伝達及び参照（説明） という部分を実現している。

【００８９】例えば現実の業務では、各種の構工法は敷地条件や建物用途、その他の条件から、建造設計者によって検討・評価・決定されることが多い。 そして、これらの情報は、図面や各種の設計図書の中に表現され、見積りや施工の担当者に伝達される。 したがって、何らかの問題が発生した時には、手戻りが多く設計変更等に時間がかかるため、施工担当者が苦労する場合もある。

【００９０】これに対して、本発明では、構造設計者がそのビューに埋め込まれているエキスパートシステムを用いて構工法を評価すると、その情報は、構造設計者から他の担当者へ向けての制約条件ビュー（オブジェクト）に格納され、見積り担当者や施工担当者のビューに伝達される。

【００９１】したがって、見積り担当者や施工担当者が自分のビューに入っていくと、これらの構工法名を知ることができる（伝達機能）。 さらに、埋め込まれた関数を使うことにより、構造設計者がその構工法を決定した理由を知ることが可能であり、また、その中の幾つかの条件を変更して、自分の立場で再評価を行うことも可能である（参照・説明機能）。

【００９２】その際、もし施工担当者がより良い構工法を発見すれば、図８に示すように制約条件の伝達機能を利用して新しい構工法名を構造設計者に返して、早い時点での設計変更を検討することが可能になる。 この制約条件管理機能は、本モデルを用いた協調型設計・施工の実現を一層充実させるものである。

【００９３】このようにこのモデルは、建物のプロジェクトに関する情報を全部入れ、さらにそれぞれの業務に対して必要な情報を提供するためのデータをすべて持つので、ユーザにとって使い易いシステムを提供することができる。 また、後工程の人が前工程の人の情報を見れるようにすることによって、設計施工の統合化を図り、
それぞれの関連した業務の統合化も図れるという大きなメリットがある。

【００９４】なお、本発明は、上記の実施例に限定されるものではなく、種々の変形が可能である。 例えば上記の実施例では、建物について適用例を説明したが、建物以外のプラントや船舶等の大規模な生産品にも同様に適用でき、また、前記のような生産品だけでなく、プロダクトモデルとプロセスモデルのように構成の部分とそれらを業務の視点からモデルが構築できるものであれば、
例えば製造システムや研究開発システムにも同様に適用できる。 したがって、本発明の説明に用いてきた生産、
製品はこのような概念も含むものであることはいうまでもない。

【００９５】

【発明の効果】以上の説明から明らかなように、本発明によれば、建物そのものの情報をプロダクトモデルとし、建築生産業務の流れをプロセスモデルとして考え、
オブジェクト指向表現を利用してコンピュータ上にプロジェクトモデルを実現するので、建築生産における情報の一元管理と建築生産の高度化、統合化を実現することができる。 さらに、本発明のプロジェクトモデルによれば、今後より多様で複雑化する建築生産業務にとって必要となる、協調的な設計、施工計画を実現してゆく上で有効であり、プロジェクトモデルを利用した統合化システムによれば、建築生産の上流段階で作られ下流段階に対して影響を与える各種制約条件の管理・伝達・制御・
緩和等が可能になる。 また、プロセスモデルでは、企画、営業、設計、見積り、施工、運用、保全等の生産業務の流れと、それぞれの担当業務をオブジェクトとして定義し、必要な情報や建物をどのように各業務の中で評価しているかをオブジェクト内にもつので、プロダクトモデルの独立性を保ち、生産業務内での業務内容や組織の変更、システムの変更等にも柔軟に対応できる。

【図面の簡単な説明】

【図１】 本発明に係る統合的生産プロジェクト情報管理システムの１実施例を示す図である。

【図２】 本発明で採用されるプロジェクトモデルの階層図である。

【図３】 各ビューの下位に展開したモデル階層図である。

【図４】 管理者用ビューと概要情報ビューの具体的な構成例及び制約条件の継承関係の例を示す図である。

【図５】 ユーザーのアクセス権定義を含む建物モデルの利用フローを示す図である。

【図６】 建物の平面図と記述とこれに対して意匠の設計者と構造設計の設計者がアクセスするパスの例を説明するための図である。

【図７】 制約条件の推移サイクルの例を示す図である。

【図８】 設計変更を行う時のフロー図である。

【符号の説明】

１…多視点をもつオブジェクト指向建物モデル、２…Ｃ
ＡＤシステム、３…サブシステム、４…リレーショナルデータベース、５…ユーザインターフェース、６、７…
インターフェース

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成５年９月１日

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】図面の簡単な説明

【補正方法】変更

【補正内容】

【図面の簡単な説明】

【図１】 本発明に係る統合的生産プロジェクト情報管理システムの１実施例を示す図である。

【図２】 本発明で採用されるプロジェクトモデルの階層図である。

【図３イ】 各ビューの下位に展開したモデル階層図である。

【図３ロ】 各ビューの下位に展開したモデル階層図である。

【図３ハ】 各ビューの下位に展開したモデル階層図である。

【図３ニ】 各ビューの下位に展開したモデル階層図である。

【図３ホ】 各ビューの下位に展開したモデル階層図である。

【図３ヘ】 各ビューの下位に展開したモデル階層図である。

【図３ト】 各ビューの下位に展開したモデル階層図である。

【図３チ】 各ビューの下位に展開したモデル階層図である。

【図４イ】 管理者用ビューと概要情報ビューの具体的な構成例及び制約

【図４ロ】 管理者用ビューと概要情報ビューの具体的な構成例及び制約

【図４ハ】 管理者用ビューと概要情報ビューの具体的な構成例及び制約条件の継承関係の例を示す図である。

【図５】 ユーザーのアクセス権定義を含む建物モデルの利用フローを示す図である。

【図６イ】 建物の平面図と記述とこれに対して意匠の設計者と構造設計の設計者がアクセスするパスの例を説明するための図である。

【図６ロ】 建物の平面図と記述とこれに対して意匠の設計者と構造設計の設計者がアクセスするパスの例を説明するための図である。

【図６ハ】 建物の平面図と記述とこれに対して意匠の設計者と構造設計の設計者がアクセスするパスの例を説明するための図である。

【図７】 制約条件の推移サイクルの例を示す図である。

【図８】 設計変更を行う時のフロー図である。

【符号の説明】 １…多視点をもつオブジェクト指向建物モデル、２…Ｃ
ＡＤシステム、３…サブシステム、４…リレーショナルデータベース、５…ユーザインターフェース、６、７…
インターフェース

【手続補正２】

【補正対象書類名】図面

【補正対象項目名】全図

【補正方法】変更

【補正内容】

【図１】

【図６イ】

【図２】

【図３ニ】

【図３イ】

【図３ロ】

【図３ハ】

【図３ホ】

【図７】

【図８】

【図３ヘ】

【図３ト】

【図３チ】

【図４イ】

【図４ロ】

【図４ハ】

【図５】

【図６ロ】

【図６ハ】