JP2019515403A - 診断のためのグラフデータベースおよびシステム健康モニタリング - Google Patents

Abstract

相互に独立して実装されたモジュール／部品を有する複合システム／プラットフォームの診断および／または予測を行うために複数の入力データソースから包括的なモデルを分散して作成するシステムおよび方法が記載されている。一実施形態では、複合プラットフォームの包括的な連結モデルを作成するための提案されたシステムは、複合プラットフォームの異なるモジュールに関連付けられた１つまたは複数の入力データソースからデータ／コンテンツ／情報を分散方式で受信するように構成された入力データ受信モジュールと、データから検索された複数のエンティティ／変数を分析し、エッジリストを作成することによって複数のエンティティ間の従属関係を決定するように構成された従属関係決定モジュールと、包括的な連結モデル（連結グラフ）をエッジリストから作成するように構成された連結モデル作成モジュールとを備える。【選択図】図４

Description

本開示は、システム工学に関する。より詳細には、本開示は、統合システムの診断および予測のためにグラフデータベースに格納することができる包括的なグラフモデルを作成するためのシステムおよび方法に関する。

背景記述には、本発明の理解に有用であり得る情報が含まれる。本明細書で提供される情報のいずれかが先行技術であるか、または現在請求されている発明と関連していること、または具体的または暗示的に参照されている出版物が先行技術であることを認めるものではない。

ソフトウェアベースまたはハードウェアベースのシステムを開発するには、いくつかのモジュールまたは部品を統合する必要があり、これらは異なる供給業者によって個別に設計されている可能性がある。製造会社やシステムプロバイダーは、様々なエンジニアリングチームの助けを借りて複合アーキテクチャーを設計し、個々のモジュールやエンジニアリングアーチファクトをサイロで開発する可能性がある。異なるモジュールまたはエンジニアリングアーチファクトが個別に設計され、実装されているため、仕様または文書が互いにシームレスに連結されず、特定の標準インターフェイスまたは入出力規約に従わない場合がある。

このようなシステムで問題を特定したり、診断や予測を実施するには、故障発生点の不具合や損傷を迅速に判断できるように、完全な連結モデルまたは従属関係マップを準備する必要がある。より詳細なモデルは、不具合の故障発生点を特定するためにより有用であることが観察されている。更に、そのような追加の連結された詳細に関心があり得る診断技術者以外のステークホルダが、診断だけのために必要とされる以上に詳細を表すそのようなモデルを使用することもできる。通常、このようなモデルを作成するには、利用可能なエンジニアリング文書をソースデータとして使用し、異なる入出力変数／パラメータを相互に「連結」しようとする必要がある。文書が必ずしも結びついていないため、いくつかのシステムエンジニアリングの問題が暴露されており、そのような問題を解決する必要がある。これはエンジニアリングプロセスの改善に関する多くのシステムエンジニアリングの洞察をもたらす。したがって、診断、システムエンジニアリング、サポート、分析、予測などの様々なアプリケーション／ステークホルダのために、様々な供給業者から受け取った様々な入力ソースから、より包括的な連結モデルを作成する必要がある。

そのようなモデルの必要性は、実施例を利用してよりよく理解することができる。例えば、モデルベース診断（ＭＢＤ）は、自動車の不具合の証拠を特定して診断するのに役立つ一方、車両ＣＡＮ Ｂｕｓ上で利用可能な診断トラブルコード（ＤＴＣ）などの車両診断情報が、車両の不具合の証拠として監視・処理され、故に、部品またはソフトウェア変数がＤＴＣの各証拠となる可能性があるこのような不具合の故障発生点を知ることが望ましく、分析、診断、システムエンジニアリング、サポート、予測、その他同様の機能のために、このシステムに関連する全ての知識を結びつけるモデルを持つことも有益であろう。しかし、既存の連結モデルは、生成するために多くの努力が必要であり、更新中に手動介入が必要であり、１つまたは複数のエンティティ／変数でクエリを実行している間は非常に低速である。既存の連結モデルはスケーラブルでも柔軟でもない。

図１は、既知の技術による所定のスキーマを使用して作成された既存の静的モデルを示す。図１に示すように、診断および予測のためのモデルを生成する既存のシステム／アーキテクチャ１００は、部品リスト１０８、ＤＴＣおよびＰＩＤリスト１１０、保証分析結果１１２、サービスマニュアル分析結果１１４などの入力データソースを収集することによって固定スキーマ（Ｆｉｘｅｄ ｓｃｈｅｍａ）をベースとするデータマッピング１０２を実行する。次に、既存のシステム１００は、所定の固定スキーマに基づいてデータマッピングを実行し、ここで、このフィールドの診断モデルは構造化データベース（ＤＢ）技術に従う。既存のシステム１００から抽出された情報は、１つまたは複数の入力ソースから、適切に解析された埋め込みコード１１６、関数従属関係１０６、およびフォルトツリー／ＤＦＭＥＡ（設計不具合モードおよびその影響分析）１０４を受け取ることもできる。システム１００は通常、適切なフォーマットで推測的に解析された全てのデータソースを必要とし、固定スキーマに従う適切なテーブル１０２に解析されたデータを手動でマッピングする必要がある。

したがって、既存のソリューションでは、解析された全てのデータを、構造化ＤＢの「適切な場所」に手動でマッピング（配置）する必要がある。「適切な場所」を決定するために必要な手作業の量は、オートメーションおよびこのアプローチがどの程度のデータをスキーマ内の「適切なテーブルの場所」に正常に配置できるかを制限する。構造化された（リレーショナル）データベースは、クエリを介して関係を詳細に考察する上で非常に貧弱である。したがって、パスクエリは構造化データベースで実行するには非常に時間がかかり高価であり、いくつかの関係（結合演算）を持つパスを含む照会結果がクラッシュし得ることがしばしばある。更に、複数のクエリが受信されたり、演算がＤＢによって同時に実行されると、既存のシステムを大幅に遅くし、システムクラッシュを引き起こす可能性がある。故に、これはスケーラブルなアプローチではない。

故に、システムの診断および予測を実施するための包括的な連結モデルを作成するためのシステムおよび方法が必要とされている。様々なエンジニアリング文書、１または複数のソースコード、特にオブジェクト／エンティティ／コンテンツリポジトリなどの様々な入力ソースから包括的な連結モデルを作成するためのシステムと方法が必要とされている。システムおよび方法は、機械プラットフォームなどのハードウェアシステムの、および関連ソフトウェアシステムのための診断および予測のためのモデルを作成するために必要とされる。

様々なエンジニアリング文書間のデータギャップを明らかにするのに役立ち得るモデルを作成するシステムおよび方法が必要であり、エンジニアリングアーチファクト間のデータ不一致を明らかにするのに役立ち得る。どの部品またはソフトウェア変数が故障発生点であり得るかを知るための包括的なモデルが必要とされている。診断推論に使用できる連結モデルを作成するためのシステムおよび方法が必要とされている。

本明細書中の全ての刊行物は、個々の刊行物または特許出願が具体的かつ個々に参照により組み込まれると示されているのと同程度に、参照により組み込まれる。

組み込まれた参考文献における用語の定義または使用が矛盾しているか、または本明細書で提供されるその用語の定義に反する場合、本明細書で提供されるその用語の定義が適用され、参照におけるその用語の定義は適用されない。

したがって、いくつかの実施形態では、記載された説明および添付の特許請求の範囲に記載された数値パラメータは、特定の実施形態によって得られることが求められる所望の特性に応じて変化し得る近似値である。いくつかの実施形態では、数値パラメータは、報告された有効数字の数と、通常の丸め技術を適用して解釈されるべきである。本発明のいくつかの実施形態の広い範囲を示す数値範囲およびパラメータが近似値であるにもかかわらず、特定の実施例に示された数値は、実施可能な限り正確に報告される。本発明のいくつかの実施形態で提示される数値は、それぞれの試験測定値に見られる標準偏差から必然的に生じる特定の誤差を含むことができる。

本明細書の記述および以下の特許請求の範囲を通して使用されるように、「ａ」、「ａｎ」、および「ｔｈｅ」の意味は、文脈上他に明確に指示されない限り、複数の言及を含む。また、本明細書の記載で使用されているように、「ｉｎ」の意味は、文脈上他に明確に指示されない限り、「ｉｎ」および「ｏｎ」を含む。

本明細書における値の範囲の列挙は、範囲内に入る個々の値ごとに個々に言及する簡略な方法として役立つことを意図するに過ぎない。本明細書中で他に示されない限り、個々の各値は、本明細書中に個別に列挙されているかのように明細書に組み込まれる。本明細書中に記載される全ての方法は、本明細書中で他に指示されない限り、または文脈によって明らかに矛盾しない限り、任意の適切な順序で実施され得る。本明細書の特定の実施形態に関して提供される任意のおよび全ての例、または例示的な用語（例えば、「など」）の使用は、単に本発明をよりよく示すことを意図しており、特許請求の範囲に記載されていない限り、発明の範囲を限定するものではない。本明細書中のいかなる言葉も、本発明の実施に不可欠な任意の請求されていない要素を示すものとして解釈されるべきではない。

本明細書で開示される本発明の代替要素または実施形態のグループ分けは、限定として解釈されるべきではない。各グループメンバーは、個別に、またはここに記載されているグループまたは他の要素の他のメンバーと任意の組み合わせで参照および要求することができる。利便性および／または特許性の理由から、１つまたは複数のグループのメンバーをグループに含めたり、グループから削除することができる。そのような包含または欠失が生じる場合、明細書は、改変されたグループを含むとみなされ、したがって添付の特許請求の範囲で使用される全てのグループの記述を満たすものとみなされる。
発明の目的

本発明の目的は、システムの診断および予測を実施するための包括的な連結モデルを作成するためのシステムおよび方法を提供することである。

本発明の別の目的は、様々な入力ソース、例えば様々な工学的文書、ソースコードなどから包括的な連結モデルを作成するためのシステムおよび方法を提供することである。

本発明の別の目的は、ハードウェアシステム（例えば、機械プラットフォーム）の診断および予測のためのモデルならびにソフトウェアシステムのためのモデルを作成するためのシステムおよび方法を提供することである。

本発明の目的は、様々なエンジニアリング文書間のデータギャップを明らかにし、エンジニアリングアーチファクト間のデータ不一致を明らかにすることができるモデルを作成するためのシステムおよび方法を提供することである。

本発明の別の目的は、不具合／故障の故障発生点となる可能性のある部品またはソフトウェア変数を知るために使用することができる包括的なモデルを作成することである。

本発明の更に別の目的は、診断トラブルシューティングに使用することができる連結モデルを作成するためのシステムおよび方法を提供することである。
概要

相互に独立して実装されたモジュール／部品を有する複合システムの診断および／または予測を実施するために、複数の入力データソースから包括的な動的モデルを分散して作成するためのシステムおよび方法が記載されている。

一実施形態において、複合プラットフォームの包括的な連結モデルを作成するための提案されたシステムは、連結グラフ（互換可能に、連結モデルとも呼ばれる）の生成を容易にするように動作可能な１つまたは複数のルーチンをその中で具現化した非一時的格納装置と、非一時的格納装置に連結され、１つまたは複数のルーチンを実行するように動作可能な１つまたは複数のプロセッサとを含み、１つまたは複数のルーチンは、１つまたは複数のプロセッサによって実行されると、複数の入力ソースから複合プラットフォームに関するデータ（コンテンツ／情報とも呼ばれる）を受信する入力データ受信モジュールを含むことができ、受信したデータには、システムエンジニアリング文書、ソフトウェアコード、メンテナンスマニュアル、特に１つまたは複数の分散型または集中型入力ソースからのコンテンツなどが含まれ得るが、これらに限定されない。

本開示のシステムは更に、１つまたは複数のプロセッサによって実行されると、（例えば、複数の入力ソースから受信された複数のエンティティ／変数を有する）受信データを分析し、少なくとも１つのエッジリスト（親子リストとも呼ばれる）を作成することによって、複数のエンティティ／変数の従属関係（特異関係）を決定する従属関係決定モジュールを含むことができる。エンティティ／変数を識別するための受信データの解析は、ノード（少なくとも１つのノードプロパティを有する）またはエッジ（少なくとも１つのエッジプロパティを有する）のいずれかとして、各エンティティ／変数を分類して格納するのに役立つグラフデータベースを生成し、構築するために使用することができる。したがって、グラフデータベース（グラフｄｂとも呼ばれる）は、データがノード／ノードプロパティまたはその間の関係に基づいて２つのノードを連結するエッジ（エッジプロパティを含む）のいずれかとなるようにデータを格納する。したがって、グラフ関係は、（リレーショナルデータベースに頼る先行技術の場合のように）必須のスキーマを介して間接的にではなく、個々のデータを介して直接的にモデル化されるという事実の点で、大きな利点を有する。コンテキストを有する関係性を開示する受信された入力ソース／ソフトウェアコードデータの分析によって識別されるエンティティ／変数は、２つのノード（例えば、開始ノードおよび終了ノード）を連結するエッジとして分類することができる。各識別されたエッジは、関連するエッジプロパティを有することができる。同様に、各ノードをノードプロパティに関連付けることもできる。

本開示のシステムは更に、１つまたは複数のプロセッサによって実行されると、少なくとも１つのエッジリストから包括的な連結モデル（「連結グラフモデル」または「連結グラフ」とも呼ばれる）を作成する連結グラフモデル作成モジュールを含むことができる。例示的な実施態様では、連結モデルは、連結グラフの形で表すことができる。一態様において、連結グラフは、グラフデータベースが生成されるより早く自動的に構築／補正／変更され得、グラフデータベースの変更によって、それぞれの変化を連結グラフに反映させることができる。

一態様において、連結モデル／グラフが構築／生成されると、診断または予測を実施するために、目的とするノード／エンティティのネットワーククエリを受信することができ、クエリを実行して、それに直接的および間接的に連結された全てのノードエンティティ、およびそれを連結するエッジを戻すことによりノードの子ノード、子ノードの子ノードなどを提供することができる。追加のクエリロジックは、ハードウェアの部品や故障発生点を表すノードや試験または修理などの特定のプロパティを持つこのネットワークにおけるノードおよびエッジのみをフェッチするように構成可能である。

グラフデータベースは、ノードクエリ、エッジクエリ、ノードおよびエッジプロパティークエリ、ならびにいくつかのノードおよびそれらを他のノードに連結する可能性のあるパスを含むネットワーククエリを可能にする。グラフデータベースはまた、メモリ要件が大幅に低いリレーショナルデータベースよりも数桁も高速に実行される最短および最長のパスクエリを可能にする。

一態様において、作成された連結モデルは、異なる供給業者のモジュールを使用して設計された複合システムの診断および／または予測に使用できる。

システムの個々の部品／モジュールに関連付けられた仕様文書、Ｓｉｍｕｌｉｎｋモデル、ソースコード、システムエンジニアリング文書、メンテナンスマニュアルなど、様々な入力データソースから包括的なモデルを作成することができる。提案されたシステムによって作成されるような包括的な連結モデルは、健康指標、部品、故障、修復処置などの診断および予測に関連する異なるエンティティの連結性を記述し、全体的な連結性および従属関係マップを提供する。連結グラフモデルによって記述されたこの全体的な連結性／従属関係マップは、システムエンジニアリングにおいて貴重なものであり、文書／アーチファクトを独自に開発する様々なエンジニアリングサイロの最新の診断情報の優れたソースを作成することができる。

例示的な実施態様では、従属関係決定モジュール（ＹＵＣＣＡ）は、１つのタイプの入力（埋め込みコード）を解析して関連する関係を抽出してモデル／グラフを構築するためのソフトウェア分析を実行する包括的な方法を組み込むことができる。例示的な実施態様では、コントローラコードがＭａｔｌａｂ−Ｓｉｍｕｌｉｎｋなどのよりハイレベルな言語で利用可能である場合、Ｍａｔｌａｂ−Ｓｉｍｕｌｉｎｋまたは類似のよりハイレベルなソフトウェア言語を使用して、従属関係情報を容易に抽出することもできる。ここで、解析された従属関係情報は、各診断トラブルコードソフトウェア変数がコントローラの入力および出力ソフトウェア変数によってどのように影響されるかを抽出することができるソフトウェア変数のネットワークを記述する。

一態様において、本開示のシステムは、車両トラブルを識別し診断するためのモデルベース診断（ＭＢＤ）に使用することができる。車両ＣＡＮ Ｂｕｓで利用可能な車両診断情報（ＤＴＣ）を、故障の症状を識別するために監視することができる。

例示的な実施態様では、連結モデルは、システムエンジニア、キャリブレーションエンジニア、およびサービス技術者などの様々なステークホルダに対する診断、分析、予測、分析支援などの様々なサービスを可能にするために使用することができる。

添付の図面は、本開示の更なる理解を提供するために含まれ、本明細書に組み込まれ、その一部を構成する。図面は、本開示の例示的な実施形態を示し、説明と共に、本開示の原理を説明するのに役立つ。

図１は、既知の技術による所定のスキーマを使用して作成された例示的な静的モデルを示す。

図２は、本開示の一実施形態による、複数のデータソースから包括的な連結グラフモデルを作成するための例示的なシステムの機能モジュールを示す。

図３は、本開示の一実施形態による、システムの診断および予測を可能にするための連結グラフモデルを作成するための例示的な方法のフローチャートを示す。

図４は、本開示の一実施形態による、複数のデータソースから包括的な連結モデルを作成するための例示的なシステムを示す。

図５は、本開示の一実施形態によるソフトウェア分析に基づいて作成された例示的な可変従属関係テーブル（エッジリスト）を示す。

図６Ａは、本開示の一実施形態に従って生成された例示的なサブグラフを示す。

図６Ｂは、本開示の一実施形態に従って生成された例示的な連結グラフを示す。

図７は、本開示の一実施形態により、どのようにサブグラフを作成し、次いで一緒に処理してスーパーグラフを生成することができるかを示す。

図８は、本開示の一実施形態による可変従属関係分析の例示的なフローを示す。

図９は、本開示の一実施形態による、エンティティの連結されたチェーンを作成するために使用することができる例示的なフロー図を示す。

図１０は、本開示の一実施形態による、データソースからエンティティ情報を抽出し、可変関係テーブルを作成するための例示的なブロック図を示す。

図１１Ａは、変数が書き込まれまたは変更され得る例を提供する。

図１１Ｂは、ディレクティブを使用したコード選択の例を示す。

以下は、添付図面に示される開示の実施形態の詳細な説明である。実施形態は、開示を明確に伝えるように詳細に記載されている。しかしながら、提供される詳細の量は、実施形態の予想される変形を限定するものではなく、反対に、添付の特許請求の範囲によって規定される本開示の精神および範囲内に入る全ての変更、等価物、および代替物をカバーすることが意図される。

添付の特許請求の範囲の各々は、特許請求の範囲に記載された様々な要素または限界に対する等価物を含むと侵害目的で認識される別個の発明を定義する。文脈に応じて、以下の全ての「発明」への言及は、特定の特定の実施形態のみを指す場合もある。他の場合において、「発明」への言及は、特許請求の範囲の１つ以上（必ずしも全てではない）に列挙される主題を指すことが認識されるであろう。

本明細書の記述および以下の特許請求の範囲を通して使用されるように、「ａ」、「ａｎ」、および「ｔｈｅ」の意味は、文脈上他に明確に指示されない限り、複数の言及を含む。また、本明細書の記載で使用されているように、「ｉｎ」の意味は、文脈上他に明確に指示されない限り、「ｉｎ」および「ｏｎ」を含む。

本明細書中に記載される全ての方法は、本明細書中で他に指示されない限り、または文脈によって明らかに矛盾しない限り、任意の適切な順序で実施され得る。本明細書の特定の実施形態に関して提供される任意のおよび全ての例、または例示的な用語（例えば、「など」）の使用は、単に本発明をよりよく示すことを意図しており、特許請求の範囲に記載されていない限り、発明の範囲を限定するものではない。本明細書中のいかなる言葉も、本発明の実施に不可欠な任意の請求されていない要素を示すものとして解釈されるべきではない。

本明細書で使用する様々な用語を以下に示す。特許請求の範囲で使用されている用語が以下に定義されていない限り、出願時に印刷物および発行された特許に反映されているように当該技術者がその用語に与えた最も広い定義を与えられるべきである。

相互に独立して実装されたモジュール／部品を有する複合システムの診断および／または予測を実施するために、複数の入力データソースから包括的な動的モデルを分散して作成するためのシステムおよび方法が記載されている。

一実施形態において、複合プラットフォームの包括的な連結モデルを作成するための提案されたシステムは、連結グラフ（互換可能に、連結モデルとも呼ばれる）の生成を容易にするように動作可能な１つまたは複数のルーチンをその中で具現化した非一時的格納装置と、非一時的格納装置に連結され、１つまたは複数のルーチンを実行するように動作可能な１つまたは複数のプロセッサとを備え、１つまたは複数のルーチンは、１つまたは複数のプロセッサによって実行されると、複数の入力ソースから複合プラットフォームに関するデータ（コンテンツ／情報とも呼ばれる）を受信する入力データ受信モジュールを含むことができ、受信したデータには、システムエンジニアリング文書、ソフトウェアコード、メンテナンスマニュアル、特に１つまたは複数の分散型または集中型入力ソースからのコンテンツなどが含まれ得るが、これらに限定されない。

本開示のシステムは更に、１つまたは複数のプロセッサによって実行されると、（例えば、複数の入力ソースから受信された複数のエンティティ／変数を有する）受信データを分析し、少なくとも１つのエッジリスト（親子リストとも呼ばれる）を作成することによって、複数のエンティティ／変数の従属関係（特異関係）を決定する従属関係決定モジュールを含むことができる。エンティティ／変数を識別するための受信データの解析は、ノード（少なくとも１つのノードプロパティを有する）またはエッジ（少なくとも１つのエッジプロパティを有する）のいずれかとして、各エンティティ／変数を分類して格納するのに役立つグラフデータベースを生成し、構築するために使用することができる。したがって、グラフデータベース（グラフｄｂとも呼ばれる）は、データがノード／ノードプロパティまたはその間の関係に基づいて２つのノードを連結するエッジ（エッジプロパティを含む）のいずれかとなるようにデータを格納する。したがって、グラフ関係は、（リレーショナルデータベースに頼る先行技術の場合のように）必須のスキーマを介して間接的にではなく、個々のデータを介して直接的にモデル化されるという事実の点で、大きな利点を有する。コンテキストを有する関係性を開示する受信された入力ソース／ソフトウェアコードデータの分析によって識別されるエンティティ／変数は、２つのノード（例えば、開始ノードおよび終了ノード）を連結するエッジとして分類することができる。各識別されたエッジは、関連するエッジプロパティを有することができる。同様に、各ノードをノードプロパティに関連付けることもできる。

本開示のシステムは更に、１つまたは複数のプロセッサによって実行されると、少なくとも１つのエッジリストから包括的な連結モデル（「連結グラフモデル」または「連結グラフ」とも呼ばれる）を作成する連結グラフモデル作成モジュールを含むことができる。例示的な実施態様では、連結モデルは、連結グラフの形で表すことができる。一態様において、連結グラフは、グラフデータベースが生成されるより早く自動的に構築／補正／変更され得、グラフデータベースの変更によって、それぞれの変化を連結グラフに反映させることができる。

一態様において、連結モデル／グラフが構築／生成されると、診断または予測を実施するために、目的とするノード／エンティティのネットワーククエリを受信することができ、クエリを実行して、それに直接的および間接的に連結された全てのノードエンティティ、およびそれを連結するエッジを戻すことによりノードの子ノード、子ノードの子ノードなどを提供することができる。追加のクエリロジックは、特定のプロパティを持つこのネットワークにおけるノードおよびエッジのみをフェッチするように構成可能である。

グラフデータベースは、ノードクエリ、エッジクエリ、ノードおよびエッジプロパティークエリ、ならびにいくつかのノードおよびそれらへのパスを含むネットワーククエリを可能にする。グラフデータベースはまた、メモリ要件が大幅に低いリレーショナルデータベースよりも数桁も高速に実行される最短および最長のパスクエリを可能にする。

一態様において、作成された連結モデルは、異なる供給業者のモジュールを使用して設計された複合システムの診断および／または予測に使用できる。

システムの個々の部品／モジュールに関連付けられた仕様文書、Ｓｉｍｕｌｉｎｋモデル、ソースコード、システムエンジニアリング文書、メンテナンスマニュアルなど、様々な入力データソースから包括的なモデルを作成することができる。提案されたシステムによって作成されるような包括的な連結モデルは、健康指標、部品、故障、修復処置などの診断および予測に関連する異なるエンティティの連結性を記述し、全体的な連結性および従属関係マップを提供する。連結グラフモデルによって記述されたこの全体的な連結性／従属関係マップは、システムエンジニアリングにおいて貴重なものであり、文書／アーチファクトを独自に開発する様々なエンジニアリングサイロの最新の診断情報の優れたソースを作成することができる。

例示的な実施態様では、従属関係決定モジュール（ＹＵＣＣＡ）は、１つのタイプの入力（埋め込みコード）を解析して関連する関係を抽出してモデル／グラフを構築するためのソフトウェア分析を実行する包括的な方法を組み込むことができる。例示的な実施態様では、コントローラコードがＭａｔｌａｂ−Ｓｉｍｕｌｉｎｋなどのよりハイレベルな言語で利用可能である場合、Ｍａｔｌａｂ−Ｓｉｍｕｌｉｎｋまたは類似のよりハイレベルなソフトウェア言語を使用して、従属関係情報を容易に抽出することもできる。ここで、解析された従属関係情報は、各診断トラブルコードソフトウェア変数がコントローラの入力および出力ソフトウェア変数によってどのように影響されるかを抽出することができるソフトウェア変数のネットワークを記述する。

一態様において、本開示のシステムは、車両トラブルを識別して診断するためにＭＢＤに使用することができる。車両ＣＡＮ Ｂｕｓで利用可能な車両診断情報（ＤＴＣ）を、故障の症状を識別するために監視することができる。

例示的な実施態様では、連結モデルは、システムエンジニア、キャリブレーションエンジニア、およびサービス技術者などの様々なステークホルダに対する診断、分析、予測、分析支援などの様々なサービスを可能にするために使用することができる。

本開示は更に、機器プラットフォームの健康監視を可能にするように構成されたシステムに関し、前記システムは、連結グラフの生成および詳細な考察を容易にするように動作可能な１つまたは複数のルーチンをその中で具現化した非一時的格納装置と；非一時的格納装置に連結され、１つまたは複数のルーチンを実行するように動作可能な１つまたは複数のプロセッサであって、１つまたは複数のルーチンが、１つまたは複数のプロセッサによって実行されると、複数の入力ソースから機器プラットフォームに関するデータを受信する入力データ受信モジュールを含み、受信したデータが機器プラットフォームの１つ以上のエンティティに関するものである、１つまたは複数のプロセッサと；１つまたは複数のプロセッサによって実行されると、受信したデータを分析し、少なくとも１つのエッジリストを作成することによって１つ以上のエンティティ間の従属関係を決定し、１つ以上のノードおよび複数のエッジを含むグラフデータベースを構築する従属関係決定モジュールであって、複数のエッジの各エッジが、開始ノードと終了ノードとを結びつけ、それらの間の関係を規定する、従属関係決定モジュールと；１つまたは複数のプロセッサによって実行されると、少なくとも１つのエッジリストから連結グラフを作成し、前記連結グラフをグラフデータベースまたはグラフライブラリに格納する連結グラフモデル作成モジュールであって、連結グラフが、ネットワーク・サブグラフ識別、ネットワーク・パス最短／最長パス、ノード、エッジ、ノードプロパティおよびエッジプロパティのいずれかまたはその組み合わせに関して照会可能である、連結グラフモデル作成モジュールと、を備える。

図２は、本開示の一実施形態による、複数のデータソースから包括的な動的連結モデルを作成するための例示的なシステムの機能モジュールを示す。一態様において、本システムは、複合プラットフォームの様々なモジュール／サブシステムと関連付けられた１つまたは複数の入力データソース（文書、ユーザマニュアル、技術仕様書、特にコンテンツリポジトリ／文書など）からデータ／コンテンツ／情報を受信するように構成された入力データ受信モジュール２０２と；１つまたは複数の入力データソースから受信したデータ／コンテンツ／情報の一部を形成する複数のエンティティ／変数を分析し、エッジリストを作成することによって複数のエンティティ／変数の全ての従属関係（全ての特異関係）を決定してグラフデータベースを作成するように構成された従属関係決定モジュール２０４と；グラフデータベースに基づいてエッジリストから包括的な連結／グラフモデル（連結グラフ）を作成するように構成された連結モデル作成モジュール２０６とを備えることができる。例示的な実施態様では、連結モデルは、連結グラフの形で表すことができる。

一態様において、本開示のシステムは、車両トラブルを識別し診断するためのモデルベース診断（ＭＢＤ）に使用することができる。車両ＣＡＮ Ｂｕｓで利用可能な車両診断情報（ＤＴＣ）を、故障の症状を識別するために監視することができる。

一態様において、本開示の一実施形態によるシステムによって生成された例示的なモデルは、複数の行を含むことができ、例示的なモデルの各行は、最初の列に記載される診断トラブルコード（ＤＴＣ）間の連結を記述する連結サブグラフとして解釈することができ、後続の対応する列には部品名が記載されている。一態様において、システムによって生成された提案されたモデルの精度は、顧客のサービスマニュアルに基づいて確認することができ、作成されたモデルがサービスマニュアルの関連する全ての部品などを生成することが観察される。サービスマニュアルに記載されていない追加の（更に）部品も修正されることが確認されている。

例示的な実施形態では、システム２００は、クラウドベースのリソースおよびクラウドベースの入力データソースを使用して分散方式（複数のサーバ／クラウドまたは１つまたは複数のネットワークにわたって構成された演算装置からの入力データソースを組み込むことによって）で実施することができる。別の態様において、システム２００は、構造化ＤＢ（スキーマを有する）の代わりに長いリストとしてデータを格納できるという意味でビッグデータ互換性を有することができる。データリストを分割して、別々のコンピュータに分散して格納することができる。データを演算に持ち込むのではなく、または、広範囲に解析する必要なく、演算をデータに持ち込むために、コンピュータ上にクエリを分散することができる。

理解できるように、クラウドベースのリソースは、提案されたシステムが追加の性能のために必要に応じて追加の演算リソース／サーバを追加することを可能にする。

例示的な態様において、システム２００は、「診断」アプリケーションに使用することができるグラフデータベースから連結グラフモデルを作成する。理解できるように、データ編集には固定スキーマは使用されないので、システム２００は従来のＤＢアプローチと比較してより柔軟性がある。システム２００はまた、固定スキーマがないので、データ解析の量が少なくて済む。システム２００は、入力データを複数のソースから詳細に取り込むことを可能にする。システム２００はまた、モデル開発のために非常に堅牢な方法（グラフ化）を使用することもできる。

例示的な実施形態では、システム２００は、Ｃｏｍｐｒｅｈｅｎｓｉｖｅ Ｓｏｆｔｗａｒｅ従属関係分析（例えば、ＫＰＩＴ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｌｔｄ．が開発したＳｅｑｕｅｎｔｉａｌ ｔｏ Ｐａｒａｌｌｅｌ自動コード変換専用ツールであるＹＵＣＣＡ（ＹＵＣＣＡに関する更なる詳細については２５１３／ＭＵＭ／２００８および２５５９／ＭＵＭ／２００８を参照）を使用する）を行って提案されたモデルを作成する。理解できるように、全ての変数従属関係は、可変リード・ライト分析の後に取り込まれ、その後、可変リード・ライト分析の精度を高め、全ての可能な関係を収集するために関数ポインタ分析が行われる。変数従属関係は、単純なテキスト（テキストマッチング）検索ではなく、コード分析に基づくものである。例示的な実施態様において、システム２００は、全ての可変関係の収集を保証するためにマクロ変数を処理する。システム２００は、条件変数を可変関係に影響を及ぼす変数と見なす。

一実施形態では、システム２００は車両故障診断用に構成することができ、このシステムは、入力データソース（ユーザマニュアル、ソフトウェアコード、文書など）から全てのエンティティ（車両健康関連情報）を抽出し、ビッグデータ・アプローチを使用してエンティティを分析して、１つ以上の親データと１つ以上の子データとの間の関係を特定する有向連結グラフを生成するように構成することができ、連結グラフの処理に基づいて複合システムの故障を検出または予測するための診断／予測（車両故障診断および予測）を可能にする。例示的な実施態様では、連結グラフのサブグラフを異なるコンピュータ上に作成することができる。

一態様において、提案されたシステム（従属関係分析が実行される）によって受信されたデータは、提案された連結グラフを形成するために分析される必要のある異なる車両機能に関連するソース／ソフトウェアコードの形態であってもよいことを理解されたい。したがって、ソースコードを分析して従属関係（従属関係とも呼ばれる）を決定することができる。したがって、更なる態様において、提案されたシステムは、所望の診断を提供するために、ソースコードと共に１つまたは複数の入力ソース（試験／検証マニュアルまたはＤＴＣマニュアルなど）を分析する。

別の態様において、受信したデータとしては、診断情報／データ／サービスへのアクセスを提供する様々な車両部品のリスト、または配線／油圧図、またはＯＤＸ（Ｏｐｅｎ Ｄｉａｇｎｏｓｔｉｃ ｅＸｃｈａｎｇｅ）ファイルのリスト、ビジネスサービス文書、共通サービスに関する文書、サービスマニュアル、エンタープライズ・リソース・プラニング（ＥＲＰ）データ、ストリーム分析、クロス分析、保証／信頼性などの様々なアプリケーションサービスに関連するデータ、特に車両の一部を構成するか、または車両と機能的に連携する様々なエンティティ／変数に関する情報／データを挙げることができる。

図３は、本開示の一実施形態による、システムの診断および予測を可能にするための連結グラフモデルを作成するための例示的な方法のフローチャートを示す。図３に示すように、この方法は、ステップ３０２に示すように、１つまたは複数の入力ソース（ユーザマニュアル、ソフトウェアコード、文書など）から複数のエンティティ（車両健康関連情報）を抽出するステップと、ステップ３０４に示すように、エンティティを分析して、ビッグデータ・アプローチを用いて親ノードと子ノードとの間の関係を特定する１つ以上の有向連結グラフを生成するステップと、ステップ３０６に示すように、この１以上の連結グラフに基づいて診断／予測（車両故障診断および予測）を行うステップとを含む。例示的な実施態様では、連結グラフのサブグラフを異なるコンピュータ上で生成することができる。

例示的な実施態様では、方法３００を使用して、特定された各親要素（ユーザによってまたは提案されたシステム／モデルによって自動的に特定される）に関するエンティティの連結チェーンを、親−子データリスト・マッピングを用いて抽出することができる。子のためのルックアップ（ＭＡＰ）は、次のエンティティ情報が存在する場所に持ち込まれ、データ格納演算装置上でローカル処理されることができる。連結された全ての演算装置から受け取った子に関する結果は、Ｃｈａｉｎまで減らすことができ、次の反復のための新しいＰａｒｅｎｔを作成することができる。反復プロセスは、特定された親への全ての連結を識別することができる。例示的な実施態様では、データから連結グラフを識別するために、ビッグデータ・マップリデュース構造において反復プロセスを実施することができる。例示的な実施態様では、連結グラフは、例えばオープンソースのＡｐａｃｈｅ ＨａｄｏｏｐでＧｉｒａｐｈとして実施され、大規模な連結グラフを達成することができる。提案されたグラフは、コモディティハードウェアから構築されたコンピュータクラスタ上の大きなデータセットの分散格納および分散処理のための他のソフトウェアフレームワークにおいて実施することができ、そのような可能な実施は全て本開示の範囲内にあることを理解されたい。

図４は、本開示の一実施形態による、複数のデータソースから包括的な動的連結モデルを作成するための例示的なシステムを示す。図４に示すように、（システム２００のモジュールを使用する）システム４００は、発見された全てのハードウェア・エンティティおよびソフトウェア・エンティティについて、ＤＴＣから有向連結グラフ４０２を生成する。例示的な実施態様では、システム４００は、フォルトツリー／ＤＦＭＥＡ４０６、１つ以上の部品リスト４０８、ＤＴＣおよび１つ以上のＰＩＤリスト４１０、サービスマニュアル分析結果４１４、埋め込みコード４１６、部品ライブラリ、変更追跡記録および履歴、特に同様の入力ソースなどの入力データソースを解析し、モデルクエリ分析４１８および関数従属関係４０４などの分析を行うことによって有向グラフ４０２を生成することにより検索／発見されたエンティティを分析することによって、有向連結グラフ４０２を作成／生成する。一態様において、システム４００は、有向連結グラフ４０２に基づいて、モデルクエリ分析４１８を容易にすることができる。

一態様において、連結モデル／連結グラフが準備されると、診断または予測を行うために、再帰的クエリ（コード）は、目的とするエンティティ（親エンティティ／ノードと呼ばれる）から始まり、連結された全てのエンティティが提供されるまで、その子を、次いで子の子を徹底的に検索することができ、データリストには更なる子を見つけ続けるためのデータがなくなる。

図４に示すように、システムは、システムエンジニアリング文書、ソフトウェアコード、メンテナンスマニュアルなどの１つまたは複数の入力ソースから全ての関連知識を抽出し、モデルとして機能する連結グラフを作成することができる。例示的な実施態様において、エンティティ間の連結（エッジ）は、入力内に含まれる情報に従属して作成することができる。更に、ある入力ソースに現れる頂点（エンティティ）が別の入力ソースにも出現して、入力ソース間での連結を作成し、複数の入力ソースをリンクすることがある。例示的な実施態様では、全ての未処理文書／入力は、これまでモデルまたは連結モデルと呼ばれているこの連結グラフを生成するためのデータとして役立つ。このシステムは、顧客文書から目的とする潜在的なエッジを抽出し、長い親子リストを作成する。例示的な実施態様では、目的とする開始頂点（エンティティ）が与えられた場合に、スクリプトを使用して、連結された全てのエッジのチェーンを抽出することができる。目的とするサブグラフは、任意の所与のエンティティについて同様に抽出することができる。

例示的な実施態様では、入力データ（顧客データ）を受け取ると、システム４００は入力データ（例えばソースコード）に関するＹＵＣＣＡ Ｓｏｆｔｗａｒｅ Ｄｅｐｅｎｄｅｎｃｙ分析を行って、各行にどの親変数がコードの行からの子変数の影響を受けるかが記述された親子リストの形式で解析出力を生成することができる。コード内のみにあって、コントローラからの入力や出力を表さないいくつかのコード変数が存在する場合があるため、このシステムは、入力データソースとして提供される他のいくつかのテーブル（例えば、図５に示すようなテーブル）と共にこのリストを追加することができる。理解できるように、異なるエンティティが追加される順序または切断されたデータがこの長いリストに追加される場合の順序は、最終結果の相違を生じない。長いリストは、目的とする全ての可能なエッジの入力データからの包括的なリストであり得る。例示的な実施態様では、システムは、目的とするＤＴＣ（Ｄｉａｇｎｏｓｔｉｃ ｔｒｏｕｂｌｅ ｃｏｄｅ）から開始し、関心のサブグラフを抽出するためにコード（開示文書に記載されたフローチャート）を使用することによって、予測または診断を可能にする。このシステムは、顧客から目的とするＤＴＣのリストを受け取り、これらのＤＴＣを含む包括的な連結モデルを作成することができる。

一実施形態では、連結グラフの全ての潜在的な頂点およびエッジは、入力データ（顧客文書とも呼ばれる）から収集される。一実施態様では、提案されたシステムはＹＵＣＣＡ（または他のＳｅｑｕｅｎｔｉａｌ ｔｏ Ｐａｒａｌｌｅｌ自動コード変換ツール）を使用して、コントローラにフラッシュされたコード（入力ソース）を解析してＤＴＣ間のエッジ（それらをセット／リセットするための決定は全面的にコード内で行われる）およびコントローラの入出力として動作するソフトウェア変数を判断することができる。顧客の提供するテーブル（エンジニアリング文書）を使用し、テーブルのどの列に目的とする頂点およびエッジが含まれ得るかを決定するように、システムを構成することができる。システムは、プラットフォームの健康関連情報を含み得る列を決定することができる。ドキュメントのフォーマットに応じて、情報抽出には、例えばソフトウェアソースコードの場合、文書の解析が含まれ得る。同様に、自然言語で書かれたワード文書は、自然言語処理（ＮＬＰ）を使用して解析されて、潜在的なグラフ関連情報（頂点およびエッジ）を抽出することができる。

図５は、本開示の一実施形態によるソフトウェア分析に基づいて作成された例示的な可変従属関係テーブルを示す。図５に示すように、テーブル５００は、親エンティティを列挙する親列５０２と、対応する親エンティティの直接的な子エンティティを列挙する子列５０４とを含む。図５において、例示的な実施態様では、ＶＡ５が開始頂点（親ノード）として与えられる場合、提案されたシステムは、親子リスト／グラフ／モデルを使用して、ＶＡ５に連結された全てのエッジを詳細に考察し、連結された頂点および連結された頂点の下流に連結された全ての頂点を見つける。ＶＡ５に関する例示的な従属関係グラフは、エンティティ（頂点）ＶＡ４、ＶＡ６、ＶＡ７、ＶＡ８、ＶＡ９、ＶＡ５３および８を含むことができる。ＶＡ４、ＶＡ６およびＶＡ７は親ノードＶＡ５の直接の子ノードである。ＶＡ５３と８はＶＡ７の直接の子ノードである。ＶＡ８とＶＡ９は親ノードＶＡ６の直接の子ノードである。

図６は、車両の部品Ｐ１に関する例示的な連結サブグラフ６００を示しており、ここで、Ｐ＊は１つ以上の部品を示し、ｆｎ^＊は１つ以上の影響を受ける機能を示し、Ｒ^＊は１つ以上の修正動作を示し、ＲＡ^＊（図示せず）は修理動作を示し、ＲＣ^＊は故障発生点／故障モードを示し、Ｔ^＊は試験に関係し、Ｔ^＊−Ｒ^＊は試験Ｔ^＊の結果Ｒ^＊に関係する。

他方、図６Ｂは、複数のサブグラフ、ＤＴＣリストに基づいて生成された第１のサブグラフ６５２、ＹＵＣＣＡからのソフトウェアコード変数従属関係に基づいて生成された第２のサブグラフ６５４、部品リストに基づいて生成された第３のサブグラフ６５６、アセンブリに基づいて生成された第４のサブグラフ６５８、コントローラＩ／Ｏに基づいて生成された第５のサブグラフ６６０、顧客間の部品故障に関する部品共通ドメイン知識に基づいて生成された第６のサブグラフ６６２、および電気回路に基づいて生成された第７のサブグラフ６６４を含む。そのような連結グラフ６９０は、必要なサブグラフまたは必要な情報を抽出するために、ノード、エッジ、それらの特性、および連結するネットワーク経路に基づいて監査および照会することができる。一態様において、各サブグラフは、それ自身のサブグラフデータベースを有することができ、これは連結グラフ６５０を生成している間に集約することができ、あるいは別の代替実施態様では、単一のグラフデータベースを全てのサブグラフに関して共に生成することができ、これらは双方とも例示的な実施態様であり、グラフデータベースを生成し、かつ、それに基づいてグラフモデルを提示する他の任意のモードは、本発明の範囲内に完全に含まれる。

本開示のシステムおよび方法は、エンティティ情報を抽出し、１つまたは複数のデータソースから検索されたエンティティの従属関係を示す所与の複合プラットフォームの連結グラフを作成する。例示的な実施態様では、本開示のシステムおよび方法は、車両の機械的健康関連情報を生成するために使用することができる。

理解できるように、提案されたシステムによって作成された連結グラフにおいて、推測的なスキーマは必要ない。このような連結グラフの連結は入力データソースから作成することができ、連結グラフは、生成されると、あるスキーマパターンを明らかにし得る。提案されたシステムでは、診断情報が特定のスキーマ構造に適合する必要はない。

一態様において、提案されたシステムは、同じ入力データからそれほど詳細ではないまばらなモデルを生成する固定スキーマをベースとするＤＢ方法と比較した場合、モデルの非常に詳細な連結情報を有する所与の入力データに対して包括的な連結グラフを生成する。

理解できるように、本明細書で説明するシステムおよび方法は、再帰的クエリによるスケーラブル（ビッグデータおよび分散クエリの実施を伴う）かつ徹底的なモデル構築アプローチを提供する。作成されたモデルは、既存のアプローチと比較して安定しており、文書の解析はほとんど必要ない。本開示のシステムおよび方法は、固定スキーマに限定されず、したがって、ＤＢアプローチよりも柔軟性がある。厳密なスキーマにデータを適合させるには、データを正確に解析する必要があり、これにより解析作業が増加し、結果としてデータ内の全ての関連する詳細を取り込めなくなる。一方、提案されたアーキテクチャ／システムは、より柔軟性があり、解析が少なくて済むだけでなく、より詳細な情報を容易に生成することができる。また、既存の典型的な構造化ＤＢアプローチでは、全てのデータは、通常、１つのサーバーに格納されている１つのＤＢに格納する必要があり、これは、１つの演算リソースによって処理され得るデータ、モデルおよびクエリの量を限定し、また、クラッシュやデータの損失に対しても脆弱になる。他方、提案されたシステムおよび方法は、データおよびグラフを異なるコンピュータに分散することができるビッグデータ・アプローチを使用する。例示的な実施態様では、大規模なグラフ化またはモデリングを、本開示のシステムを使用して行うことができる。例えば、ソーシャルメディアや他の業界などのアプリケーションでは、Ｇｉｒａｐｈまたはそのような他の任意のグラフデータベースを使用して、顧客／業界／仕様提供データからの連結グラフを格納および照会することができる。ＮｅｔｗｏｒｋＸ、ＯｒｉｅｎｔＤＢ、Ｎｅｏ４ｊは、より小さいグラフ用の他のグラフデータベースである。例示的な実施態様では、本開示のシステムは、問題のサイズおよび必要性に応じて、これらのタイプのグラフデータベースのいずれかで実施され、完全にスケーラブルにすることができる。

図７は、本開示の一実施形態により、どのようにサブグラフを作成し、次いで一緒に処理してスーパーグラフを生成することができるかを示す。図示されているように、ノード間の関係に基づいてエッジによって連結されたノードのリストを与えるために、ＤＴＣマスターリスト７０２がＹＵＣＣＡコントローラ７０４に基づいて処理されたときに、第１のサブグラフを作成することができる。ここでノードおよびエッジはグラフデータベースに格納されている。第２のサブグラフは、ＤＴＣ従属ソフトウェア変数７０６に基づいて生成することができる。同様に、コントローラＩ／Ｏリストテーブル７０８を使用して処理される物理Ｉ／Ｏソフトウェア変数７１０に基づいて、第３のサブグラフを生成することができる。別の例示的な第４のサブグラフは、回路図抽出テーブル７１２に基づく入力としてＥＣＵピンコネクタ７１４の処理に基づいて生成することができる。第５の例示的なサブグラフは、回路コード、連結記述および装置を有する回路図７１６を使用して、回路コネクタおよびデバイス記述７１８の処理に基づいて生成することができる。このように生成されたサブグラフの全てを集約して、図６Ｂに示すようなスーパーグラフを生成することができる。

同様に、別の例示的な実施態様では、ＳＤＡ、ＩＯ、および回路図などの顧客車両データを使用して、第１のグラフデータベースおよび結果として得られるサブグラフ（エッジおよびノードを示す）を生成することができ、部品命名規約などの顧客語彙を使用して、第２のグラフデータベースおよび結果として得られるサブグラフ（エッジおよびノードを示す）を生成することができ、顧客間のドメイン知識を使用して、第３のグラフデータベースおよび結果として得られるサブグラフ（エッジおよびノードを示す）を生成することができ、最終的に３つのサブグラフの全てを組み合わせて、結合された／スーパーグラフを生成することができる。

図８は、本開示の一実施形態による変数従属関係分析を示す例示的なフロー図を示す。図８に示すように、所与のデータフローグラフ（ＤＦＧ）８０２のための変数従属関係分析（ＶＤＡ）を行う方法は、ステップ８０４に示すように複合プラットフォームによって使用される関数を再帰的に探索するステップと、ステップ８０６に示すように関数の式を読み取るステップと、ステップ８０８に示すように式から全ての書き込まれた変数を収集するステップとを含むことができる。この方法は、ステップ８１０に示すように式（正規式など）から他の影響する変数を収集し、ステップ８１２に示すように関係を出力ｘｍｌに更新するステップを更に含むことができる。

図９は、本開示の一実施形態による所与の親のエンティティの連結されたチェーンを作成するために使用することができる例示的なフロー図９００を示す。例示的な実施態様では、入力データを解析し、関連するエンティティ／変数を検索した後に、連結されたエンティティのチェーンを作成することができる。図９に示すように、ステップ９０２に示すように、特定された親ノードについてチェーンが形成される所与のデータリストに対して、提案された方法は、ステップ９０４に示すように、親エンティティが他の子を有するかどうかを再帰的にチェックし（親が存在するまで、つまり、親の値はＮＵＬＬではない）、ステップ９０６に示すように、複数の演算装置上に分散された所与のデータリストを使用して親ノードの全ての直接の子を検索することができる。この方法は、次に、ステップ９０８に示すように、全ての演算装置から親ノードについて得られた子の和集合を行うことによって、チェーンにない固有の子を保持することができる。この方法は、次に、ステップ９１０に示すように、チェーンおよび識別／保持された固有の子の和集合としてチェーンを更新することができる。ステップ９１２では、識別／保持された固有の子が次の反復の親として作成され、ステップ９０４から９１０は、９０４で述べられた条件が存在するまで、すなわち潜在的に割り当てられた親ノードが存在するまで再帰的に実行される。

図１０は、本開示の一実施形態による、１つまたは複数のデータソースからエンティティ情報を抽出し、それに基づいて可変関係テーブルを作成するための例示的なブロック図を示す。例示的な実施態様において、提案されたシステムは、入力データ１００２（例えばＣコード）を受信すると、受信した入力データ１００２に対してＹＵＣＣＡソフトウェア分析ツール１００４を使用してＹＵＣＣＡソフトウェア従属関係分析を行うことができる。本発明の例示的な実施形態をＹＵＣＣＡ従属関係分析に関して説明したが、任意の他の同様の分析ツールを使用することもできる。例示的な実施態様では、提案されたシステムは、従属関係分析を行った後、例えばＸＭＬ形式でまたは図５に示すような論理テーブルとして格納することができる可変関係テーブル１００６を出力することができる。

例示的な実施態様では、ソースコードなどの入力１００２をＹＵＣＣＡによって処理して、各行にどの親変数がコードの行からの子変数の影響を受けるかが記述された親子リスト形式の形態で解析出力を生成することができる。コード内にあって、コントローラからの入力や出力を表さないいくつかのコード変数が存在する場合があるため、システムは、このリストに入力データソースとして提供される他のいくつかのテーブルを追加することができる。

一態様において、提案されたシステムは、変数、アレイ、条件文、ループ、ポインタ、関数ポインタ、関数呼び出しおよび定義、システム呼び出しなどの異なるプログラミング・エンティティを含み得るＣコードを受け取り、従属関係マッピングを含む出力としてＸＭＬファイルを生成することができる。ＸＭＬは２つのセクションを含むことができ、これらのセクションの１つは変数間の１次関係を含むことができる。簡単な出力例を以下の実施例１に示す。最後の出力は、例に示すように直接変数名を持たず、代わりに変数ＩＤで表現して、類似した名前と異なる可視性を持つ変数を区別することができる。システムは、同じＸＭＬファイルの第２セクション（メタデータ）から変数名および宣言場所、ファイル名、変数のタイプのような他のプロパティを取り出すことができる。
実施例１：
ステートメント「ａａ＝ｂｂ＋ｃｃ」を考慮する；
変数「ａａ」は変数「ｂｂ」と「ｃｃ」の両方に影響を受ける。
したがって、生成される出力には以下の記録がある。

例示的な実施態様では、上述したシステムおよび方法を使用して、変数更新、ポインタ解決、制御フロー、およびデータフローに関する完全なコードの分析を必要とするシステム分析を行うことができる。これは複合プロセスなので、ソフトウェアは、１）フロントエンド、２）バックエンドの２つのモジュールに分けることができる。
フロントエンド：コードスキャナとパーサ

本開示のシステムを使用してフロントエンド分析を行うために、入力Ｃソースコードをスキャンし、パースしてトークン（関数名、変数、ポインタなど）を識別し、それらの情報（例えば、宣言ファイル名、行番号など）をマッピングすることができる。これらの関係は、更なる使用のために（例えば）ＸＭＬファイルに入れることができる。バックエンドはコンパイラ指令を処理することもできる。
バックエンド：コード分析

本開示のシステムを使用して、コード分析とも呼ばれるバックエンド分析を行うために、フロントエンドで生成されたＸＭＬファイルを入力として与えることができ、このシステムは、ＸＭＬファイルからＣＦＧ（制御フローグラフ）やＤＦＧ（データフローグラフ）を生成することができる。ＤＦＧ内の全てのステートメントを分析して、意図した可変関係出力を生成することができる。

生成されたデータフローグラフ（ＤＦＧ）には、変数名や操作だけでなく、更に多くのデータが含まれている場合がある。生成されたデータフローグラフ（ＤＦＧ）には、特定のステートメントで変更される変数に関連する情報を含めることができる。正確には、参照渡しされた引数で関数呼び出しが発生すると、モジュールは呼び出された関数を解析して、渡された引数が関数呼び出し内で変更されているかどうかを探し出す。変更された場合、変数は変更済みとしてマークされる。このモジュールは、あらゆるレベルの関数呼び出しで可変の書き込み／変更を識別するのに有力である。図１１Ａは、変数が書き込まれまたは変更され得る例を提供する。

例示的な実施態様では、ＤＦＧモジュールは、ポインタおよび関数ポインタも推定することができる。したがって、ＶＤＡ（変数従属関係分析）で式を処理している間に、ポインタ変数を盲目的に見るのではなく、実際にどの値が他の変数に影響を及ぼしているかを見ることができる。したがって、ＤＦＧは簡単なテキスト検索に基づいているのではなく、コードの詳細な分析に基づいている。ソフトウェア分析には、変数の更新、ポインタ解決、制御フロー、およびデータフローに関する完全なコードの分析が必要である。

システムは、図８で説明した方法を使用して、可変従属関係分析を行うことができる。図８に示すように、システムは、プログラムと同様の構造を有してもよいＤＦＧツリー構造を受信する。システムは、関数と、リンクリストで表されるこれらの関数内のステートメント／式を有する。ＤＦＧツリーの第１レベルに存在する関数は、関数が残存しなくなるまで次々と解析され得る。関数内の式は、ＤＦＧツリーの関数ブロックの下にリンクすることができる。各式を分析して、従属変数とインフルエンサ変数を識別できる。全ての変数が収集されると、システムは、これらの変数を、例えばＸＭＬファイルに入れることができる。

［従属関係およびインフルエンサの識別］
例示的な実施態様では、提案されたシステムは、従属変数およびインフルエンサ変数を識別することができる。従属変数は、コード式で変更される変数である。インフルエンサ変数は、従属変数に割り当てられた値を集合的に生成する変数である。システムは、異なるシナリオを使用して、従属変数および影響を与える変数を識別することができる。１）簡単な代入式、２）条件、３）関数呼び出し、４）システム呼び出し、５）コンパイラ指令。

［１．簡単な代入式］
これらは、基本的で単純な変数変更式である。従属変数を特定することは、式のＬＨＳを見つけることと同じくらい簡単である。ＲＨＳ上の全ての変数は影響を与える変数である。ＲＨＳで関数呼び出しがある場合、戻り変数とその関数に渡されたパラメータはＬＨＳに影響する。関数内で読み取られる引数変数は、影響を与える変数として追加されるだけであり、残りの未使用の引数は破棄できることに留意されたい。

［２．条件］
条件ブロック内のステートメントは、条件が満たされた場合にのみ実行される。したがって、条件内で使用される変数は、実際には、これらの条件ブロック内にある全ての従属変数に影響を与える。これは、「ｅｌｓｅブロック」にも適用される。なぜなら、条件変数が影響を与えて条件を満たさない場合にのみこのブロックが実行されるからである。ネストされたｉｆ−ｅｌｓｅブロックの場合、異なる親ブロック内の先行する全ての条件変数は影響を与える変数とみなされる。同じことが全てのスイッチブロックに当てはまる。

［３．関数呼び出し］
関数呼び出しは、戻り値をキャッチせずに、または式内で自動的に検出される可能性がある。どちらも、従属変数と影響を及ぼす変数を検出するために処理される。関数呼び出し中に、関数定義内のステートメントが実行される。したがって、呼び出しサイトで内部操作を見つけることはできないかもしれないが、操作がインラインであると仮定する必要があり得る。関数が自動的に呼び出されるときは、参照渡しのポインタ引数をチェックすることが重要である。これらのパラメータは、関数内で変更が確認され、呼び出しサイトの行番号で従属変数であるとみなされる。この分析は、関数呼び出しが式の中にあっても行われる。この式は、ｉｆまたは代入操作の条件になる可能性がある。

［４．システム呼び出し］
システム呼び出しは、プログラムからのオペレーティングシステム（ＯＳ）要求である。これらの関数／呼び出しの本体は、一般にクライアントによって提供されていないため、手作業で処理するために、これらのシステム呼び出しの機能を取得することが可能である。取得する必要のある関係は、引数間の関係でも、引数とシステム呼び出しの戻り値との間の関係であってもよい。これらの関係は、既知のシステム呼び出しが見つかると自動的に追加される。
実施例３Ｒｅｐｏｒｔ＿Ｅｒｒｏｒ（ＥＲＲＯＲ ＩＤ ２３４）；
このようなシステム呼び出しは非常に一般的であり、ＥＣＵの問題を特定するのに必要である。この呼び出しの一般的な機能は、グローバルエラーステータスを、引数として渡されたエラーＩＤに更新することである。この場合、グローバルエラーステータスはエラー＿ＩＤ＿２３４で更新される。

［５．コンパイラ指令］
コンパイラ指令はコードを少し変更してコードを構成するのが便利である。要約すると、コンパイラ指令は編集が必要なコードを設定する。コンパイラ指令に基づいて編集時に解決される定数や関数が存在する可能性がある。フロントエンド（スキャナとパーサー）は、これらのコンパイラ指令を解決し、実行される実際のコードを提供する。図１１Ｂは、ディレクティブを使用したコード選択の例を示す。

ほとんどの開発者は、これらのディレクティブを使用してパフォーマンスの向上と管理性を実現している。しかし、そのような場合、システムはフロントエンド処理中にいくつかの変数／マクロを見逃す可能性がある。プログラム分析の一貫性を維持するために、本開示のシステムは、処理中にコンパイラ指令を操作するのではなく、これらのマクロをフロントエンドと平行した別個の手順として扱う。

一態様において、提案されたシステムは、マクロ使用の場所を収集し、対応する式での影響を及ぼす変数としてそれらを使用することができる。マクロは常に定数であり、実行時にこれらの変数を変更することは不可能であるため、常に影響を受け、従属することは決してないと仮定することは安全である。

また理解できるように、提案されたシステムは変数従属関係のチェックを行うために完全なコードを解析するので、変数従属関係よりもはるかに多くの情報を有する可能性がある。例えば、システムは特定の従属関係の行番号を持つことができる。同様に、システムはファイル名、親関数、条件ネストレベルなどを各従属関係ごとに収集することができる。この情報は、更なる分析に役立ち、要件に基づいて出力ＸＭＬで提供することができる。

更に、変数の概念タイプを抽象化して、変数の車両の特定のサブシステムとの関連を特定することが重要である。例えば、ＣＡＮメッセージまたは特定のＥＣＵの内部物理ピン値に起因してエラーが発生したかどうかを知ることが望ましい。変数の概念タイプを抽象化することは、コード内の標準情報の欠如によるコード分析に基づいては不可能である。しかしながら、開発者は管理性のための変数の命名規則をよく維持していることが確認される。例示的な実施形態では、提案されたシステムは、この情報を利用して可変タイプを識別することができる。システムは開発者から命名規則を取得し、パターンマッチングを使用して個々の変数タイプを識別することができる。開発者がコード化規則を維持していない場合や、個々の開発者がその規則に従わない場合、変数の分類は不可能である。

観察できるように、相互通信のために車両システムにわたって使用されるいくつかのシステムレベル変数が存在する。このような変数は、標準的であり、各システム（例えば車両）に固有であり、通常は適切に文書化されている。開発者は、通常、これらの概念タイプの変数をテキストファイルのペアとして提供する。これを基にして、提案されたシステムは分析中にこれらのファイルを使用して、モデルとしてＸＭＬファイルに取り込むことができる。

本開示は、車両健康評価／診断／予測／管理におけるアプリケーションに関して説明されているが、提案された発明の連結グラフは、他の任意のアプリケーションにおいても使用され得、そのようなアプリケーションは全て、本開示の範囲内であることが理解される。

一態様において、１つまたは複数のエンティティの従属関係分析に基づいて生成され、エンティティと関連する変数との間の関係を反映する提案された連結グラフは、ソフトウェアシステムエンジニアリング、データ分析、金融取引、ブロックチェーン取引、ビッグデータ、特に同様のアプリケーションなどの業界／技術にわたるシステムエンジニアリングアプリケーションにおいて使用することができる。例えば、連結グラフを使用して連結性の崩壊を識別し、それらを解決するのを助けることができる。連結グラフモデルを構築している間に、異なる入力ソースからのデータをグラフデータベースにインポートすることができる。これらの入力ソースは異なるエンジニアリングサイロで開発されるため、第１のエンジニアリングサイロからの１つまたは複数のデータノードは、ロジックまたはシステムエンジニアリングの理解に基づいて予想されるように、第２のエンジニアリングサイロ内のデータに連結していなくてもよい。例えば、ソフトウェアコードの特定の電圧センサのＤＴＣノードは、配線図をインポートして取得した電圧センサに連結することができない。しかし、それらは連結することが期待されるため、この連結性の崩壊は、いずれかの入力ソースの欠落、不一致、または不良データのために発生する可能性がある。本開示の一態様において、提案されたグラフデータベースは、そのような場合に、センサの他のノードへの連結性を見つけるために容易に照会することができ、ＤＴＣのネットワークを見つけるために照会して、それらが連結されていた場所を決定し、次いで、そのデータが入力ソースで利用できなかった理由を探す。これは、重要なデータを正しく取り込むために、エンジニアリング入力ソースやシステムエンジニアリングの方法とプラクティスの修正と改善につながる可能性がある。

更に、本開示の態様は、提案された連結モデル／グラフが準備されているとき、モデル内の１つの部品、サブシステム、またはシステムがどのように他の部品、サブシステム、またはシステムに連結するかを決定するためにモデルを照会することができるインタフェース（連結性）モデルを開発するために使用することができる。照会結果は、システムエンジニアリングのインターフェイスモデルとして機能し得る必要な連結性情報を記述して、同じページ上で互いに連結する異なるシステム上でのチームの動作およびそれらの連結を保持することができる。あるチームがこのインターフェイスを介して別のチームからの特定の信号を期待しているが、このインターフェイスで利用できない場合は、このインターフェイスモデルで簡単に見ることができ、デザインを修正することができる。

本開示の態様はまた、強力なクエリを実行することができる製品開発サイクルの任意の時点におけるプラットフォームの包括的かつ信頼すべき１つの状態を全てのシステムエンジニアリンググループに提供することができる。例えば、製品開発中に異なるサイロで作業する異なるチームが、サイロの他のシステムに影響を与える変更を行う場合、その情報は容易に理解できず、全てのサイロで利用することはできない。異なるサイロからのデータソースと共同で作業しているグラフモデルは、開発と変更が今日どこにあるかについて興味のある人に知らせることによって、誰をも同じページ上に維持することができる。例えば、システムの構築中に、いくつかの設計変更が行われ、メンテナンスマニュアル作成チームが、いくつかの変更後に廃止されたシステムエンジニアリングから受け取った最後の入力ソースに基づいて、この変更システムのマニュアルを作成しようとしている可能性がある。このグラフモデルにアクセスする場合は、最新の状態を知ってマニュアルを正しく作成し、再作業を避けて、セールスリリース前にマニュアル作成作業を完了する。

本開示の態様は、更に、システムエンジニアリンググループ間のコラボレーションを増やす助けをする。提案された連結モデルを使用して、あるサイロ内での変更の、別のサイロに対する影響および結果を容易に理解し、そのような変更を行う前に、異なるサイロが集結し、影響を効果的に管理することによって、通常はタイムラインが非常にタイトとなる開発サイクルで後で問題を避けることができる。

本開示の態様は、問題が他のエンジニアリングサイロに伝播する前に、それら問題の発見および解決を更に可能にすることができる。提案された包括的なグラフモデルは、システム全体に及ぼされる変更の影響を評価し、問題を早期に発見するための強力なクエリを可能にし、全ての関係者に通知するのを容易にする。一態様において、提案されたアーキテクチャは、更に、ＥＣＵに連結された全てのセンサおよびアクチュエータについてモデル化された電力消費を伴うＥＣＵ電力消費分析を可能にし、それにより、ＥＣＵおよびＥＣＵに連結された全てのセンサおよびアクチュエータの電力消費定格に関するデータがそれらのデューティサイクルに沿って利用可能である場合、それらセンサとアクチュエータの特性として取り込まれる。これにより、提案されたシステムのユーザは、ＥＣＵの消費電力、複数のＥＣＵ間の電力消費の比較、複数の設計構成のモデル照会を行うことができる。デューティサイクル改善の機会を特定して、より効果的なアクチュエータ駆動アルゴリズムを探索できるように使用することができる。

本開示の態様は、システムに対する任意の変更に関連するｗｈａｔ−ｉｆ分析を更に可能にすることができる。設計変更が評価される場合、または複数の設計オプションが評価される場合には、それらを全てモデルに追加することができ、モデルを照会して、各設計がシステム全体に与える影響を評価することができる。ｗｈａｔ−ｉｆ分析はシステムのどの部分が変更の影響を受けるかを判断するためにも使用でき、それにより、システム全体ではなく、それらの部分に限定して試験を行うことができる。現場の車両に問題が発生し、問題を解決するために設計／ソフトウェアの変更が行われる場合、ＯＥＭは、車両が修理のために回収される前に、修理によってシステムの残りの部分に予期しない結果が生じないかどうかを知る必要があり、これは高価で時間がかかる大規模なフィールド試験によって行うことができる。一方、本発明のグラフモデルへのクエリは、これらの変更が影響を及ぼす可能性があるサブシステムおよび個々の部品を容易に識別することができ、試験はそれらの部品およびサブシステムのみに限定することができる。本開示の態様は、待ち時間がモデルに取り込まれる場合、ＤＴＣ−故障発生点待ち時間分析も可能にし、これにより、入力を提供する際にソフトウェア変数を演算する際の待ち時間が利用可能であれば、それをエッジプロパティとしてモデル化することができる。車両ハードウェアの特定の故障発生点（ｐｏｉｎｔ ｏｆ ｆａｉｌｕｒｅ）がアクティブになると、グラフモデルは、それが起動するソフトウェア変数を通知できる。その間に、トリガされたソフトウェア変数とＤＴＣとの間の最短経路および最長経路を用いてＤＴＣをトリッピングするための待ち時間を推定することができる。

本開示の態様はまた、診断の検出可能性（範囲）を決定するのに役立ち、故障発生点および可能な全ての証拠（修理、試験、ＤＴＣ、観察などの、どの故障発生点がアクティブであり得るかに関する情報を提供するエンティティ）のマトリックスが、グラフモデルを照会することによって得られ得る。そのようなマトリックスは、故障発生点の各々がどのように検出され得るか、および検出され得るか否かを示すことができる。故障発生点の検出可能性を向上させるために、このマトリックスに基づいて別の試験またはＤＴＣを追加するのを決定することができる。検出可能性はまた、センサを追加するまたは設計から除去するための費用を正当化するために使用することができ、検出可能性マトリックスに基づいて複数の方法で特定の故障発生点を検出できる場合には、大きな結果を伴うことなく、それを検出する方法の１つを除去することができる。例えば、異なるセンサに関連する複数のＤＴＣが故障発生点を検出する場合、センサが他の重大な用途を有していなければ、おそらくそれらセンサの１つおよび関連するＤＴＣをシステム設計から除去することを考慮することができる。同様に、検出可能性マトリックスに基づいて検出することが困難な故障発生点が存在し、この故障発生点のアクチベーションが、他の部分に急速に蓄積する損傷および高価な修復をもたらし得る場合には、この故障発生点に関する情報を提供する新しいＤＴＣにリンクし得るセンサの追加は、そのような修理の平均費用とセンサの追加費用に重みを付けることによって考慮することができる。

本開示の態様は、初期メンテナンスマニュアルを開発するために使用することもでき、グラフモデルは、部品、それらの故障発生点、それらを検出するＤＴＣ、それらを識別する試験およびそれらを修復する修理に関する全ての連結性情報を有する。モデルクエリは、ＤＴＣごとに影響を受ける可能性のある部品、試験および修理を生成することができる。これは、各ＤＴＣの初期メンテナンスマニュアルになる。モデルは、ＤＴＣのグループのメンテナンスアクションを提供することもできる。

本開示は、システムの診断および予測を効率的に行うための包括的な連結モデルを作成するのに役立つ。

本開示は、様々な入力ソース、例えば異なるエンジニアリング文書、ソースコードなどから、包括的な連結モデルを作成するのに役立つ。

本開示は、ハードウェアシステム（例えば、機械プラットフォーム）およびソフトウェアシステムの診断および予測のためのモデルの作成に役立つ。

本開示は、様々なエンジニアリング文書間のデータギャップを明らかにし、エンジニアリングアーチファクト間のデータ不一致を明らかにし得る効率的なモデルを作成するのに役立つ。

本開示は、故障／エラーに影響し／を引き起こす可能性のある部品またはソフトウェア変数を決定するために使用できる包括的なモデルを提供する。

本開示は、診断推論に使用することができる効率的な連結モデルの作成を可能にする。

以上、本発明の様々な実施形態について説明したが、本発明の基本的な範囲から逸脱することなく、本発明の他のおよび更なる実施形態を考案することができる。本発明の範囲は、以下の特許請求の範囲によって決定される。本発明は、当業者に利用可能な情報および知識と組み合わせた場合に、当業者が本発明を製作および使用できるようにするために含まれる記載された実施形態、変形例または実施例に限定されない。

［発明の効果］
本発明は、既存のモデルと比較してスケーラブルで柔軟なモデルを提供する。

本発明は、より大量のデータの処理およびそのようなデータの照会を可能にする。

本発明は、演算を遅らせることも、システムクラッシュを引き起こすこともない連結グラフアーキテクチャを可能にする。

本発明は、分散環境においてデータを処理する能力を有する。

本発明は、予め定義された入力スキーマおよび構造化データベースの使用を必要としない連結グラフモデルを可能にする。

本発明は、異なる入力文書からより包括的な連結モデルを提供する。

本発明は、分析、診断、システムエンジニアリング、サポート、予測、特に同様の機能などのためにシステム全体を連結するモデルを提供する。

本発明は、システムモデルから呼び出しグラフを生成するための堅牢なシステムを提供する。

本開示は、構造化ＤＢを照会することと比較して、グラフを簡単に解析するためモデル構築努力を一桁分減少させることができる。

本開示は、モデル構築努力を減少させることを可能にし、付加的な費用なしに全ての利用可能なモデルの詳細を組み込むことを可能にする。

本開示は、より正確な診断をもたらす連結モデル／グラフを提供する。

本開示は、提案されたグラフＤＢ／データベースの使用により、クエリ速度およびクエリ深度が大幅に増加することを可能にし、これにより、リレーショナルデータベースで実行することが不可能な複合クエリが可能になる。更に、診断に必要なクエリはほぼ即座に実行できる。

Claims (11)

1. 機器プラットフォームの健康監視を可能にするように構成されたシステムであって、
   連結グラフの生成および詳細な考察を容易にするように動作可能な１つまたは複数のルーチンをその中で具現化した非一時的格納装置と、
   前記非一時的格納装置に連結され、前記１つまたは複数のルーチンを実行するように動作可能な１つまたは複数のプロセッサであって、前記１つまたは複数のルーチンが、前記１つまたは複数のプロセッサによって実行されると、複数の入力ソースから前記機器プラットフォームに関するデータを受信する入力データ受信モジュールを含み、前記受信したデータが前記機器プラットフォームの１つ以上のエンティティに関するものである、１つまたは複数のプロセッサと、
   前記１つまたは複数のプロセッサによって実行されると、前記受信したデータを分析し、少なくとも１つのエッジリストを作成することによって前記１つ以上のエンティティ間の従属関係を決定し、１つ以上のノードおよび複数のエッジを含むグラフデータベースを構築する従属関係決定モジュールであって、複数のエッジの各エッジが、開始ノードと終了ノードとを結びつけ、それらの間の関係を規定する、従属関係決定モジュールと、
   前記１つまたは複数のプロセッサによって実行されると、前記少なくとも１つのエッジリストから前記連結グラフを作成し、前記連結グラフをグラフデータベースまたはグラフライブラリに格納する連結グラフモデル作成モジュールであって、前記連結グラフが、ネットワーク・サブグラフ識別、ネットワーク・パス最短／最長パス、ノード、エッジ、ノードプロパティおよびエッジプロパティのいずれかまたはその組み合わせに関して照会可能である、連結グラフモデル作成モジュールと、
   を備えるシステム。
2. 前記複数の入力ソースは、システムエンジニアリング文書、ソフトウェア／ソースコード、１つ以上のフォルトツリー、シミュレーションモデル、ＤＴＣおよび１つ以上のＰＩＤリスト、サービスマニュアル、システムフォルトモデル、埋め込みコード、ＤＦＭＥＡ、１つ以上の仕様文書、配線図、油圧図、Ｓｉｍｕｌｉｎｋモデル、機械システムモデル、機械図面、シミュレーションモデルおよびメンテナンスマニュアルのいずれかまたはそれらの組み合わせから選択される、請求項１に記載のシステム。
3. 前記データは、１つまたは複数の分散型または集中型入力ソースから受信される、請求項１に記載のシステム。
4. 前記連結グラフは、入信データに基づいてそれ自身を変更する動的連結モデルに対応する、請求項１に記載のシステム。
5. 前記連結グラフは、複数のサブグラフを含み、前記複数のサブグラフは、２つ以上の演算装置にわたって作成される、請求項１に記載のシステム。
6. 前記受信されたデータは、前記連結グラフを生成しつつ前記データを効率的に処理するためのビッグデータ形式で構造化される、請求項１に記載のシステム。
7. 前記１つまたは複数のエンティティは、前記車両に関連するソフトウェアエンティティ、ハードウェアエンティティ、変数および部品のいずれかまたはそれらの組み合わせを含む、請求項１に記載のシステム。
8. 前記データ従属関係決定モジュールによる前記受信データの分析は、前記受信データを解析して、それぞれのノードプロパティを有するノードの形態で前記機器プラットフォームの前記１つ以上のエンティティを取得し、前記機器プラットフォームの取得された１つ以上のノードエンティティ間のエッジを決定することを含み、前記決定されたエッジの各エッジが、前記少なくとも１つのエッジリストを生成するエッジプロパティを有する、請求項１に記載のシステム。
9. 機器プラットフォームの健康診断および／または予測を可能にする方法であって、
   １つまたは複数の入力ソースから前記機器プラットフォームに関連する複数のエンティティを抽出するステップと、
   前記複数のエンティティを分析して１つ以上のノードを有するとともに、親ノードと子ノードとを連結し、それらの間の関係性を定義する１つ以上のエッジを有するグラフデータベースを生成するステップであって、前記生成されたグラフデータベースを使用して、グラフデータベースの代表であるとともに、グラフデータベースの変化に基づいて動的に変化する連結グラフを構築するステップと、
   クエリを受信し、前記受信されたクエリで言及された目的とする少なくとも１つのエンティティから始まり、目的とする少なくとも１つのエンティティの全ての子が詳細に考察されるまで連結グラフ上で受信したクエリを再帰的に実行することによって、前記連結グラフに基づいて診断および／予測を行い、これにより、少なくとも１つの目的とするエンティティに関して全ての連結されたエンティティを出力するステップと、
   を含む方法。
10. 前記１つまたは複数の入力ソースは、システムエンジニアリング文書、ソフトウェア／ソースコード、１つ以上のフォルトツリー、ＤＴＣおよび１つ以上のＰＩＤリスト、サービスマニュアル、システムフォルトモデル、埋め込みコード、ＤＦＭＥＡ、１つ以上の仕様文書およびメンテナンスマニュアルのいずれかまたはそれらの組み合わせから選択され、前記１つ以上のエンティティは、前記車両に関連するソフトウェアエンティティ、ハードウェアエンティティ、変数および部品のいずれかまたはそれらの組み合わせを含む、請求項９に記載の方法。
11. 前記連結グラフは、複数の連結サブグラフを含み、各連結サブグラフは、特定のタイプの入力ソースに関するものである、請求項９に記載の方法。