(57)【要約】  本原理に従うシステムおよび方法は、自動化された環境におけるソフトウェアおよびハードウェアテストをサポートするように設計されたテストアーキテクチャを提供する。ホスト環境、ホストユーザインターフェース、テストスクリプト、ホストターゲット間通信、ターゲットテストモジュール、ターゲットテストシェル、ターゲットコマンド、および他のサポート態様を含む、テストシステムの機能定義およびアーキテクチャを含むシステムおよび方法が説明される。
2019502297.tif 000002
【特許請求の範囲】
【請求項１】
共通のデータバスを使用して、多数のデバイス間のデータ通信を構成するためのシステムであって、
a.データバスを使用したメッセージの信号通信のために、第1のプロセッサベースのデバイスを設定することと、
b.前記データバスを使用したメッセージの信号通信のために、第2のプロセッサベースのデバイスを設定することと、
c.前記第2のプロセッサベースのデバイスへメッセージを送信するように、前記第1のプロセッサベースのデバイスを設定することであって、前記メッセージを送信するように設定することはさらに、前記第2のプロセッサベースのデバイスに関連付けられた設計保証レベルに従って、チェック値を生成することを含む、ことと、
d.前記第2のプロセッサベースのデバイスにおいて、表示または計算のために前記メッセージ内のデータを使用する前に、前記第2のプロセッサベースのデバイスの前記設計保証レベルに従って、前記チェック値を検証または確認することとを含む、システム。
【請求項２】
前記チェック値は、巡回冗長検査(CRC)値である、請求項1に記載のシステム。
【請求項３】
異なる設計保証レベルごとに、異なる設計保証レベルパラメータを提供することをさらに備える、請求項1に記載のシステム。
【請求項４】
前記チェック値を生成することはさらに、前記第1のプロセッサベースのデバイスに関連付けられた設計保証レベルに基づく、請求項1に記載のシステム。
【請求項５】
前記第1および第2のプロセッサベースのデバイスはさらに、前記システムが初期化されると、互いに、および/または、他の接続されたプロセッサベースのデバイスへ、ソフトウェア互換性メッセージを送信するように構成され、前記ソフトウェア互換性メッセージは、異なるデバイス間のソフトウェアの互換性を示し、受信された前記ソフトウェア互換性メッセージは、前記デバイスが相互運用性を持っているソフトウェアまたはソフトウェア構成を各デバイスが把握するように、リストに記憶され、各デバイスは、前記システム内の他のデバイスと相互運用する前に、少なくとも一度、相互運用性について前記リストをチェックするように構成される、請求項1に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
この出願は、以下の米国仮特許出願、すなわち、2015年11月13日に出願され「System, Architecture, And Method For Testing Software And Hardware Components」と題された第62/255,010号、2015年11月13日に出願され「System And Method For Common Approach Procedure」と題された第62/254,983号、および、2015年11月13日に出願され「System And Method For Coupling Existing Components」と題された第62/254,959号の優先権の利益を主張し、これらはすべて、その全体が参照によって本明細書に組み込まれる。
【０００２】
本発明は、アビオニクスシステムに関する。
【背景技術】
【０００３】
図1は、航空機の操作において使用され得るアビオニクスシステム100の1つの例を図示する。システム100は、ディスプレイデバイス102、ユーザ入力デバイス104、処理システム106、ディスプレイシステム108、通信システム110、ナビゲーションシステム112、飛行管理システム(FMS)114、1つまたは複数のアビオニクスシステム116、および、システム100の操作をサポートするデータ記憶要素118を含む。
【０００４】
ディスプレイシステム108は一般に、ディスプレイデバイス102における、1つまたは複数の航行地図の表示および/またはレンダリング、および/または、航空機の操作、および/または、システム110,112,114,116に関する他の表示を制御するように構成されたハードウェア、ソフトウェア、および/または、ファームウェア構成要素に相当する。この点に関し、ディスプレイシステム108は、たとえば、地形データベース、障害物データベース、航行データベース、地政学的データベース、ターミナル空域データベース、特別用途空域データベース、または、ディスプレイデバイス102における航行地図および/または他のコンテンツをレンダリングおよび/または表示するための他の情報のように、ディスプレイシステム108の操作をサポートするように適切に構成された1つまたは複数のデータベースへアクセスし得るか、または、このようなデータベースを含み得る。
【０００５】
処理システム106は、複数の空港に関する航空機操作手順情報(または、計器操作手順情報)を含み、かつ、航空機操作手順情報と、対応する空港との関連付けを保持している、データ記憶要素118を含んでいるか、その他の方法でそれにアクセスする。航空機操作手順情報は、特定の空港において、または、特定の空港の近傍において、航空機によって試みられ得る特定の航空機動作(たとえば、進入、出発、到着、上昇等)に関連付けられた操作パラメータまたは命令のセットを含む。たとえば、特定の航空機動作のための航空機操作手順情報は、その航空機動作を図解的に例示するグラフィック要素(たとえば、航行基準地点、航行セグメント、操作手順旋回等に関するシンボル)と、その航空機動作を実行するための操作パラメータまたは命令をさらに説明する、グラフィック要素に関連付けられたテキスト情報とを含み得る。たとえば、空港のための計器進入操作手順(IAP)は、進入コースを、進入コースへの/進入コースからの移行のための操作手順旋回とともに図解的に例示するシンボルおよび航行セグメントを含み得、それに加えて、進入操作手順は、これらシンボルに関連付けられたテキスト情報、および/または、操作パラメータを説明する、または、これらシンボルおよび/または航行セグメントの箇所に、または、その近傍に、航空機を操作するための命令を提供する航行セグメントを含む。
【発明の概要】
【課題を解決するための手段】
【０００６】
本開示の1つの態様では、本原理に従うシステムおよび方法は、自動化された環境におけるソフトウェアおよびハードウェアテストをサポートするように設計されたテストアーキテクチャを提供する。ホスト環境、ホストユーザインターフェース、テストスクリプト、ホストターゲット間通信、ターゲットテストモジュール、ターゲットテストシェル、ターゲットコマンド、および他のサポート態様を含むテストシステムの機能定義およびアーキテクチャを含むシステムおよび方法が説明される。
【０００７】
本原理に従うシステムおよび方法では、技術者またはプログラマは、構成要素のテスト可能性を有効化するために特別のテストコードを記述する必要はない。むしろ、1つの実施では、プログラマは、単に宣言をするだけでよいか、または、むしろ、たとえば様々な計器変数、すなわち「iVar」の宣言において、宣言がなされる手法を変えるだけでよく、このようにして、ソフトウェアまたはハードウェアは、外部の世界に対してテスト可能または「設定可能」となる。そうすることで、テスト構成要素はより便利になる。
【０００８】
本原理に従うシステムおよび方法の別の態様では、テストソフトウェアは、テストのためにロードされる必要はなく、特別なテスト「構築」も要求されない。テストは、実際のソフトウェアまたはハードウェア自身において生じ得る。これは多くの利点をもたらす。と言うのは、特に、アビオニクスまたは他のビークルナビゲーションまたは操作実施において使用される場合、構成要素はかなりのレベルの確認を必要とするためである。
【０００９】
本発明の利点は、いくつかの実施形態において、以下のうちの1つまたは複数を含み得る。テストアーキテクチャは、ソフトウェアおよびハードウェアの高レベルの自動化、反復、および総括的なテストをサポートするテスト環境を含み得、同じことが、ユニットレベルおよびシステムレベルのテストにおいて有利に適用され得る。
【００１０】
他の利点は、図面および特許請求の範囲を含む以下の説明から理解されるであろう。
【００１１】
この概要は、概念の選択を、簡略形式で紹介するために提供される。これら概念はさらに、発明を実施するための形態のセクションにおいて説明される。この概要において説明されるもの以外の要素またはステップが可能であり、要素またはステップが必ずしも必要とされる訳ではない。この概要は、特許請求された主題の重要な特徴または本質的な特徴を特定することは意図されておらず、また、特許請求された主題の範囲を決定する際における支援として使用されることも意図されていない。特許請求された主題は、この開示のいずれかの部分において注目されている任意のまたはすべての欠点を解決する実施に限定されない。
【図面の簡単な説明】
【００１２】
【図１】航空機の操作において使用され得るアビオニクスシステム100の一例を図示する図である。
【図２】ハードウェアおよびソフトウェア構成要素をテストするために使用され得るアーキテクチャの高レベルブロック図である。
【図３】図1に図示されるターゲットモジュールに組み込まれ得る組み込みテストソフトウェアモジュールのソフトウェアデータフロー図である。
【図４】一般化されたまたは共通進入操作手順の概要図である。
【発明を実施するための形態】
【００１３】
ハードウェアおよびソフトウェア構成要素のテスト
下記で説明されるように、テストアーキテクチャは、自動化されたテスト方法論を使用して、ソフトウェアおよびハードウェアの検証をサポートする検証ツールを提供し得る。このアーキテクチャは一般に、ハードウェアおよびソフトウェア構成要素へ適用可能である一方、1つの例示的な用途では、テストアーキテクチャは、ライン交換可能ユニット(LRU)および完全なアビオニクスシステムのテストを提供する。テストの出力は、テスト結果記録と、特有のテスト入力、および、アーカイブ可能なファイルへのテスト出力のログとを含み得る。特定の実施が以下に説明されるが、変形が可能であることが理解されるであろう。
【００１４】
図2に図示されるように、ホスト制御コンピュータ210は、1つまたは複数のターゲットハードウェア構成要素またはモジュール220を制御するために使用されるテスト環境を実行するホストエンジン214を有する。各ターゲット構成要素またはモジュール220は、1つまたは複数のプロセッサを含む。たとえば、1つの実施形態では、ターゲットハードウェア構成要素220は、おのおのが、図2に図示されるように、マイクロコントローラユニット(MCU)のようなプロセッサを含むライン交換可能ユニット(LRU)であり得る。MCUまたは他のプロセッサはおのおの、組み込みテストソフトウェアを動作させる。テストされているハードウェア構成要素およびそれに関連付けられたプロセッサは、本明細書において、ターゲットモジュール220と称されることがある。
【００１５】
アビオニクスシステムがテストを受ける場合、様々なターゲットモジュールは、アビオニクス構成要素と、LRU、ラック、ディスプレイ、PGP、AIU、APサーボコントローラ、および電源切替インターフェースを含む航空機電源のような航空機電力構成要素とを含み得る。
【００１６】
ホスト制御コンピュータ210は、たとえば、Python、Lab VIEW、または他のスクリプト/制御言語を実行し、テストスクリプトを実行する。ホスト制御コンピュータ210は、スクリプトコマンドを実行し、バイナリプロトコル216を使用して、たとえば、USBコントローラ間エリアネットワーク(CAN)またはCAN-over-Ethernetを経由して、ターゲットシステムのテストモジュールと通信する。システムスクリプトは、単一のテストへ結合される一連のLRU/MCUスクリプトであり得るか、または、マルチLRU機能のために意図された追加のテストであり得る。スクリプトは、設計保証レベル(DAL C)または独立テストエンジニア(DAL A/B)のために、ソフトウェア作者によって設計される。LRU/MCUスクリプトは、論理的に体系化され、ターゲットモジュールソースコードとともに記憶されることが意図される。
【００１７】
ホスト制御コンピュータ210はまた、グラフィカルユーザインターフェース(GUI)アプリケーション212を動作させ、トラブルシューティングのためにしばしば使用される機能へのユーザインターフェースを提供する。GUIは、ターゲットモジュールがLRUである場合のために、以下の特徴のうちの1つまたは複数をサポートし得る。
・接続されたすべてのLRUのビュー
・各LRUについて、モードをテストモードへ変更し、iVar(計器変数)をビューし、iVarを設定する能力
・iVarのための設定生成器
・iVarデータのグラフ表示
・LRU/MCUの生成
【００１８】
スクリプト
1つの実施形態では、ホスト制御コンピュータ210は、たとえば、テストホスト環境で構成されたMicrosoft Windowsを実行しているPC互換コンピュータであり得る。この環境は、テストを行うために必要なソフトウェアおよびデータを含む。あるいは、ホスト制御コンピュータ210は、Linux(登録商標) CPUであり得る。
【００１９】
バイナリプロトコルのようなテスト通信プロトコル216が、ホスト制御コンピュータ210とターゲットモジュール220との間の通信のために使用される。ホスト制御コンピュータ210物理インターフェースは、USB、イーサネット(登録商標)、およびPCIeであり得る。他のターゲットおよび機器インターフェースの場合はアダプタが使用され得る。
【００２０】
以前に言及したように、ターゲットモジュール220は、例示として、テスト中の完全なアビオニクスシステム、または、テストされるべき組み込みソフトウェアを実行しているプロセッサをおのおのが有する個々のLRUであり得る。図2に図示されるように、組み込みテストソフトウェアは、プロトコルレイヤ225、実行エンジン230、データ生成機能235、および計器変数アクセス機能240を含み得る。スクリプトによって使用されるデータは、直接符号化され得るか、または、データファイルに由来し得る。データファイルは、エンジニアデータ、内部データレコーダを使用する記録、テストシステム記録、外部データ生成器、およびターゲットデータ生成器から生成され得る。
【００２１】
本明細書で説明されるテストアーキテクチャは、期待される結果をターゲットデータと比較して、所与のテストシナリオのためのログされた合格/失格レポートを生成する能力を用いて、期待される結果をサポートする。期待される結果は、特有の値、または、許容可能な統計的なデータの評価として定義され得る。
【００２２】
以前に言及したように、ホスト制御コンピュータ210は、必要に応じて、USBまたはイーサネット(登録商標)を経由して、たとえばCANを介して、ターゲットモジュール220への通信をサポートする。正常なシステムであれば、DATA I/Oカード上のEthernet-to-CANを介して、アビオニクス計器ラックへ、CANデータを提供する。CANは、DATA I/Oカードが利用可能ではないこれら状況のために直接サポートされ得る。
【００２３】
ホスト制御コンピュータ210からターゲットモジュールへのCANインターフェースは、組み込みテストシステムと通信するために使用され得る。これは、ホスト制御コンピュータ210へ接続されたUSBまたはPCIeデバイスであり得る。ハブまたはスイッチを経由したホスト制御コンピュータ210からターゲットモジュール220へのイーサネット(登録商標)インターフェースが、ターゲットモジュールと通信するために使用され得る。
【００２４】
テストアーキテクチャによってサポートされ得る様々なインターフェースデバイスは、例示として、ホスト制御コンピュータ210(USBからシリアルデバイスが許可される)およびターゲットLRU UARTアダプタ、uSDカードアダプタおよびクラス10 uSDカード、テストIOアクセサリ、電源(公称12〜28v DC、5ワット)からのシリアルインターフェース、LRUのようなターゲットモジュールに特有の接続ケーブル、および/または、混合信号DIN、RJ45パッチ、DB9ヌルモデム、DB9 CANのようなラックインターフェース、RF信号生成器、GPS位置生成器、オーディオ信号生成器、航空機サーボ、GPIB-USBインターフェース変換器、および、GPIB-イーサネット(登録商標)変換器のようなテスト特有の外部データ生成デバイス、を含み得る。
【００２５】
ホスト制御コンピュータ210はまた、必要なインターフェースを介して、RF生成器、電源等のような外部テスト機器を操作することができ得る。
【００２６】
ホスト制御コンピュータ210によってサポートされるソフトウェアは、グラフィカルスクリプトデバッグをサポートする統合開発環境と、スクリプトおよびデータファイルを解析し、ユーザ入力を獲得し、ターゲットからデータを受信する機能を有するスクリプトインタプリタと、を含むホスト環境である。テストアーキテクチャはデータ駆動型であり得る。典型的なデータのタイプは、スクリプト、ターゲット特有の変換テーブル、入力データ、期待される出力、ターゲット生成出力、およびテスト結果を含む。
【００２７】
スクリプトは、ターゲットモジュールへ発行されるコマンドの集合のみならず、スクリプト自身のための算術演算、論理演算、および制御フロー演算のようなソフトウェアプログラミングの基本的な構築物として定義される。スクリプト言語は、構文、算術演算、論理演算、および制御フロー演算を提供するものである。スクリプトは、テスト通信プロトコルを経由してターゲットによってサポートされている、定義された方法のライブラリを使用して構築される。スクリプトは、他のスクリプトを参照または呼び出し得るという点において階層的であり得る。スクリプトは、ターゲット名からスクリプト名を切り離すために、ターゲット特有のエイリアスから連結名への変換テーブルを使用し得る。スクリプトは、テスト中に処理すべき、および/または、ターゲットへ通信すべき入力データを組み込む(読み取る)ことができる。スクリプトは、テスト中に、ターゲットによって生成されたキャプチャされたデータを出力することができる。スクリプトは、テスト中に、期待される出力データと、ターゲットによって生成された出力データとの比較に基づいて、テスト結果を出力することができる。
【００２８】
ホスト制御コンピュータ210への入力データは、テスト通信プロトコルにおいてあらかじめ定義されたデータであるか、外部機器から導出された、または、数学モデルまたは既知の入力を用いる関数から計算された入力データかのいずれかである。入力データは、テストされているターゲットモジュールを模擬、アクセス、および制御するために使用される。
【００２９】
ターゲットモジュールから読み取られたすべてのデータは、データ再生のために使用され得るフォーマットで、テストシステム内に保存され得る。
【００３０】
ホスト制御コンピュータ210によって取得される期待される出力は、テスト実行中に、ターゲット出力と比較されるべきデータのあらかじめ定義されたセットである。期待される結果は、テストスクリプト内に直接含まれ得るか、または、テストスクリプトによって外部ファイルとして参照され得る。すべてのテスト結果である合格/失格は、日付およびタイムスタンプ、テスト構成、実行されたスクリプト、およびバージョンとともに保存される。
【００３１】
ターゲットモジュールがアビオニクスシステムの構成要素である場合、図3に図示されるように、ターゲットテストソフトウェアモジュール310は、アビオニクス組み込みソフトウェアの構成要素である。テストモジュール310は、アビオニクス組み込みソフトウェア内のデータおよびコマンド350の投入および記録のための機能を提供する。それは、一般に、組み込みソフトウェアに含まれ得る(すなわち、一般にコンパイラフラグを用いてはコンパイルされ得ない)。それは、サポートされているすべてのインターフェースにおいて、アビオニクステスト通信プロトコルのプロトコルハンドリングを提供する。組み込みテストモジュール310は、以下により詳細に説明されるように、iVar320として知られているデータ要素をテストシステムへ提示するために、他の組み込みモジュールのためのインターフェースを提供する。組み込みテストモジュール310はまた、テストモードが非アクティブである場合、データの保全性を保証するためのモニタリング機能を提供する。
【００３２】
テストモードモニタ330は、テストインターフェースを経由してアクセスを制御する。このモードは、起動時にはデフォルトで無効にされている。ターゲットモジュールは、ホスト制御コンピュータ210から、テスト通信プロトコルを経由して提供される特有のコマンドシーケンスによって有効化されるテストモードを有し得る。アビオニクステスト通信プロトコルを経由してテストモードに入るように、不注意にテストモードへ入るのを回避するためにターゲットモジュール特有のキーが必要とされ得る。たとえば、LRUのようなターゲットモジュールに、たとえば、アクセスタイプが後続するarmのようなテストモードへ指示するために、2ステップの処理が使用され得る。テストシステムが有効化されると、テストインターフェースから獲得されるハンドルを経由して変数がアクセスされ得る。ターゲットモジュールがリセットされると、テストモードはデフォルトで無効にされ、新たなテストセッションが確立されねばならない。
【００３３】
組み込みテストモジュール310は、以下に説明されるアビオニクススクリプトAPIにおいて定義されるすべてのコマンドをサポートする。
【００３４】
iVarは、組み込みテストソフトウェアモジュール310がターゲットモジュールのシステムソフトウェアにおけるデータを修正するための主要なデータ投入地点である。iVarは、組み込みテストソフトウェアモジュール310を経由してアクセスされるために機能を追加したソフトウェアにおいて使用される変数である。これら変数は、変数をエイリアスによって参照するために、テストスクリプトによって使用されるUS-asciiテキスト名を用いて宣言される。iVarは、正常なプログラムフローを制御するためのモードフラグ、または、正常なプログラムフローを中断し、テストシステム限定の書き込みアクセスを許可するテストを含み得る。iVarモードが正常である場合は、正常なプログラムおよびデータフローが割当のために使用される。iVarモードがテストである場合は、正常なプログラムおよびデータフローがブロックされ、テストシステム割当のみが使用される。組み込みソフトウェアによるいずれのデータ変更も、変数のモードがテストに設定されている間は無視される。iVarは、モードが正常へ設定されることによって初期化される。iVarは、外部アクセスのために使用されるシステムにユニークな連結名で命名され得る。連結名定義の例が以下に提供される。
【００３５】
組み込みテストソフトウェアモジュール310は、テスト通信プロトコルを使用してコマンドによって、ホスト制御コンピュータから構成されるiVarのための内部データ生成器機能340をサポートする。データ生成器およびパラメータの例示的なリストが以下に提示される。
【００３６】
起動時に、ターゲットモジュールは無効化される。テストモードが有効化された場合、テストモードモニタ330は、モードフラグをチェックする。テストモードにおいてiVarモードフラグが発見されると、システムにエラーが通信される。1つの実施態様では、テストモードモニタ330は、少なくとも1Hzの周波数で実行する。
【００３７】
テスト通信プロトコルは、ホスト制御コンピュータ210とターゲットモジュールの組み込みテストモジュール310との間で通信するために使用される。リトルエンディアンビットオーダがこのプロトコルにおいて使用される。
【００３８】
テストモジュールがアビオニクスシステムである事象では、プロトコルは、組み込みテストモジュール310へ以下のコマンドをサポートし得る。
【００３９】
【表１】
2019502297.tif 000003
【００４０】
組み込みテストソフトウェアモジュール310によってサポートされた対応するコマンドを利用するためにテストスクリプトのために定義された機能が、以下に説明される。これら機能は、ホスト制御コンピュータによって、ターゲットモジュールへ変換される。
【００４１】
ターゲットモジュールがLRUである場合、スプリプトによってサポートされ得る例示的なLRU機能は、以下の通りである。
【００４２】
【表２】
2019502297.tif 000004
【００４３】
以前に言及したように、iVarへのアクセスは連結名を介し得る。連結名は、一般に、システム全体にわたってユニークである。連結名の階層が使用される。1つの実施態様では、連結名は、以下のように形成され得る。
【００４４】
【表３】
2019502297.tif 000005
【００４５】
許容される文字列:(0〜9、A〜Z、a〜z、_)。いずれのフィールドにおいても、他のどの文字列(すなわち、空白および「.」)も許容されず、許容されていない文字列は、「?」に置き換えられる。連結名は、フィールドを分離するために「.」を使用し得る。
【００４６】
以下は、スクリプトによってサポートされ得る例示的なiVar機能である。
【００４７】
【表４】
2019502297.tif 000006
【００４８】
受信されたiVar値に関する統計値を収集することがしばしば必要であり得る。以下は、収集されたiVarの履歴において使用され得るiVarの特性および関数である。最小、最大、平均、標準偏差、ソート履歴、履歴が範囲内であるかどうかのBoolean、度数が履歴からの範囲内であるかどうかのBoolean、履歴における値の数、および、履歴の平均レート。
【００４９】
スクリプトにおけるiVarは、ターゲットモジュールにおける値を表すメンバ変数「値」を有するオブジェクトである。iVarを、組み込みシステムの場合と同じように活用するために、いくつかの演算子は、iVarを値であるかのように使用することを可能にする。たとえば、2つのiVarを足すことは、それらのiVar値の総和の値を生成すべきである。同じことが、すべての標準的な数学的関数に当てはまる。たとえば、
Sum=iVar_l+iVar2
は、
Sum=iVar_l.value+iVar2.valueと等しい。
【００５０】
生成器は、iVarへのデータセットSを生成する。値は、設定レートに設定されるか、あるいは、データをロードする場合には、提供された時間に設定され、iVarは、ランプ関数を生成するように設定され得る。ランプのためのパラメータは、以下の通りである。低い値、高い値、低から高までの時間(秒)、高から低までの時間(秒)、および設定周波数(Hz)。
【００５１】
iVarは、以下のパラメータを用いて方形波を生成するように設定され得る。低い値、高い値、低における時間(秒)、高における時間(秒)。
【００５２】
データは、組み込みテストモジュールへストリームされ得る。サポートされ得る2つのタイプのデータは、固定周波数におけるデータと、各地点を設定するための時間を有するデータである。
【００５３】
自動化されたフォーマルな検証テストをサポートするために、合格/失格基準および結果として得られるテストレポートを提供するために、多くの検証スクリプト機能が提供される。テストスクリプトは、以下の情報、すなわち、スクリプトのSVNバージョン、サマリ合格/失格結果、を含み得るファイルにおいて結果をレポートし得る。1つまたは複数のテストが失格すると、サマリは、失格、1〜n個のテスト機能、1〜n個のJama ID、1〜n個のテストID、および合格/失格結果である。すべてのスクリプトは、おのおの説明を伴う、サポートされている1〜n個のJamaテストケースを有し得る。すべてのテストケースは、1〜n個のテストIDを有し得る。この結果は、特有のテストIDの合格/失格結果を提供する。
【００５４】
テストアーキテクチャは、ホスト/ユーザインターフェースのためのツール品質をサポートしているシステムを検証するテストケースのスイートを含み得る。
【００５５】
以下のアイテム、すなわち、ホストコントローラコンピュータ/組み込みテストモジュールへの、および、ホストコントローラコンピュータ/組み込みテストモジュールからのCAN通信、クライアントへブロードキャストされたエンジンウェブサーバからの通信が、ホスト制御コンピュータによってログされ得、受信されたiVar値と、スクリプト出力ログファイルは、ファイル名におけるログの日付とログタイプを含み得る。ログエントリは、日付および時間も含み得る。
【００５６】
いくつかの実施態様では、テストアーキテクチャは、スクリプトから、外部テスト機器の制御をサポートし得る。外部テスト機器は、汎用インターフェースバス(GPIB)によって、または、LANによって接続され得る。GPIBデバイスは、LAN-GPIB変換器を使用し得るか、または、制御言語によって直接アドレス指定され得る。外部機器との通信は、IPアドレスまたはLANアダプタのIPアドレスのいずれかと、GPIBアドレスとを必要とし得る。異なる設定を有するスクリプトの動作を有効化するために、設定は、機器との通信を記述する*.cfgファイルに設定され得る。
【００５７】
テストアーキテクチャによってサポートされ得る例示的なデバイスは、Keithley 2015 THDマルチメータ、IFR 2948通信サービスモニタ、Agilent E3634A電源、Laversab 6300圧力生成器、およびAgilent E4438C ESGベクトル信号生成器を含む。このリストは網羅的であることは意図されておらず、将来のテストをサポートするためにデバイスが追加され得る。いくつかの実施では、これらデバイスは多くのコマンドをサポートし得るが、テストアーキテクチャは、生成されたテストによって必要とされるものしか実施しない。
【００５８】
アビオニクスシステムは、一般に、データバスプロトコル仕様およびテストアーキテクチャ通信プロトコルに従って、CANバスメッセージを使用して、ボードからボードへ通信する。これらメッセージは、8バイトのCANメッセージ構造に収まり、(1つのLRUから別のLRUへ)導かれ得るか、または、すべてのLRUへブロードキャストされ得る。アビオニクスシステムがテストされていると仮定すると、ホスト制御コンピュータは、指定されたCANメッセージを送信および受信し、別のLRUを模擬するか、あるいは、LRU通信をリスンするかのいずれかを行うことができる。スクリプトは、CANメッセージを送信または受信し、適切な命令またはブロードキャスト仕様に従ってそのヘッダを設定し、データを設定し、それを送信/スヌープし得る。送信は、所与のレートでなされ得、インラインでデータ変更がサポートされる。
【００５９】
共通進入操作手順
計器進入操作手順(IAP)は、航空機が、初期進入の開始から着陸までを実行するためのあらかじめ決定された一連の操縦を提供し、そのような操作手順のためのデータは、FAAによって定義されている。正確な進入および不正確な進入を含む多くのタイプのIAPが存在する。正確な進入は、LPV進入を含む一方、不正確な進入は、ローカライザのみ、着陸するためのサークル、VOR、およびすべてのGPS進入を含む。進入の多様性は、パイロットが学習すべきスキルの多様性に至り、それにより知識のギャップと間違いの可能性を引き起こす。
【００６０】
図4を一部参照して示すように、本原理に従うシステムおよび方法は、一貫した方式で、すべての計器進入操作手順を取り扱い、単一のセットのパイロット操作手順が、すべてのタイプの進入を行うために使用され得ることを保証する。パイロットに関する限り、すべての進入が作動し、常にILS進入のように見える。言い換えれば、ナビゲーションのソースに関わらず、進入操作手順は一般に同じに見え、パイロットを常に、着陸するために良好な位置に据える。パイロットは、多数の方法ではなく、1つの方法を学習するだけでよいので、これは利点を与える。進入操作手順の選択後には、すべての進入がパイロットに対して同じに見える。
【００６１】
本原理に従うシステムおよび方法では、すべての進入操作手順が、システムに含まれるナビゲーションデータベースに含まれるデータによって定義される。このシステムは、進入操作手順を設定および計算することの他に、多くの態様を有し得、一般に、航空機の飛行速度、高度、およびナビゲーションをモニタするためのモジュール形式の空輸アビオニクスシステムに関連する。
【００６２】
そのようなシステムは、コンピュータハードウェア、コンピュータソフトウェア、センサ、および、モジュール形式のアビオニクスアーキテクチャによって作動するアビオニクスシステムインターフェースデバイスを含み得る。このシステムでは、FAAによって定義された標準的な進入データは、進入タイプに応じて補足情報によって増強され、これによって、移行を含む経路が完全に定義され、パイロットによって実行される進入操作手順の選択に関わらず、一貫性を持って見えるようになる。この追加データは、以下に、より詳細に定義される。
【００６３】
飛行されるべき進入タイプの選択は、パイロットのために便利な任意の時間においてなされ得、航空機またはトラフィック条件が変化すると、迅速に変更され得る。ILS進入の最終的な進入セグメントを除いて、すべての進入タイプは、GPS-WAASナビゲーション情報を使用し得る。進入タイプが閉じ込め境界を定義する場合、これら境界が守られる。境界が定義されていない場合、本原理に従うシステムおよび方法は、TERPS基準と一貫性を持つ境界を生成し得、この基準の下で、ベースライン操作手順が開発された。生成されたこれら境界は、FAA地形クリアランスガイドラインおよび航空宇宙クリアランスガイドライン内で常に良好であるように設定され得る。
【００６４】
この操作手順に対応するルートは、横方向および縦方向に完全に定義されているので、時間にクリティカルなパイロットモード切替は必要とされない。
【００６５】
この操作手順が承諾されると、横方向および縦方向のディスプレイが、この経路を飛行されるべき経路として図示する。飛行管制または自動パイロットガイダンスが選択されると、そのガイダンスは、適切なナビゲーション情報を使用して、定義された経路に従う。
【００６６】
最終的な進入セグメントでは、角度偏差データが表示され得る。進入操作手順の中心線は、公表された操作手順と一貫性を持つように保たれ得る。操作手順を表すために使用されるレッグタイプは、たとえば、決定すべき軌跡と、決定すべき半径であり得る。より詳細には、最終的な進入セグメントにおいて、ILSとLPV/LPとの両方の進入が、角度項における経路中心線からの偏差を定義する。ILSの場合、これは、地上から送信された信号の結果である。LPV/LP進入の場合、この偏差は、ナビゲーション操作手順データベースにおける高保全データブロックによって提供されるデータに基づいて、航空機内で計算される。他のすべての進入タイプ(NDB、VOR、VOR-DME、および非WAAS GPS等)について、本原理に従うシステムおよび方法におけるナビゲーションデータベースは、同様に定義された高保全性のデータブロックを含み得、最終的な進入偏差が、角度としてパイロットによって見られるようになる。
【００６７】
同様に定義されたFASデータブロックについての情報が、進入および空港情報から取得され得、オンボードデータベースが構築される前に、正確さおよび保全性に関してテストされ得る。テストが完了すると、同様に定義されたFASデータブロックが、「CRCラッパ」によって保護され得る。進入設定中に本原理に従うシステムおよび方法内でこのラッパを正確に復号することは、データブロックにおけるデータが危険に曝されていないことを保証する。CRC原理もまた、以下に説明される。
【００６８】
線形偏差情報から角度偏差への移行は、線形偏差境界(典型的には0.3nmと0.1nmとの間)が、最大角度偏差に等しい滑走路から離れて生じ得る。ILSの場合、表示された偏差データは、移行が生じる場合に実際に切り替えられる。他のすべての進入について、切替は必要とされない。これは、有効なRNP境界を、滑走路からの経路距離の関数として変化させることによって達成される。
【００６９】
ILS進入について、ナビゲーションは、GPSからILSへ切り替わる。航空機が、最終的なセグメントにあり、最終的な進入定点内となると、その切替は、パイロット動作に依存せず、正しいナビゲーションソースのパイロット確認を提供しない。自動パイロット/飛行管制モード移行は、飛行管理システムによって開始され得る。そのシステムはまた、インターセプト経路をも管理しているので、厳しいガイダンス協定基準を満足しなければならないことに関する配慮はない。ILSについて、このシステムは、進入経路に沿って航空機のパフォーマンスをモニタし得、2つのソースが最も近く一致する場合、GPSからILSナビゲーションデータへ移行し得る。たとえば、遅延ベクトルまたは超過速度が原因で適切な横方向または縦方向のインターセプト経路が達成されないのであれば、その事実は、グラフィックディスプレイ上で直ちに視認可能となり、進入をインターセプトするための新たな経路を要求する時間をパイロットに与える。
【００７０】
ILSを除くすべての進入について、切替は必要とされない。なぜなら、滑走路への経路が連続的に定義されているからである。結果として、パイロットモード選択も、内部ガイダンスモード選択も存在しない。
【００７１】
最終進入の角度セグメントのための境界線が、HSDおよびVFD上に描写され、パイロットに、進入の状態のグラフィック画像と、動向の明確な像とを与える。
【００７２】
システムは、直線または曲線の横方向進入経路と等しく良好に作動し得る。これは、現在の進入タイプとの互換性を保証し、最終的な進入定点の外部または内部の最終的な直線セグメントをインターセプトする曲線セグメントを有するRNPおよび進歩した進入経路を使用するための変更を必要としない。
【００７３】
このシステムは、進入のための公表された最低値を変更する必要はない。最低値は、公表された進入が基づく基準と、パイロットまたはオペレータによって加えられた任意の追加物とへリンクされたままである。
【００７４】
すべての進入タイプのための進入横方向ガイダンスは、進入復行地点を超えて、進入復行保持定点へと続く。周回縦方向ガイダンスが利用可能であり、進入復行保持高度または進入復行縦方向経路のうちの1つが定義されているのであれば、進入復行保持高度または進入復行縦方向経路へ自動的に移行し得る。
【００７５】
説明された共通進入操作手順(CAP)の結果得られる1つの利点は、より単純な学習である。なぜなら、ナビゲーションシステムへ利用可能なすべての計器進入操作手順を正しく飛行するために、ステップのうちの1つのセットしか学習する必要がないからである。任意の計器進入を飛行することは、他の任意の計器進入操作手順を行うために必要なスキルにおける練習を提供する。進入タイプが選択されると、それ以上のパイロット選択は必要とされない。これは、パイロットエラーまたは混乱に関するかなりの機会を取り除く。
【００７６】
高精度のGPS情報と、進入の角度最終セグメントとの使用は、進入操作の一貫性を高め、航空機が、最低値に達した場合に、各進入を完了するために、そこから固定された一貫性のある位置にあることを保証する。
【００７７】
この点に関し、いくつかの従来の計器進入操作は、操作手順旋回、または、操作手順旋回の代わりの保持パターンを含むことが注目される。これらは、本原理に従うシステムおよび方法によってサポートされる。しかしながら、本原理に従うシステムおよび方法内の実施では、これら操作手順へのエントリは、定義された経路である。これは、出発レッグのパイロットタイミングの必要性を取り除き、経路境界が、操作手順のための保護された空域内に留まることを保証する。
【００７８】
横方向および縦方向のグラフィックは、所望された経路に関する航空機の位置の明瞭な表示を提供する。強化された横方向および縦方向の動向情報は、航空機が経路を維持しているか、それとも経路から逸脱したかを一目で示す。
【００７９】
進入タイプの選択によって、適切な無線が調整され、ナビゲーション情報が選択されるようになり得、これらはすべて、選択された進入タイプに基づく。手動の入力は必要とされない。
【００８０】
一般化された進入機能のための基本的な目的は、操作手順を定義するために使用されるデータソースに関わらず、計器進入操作の非常に高いレベルの一貫性を達成することである。この機能は、高い利用可能性、正確なGPS情報を有することに依存する。この概念は、数年前にFAAによって導入されたLPV機能の拡張である。しかし、今は、それはより多くの操作手順タイプ、RNAV、RNAV-RNP、VOR、VOR-DME、およびNDBへ適用される。この概念は、任意の進入のための公表された最低値を変更せず、定義された飛行経路が、基本的な計器進入操作手順(IAP)を構築するために使用される地形および障害物クリアランス基準に完全に準拠することを保証する方式で構築される。
【００８１】
この経路が完全に定義されていることを保証するために、IAPは再定義され、ナビゲーションデータベースへ追加される前にテストされる。3D経路は、全体的に連続的であり、手順に沿って定義されたすべての地点において、公表された操作手順をオーバレイする。操作手順旋回および保持パターンは、関連するエントリであって、そのような操作手順からの退出移行として、完全に定義される。最終的な進入経路と、進入復行との間のリンクは連続的であり、パイロットが旋回を開始した場合はいつでも、定義された横方向経路が利用可能であることを保証する。縦方向の進入復行経路もまた完全に定義されるが、加速およびクリーンアップ中に、パイロット制御された縦方向の操縦を考慮する。
【００８２】
最終的な進入セグメント偏差は角度である一方、他のすべてのセグメントに沿った偏差は線形である。根本的な操作手順が、より小さな値を指定していないのであれば、フルスケールの場合の線形偏差許容値は、+/-0.3nmである。フルスケールの場合の縦方向の偏差許容値は、+/-75'である。
【００８３】
最終進入に関する縦方向のガイダンスは、GPS情報に基づき得る一方、最低値の決定は、気圧高度(MSL)のみを使用してなされ得る。
【００８４】
適切なFASデータブロックが、IAPによってサービス提供される特有の滑走路のために定義されているのであれば、そのデータは、変更を伴わずに、一般的な進入のために使用される。そのようなFASデータブロックが存在しないのであれば、図4に説明されるように、進入データブロックが生成される。進入データブロックが定義されているのであれば、それは、自身のユニークなCRCによって保護される。
【００８５】
より詳細には、従来のナビゲーション支援(VOR、ILS、またはNDB)を使用する多数レッグ進入は、
1.到着のレッグタイプ
2.出発のレッグタイプ
3.タイミング要件付きのヘディングレッグ
4.距離要求付きのヘディングレッグ
を有し得る。
【００８６】
これらレッグタイプのおのおのは、異なる操作手順を含み、異なる基準計器を含み得る。そのようなすべての操作手順は、パイロットによる時間クリティカルな動作を含み得る。
【００８７】
一般化された進入機能は、すべてのレッグに沿った操作を同じものにし、すべての時間クリティカルなパイロット動作要件を取り除く。
【００８８】
ナビゲーションデータベースにおいて符号化されたIAPは、TFレッグおよびRFレッグから、およびTFレッグ間のRF移行から限定的に構築される。IAPにおいて命名された中間地点は、操作手順において直接使用される。追加のシステム中間地点が、RFレッグおよび移行のために定義される。命名された中間地点をリンクするTFレッグは、これら地点の3D幾何に基づく。操作手順旋回のような単一の地点および角度によって定義されるレッグは、レッグに適用可能な保護された空域内に留まるように制約される。RFレッグは、航空機の速度カテゴリ(A、B、CまたはD)および保護された操縦空間に適切な半径を用いて定義される。移行は、定義されたRF経路であり、FAAが公表した操作手順において上空飛行として定義されていないのであれば、低空飛行である。
【００８９】
ILSの場合には、自動パイロットまたは飛行管制指揮とともに偏差データが、角度移行地点(図4におけるLTA)へ線形的に定義された操作手順において、GPSベースの情報から、ILS情報へ、自動的に切り替わる。他のすべての進入タイプは、最終的な進入セグメントに沿ってGPSデータを使用するが、LTAにおける角度偏差へ移行し続ける。LTA距離は、起点からの進入経路に沿って測定され、操作手順のために定義されたRNPに依存して変動する。RNPを除いて、LTA距離を計算するために必要な情報が、FASデータブロック(DO-229D、表D-1、頁D-5)または進入データブロックに含まれる(以下参照)。機内RNP計算機能からRNP値が取得される。これは、学習の目的のために、RNPの限定されたパイロット調節を可能にする。
【００９０】
LTA距離は、進入経路中心線に沿って測定され、進入経路中心線に対して垂直な偏差が、航空機場所において計算される。これは、一般化された進入機能が、直線的な進入、または、短い直線セグメントと交差する曲線的な進入と互換的であることを可能にする。すべての進入について、滑走路の進入端に最も近い中間地点と起点との間のセグメントは直線である。
【００９１】
通常、起点は、延長された滑走路中心線に沿って位置する。公表された進入経路が滑走路中心線と一致してない環境の場合は、起点と、滑走路の進入端に最も近い中間地点との両方が、横方向に(反対方向に)シフトされ、最低でも、航空機が、着陸前に視覚的なアライメント旋回を成功裏に完了する位置にあることを保証する。
【００９２】
一般化された進入幾何図の末尾にある表は、公表されたFASデータブロックにおける情報を、進入データブロックにおける類似の情報へ関連付ける。
【００９３】
FASデータブロックを備えた公表されたGPS進入は、必要であれば、地形または障害物クリアランスのために、数度だけ傾けられることを許可される。データブロックは、同じ機能をサポートし得る。経路回転が滑走路しきい値を中心とすることができれば、一般に最良である。これは、滑走路と揃うように単一の旋回がなされることを可能にする。この種の回転は、経路が無線支援と提携されたVORまたはNDB進入のために可能ではないことがあり得る。これらの場合、最低値は、「S」旋回アライメント操作手順を現実的に行うために十分に高くなるであろう。いずれの場合も、最終的な進入経路は、オリジナルの操作手順の障害物および地形クリアランスプロビジョンが違反されていないことを保証するために、送信機角度アライメント許容値を超えて公表された進入経路の外側にあってはならない。
【００９４】
進入データブロック
進入データブロックは、以下を例外として、DO-229D、付録Dにおいて定義されたFASデータブロックの形式に従う。
【００９５】
操作タイプ:進入データブロックを使用するすべての進入操作手順は、直線(タイプ0)であり得るRNAV-RNP操作手順を除いて、(たとえ、滑走路中心線に関して角度付けられていても)進入復行が後続する直線(タイプ0)または、進入復行が後続する曲線(タイプ3)とみなされる。
【００９６】
ルートインジケータ:進入データブロックを使用するすべての進入操作手順は、滑走路への単一の経路を有すると仮定され、したがって、このフィールドは使用されない。
【００９７】
基準経路識別子:これは、手順が基づく公表された進入操作手順のための「AL」番号である。
【００９８】
MAWP/RWWP/しきい緯度:WGS-84座標において、角度単位の秒でエンコードされた、命名された進入復行中間地点または滑走路中間地点または滑走路着陸しきい値の緯度を表す。FASデータブロックに関するものと同じ意味を使用されたい。
【００９９】
MAWP/RWWP/しきい経度:WGS-84座標において、角度単位の秒でエンコードされた、命名された進入復行中間地点または滑走路中間地点または滑走路着陸しきい値の経度を表す。FASデータブロックに関するものと同じ意味を使用されたい。
【０１００】
楕円上のMAWP/RWWP/しきい高さ:MAWP/RWWP/しきい地点のWGS-84高さを表す。このフィールドは、-512mのオフセットを備えた無符号の値として符号化される。このフィールドにおける0の値は、地球楕円体の下方512mに基準地点を置く。
【０１０１】
Δ起点緯度:WGS-84座標において定義され、角度単位の秒でエンコードされた、MAWP/RWWP/しきい値からの起点の緯度における差分を表す。FASデータブロックに関するものと同じ意味を使用されたい。
【０１０２】
Δ起点経度:WGS-84座標において定義され、角度単位の秒でエンコードされた、MAWP/RWWP/しきい値からの起点の経度における差分を表す。FASデータブロックに関するものと同じ意味を使用されたい。
【０１０３】
進入しきい交差高さ(TCH):進入TCH単位セレクタによって示されるように、フィートまたはメートルのいずれかで定義された着陸しきい地点上方のFAS経路の高さ。
【０１０４】
しきい値におけるコース幅:コース偏差インジケータのフルスケール偏向が達成されるMAWP/RWWP/しきい値地点においてFASによって定義される経路からの横方向の変位。このフィールドは、80メートルのオフセットを有する無符号の固定小数点の数として符号化される。これは、通常、約26mに設定され、350フィートのコース幅を生成する。
【０１０５】
Δ長さオフセット:このフィールドは使用されない。
【０１０６】
【表５】
2019502297.tif 000007
【０１０７】
進入データブロックテスト
ナビゲーションデータベースにおいて配信される前に、進入データブロックを含む各進入操作手順は、模擬されたシステムおよび保証されたTAWSを使用して、操作手順を飛行することによってテストされ得る。各IAFから、操作手順は、進入復行地点への連続的な経路を提供し得る。経路に沿ったガイダンスは、航空機を、位置において、公表された最も低い値へ位置させ得、ここから、特殊なスキルを用いずに、かつTAWSアラートが生じることなしに、着陸がなされ得る。
【０１０８】
少なくとも1回の進入復行が、進入データブロックを含む各操作手順について実行され得る。進入復行操作手順の縦方向成分は、通常のスキルを有するパイロットを表す方式で動作するようにプログラムされ得る。進入復行の横方向部分は、進入に関して飛行され得る。進入復行の横方向経路は、進入操作手順から連続し得る。横方向のガイダンスは、ギャップも不連続性も有さず、結果として、航空機は、いずれのTAWSアラートが生じることもなく、進入復行保持地点へ到着する。
【０１０９】
既存の構成要素の結合
本原理に従うシステムおよび方法は、航空機飛行速度、高度、およびナビゲーションをモニタリングするためのモジュール形式の空輸アビオニクスシステム(モジュール形式のスイートデバイス)に関し、コンピュータハードウェア、コンピュータソフトウェア、センサ、および、モジュール形式のアビオニクスアーキテクチャによって動作するアビオニクスシステムインターフェースデバイスを含み得る。システムおよび方法はさらに、既存の計器を搭載し、既存の計器とインターフェースするために便利な、そのようなアビオニクス構成要素に関する。1つの実施では、そのような構成要素は、OEM構成要素として搭載され得る一方、他の実施では、同じものがレトロフィット搭載に関し得る。
【０１１０】
より詳細には、以前の設計は、航空機上のアビオニクスシステムと他の機器との間の信号接続のほとんどのために個別の配線を必要とし、異なる設計保証レベルの情報のために、個別のデータバスを必要とした。その結果は、すべての搭載のために、時間の浪費、かつ、エラーの傾向のある航空機配線の労力であった。
【０１１１】
現在のシステムおよび方法では、特に、いくつかの構成要素を代替する新たなモジュール形式のスイートデバイスが搭載され、機能のスイートを提供する場合、既存のコネクタが適用され得る。言い換えれば、既存のシステムが計器へ接続されているのであれば、既存のコネクタが、新たな中央ボックスへ移動され、再配線の必要性と、それに付随する問題を取り除く。新たな中央ボックスは、同じ空間を占有し得、配線を延長する必要はない。
【０１１２】
多数の構成要素へアクセスする単一のデータバスの使用を可能にするために、直近の航空機において行われているように、各構成要素のグループのために個別のデータバスを有するのではなく、または、特定の設計保証レベルに関連付けられた各構成要素のグループのための個別のデータバスではなく、1つまたは複数の要因が適用され得る。したがって、本原理に従うシステムおよび方法は、1つの構成において、1)異なる設計保証レベルのデータを伝送する多数のデータバスが、単一のケーブルにおいてルート付けられることを可能にするデータバス構造と、2)異なる設計保証レベルの情報が、各LRUにおいて処理されることを可能にするライン交換可能ユニット(LRU)のほとんどにおける多数のプロセッサの存在と、3)機体とエンジンセンサと計器とをインターフェースするための既存のコネクタの使用と、を含み得る。
【０１１３】
より詳細には、本原理に従うシステムおよび方法は、異なる設計保証レベルのデータが同じデータバスにおいて送信または混合され得る手法に関する。
【０１１４】
特に、「設計保証レベル」または「設計クリティカリティ」は、安全に関して異なるクリティカリティのレベルを有するデータに関連する用語である。たとえば、ピッチおよびロールデータが安全性クリティカルである一方、乗客の読書灯に関するデータは、それほどでもない。それでもはやり、1つのみのバスまたはほんの少しのバスしか使用されないのであれば、両タイプのデータがデータバス上に現れ得る。これらデータタイプは、最も重要なデータのための設計保証レベル「A」から、最も重要ではないデータのための設計保証レベル「D」まで及び得る。本原理に従うシステムおよび方法は、多数のデータバスの使用を排除しないが、多数のタイプのデータが、単一のバスにおいて伝送および混合されることを有効にする。
【０１１５】
より詳細には、多数のタイプのデータが単一のバスを使用してメッセージによって送信される場合、問題が生じ得る。たとえば、低い設計保証レベルを有するアビオニクス構成要素が、プログラミングのエラーによって、高い設計保証レベルに関連付けられるべきメッセージの送信を開始し得る。この場合、そのようなメッセージの受取人は、データが、低い設計保証レベルのデバイスを起源とするものであることに気付かず、それがかなり欠陥のあるものであっても、そのようなデータを計算および表示において不利に使用し得る。明らかに、より低い設計保証レベルのデバイスが、より高い設計保証レベルのデバイスを乱すことは望ましくはない。
【０１１６】
したがって、本原理に従うシステムおよび方法は、たとえば、短い巡回冗長検査(CRC)のようなチェック値の、各メッセージ、すなわち各データ送信との統合を組み込む。すなわち、送信されるべきメッセージを生成するソフトウェアはさらに、各メッセージのための個別のCRCを生成する。個別の異なるCRCは、異なる各データ保証レベルのために適用され得る。たとえば、設計保証レベル「A」データは、レベル「A」CRCを使用し得るという具合である。その後、1つのレベルのためのCRCを生成するデバイスまたはソフトウェアが、異なるレベルのためにこのCRCを生成できないことを保証することによって、システムの保全性が保証され得る。そのようなものは、適切なルールベースのシステムによって強化され得る。したがって、このように、データは、異なる設計保証レベルを有するデータを物理的に分離する必要なく、データバス上で混合され得る。なぜなら、データ自身が、組み込まれた設計保証レベルを有しているからである。
【０１１７】
使用では、特定のデバイスによって「消費された」すべてのメッセージは、デバイスによって使用されることが許可される前に、たとえばCRCのようなチェック値の使用によってチェックされたその有効性または保全性を有する。
【０１１８】
そのようなシステムの利点は、処理が多数のデバイスにわたって分散され得ることであるので、単一地点の欠陥の問題を回避する。しかしながら、そのような分散されたシステムを提供する際に、1つのデバイスからのデータが別のデバイスからのデータに悪影響を与え得る。上述したように、送信されたメッセージにおいてCRCを使用することによって、この欠点は解消される。
【０１１９】
そのようなシステム別の態様は、設定制御に関する。設定制御は、多数のデバイスを有するシステム、または、データバス上のプロセッサベースのシステムの制御に関する。たとえば、説明されたアビオニクスシステムでは、いくつかの実施および構成が、バスに結合された25個以上のプロセッサを含み得る。異なる構成要素間のソフトウェア負荷は、そのようなシステムにおいて、重要であるが複雑な問題となる。したがって、これに対処するために、また、どの設定が適切に動作し、どの設定が動作しないのかの確認を可能にするために、本原理に従うシステムおよび方法は、システムによって使用される各メッセージのためのソフトウェア互換性コードを提供する。言い換えれば、上述したように、各メッセージは、送信される場合、設計保証レベルCRCを有する。しかし、各メッセージはまた、特にシステム初期化時に、1つまたは複数のユニットへ送信されるソフトウェア互換性コードをも組み込み、これによって、各デバイスは、近隣のLRUとのソフトウェア互換性を把握するようになり、その後、各デバイスが相互運用しているソフトウェアの相互運用性が確認されていることを保証するために、そのリストをチェックし得る。相互運用性に関する情報は、メッセージによって送信され得る。
【０１２０】
本原理に従うシステムおよび方法は、個別の回路遮断器を有する各機能のための個別の電力配線を必要とし得る。これら接続は、モジュール形式のスイートデバイス端部に既に取り付けられている、事前に組み込まれたケーブルを用いて容易とされ得、適切な回路遮断器へ取り付けられる準備ができている。モジュール形式のスイートデバイス内の他のすべての電力接続は、事前に設置されたケーブルで行われ得る。すべてのアンテナケーブルおよび少数の残りの信号線は、モジュール形式のスイートデバイス端部に、事前に設置され得る。航空機オリジナルのメイン計器パネルは、必要なすべてのモジュール形式のスイートデバイスディスプレイ、ラック、および、事前に設置されたハードウェアをマウントしたエンジンインターフェースユニットを備える新しいパネルに置き換えられ得る。モジュール形式のスイートデバイスシステム、すべてのLRU、ケーブル、パネル、およびブラケットの全体が、事前にテストされたキットとして出荷され得る。これは、付随するトラブルシューティング時間およびダメージ危険度を伴う、設置中の配線エラーの可能性を大幅に低減する。
【０１２１】
本明細書で説明されたシステムおよび方法は、任意の数のコンピューティングデバイスにおいて完全に実施され得る。典型的には、一般には非一時的であるコンピュータ読取可能な媒体に命令がレイアウトされ、これら命令は、コンピューティングデバイスにおけるプロセッサが、本発明の方法を実施することを可能にするために十分である。コンピュータ読取可能な媒体は、実行時に、ランダムアクセスメモリへロードされる命令を有するハードドライブまたは固体記憶装置であり得る。たとえば、複数のユーザから、または、任意の1人のユーザからのようなアプリケーションへの入力は、任意の数の適切なコンピュータ入力デバイスにより得る。たとえば、ユーザは、キーボード、マウス、タッチスクリーン、ジョイスティック、トラックパッド、他のポインティングデバイス、または、計算に関連するデータを入力するために他のそのようなコンピュータ入力デバイスを利用し得る。データはまた、挿入されたメモリチップ、ハードドライブ、フラッシュドライブ、フラッシュメモリ、光学媒体、磁気媒体、または、他の任意のタイプのファイル記憶媒体によって入力され得る。その出力は、ビデオグラフィックカード、または、ユーザによって見られ得るディスプレイへ結合された統合グラフィックチップセットによってユーザへ配信され得る。あるいは、結果のハードコピーを出力するために、プリンタが利用され得る。この教示を与えられると、任意の数の他の明瞭な出力もまた、本発明によって考慮されることが理解されるであろう。たとえば、出力は、メモリチップ、ハードドライブ、フラッシュドライブ、フラッシュメモリ、光学媒体、磁気媒体、または他の任意のタイプの出力に記憶され得る。本発明は、たとえば、パーソナルコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、ネットブックコンピュータ、ハンドヘルドコンピュータ、携帯情報端末、モバイル電話、スマートフォン、タブレットコンピュータ、および、これら目的のために特に設計されたデバイスのように、任意の数の異なるタイプのコンピューティングデバイスにおいて実施され得ることもまた注目されるべきである。1つの実施では、スマートフォンまたはwi-fi接続デバイスのユーザは、ワイヤレスインターネット接続を使用して、サーバから自分たちのデバイスへ、アプリケーションのコピーをダウンロードする。適切な認証操作手順およびセキュアなトランザクション処理が、販売者への支払いを可能にすることができる。アプリケーションは、モバイル接続によって、または、WiFiまたは他のワイヤレスネットワーク接続によってダウンロードされ得る。その後、アプリケーションは、ユーザによって実行され得る。そのようなネットワークシステムは、複数のユーザが、システムおよび方法へ個別の入力を提供する実施のための適切なコンピューティング環境を提供し得る。テストアーキテクチャが考慮される以下のシステムでは、複数の入力は、複数のユーザが、関連するデータを同時に入力することを可能にし得る。
【符号の説明】
【０１２２】
100  アビオニクスシステム
102  ディスプレイデバイス
104  ユーザ入力デバイス
106  処理システム
108  ディスプレイシステム
110  通信システム
112  ナビゲーションシステム
114  飛行管理システム
116  アビオニクスシステム
118  データ記憶要素
210  ホスト制御コンピュータ
212  グラフィカルユーザインターフェースアプリケーション
214  ホストエンジン
216  テスト通信プロトコル
220  MCUターゲットモジュール
225  プロトコルレイヤ
230  実行エンジン
235  データ生成機能
240  計器変数アクセス機能
310  組み込みテストモジュール
320  Ivarリスト
330  テストモードモニタ
340  データ生成器機能
【図１】
2019502297.tif 000008
【図２】
2019502297.tif 000009
【図３】
2019502297.tif 000010
【図４】
2019502297.tif 000011
【国際調査報告】
2019502297.tif 000012