▶ ノースロップ グラマン システムズ コーポレイションの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-02-15
(45)【発行日】2024-02-26
(54)【発明の名称】モデルベース推論器のためのパラメトリックデータモデリング
(51)【国際特許分類】
G05B 23/02 20060101AFI20240216BHJP
B64D 45/00 20060101ALI20240216BHJP
G06F 11/22 20060101ALI20240216BHJP
G06N 5/04 20230101ALI20240216BHJP
G06Q 10/20 20230101ALI20240216BHJP
【ＦＩ】
G05B23/02 302Y
B64D45/00 Z
G06F11/22 675E
G06N5/04
G06Q10/20
【請求項の数】
20
(21)【出願番号】P 2021519624
(86)(22)【出願日】2019-07-25
(65)【公表番号】
(43)【公表日】2022-01-13
(86)【国際出願番号】 US2019043362
(87)【国際公開番号】W WO2020081138
(87)【国際公開日】2020-04-23
【審査請求日】2022-07-04
(31)【優先権主張番号】16/163,726
(32)【優先日】2018-10-18
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520128820
【氏名又は名称】ノースロップ グラマン システムズ コーポレーション
(74)【代理人】
【識別番号】110001519
【氏名又は名称】弁理士法人太陽国際特許事務所
(72)【発明者】
【氏名】ディクシット、スニール
(72)【発明者】
【氏名】ラムロス、リチャード、アール．
(72)【発明者】
【氏名】グッド、ネイサン、アール．
【審査官】松本 泰典
(56)【参考文献】
【文献】米国特許出願公開第２００８／０３１２７８３（ＵＳ，Ａ１）
【文献】米国特許出願公開第２００６／００６４２９１（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０５Ｂ ２３／０２
Ｇ０６Ｆ １１／２２
Ｂ６４Ｄ ４５／００
Ｇ０６Ｎ ５／０４
Ｇ０６Ｑ １０／２０
(57)【特許請求の範囲】
【請求項1】
コンピュータプロセッサと不揮発性記憶装置とを備える複合システムのためのオンボード診断システムであって、前記複合システム内の複数のソースから、前記複合システムの動作中に伝送されるセンサデータを含むデータを読み取るためのインターフェースと、
前記複合システムを構成する複数のサブシステムの動作を各々表す複数のモデルであって、前記複数のモデルの各々が複数のノードを含み、前記ノードは、前記複合システムの各サブシステムの機能、構成要素、およびセンサを表し、前記ノードの少なくともいくつかは、パラメータ化されたデータ、直接アナログセンサデータ、および前記複数のサブシステムが生成したＢＩＴ（組み込み試験）データを表し、前記複数のモデルの各々は、前記不揮発性記憶装置に格納される、ＸＭＬモデル構成ファイルからなる、前記複数のモデルと、
前記コンピュータプロセッサによって実行されるＭＢＲ（モデルベース推論）エンジンであって、前記ＭＢＲエンジンは、前記インターフェースで読み取られたデータを受信し、前記ＸＭＬモデル構成ファイルから前記複数のサブシステムの前記複数のモデルを実装して、一つのサブシステムのモデルに含まれる複数のノードが表すデータに基づいて前記一つのサブシステムの診断分析を生成し、ＢＩＴデータを表すノードからのデータと、少なくとも一つの他のノードからのデータと、に基づいて前記一つのサブシステムに異常があるか否かを判定し、前記少なくとも一つの他のノードからのデータが、前記一つのサブシステムに異常があるか否かの補強証拠を提供する、ＭＢＲエンジンと、
前記診断分析およびデータを受信し、実行可能な保守タスクおよびレポートを提供する保守ビューアと、
を備える、システム。
【請求項2】
前記ＭＢＲエンジンは、前記一つのサブシステムの異常を示す前記ＢＩＴデータを表すノードからのデータと、前記一つのサブシステムの異常について補強証拠を提供しない、前記少なくとも一つの他のノードからのデータと、に基づいて、前記一つのサブシステムの異常が誤検出であり誤りであることを判定する、請求項１に記載のシステム。
【請求項3】
前記ＭＢＲエンジンは、一つのサブシステムの異常を示す前記ＢＩＴデータを表すノードからのデータと、前記一つのサブシステムの異常について補強証拠を提供する、前記少なくとも一つの他のノードからのデータと、に基づいて、前記一つのサブシステムの異常判定が妥当であることを判定する、請求項１に記載のシステム。
【請求項4】
前記ＭＢＲエンジンによる誤判定であるとの判定が、前記複合システムのリアルタイム動作中に行われる、請求項１に記載のシステム。
【請求項5】
前記ＭＢＲエンジンによる異常判定が妥当であるとの判定が、前記複合システムのリアルタイム動作中に行われる、請求項１に記載のシステム。
【請求項6】
前記ＸＭＬモデル構成ファイルの各々は、関連するセンサ及び論理的機能を含む、対応するサブシステムの表現である、請求項１に記載のシステム。
【請求項7】
前記パラメータ化されたデータは、較正値をさらに含む、請求項１に記載のシステム。
【請求項8】
少なくとも１つのノードが、ＢＩＴデータを前記モデルに提供するための物理的センサノードをさらに含む、請求項１に記載のシステム。
【請求項9】
少なくとも１つのノードが、前記モデルに直接物理的センサ定量データを提供するための物理的センサノードをさらに備える、請求項１に記載のシステム。
【請求項10】
前記複合システムを表す前記モデルを作成し、試験するためのグラフィカルユーザインターフェースをさらに備える、請求項１に記載のシステム。
【請求項11】
複合システムのための統合輸送手段健全性管理（ＩＶＨＭ）の方法であって、前記複合システムの複数のサブシステムの動作を各々表す複数のモデルを生成し、前記複数のモデルの各々は、前記複数のモデルの各々が複数のノードを含み、前記ノードは、前記複合システムの前記複数のサブシステムの各々の機能、構成要素、およびセンサを表し、前記ノードのうちの少なくともいくつかは、パラメータ化されたデータ、直接アナログセンサデータ、および前記複数のサブシステムが生成したＢＩＴ（組み込み試験）データを表し、
前記複数のサブシステムの前記複数のモデルをそれぞれＸＭＬモデル構成ファイルへエクスポートし、
前記モデルと前記複合システムの複数のソースからのセンサデータとを用いてＭＢＲ（モデルベース推論）エンジンを実行して、一つのサブシステムのモデルに含まれる複数のノードが表すデータに基づいて前記一つのサブシステムの診断分析を生成し、
前記ＭＢＲエンジンにより、ＢＩＴデータを表すノードからのデータと、少なくとも一つの他のノードからのデータとに基づいて、前記一つのサブシステムに異常があるか否かを判定し、前記少なくとも一つの他のノードからのデータが、前記一つのサブシステムに異常があるか否かの補強証拠を提供し、
前記診断分析に基づいて前記複合システムにおいて行われるべき保守を示すレポートを生成すること、
を含む、方法。
【請求項12】
前記ＭＢＲエンジンは、前記一つのサブシステムの異常を示す前記ＢＩＴデータを表すノードからのデータと、前記一つのサブシステムの異常について補強証拠を提供しない、前記少なくとも一つの他のノードからのデータと、に基づいて、前記一つのサブシステムの異常が誤検出であり誤りであることを判定することをさらに含む、請求項１１に記載の方法。
【請求項13】
前記ＭＢＲエンジンは、前記一つのサブシステムの異常を示す前記ＢＩＴデータを表すノードからのデータと、前記一つのサブシステムの異常について補強証拠を提供する、前記少なくとも一つの他のノードからのデータと、に基づいて、前記一つのサブシステムの異常判定が妥当であることを判定することをさらに含む、請求項１１に記載の方法。
【請求項14】
前記ＭＢＲエンジンによる誤判定であるとの判定が、前記複合システムのリアルタイム動作中に行われる、請求項１１に記載の方法。
【請求項15】
前記ＭＢＲエンジンによる異常判定が妥当であるとの判定が、前記複合システムのリアルタイム動作中に行われる、請求項１１に記載の方法。
【請求項16】
前記ＸＭＬモデル構成ファイルは、各々が関連するセンサ及び論理的機能を含む、対応するサブシステムの表現である、請求項１５に記載の方法。
【請求項17】
前記パラメータ化されたデータは、較正値をさらに含む、請求項１１に記載の方法。
【請求項18】
少なくとも１つのノードが、ＢＩＴデータをモデルに提供するための物理的センサノードをさらに含む、請求項１１に記載の方法。
【請求項19】
少なくとも１つのノードが、モデルに直接物理的センサ定量データを提供するための物理的センサノードをさらに含む、請求項１１に記載の方法。
【請求項20】
前記複合システムを表す前記モデルを作成し、試験するためのグラフィカルユーザインターフェースをさらに備える、請求項１１に記載の方法。【発明の詳細な説明】
【技術分野】
【0001】
種々の実施例は、全体として、モデルベース診断システムに関し、より詳細には、統合輸送手段健全性管理（Integrated Vehicle Health Management：ＩＶＨＭ）システムにおけるモデルベース推論（Model Based Reasoner：ＭＢＲ）エンジンへのパラメータ化入力および機器故障の診断に関する。
【背景技術】
【0002】
輸送手段、航空機、宇宙船および他のシステムのような複雑なシステムは、通常、輸送手段（vehicle）を制御および管理するための多くのサブシステムを含む。本明細書全体を通して、輸送手段（vehicle）への言及は、様々な複雑なシステム（複合システム）を包含することを理解されたい。これらのサブシステムのうちの１つ以上において、特に輸送手段のリアルタイム動作中に発生し得る有害事象または故障を識別することが望ましい。統合輸送手段健全性管理システムを使用して、輸送手段の様々な特性（故障モード）を監視および診断することができる。システム挙動に関するモデル、ルール、決定、および事例を使用するモデルベースシステム（即ち、エキスパートシステム）は、輸送手段内のセンサおよび他のデータソースからの入力を受け取り、評価するシステムの機能モデルを作成するために開発されてきた。しかしながら、従来技術のモデルは、サブシステムレベルでのみ統合され、輸送手段全体を網羅していない。加えて、輸送手段のライフサイクルに亘ってハードウェアおよびソフトウェアのアップグレードに応じてモデルを開発および更新するために、大量の時間および資源が必要とされる。
【0003】
技術的診断ソリューションに対するルールベースのアプローチでは、組み込み試験（built-in test：ＢＩＴ）データを使用することができる。ＢＩＴエンジニアリング（ルールベースアプローチと考えられる）は、複雑なシステムに対してはあまり効果的ではなく、高い誤警報（false alarm：ＦＡ）率の主な理由となる。良好なルールを作成することに関わる工学的努力は、数十年にわたるソフトウェアおよびハードウェアのアップグレードでは非常に費用がかかり、高負担である。従って、これらのシステムを維持するコストは膨大であり、ライフサイクルコストのほぼ７２％が動作およびサポートに費やされる。加えて、機器ＢＩＴ情報は、異なるベンダによって供給され得るので、一般に、一貫した規格に従っていない。
【発明の概要】
【課題を解決するための手段】
【0004】
実施例は、輸送手段に関するリアルタイムの診断及び保守情報を生成するためにモデルベース推論器を使用する統合輸送手段健全性管理システムを包含する。一実施形態では、コンピュータプロセッサおよび不揮発性記憶装置を有する複合システム用オンボード診断システムは、複合システム内の複数のソースからセンサデータを含むデータを受信するためのインターフェースと、複合システムを表すモデルであって、図式内の複数のノードをさらに含み、前記ノードが、複合システムの機能、構成要素、センサを表し、前記ノードのうちの少なくともいくつかが、パラメータ化されたデータ、直接アナログセンサデータ、および組み込み試験（ＢＩＴ）データを表し、不揮発性記憶装置内に格納されたＸＭＬモデル構成ファイルからなる、モデルと、モデルを作成および検証するためのモデル開発および検証インターフェースと、モデルを評価するためのモデル試験マネージャと、コンピュータプロセッサによって実行されるモデルベース推論（ＭＢＲ）エンジンであって、入力インターフェースからデータを受信し、対応するＸＭＬモデル構成ファイルからモデルを実装し、複合システムの診断分析およびデータを生成する、ＭＢＲエンジンと、診断分析およびデータを受信し、実施可能な保守タスクおよびレポートを提供するための保守ビューアと、を含む。
【0005】
さらなる実施形態では、モデル試験マネージャは、シミュレートされたデータまたは複合システムから捕捉された動作データを使用してモデルを評価する。
【0006】
一実施形態では、複合システムの統合輸送手段健全性管理（ＩＶＨＭ）方法は、複合システムを表すモデルを生成し、前記モデルが図式内の複数のノードをさらに含み、前記ノードは、複合システムの機能、構成要素、およびセンサを表し、前記ノードのうちの少なくともいくつかは、パラメータ化データ、直接アナログセンサデータ、および組み込み試験（ＢＩＴ）データを表し、前記モデルを検証し、前記モデルを試験し、前記モデルをＸＭＬモデル構成ファイルにエクスポートし、前記モデル及び前記複合システム内の複数のソースからのセンサデータを使用してモデルベース推論（ＭＢＲ）エンジンを実行し、前記複合システムの診断分析およびデータを生成し、前記診断分析およびデータに基づいて前記複合システムの保守を実行することを含む。
【0007】
さらなる実施形態では、試験ステップは、シミュレートされたデータまたは複合システムから捕捉された動作データを使用してモデルを評価することをさらに含む。
【0008】
上記の実施形態のいずれかにおいて、少なくとも１つのノードは、状態およびステータスを有するシステム要素を表すための構成要素ノード、他のノードからの出力を論理的に結合するための機能ノード、又はパラメータ化されたデータをモデルに提供するための物理的センサノードをさらに含む。
【0009】
上記の実施形態のいずれにおいて、パラメータ化されたデータは、センサデータの上限値および下限値をさらに含む。
【0010】
上記の実施形態のいずれにおいて、パラメータ化されたデータは、較正値をさらに含む。
【0011】
上記実施形態のいずれかにおいて、少なくとも１つのノードは、モデルにＢＩＴデータを提供するための物理的センサノード、またはモデルに直接的物理的センサ定量データを提供するための物理的センサノードをさらに含む。
【0012】
上記の実施形態のいずれかにおいて、複合システムを表すモデルを作成し、試験するためのグラフィカルユーザインターフェースが提供され得る。
【0013】
次に、いくつかの例示的な実施形態を、添付の図面を参照して説明する。
【図面の簡単な説明】
【0014】
【図1】航空機内の機器故障の診断分析のためのオンボード動作ＩＶＨＭシステムおよびそのインターフェースのブロック図を示す。
【図2】ＩＶＨＭシステムの設計、動作、および保守プロセスおよびインターフェースのブロック図を示す。
【図3】ＩＶＨＭシステムと共に使用するサブシステムのモデルを示す。
【図7】センサノードへのデータマッピングの表示を示す。
【図8】ＩＶＨＭシステムと共に使用するモデルを試験するための機構の表示を示す。
【図9】障害解析報告の一例を示す図である。
【図10】誤警報報告の一例を示す。
【発明を実施するための形態】
【0015】
モデル駆動アーキテクチャ（Model Driven Architectures：ＭＤＡ）およびモデルベースエンジニアリング（Model Based Engineering：ＭＢＥ）を使用する統合輸送手段健全性管理（ＩＶＨＭ）は、システムが変更またはアップグレードされるたびにではなく、１回でソフトウェアおよびハードウェア要素に飛行資格を与える（flight qualified）解決方法である。これにより、システムの診断ドメイン知識を持つモデルを含むＸＭＬ形式の構成ファイルを使用することで、コストを大幅に削減できる。モデルは、正確さのために検証される必要があるが、高価で時間のかかるソフトウェア飛行資格検査（flight qualification）を必要としない。これにより、軍事作戦および支援コストが２５％～３５％節約される。
【0016】
図１は、ＭＢＲエンジン１４が航空機１２のアビオニクス（航空電子機器）室内の計算装置（図示せず）上で動作する、航空機１２上のＩＶＨＭシステム１０の機能的挙動およびインターフェースを示す。図１を参照して航空機が示され、説明されているが、実施形態はこの種の輸送手段に限定されない。観測された挙動１６は、様々な航空機アビオニクスデータバスから得られたＢＩＴ、パラメトリック、及びセンサデータを指す。予想される挙動１８は、様々なサブシステム、回線交換可能ユニット（line replaceable units：ＬＲＵ）、およびシステム全体の構成要素のモデル化されたドメイン知識２０から予想されるものを指す（このモデルはＸＭＬフォーマットで表される）。構成要素は、サブシステム、ＬＲＵ、およびその他の構成要素を指す。観測された挙動１６が予想される挙動１８と異なる場合、異常挙動（不一致／残差）が登録され、ＭＢＲエンジン１４は診断モード（原因分析）に入る。ＢＩＴ、パラメトリック、およびセンサデータの様々な推論アルゴリズムおよび分析により、ＭＢＲエンジン１４は、故障した構成要素の検出、単一の故障した構成要素または類似の構成要素の曖昧性群（ambiguity group）の分離、誤警報識別、故障した構成要素の機能的評価（すなわち、ポンプ内の漏れ、パイプ内の漏れ、空気流の閉塞、軸受損傷、および構成要素の物理性に依存する他の評価）、および未知の異常を含む、結果２２を生成する。未知の異常の場合、モデル２０は、構成要素に関する追加情報と、その構成要素の故障モードに関連する他の構成要素との相互作用と、を用いて改善される。この情報は、これらの構成要素の製造業者から得られ、追加の故障モードが既存のモデルに追加される。チェーン（直列または並列）における類似の要素の曖昧性群を低減するために、典型的には、曖昧性群内の特定の構成要素を分離するために追加のセンサが必要とされる。サイズ、重量、および電力の制限により追加のセンサを適用できない場合、保守者は局所曖昧性群内でオフボード診断分析を実行しなければならない。
【0017】
図２は、ＩＶＨＭシステム１００のブロック図を示す。図２の様々な構成要素は、モデル化されたシステムにおいて、それらの相互接続された機能、故障モード、故障確率、および機能評価を論理的に結合させるために共にリンクされ、設計ソース（１１４、１１６、１１８、１２０）、パイロットのディスプレイに配信される（運航飛行プログラム１０２から得られる）リアルタイムまたは後処理された入力データ、地上システム（ＯＦＰ１０２から得られる）、および保守者の地上保守アクション１２２のためのディスク（１２６）上の記憶装置にもリンクされる。議論の目的上、ＩＶＨＭシステム１００はブロック図として表現されるが、記述された機能および方法は、様々な方法で、ハードウェア構成要素内で論理的に結合されてもよい。
【0018】
運航飛行プログラム（Operational Flight Program：ＯＦＰ）１０２は、輸送手段の全体的な動作を管理するためのハードウェアおよびソフトウェアを含む。ＯＦＰ１０２には、ランタイム診断エンジンＩＶＨＭＥｘｅｃ１０４が含まれている。また、ＯＦＰ１０２は、アビオニクスデータバスに受動的に取り付けられ、ミッション計画システムと能動的にインターフェースされ、地上システムおよび保守システム１２２と能動的にインターフェースされる、スタンドアロンのアビオニクスＩＶＨＭコンピュータとして実装されてもよい。ＩＶＨＭＥｘｅｃ１０４には、診断モデルベース推論（ＭＢＲ）エンジン１０６が含まれている。ＭＢＲエンジン１０６は、輸送手段システムまたはサブシステムの物理モデルを、システム状態を記述する入力データと結合し、次いで、システムが正常に動作しているか、システム異常が存在するかを決定するために決定論的推論を実行し、システム異常が存在する場合には、存在する障害および誤警報の位置および種類を分離し、識別する。ＩＶＨＭＥｘｅｃ１０４は、携帯型保守装置ビューア１２２によってもアクセスされ得るディスク１２６に保守記録を書き込む。
【0019】
ＭＢＲエンジン１０６は、データメッセージインターフェース１０８を介してリアルタイムセンサデータを受信する。また、リアルタイム動作インターフェース１１２を介して輸送手段のランタイム動作モデル１１０を受信する。輸送手段のモデル１１０は、モデル開発グラフィカルユーザインターフェース（ＧＵＩ）１１４を使用してモデリング技術者によって作成される。モデル１１０は、オフライン（非リアルタイム）でＭＢＲエンジン１０６により作成および検証され、その後、ＩＶＨＭＥｘｅｃ１０４のリアルタイム埋め込みビルドによって使用されるＸＭＬファイルにエクスポートされる。モデル１１０の作成に加えて、ＧＵＩ１１４は、モデルを検証するためにも使用される。検証および妥当性確認は、特定の入力データを使用せずに、モデルの内部論理および要素を試験（テスト）することである。このプロセスは、モデルが適切に動作することを妨げるエラー、または全く動作しないというエラーなしに、モデルが論理的に一貫していることを保証するために必要である。
【0020】
モデル開発プロセスのさらなるステップとして、試験マネージャ１１６は、シミュレートされた又は実際の飛行データ１１８に対して試験することによって、モデルを評価する。開発インターフェース１２０は、ＩＶＨＭＥｘｅｃ１０４ランタイムに静的または動的に（スタンドアロンＩＶＨＭＥｘｅｃの場合は静的に、グラフィカルユーザインターフェース（ＧＵＩ）との統合のためには動的に）実行可能にリンクされた別個のクラスである、ＭＢＲエンジン１０６アルゴリズムの修正および追加を可能にする。検証はモデルを論理的に試験するが、試験マネージャ１１６は、モデルの性能および出力が所望のものであることを保証する。モデルが検証され、試験されると、ＸＭＬモデル構成ファイル１１０が生成される。
【0021】
ＩＶＨＭＥｘｅｃ１０４は、モデルのＸＭＬ表現をロードし、輸送手段内の様々なバスから受信されるセンサデータメッセージおよび地上での再生のための様々なフォーマットで記憶された履歴データの少なくとも一方を入力するためにモデルを適用することによって、リアルタイムでＭＢＲエンジン１０６を実行する実行主体である。ＩＶＨＭＥｘｅｃ１０４はまた、開発インターフェース１２０を介して試験マネージャ１１６によって使用されてもよい。記憶装置インターフェース１２４は、ＭＢＲエンジン１０６を記録データ記憶装置１２６に接続させる。記録されたデータ１２６は、ログファイル、機器の完全なタイムスタンプされた状態、例えば、スナップショット、タイムスタンプされた故障／故障異常、検出、分離、および分離に関する任意の機能的評価を含む。ログファイルは、ＭＢＲエンジンソフトウェア状態（バージョン番号、故障および再起動）に加えて、他の航空ソフトウェアの識別子、そのバージョン番号、故障した場合は故障時の状態、ソフトウェアの再起動、および故障につながる機能評価を含むことができる。このデータの収集により、航空機で発生した実際のイベントの診断可視化の再現が可能になり、保守者は障害構成要素につながるハードウェア及びソフトウェア両方の相互作用をよりよく理解できるようになる。記録データ記憶装置１２６は、ＭＢＲエンジン１０６によって使用される生データおよびその処理の結果を記憶する。
【0022】
一実施形態では、ＭＢＲエンジン１０６は、動的に較正されたデータ入力能力と、論理ゲートのセット（共通集合ＡＮＤ、論理和ＯＲ、排他的論理和ＸＯＲ、その他）と、ルールと、事例（履歴）と、決定ツリーと、を含み、これらは、パラメータ化された直接アナログセンサデータと、対応する組込み試験（ＢＩＴ）入力と、のＩＶＨＭデータ融合のためにセンサ論理で組み合わされる。パラメトリックデータ、直接アナログセンサデータ、およびＢＩＴ結果の比較は、故障および誤警報予測における信頼性尺度を生成する。
【0023】
次に、ＭＢＲエンジン１０６が使用するモデルの作成の一例について説明する。一実施形態によると、モデルは、モデル化された輸送手段内の多くのソースからのデータ融合を提供する。具体的には、モデルはパラメータ化されたデータ入力機能を含むことができ、これは、ＭＢＲエンジン１０６が、異常の存在を判定するために、測定された物理量に対して固定的または動的に較正された境界値を有する、アナログおよび定量化されたデジタルデータ入力を含むことを可能にする。パラメータ化されたデータの異常判定は、単純な固定的境界値、物理的センサ動作に基づいて動的に変化する較正値、または信号雑音低減、ウィンドウ処理、待ち時間、および同様のパラメータ化されたデータ調整を含む、より複雑な判定特性に基づくことができる。これらのデータ較正パラメータおよび閾値は、システムのリアルタイム動作中の評価のためのセンサノード特性となる。機能（関数）は論理集合やオペランドとして表現でき、ルールは論理集合や自然言語の意味論、履歴挙動（事例ベース）、意思決定ツリー（フォールトツリー解析）として表現できる。例えば、圧力機能の場合、モデルは、流量圧力が提供されているかどうかを評価し、所望の機能論理に従って他の入力を組み合わせる。一実施形態では、各入力は、真として評価される機能に対して肯定的な結果を示さなければならないが、他の論理機能を使用してもよい。この機能のための様々なユーザ定義パラメータは、その機能のノードプロパティ（特性）として表現することができる。輸送手段のＸＭＬ ＭＢＲモデル１１０およびアビオニクス計算装置上で動作するバイナリＩＶＨＭＥｘｅｃ１０４リアルタイムエンジンは、輸送手段全体にＩＶＨＭ能力／機能を提供する。
【0024】
パラメトリック及びＢＩＴ ＭＢＲモデルは、それらの機能に関連する構成要素及びセンサを含むことができる。一実施形態では、輸送手段システムまたはサブシステムのモデルは、図３に示すような図式（グラフ）内のノードとして表すことができる。具体的には、図３は、図２のモデル開発ＧＵＩ１１４を使用して表される、診断的ノードまたは非診断的ノードの両方を含む環境制御サブシステム（environment control subsystem：ＥＣＳ）の一例を示す。説明上、特定の例を議論するが、本明細書で説明する原理は、輸送手段の任意のサブシステムまたはシステムに適用することができる。モデリング技術者は、図２のＧＵＩ１１４を介して図３のモデルと対話する。
【0025】
診断的ノードは、故障または誤警報を引き起こすシステム構成要素を決定するために、ＭＢＲモデル推論において直接使用され、一方、非診断的ノードは、センサ出力およびＢＩＴ試験比較などのタスクのために使用される。非診断的ノードは、パラメトリックセンサデータとＢＩＴデータ結果とのリアルタイム比較のために使用される。パラメトリックセンサは、真の（センサが故障していない場合の）システムの挙動を表し、ＢＩＴデータが対応する構成要素の故障を示しているときにそれらが名目上動作している場合、この結果は誤警報として示される。故障したセンサは、センサに対する誤検出および検出漏れ試験により識別される。流れ圧力構成要素などの構成要素は、当該構成要素をモデルの他の要素に接続することによって、その状態（例えば、オン、オフ、高圧または低圧など）およびステータス（動作中、故障、漏れなど）がＭＢＲエンジン１０６によって示される、特定のシステム要素を指す。センサノードは、多くの形態、例えば、直接センサアナログ入力、パラメトリックデータ入力、及びバイナリＢＩＴデータ入力をとり得る、入力データによりモデル化される。図３を参照すると、代表的な構成要素ノードが、ＥＣＳ流量圧力（ECS Flow Pressure）センサノード２０２として示されている。他の構成要素ノードには、ＥＣＳ流れ（ECS Flow）２０４、ＥＣＳ冷却（ECS Cooling）２０６およびＥＣＳ準備完了（ECS Ready）２０８が含まれる。
【0026】
図３のモデルにおける別の種類のノードは、機能ノードである。代表的な機能ノードが、流れ圧力供給（Provide Flow Pressure）ノード２１０として示されている。他の機能ノードには、流れ提供（Provide Flow）２１２、冷却提供（Provide Cooling）２１４、およびＥＣＳ準備完了提供（Provide ECS Ready）２１６が含まれる。図３の各機能ノードは、基本的ＡＮＤ関数（Basic AND function）を表す。例えば、流れ圧力提供（Provide Flow Pressure）２１０は、流れ圧力が提供されているかどうかを決定するために使用され（論理セットおよび論理オペランド）、所望の機能論理に従って他の入力を結合する。この例では、各入力は、結果として得られる機能の状態が真であるために、肯定的な結果を示さなければならない。機能ノード２１０のための様々なユーザ定義パラメータは、機能ノードアイコンをダブルクリックすることによってモデリング技術者によって見られることができ、これは、図４に示される機能ノード２１０のウィンドウを呼び出す。ノードプロパティで定義されるパラメータには、ノードクラス３０２、デフォルトパラメータ値３０４、およびノード２１０の能力、出力およびステータスデータタイプを定義するデータアイテム３０６が含まれる。図４には、特定のラベルおよび特徴が示されているが、これらは、モデル化される機能およびモデル化される輸送手段の設計に応じて変化し得る。
【0027】
図３のモデルにおける別の種類のノードは、物理的センサノードである。代表的な物理的センサノードは、図３にＥＣＳ＿流れ圧力（ECS_FlowPressure）ノード２１８として示されている。別の物理的センサノードがＥＣＳ＿温度（ECS_Temperature）ノード２３８として示されている。物理ノードおよび仮想ノードは、多くの形態をとり得る入力データを示すためにモデル内で使用される。上述したように、モデリング技術者は、ＧＵＩ１１４を介して図３のモデルと対話する。物理的センサノード２１８のための様々なユーザ定義パラメータは、ノードアイコンをダブルクリックすることによってモデリング技術者が見ることができ、これにより、図５に示す物理的センサノード２１８のウィンドウを表示する。センサノード２１８の場合、パラメータ化された入力データは、図５に示されるノードプロパティウィンドウ内のデフォルトとして定義される固定上限値および下限値（許容閾値）と共に使用される。パラメータ化されたデータの使用は、図５に見られるように、生の（未加工）値４０２としてセンサノードプロパティに列挙される、定量化されたセンサ値の直接分析を可能にする。この場合、センサ未加工値４０２は、ＥＣＳサブシステムについて測定された流量圧力を含む。未加工値４０２が下限値４０４を下回るか、または上限値４０６を上回る場合、センサは異常を示し、これは次いで、モデルの残りの部分とともにＭＢＲエンジン１０６（図２）によって、異常の性質および原因を決定するために使用される。
【0028】
物理的センサノードの別の例は、ＢＩＴ ＥＣＳ＿流れ圧力故障（BIT ECS_FlowPressureFault）２２０である。このセンサは、モデル化されたシステムからのＢＩＴ（Ｂｕｉｌｔ－Ｉｎ－Ｔｅｓｔ）データを使用し、データ出力における異常または正常な動作のいずれかを示す。このＢＩＴ試験は、対応するパラメータ化されたセンサと同じ上限値および下限値を使用するように設計されているが、異常動作の場合には異なる結果を生成する可能性がある。したがって、本発明者らは、ＢＩＴ試験を、別個のパラメータ化されたデータ入力と共に、排他的論理和（ＸＯＲ）又はセンサノードであるＸＯＲ＿ＥＣＳ流れ圧力（XOR_ECS_FlowPressure）ノード２２２への入力として使用する。場合によっては、ＢＩＴ試験センサのみが保守者に利用可能であり、この場合、ＢＩＴ試験は、ＥＣＳ流れ圧力（ECS Flow Pressure）２１８のためにここで使用されるパラメトリックセンサノードと同様に、診断的センサとして使用されるであろう。図３のモデルにおける他の物理的センサノードは、ＢＩＴ＿ＥＣＳ＿準備未完了（BIT_ECS_NotReady）ノード２４０およびＢＩＴ＿ＥＣＳ＿温度故障（BIT_ECS_TempFault）ノード２４２を含む。
【0029】
ＸＯＲ＿ＥＣＳ＿流れ圧力（XOR_ECS_FlowPressure）ノード２２２は、物理的センサノードＢＩＴ＿ＥＣＳ＿流れ圧力故障（BIT_ECS_FlowPressureFault）２２０およびパラメータ化された入力センサノードであるＥＣＳ＿流れ圧力＿ＮＤ（ECS_FlowPressure_ND）２２８からの入力を受信する。別個のパラメータ化された入力センサがＸＯＲ入力のために使用される理由は、この入力が非診断的である（診断サイクルが実行されない）からである。センサは、システムの故障および誤警報を判定するためにＭＢＲエンジンで使用されることを意味する診断的なものであってもよいし、ＭＢＲエンジン評価からそれらを除去するための非診断的なものであってもよい。ＸＯＲ論理及び出力が相補的であり、ＭＢＲエンジン処理とは分離されるので、ＸＯＲセンサ入力は、ＭＢＲエンジンとの干渉を防止するために非診断パラメトリックセンサ入力２２８が望ましい。ここで使用される例では、ＢＩＴ試験センサ２２０も、同じ理由で非診断的センサである。さらに、ＸＯＲセンサについては、各センサがそれに付属するダウンストリーム機能を有するという設計要求を満たすために、ブランク関数２２６を使用する。別のブランク関数が符号２３６に示されている。ノード２２２と同様に、ＸＯＲ＿ＥＣＳ＿温度（XOR_ECS_Temp）ノード２４４は、物理的センサノードＢＩＴ＿ＥＣＳ＿温度故障（BIT_ECS_TempFault）２４２およびパラメータ化センサノードＥＣＳ＿温度＿ＮＤ（ECS_Temperature_ND）２２４からの入力を受信する。
【0030】
ＸＯＲ＿ＥＣＳ＿流れ圧力（XOR_ECS_FlowPressure）ノード２２２は、別個の出力ストリームを生成し、接続されたセンサ（パラメータ化されたセンサノード２２８および対応するＢＩＴ試験ノード２２０）が異なる評価を提供する場合にのみ、正のブール結果を示す。通常の動作条件下ではこれは起こらないはずであり、したがって、ＸＯＲセンサノードは、システムのＢＩＴまたはパラメータ化された入力のうちの１つが異常な結果を提供しているときを判定するのに有用である。これにより、モデル作成者にシステムの健全性を診断するためのまた別のツールが提供され、そうでなければシステム健全性を分析することは困難である。
【0031】
ＢＩＴ試験データフィールドのみが利用可能である場合の例が、図３において、ＢＩＴ＿ＥＣＳ＿流れステータスフラグ故障（BIT_ECS_FlowStatusFlagFault）ノード２３０として示され、これは、センサ入力を流れ提供ノード２１２に提供する。この場合、ＢＩＴ試験ノード２３０は診断的ノードであり、ＭＢＲエンジンで直接使用される。図３に見られる他のモデル要素種類は、例えば、モデル機能を記述する、符号２３２で示されるコメントと、図３に示されるサブモデルに示されるものの外側のモデル要素が、サブモデル、具体的には冷却提供（Provide Cooling）機能ノード２１４と通信することを可能にする、出力アイコン２３４と、を含む。
【0032】
場合によっては、パラメトリックノードは、固定的な上限値および下限値を有さない。この場合、例えば図６に示すような、別個のノードクラスを使用することができる。このノードは、図３のサブシステムモデルの一部ではない。ここでは、時間とともに変化し得る較正値（例えば、較正電圧）を提供する第２の入力が使用される。測定値は、較正値の周囲で、較正マイナスパーセント（calib_minus_percent）５０２および較正プラスパーセント（calib_plus_percent）５０４（一般にサブシステムサプライヤ情報から決定される）によって定義されるパーセンテージ範囲内に収まる必要がある。この種のセンサノードは、パラメータ化されたセンサの限界に対する既知の較正値が存在する場合、図３および図５のＥＣＳ流量圧力（ECS FlowPressure）ノード２１８などの境界＿センサ＿ｃｆｇ（Bounds_sensor_cfg）クラスノードの代わりに使用することができる。
【0033】
一実施形態では、図３に示すようなモデルは、モデルの各要素に対応するデータフィールドのリストを含む。例えば、図７に示すように、ＥＣＳ_温度（Ｃ）（ECS_Temperature (C)）６０２値は、ＥＣＳサブモジュール内の診断的ＥＣＳ＿温度（ECS_Temperature）センサノード６０４および非診断的ＥＣＳ＿温度（ECS_Temperature）センサノード６０６にマッピングされる。これらは、このモデルのデータ入力として使用されるファイル形式のデータ列のラベルであり、各サブシステム内の様々なセンサのための全てのデータフィールドが、１つのファイル内で体系的に定義されることを可能にする。別々のデータ項目がＢＩＴ試験データノードに、および較正データ項目が較正されたセンサノードにマッピングされる。ドロップダウンメニュー６０８における未加工データ項目選択は、この例示的なデータ項目がＥＣＳ温度センサからの未加工（生）の測定値であることを示す。モデル内の各センサ（パラメトリックまたはＢＩＴ）は、較正されたパラメトリックセンサのための任意の較正値データセットと共に、データ項目にマッピングされる。
【0034】
再び図２を参照すると、モデル開発ＧＵＩ１１４を使用してＩＶＨＭ ＭＢＲモデルが構築された後（各サブシステムの動作をエミュレートするために、すべてのセンサ、構成要素、および機能が配置されている）、実際のまたはシミュレートされたシステムデータを使用してモデルを実行するには２つの方法がある。上述したように、ＧＵＩ１１４は、試験マネージャ１１６を用いて、記録された飛行データ１１８を用いてＭＢＲモデルを実行する直接的な方法を含む。図８は、新しい試験ポップアップウィンドウ７０２を有する代表的な試験マネージャウィンドウを示す。飛行再現試験７０４が選択されると、適切な試験シミュレートデータまたは実際の飛行データファイルが選択肢７０６から選択され、試験マネージャ１１６にロードされる。データファイルを使用してモデルの試験を実行すると、出力ファイルが生成され、これに続いて保存され、保守記録として書き込まれた分析診断結果と共に、閲覧することができる。既に飛行データを使用した他のテストは、７０８に示されるものから選択されてもよい。図８に示す特定の試験は代表的な例にすぎず、多くの他の試験を使用することもできる。
【0035】
代替的実施形態では、ＧＵＩ１１４（図２）を使用するモデリング技術者は、ＩＶＨＭＥｘｅｃ１０４（図２）のコマンドラインスタンドアロンバージョンを使用してモデルを試験することができる。この手順では、モデルとデータマッピングに関する情報を含むＸＭＬ（拡張マークアップ言語：Extensible Markup Language）ファイルが生成される。このファイルは、ＩＶＨＭＥｘｅｃ１０４のコマンドラインスタンドアロンバージョンで実行して、事前定義された記憶場所に出力ファイルを生成することができ、これはＰＭＤデータビューア１２２（図２）にロードすることができる。この結果は、試験マネージャ１１６で生成されたものと同じであるべきであるが、コマンドライン手順では、大量のデータセットと可変数のシステムＭＢＲモデルのバッチファイル処理を可能にする。
【0036】
モデル試験からの出力データの一例が、図９に示されている。ＭＢＲエンジン１０６（図２）は、ＥＣＳ冷却構成要素の故障を、ＥＣＳ＿温度（ECS_Temperature）ノード２３８として表されるパラメータ化されたＥＣＳ温度センサと、他の温度センサを含む他のサブシステム構成要素における補強証拠（これらのケースの一部では、例えば、ＬＴＡレーザ増幅器ドライバ温度（図示せず）であり、利用可能な唯一のデータはＢＩＴ試験であり、従って、この場合にはＢＩＴ試験ノードが補強証拠として用いられる）と、の両方における故障を用いて、分離している。図２及び図９に同様に示されるように、相互接続されたサブシステムのサブモデルの論理は、ＥＣＳ温度を測定するパラメータ化されたセンサＥＣＳ＿温度（ECS_Temperature）ノード２３８が、適切な補強証拠を有する異常であると判断されたときに、この結果を決定する。さらに、ＥＣＳ温度異常を測定するＢＩＴ試験ＢＩＴ＿ＥＣ＿温度故障（BIT_EC_TempFault）ノード２４２は、別個の故障を示しており、このセンサノードは非診断的であり、したがってシステム故障を判定するために使用されないが、非診断的ＥＣＳ＿温度＿ＮＤ（ECS_Temperature_ND）パラメトリックセンサノード２２４のための比較器として使用される。ＢＩＴノードとパラメトリックノード間の変動は、欠陥のあるＢＩＴ試験またはセンサを示すことができ、パラメータ化されたセンサを実装することによって追加される能力の１つである。
【0037】
図１０は、誤警報を生成するＭＢＲエンジン１０６の出力の一例を示す。この場合、配電ユニット（ＰＤＵ）Ｐ５Ｖセンサ８０２は、ＰＤＵサブモデルシステム内の電圧を測定するパラメトリックセンサであるが、このサブシステムのためのデータ入力が定義されたパラメトリック範囲から外れているため、異常を生成している。パラメトリックセンサノードの実装は、潜在的に煩雑なハードウェアＢＩＴ試験結果を回避して、このセンサデータの直接使用を可能にする。パラメータ化されたノードはまた、信頼性尺度の計算、スプリアス（偽）データポイントのためのデータのウィンドウ化、および同様の分析のために、定量的データの分析を直接可能にする。このサブモデルでは、パラメトリックノードＰＤＵ＿Ｐ５＿ＮＤ８０６と、ＢＩＴ＿ＰＤＵ＿Ｐ５＿電圧故障８０８からのＢＩＴ試験データとの間のＸＯＲ＿ＰＤＵ＿Ｐ５ノード８０４を使用する比較器分析が行われ、これら２つの結果の間に、センサまたはＢＩＴ試験の失敗を示す不一致があるかどうかが判定される。以下の例では、他のサブシステムは、システムハードウェアにおける実際の障害の場合に同様の異常を予想するので、異常は誤警報であると判定される。このような他の異常は存在しないので、ＭＢＲエンジン１０６は、この異常が誤警報であると判断することができる。
【0038】
本発明の中心的目的は、ノースロップ・グラマン社セクターの全ての輸送手段、航空機、その他のシステムに対して、高忠実度リアルタイム診断能力（誤警報（ＦＡ）拒絶、故障検出（ＦＤ）、故障分離（ＦＩ）、および機器故障に対するパラメータ傾向分析）を生成することである。本発明は、多数のハードウェアデバイスおよびオペレーティングシステム、ならびにシステムアビオニクス統合に対する、飛行中のリアルタイムシステム動作中にシステムの健全性を判定するための、組み込みソフトウェア診断能力を提供する。パラメトリックデータ入力とＸＯＲパラメトリック・ＢＩＴ比較器の融合とを実装することにより、システムは、定量的なセンサ入力を解析し、高度な故障と誤警報信頼度測度を開発し、有効なシステム健全性管理と診断能力を維持しながら、ＢＩＴ故障を特定し、解析する能力を有する。
【0039】
別段の指定なく使用される限り、用語「上側」、「下側」、「前」、「後」、「上に」、「下に」、および同様のそのような用語は、実施形態を特定の向きに限定するものとして解釈されるべきではない。むしろ、これらの用語は、相対的にのみ使用される。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
