モデルベース診断インタフェース
【課題】モデルベース診断インタフェースのための方法および装置を提供する。
【解決手段】システム情報１１４と、システム１０２の状態を表すシステムデータ１０６とを有するシステム１０２用のモデルベース診断インタフェース１１２を作成するための方法が提供され、この方法は、前記システム１０２をモデル化して、システムモデル命名規則１０７を有するシステムモデル１０３を生成するステップと、前記システムモデル命名規則１０７に、前記システムデータ１０６をマッピング１４０２するステップと、前記システムモデル命名規則１０７にマッピングされた前記システムデータ１０６を前記システム情報１１４にバインド１５０２するステップとを備える。
【解決手段】システム情報１１４と、システム１０２の状態を表すシステムデータ１０６とを有するシステム１０２用のモデルベース診断インタフェース１１２を作成するための方法が提供され、この方法は、前記システム１０２をモデル化して、システムモデル命名規則１０７を有するシステムモデル１０３を生成するステップと、前記システムモデル命名規則１０７に、前記システムデータ１０６をマッピング１４０２するステップと、前記システムモデル命名規則１０７にマッピングされた前記システムデータ１０６を前記システム情報１１４にバインド１５０２するステップとを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、遠隔計測されるシステム（ｔｅｌｅｍｅｔｅｒｅｄ ｓｙｓｔｅｍ）用の診断システムに関する。本発明はより詳細には、既製市販（ＣＯＴＳ：ｃｏｍｍｅｒｃｉａｌ−ｏｆｆ−ｔｈｅ−ｓｈｅｌｆ）診断エンジンを使用する診断システムに関する。本発明はさらにより詳細には、遠隔計測されるシステムとＣＯＴＳ診断エンジンとの間のモデルベース診断インタフェースに関する。
【背景技術】
【０００２】
統合乗物健全性管理システム（ＩＶＨＭＳ：Ｉｎｔｅｇｒａｔｅｄ Ｖｅｈｉｃｌｅ Ｈｅａｌｔｈ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）は、複雑な工学システム内のそのシステム用に設計されたコンポーネントおよびサブシステムの異常に対して、準リアルタイムの修正応答を提供することを意図している。修正応答は、準リアルタイムの修正応答をサポートするために好ましくはリアルタイムに実行される、診断および予知診断に依存している。宇宙船、航空機、および船舶など、複雑な工学システムのリアルタイム自動診断が、漠然とした目標（ｅｌｕｓｉｖｅ ｇｏａｌ）となっている。
【０００３】
ＩＶＨＭＳの１つの要素は、診断エンジンとも呼ばれる診断ロジックであることができる。様々なタイプの診断エンジンが、当技術分野で知られている。例えば、合格／不合格基準を使用する診断エンジン、状態機械診断エンジン、ニューラルネット診断エンジン、およびデータマイニング診断エンジンが、ＣＯＴＳ製品として入手可能である。いくつかのタイプは、複数の発売元から入手可能であるが、その各々は、わずかに異なる入力データ用インタフェースを有している。様々なＣＯＴＳ診断エンジンは各々、独自の入力要件を有することができる。
【０００４】
診断エンジンは通常、非リアルタイムの後処理アプリケーションで使用される。診断エンジンは、その特定の診断エンジン用に特別にフォーマットされた入力を処理する。例えば、ある診断エンジンは、合格／不合格表示のみを受け入れ、別の診断エンジンは、一定の形式の状態変数を必要とし、さらに別の診断エンジンは、入力としてリレーショナルデータベースを利用することができる。ＣＯＴＳ診断エンジンの製造業者は通常、ＣＯＴＳ診断エンジン自体の最大性能を引き出す入力フォーマットを指定する。エンジンは、ＣＯＴＳ診断エンジンの製造業者がよく知らない多種多様なアプリケーションでも使用できるように設計されるので、特定の１組の利用可能なデータ用にＣＯＴＳ診断エンジンを調整することは、そのＣＯＴＳ診断エンジンのエンドユーザに任されている。受け入れ可能な入力形式でデータを提供することの代償は、ＣＯＴＳ診断エンジン間の切り替えに対してコスト上の障壁が築かれることであり、エンドユーザは不便でも特定の発売元に依存することになる。
【０００５】
ＩＶＨＭＳを使用するシステムを含む実際のシステムは、様々なシステム要素状態に関するデータを提供するために遠隔計測され得る。テレメトリ（ｔｅｌｅｍｅｔｒｙ）は、個々のデータフォーマット、データソース、および類似のデータ属性に関連づけられた、しばしば簡略記号または短縮形式をとるデータ名を含むテレメトリ命名規則（ｔｅｌｅｍｅｔｒｙ ｎｏｍｅｎｃｌａｔｕｒｅ）を有する。テレメトリ命名規則は通常、ＣＯＴＳ診断エンジンの入力要件と互換性がない。
【０００６】
実際のシステムはさらに、試験点でデータを提供することができ、組み込み試験またはその他の試験時に生成された試験データを提供することができる。試験点データは、テレメトリと類似することができるが、定期的に生成されない。試験データは通常、ＣＯＴＳ診断エンジンの入力データ要件と互換性がない試験データ命名規則（ｔｅｓｔ ｄａｔａ ｎｏｍｅｎｃｌａｔｕｒｅ）を有する。
【０００７】
テレメトリ命名規則、システムモデル命名規則、試験命名規則、試験点データ命名規則、およびＣＯＴＳ診断エンジン用の入力データ要件は、互いに相関性がなく、そのため、ＣＯＴＳ診断エンジン用の入力データを獲得するのに大きな労力が必要とされる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
したがって、大きな労力を必要としない方法でＣＯＴＳ診断エンジンに入力を提供するように、テレメトリ命名規則、システムモデル命名規則、試験命名規則、試験点命名規則を互いに相関させることが望ましい。また、互いに相関させた命名規則データと１つまたは複数のＣＯＴＳ診断エンジンの間にインタフェースを提供することが望ましい。
【課題を解決するための手段】
【０００９】
システムの状態を表すシステムデータと、前記システム内の関係に関するシステム情報とを有し、またモデル命名規則（ｍｏｄｅｌ ｎｏｍｅｎｃｌａｔｕｒｅ）をもつシステムモデルを有するシステム用の診断インタフェースのための装置が提供され、診断インタフェースは、前記システムデータに応答する出力を生成する少なくとも１つの演算オブジェクトを備え、前記少なくとも１つのオブジェクトは、前記システムデータの前記システム情報へのバインディングを含み、前記システムデータは、バインドされる前に前記モデル命名規則にマッピングされる。
【００１０】
システム情報と、前記システムの状態を表すシステムデータとを有するシステム用のモデルベース診断インタフェースを作成するための方法が提供され、この方法は、前記システムをモデル化して、システムモデル命名規則を有するシステムモデルを生成するステップと、前記システムデータを前記システムモデル命名規則にマッピングするステップとを備える。
【００１１】
これ以降、本発明が添付の図面と関連させて説明されるが、図面中では同じ番号は同じ要素を表す。
【発明を実施するための最良の形態】
【００１２】
以下の詳細な説明は、本質的に例示的なものに過ぎず、本発明、または本発明の用途および利用法を限定することは意図していない。さらに、上述の技術分野、背景技術、課題を解決するための手段、または以下の発明を実施するための最良の形態で提示された、明示または含意された理論によって拘束されることは意図していない。
【００１３】
診断インタフェースは、様々な形式でシステムデータを受け取り、それらを処理して診断エンジンへの入力として許容可能な形式にする。選択された診断エンジンに応じて許容可能な形式を生成するには、拡張処理が必要とされることもある。例えば、ある特定の診断エンジンは、傾向データを必要とするかもしれない。図１に示されるように、モデルベース診断インタフェース１１２は、診断エンジン１２２を使用したシステム診断用に使用される任意のシステムデータ１０６のソースとともに使用され得る。システムデータ１０６は、テレメトリ、試験データ、試験点データ、入力、中間結果、および出力を含むが、これらに限定されない、システムからのデータである。システムデータ１０６は、１つまたは複数のシステム命名規則を有し、データ識別子、属性識別子、およびフォーマットを含む。診断エンジン１２２は、システム１０２に関するデータを診断結果に変換する、様々なタイプのマシン実施ロジックのいずれか１つである。診断エンジン１２２は通常、テレメトリ、試験データ、および試験点データ命名規則といった様々な命名規則と互換性のない、それら独自の命名規則を有する。診断インタフェース１１２は、システムデータ１０６を受け取り、そのデータを処理して診断エンジン１２２にとって許容可能な形式にする。
【００１４】
図２は、コンポーネント関係を定義した組織を有する、関連するコンポーネントと見なすことができるシステム１０２を示す。各コンポーネントは、１つまたは複数の入力、１つまたは複数の出力、および入力を出力に変換するための１つまたは複数のメカニズムまたは機能を有する。システム１０２では、１つのコンポーネントの出力は、別のコンポーネントの入力とすることができる。コンポーネントは、様々なレベルの細目で定義され得る。例えば、姿勢制御システムは、宇宙船のコンポーネントとすることができ、リアクションホイールは、姿勢制御システムのコンポーネントとすることができ、リアクションホイール制御エレクトロニクスモジュールは、リアクションホイールのコンポーネントとすることができ、抵抗器は、制御エレクトロニクスモジュールのコンポーネントとすることができる。システム１０２は境界を有し、その境界を横切るものは、システムへの入力またはシステムの出力である。いくつかのシステム１０２はきわめて複雑であり、１次システムの問題を監視し、緩和するためだけに、他のシステムを必要とする。統合乗物健全性管理システム（ＩＶＨＭＳ）は、１次システム１０２から取得したシステムデータ１０６を使用して、より複雑な１次システムを監視することができる。ＩＶＨＭＳは、診断エンジン１２２を使用することができ、そのため、診断インタフェース１１２を必要とする。
【００１５】
診断インタフェース１１２は、モデルベース診断インタフェース１１２とすることができる。診断インタフェース１１２がモデル命名規則１０７を使用してシステムデータ１０６にアクセスできる場合、診断インタフェース１１２はモデルベースと呼ばれる。モデルベース診断インタフェース１１２を作成するため、モデル命名規則１０７が定義され、システムデータ１０６がモデル命名規則１０７に関連づけられる。モデル命名規則１０７は、システムの様相を表すトークンを含む。トークンは、モデリングソフトウェアによって操作され、アイコン、変数名、要素（またはコンポーネント）名、フォーマット、および関係識別子などを含むことができる。モデル命名規則１０７を作成するため、我々はシステム１０２から開始する。システム１０２は、システムデータ１０６に加えて、システム１０２のコンポーネント間の関係を記述するシステム情報１１４を有する。システム情報１１４は、例えば、ブロック図またはリレーショナルデータベースを含む様々な形式をとることができる。システム情報１１４は、例えば、システムコンポーネント階層、ネットワークトポロジ、またはデータとデータ属性の間の関係を含むことができる。システム情報１１４は、モデル開発環境を使用する操作者によって、システム１０２のモデル１０３を構築する際に、少なくとも暗黙的に使用され得る。モデル１０３は、シミュレートされた入力を使用して、実際のシステム１０２と同じまたはシミュレートされた出力を生成することができる。モデル１０３は、データ識別子、ならびにデータ属性名およびフォーマットを含むが、これらに限定されない、モデル命名規則１０７を有する。モデル命名規則１０７は、モデルを作成する操作者によって作成される。したがって、モデル命名規則１０７は、１次的には恣意的で柔軟であるが、モデル１０３が作成されるモデル開発環境の一定の制限によって拘束を受けることもある。モデル命名規則１０７は、例えば、リスト、リレーショナルデータベース、またはリレーショナルデータベース内のテーブルを含む様々な形式をとることができる。１つまたは複数のシステム命名規則とは異なり、モデル命名規則１０７は、操作者によって容易に変更され得る。
【００１６】
モデル命名規則１０７がモデル１０３の作成によって設計された後、モデル１０３には、システムデータ１０６をモデル命名規則１０７に関連づけまたはマッピングすることが残っている。マッピング機能１４０２は、システムデータ１０６をモデル命名規則１０７にマッピングする。マッピング機能を使用した結果、モデル命名規則１０７を使用することでアクセス可能なシステムデータ１０６であるマッピングされたシステムデータ１４０４ができる。モデルベース診断インタフェース１１２の利点は、実際のシステム１０２における変更案を実施前にモデル１０３内で実験できること、および診断システム１１２、１２２に対する対応する変更をモデル化し、実際のシステム１０２に対する変更と一緒に開発できることである。したがって、診断システム１１２、１２２に対する変更が、実際のシステム１０２に対する変更に遅れをとることはない。モデルベース診断インタフェース１１２は、実行可能ステートメント内で関連するモデル命名規則１０７によってシステムデータ１０６を参照することによって、マッピングされたシステムデータ１４０４を使用してシステムデータ１０６の値にアクセスすることができる。
【００１７】
上で説明されたモデルベース診断インタフェース１１２は、システムデータ１０６と診断エンジン１２２の間のインタフェースとしての独立機能を有する。モデルベース診断インタフェース１１２は、ＩＶＨＭＳプログラムなどの他のプログラムから利用可能であれば、より強力なツールとなる。診断インタフェース１１２をＩＶＨＭＳプログラムから利用可能にするため、マッピングされたシステムデータ１４０４は、ＩＶＨＭＳから利用可能な実行可能ステートメント内でＩＶＨＭＳプログラムに関連する追加情報にバインドされ得る。
【００１８】
図３に示されたバインディング手続き１５０２は、マッピングされたシステムデータ１４０４をシステム情報１１４にバインドする。バインディング機能１５０２を使用した結果、演算オブジェクトをそれから作成できる１つまたは複数のクラスができる。結果のオブジェクトは、適切なオブジェクトがそれにバインドされたシステム情報への参照によってリンクされ、または他の方法で利用される時は常に、モデル命名規則１０７を介してシステムデータ１０６への演算アクセスを可能にするデータアクセスおよび処理機能を有する。簡単な例を挙げると、ＩＶＨＭＳは、ある特定のスラスタ（ｔｈｒｕｓｔｅｒ）の健全性を監視することを試み、その結果、ＩＶＨＭＳは、その特定のスラスタに関するシステム情報１１４を含むモデルベース診断インタフェース１１２内のオブジェクトと動的にリンクする。リンクされた診断インタフェースオブジェクトは、ＴｈｒｕｓｔｅｒＯｎｅＴｅｍｐを「ＧＥＴ」（Ｃ＋＋の動詞）するためにロードされるが、ＴｈｒｕｓｔｅｒＯｎｅＴｅｍｐは、所望のスラスタの温度に関する原データを保持するテレメトリストリーム内のある特定のデータフレームのある特定の部分に収められたシステムデータ１０６の一項目に対する例示的なモデル命名規則１０７の名称である。リンクされた診断インタフェースオブジェクトは、その後さらに、原テレメトリデータ（おそらくバイナリビットストリーム）と華氏度の間の関係などのシステム情報１１４を使用して、華氏度のスラスタ温度を診断エンジン１２２が受け入れ可能なフォーマットにフォーマットし、フォーマットされたデータを診断エンジン１２２に供給することができる。
【００１９】
システム情報１１４をマッピングされたシステムデータ１４０４にバインドすることで、診断インタフェース１１２用のＩＶＨＭＳコンテキストが作成される。ＩＶＨＭＳ以外のプログラムは、コンテキストを作成するため、システム情報１１４以外の情報を使用することができることは理解されよう。システム情報１１４は、ＩＶＨＭＳのために使用する正しい情報であるに過ぎず、ＩＶＨＭＳは、システム情報１１４に基づいてシステムデータ１０６を使用することができる。マッピングされたシステムデータ１４０４をシステム情報１１４にバインドするオブジェクトは、ある特定の実施形態ではモデルベース診断インタフェース１１２とすることができる、動的リンクライブラリ（ＤＬＬ）または類似の構成を構成することができる。
【００２０】
図４は、モデルベース診断インタフェース１１２を開発するための例示的な装置１３００を示している。この装置は、プロセッサ１３０２と、プロセッサ１３０２に結合されたメモリ１３０４と、プロセッサ１３０２に結合されたデータインタフェース１３５０と、プロセッサ１３０２に結合されたユーザインタフェース１３６０とを備える。結合はバス１３７０によって達成される。メモリは、システムモデル開発環境１３２０と、前記システムモデル開発環境に結合された少なくとも１つのランタイム診断エンジン１２２とを格納するように構成される。データインタフェース１３５０は、システムデータ１０６のソースとしてのシステム１０２に結合される。モデル開発環境１３２０は、システムのモデル１０３を作成するためにユーザがユーザインタフェース１３６０を介して入力１３８０を供給できるようにする。ユーザは、モデル１０３を作成する際にシステム情報１１４およびシステムデータ属性１３０８を利用することができる。例えば、操作者は、操作者入力のためにシステム情報１１４およびシステムデータ属性１３０８を参照することができ、またはシステムモデル１０３を構築するモデル開発環境１３２０への入力としてデータファイルからデータを使用することができる。システムモデル１０３は、モデル命名規則１０７を有する。
【００２１】
システムモデル１０３が構築されると、次にモデル開発環境１３２０または別個のプログラム（図示されず）が、上でより詳細に説明されたように、システムデータ１０６をモデル命名規則１０７にマッピングする。システムデータ１０６は、マッピングの前にシステムデータ属性１３０８に関連づけられ得る。マッピングされたシステムデータは、図１４に示されるように、スキーマコンパイラ１１０４によってコンパイルされるデータスキーマ１１０２を有する。スキーマコンパイラ１１０４は、モデル開発環境１３２０の一部として組み込まれ得る。一つの代替実施形態では、スキーマコンパイラは、独立のプログラムとすることができる。スキーマコンパイラ１１０４によるスキーマ１１０２のコンパイルは、メモリ１３０４に格納された様子が示されたモデルベース診断インタフェース１１２を共同して形成できるオブジェクトを作成するためのクラスを生成する。
【００２２】
モデル開発環境１３２０と１つまたは複数の診断エンジン１２２は、クラスまたはオブジェクトに含まれる関数を生成することによって結合され得、この関数は、バインドされたシステムデータを診断エンジン１２２用の入力に変換する。モデル開発環境１３２０が診断エンジン１２２の入力要件に関する情報へのアクセスを獲得できる様々な方法が存在すること、また診断エンジン１２２をモデル開発環境１３２０に結合する際には、これらの様々な方法のすべてが企図されていることは、当業者であれば理解されよう。診断エンジンにとって必要な入力に関する情報へのアクセスが獲得され、システムデータ１０６が分かった後、バインドされたマッピングシステムデータを診断エンジン１２２用の入力に変換するための関数が生成され得る。様々な従来のコンパイルおよびリンク技法を、バインドされたマッピングシステムデータとともに関数をコンパイルするために使用することができる。オブジェクトは、ＩＶＨＭからアクセス可能なＤＬＬ内に集められ得る。複数の診断エンジンを利用するある特定の実施形態では、各オブジェクトは、どの診断エンジン１２２が選択されるかに関する情報にアクセスし、各オブジェクトは、適切な入力を選択された各診断エンジン１２２に供給するための機能を含むことができる。別の特定の実施形態では、図３に示されたバインディング手続き１５０２は、診断エンジンの選択結果にアクセスし、別個のＤＬＬまたは同等のソフトウェアライブラリが、診断インタフェース１１２を構成するＤＬＬの全体によって各診断エンジン用に生成される。
【００２３】
モデルベース診断インタフェースを含む、ＤＬＬもしくはその他のライブラリ、またはプログラム構造は、記憶または伝送媒体を含む任意の信号媒体上のプログラム製品として配布され得る。配布は、ＩＶＨＭの一部、または診断インタフェース１１２だけとすることもできる。
【００２４】
システムは、物理的構造と、情報、通信、またはデータ構造とを有する。図５は、例示的なモデルベース診断インタフェース１１２を使用するＩＶＨＭＳの情報構造１００を示している。情報構造１００は、それぞれシステム入力１０４およびシミュレートされたシステム入力１０５を有するシステム１０２、モデル１０３におけるシステムの表現、ならびにシステム出力１０６とを含む。システム入力１０４は、データ、力、環境的影響、コマンド、スイッチ状態の変更、またはシステム１０２の状態に影響を及ぼし得るその他の任意の要因とすることができる。シミュレートされたシステム入力１０５は、データファイル、関数、オブジェクト、またはシステム１０２がシステム境界で外部世界について感知するものをシミュレートするデータを含む、もしくは生成するその他のデータ構造とすることができる。システム出力１０６またはシステムデータ１０６は、少なくともテレメトリ１０８を含み、システム試験情報１１０を含むべきである。システム試験情報は、試験点情報も含むことができる。システム１０２の内部の関係についての情報を含むシステム情報１１４は、システム１０２に固有である。例えば、データ階層情報１１６、システムコンポーネント情報１１８、およびコンポーネント階層１２０などのシステム構造情報１２０が、システム情報に含まれ得る。システム出力１０６、モデル１０３命名規則１０７、およびシステム情報１１４は、（以下でさらに説明されるように）モデルベース診断インタフェース１１２を作成するために使用される。システム出力１０６は、モデルベース診断インタフェース１１２への入力である。命名規則１０７を有するモデル１０３は、以下でより詳しく見られるように、命名規則１０７をモデルベース診断インタフェース１１２に提供する。モデルベース診断インタフェース１１２の出力は、少なくとも１つの既製市販（ＣＯＴＳ）ランタイム診断エンジン１２２への入力であり、このエンジンは、診断された状態に応答するためにシステム入力１０４または１０５を変更する障害回復手続き１２４によって使用される診断出力を生成する。
【００２５】
図６は、モデルベース診断インタフェース１１２を作成するための例示的なプロセス２００のフローチャートを示している。プロセス２００は、ステップ２０２で、システムモデリング分野の当業者に知られた様々なＣＯＴＳシステムモデリング開発ツールおよび環境の１つを使用して達成される、または同様の目的に役立つ企業独自のもしくはカスタマイズされたモデリング開発ツールとすることができる、モデル開発から開始する。ステップ２０４は、新規コンポーネントをモデル化すべきかどうかを決定し、する必要がない場合、プロセス２００は、ステップ２０６で終了することができる。システムモデリング開発環境でその他の活動を行うことも可能だが、それらはここでは直接関係しないことを理解されたい。例えば、システム挙動を観測するために１組の入力１０５を用いてシステムモデル１０３を実行すること、またはモデル１０３を編集することは、ステップ２０４とステップ２０６の間で成し遂げられ得る。
【００２６】
新規コンポーネントをモデル化すべきであると、ステップ２０４が決定した場合、ステップ２０８がコンポーネントの基本モデルを提供する。コンポーネントは、モデリング開発環境で操作者によって作成されることもできるが、モデル開発環境で扱い易い形式でデータが利用可能な場合、コンピュータ生成のシステムモデルが使用されることもできる。例示的なコンポーネント５０２のブロック図と、システムモデリング環境内のそれと同等（「＝＞」で表される）の例示的なアイコン５０４との例示的な同等関係５００が、図９に例示されている。コンポーネント５０２は、入力５０６と、１つまたは複数の変換関数（ｔｒａｎｓｆｅｒ ｆｕｎｃｔｉｏｎ）５０８と、出力５１０とを含む。変換関数５０８は、入力５０６に応じて出力５１０を生成する。変換関数は、入力５０６を出力５１０に変換する、電子回路、電気機械、機械、電気、流体、もしくは類似の装置、デジタル論理、アナログ論理、またはその他の任意の装置、もしくは任意のタイプの装置の組み合わせをモデル化することができる。例示的なアイコン５０４は、コンポーネント識別子「０１ＡＳ」と、入力５０６についての情報「［Ｒ（３），Ｖ（３）］」と、変換関数についての情報「ＡＳＴＲＯ（Ｒ，Ｖ）」と、出力５１０についての情報「｛ＯＲＢＩＴ（６）｝」とを含む。例は単純であるが、入力５０６、変換関数５０８、および出力５１０は、コンピュータによって扱い易い任意の複雑さを備えることができることを理解されたい。３次元直交座標位置「Ｒ（３）」と速度「Ｖ（３）」ベクトルを古典的な軌道要素「｛ＯＲＢＩＴ（６）｝」に変換するコンポーネント「０１ＡＳ」の例は、限定を意図したものではない。コンポーネント５０２は、ステップ２０８でモデル化される任意の種類のシステムのコンポーネントとすることができる。例えば、通信ネットワーク、宇宙船、船舶、原子力発電所、電力網、またはその他のシステムのためのコンポーネントが、ステップ２０８でモデル化され得る。同様に、様々なアイコン、ならびに必要とされる入力５０６、変換関数５０８、および出力５１０の様々な識別方式が、本発明から逸脱することなく、使用され得る。（以下で説明される）他のアイコンとの関連、コンポーネント識別子、およびアイコン内の追加のテキスト形式データを伴ったアイコン５０４は、モデル命名規則によるコンポーネントの表現である。コンポーネント５０２のブロック図は、システム命名規則によるコンポーネントの表現である。コンポーネントからなるシステム１０２も同様に、システム命名規則およびモデル命名規則によって表現され得る。
【００２７】
モデル化すべきシステムの新規コンポーネント５０２がステップ２０８で作成された後、新規コンポーネント５０２は、モデル化されたシステム内の他のコンポーネントにステップ２１０で関連づけられ得る。他のコンポーネント６０２、６０４、６０６、および６０８に関連づけられた新規コンポーネント５０２が、図１０の例示的な同等関係６００に示されている。例示的なコンポーネント６０２および６０４は、コンポーネント５０２に入力５０６を供給するコンポーネントとして示されている。例示的なコンポーネント６０６および６０８は、出力５１０の消費主体として示されている。入力供給主体６０２および６０４用のアイコン６１０および６１２、ならびに出力消費主体６０６および６０８用のアイコン６１４および６１６は、アイコン５０４と同様の形式を有することができる。一般に、アイコンは、システムモデル全体にわたって、規約または規準に従って描かれる。規約によれば、コンポーネントは、適切に改められた情報がそこに表示された異なるアイコンをもつことができる異なるクラスに属することができる。２つの入力供給主体６０２および６０４、ならびに２つの出力消費主体６０６および６０８だけしか図１０には示されていないが、任意のタイプおよびアイコンデザインの任意の数の他のコンポーネントをステップ２１０で関連づけることができることを理解されたい。すべてのシステムモデリング環境がアイコンを使用するわけではないこと、システムモデルの非アイコン表現は、アイコンとは無関係なモデル命名規則を有することができることを理解されたい。
【００２８】
図１１の例示的な同等関係７００に示されるように、ステップ２１２で、テレメトリ１０８が、コンポーネント５０２に関連づけられる。テレメトリ１０８は、コンポーネント５０２の状態を指示するデータを備え、１つまたは複数の入力５０６、結果、中間結果、または変換関数５０８の内部値、および出力５１０を含むことができる。モデル１０２のテレメトリ１０８は、実際のシステム１０２からの、または実際のシステムの観測された挙動からのテレメトリ１０８を再現すべきであり、テレメトリがこれらの観測の結果を捕捉する。一つの代替実施形態では、モデル化されたテレメトリ１０８は、実際のテレメトリ１０８のサブセットとすることができる。したがって、変換関数５０８は、変換関数５０８の中間結果として、テレメトリ１０８の一部を生成することができる。アイコン７０４は、データレート情報「＠６０」およびテレメトリデータフォーマット「＝８１」を伴ったテレメトリデータ名（例えば、「Ｒ０１ＡＳＺＺ０１Ｕ１」、「Ｖ０１ＡＳＡＶＮＪＪ」など）の追加を示している。一実施形態では、テレメトリデータ名、またはその他のシステムデータ名は、コンポーネント５０２内で、データの発生点についての詳細を明らかにするため、構文解析され得る。テレメトリデータ、およびテレメトリデータに関する情報は共同で、テレメトリ命名規則を定義する。テレメトリ１０８とコンポーネント５０２との関連づけは、１度に１つのコンポーネントずつ成し遂げられ得る。一つの代替実施形態では、テレメトリ１０８のデータをコンポーネント識別子に関係づけるデータベースを、複数のコンポーネントとそれらのテレメトリ１０８の情報との間の関連、またテレメトリ属性を単一ステップで作成することができるモデル開発環境への入力とすることができる。
【００２９】
コンポーネント５０２は、図１２の例示的な同等関係８００にさらに示されるように、ステップ２１４で、それに関連づけられた試験情報１１０も有することができる。試験は、組み込み試験、境界走査試験、承認試験、集合体システム比較試験、または複雑機能試験（ｃｏｍｐｌｅｘ ｆｕｎｃｔｉｏｎ ｔｅｓｔ）などを含むことができる。試験は、試験出力１１０の形でコンポーネント５０２から応答を引き出す試験入力８０２を有することができる。試験出力１１０は、テレメトリデータ１０８とフォーマットが同様であることができ、または特定の試験用に独自に適合されたフォーマットを有することができる。試験出力データ１１０、ならびにそのフォーマットおよび関連情報は共同で、試験データ命名規則を定義する。
【００３０】
コンポーネント５０２がモデル化され（ステップ２０８）、その他のコンポーネントに関連づけられ（ステップ２１０）、テレメトリ（ステップ２１２）および試験情報（ステップ２１４）に関連づけられた後、すべてのコンポーネントがシステムモデル１０３に追加されたかどうかを、ステップ２１６が決定する。モデル化すべきコンポーネントがまだ残っていると、ステップ２１６が決定した場合、次のコンポーネントのモデル化を開始するため、ステップ２０４、さらにステップ２０８へと進む。すべてのコンポーネント、または少なくともいくつかの診断機能を可能にする希望の所定数のコンポーネントがモデル化された場合、次にステップ２１８が、ステップ２１８に示されるようにテレメトリ１０８および試験データ１１０をモデル命名規則にマッピングする機能を追加する。ステップ２１８までのステップが、システム命名規則で記述されたシステム１０２を、モデル命名規則１０７で記述されたモデル１０３に変換する。
【００３１】
ステップ２１８は、テレメトリおよび試験データをモデル命名規則１０７にマッピングする機能を追加する。この機能は、システム１０２からの各テレメトリデータ要素を、モデル１０３内の各同等要素にそれぞれ関連づける。テレメトリデータ１０８は、実際のシステム１０２では、フレーム同期信号から特定の時間だけずれたデータフレームの一部分の内容として識別され得る。テレメトリデータストリーム内でのテレメトリ項目の位置は、位置情報へのアクセスを提供するテレメトリ識別子に関連づけられ得る。例えば、一連のテレメトリデータフレームにおける第２のデータフレームの第３のサブフレームは、１秒ごとに実数データフォーマットで位置ベクトルの第１成分を含むことができ、それはモデル命名規則「コンポーネント０１ＭＴＨ（６０２）および０６ＭＴＨ（６０４）によって供給され、コンポーネント０１ＮＡＶ（６１４）および０３ＮＡＶ（６１６）を供給するアイコン０１ＡＳ内のＲ０１ＡＳＺＺ０１Ｕ１＠６０＝８１」にマッピングされ得る。モデル命名規則１０７は説明の目的で簡略形式で表されていること、またテレメトリデータ項目用のモデル命名規則ははるかに多くの情報を含むことができることを理解されたい。例えば、テレメトリ項目はさらに、テレメトリデータがそれを介してシステムの境界に流れるモデル化されたデータ通信階層全体、およびテレメトリデータ項目の生成を行うモデル化されたシステム階層全体にマッピングされ得る。ステップ２１８で追加された機能は、考察下の特定のシステムおよび最終的に希望する診断に合わせて複雑さが変化する。マッピングの結果は、定義されたデータ組織またはスキーマを有し、ライブ、シミュレート、または再生されたテレメトリストリーム内のテレメトリデータ項目を、モデル命名規則１０７で表現された対応するテレメトリ属性にそれぞれ関連づけるマッピングされたテレメトリデータ９０５として、図１３の例示的な同等図９００に示されている。
【００３２】
ステップ２２０は、図１３に示されるように、マッピングされたテレメトリデータ９０５をシステム情報９０４にバインドする手続きを追加する。データは作成時に演算オブジェクトに組み込まれる時にバインドされることを理解されたい。ダイナミックリンクライブラリ（ＤＬＬ）または同等のソフトウェアライブラリ内の演算オブジェクトは、ＩＶＨＭＳまたは類似のコンピュータプログラムの実行時にリンクされ得、その時にデータをバインドすることができる。図１４を参照すると、データバインティングの１つの手法が示されている。当技術分野で知られたその他のデータバインティング方法を使用することもできる。データをバインドするオブジェクトは、スキーマコンパイラ１１０４でデータスキーマ１１０２をコンパイルすることによって生成される派生クラス１１０６のオブジェクト１１０８である。データスキーマ１１０２は、マッピングされたテレメトリデータ９０７、システム情報１１４、および１つもしくは複数のＣＯＴＳまたは内部開発された診断エンジン１２２の入力要件１１１２に基づいて、作成され得る。例えば、ＩＶＨＭソフトウェアプログラム１１１０は、１つまたは複数のＣＯＴＳ診断エンジン１２２への入力９０７を生成するために、システム情報１１４にマッピングされたテレメトリストリームおよび／または試験データストリームにアクセスするためのオブジェクト１１０８とリンクすることができる。データスキーマ１１０２は、システム情報１１４に基づいて組織され、マッピングされたテレメトリデータ９０７およびその属性に基づいて定義またはフォーマットされ得る。例えば、データスキーマ１１０２は、各データ要素がバインドされたシステムコンポーネントによって組織され、テレメトリ識別子およびフォーマットによって定義され得る。ＩＶＨＭ１１１０とリンクされたオブジェクト１１０８は、モデル命名規則１０７を使用して実行時にテレメトリデータ１１１４を「ＧＥＴ」（Ｃ＋＋の動詞として）し、そのデータをそれらのオブジェクト１１０８内の関数によって処理し、システム情報にバインドされたデータをＣＯＴＳ診断エンジン１２２に提供する。
【００３３】
モデルベース診断インタフェース１１２の構築はステップ２２２で終了する。モデルベース診断インタフェースの試験を行うのが望ましく、ステップ２２４で行われる。モデルベース診断インタフェースの例示的な実施形態の利点は、ＩＶＨＭがオブジェクト１１０８とコンパイルされた後は、データソースはＩＶＨＭとは無関係になることである。データソースは、ライブテレメトリ、シミュレートされたテレメトリ、もしくは再生されたテレメトリ、または同様の多様性をもつ試験データとすることができる。したがって、ＩＶＨＭは、構築され（ステップ２２２）、システムモデル１０３を使用してシミュレーションによる試験を受け（ステップ２２４）、その後、ステップ２２６でリアルタイム診断を実行するために、実際のシステム１０２に組み込まれ、または他の方法で結合され得る。
【００３４】
図５を再び参照すると、ＣＯＴＳ診断エンジン１２２の出力は、システム１０２内の障害回復手続き１２４を実行可能なコンピュータプログラムから応答を引き出すことができる。そのような手続きは、例えば、システム１０２またはモデル１０３内のクロスストラッピングスイッチ（ｃｒｏｓｓ−ｓｔｒａｐｐｉｎｇ ｓｗｉｔｃｈ）の状態を変更することができる。したがって、モデルベース診断インタフェース１１２は、システム１０２の物理的および論理的状態を含むことができるシステム１０２の状態を変更することができる。障害回復手続き１２４の出力も、試験および検証のために、シミュレートされたモデル入力１０５に入力され得る。
【００３５】
図７は、バインディング手続き３０８、３１０、３１２、および３１４の代替ソースを示す、診断インタフェース１２２を作成するための方法の例示的な実施形態３００を示している。例示的な実施形態３００の利点は、マッピングされたテレメトリがバインドされるオブジェクトを作成するために、よく知られたＭａｔｈｅｍａｔｉｃａ、Ｃ＋＋（３０８）、およびＭＡＴＬＡＢなどのオブジェクトをサポートする様々なＣＯＴＳコンピュータプログラムが使用できることである。これは手続きライブラリの作成を可能にし、それによってモデルベース診断インタフェース１１２を作成するコストを引き下げる。生成されるオブジェクトは、マッピングされたデータ９０５の特定のスキーマ、システム情報１１４、および診断エンジン１２２Ｂ〜１１２Ｎの必要に適合された関数を含む。試験データ１１０のほか、ライブテレメトリ３２０、保存されたテレメトリ３２２、またはシミュレートされたテレメトリ（図示されず）を含む入力データ１０６は、ステップ９０２でシステム命名規則１０７にマッピングされる。一つの代替実施形態では、特定の診断エンジン１２２Ａが、バインディングを必要としないこともあるが、マッピングされたテレメトリデータ９０５だけで動作することができる。例えば、オブジェクトベースではないレガシ診断エンジン１２２Ａは、マッピングされたテレメトリデータ９０５を直接供給され得る。バインドされたデータ９０７を使用する診断エンジン１２２Ｂ〜１２２Ｎの場合、バインディング用の手続きが手続きライブラリから選択され、データがステップ９０４でシステム情報にバインドされる。典型的なバインディング手続きは、属性を有するマッピングされたデータをＣＯＴＳ診断エンジン１２２Ｂ〜１２２Ｎによって受け取り可能な形式に変換するオブジェクトを作成するためのクラスを生成する。関数は、数学関数、テキスト関数、論理関数、またはそれらの複合型とすることができる。
【００３６】
図８は、診断エンジン４２０、４２２、４２４、４２６の選択をより詳しく示した、モデルベース診断インタフェース１１２を使用して診断結果４３０を取得する方法の例示的な実施形態４００を示している。例示的な実施形態のこの態様では、モデルベース診断インタフェース１１２が作成される前に、ステップ４０２で、１つまたは複数の診断エンジン４２０、４２２、４２４、４２６が、診断エンジン１２２の集まりから選択される。診断エンジンは入力要件によって変化するので、ステップ４０２で選択された診断エンジンに必要とされるテレメトリだけに限定されたテレメトリが、ステップ４０４で選択され得る。テレメトリ１０８は、ステップ４０６で、テレメトリ属性４０８に関連づけられ得る。例えば、各テレメトリデータ要素は、ユニット、タイプ、起源、パス、待ち時間、および類似の属性に関連づけられ得る。テレメトリ１０８は、次にステップ４１０で、上で説明されたモデル命名規則４１２にマッピングされる。次にマッピングされたテレメトリは、診断エンジン１２２の集まりからステップ４０２で選択された１つまたは複数の診断エンジン４２０、４２２、４２４、および４２６に入力を提供するＩＶＨＭＳにリンク可能なオブジェクトにバインドされる。ステップ４１６は、選択された診断エンジン４２０、４２２、４２４、および／または４２６と、マッピングされたテレメトリデータを属性にバインドするオブジェクトとを含むＩＶＨＭＳを実行する。選択された診断エンジン４２０、４２２、４２４、および／または４２６は、ＩＶＨＭＳによって様々な目的で使用され得る診断結果４３０を生成する。例えば、診断結果４３０は、障害回復手続き１２４への入力として、予知診断アプリケーション用に、診断用に直接、または同様の目的のために使用され得る。
【００３７】
図１５は、簡単な例示的なＩＶＨＭＳ１２００と、診断インタフェース１１２を作成する例示的な方法を示すフローチャートとの複合ブロック図である。作成の例示的なステップは、モデル化２０８と、マッピング９０２と、バインディング９０４とを含む。例示的なＩＶＨＭＳは、システム１０２と、診断インタフェース１１２と、ＣＯＴＳ診断エンジン１２２と、障害回復手続き１２４とを含む。例示的なＩＶＨＭＳでは、モデルベース診断インタフェース１１２は、システム１０２からシステムデータ１０６を受け取って、診断エンジン１２２に診断入力を送り、診断エンジンは、ＣＯＴＳ診断エンジン１２２を使用して、障害回復手続き１２４への入力として診断出力を生成し、障害回復手続きは、システム１０２に障害回復入力を供給する。システム１０２は、モデル１０３を構築する際に利用され得、その少なくとも一部がマッピングされたシステムデータにステップ９０４でバインドされるシステム情報１１４を生成する。システム１０２は、モデル１０３を構築する際にパターンとして利用され、モデル命名規則にステップ９０２でマッピングされる、モデルベース診断インタフェース１１２への入力とすることができるデータ１０６も生成する。システムデータ１０８、１１０のスキーマは、マッピングされたシステムデータをシステム情報１１４にバインドするクラスを生成するために使用される。
【００３８】
少なくとも１つの例示的な実施形態が上述の詳細な説明で提示されたが、数多くの変形が存在することを理解されたい。診断インタフェース１１２に関して提示されたすべては、同様に予知診断インタフェースにも適切に適用されることを理解されたい。さらに、本発明の方法および装置の利点は、固定された所定のデータ命名規則を、柔軟な中間のモデル命名規則１０７を介して、異なる固定された所定の診断インタフェース１１２のデータ命名規則に適合させることができ、それによってシステム１０２への変更と一緒に容易に診断も変更する柔軟性を操作者に与えることであることを理解されたい。１つまたは複数の例示的な実施形態は例であるにすぎず、本発明の範囲、適用性、または構成をいかなる方法によっても限定する意図はないことも理解されたい。むしろ、上述の詳細な説明は、１つまたは複数の例示的な実施形態を実施するための便利なロードマップを当業者に提供するであろう。添付の特許請求の範囲で説明される本発明およびそれらの法的な均等物の範囲から逸脱することなく、様々な変更が要素の機能および構成に施され得ることを理解されたい。
【図面の簡単な説明】
【００３９】
【図１】例示的なモデルベース診断インタフェースのブロック図である。
【図２】追加の細部が示された図１の例示的なモデルベース診断インタフェースのブロック図である。
【図３】より多くの細部が示された図１の例示的なモデルベース診断インタフェースのブロック図である。
【図４】ＩＶＨＭシステムと関連する例示的なモデルベース診断インタフェースのブロック図である。
【図５】ランタイムモデルベース診断インタフェースを作成するための例示的な方法のフローチャートである。
【図６】例示的な診断インタフェースの一態様のブロック図である。
【図７】モデルベース診断インタフェースを作成するための例示的な装置のブロック図である。
【図８】ランタイムモデルベース診断インタフェースを作成するための例示的な方法の別の態様のフローチャートである。
【図９】例示的なモデルベース診断インタフェースを作成する第１のステップにおける、例示的なモデル化されたコンポーネントおよびその同等の例示的なモデル化アイコンのブロック図である。
【図１０】例示的なデータ入力およびデータ出力、ならびにそれらのための同等の例示的なモデル化アイコンを有する、図９の例示的なモデル化されたコンポーネントのブロック図である。
【図１１】例示的なテレメトリ出力、およびそのための同等の例示的なモデル化アイコンを有する、図１０の例示的なモデル化されたコンポーネントのブロック図である。
【図１２】例示的な試験入力および試験出力、ならびにそれらのための同等の例示的なモデル化アイコンを有する、図１１の例示的なモデル化されたコンポーネントのブロック図である。
【図１３】システム診断プロセスへの例示的な入力として提示された、図１２の例示的なモデル化されたコンポーネント、およびそのための同等の例示的なモデル化アイコンのブロック図である。
【図１４】マッピングされたデータをシステム情報にバインドする図１３からの例示的なプロセスステップのフローチャートである。
【図１５】例示的なモデルベース診断インタフェースを作成するステップと使用するステップとの間の関係をシステムからのデータと一緒に示すフローチャートである。
【技術分野】
【０００１】
本発明は一般に、遠隔計測されるシステム（ｔｅｌｅｍｅｔｅｒｅｄ ｓｙｓｔｅｍ）用の診断システムに関する。本発明はより詳細には、既製市販（ＣＯＴＳ：ｃｏｍｍｅｒｃｉａｌ−ｏｆｆ−ｔｈｅ−ｓｈｅｌｆ）診断エンジンを使用する診断システムに関する。本発明はさらにより詳細には、遠隔計測されるシステムとＣＯＴＳ診断エンジンとの間のモデルベース診断インタフェースに関する。
【背景技術】
【０００２】
統合乗物健全性管理システム（ＩＶＨＭＳ：Ｉｎｔｅｇｒａｔｅｄ Ｖｅｈｉｃｌｅ Ｈｅａｌｔｈ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）は、複雑な工学システム内のそのシステム用に設計されたコンポーネントおよびサブシステムの異常に対して、準リアルタイムの修正応答を提供することを意図している。修正応答は、準リアルタイムの修正応答をサポートするために好ましくはリアルタイムに実行される、診断および予知診断に依存している。宇宙船、航空機、および船舶など、複雑な工学システムのリアルタイム自動診断が、漠然とした目標（ｅｌｕｓｉｖｅ ｇｏａｌ）となっている。
【０００３】
ＩＶＨＭＳの１つの要素は、診断エンジンとも呼ばれる診断ロジックであることができる。様々なタイプの診断エンジンが、当技術分野で知られている。例えば、合格／不合格基準を使用する診断エンジン、状態機械診断エンジン、ニューラルネット診断エンジン、およびデータマイニング診断エンジンが、ＣＯＴＳ製品として入手可能である。いくつかのタイプは、複数の発売元から入手可能であるが、その各々は、わずかに異なる入力データ用インタフェースを有している。様々なＣＯＴＳ診断エンジンは各々、独自の入力要件を有することができる。
【０００４】
診断エンジンは通常、非リアルタイムの後処理アプリケーションで使用される。診断エンジンは、その特定の診断エンジン用に特別にフォーマットされた入力を処理する。例えば、ある診断エンジンは、合格／不合格表示のみを受け入れ、別の診断エンジンは、一定の形式の状態変数を必要とし、さらに別の診断エンジンは、入力としてリレーショナルデータベースを利用することができる。ＣＯＴＳ診断エンジンの製造業者は通常、ＣＯＴＳ診断エンジン自体の最大性能を引き出す入力フォーマットを指定する。エンジンは、ＣＯＴＳ診断エンジンの製造業者がよく知らない多種多様なアプリケーションでも使用できるように設計されるので、特定の１組の利用可能なデータ用にＣＯＴＳ診断エンジンを調整することは、そのＣＯＴＳ診断エンジンのエンドユーザに任されている。受け入れ可能な入力形式でデータを提供することの代償は、ＣＯＴＳ診断エンジン間の切り替えに対してコスト上の障壁が築かれることであり、エンドユーザは不便でも特定の発売元に依存することになる。
【０００５】
ＩＶＨＭＳを使用するシステムを含む実際のシステムは、様々なシステム要素状態に関するデータを提供するために遠隔計測され得る。テレメトリ（ｔｅｌｅｍｅｔｒｙ）は、個々のデータフォーマット、データソース、および類似のデータ属性に関連づけられた、しばしば簡略記号または短縮形式をとるデータ名を含むテレメトリ命名規則（ｔｅｌｅｍｅｔｒｙ ｎｏｍｅｎｃｌａｔｕｒｅ）を有する。テレメトリ命名規則は通常、ＣＯＴＳ診断エンジンの入力要件と互換性がない。
【０００６】
実際のシステムはさらに、試験点でデータを提供することができ、組み込み試験またはその他の試験時に生成された試験データを提供することができる。試験点データは、テレメトリと類似することができるが、定期的に生成されない。試験データは通常、ＣＯＴＳ診断エンジンの入力データ要件と互換性がない試験データ命名規則（ｔｅｓｔ ｄａｔａ ｎｏｍｅｎｃｌａｔｕｒｅ）を有する。
【０００７】
テレメトリ命名規則、システムモデル命名規則、試験命名規則、試験点データ命名規則、およびＣＯＴＳ診断エンジン用の入力データ要件は、互いに相関性がなく、そのため、ＣＯＴＳ診断エンジン用の入力データを獲得するのに大きな労力が必要とされる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
したがって、大きな労力を必要としない方法でＣＯＴＳ診断エンジンに入力を提供するように、テレメトリ命名規則、システムモデル命名規則、試験命名規則、試験点命名規則を互いに相関させることが望ましい。また、互いに相関させた命名規則データと１つまたは複数のＣＯＴＳ診断エンジンの間にインタフェースを提供することが望ましい。
【課題を解決するための手段】
【０００９】
システムの状態を表すシステムデータと、前記システム内の関係に関するシステム情報とを有し、またモデル命名規則（ｍｏｄｅｌ ｎｏｍｅｎｃｌａｔｕｒｅ）をもつシステムモデルを有するシステム用の診断インタフェースのための装置が提供され、診断インタフェースは、前記システムデータに応答する出力を生成する少なくとも１つの演算オブジェクトを備え、前記少なくとも１つのオブジェクトは、前記システムデータの前記システム情報へのバインディングを含み、前記システムデータは、バインドされる前に前記モデル命名規則にマッピングされる。
【００１０】
システム情報と、前記システムの状態を表すシステムデータとを有するシステム用のモデルベース診断インタフェースを作成するための方法が提供され、この方法は、前記システムをモデル化して、システムモデル命名規則を有するシステムモデルを生成するステップと、前記システムデータを前記システムモデル命名規則にマッピングするステップとを備える。
【００１１】
これ以降、本発明が添付の図面と関連させて説明されるが、図面中では同じ番号は同じ要素を表す。
【発明を実施するための最良の形態】
【００１２】
以下の詳細な説明は、本質的に例示的なものに過ぎず、本発明、または本発明の用途および利用法を限定することは意図していない。さらに、上述の技術分野、背景技術、課題を解決するための手段、または以下の発明を実施するための最良の形態で提示された、明示または含意された理論によって拘束されることは意図していない。
【００１３】
診断インタフェースは、様々な形式でシステムデータを受け取り、それらを処理して診断エンジンへの入力として許容可能な形式にする。選択された診断エンジンに応じて許容可能な形式を生成するには、拡張処理が必要とされることもある。例えば、ある特定の診断エンジンは、傾向データを必要とするかもしれない。図１に示されるように、モデルベース診断インタフェース１１２は、診断エンジン１２２を使用したシステム診断用に使用される任意のシステムデータ１０６のソースとともに使用され得る。システムデータ１０６は、テレメトリ、試験データ、試験点データ、入力、中間結果、および出力を含むが、これらに限定されない、システムからのデータである。システムデータ１０６は、１つまたは複数のシステム命名規則を有し、データ識別子、属性識別子、およびフォーマットを含む。診断エンジン１２２は、システム１０２に関するデータを診断結果に変換する、様々なタイプのマシン実施ロジックのいずれか１つである。診断エンジン１２２は通常、テレメトリ、試験データ、および試験点データ命名規則といった様々な命名規則と互換性のない、それら独自の命名規則を有する。診断インタフェース１１２は、システムデータ１０６を受け取り、そのデータを処理して診断エンジン１２２にとって許容可能な形式にする。
【００１４】
図２は、コンポーネント関係を定義した組織を有する、関連するコンポーネントと見なすことができるシステム１０２を示す。各コンポーネントは、１つまたは複数の入力、１つまたは複数の出力、および入力を出力に変換するための１つまたは複数のメカニズムまたは機能を有する。システム１０２では、１つのコンポーネントの出力は、別のコンポーネントの入力とすることができる。コンポーネントは、様々なレベルの細目で定義され得る。例えば、姿勢制御システムは、宇宙船のコンポーネントとすることができ、リアクションホイールは、姿勢制御システムのコンポーネントとすることができ、リアクションホイール制御エレクトロニクスモジュールは、リアクションホイールのコンポーネントとすることができ、抵抗器は、制御エレクトロニクスモジュールのコンポーネントとすることができる。システム１０２は境界を有し、その境界を横切るものは、システムへの入力またはシステムの出力である。いくつかのシステム１０２はきわめて複雑であり、１次システムの問題を監視し、緩和するためだけに、他のシステムを必要とする。統合乗物健全性管理システム（ＩＶＨＭＳ）は、１次システム１０２から取得したシステムデータ１０６を使用して、より複雑な１次システムを監視することができる。ＩＶＨＭＳは、診断エンジン１２２を使用することができ、そのため、診断インタフェース１１２を必要とする。
【００１５】
診断インタフェース１１２は、モデルベース診断インタフェース１１２とすることができる。診断インタフェース１１２がモデル命名規則１０７を使用してシステムデータ１０６にアクセスできる場合、診断インタフェース１１２はモデルベースと呼ばれる。モデルベース診断インタフェース１１２を作成するため、モデル命名規則１０７が定義され、システムデータ１０６がモデル命名規則１０７に関連づけられる。モデル命名規則１０７は、システムの様相を表すトークンを含む。トークンは、モデリングソフトウェアによって操作され、アイコン、変数名、要素（またはコンポーネント）名、フォーマット、および関係識別子などを含むことができる。モデル命名規則１０７を作成するため、我々はシステム１０２から開始する。システム１０２は、システムデータ１０６に加えて、システム１０２のコンポーネント間の関係を記述するシステム情報１１４を有する。システム情報１１４は、例えば、ブロック図またはリレーショナルデータベースを含む様々な形式をとることができる。システム情報１１４は、例えば、システムコンポーネント階層、ネットワークトポロジ、またはデータとデータ属性の間の関係を含むことができる。システム情報１１４は、モデル開発環境を使用する操作者によって、システム１０２のモデル１０３を構築する際に、少なくとも暗黙的に使用され得る。モデル１０３は、シミュレートされた入力を使用して、実際のシステム１０２と同じまたはシミュレートされた出力を生成することができる。モデル１０３は、データ識別子、ならびにデータ属性名およびフォーマットを含むが、これらに限定されない、モデル命名規則１０７を有する。モデル命名規則１０７は、モデルを作成する操作者によって作成される。したがって、モデル命名規則１０７は、１次的には恣意的で柔軟であるが、モデル１０３が作成されるモデル開発環境の一定の制限によって拘束を受けることもある。モデル命名規則１０７は、例えば、リスト、リレーショナルデータベース、またはリレーショナルデータベース内のテーブルを含む様々な形式をとることができる。１つまたは複数のシステム命名規則とは異なり、モデル命名規則１０７は、操作者によって容易に変更され得る。
【００１６】
モデル命名規則１０７がモデル１０３の作成によって設計された後、モデル１０３には、システムデータ１０６をモデル命名規則１０７に関連づけまたはマッピングすることが残っている。マッピング機能１４０２は、システムデータ１０６をモデル命名規則１０７にマッピングする。マッピング機能を使用した結果、モデル命名規則１０７を使用することでアクセス可能なシステムデータ１０６であるマッピングされたシステムデータ１４０４ができる。モデルベース診断インタフェース１１２の利点は、実際のシステム１０２における変更案を実施前にモデル１０３内で実験できること、および診断システム１１２、１２２に対する対応する変更をモデル化し、実際のシステム１０２に対する変更と一緒に開発できることである。したがって、診断システム１１２、１２２に対する変更が、実際のシステム１０２に対する変更に遅れをとることはない。モデルベース診断インタフェース１１２は、実行可能ステートメント内で関連するモデル命名規則１０７によってシステムデータ１０６を参照することによって、マッピングされたシステムデータ１４０４を使用してシステムデータ１０６の値にアクセスすることができる。
【００１７】
上で説明されたモデルベース診断インタフェース１１２は、システムデータ１０６と診断エンジン１２２の間のインタフェースとしての独立機能を有する。モデルベース診断インタフェース１１２は、ＩＶＨＭＳプログラムなどの他のプログラムから利用可能であれば、より強力なツールとなる。診断インタフェース１１２をＩＶＨＭＳプログラムから利用可能にするため、マッピングされたシステムデータ１４０４は、ＩＶＨＭＳから利用可能な実行可能ステートメント内でＩＶＨＭＳプログラムに関連する追加情報にバインドされ得る。
【００１８】
図３に示されたバインディング手続き１５０２は、マッピングされたシステムデータ１４０４をシステム情報１１４にバインドする。バインディング機能１５０２を使用した結果、演算オブジェクトをそれから作成できる１つまたは複数のクラスができる。結果のオブジェクトは、適切なオブジェクトがそれにバインドされたシステム情報への参照によってリンクされ、または他の方法で利用される時は常に、モデル命名規則１０７を介してシステムデータ１０６への演算アクセスを可能にするデータアクセスおよび処理機能を有する。簡単な例を挙げると、ＩＶＨＭＳは、ある特定のスラスタ（ｔｈｒｕｓｔｅｒ）の健全性を監視することを試み、その結果、ＩＶＨＭＳは、その特定のスラスタに関するシステム情報１１４を含むモデルベース診断インタフェース１１２内のオブジェクトと動的にリンクする。リンクされた診断インタフェースオブジェクトは、ＴｈｒｕｓｔｅｒＯｎｅＴｅｍｐを「ＧＥＴ」（Ｃ＋＋の動詞）するためにロードされるが、ＴｈｒｕｓｔｅｒＯｎｅＴｅｍｐは、所望のスラスタの温度に関する原データを保持するテレメトリストリーム内のある特定のデータフレームのある特定の部分に収められたシステムデータ１０６の一項目に対する例示的なモデル命名規則１０７の名称である。リンクされた診断インタフェースオブジェクトは、その後さらに、原テレメトリデータ（おそらくバイナリビットストリーム）と華氏度の間の関係などのシステム情報１１４を使用して、華氏度のスラスタ温度を診断エンジン１２２が受け入れ可能なフォーマットにフォーマットし、フォーマットされたデータを診断エンジン１２２に供給することができる。
【００１９】
システム情報１１４をマッピングされたシステムデータ１４０４にバインドすることで、診断インタフェース１１２用のＩＶＨＭＳコンテキストが作成される。ＩＶＨＭＳ以外のプログラムは、コンテキストを作成するため、システム情報１１４以外の情報を使用することができることは理解されよう。システム情報１１４は、ＩＶＨＭＳのために使用する正しい情報であるに過ぎず、ＩＶＨＭＳは、システム情報１１４に基づいてシステムデータ１０６を使用することができる。マッピングされたシステムデータ１４０４をシステム情報１１４にバインドするオブジェクトは、ある特定の実施形態ではモデルベース診断インタフェース１１２とすることができる、動的リンクライブラリ（ＤＬＬ）または類似の構成を構成することができる。
【００２０】
図４は、モデルベース診断インタフェース１１２を開発するための例示的な装置１３００を示している。この装置は、プロセッサ１３０２と、プロセッサ１３０２に結合されたメモリ１３０４と、プロセッサ１３０２に結合されたデータインタフェース１３５０と、プロセッサ１３０２に結合されたユーザインタフェース１３６０とを備える。結合はバス１３７０によって達成される。メモリは、システムモデル開発環境１３２０と、前記システムモデル開発環境に結合された少なくとも１つのランタイム診断エンジン１２２とを格納するように構成される。データインタフェース１３５０は、システムデータ１０６のソースとしてのシステム１０２に結合される。モデル開発環境１３２０は、システムのモデル１０３を作成するためにユーザがユーザインタフェース１３６０を介して入力１３８０を供給できるようにする。ユーザは、モデル１０３を作成する際にシステム情報１１４およびシステムデータ属性１３０８を利用することができる。例えば、操作者は、操作者入力のためにシステム情報１１４およびシステムデータ属性１３０８を参照することができ、またはシステムモデル１０３を構築するモデル開発環境１３２０への入力としてデータファイルからデータを使用することができる。システムモデル１０３は、モデル命名規則１０７を有する。
【００２１】
システムモデル１０３が構築されると、次にモデル開発環境１３２０または別個のプログラム（図示されず）が、上でより詳細に説明されたように、システムデータ１０６をモデル命名規則１０７にマッピングする。システムデータ１０６は、マッピングの前にシステムデータ属性１３０８に関連づけられ得る。マッピングされたシステムデータは、図１４に示されるように、スキーマコンパイラ１１０４によってコンパイルされるデータスキーマ１１０２を有する。スキーマコンパイラ１１０４は、モデル開発環境１３２０の一部として組み込まれ得る。一つの代替実施形態では、スキーマコンパイラは、独立のプログラムとすることができる。スキーマコンパイラ１１０４によるスキーマ１１０２のコンパイルは、メモリ１３０４に格納された様子が示されたモデルベース診断インタフェース１１２を共同して形成できるオブジェクトを作成するためのクラスを生成する。
【００２２】
モデル開発環境１３２０と１つまたは複数の診断エンジン１２２は、クラスまたはオブジェクトに含まれる関数を生成することによって結合され得、この関数は、バインドされたシステムデータを診断エンジン１２２用の入力に変換する。モデル開発環境１３２０が診断エンジン１２２の入力要件に関する情報へのアクセスを獲得できる様々な方法が存在すること、また診断エンジン１２２をモデル開発環境１３２０に結合する際には、これらの様々な方法のすべてが企図されていることは、当業者であれば理解されよう。診断エンジンにとって必要な入力に関する情報へのアクセスが獲得され、システムデータ１０６が分かった後、バインドされたマッピングシステムデータを診断エンジン１２２用の入力に変換するための関数が生成され得る。様々な従来のコンパイルおよびリンク技法を、バインドされたマッピングシステムデータとともに関数をコンパイルするために使用することができる。オブジェクトは、ＩＶＨＭからアクセス可能なＤＬＬ内に集められ得る。複数の診断エンジンを利用するある特定の実施形態では、各オブジェクトは、どの診断エンジン１２２が選択されるかに関する情報にアクセスし、各オブジェクトは、適切な入力を選択された各診断エンジン１２２に供給するための機能を含むことができる。別の特定の実施形態では、図３に示されたバインディング手続き１５０２は、診断エンジンの選択結果にアクセスし、別個のＤＬＬまたは同等のソフトウェアライブラリが、診断インタフェース１１２を構成するＤＬＬの全体によって各診断エンジン用に生成される。
【００２３】
モデルベース診断インタフェースを含む、ＤＬＬもしくはその他のライブラリ、またはプログラム構造は、記憶または伝送媒体を含む任意の信号媒体上のプログラム製品として配布され得る。配布は、ＩＶＨＭの一部、または診断インタフェース１１２だけとすることもできる。
【００２４】
システムは、物理的構造と、情報、通信、またはデータ構造とを有する。図５は、例示的なモデルベース診断インタフェース１１２を使用するＩＶＨＭＳの情報構造１００を示している。情報構造１００は、それぞれシステム入力１０４およびシミュレートされたシステム入力１０５を有するシステム１０２、モデル１０３におけるシステムの表現、ならびにシステム出力１０６とを含む。システム入力１０４は、データ、力、環境的影響、コマンド、スイッチ状態の変更、またはシステム１０２の状態に影響を及ぼし得るその他の任意の要因とすることができる。シミュレートされたシステム入力１０５は、データファイル、関数、オブジェクト、またはシステム１０２がシステム境界で外部世界について感知するものをシミュレートするデータを含む、もしくは生成するその他のデータ構造とすることができる。システム出力１０６またはシステムデータ１０６は、少なくともテレメトリ１０８を含み、システム試験情報１１０を含むべきである。システム試験情報は、試験点情報も含むことができる。システム１０２の内部の関係についての情報を含むシステム情報１１４は、システム１０２に固有である。例えば、データ階層情報１１６、システムコンポーネント情報１１８、およびコンポーネント階層１２０などのシステム構造情報１２０が、システム情報に含まれ得る。システム出力１０６、モデル１０３命名規則１０７、およびシステム情報１１４は、（以下でさらに説明されるように）モデルベース診断インタフェース１１２を作成するために使用される。システム出力１０６は、モデルベース診断インタフェース１１２への入力である。命名規則１０７を有するモデル１０３は、以下でより詳しく見られるように、命名規則１０７をモデルベース診断インタフェース１１２に提供する。モデルベース診断インタフェース１１２の出力は、少なくとも１つの既製市販（ＣＯＴＳ）ランタイム診断エンジン１２２への入力であり、このエンジンは、診断された状態に応答するためにシステム入力１０４または１０５を変更する障害回復手続き１２４によって使用される診断出力を生成する。
【００２５】
図６は、モデルベース診断インタフェース１１２を作成するための例示的なプロセス２００のフローチャートを示している。プロセス２００は、ステップ２０２で、システムモデリング分野の当業者に知られた様々なＣＯＴＳシステムモデリング開発ツールおよび環境の１つを使用して達成される、または同様の目的に役立つ企業独自のもしくはカスタマイズされたモデリング開発ツールとすることができる、モデル開発から開始する。ステップ２０４は、新規コンポーネントをモデル化すべきかどうかを決定し、する必要がない場合、プロセス２００は、ステップ２０６で終了することができる。システムモデリング開発環境でその他の活動を行うことも可能だが、それらはここでは直接関係しないことを理解されたい。例えば、システム挙動を観測するために１組の入力１０５を用いてシステムモデル１０３を実行すること、またはモデル１０３を編集することは、ステップ２０４とステップ２０６の間で成し遂げられ得る。
【００２６】
新規コンポーネントをモデル化すべきであると、ステップ２０４が決定した場合、ステップ２０８がコンポーネントの基本モデルを提供する。コンポーネントは、モデリング開発環境で操作者によって作成されることもできるが、モデル開発環境で扱い易い形式でデータが利用可能な場合、コンピュータ生成のシステムモデルが使用されることもできる。例示的なコンポーネント５０２のブロック図と、システムモデリング環境内のそれと同等（「＝＞」で表される）の例示的なアイコン５０４との例示的な同等関係５００が、図９に例示されている。コンポーネント５０２は、入力５０６と、１つまたは複数の変換関数（ｔｒａｎｓｆｅｒ ｆｕｎｃｔｉｏｎ）５０８と、出力５１０とを含む。変換関数５０８は、入力５０６に応じて出力５１０を生成する。変換関数は、入力５０６を出力５１０に変換する、電子回路、電気機械、機械、電気、流体、もしくは類似の装置、デジタル論理、アナログ論理、またはその他の任意の装置、もしくは任意のタイプの装置の組み合わせをモデル化することができる。例示的なアイコン５０４は、コンポーネント識別子「０１ＡＳ」と、入力５０６についての情報「［Ｒ（３），Ｖ（３）］」と、変換関数についての情報「ＡＳＴＲＯ（Ｒ，Ｖ）」と、出力５１０についての情報「｛ＯＲＢＩＴ（６）｝」とを含む。例は単純であるが、入力５０６、変換関数５０８、および出力５１０は、コンピュータによって扱い易い任意の複雑さを備えることができることを理解されたい。３次元直交座標位置「Ｒ（３）」と速度「Ｖ（３）」ベクトルを古典的な軌道要素「｛ＯＲＢＩＴ（６）｝」に変換するコンポーネント「０１ＡＳ」の例は、限定を意図したものではない。コンポーネント５０２は、ステップ２０８でモデル化される任意の種類のシステムのコンポーネントとすることができる。例えば、通信ネットワーク、宇宙船、船舶、原子力発電所、電力網、またはその他のシステムのためのコンポーネントが、ステップ２０８でモデル化され得る。同様に、様々なアイコン、ならびに必要とされる入力５０６、変換関数５０８、および出力５１０の様々な識別方式が、本発明から逸脱することなく、使用され得る。（以下で説明される）他のアイコンとの関連、コンポーネント識別子、およびアイコン内の追加のテキスト形式データを伴ったアイコン５０４は、モデル命名規則によるコンポーネントの表現である。コンポーネント５０２のブロック図は、システム命名規則によるコンポーネントの表現である。コンポーネントからなるシステム１０２も同様に、システム命名規則およびモデル命名規則によって表現され得る。
【００２７】
モデル化すべきシステムの新規コンポーネント５０２がステップ２０８で作成された後、新規コンポーネント５０２は、モデル化されたシステム内の他のコンポーネントにステップ２１０で関連づけられ得る。他のコンポーネント６０２、６０４、６０６、および６０８に関連づけられた新規コンポーネント５０２が、図１０の例示的な同等関係６００に示されている。例示的なコンポーネント６０２および６０４は、コンポーネント５０２に入力５０６を供給するコンポーネントとして示されている。例示的なコンポーネント６０６および６０８は、出力５１０の消費主体として示されている。入力供給主体６０２および６０４用のアイコン６１０および６１２、ならびに出力消費主体６０６および６０８用のアイコン６１４および６１６は、アイコン５０４と同様の形式を有することができる。一般に、アイコンは、システムモデル全体にわたって、規約または規準に従って描かれる。規約によれば、コンポーネントは、適切に改められた情報がそこに表示された異なるアイコンをもつことができる異なるクラスに属することができる。２つの入力供給主体６０２および６０４、ならびに２つの出力消費主体６０６および６０８だけしか図１０には示されていないが、任意のタイプおよびアイコンデザインの任意の数の他のコンポーネントをステップ２１０で関連づけることができることを理解されたい。すべてのシステムモデリング環境がアイコンを使用するわけではないこと、システムモデルの非アイコン表現は、アイコンとは無関係なモデル命名規則を有することができることを理解されたい。
【００２８】
図１１の例示的な同等関係７００に示されるように、ステップ２１２で、テレメトリ１０８が、コンポーネント５０２に関連づけられる。テレメトリ１０８は、コンポーネント５０２の状態を指示するデータを備え、１つまたは複数の入力５０６、結果、中間結果、または変換関数５０８の内部値、および出力５１０を含むことができる。モデル１０２のテレメトリ１０８は、実際のシステム１０２からの、または実際のシステムの観測された挙動からのテレメトリ１０８を再現すべきであり、テレメトリがこれらの観測の結果を捕捉する。一つの代替実施形態では、モデル化されたテレメトリ１０８は、実際のテレメトリ１０８のサブセットとすることができる。したがって、変換関数５０８は、変換関数５０８の中間結果として、テレメトリ１０８の一部を生成することができる。アイコン７０４は、データレート情報「＠６０」およびテレメトリデータフォーマット「＝８１」を伴ったテレメトリデータ名（例えば、「Ｒ０１ＡＳＺＺ０１Ｕ１」、「Ｖ０１ＡＳＡＶＮＪＪ」など）の追加を示している。一実施形態では、テレメトリデータ名、またはその他のシステムデータ名は、コンポーネント５０２内で、データの発生点についての詳細を明らかにするため、構文解析され得る。テレメトリデータ、およびテレメトリデータに関する情報は共同で、テレメトリ命名規則を定義する。テレメトリ１０８とコンポーネント５０２との関連づけは、１度に１つのコンポーネントずつ成し遂げられ得る。一つの代替実施形態では、テレメトリ１０８のデータをコンポーネント識別子に関係づけるデータベースを、複数のコンポーネントとそれらのテレメトリ１０８の情報との間の関連、またテレメトリ属性を単一ステップで作成することができるモデル開発環境への入力とすることができる。
【００２９】
コンポーネント５０２は、図１２の例示的な同等関係８００にさらに示されるように、ステップ２１４で、それに関連づけられた試験情報１１０も有することができる。試験は、組み込み試験、境界走査試験、承認試験、集合体システム比較試験、または複雑機能試験（ｃｏｍｐｌｅｘ ｆｕｎｃｔｉｏｎ ｔｅｓｔ）などを含むことができる。試験は、試験出力１１０の形でコンポーネント５０２から応答を引き出す試験入力８０２を有することができる。試験出力１１０は、テレメトリデータ１０８とフォーマットが同様であることができ、または特定の試験用に独自に適合されたフォーマットを有することができる。試験出力データ１１０、ならびにそのフォーマットおよび関連情報は共同で、試験データ命名規則を定義する。
【００３０】
コンポーネント５０２がモデル化され（ステップ２０８）、その他のコンポーネントに関連づけられ（ステップ２１０）、テレメトリ（ステップ２１２）および試験情報（ステップ２１４）に関連づけられた後、すべてのコンポーネントがシステムモデル１０３に追加されたかどうかを、ステップ２１６が決定する。モデル化すべきコンポーネントがまだ残っていると、ステップ２１６が決定した場合、次のコンポーネントのモデル化を開始するため、ステップ２０４、さらにステップ２０８へと進む。すべてのコンポーネント、または少なくともいくつかの診断機能を可能にする希望の所定数のコンポーネントがモデル化された場合、次にステップ２１８が、ステップ２１８に示されるようにテレメトリ１０８および試験データ１１０をモデル命名規則にマッピングする機能を追加する。ステップ２１８までのステップが、システム命名規則で記述されたシステム１０２を、モデル命名規則１０７で記述されたモデル１０３に変換する。
【００３１】
ステップ２１８は、テレメトリおよび試験データをモデル命名規則１０７にマッピングする機能を追加する。この機能は、システム１０２からの各テレメトリデータ要素を、モデル１０３内の各同等要素にそれぞれ関連づける。テレメトリデータ１０８は、実際のシステム１０２では、フレーム同期信号から特定の時間だけずれたデータフレームの一部分の内容として識別され得る。テレメトリデータストリーム内でのテレメトリ項目の位置は、位置情報へのアクセスを提供するテレメトリ識別子に関連づけられ得る。例えば、一連のテレメトリデータフレームにおける第２のデータフレームの第３のサブフレームは、１秒ごとに実数データフォーマットで位置ベクトルの第１成分を含むことができ、それはモデル命名規則「コンポーネント０１ＭＴＨ（６０２）および０６ＭＴＨ（６０４）によって供給され、コンポーネント０１ＮＡＶ（６１４）および０３ＮＡＶ（６１６）を供給するアイコン０１ＡＳ内のＲ０１ＡＳＺＺ０１Ｕ１＠６０＝８１」にマッピングされ得る。モデル命名規則１０７は説明の目的で簡略形式で表されていること、またテレメトリデータ項目用のモデル命名規則ははるかに多くの情報を含むことができることを理解されたい。例えば、テレメトリ項目はさらに、テレメトリデータがそれを介してシステムの境界に流れるモデル化されたデータ通信階層全体、およびテレメトリデータ項目の生成を行うモデル化されたシステム階層全体にマッピングされ得る。ステップ２１８で追加された機能は、考察下の特定のシステムおよび最終的に希望する診断に合わせて複雑さが変化する。マッピングの結果は、定義されたデータ組織またはスキーマを有し、ライブ、シミュレート、または再生されたテレメトリストリーム内のテレメトリデータ項目を、モデル命名規則１０７で表現された対応するテレメトリ属性にそれぞれ関連づけるマッピングされたテレメトリデータ９０５として、図１３の例示的な同等図９００に示されている。
【００３２】
ステップ２２０は、図１３に示されるように、マッピングされたテレメトリデータ９０５をシステム情報９０４にバインドする手続きを追加する。データは作成時に演算オブジェクトに組み込まれる時にバインドされることを理解されたい。ダイナミックリンクライブラリ（ＤＬＬ）または同等のソフトウェアライブラリ内の演算オブジェクトは、ＩＶＨＭＳまたは類似のコンピュータプログラムの実行時にリンクされ得、その時にデータをバインドすることができる。図１４を参照すると、データバインティングの１つの手法が示されている。当技術分野で知られたその他のデータバインティング方法を使用することもできる。データをバインドするオブジェクトは、スキーマコンパイラ１１０４でデータスキーマ１１０２をコンパイルすることによって生成される派生クラス１１０６のオブジェクト１１０８である。データスキーマ１１０２は、マッピングされたテレメトリデータ９０７、システム情報１１４、および１つもしくは複数のＣＯＴＳまたは内部開発された診断エンジン１２２の入力要件１１１２に基づいて、作成され得る。例えば、ＩＶＨＭソフトウェアプログラム１１１０は、１つまたは複数のＣＯＴＳ診断エンジン１２２への入力９０７を生成するために、システム情報１１４にマッピングされたテレメトリストリームおよび／または試験データストリームにアクセスするためのオブジェクト１１０８とリンクすることができる。データスキーマ１１０２は、システム情報１１４に基づいて組織され、マッピングされたテレメトリデータ９０７およびその属性に基づいて定義またはフォーマットされ得る。例えば、データスキーマ１１０２は、各データ要素がバインドされたシステムコンポーネントによって組織され、テレメトリ識別子およびフォーマットによって定義され得る。ＩＶＨＭ１１１０とリンクされたオブジェクト１１０８は、モデル命名規則１０７を使用して実行時にテレメトリデータ１１１４を「ＧＥＴ」（Ｃ＋＋の動詞として）し、そのデータをそれらのオブジェクト１１０８内の関数によって処理し、システム情報にバインドされたデータをＣＯＴＳ診断エンジン１２２に提供する。
【００３３】
モデルベース診断インタフェース１１２の構築はステップ２２２で終了する。モデルベース診断インタフェースの試験を行うのが望ましく、ステップ２２４で行われる。モデルベース診断インタフェースの例示的な実施形態の利点は、ＩＶＨＭがオブジェクト１１０８とコンパイルされた後は、データソースはＩＶＨＭとは無関係になることである。データソースは、ライブテレメトリ、シミュレートされたテレメトリ、もしくは再生されたテレメトリ、または同様の多様性をもつ試験データとすることができる。したがって、ＩＶＨＭは、構築され（ステップ２２２）、システムモデル１０３を使用してシミュレーションによる試験を受け（ステップ２２４）、その後、ステップ２２６でリアルタイム診断を実行するために、実際のシステム１０２に組み込まれ、または他の方法で結合され得る。
【００３４】
図５を再び参照すると、ＣＯＴＳ診断エンジン１２２の出力は、システム１０２内の障害回復手続き１２４を実行可能なコンピュータプログラムから応答を引き出すことができる。そのような手続きは、例えば、システム１０２またはモデル１０３内のクロスストラッピングスイッチ（ｃｒｏｓｓ−ｓｔｒａｐｐｉｎｇ ｓｗｉｔｃｈ）の状態を変更することができる。したがって、モデルベース診断インタフェース１１２は、システム１０２の物理的および論理的状態を含むことができるシステム１０２の状態を変更することができる。障害回復手続き１２４の出力も、試験および検証のために、シミュレートされたモデル入力１０５に入力され得る。
【００３５】
図７は、バインディング手続き３０８、３１０、３１２、および３１４の代替ソースを示す、診断インタフェース１２２を作成するための方法の例示的な実施形態３００を示している。例示的な実施形態３００の利点は、マッピングされたテレメトリがバインドされるオブジェクトを作成するために、よく知られたＭａｔｈｅｍａｔｉｃａ、Ｃ＋＋（３０８）、およびＭＡＴＬＡＢなどのオブジェクトをサポートする様々なＣＯＴＳコンピュータプログラムが使用できることである。これは手続きライブラリの作成を可能にし、それによってモデルベース診断インタフェース１１２を作成するコストを引き下げる。生成されるオブジェクトは、マッピングされたデータ９０５の特定のスキーマ、システム情報１１４、および診断エンジン１２２Ｂ〜１１２Ｎの必要に適合された関数を含む。試験データ１１０のほか、ライブテレメトリ３２０、保存されたテレメトリ３２２、またはシミュレートされたテレメトリ（図示されず）を含む入力データ１０６は、ステップ９０２でシステム命名規則１０７にマッピングされる。一つの代替実施形態では、特定の診断エンジン１２２Ａが、バインディングを必要としないこともあるが、マッピングされたテレメトリデータ９０５だけで動作することができる。例えば、オブジェクトベースではないレガシ診断エンジン１２２Ａは、マッピングされたテレメトリデータ９０５を直接供給され得る。バインドされたデータ９０７を使用する診断エンジン１２２Ｂ〜１２２Ｎの場合、バインディング用の手続きが手続きライブラリから選択され、データがステップ９０４でシステム情報にバインドされる。典型的なバインディング手続きは、属性を有するマッピングされたデータをＣＯＴＳ診断エンジン１２２Ｂ〜１２２Ｎによって受け取り可能な形式に変換するオブジェクトを作成するためのクラスを生成する。関数は、数学関数、テキスト関数、論理関数、またはそれらの複合型とすることができる。
【００３６】
図８は、診断エンジン４２０、４２２、４２４、４２６の選択をより詳しく示した、モデルベース診断インタフェース１１２を使用して診断結果４３０を取得する方法の例示的な実施形態４００を示している。例示的な実施形態のこの態様では、モデルベース診断インタフェース１１２が作成される前に、ステップ４０２で、１つまたは複数の診断エンジン４２０、４２２、４２４、４２６が、診断エンジン１２２の集まりから選択される。診断エンジンは入力要件によって変化するので、ステップ４０２で選択された診断エンジンに必要とされるテレメトリだけに限定されたテレメトリが、ステップ４０４で選択され得る。テレメトリ１０８は、ステップ４０６で、テレメトリ属性４０８に関連づけられ得る。例えば、各テレメトリデータ要素は、ユニット、タイプ、起源、パス、待ち時間、および類似の属性に関連づけられ得る。テレメトリ１０８は、次にステップ４１０で、上で説明されたモデル命名規則４１２にマッピングされる。次にマッピングされたテレメトリは、診断エンジン１２２の集まりからステップ４０２で選択された１つまたは複数の診断エンジン４２０、４２２、４２４、および４２６に入力を提供するＩＶＨＭＳにリンク可能なオブジェクトにバインドされる。ステップ４１６は、選択された診断エンジン４２０、４２２、４２４、および／または４２６と、マッピングされたテレメトリデータを属性にバインドするオブジェクトとを含むＩＶＨＭＳを実行する。選択された診断エンジン４２０、４２２、４２４、および／または４２６は、ＩＶＨＭＳによって様々な目的で使用され得る診断結果４３０を生成する。例えば、診断結果４３０は、障害回復手続き１２４への入力として、予知診断アプリケーション用に、診断用に直接、または同様の目的のために使用され得る。
【００３７】
図１５は、簡単な例示的なＩＶＨＭＳ１２００と、診断インタフェース１１２を作成する例示的な方法を示すフローチャートとの複合ブロック図である。作成の例示的なステップは、モデル化２０８と、マッピング９０２と、バインディング９０４とを含む。例示的なＩＶＨＭＳは、システム１０２と、診断インタフェース１１２と、ＣＯＴＳ診断エンジン１２２と、障害回復手続き１２４とを含む。例示的なＩＶＨＭＳでは、モデルベース診断インタフェース１１２は、システム１０２からシステムデータ１０６を受け取って、診断エンジン１２２に診断入力を送り、診断エンジンは、ＣＯＴＳ診断エンジン１２２を使用して、障害回復手続き１２４への入力として診断出力を生成し、障害回復手続きは、システム１０２に障害回復入力を供給する。システム１０２は、モデル１０３を構築する際に利用され得、その少なくとも一部がマッピングされたシステムデータにステップ９０４でバインドされるシステム情報１１４を生成する。システム１０２は、モデル１０３を構築する際にパターンとして利用され、モデル命名規則にステップ９０２でマッピングされる、モデルベース診断インタフェース１１２への入力とすることができるデータ１０６も生成する。システムデータ１０８、１１０のスキーマは、マッピングされたシステムデータをシステム情報１１４にバインドするクラスを生成するために使用される。
【００３８】
少なくとも１つの例示的な実施形態が上述の詳細な説明で提示されたが、数多くの変形が存在することを理解されたい。診断インタフェース１１２に関して提示されたすべては、同様に予知診断インタフェースにも適切に適用されることを理解されたい。さらに、本発明の方法および装置の利点は、固定された所定のデータ命名規則を、柔軟な中間のモデル命名規則１０７を介して、異なる固定された所定の診断インタフェース１１２のデータ命名規則に適合させることができ、それによってシステム１０２への変更と一緒に容易に診断も変更する柔軟性を操作者に与えることであることを理解されたい。１つまたは複数の例示的な実施形態は例であるにすぎず、本発明の範囲、適用性、または構成をいかなる方法によっても限定する意図はないことも理解されたい。むしろ、上述の詳細な説明は、１つまたは複数の例示的な実施形態を実施するための便利なロードマップを当業者に提供するであろう。添付の特許請求の範囲で説明される本発明およびそれらの法的な均等物の範囲から逸脱することなく、様々な変更が要素の機能および構成に施され得ることを理解されたい。
【図面の簡単な説明】
【００３９】
【図１】例示的なモデルベース診断インタフェースのブロック図である。
【図２】追加の細部が示された図１の例示的なモデルベース診断インタフェースのブロック図である。
【図３】より多くの細部が示された図１の例示的なモデルベース診断インタフェースのブロック図である。
【図４】ＩＶＨＭシステムと関連する例示的なモデルベース診断インタフェースのブロック図である。
【図５】ランタイムモデルベース診断インタフェースを作成するための例示的な方法のフローチャートである。
【図６】例示的な診断インタフェースの一態様のブロック図である。
【図７】モデルベース診断インタフェースを作成するための例示的な装置のブロック図である。
【図８】ランタイムモデルベース診断インタフェースを作成するための例示的な方法の別の態様のフローチャートである。
【図９】例示的なモデルベース診断インタフェースを作成する第１のステップにおける、例示的なモデル化されたコンポーネントおよびその同等の例示的なモデル化アイコンのブロック図である。
【図１０】例示的なデータ入力およびデータ出力、ならびにそれらのための同等の例示的なモデル化アイコンを有する、図９の例示的なモデル化されたコンポーネントのブロック図である。
【図１１】例示的なテレメトリ出力、およびそのための同等の例示的なモデル化アイコンを有する、図１０の例示的なモデル化されたコンポーネントのブロック図である。
【図１２】例示的な試験入力および試験出力、ならびにそれらのための同等の例示的なモデル化アイコンを有する、図１１の例示的なモデル化されたコンポーネントのブロック図である。
【図１３】システム診断プロセスへの例示的な入力として提示された、図１２の例示的なモデル化されたコンポーネント、およびそのための同等の例示的なモデル化アイコンのブロック図である。
【図１４】マッピングされたデータをシステム情報にバインドする図１３からの例示的なプロセスステップのフローチャートである。
【図１５】例示的なモデルベース診断インタフェースを作成するステップと使用するステップとの間の関係をシステムからのデータと一緒に示すフローチャートである。
【特許請求の範囲】
【請求項１】
（ａ） プロセッサと、
（ｂ） 前記プロセッサに結合されたメモリと、
（ｃ） 前記メモリ内に記憶され、前記プロセッサによって実行可能なプログラムであって、システムの状態を表すシステムデータを有するシステム用診断インターフェースと、前記システム内の関係に関するシステム情報を含み、
前記システム情報のモデル命名規則表現と、モデル情報及び命名規則と、システム故障モード情報及び命名規則と、テレメトリ情報及び命名規則とを含む階層的システムモデルを有し、
前記システム情報、前記モデル情報及び命名規則、前記システム故障モード情報及び命名規則、及び前記テレメトリ情報及び命名規則を、前記モデル命名規則表現を用いて、バインド機能にマッピングし、
前記システム情報、前記モデル情報及び命名規則、前記システム故障モード情報及び命名規則、及び前記テレメトリ情報及び命名規則を、前記バインド機能を用いてバインドして、バインドされたシステムを生成し、
前記バインドされたシステムを用いて、ランタイム実行用の最適化されたモデルベース診断インターフェースを生成し、
前記バインドされたシステム及び前記最適化されたモデルベース診断インターフェースを用いて、１つ以上のシステム故障を決定し、
前記バインドされたシステム及び前記最適化されたモデルベース診断インターフェースを用いて、前記１つ以上のシステム故障の根本原因を決定する、
ように構成される前記プログラムと、
を含む装置。
【請求項２】
請求項１に記載の装置であって、前記モデル命名規則がシステムをモデル化する環境においてシステムを記述する言語からなり、当該言語がモデリングソフトウエアによって取り扱い可能なトークンからなり、当該トークンが少なくとも１つのアイコン、変数名、要素名、コンポーネント名、フォーマット、及び関係識別子を含む事を特徴とする装置。
【請求項３】
請求項１に記載の装置であって、前記プログラムが更に、
前記バインドされたシステム及び前記モデルベース診断インターフェースを用いて、将来の結果と、当該将来の結果の影響の程度を予測するように構成されている事を特徴とする装置。
【請求項４】
請求項１に記載の装置であって、前記モデル情報が、システム要素階層情報と、システム構造階層情報と、データスキーマ情報とから成ることを特徴とする装置。
【請求項５】
請求項１に記載の装置であって、前記プログラムが更に、
１つ以上のあり得る故障モードの、１つ以上の初期的原因を決定し、
前記１つ以上の初期的原因を１つ以上のあり得る原因と比較し、
前記１つ以上の初期的原因と１つ以上のあり得る原因との比較に基づいて、１つ以上の根本原因を決定するように構成されている事を特徴とする装置。
【請求項１】
（ａ） プロセッサと、
（ｂ） 前記プロセッサに結合されたメモリと、
（ｃ） 前記メモリ内に記憶され、前記プロセッサによって実行可能なプログラムであって、システムの状態を表すシステムデータを有するシステム用診断インターフェースと、前記システム内の関係に関するシステム情報を含み、
前記システム情報のモデル命名規則表現と、モデル情報及び命名規則と、システム故障モード情報及び命名規則と、テレメトリ情報及び命名規則とを含む階層的システムモデルを有し、
前記システム情報、前記モデル情報及び命名規則、前記システム故障モード情報及び命名規則、及び前記テレメトリ情報及び命名規則を、前記モデル命名規則表現を用いて、バインド機能にマッピングし、
前記システム情報、前記モデル情報及び命名規則、前記システム故障モード情報及び命名規則、及び前記テレメトリ情報及び命名規則を、前記バインド機能を用いてバインドして、バインドされたシステムを生成し、
前記バインドされたシステムを用いて、ランタイム実行用の最適化されたモデルベース診断インターフェースを生成し、
前記バインドされたシステム及び前記最適化されたモデルベース診断インターフェースを用いて、１つ以上のシステム故障を決定し、
前記バインドされたシステム及び前記最適化されたモデルベース診断インターフェースを用いて、前記１つ以上のシステム故障の根本原因を決定する、
ように構成される前記プログラムと、
を含む装置。
【請求項２】
請求項１に記載の装置であって、前記モデル命名規則がシステムをモデル化する環境においてシステムを記述する言語からなり、当該言語がモデリングソフトウエアによって取り扱い可能なトークンからなり、当該トークンが少なくとも１つのアイコン、変数名、要素名、コンポーネント名、フォーマット、及び関係識別子を含む事を特徴とする装置。
【請求項３】
請求項１に記載の装置であって、前記プログラムが更に、
前記バインドされたシステム及び前記モデルベース診断インターフェースを用いて、将来の結果と、当該将来の結果の影響の程度を予測するように構成されている事を特徴とする装置。
【請求項４】
請求項１に記載の装置であって、前記モデル情報が、システム要素階層情報と、システム構造階層情報と、データスキーマ情報とから成ることを特徴とする装置。
【請求項５】
請求項１に記載の装置であって、前記プログラムが更に、
１つ以上のあり得る故障モードの、１つ以上の初期的原因を決定し、
前記１つ以上の初期的原因を１つ以上のあり得る原因と比較し、
前記１つ以上の初期的原因と１つ以上のあり得る原因との比較に基づいて、１つ以上の根本原因を決定するように構成されている事を特徴とする装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２００９−２８３００４（Ｐ２００９−２８３００４Ａ）
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【出願番号】特願２００９−１７６５９３（Ｐ２００９−１７６５９３）
【出願日】平成２１年７月２９日（２００９．７．２９）
【分割の表示】特願２００６−５３４３２１（Ｐ２００６−５３４３２１）の分割
【原出願日】平成１６年１０月５日（２００４．１０．５）
【出願人】（５００５７５８２４）ハネウェル・インターナショナル・インコーポレーテッド (1,504)
【Ｆターム（参考）】
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【出願日】平成２１年７月２９日（２００９．７．２９）
【分割の表示】特願２００６−５３４３２１（Ｐ２００６−５３４３２１）の分割
【原出願日】平成１６年１０月５日（２００４．１０．５）
【出願人】（５００５７５８２４）ハネウェル・インターナショナル・インコーポレーテッド (1,504)
【Ｆターム（参考）】
[ Back to top ]