製品のライフサイクル全般を計算機支援するためには、
それぞれの過程で種類の異なる様々なアプリケーションを利用しなければならない。
さらにこれらのプロセス全体が効率よく行われるためには、
情報ネットワークによるプロセスの統合が重要な鍵になる。
本稿ではこの様な種類の異なるアプリケーション同士が、
情報を共有しながら共同作業を効率よく行えるような、情報ネットワーク環境の実現法について述べる。
キーワード：製品モデル、ライフサイクル、分散協調ネットワーク、STEP、Java、CORBA
環境保護や資源利用の効率化に向けて、工業製品の設計や生産のみでなく、 その利用・保守・リサイクル・廃棄の全ライフサイクルプロセスを考慮に入れて、 工業活動を最適化することが近年特に強く要求されている。 利用・保守・リサイクル・廃棄などの過程は、 従来は設計段階で良く検討されていないことが多く、 それらのためのデータも十分に提供されなかった。 例えば、保守部品が不足するときの代替部品の可能性や、リサイクルのための材料組成データ、 などを知ることは簡単ではなかった。 しかも、それらのデータの必要性が生じる作業環境は屋外であったりして、 計算機を利用することも困難であった。
このような問題を解決するためには、
などが必要である。 ここでは、主に2.および3.の課題を研究する。
ここではまずライフサイクル支援に必要なデータモデルの確立と、 それらのデータへの遠隔地からの利用を可能とする情報ネットワーク環境の開発を行う。
製品の利用・保守・廃棄管理のプロセスを重視して、 これらの評価が十分にできるプロダクトモデル情報のデータモデルを構築する。ISO 10303 STEP(STandard for the Exchange of Product model data) などの標準データ表現は十分考慮しつつも、 これらに欠けている属性情報は随時新規に導入する。 (STEPとは製品モデル情報を交換・記述するための国際規格である。 詳しくはSTEP推進センターのページhttp://www.jstep.jipdec.or.jp/を参照) 属性データ表現として次の３種類を分類し、適切な表現データモデルを構築する。
従来から設計生産の高度計算機支援のためのプロダクトモデルの表現手法は良く研究されてきたが、 決定的な手法は見いだされていなかった。 データ表現の透明性を高め、データ交換や共有に資するためには、 データ表現が静的とならざるを得ず、応用処理からは独立となる。 現状のSTEPなどが代表的なものである。 個別の応用処理を重視すると深い意味処理を可能とする動的なデータ表現が必要となり、 これは個別応用には効率的であるが、他応用との連携においてデータの整合性管理を行うことが極めて困難となる。 プロダクトライフサイクル支援のためには、非常に広範囲のデータを、長期間、 地域的に分散した状態で提供しなければならない。 データの管理は静的で中立的に、データの処理は専用的で動的に行わざるを得ない。 そのために、ネットワーク情報環境において、静的・中立的データと、 動的・専用的データとの、相互変換を柔軟に行う必要がある。 このために、以下のような分散情報環境構築の方法論を確立する。
図1 : ライフサイクルモデリングのための分散環境利用例
上述のようにプロダクトライフサイクルを支援するためには、 設計・生産・利用・保守・廃棄の各プロセスにおいて、 様々な種類の異なるアプリケーションが用いられる。 そしてこれらのアプリケーションは同一のプロダクトモデル、 様々なデータモデルに対して非同期的にアクセスを行う必要がある。 この様な、異なる種類のアプリケーション同士が同一のデータに対して透過的にアクセスできるようなネットワーク環境の構築が、 プロダクトライフサイクル支援には必要になる。 本研究ではこのためのネットワーク環境をCORBA/STEP/Javaの技術を使って開発することとした。CORBA(The Common Object Request Broker: Architecture and Specification) はOMG(Object Management Group) が規定した、オブジェクト指向における分散したクライアント・サーバ環境で 利用されるオブジェクト連携機構である。 (http://www.omg.org/他参照)
このためのアーキテクチャとして、図２に示す様なネットワーク環境を提案する。 プロダクトライフサイクルを支援するための各種アプリケーションはネットワークを通じてSTEPデータベースおよび各種ライフサイクル支援サービスを提供するサーバに接続される。 ネットワーク上での各種通信はCORBA/Javaを利用し、 製品データやライフサイクルモデルのデータはSTEPの形式で記述してSTEPデータサーバ上に格納される。 アプリケーションからはサービスに対して特定の処理のリクエストを送ったり、 STEPデータサーバに対してデータの読み出し・書き込みのリクエストを送る。 現在のSTEPで扱えないワークフローやドキュメントなどに関するサービスに対しては、 CORBAあるいはJRMI (Java Remote Method Invocation)を用いて、 リモートサービス上の関数の呼び出しを行う。 これに対してSTEPデータサーバに対しては、データをJOS (Java Object Serialization)を用いて転送し、 アプリケーション自身がデータ処理を行う。
図2 : CORBA/JavaとSTEPによるクライアント・サーバ環境
STEPデータサーバはSTEP(AIM)の形式でデータを保持するが、 データを要求するクライアントアプリケーションに対しては、 よりアプリケーションの内部データ構造に近い形式(ARM相当)に変換してデータを提供できるようにする。 この変換を実行時に行うのがデータマッピング・モジュールである。 データマッピングはマッピング記述言語で記述されたデータ間の対応関係に基づいて行われる。 特にデータ記述言語EXPRESSで記述された２つの異なる構造を持つモデル同士のマッピングを定義する言語が、EXPRESSマッピング言語である。 マッピング言語の必要性はSTEPの世界でも認識されており、 様々な言語が提案されている。 ISO STEPとしてはEXPRESS-Xという言語を標準マッピング言語として開発して行く予定であるが、 EXPRESS-V、EXPRESS-M、BRIITY、EXPRESS-HLDAIなどのマッピング言語開発者らが標準化に参加している。 特にEXPRESS-HLDAIは日本で開発されたマッピング言語である。 (http://www.jstep.jipdec.or.jp/ja/hldai/hldaimain.htm参照) EXPRESSマッピング言語を利用することによって、 様々なメリットが考えられる。
一般にSTEP(AIM)の形式のデータはアプリケーションに依存しない中立な形でのプロダクトモデルの正確な記述には適している。 しかしそのため、データ構造が複雑でアプリケーションからのアクセス方法も複雑になり、 データ量も大きくなるのでネットワーク上での転送時間も増大する。 一方アプリケーションの内部データ構造をEXPRESSで記述したARM形式のデータは、 データ構造が簡潔で理解しやすくサイズも小さくてすむ。 データマッピング・モジュールで実行時にARM形式とAIM形式のマッピングを行えば、 STEPデータサーバ内部には常に中立なSTEP(AIM)形式でデータが保持されるが、 それを利用する各アプリケーションからは自分の内部データと同じ構造のデータとして読み書きすることができるので、 STEP標準のSDAI(Standard Data Access Interface) を利用するのに比べてアプリケーションの開発が非常に楽になる。 またデータ転送の量も押さえられるメリットもある。 一方SDAIを利用した場合には、開発は大変だがインタフェースは一度実装してしまえば、 任意の形式のSTEPデータに対して利用可能であるというメリットがある。 本研究ではアプリケーションのタイプに応じて、この２つのアクセス方法を使い分ける。
この様なアーキテクチャの情報ネットワーク環境を開発するために、現在以下の項目に分けて作業を行っている。
以上、ライフサイクルモデリング支援のための情報ネットワーク環境のアーキテクチャについて述べた。 本研究は現在進行中であるが、以下のような研究成果が期待される。
F.Kimura, et al. “Product Life Cycle Modelling for Inverse Manufacturing”, Life Cycle Modelling for Innovative Products and Processes, Krause & Jansen Ed. IFIP (1996)
J.Owen “STEP: An Introduction”,Information Geometers(1993)
M.Hardwick, et al. “EXPRESS-X Reference Manual”, URL=http://www.rdrc.rpi.edu/express-x/homepage.html, (1996)