(57)【要約】【課題】  アプリケーション間あるいはアプリケーションとデータベースとの間で適切にデータを連携できるアプリケーション・データベース連携方法を提供することである。【解決手段】  ＸＭＬを用いて、アプリケーションの入出力データに含まれるタグとデータサーバ上のデータに含まれるタグとが同じ種類のデータには同じタグとなるように構成された両者の共通のタグであるレファレンスタグセットを用いてタグ付けし、インターネットに接続された複数の計算機上にあるアプリケーションと、インターネットに接続された複数のデータサーバにあるデータベースとを連携する。【選択図】  図１
2005250770.tif 000002
【特許請求の範囲】
【請求項１】
インターネットに接続された複数の計算機上にあるアプリケーションと、インターネットに接続された複数のデータサーバにあるデータベースとを連携するアプリケーション・データベース連携方法において、ＸＭＬを用いて、アプリケーションの入出力データに含まれるタグとデータサーバ上のデータに含まれるタグとが同じ種類のデータには同じタグとなるように構成された両者の共通のタグであるレファレンスタグセットを用いてタグ付けされていることを特徴とするアプリケーション・データベース連携方法。
【請求項２】
前記データサーバに記録されるデータが、少なくともプラントの機器構成データと、機器データと、運転履歴データと、計測データとに分かれ、それぞれのデータがＸＭＬを用いて記録されていることを特徴とする請求項１記載のアプリケーション・データベース連携方法。
【請求項３】
前記アプリケーションの入出力データに含まれるタグと、前記データサーバ上のデータに含まれるタグとが、タグ名称は異なるがそのタグで関連づけられたデータの内容が同じものについては、それら名称の異なるタグを同一タグと判別することを特徴とした請求項１記載のアプリケーション・データベース連携方法。
【請求項４】
タグ名称の異なる複数のタグが同一内容のデータに関連づけられている場合に、同じ内容ごとにまとめたタグリストを参照することにより名称の異なるタグが同一内容を示していることを判別することを特徴とする請求項３記載のアプリケーション・データベース連携方法。
【請求項５】
タグ名称は異なるが内容を等価にする変換方法を別途用意しておき、その変換方法に基づいて内容を変換して、複数のタグ内容を等価とすることを特徴とする請求項３記載のアプリケーション・データベース連携方法。
【請求項６】
同じ内容で異なる名称のタグを、ＸＳＬのパターンマッチング機能、ＸＳＬＴのタグである「ループ」および「条件分岐」を用いて同一タグと判別することを特徴とする請求項４または５記載のアプリケーション・データベース連携方法。
【請求項７】
前記アプリケーションの入力データはプラントの機器スペックデータであり、前記機器スペックデータのタグは、その機器がどのプラントで用いられているかを示すプラントタグと、その機器が属する当該プラントの系統タグと、機器の名称を表す機器名称タグと、当該機器の定格スペックなど複数の特性データを含む複数の機器スペックタグとを持ち、このタグ付けされたデータに基づいて、アプリケーションが行う計算の対象機器であることを特定することを特徴とする請求項１記載のアプリケーション・データベース連携方法。
【請求項８】
前記特定された対象機器のタグ付けされたデータに基づいて、アプリケーションの計算に必要なデータ部分を検出しデータを獲得することを特徴とする請求項７記載のアプリケーション・データベース連携方法。
【請求項９】
前記アプリケーションの計算に必要なデータ部分を検出しデータを獲得する際に、ＸＳＬＴを用いることを特徴とする請求項８記載のアプリケーション・データベース連携方法。
【請求項１０】
前記アプリケーションの入力データはプラントの運転データであり、前記データサーバ上のデータは、プラント名称タグと、日時タグと、系統名称タグと、機器名称タグと、複数の測定値名称タグとを持ち、タグ付けがプラント全体から部分へと階層化されていることを特徴とする請求項１記載のアプリケーション・データベース連携方法。
【請求項１１】
前記アプリケーションの入力データはプラントの機器データであり、機器ごとにタグ付けがなされ、その機器を解析する際に必要となる複数の計測データが当該機器と対応づけられており、対応づけられた計測データがＸＭＬ形式で記録され、当該機器のタグ以下にそれらの計測データが記録されていることを特徴とする請求項１記載のアプリケーション・データベース連携方法。
【請求項１２】
前記機器を解析する際に必要となる複数の計測データが測定されていない場合、プラント構成に基づいて代替データを同定することを特徴とする請求項１１記載のアプリケーション・データベース連携方法。
【請求項１３】
前記データベースのデータをアプリケーションが利用できるデータに変換する際に、データベースのタグとアプリケーションの入力データのタグとを用い、それらのタグの組み合わせごとに定めたデータの変換方法により、データを変換することを特徴とする請求項１記載のアプリケーション・データベース連携方法。
【請求項１４】
前記アプリケーションが利用できるデータへのデータ変換は、ＸＭＬのスタイルシートを用いてデータ変換することを特徴とする請求項１３記載のアプリケーション・データベース連携方法。
【請求項１５】
前記データベースのデータをアプリケーションが利用できるデータに変換する際に、異なるデータ構造を持つデータベースから得られるデータを、解析体系のデータ、解析体系を構成する各コンポーネントのデータ、解析の初期状態を決める初期値データ、解析の内容を決める運転操作データからなるデータ構造に変換することを特徴とする請求項１記載のアプリケーション・データベース連携方法。
【請求項１６】
前記データ構造の変換を行う際に、ＸＳＬＴを利用することを特徴とする請求項１５記載のアプリケーション・データベース連携方法。
【請求項１７】
前記データベースのデータをアプリケーションが利用できるデータに変換する際に、複数のデータベースに対して、それぞれのデータベースの構造変換後における最上位データを日時データとし、それぞれの最上位データである日時データを比較することでデータの整合性を確認することを特徴とする請求項１記載のアプリケーション・データベース連携方法。
【請求項１８】
前記日時データを比較する際に、日時判定のためのデータベースを指定し、その指定されたデータベースの日時データを基準とし、それ以外のデータについては、基準日時に最も近い過去の日時を持ったデータをもって整合性を確認することを特徴とする請求項１７記載のアプリケーション・データベース連携方法。
【請求項１９】
前記解析体系のデータ、解析体系を構成する各コンポーネントのデータ、解析の初期状態を決める初期値データ、解析の内容を決める運転操作データからなるデータ構造に構造変換されたデータに対して、ＸＳＬのＤＯＭインターフェイスを利用してアクセスすることを特徴とする請求項１５記載のアプリケーション・データベース連携方法。
【請求項２０】
前記データサーバからデータを取り込む際に、プラント全体のデータを一括して取り込む方式、プラントの系統ごとのデータを取り込む方式、プラントの機器個別のデータを取り込む方式を用意し、解析内容に応じてそれらを利用することを特徴とする請求項１記載のアプリケーション・データベース連携方法。
【請求項２１】
前記データを一括して取り込む方式として、ＸＭＬを用いたタグ指定を用いることを特徴とする請求項２０記載のアプリケーション・データベース連携方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上で複数のアプリケーションやそのデータ入出力に使用されるデータベースの相互の連携を行うアプリケーション・データベース連携方法に関する。
【背景技術】
【０００２】
ネットワークに接続された計算機が処理するアプリケーション間における連携、あるいは計算機が処理するアプリケーションとデータサーバのデータベースとの連携に際しては、使用するアプリケーションやデータベースごとに、専用のプリプロセッサやポストプロセッサを開発し、独自のデータフォーマットやコーリングシーケンスを用いている。
【０００３】
大規模なシミュレーション解析コードなどのアプリケーションでは、膨大な入力データを要し、また膨大な結果を出力することが一般的である。これらの入出力データの形式や構成はアプリケーションに依存するため、データ処理専用のアプリケーションを別途に作成したりあるいは手動で処理する場合が多い。
【０００４】
図１４は、アプリケーションとデータベースとの利用形態を示す概念図である。プラントの解析を行う場合に、リファレンスとなる計測データ１がある。計測データは実プラントに設置された検出器を用いて計測・記録され、それらは計測した日時や計測点などに分類されて計測データベース２に保存され保管される。また、プラントを模擬するためにはプラント構成・構造データやプラントを構成する個々の機器データが必要であり、それらは個別の機器データ３から、プラントの構成分類に従って機器データベース４で保存され管理される。
【０００５】
これらの計測データ１や機器データ３をもとに、アプリケーション５ａ用の入力データを用意してアプリケーション５ａを実行すると、その結果がデータベース６ａに保存される。アプリケーション５ａの結果を利用して、別のサービスを提供するアプリケーション５ｂを実行するためには、データベース６ａ、計測データベース２、機器データベース４などから実行に必要な入力データを用意する。アプリケーション５ｂの結果はデータベース６ｂに保存され、以下同様の手順でデータのやり取りが行われる。
【０００６】
データのやり取りは、一般的にデータベースから必要な情報を入手して、手作業で入出力データを作成するという手順がこれまでの一般的な手法である。データ数が膨大になると手作業では時間がかかりすぎるし、また間違いなど正確性の観点からも問題がある。
【０００７】
そこで、図１５に示すようにネットワーク９を介したデータ連携方法がある。すなわち、図１４の計測データ１〜データベース６ａまでの各機能要素をネットワークを介して固く結合している場合である。例えば、アプリケーション５ａとアプリケーション５ｂとは、互いに中間的なデータファイル、あるいは同時に実行される場合にはメモリを介して、データを密に交換する。データは互いに必要なものを、互いにデータ構造とデータアクセス手順が統一された方法により交換する。データは必要なもののみを交換するので効率的には優れており、また電子データを介するので正確である。
【０００８】
プラント等のシステムの内部状態等の情報を収集しユーザに提示を行うものとして、収集した情報に対して柔軟に提示方法を決定でき、すべての状況別に提示方法などを定義しなくてもよいようにしたものがある（例えば、特許文献１参照）。また、プラント等の巨大または複雑な設備において、必要とする取扱説明書及び／又は図面を容易に検索できるようにしたものもある（例えば、特許文献２参照）。
【特許文献１】特開２００１ー１０９４４７号公報（図１）
【特許文献２】特開２００２ー２１５６５８号公報（図１）
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、データ交換手順は固定されているため、柔軟性や拡張性に問題がある。例えば、交換するデータの数が増えた場合などにはそのデータの読み込みや書き込み部分を修正しなければならないし、中間ファイルに互換性がなくなってしまう。また、当然ながら他のアプリケーションとのデータ交換はできないので、やはり交換手順を新たに用意する必要がある。こうした、データ交換手順やデータ構造の詳細は専門的なものであることから、誰もが直ぐに用意できるわけではない。すなわち、限られた範囲で限られた情報交換しかできない。
【００１０】
このように、個々のアプリケーションごとに個別のデータフォーマットを有しているため、そのように処理されたデータは他のアプリケーションでは利用できない。他のアプリケーションでのデータを利用するためには、専用のデータ変換アプリケーションが必要になる。また、データが個別・専門化されているため、データを利用する場合には、そのデータに熟知している必要があり、データの有効利用が図り難いといった課題がある。
【００１１】
すなわち、アプリケーション間あるいはデータベース間での連携は固く結合されており、交換するデータの形式やその構造、交換手順などを互いに厳密にあわせている。これよりデータ交換の効率は最適化されるが、データ形式や構造の変化等に対しては一々変更する必要があり、ネットワーク上での利用法としては必ずしも適してはいない。
【００１２】
これに対して近年はネットワーク上におけるＷｅｂサービスに代表されるように、緩やかな結合により、ネットワーク上における情報を共有化することが一般化している。そのためのデータ記述言語としてＨＴＭＬ（ハイパーテキスト・マークアップ言語：Hypertext markup language）が広く普及しているが、ＨＴＭＬの主な機能はデータ表示機能であり、データを加工・処理するための機能は不十分である。その欠点を補うものとして、ＸＭＬ（拡張可能マークアップ言語：eXtensible Markup language）が新たに提案され国際的にも標準化され急速に普及しつつある。
【００１３】
本発明の目的は、アプリケーション間あるいはアプリケーションとデータベースとの間で適切にデータを連携できるアプリケーション・データベース連携方法を提供することである。
【課題を解決するための手段】
【００１４】
本発明のアプリケーション・データベース連携方法は、インターネットに接続された複数の計算機上にあるアプリケーションと、インターネットに接続された複数のデータサーバにあるデータベースとを連携するアプリケーション・データベース連携方法であり、ＸＭＬを用いて、アプリケーションの入出力データに含まれるタグとデータサーバ上のデータに含まれるタグとが同じ種類のデータには同じタグとなるように構成された両者の共通のタグであるレファレンスタグセットを用いてタグ付けされていることを特徴とする。すなわち、ネットワーク上におけるアプリケーション・データベース連携の基本的な情報記述方式としてＸＭＬを使用し、その処理としてＸＳＬ／ＸＳＬＴを用い、また、アプリケーションとの連携としてＸＭＬデータのＤＯＭツリーを用いる。
【発明の効果】
【００１５】
本発明によれば、ネットワーク上におけるアプリケーション・データベース連携の基本的な情報記述方式としてＸＭＬを使用し、ＸＭＬをアプリケーション間あるいはアプリケーションとデータベースとの間の共通の情報記述言語として用いることにより、アプリケーション・データベース間での緩やかなデータ結合を実現するので、プラットフォームに依存し難い、均一化されたサービスを提供することが可能となる。また、プラントデータをＸＭＬにより、プラントの構造に基づいた階層構造化させることで、それぞれのデータ使用状況に適合したデータの相互利用が可能となり、最新の信頼性の高いデータの有効利用が図られる。
【発明を実施するための最良の形態】
【００１６】
図１は、本発明の実施の形態に係わるアプリケーション・データベース連携方法を実現するためのＷｅｂシステムの構成図である。図１に示すように、計測データ１〜データベース６ｂおよびクライアント１２ａ、１２ｂはＷｅｂ（ウェブ）サーバ１０に接続され、Ｗｅｂサーバ１０とＷｅｂ上での各サーバのロケーションを指定するディレクトリサービス１１とにより、Ｗｅｂ上でアプリケーションやデータベースが緩やかに連携するように構成されている。すなわち、ＸＭＬを用いて、アプリケーションの入出力データに含まれるタグとデータサーバ上のデータに含まれるタグとが同じ種類のデータには、同じタグとなるように構成された両者の共通のタグであるレファレンスタグセットを用いてタグ付けされている。
【００１７】
図２は、本発明の実施の形態でのアプリケーション・データベース連携方法を既存のアプリケーション・データベース連携方法と比較した概念図である。アプリケーション・データベース連携方法としては以下のものがある。
【００１８】
（Ａ）アプリケーションが共通の処理プログラム（Tool Box等）を介して処理を行うシステム。
【００１９】
（Ｂ）アプリケーション同士がお互いを呼ぶためのインターフェイスを備えているもの。（Ｃ）データの記録形式が共通であるもの。
【００２０】
ここで、（Ａ）をネットワーク上に拡張したものが分散システムの開発環境であるＣＯＲＢＡ（Commom Object Request）やＪＩＮＩ（登録商標）、ＤＣＯＭ（Distributed componet object model）などである。（Ｂ）を実現するためのツールがメッセージ交換を抽象化して、ネットワーク上でのアプリケーションインターフェイスを共通化するモバイルエージェントであり、（Ｃ）を実現する手段が情報表現の共通仕様であるＸＭＬ（eXtensible Markup language）である。また、（Ａ）（Ｂ）（Ｃ）を組み合わせたものが“Ｗｅｂサービス”として最近期待を集めている。これらに関して、ＣＯＲＢＡやＪＩＮＩ、ＤＣＯＭは、特定のベンダーに依存し、相互に互換性がない。またエージェントシステムはエージェントが動く環境を各計算機に構築する必要があり、一般化していないなどの課題がある。
【００２１】
より簡便に利用でき、プラットフォームに関係なく連携できるシステムとしては（Ｃ）のＸＭＬや、（Ａ）+（Ｂ）+（Ｃ）のＷｅｂサービスがあげられる。ＸＭＬは、データがテキスト形式で表現されていること、データの構造を表現できること、インターネットで直接利用できること、どのようなアプリケーションでも利用できることが評価されている。
【００２２】
Ｗｅｂサービスは、アプリケーションをＡＰＩ（Appliction Programming Interface）レベルで堅く結合するのではなく、ＲＰＣ（Remot Procedure Call）をＸＭＬ文書に埋め込み、ネットワーク経由で交換することで結合する緩やかな疎結合方式となっており、３つの方式のよいところを集めた方式となっている。
【００２３】
ＸＭＬは、拡張可能なマーク付け言語であり、データを記述するための言語でおる。「テキストデータのみを使用して、文書のもつデータの内容とメタデータ（データが持つ構造や属性）を表現することを目的とした言語」ということになる。その記述方法はタグと呼ばれる特定のマークを用いる点に特徴がある。ＸＭＬは、ＨＴＭＬ（ハイパーテキストマーク付け言語）同様に、ＳＧＭＬ(Standard Generalized Markup Language)（標準一般化マーク付け言語）から派生した言語であり、ＨＴＭＬの簡易さ、インターネット親和性とＳＧＭＬの汎用性とを兼ねそなえている。
【００２４】
特にＳＧＭＬから受け継いだ２点は、ＸＭＬにとって重要な意味を持つ。「タグを自由に作れる」ということは、タグが対応する一つ一つのデータに、「意味」を持たせられるということになる。例をあげると”１００”というデータを記述する際に、そのデータの対応するタグに「このデータは『単価』を意味する」と記述することが可能となる。もう一つの「文書の型を定義できる」という特性は、文書の構造を明示的に記述できるという利点となる。これはデータ同士の関連を明確にできるということであり、データをアプリケーションで処理することが容易となる。
【００２５】
このようなＸＭＬの特性により、どの様なメリットがあるかを下記に列挙する。
【００２６】
（ａ）マニュアル文書の作成者
現在の文書管理のデファクトスタンダードであるＳＧＭＬからＸＭＬへ移行することで、生産性の向上という恩恵が得られる。また作成した文書をイントラネットで利用できるようにすることも容易になる。
【００２７】
（ｂ）情報システムの管理者
システム間でやり取りするデータにメタデータとして管理情報やセキュリティ情報を付加できる。
【００２８】
（ｃ）アプリケーション開発者
異なるプラットフォームのシステム間でデータ形式のコンバートを意識する必要がなくなる。出力するデータの形態を変換する機能を容易に構築できる。
【００２９】
（ｄ）Ｗｅｂぺ一ジの作成者、またはＷｅｂマスター
アプリケーション（主にブラウザ）に特別な処理を行わせるＷｅｂぺ一ジ上の個所にＸＭＬ文書を使用できる。
【００３０】
Ｗｅｂプログラミングモデルにおける相互作用の単純さのおかげで、システムを段階的に構築していくことが可能となる。システムのすべての要素を一括して配置しなくてはならない密結合のＲＰＣや分散オブジェクトアプリケーションとは異なり、Ｗｅｂべースシステムではクライアントとサーバを必要に応じて追加していくことができる。新しいアプリケーションヘの接続は、かなり簡単に確立でき、きわめて高度な相互運用性、スケーラビリティ、および運用管理性を通して、ＤＮＳ名の登録を除げば中央での調整をほとんど必要とせずに分散的な手法で実現することができる。
【００３１】
これは、現在のようにネットワーク上でのアプリケーション開発が当たり前となってきている現状においては、アプリケーション開発、あるいはそれらを連携させたアプリケーションシステムの開発に際して、極めて重要な特性である。さらには、これらのシステムによるサービス提供手段として、Ｗｅｂサービスの利用は不可欠となっている。
【００３２】
Ｗｅｂサービスの背後にある基本的な着想は、疎結合のＷｅｂプログラミングモデルを非ブラウザベースのアプリケーションに適用することにある。その目的は分散アプリケーションを構築するためのプラットフォームを提供することである。
【００３３】
この分散アプリケーションは、さまざまなオペレーテイングシステム、デバイス上で実行されるソフトウェアを利用し、複数のベンダから提供されるさまざまなプログラム言語で記述され、全てが独立に開発、配置されることも可能である。Ｗｅｂサービスの特徴は、疎結合の分散システムを構築するための新しい汎用プラットフォームであり、次の４事柄がポイントとなる。
【００３４】
（ａ）疎結合が重要。
【００３５】
（ｂ）ＸＭＬが重要。
【００３６】
（ｃ）オブジェクトはＷｅｂサービスの実装に使用されるが、プログラミングモデルにとっての必須要素ではない。
【００３７】
（ｄ）プラットフォームの進化は継続する。幅広いプラットフォーム上で基本的なサービスを構築することができる。さらに、より高水準なサービス、代替トランスポートプロトコルの使用、およびその他のトピックに関わる作業も進行中。
【００３８】
以下、ＸＭＬを用いたアプリケーション連携システムの開発とＷｅｂサービスによるサービス提供との具体例を、プラント設計用のアプリケーションおよびデータベース連携を例にとり説明する。
【００３９】
ＸＭＬによる情報表現においては、データがすべてＸＭＬという、共通のフォーマットで記述されるため、アプリケーションやデータベースが交換する情報のＸＭＬ化を行うことにより連携が可能となる。しかも、ＸＭＬはインターネット対応であるため、通信手段などを特別に考慮する必要がなく、ネットワーク上での連携が可能である。交換する情報のＸＭＬ化を行い、プラント設計データ、運転データ、解析コード入力データ、保守データ等のＸＭＬ表現を標準とする。これにより、インターネット上の共通言語でデータベースを介さず情報交換が可能となり、プラント情報の階層化表現が可能となる。
【００４０】
プラント設計におけるアプリケーション連携のシステムの具体化を行うにあたって、まず、プラントで得られるデータ、解析コードで用いるデータについて分類し、それらを用いた連携方法について検討し具体化する。その際、機器関連データの電子カタログの利用や、プラント関連データのタグ付け方法、解析コードで利用する場合のデータ変換方法について具体化を行う。また、解析結果の整合性を確認する方法や、解析の観点からより簡便にデータにアクセスする方法などについても検討する。システム実現の具体化を以下の項目について行う。
【００４１】
（ａ）ＸＭＬによるデータ連携
（ｂ）機器スペックデータの利用
（ｃ）プラント関連データの表現方法
（ｄ）データ変換の方法
（ｅ）データの整合性を確保する手段
（ｆ）データヘのアクセス
（ｇ）データのレベル分け
ネットワーク上の解析コードと解析コードが利用するデータを持つデータサーバとが連携するためには、お互いが利用するデータに関し共通の指標が必要となる。共通の指標として、共通データ表現としてＸＭＬを使用し、ＸＭＬのタグ機能を用いたタグ付けによりデータの構造化を行う。
【００４２】
図３は、本発明の実施の形態におけるＸＭＬをデータ記述に用いた場合のアプリケーション・データベース連携関係の説明図である。プラント解析において必要となるデータには、プラントに関わるデータとして、機器構成データ１３、機器データ３、運転履歴データ１４と計測データ１とがあり、また、アプリケーションすなわち解析コードに関わるデータとして入出力データ（入力データ１５、出力データ１６）がある。これらのデータをＸＭＬで表現するためにタグ付けが必要となるが、アプリケーション連携のためには共通の内容を持つデータに関しては、同じタグ付けを行う必要がある。
【００４３】
そこで、プラントに関わるデータのタグと解析コードの入出力データに関わるタグとを評価選定し、共通な内容については統合し、最大公約数としてのタグを選定することになる。これらをレファレンスタグとして定義し、データを記述する際の共通の指標として用いることで、データサーバとアプリケーションとのデータ連携が可能となる。
【００４４】
図４は、本発明の実施の形態におけるタグレファレンスを参照したアプリケーション間でのデータ連携の説明図である。図４に示すように、解析コード（アプリケーション）Ａの解析結果（出力）を使用して、解析コード（アプリケーション）Ｂの入力データとして利用する場合を考える。例えば、解析コードＡが原子炉の熱出力過渡応答を計算して、解析コードＢはその結果を入力して熱的な安全余裕を計算するものとする。両解析コード間におけるデータ連携は、データを格納したファイルを介して行うのが一般的である。すなわち、解析コードＡで時間とそれに対応したパラメータを格納したファイルを生成して、解析コードＢでそれを逐次読み込み利用する。
【００４５】
この場合、解析コードＢで解析コードＡの結果を利用するに際しては、そのファイルの構造なり、パラメータの物理的意味を予め知っている必要がある。また、例えば、別の解析コードＣでは解析コードＡの別の解析結果、例えばドーム圧力変化が必要な場合は、解析コードＢで利用したファイルにそれが含まれていなければ、解析コードＣ用にまた別のファイルを用意する必要があり、またそのファイル構造の情報を知っていなければならない。すなわち、利用形態に伴って個別にファイルを用意する必要があり、またそのファイル情報を用意しておく必要がある。こうした情報が無い場合、その情報を知らない第三者にはそのファイルは利用できないことになる。
【００４６】
これに対して、ＸＭＬを用いて交換データを統一的に記述してしまえば、後は利用する側ではそのタグ情報から必要なデータを入手することが可能である。すなわち、図４に示したように、データをＸＭＬにより記述することにより共通化を行う。その際、コード間におけるデータ構造をＸＭＬで記述するわけであるが、解析コードＡの解析結果である原子炉熱出力が、解析コードＢの入力である原子炉熱出力に対応化させる必要がある。すなわち、解析コードＡの原子炉熱出力のデータ本体を規定するタグ名と、解析コードＢのそれが対応していることを保証しておく必要がある。
【００４７】
そこで、例えばこの＜原子炉熱出力＞が解析コードＡの出力のそれと、解析コードＢの入力のそれであるということを、レファレンスタグとして登録しておく。すなわち、図４に示すように、解析コードＢが必要とするデータＢ（例えば、原子炉熱出力）が、レファレンステーブルに登録されているかを確認して、登録されていれば＜原子炉熱出力＞というタグのデータを解析コードＡに参照し、ＸＭＬ変換により解析コードＢで使用できるデータに変換して引用する。
【００４８】
図５は、本発明の実施の形態におけるネットワーク上でＸＭＬデータを利用し表示する場合の説明図である。データ構造をＸＭＬで表現しておくので、図５に示すようにネットワーク上で自由に参照することも可能になり、データの有効利用の観点からは非常に優れた表現法となる。
【００４９】
図６は、本発明の実施の形態におけるネットワーク上でＸＭＬを介してそれぞれアプリケーションサーバ間で連携する場合の説明図である。データ構造をＸＭＬで表現しておくので、図６に示すように、単にアプリケーションコード間の連携だけではなく、ネットワーク上に分散したサーバ上のデータを相互に参照し引用して有機的に連携することも可能となる。分散したデータの一例として、プラントの機器構成データ、機器データ、運転履歴データおよび計測データなどがある。例えば、＜原子炉熱出力＞というタグが計測データに含まれており、レファレンスタグに登録されていれば、解析コードと計測データとで同じデータを互いに参照することが可能となり、解析コードの検証などに使用できる。
【００５０】
同じタグ名が付けられたデータをレファレンスタグにより保証することは重要であり、例えば、原子炉熱出力と原子炉電気出力とは異なった出力を表しており、これを両者原子炉出力で括ることは不適切である。但し、互いに単位系が異なっていても、＜単位＞という要素とそれらの間の換算係数をレファレンスとして用意しておけば、ＸＭＬ変換時に単位変換を行うことが可能である。
【００５１】
また、対応するデータ本体が存在しなくても、データ換算の方法が規定されていれば、その換算方法に基づいてデータを生成することが可能である。すなわち、解析コードＢで必要とするデータが原子炉電気出力であり、解析コードＡの出力としては原子炉熱出力しかなくても、原子炉電気出力＝発電機効率＊原子炉熱出力と規定され、発電機効率が存在すれば、解析コードＢで必要とする原子炉電気出力のデータ本体を得ることができる。このようなデータ変換には、後述するＸＳＬＴ（XSL Transformations）のような手法を用いることにより、変換処理を統一化することができる。
【００５２】
原子炉熱出力のようなパラメータはレファレンスタグ名としては統一して用いることが望ましいが、慣用的に同じものを違う名称で記述しているものはその限りではない。例えば、弁とバルブは同じものであり、あえてこれを同じタグ名に統一することはかえって不便である。そこで、互いに違う名称であっても慣用的に同じものを示すものに関しては、互いに同じものであることをレファレンスタグで宣言しておく。このように違う名称でも同じ内容を表すことを判定するためには、共通概念辞書（オントロジー）を用意しておき、辞書を参照しながら名称を同じものに変換（オントロジー変換）してマッチングさせることが一般的には行われている。但し、こうした共通概念が通じる分野（対象領域）が限られていることもあるので、その場合は分野ごとに異なる辞書を用意する必要がある。しかし、ここで例として挙げた弁とバルブのような機器名称などは、レファレンスタグで同じもとの列挙しておく（［弁、バルブ］）ことにより、いずれかにマッチしたタグ名は互いに同じ内容であると判定して、使用することができる。
【００５３】
このように、マッチングを行う深さは、対象分野や対象データによっても異なってくるが、マッチングを行う範囲を共通タグリスト化して用意しておく。すなわち、［弁、バルブ、ＶＡＬＶＥ］、［配管、パイプ、ＰＩＰＥ］等といったタグリストを、例えば機器データにおけるセットとして用意しておく。
【００５４】
こうしたマッチングの処理を行う手段として、スクリプト言語などを用いることも可能であるが、処理環境の統一性の観点から、ＸＭＬのスタイルを変換するスタイルシート言語ＸＳＬ（XML Style Language）を用いる。ＸＳＬはＸＭＬで記述された内容を表示するためのスタイルを記述する言語であるが、表示対象要素の検索や表示の変換、値のソートなどといったスタイル変換機能を有している。ＸＳＬはこのように表示のための整形（フォーマッテインク）を行うが、さらに要素の一部の入れ替えや変換、特定の要素内容の検索やソートといったデータ加工の手段として、ＸＳＬＴが定義され用意されている。
【００５５】
すなわち、様々なＸＭＬデータから必要なデータ加工をＸＳＬＴで行い、その結果をＸＳＬで整形して表示すると言うのが、ＸＭＬを用いた情報処理の流れになる。複数のタグ間におけるパターンマッチングを、ＸＳＬのパターンマッチング機能を用い複数候補間での繰り返しとマッチングによる条件分岐とをＸＳＬＴの繰り返し処理機能と条件分岐機能を用いることにより、データ処理の環境まで含めて統一することが可能である。以上述べた処理の流れについては後述する。
【００５６】
機器スペックデータをＸＭＬ表現し用いることを既に述べたが、機器スペックなどは機器供給メーカが、ＸＭＬべ一スの電子カタログなどによりネット上にオープンしていることが考えられる。このような場合、ＸＭＬを利用することで、ネットワーク上のこれらのデータを入手し加工することができる。すなわち、現状では、こうした機器データスペック、例えばある規格のポンプの定格の揚程や回転数、あるいはあるスケジュール配管の厚さや材質などのデータは、カタログデータから値を探し出して、値を一つ一つ手入力するのが一般的であるが、これでは時間もかかるし、入力ミスなど信頼性の観点からも問題がある。
【００５７】
これに対して、プラントを構成する部品は、インターネットの広がりにつれて、そのスペックを含め電子カタログ化されつつある。そこで、ＸＭＬのタグ機能を活用し、機器スペックなどはＸＭＬ化された電子カタログから、解析に必要な部分に対応するタグの内容（データ）を自動的に取り込むようにすることができる。これまでＷｅｂ表示に汎用的に使用されているＨＴＭＬでは、ぺ一ジの一部を切り出すということはできなかったが、ＸＭＬでは、ＸＬｉｎｋやＸＰｏｉｎｔｅｒにより解析に必要なデータの部分だけを切り取り加工することができるためこれが可能となる。
【００５８】
図７は、本発明の実施の形態におけるネットワーク上で電子カタログを利用する場合の説明図である。電子カタログはＪＩＳ規格、あるいはＡＳＭＥ規格に基づいた機器カタログとして既に多くのものがＷｅｂ上で公開され利用可能になっている。こうした電子カタログ本体へのリンク情報は、これまでＨＴＭＬではリンク元からリンク先への一方的なリンクで、しかもリンク先のファイル情報すべてをリンクすることしかできなかった。このため、電子カタログそのものへのリンクは行えても、電子カタログの中を検索して、必要なデータのみを抜き出してくるということはできなかった。
【００５９】
これに対して、拡張されたリンク仕様であるＸＬｉｎｋと、リンク先での特定の箇所へのアドレスを参照するＸＰｏｉｎｔｅｒを用いることにより、必要なデータを検索して参照し、抜き出してくることが可能となる。
【００６０】
図８は、本発明の実施の形態におけるネットワーク上での電子カタログの利用形態の説明図である。例えば、図８に示すように、必要とする機器データが小型うず巻きポンプである場合、吸い込み口径が決まっていればそれから揚程を検索する、あるいは逆に必要な揚程から吸い込み口径を割り出し、ポンプを特定することができる。こうした細かい処理は、ＸＰｏｉｎｔｅｒの位置指定機能および文字指定機能を組み合わせることにより、特定の情報のアドレス参照（ポインタ）により可能である。また、特殊なポンプであり、そのポンプメーカの電子力タログヘのリンクが必要であれば、ポンプの電子カタログ間で拡張リンクを張っておけば、その電子力タログヘ意識することなくリンクすることが可能であり、ネットワーク上における最新のデータを利用することができる。
【００６１】
このように、Ｗｅｂ上にある電子カタログから機器特性データを取り込むことにより、これまで人手に頼っていた数値の入力作業を自動化でき、入力に伴うミスを無くすることができる。また、どんなにＣＡＤ化されても専門家だけにしか使えなかった汎用シミュレーションツールが一般の技術者にも容易に利用できるようになる。
【００６２】
また、ＸＭＬのタグ付けを有効に用いると、解析に必要なデータをひとまとまりにするなど、データに構造を持たせることができる。例えば、プラントの解析を行う際には、特定の機器周りの解析を行いたいとする要求やプラント全体の解析を行いたいとする要求など解決すべき課題に応じてその解析範囲が異なる。そこで、例えば給水ポンプの解析を行いたいとする場合、入口における流体の温度、流量、圧力、出口における温度、流量、圧力、さらに、ポンプ回転数、入力電力などがあればよい。これらのデータは、それぞれ別のタグでタグ付けするが、これらのデータをポンプタグの下に置き、ポンプタグの下位構造とすることで、一括して取り出すことができる。
【００６３】
また、プラントは系統ごとに構成されていることから、上記の機器周りのデータの上位に、各系統単位のタグ付けを行う、さらにその上にプラント単位のタグ付けを行うなど、プラントの構造と解析に必要なデータの構成とを考慮してタグ付けを行うことで、解析の様々な要求に応えることができる。
【００６４】
図９は、本発明の実施の形態における階層・構造化されたＸＭＬデータの一例の説明図である。図９に示すように、プラント全体から部分へと階層化されるようにタグ付けを行う。図９では、あるプラントデータを構造化した一例を示しており、運転データと系統構成データから構成されているものとする。運転データは、まずそのデータの取得された時間（年日時）ごとに分けられるので、ある時間に対応した１セットの運転データの先頭には、まずこの取得時間データが設定される。従って、取得時間によるデータ検索はこの時間データを参照することになる。
【００６５】
その次に、その取得時間に対応した運転データが１セット分続く。この一例では、まず系統データが続き、そこには給水系データ、タービン系データなどが含まれている。各データの内容には実データが含まれている必要はなく、この一例のようにその実データヘの参照リンクデータがＸＬｉｎｋで参照されていてもよい。従って、ある時間のタービン系運転データのみが必要であれば、その時間に対応したタグ名＜タービン系運転データ＞のデータを参照すれば良い。
【００６６】
次の系統構成は、プラント寿命中においても頻繁に変更される性格のものではなく、また変更されたとしても現時点での最新データのみが実機を反映しているので、これのみが意味のあるデータである。従って、運転データとは異なり、時間データは置かれていない。但し、変更履歴等の必要なデータに関してはその限りではない。系統構成データは、各系統ごと、例えば給水系、タービン系等と分かれて構成され、さらに各系統を構成する機器データから構成される。各機器データには機器スペックが含まれており、例えば、給水ポンプであれば、ポンプ性能データ、使用条件データ、使用環境データなどから構成され、給水ポンプ単体の性能計算などを行いたいときに必要なデータが、ひとかたまりで入手できる。
【００６７】
これまでは、プラントデータは階層化されることなく、個別に記録あるいは一括して記録されていたので、利用に当たっては、専門家がどこのデータであるかを特定する作業が必要であった。このため、データとして記録されてはいても、解析の専門家とプラント構成や運転の専門家とはその分野が異なるため、他分野の専門家にとってプラントデータは使いやすいとはいえない状況である。
【００６８】
これに対して、ＸＭＬでプラント情報を階層化することにより、プラントは全体から部分へと構成されており、その大きさによってプラントレベル、系統レベル、機器レベルなどに分けることができる。各レベルごとにタグ付けすることで、インターネット上から特定のレベルのデータを参照することができる。また計測データも同様に、全体から部分へと階層表現し、プラント全体のデータ、系統のデータ、機器のデータとすることで、ＸＭＬプロセッサによりタグ構成を解釈でき、解析に必要な部分に対応する運転データを自動的に取り込むことができる。計測データは機器ごとにそれらを解析する際に必要となるデータがまとめられている。
【００６９】
このように計測データが階層・構成化されているので、万一必要とする計測データが存在しなくても、系統構成を参考に代替データを推定して、それを利用することが可能となる。例えば、ある機器の入口条件が計測データに存在しない場合でも、その上流側機器の出口条件がある場合などは、それを代替データとして利用するということができる。
【００７０】
以上のように、Ｗｅｂ上にある運転データやプラント構成データから解析に必要とされるデータを取り込むことにより、これまで人手に頼っていた数値の入力作業を自動化することにより、作業が極めて迅速化され、また入力に伴うミスを無くすことにより、信頼性を高めることが可能となる。
【００７１】
ここで、アプリケーション連携で用いる解析コードには、３次元詳細解析やポイント簡易解析など様々な種類がある。それぞれの解析内容に応じて利用するデータも異なってくる。そこで、それぞれの場合においてプラントから得られるデータを利用可能なようにデータを互いに変換する必要がある。
【００７２】
図１０は、本発明の実施の形態におけるアプリケーション間でのデータ変換の流れの説明図である。図１０に示すように、プラントデータにはデータ構造が多様なものがあり、それらを様々な解析コードが利用できるようにする変換もまた多様である。しかし、このような場合においてこそ、これらを統一的に扱うためにＸＭＬを利用することができる。
【００７３】
アプリケーション側で、例えば、平均データが必要であるが、計測データは分布測定している場合、得られたプラントデータから平均化の作業を行うことになるが、プラントデータの中に分布データであることを示すタグが設定されていることで、このタグ情報を判別し、平均化の処理を自動的に行うことができる。これはＸＭＬのデータ構造変換ツールであるＸＳＬＴを利用して実現できる。
【００７４】
すなわち、アプリケーション側で＜平均データ＞というタグが設定されており、その属性としてその求め方が＜分布データ＞の平均値であることが設定されていれば、参照データ側から＜分布データ＞を探し出し、その平均値を求めることにより＜平均データ＞を利用することが可能になる。同様に、コード間のデータ変換を行う場合についても、ＸＭＬのデータ構造変換ツールであるＸＳＬＴを利用して実現できる。例えば、上記の平均値と分布値を用いるコード群間で変換を行う場合、各コードには、平均値を示すタグを持つものと分布値を示すタグを持つものがあり、お互いの間でデータ交換を行う際には、それらのタグ情報を元にデータ構造を変換するＸＳＬＴを作成することができる。
【００７５】
次に、異なるアプリケーション間でのＸＭＬデータ構造を変換する仕組みとしては、ＤＯＭ（Document Object Model）と呼ばれるデータ構造をツリー状のオブジェクトモデルに変換するものが用意されている。通常、ＸＭＬデータからＤＯＭへの変換にはパーサと呼ばれる変換ツールを用いており、ＤＯＭオブジェクトに変換された時点で、各オブジェクトの要素や属性に対してアプリケーションが操作を行うことができる。オブジェクトに変換してしまえば、ＸＳＬＴあるいはＣＧＩ（Common Gateway Interface）言語、汎用プログラミング言語などを用いて変換を行うことができる。例えば、間引きであればデータの属性値である順番に対して、ある一定の間隔でのみ値を参照するといった処理になる。すなわち、複数の互いにデータ構造の異なるアプリケーション間においても、ＤＯＭという共通オブジェクトを介して、互いにデータ処理の受け渡しが可能になり、ごく自然にアプリケーション連携を行うことが可能である。
【００７６】
このように、アプリケーションに依存せずに操作可能なオブジェクトＤＯＭと、それをＸＭＬから生成するパーサと呼ばれるシステムが用意され、既存アプリケーションと容易に連携させることが可能であるのがＸＭＬの重要なメリットの一つである。
【００７７】
一般にプラントシステムを解析するにあたっては、システムを構成する体系データ、各体系の構成要素であるコンポーネントに関するデータ、解析の初期状態を設定する初期値データ、解析の内容を決める運転操作データ、という複数の性格の異なるデータを必要とする。体系データはシステムの構成を定義するデータであり、プラントデータを階層・構造化させておけば、プラントデータ全体の構造、すなわちＤＯＭそのものに対応する。従って、これらの各種データを自動変換・生成するにあたってはＸＭＬによる階層・構造化は極めて利に適ったデータ表現の手段であることがわかる。
【００７８】
プラントを解析する際に必要となるデータは、機器の構成やスペックに関わる情報（プラント構成データ、機器データ）、運転操作の情報（運転手順データ）、計測点のデータ（実機観測データ）の３種類に分類できる。特定の時刻のプラント状態を解析するときには、これらの３種類のデータが互いにコンシステントであることが要求される。それぞれのデータの特徴として、プラントの構成に関わる情報（そのプラントの機器構成や機器スペックなど）は、プラントが建設されるときに決定され、運開後に発生するメンテナンスを除けば変更がない。一方、運転操作の情報や、プラントに設置された計測器から得られる計測データなど、運転ごとに記録されるプロセス値は時々刻々変更されている。また、３種類のデータは、記述する情報が異なるためそのフォーマットも異なる。機器スペックなどは電子カタログのように、項目と数値が対応している。運転操作は運転日報のように時刻と操作を対応させている、また運転データは数値の並びとなっている。そこで、それぞれを分離して記録するとともに、機器構造やスペックなどの情報と運転データとの関連を日付や運転操作記録により関連づける。
【００７９】
図１１は、本発明の実施の形態におけるデータ間での整合性に時間データを用いることの説明図である。図１１に示すように、それぞれを分離して記録するとともに、機器構造やスペックなどの情報と運転データとの関連を日付や運転操作記録により関連づけることで、解析の際に必要となるデータの整合性を確保することが可能であると考えられる。例えば、「計測データ」のデータベースを基準データベースとし、基準データベースのある日時のデータを解析する場合、その日時に最も近い過去の機器構成データや、機器スペックデータを用いることになる。これにより、更新頻度の少ない機器データなどを少ない記録のまま利用できる。
【００８０】
次に、ネットワーク上の複数の箇所にある、異なる書式を持つデータにアクセスする場合、それぞれのデータにアクセスできるアプリケーションを介して行うことが多い。このためには、それらのアプリケーションには外からの要求に応えるための窓口であるＡＰＩが用意されている必要がある。すなわち、まず、他のコンピュータと通信を確立し、そこでＡＰＩを介してアプリケーションからデータにアクセスすることになる。これらの手続きは煩雑であるため、この部分メッセージ伝達を抽象化して手続きを統一化する、モバイル・エージェントに任せる方法などが検討されている。しかし、エージェントを用いる場合、他のコンピュータがエージェントを受け入れる仕組みを備える必要があり、更には、連携するアプリケーションごとにエージェントとアプリケーションの仲立ちを行うエーシェントラッパーを用意する必要がある。
【００８１】
これに対して、それらのデータがＸＭＬで記述されていれば、ＸＭＬによりネットワーク上から直接データを読み込むことができる。さらに、ＸＭＬプロセッサを通して、前述のＤＯＭツリー表現とすることで、どの様なアプリケーションも共通のＤＯＭインターフェイスからアクセスすることが可能である。ＤＯＭツリーの各オブジェクトはどのＯＳでも、どのプログラム言語でもＤＯＭインターフェイスからアクセスできるため、特定のプラットフォームにも依存しないという、ネットワーク上で利用するに際しては極めて重要な特性を有している。
【００８２】
アプリケーション連携においては、様々なプラットホームにおけるアプリケーションが連携する場合が多い、それらを考慮すると、ここで示した方法はネットワーク上のアプリケーション連携にとって必要不可欠の方法となる。
【００８３】
図１２は、本発明の実施の形態におけるアプリケーション間でのデータ変換にＤＯＭツリーを用いた説明図である。図１２に示すように、プラントからのデータをこのような形（ＤＯＭツリー）で構造化しておくことで、これを読む際に、アプリケーションの側からその計算体系に即して読むということができる。これにより、解析する側の計算体系を変更した場合でも、容易にデータにアクセスできる。これは様々な体系を扱える汎用コードにおいては、計測データは変わらないが、計算体系を変えて計算するといった場合に極めて有効になる。また、同じプラントデータを異なるアプリケーションで利用するといった場合にも、プラントデータを一々書き換える必要がない。既に述べたように、プラントデータの構造自体がＤＯＭツリー構造に対応付けられるため、極めて管理の柔軟なデータ構造である。
【００８４】
また、解析には、同一プラントで、全運転データを変えた解析を多数行う場合、プラントのある系統のデータだけをまとめて変えたい場合、あるいは機器データのみを変えたい場合などがある。そこで、プラント全体のタグ、系統のタグ、機器のタグというものを用意し、必要なデータの上位のタグを指定することで、下位のものすべてを取り出すことができれば解析を効率化することが可能である。このような方法は、いろいろな運転状況の解析を行うといった運転データの変更解析に役立つのみならず、特定の機器スペックのみを変更する等といったプラントの仕様を変更しプラント設計の最適化を行う場合などの設計最適化検討にも適用できる。つまり、解析の内容に応じて、運転データのレベル分けを利用する場合、機器データのレベル分けを利用する場合、構造データのレベル分けを利用する場合など、必要なレベルで構造化されたタグ付けを活用できる。
【００８５】
この具体的な一例は既に図９で示した。すなわち、図９におけるように、プラント全体のデータを、系統ごと、系統内での機器ごと、といった階層構造化しておくことにより、利用形態に基づいて、プラントデータ一括の更新、一部の系統のみの更新、さらにはある特定の機器のみの更新といった柔軟なデータ利用が可能になる。
【００８６】
図１３は、本発明の実施の形態における典型的な解析処理の流れの説明図である。まず、プラント解析を行うために入力データ準備を行う（Ｓ１０）。解析対象とするプラントとその事象に基づき、プラントデータの検索をネットワーク上にて行う（Ｓ１１）。この場合、対象とする事象のレファレンスとなるプラント計測データを計測ＤＢから検索して（Ｓ２０）、対応する計測データの検索が終了すると、その時間データをプラントデータ検索に回答する（Ｓ２１）。それと同時にその時間データに対応した運転データを運転ＤＢから検索し（Ｓ２２）、その時間データに対応した運転データをプラントデータ検索に回答する（Ｓ２３）。
【００８７】
次に、時間データと運転データを取得すると、それらの情報に基づいて整合性のあるデータ検索を開始する（Ｓ１２）。すなわち、時間データからそれに最も近い過去の系統データセットを系統ＤＢから検索するとともに運転データから解析に必要不可欠な系統データを選択する（Ｓ２４）。これらのデータ検索・取得が終了すると、データセットの確認（十分性、整合性）を行い（Ｓ１３）、データ準備が確認されると解析を実行しその結果を確認する（Ｓ１４）。その結果確認により、一部のデータ、例えぱある機器データの修正が必要と判断されると（Ｓ１５）、それらのデータを機器ＤＢから検索する（Ｓ２６）。それらのデータが特殊なデータで、機器ＤＢからリンクされた電子カタログに存在する場合、そのリンクを辿り必要な電子カタログのデータにアクセスして（Ｓ２７）、更新機器データを取得する（Ｓ２８）。そして、更新した機器データに修正して解析を再実行し（Ｓ１６）、結果確認を行う（Ｓ１７）。
【００８８】
このようにして、データ検索、データ準備、解析実行、結果確認、データ修正、データ再建策、再解析実行、結果再確認を行う。従来はこれらがすべて人手を介したものであったが、本発明の実施の形態によれば、結果の判断、データ修正の必要性の判断を除けば、ほとんどの処理がＸＭＬを介して自動的に行うことが可能となる。もちろん、レファレンスデータに基づいた判断基準までプログラム化されていれば、そのような判断も自動的に実行が可能である。
【図面の簡単な説明】
【００８９】
【図１】本発明の実施の形態に係わるアプリケーション・データベース連携方法を実現するためのＷｅｂシステムの構成図。
【図２】本発明の実施の形態でのアプリケーション・データベース連携方法を既存のアプリケーション・データベース連携方法と比較した概念図。
【図３】本発明の実施の形態におけるＸＭＬをデータ記述に用いた場合のアプリケーション・データベース連携関係の説明図。
【図４】本発明の実施の形態におけるタグレファレンスを参照したアプリケーション間でのデータ連携の説明図。
【図５】本発明の実施の形態におけるネットワーク上でＸＭＬデータを利用し表示する場合の説明図。
【図６】本発明の実施の形態におけるネットワーク上でＸＭＬを介してそれぞれアプリケーションサーバ間で連携する場合の説明図。
【図７】本発明の実施の形態におけるネットワーク上で電子カタログを利用する場合の説明図。
【図８】本発明の実施の形態におけるネットワーク上での電子カタログの利用形態の説明図。
【図９】本発明の実施の形態における階層・構造化されたＸＭＬデータの一例の説明図。
【図１０】本発明の実施の形態におけるアプリケーション間でのデータ変換の流れの説明図。
【図１１】本発明の実施の形態におけるデータ間での整合性に時間データを用いることの説明図。
【図１２】本発明の実施の形態におけるアプリケーション間でのデータ変換にＤＯＭツリーを用いた説明図。
【図１３】本発明の実施の形態における典型的な解析処理の流れの説明図。
【図１４】アプリケーションとデータベースとの利用形態を示す概念図。
【図１５】アプリケーションとデータベースとの利用をネットワークを介して行う場合のデータ連携方法の説明図。
【符号の説明】
【００９０】
１…計測データ、２…計測データベース、３…機器データ、４…機器データベース、５…アプリケーション、６…データベース、９…ネットワーク、１０…Ｗｅｂサーバ、１１…ディレクトリサービス、１２…クライアント、１３…機器構成データ、１４…運転履歴データ、１５…入力データ、１６…出力データ
【図１】
2005250770.tif 000003
【図２】
2005250770.tif 000004
【図３】
2005250770.tif 000005
【図４】
2005250770.tif 000006
【図５】
2005250770.tif 000007
【図６】
2005250770.tif 000008
【図７】
2005250770.tif 000009
【図８】
2005250770.tif 000010
【図９】
2005250770.tif 000011
【図１０】
2005250770.tif 000012
【図１１】
2005250770.tif 000013
【図１２】
2005250770.tif 000014
【図１３】
2005250770.tif 000015
【図１４】
2005250770.tif 000016
【図１５】
2005250770.tif 000017