JP5580200B2 - 航空機搭載のシステムのオペレーション・ソフトウェアをデバッグする方法およびその方法を実施するためのデバイス - Google Patents

Description

本発明は、システムのオペレーションがコンピュータ内の一連のロジック命令の実行に依存する場合のシステム・オペレーションの安全性の分野に関する。

特に、本発明は、一連のロジック命令を実行しなければならないシステム、特に、航空機搭載用電子システムなど、安全性要件が高いシステムのオペレーション・ソフトウェアをデバッグする方法に関する。

この方法は、開発者が機内搭載システムのオペレーション・ソフトウェア用の一連のロジック命令内のエラーを探索して訂正できるようにする。本発明は、航空術の分野、より詳細には、機内搭載システムのオペレーション・ソフトウェアにテストを実行する分野で特に有利であるが、この分野の専用ではない。

安全性の理由で、航空機搭載用システムは、システムのオペレーションが正しいかについてのチェックを受け、そのチェック中に、前記システムは、そのようなシステムを取り付けた航空機が飛行を許可される前、または営業利用に入るときでも、営業利用が許可される前の認可要件を満たしていることが証明される必要がある。

システムの搭載前に、これらのシステムは、認可機関によって出されている要件の中でも特に整合性および安全性要件を満たしていることをチェックするために多数のテストを受ける。これらの機内搭載システムは、特に航空機用のおそらく重要なオペレーション、例えば、操縦用のオペレーションを実行することを目的とした専用コンピュータであり得る。これらのシステムは、これ以降、コンピュータと称される。

現行のシステム・アーキテクチャでは、しばしば、各コンピュータは、１つの用途または同じ性質のいくつかの用途、例えば、飛行制御用途に専用となっている。各コンピュータは、ハードウェア部とソフトウェア部を含む。ハードウェア部は、少なくとも１つの中央処理ユニット（ＣＰＵ）および少なくとも１つの入出力ユニットを備え、コンピュータは、入出力ユニットを介してコンピュータ、外部周辺機器などのネットワークに接続される。

しばしば航空術の分野で実施される機内搭載システムの１つの本質的な特性は、実行される前記システムの専用機能に不要な手段の導入は極力回避するアーキテクチャ、すなわち、ソフトウェアと同じようにハードウェアに関係している。

したがって、航空術において普及している用途で一般的に見られるシステムとは反対に、本コンピュータは複雑なオペレーティング・システムを備えていない。加えて、ソフトウェアは、中央処理ユニットによって理解される言語に可能な限り近い言語で作成され、利用可能な入出力はシステム・オペレーションに必要な入出力のみ、例えば、センサまたは他の航空機要素から発生する情報、またはアクチュエータまたは他の要素に送信される情報である。

このタイプのアーキテクチャの利点は、そのようなシステムのオペレーションの方がより容易に制御されるという事実から生ずる。この利点は、一部の動作態様が制御不可のパラメータによって左右され、それとは別にアプリケーション・ソフトウェアと同じ安全性の実証が行われる複雑なオペレーティング・システムに依存しない。本システムは、実行される前記システムの機能に厳密に必要な手段のみを有するので、より単純であり、脆弱性がより小さい。

他方では、そのようなシステムの動作条件は検出することがはるかに難しい。例えば、本システムは、キーボードおよび画面などの従来のマン／マシン・インターフェースを一切備えておらず、このインターフェースによって一連の命令のオペレーションが正しいかがチェックでき、オペレータがこのオペレーションと対話できるのであるが、これを備えていないことが、ソフトウェアの開発、検証および認定フェーズ中に必要な本質的なチェックを行うことを困難にしている。

本コンピュータのソフトウェア部は、関連の用途に固有のソフトウェア・プログラムを含み、そのプログラムがコンピュータのオペレーションを確実にし、そのロジック命令が、システム・オペレーションを決定するアルゴリズムに相当する。

システム認可を得るために、システムの使用前および航空機の使用前にコンピュータ妥当性検査フェーズが実行される。

既知の方法では、妥当性検査フェーズは一般的に、コンピュータ実行プロセスの各ステップで、そのステップが、期待されるシステム・オペレーションを実行するように設定された仕様に準拠していることをチェックすることで行われる。

この仕様への準拠を検証する検証フェーズは、特にソフトウェア・プログラムに関して、最も単純なソフトウェア構成要素をチェックすることから、ターゲット・コンピュータで使用される構成要素のすべてを統合した完全ソフトウェア・プログラムをチェックするまでの連続するステップにより実行される。

第１の検証ステップにおいて、テスト可能な最も単純なソフトウェア要素が、単体テストとして知られているテストを受ける。これらのテスト中、個々に取り上げられる前記ソフトウェア要素のロジック命令、すなわち、コードが設計要件に準拠して実行されたことをチェックされる。

統合ステップとして知られる第２のステップにおいて、分離されたチェックを個別に受けた個々のソフトウェア構成要素が、中に含まれるソフトウェア構成要素どうしが対話する単体を構成するために統合される。これらの個別のソフトウェア構成要素は、そのソフトウェア構成要素が整合していること、特に前記構成要素間の機能上のインターフェースのレベルで整合していることをチェックすることを目的として統合テストを受ける。

第３のステップにおいて、ソフトウェア構成要素のすべてが、それらが設計された目標のコンピュータに統合される。次に、コンピュータに統合された構成要素のセットによって形成されるソフトウェアが仕様に準拠していること、すなわち、そのコンピュータは、期待される機能を実行すること、およびそのコンピュータのオペレーションが信頼できて、安全であることを証明するために妥当性検査テストが実行される。

ソフトウェア項目が安全であることを保証するため、および認可要件を満たすために、そのソフトウェアが受けたテストのすべてが、この妥当性検査フェーズ中にも、適切なレベルの確実性でもって、そのソフトウェアは、それが組み込まれたシステムの安全性要件に準拠していることを証明する必要がある。

妥当性検査フェーズ中にソフトウェアに実行される個別のテストは、前記ソフトウェアの誤動作（誤動作はコンピュータの正しいオペレーション、したがって航空機およびその安全性に影響を与えるおそれがある）が発生する可能性がないこと、または誤動作が発生した場合、ソフトウェアがこの状況を管理できることが保証されるようにすることができる。

いずれの場合にも、妥当性検査フェーズ中、中でも異常が観察される場合の調査オペレーションについては、そのソフトウェアが導入されているコンピュータの入出力パラメータが期待されるパラメータに適合するだけでなく、一部の内部ソフトウェア・アクションが正しいことも保証する必要があることが多い。

この場合、機内搭載用途向けの専用コンピュータの特殊なアーキテクチャのために、特定のデバイスおよび方法を実装せずにソフトウェアの動作条件を検出することは、一般的に非常に困難である。

第１の既知の方法は、ソフトウェアが導入済みの、テストされるコンピュータと関連のプラットフォームとの間に、エミュレータを使用することによりファイル配信システムを導入することで行われる。エミュレータとは、コンピュータ・プロセッサのコンピューティング・ユニットのロジック・オペレーションを関連のプラットフォーム上でシミュレートできるようにするデバイスのことである。

エミュレータが取り付けられたそのような動作モードでは、コンピュータ・プロセッサはプローブに置き換えられ、それにより、プロセッサ・エミュレーションをサポートする関連のプラットフォームとのインターフェースが作成される。

したがって、プロセッサ部を除いて、テストされるソフトウェアをコンピュータで実行すること、および関連のプラットフォームによって実行される機能によって、入出力ユニットの出力を検出することに加えて、例えば、前記入出力ユニットに対する入力シミュレーションに応答して動作条件または特定の内部ソフトウェア誤動作を検出することが可能になる。

この第１の方法は、多くの欠点がある。実際には、テストされる各タイプのコンピュータが特殊なテスト・ベッドまたは少なくとも非常に特殊なテスト・ベッド構成を必要とする。テスト・ベッドとは、特に、テストされるコンピュータをインターコネクトするための手段、コンピュータ・プロセッサ（複数可）をエミュレートするための手段、およびテスト・プログラムを実行するための手段を備えたユニットである。

各プロセッサは、エミュレーション・ソフトウェアの場合にも、プロセッサの代わりに接続されるセンサの場合と同じだけ特殊なエミュレータを必要とするので、コンピュータの定義に合わせてエミュレータの数を増やさなければならない。

さらに、エミュレータを使用して調査できることは、一般的に限定される。加えて、関連のプロセッサに固有の機械語を扱う必要があるため、開発者は、機械語プログラミングの専門家でなければならない。

さらに、エミュレータは高価な製品であり、一般的に少量が製造されるだけである。このタイプの製品の寿命は非常に短い（６カ月から２年）が、開発およびチェック手段のオペレーションの保守（規制、産業界の反応）は航空機プログラムの使用期間（２０年、おそらくそれ以上）を通して必要である。したがって、陳腐化の対処に関して問題が発生し、その問題は、解決がますます困難になってきている。

したがって、エミュレータを使用するというこの解決策は、調査についてパフォーマンスが限られることに加えて、導入および保守が両方とも高価であるために、十分に適合しているようには思えない。

一般的に設計の安全性の点で機能の冗長性を確保するために異なるモデルのプロセッサが使用され、したがって、同じだけエミュレータの必要性が増すという事実によってもコストが上がる。

第２の方法は、エミュレータの問題を克服することを目指して、ホスト・プラットフォーム上で、テストされるプログラムを実行するために使用されるコンピュータのオペレーションをシミュレートすることで行われる。この場合、テストされるソフトウェアは、テスト・ベクトルを読み取るため、またはテスト結果を記録するために、ホスト・プラットフォーム上のファイルにアクセスできなければならない。

テストされるソフトウェアは、当然ながら、ホスト・プラットフォーム・ファイルへのそのようなアクセスのための機能を有していないので、テストされるソフトウェアは、これらのアクセス機能を組み込むために修正される必要がある。

情報を転送するためには、通常はシステム呼び出し命令が使用されるが、システム呼び出し命令は、シミュレートされるテスト環境によって伝送される。システム呼び出し命令は、例えば、ファイルを開くこと、ファイルを書くこと、またはファイルを読み取ることでもあり得る。システム呼び出し命令は、ホスト・プラットフォーム・オペレーティング・システムによってインターセプトされ、そのオペレーティング・システムはシステム呼び出し命令をホスト・プラットフォーム・システム呼び出しに変換する。

この第２の方法も欠点がある。実際には、ファイルの多様さは、アクセス機能の開発が極端にホスト・プラットフォームおよびそのオペレーティング・システムに依存するという具合である。しかし、ホスト・プラットフォームの改変性は、時間的（ホスト・プラットフォームの置換）と同じように空間的にも（開発チームが世界中に配置されている場合）重要であり、そのことが、この方法の実施に際して実践の難しさを生み出す。

ファイル・システムへのそのようなアクセス機能を開発するためにオペレーティング・システムの機能を修正できる専門家が必要なので、これらの難しさは一層深刻になり、したがって、テストの専門家に任せられない。

したがって、この方法は、実施するには高価でもあり、難しくもある。

さらに、この方法は、テストされるソフトウェアに関しては非常に邪魔であり、テストを実行するためにソフトウェアを修正することは、ソフトウェアのオペレーション自体に支障を来す危険性がある。

コンピュータ・ソフトウェアの妥当性検査および検証フェーズ中、テストを実行することにより、エラーが検出されることがあるが、エラーは、オペレーション・ソフトウェアの走行を停止することで、または１つまたはいくつかのテスト事例でエラー結果が生成されることで示される。したがって、開発者は、これらのエラーを訂正するために、命令コード行の中の異常またはエラーを探索しなければならない。この探索は、実行パスのポイントの連続が通常の実行とは逆の順に現れるオペレーションによって行われる。つまり、一連のコード行が逆に再追跡され、エラーは、これらのコード行の中で探索され（すなわち、すでに実行されたが、１つまたは複数のエラーを含む一連のコード行が再追跡される）、再追跡された一連のコード行が再実行される。この探索は、逆実行として知られる。

この逆実行オペレーションは、オペレーション・ソフトウェアの、命令コード行の連続で形成される実行パスの任意のポイントにおける命令コード行を開発者が理解していることを必要とする。しかし、開発者は、実行パス内のどこにそのエラーがあるかを知らない。したがって、開発者は、逆実行オペレーションが何行のコードに対して実行されねばならないかを知らない。加えて、機内搭載ソフトウェアの場合、逆実行オペレーションは、通常の実行と同じ言語、すなわち、機械語で実行される必要がある。そのため、開発者が、一連の行を再追跡し、エラーを突き止めるためにオペレーション・ソフトウェア・プログラムの走行を十分詳細に理解することは難しい。さらに、エラーまたは異常を突き止めるためにその不良チェーンはどのポイントまで再追跡されねばならないかを開発者が知ることができるようにするための、逆実行オペレーションを制御および監視する手段がない。

その複雑さを考慮すると、このエラー探索は相当な時間を要し、それは数時間から数日に渡る可能性があり、そのため、生産性および労力の点でデバッグ・フェーズのコストは相対的に高くなる。これは、現行のデバッグ・ツールが逆実行オペレーションを効率よくサポートする手段を提供しないからである。これは、時間的にｎ個の単位（一般的に秒数）を再追跡するか、またはｎ個のコンピューティング・ステップを再追跡するかに関係する。デバッグされるソフトウェアのロジックとの機能的な関連性はない。したがって、これが、機内搭載ソフトウェアの事例が一般的にそうであるような複雑なロジックを有するソフトウェア項目を含む場合、逆実行オペレーションの効率が相当に悪化するか、または完全に失われることすらある。

本発明の目的は、前述された手法の欠点を克服することである。この目的のために、本発明は、オペレーション・ソフトウェアをデバッグし、開発者が、開発者によって書かれた一連の命令内のエラーまたは異常の位置を容易に突き止められるようにする方法に関する。これを達成するために、本発明の方法は、実行パスを機能別に順序付けることにより、オペレーション・ソフトウェア・プログラムの実行オペレーションを構成することに関する。この機能別順序付けは、プログラムを機能単位に分割するような方法でプログラムの通常の実行パス内の特定の位置にフラグを配置することにより行われ、これにより、開発者は、逆実行オペレーションをどこから実行しなければならないかの位置を突き止めることができる。この順序付けオペレーションは、対話式または自動で実行できる。

より厳密には、本発明は、機内搭載システムのオペレーション・ソフトウェア・プログラムをデバッグする方法であって、以下のステップ、すなわち、
ａ）実行パスを隣接する機能別インターバルに分割するために前記実行パスに沿ってフラグを配置することによりプログラムにフラグを付けるステップと、
ｂ）プログラムを通常に実行するステップと、
ｃ）フラグの状態ベクトルを使用してプログラムの実行状態を獲得するステップと、
ｄ）エラーが検出された場合、
d-1)そのフラグの状態ベクトルに基づいて不良機能別インターバルを探索するステップ、
d-2)この不良機能別インターバル内でプログラムを逆実行するステップ、
d-3)エラーを判定して訂正するステップ
を含むことを特徴とする方法に関する。

本発明の方法は、以下の特性の１つまたは複数を有することもできる。
− エラーは、プロセッサ例外エラーの後にプログラムが停止した時に検出される。
− 本方法は、エラーが見つかった機能別インターバルを改善するためのオペレーションを含む。
− 機能別インターバルを改善するためのオペレーションは、追加の入口および出口フラグ、および／または中間フラグを判定するステップを含む。
− 不良機能別インターバルを探索するステップは自動的に実行される。
− 不良機能別インターバルを探索するステップは、開発者の介入によって対話式に実行される。
− 本方法は、各フラグの位置、およびプログラムの実行状態に関する情報をホスト・プラットフォーム上の結果ファイルに記録するステップを含む。

本発明は、航空機搭載システムのオペレーションをシミュレートし、前述の定義による方法を実施するプロセッサを備えることを特徴とするデバイスにも関する。

本発明のデバイスは、以下の特性を有することができる。
− プロセッサは、テストおよびデバッグ・ホスト・プラットフォーム上で仮想的にシミュレートされる。

本発明は、制御ユニットにロードできて、制御ユニットにロードされて実行されると、前述の定義による方法を実施するための命令シーケンスを含む、航空機搭載システム用のオペレーション・プログラムにも関する。

本発明は、以下の説明を読み、添付の図面を精査すると、よりよく理解されるであろう。これらは、大ざっぱな指針として提示されるのであって、決して本発明の限定された指針として提示されるのではない。

本発明によるプログラムを概略的に示した図である。 本発明の方法のオペレーション図である。 機内搭載システムのオペレーション・ソフトウェアのデバッグ・フェーズにおけるテスト環境を概略的に示した図である。

オペレーション・ソフトウェアは、プログラムのセットで構成される。記述された一連の命令のセットで構成されるプログラムは、これ以降、命令チェーンと称する。本発明による方法は、機内搭載システムのオペレーション・ソフトウェア・プログラムの実行パス内の位置マーカを参照し、エラーまたは異常の位置をそれらの位置マーカについて判定する。

図１は、この方法の様々なフェーズを概略的に示している。図１に示された各フェーズは、本発明の方法の異なるステップでの、機内搭載システムのオペレーション・ソフトウェアのプログラムを表している。図１の第１のフェーズは、本発明の方法を適用する前のプログラムの例である。このプログラム、すなわち、参照番号２０は、命令チェーンのセット２０−１から２０−ｎを含んでいる。

これらの命令チェーンは、現れる順、すなわち、命令２０−１から命令２０−ｎの順に実行され、それによって、プログラムの通常の実行パスが形成される。

図１の第２のフェーズはプログラム２１を表しており、プログラム２１は、フラグ２８が配置された後のプログラム２０に一致する。フラグ２８は、プログラム内の特定の位置に配置された仮想マーカである。これらの位置は、個々のプログラム機能の先頭および／または末尾に一致することが好ましい。フラグ２８は、例えば、プログラム機能の入口ポイントまたは出口ポイントに配置される。各プログラム機能の入口ポイントまたは出口ポイントにフラグを配置することは、機能別順序でフラグを配置すると言われる。

フラグは、データ・フローのレベルまたは制御フローのレベルでの実行パス内の任意の、他の事前に定義された位置、例えば、プログラムの不良ポイントに配置することもできる。フラグは、プログラムの実行パス内にマーカを構成する。フラグは、このように、１つまたはいくつかの異常またはエラーが検出された時にプログラムの実行パスの走行中にマーカを構成する。異常またはエラーが検出されたことは、エラーの結果、プログラムの走行の中断、または無限の実行ループによって示される。

異常またはエラーは、機能関係もあり得る。その場合には、本方法は、開発者に前記異常またはエラーを訂正するように依頼する。

異常またはエラーは、プログラムの走行の制御を失わせる性質のものもあり得る。そのようなエラーは、例えば、プロセッサの算術オーバーフローもあり得て、その結果、例えば、ポインタは、禁止されたエリアを越えて配置されることがある。この場合には、プログラムの実行は中断される。算術オーバーフローの後に続く中断は、プロセッサ例外中断と呼ばれる。

本発明で説明される実行パスの機能別順序付けは、このタイプのプロセッサ例外中断エラーを検出し、訂正できるようにしている。これを達成するために、本発明による順序付けは、プログラムの実行パスを隣接する機能別インターバルに分割する。機能は、次から次へと実行される。本発明の実施形態の１つのモードでは、フラグは各機能の先頭に配置される。各フラグは、メモリからのイメージに一致する状態ベクトルを含む。この状態ベクトルは、事前に定義された位置、すなわち、フラグが配置された位置にあるメモリの状態を示し、これにより、後刻、状態ベクトルからの情報でメモリをリセットすることができる。

プログラム走行の開始時、すべてのフラグは非活動状態である。これらのフラグのそれぞれについての状態ベクトルは中性であるか、または非活動状態である。すなわち、状態ベクトルは、いかなる情報も持たない。１つの機能が通常に実行されるたびに、次の機能の入口ポイントに配置されたフラグが活動化することで状態を変化させる。したがって、このフラグの状態ベクトルは、プログラムの実行状態を獲得する。すなわち、プログラム実行のこのレベルでシステム・メモリに記録されている情報を獲得する。

順序付けオペレーションは自動的に実行できる。すなわち、フラグは各機能別インターバルの先頭に自動的に配置される。順序付けオペレーションは対話式にも実行できる。すなわち、開発者が同じ機能内に追加フラグを配置することを選択できる。これらの追加フラグは、入口フラグ、出口フラグ、および／または中間フラグが可能である。自動または対話式順序付けの選択は、開発者自身によって行われる。対話式順序付けは、エラーの探索および訂正インターバルを改善できるようにする。すなわち、前記インターバルを短縮することができ、したがって、エラー検出プロセスが容易になる。

図１の第３のフェーズはプログラム２２を表しており、プログラム２２は、通常モードでの前記プログラムの実行オペレーション中のプログラム２１に一致する。通常モードでのこの実行オペレーションは通常の実行と称されるが、この実行オペレーションは、第１の命令行２０−１から始まる、命令ごとのプログラムの論理的走行に一致する。

図１の第４のフェーズはプログラム２３を表しており、プログラム２３は、プログラムの実行状態およびフラグの位置に関する情報が獲得された時のプログラム２１に一致する。実際には、プログラムの通常の実行中、通常に実行された機能の末尾に配置されたフラグが活動化される。このフラグの状態ベクトルは、プログラム実行のこのレベルでのメモリの状態を獲得または記憶する。

プログラムの中断中、最後に活動化されたフラグが、プログラム中断が起きた機能を示す。このフラグの状態ベクトルが、不良機能が実行された時にプログラムが動作していた実行状態を突き止められるようにする。

情報を状態ベクトルによって獲得できるようにするために、通常の実行オペレーションを監視するツールはフラグを越えていくトラフィックを、通常に発生する順に、すなわち、プログラムの命令行の通常の実行どおりに判定する。フラグを渡り切ると、監視ツールは、最後に検出されたフラグの状態ベクトル内のメモリの状態を獲得し、この情報をデータ・メモリ４に記録する。

エラーが発生すると、開発者は、プログラム内の前記エラーを突き止めるためにプログラムの逆実行オペレーションを実行する。図１の第５のフェーズはプログラム２４を表しており、プログラム２４は、この逆実行オペレーション中のプログラム２３に一致する。この逆実行オペレーションでは、最後に活動化されたフラグに一致する機能、すなわち、状態ベクトルが獲得された最後の機能の最初の命令行まで実行オペレーションをリセットするために、プログラムをプログラムの通常の走行と比較したときにプログラムを逆に再追跡できるようにする。

つまり、逆実行オペレーションは、プログラムの命令チェーンを再追跡して不良命令チェーンの位置を判定するためにフラグに従って実行される。したがって、逆実行オペレーションは、単一の機能別インターバル内で実行できる。この機能別インターバル内で不良チェーンまたはエラーが検出されると、開発者はこのチェーン内でエラーまたは異常を探索し、それを訂正する。

フラグのおかげで、開発者は不良命令チェーンを容易に突き止めることができる。エラーが訂正されると、開発者は、他の起こりそうなエラーを検出するために逆実行オペレーションを続行することができる。実際には、本発明の方法では、実行パスは、単一のプログラム・デバッグ・フェーズ内でいくつかのエラーまたは異常が検出および訂正できるような方法で構成されている。

上述のデバッグ・フェーズ、すなわち、エラーを探索して訂正するフェーズは、図１のプログラム２５で表されている。

エラーが修正されて、開発者が次の、または前のエラーに移りたい場合、対話式フェーズが使用できる。この対話式フェーズでは、プログラム２６が対話式順序付けオペレーションを含んでおり、そのおかげで、開発者は、ある１つの機能別インターバルから別の機能別インターバルへスキップできる。

図２は、本発明の方法の様々なステップを詳細に示している。図２の機能図は準備ステップ３０を表しており、このステップでは、開発者によってデバッグ・フェーズが要求されているかをテスト環境制御ユニットが検出する。

開発者がデバッグ・オペレーションの実行を希望している場合、テスト環境制御ユニットは、ステップ３１で、実行パスを隣接する機能別インターバルに分割するために前記実行パスに沿ってフラグを配置することにより、プログラムのフラグ付けオペレーションを実行する。各フラグは、すでに説明したように、活動化された、または非活動化された状態ベクトルを有する。フラグの状態ベクトルは、プログラムの実行状態に関する情報が獲得されている場合、「活動化されている」と称される。したがって、フラグの状態ベクトルは、そのフラグの前の機能がエラーなしで実行されると、活動化される。その反対の場合、フラグの状態ベクトルは「非活動化された」ままである。

ステップ３２で、制御ユニットはプログラムの通常の実行を開始する。

ステップ３３で、制御ユニットは、プログラムの実行状態を知るためにフラグの状態ベクトルに状態情報を獲得する。

ステップ３４で、制御ユニットは、オペレーション・ソフトウェア・プログラムの実行に中断が起きたかを検出する。プログラムが機能することを停止した場合、エラーまたは異常が検出されている。その場合、ステップ３５が適用される。中断が起きていない場合、通常の実行オペレーションが続行され、ステップ３２および３３が繰り返される。

ステップ３５は、起きた中断はプロセッサ例外中断であるかを判定する。そうである場合には、ステップ３６が適用される。そうでない場合には、ステップ３７が適用される。この場合には、機能関係のエラーが検出されたため、または通常の実行オペレーションがエラーなしで完了したために、プログラムの実行オペレーションが終了したことを知らせるために開発者にメッセージが送られる。

したがって、この方法はステップ４３に進み、ステップ４３で、制御ユニットは、実行パスを後日に参照できるようにするためにフラグの位置をテスト結果ファイルに記録する。

ステップ４４で、テスト結果ファイルが閉じられる。ステップ４５は、テストの終わり、またはプログラムの実行オペレーションの終わりを示す最終ステップである。

ステップ３５でプロセッサ例外が検出されると、ステップ３６は、その不良チェーンが配置されている機能別インターバルを算出するために通常のパス内の最初の非活動フラグを探索する。次いで、ステップ３８が適用される。ステップ３８では、ステップ３６で判定された機能別インターバル内のエラーの探索インターバルを改善するために、開発者は、対話式で追加の入口フラグ、出口フラグおよび／または中間フラグを埋め込むことができる。ステップ３９で、データ・フローまたは制御フロー内で不良ポイントが検出される。これらの不良ポイントは、エラーを囲むインターバルをさらに改善できるようにする。これらの不良ポイントを判定後、ステップ４０は、エラーを囲む不良インターバルを明示する。

ステップ３８から４０は、逆実行オペレーション中のエラー探索プロセスを容易にするために、エラーを囲むインターバルが短縮される、本発明の実施形態の好ましいモードを形成することに留意されたい。

どの場合にも、この方法は、制御が、非活動フラグを検出するステップ３６から逆実行オペレーションのステップ４１まで単純に渡されることを含むことができる。この場合には、開発者は、エラーが検出された機能の全体に逆実行オペレーションを実行しなければならない。

ステップ４１で、逆実行オペレーションが開始され、開発者は、不良プログラム命令チェーンが検出された機能にまでプログラムを再追跡することができる。本発明の実施形態の１つのモードでは、逆実行オペレーションは２つの連続したフラグの間（インターバル）で実行される。これは、ほとんどの場合、不良機能の先頭および末尾に一致する。開発者に、ある１つのインターバルから別のインターバルにスキップさせないための特別な規制はない。実施形態の別のモードでは、逆実行オペレーションは、エラーを囲む改善されたインターバルに、すなわち、機能の一部分にのみ実行される。

ステップ４２では、開発者は、エラーのデバッグ・オペレーションを実行する。すなわち、開発者は、不良機能別インターバル内でエラーを突き止めて、訂正する。デバッグ・ステップ４２が完了すると、この方法は、プログラムが正しく実行できるかをチェックするためにステップ３１から繰り返される。

制御ユニットがそれ以上のプロセッサ例外中断を検出しない場合、制御ユニットは開発者に、プログラムのデバッグ・フェーズが完了したことを知らせるメッセージを送る（ステップ３７）。

本発明による方法は、ホスト・プラットフォーム上で仮想的にシミュレートされるシステムのテスト環境で実施できる。この方法は、専用のオペレーション・エミュレータを介して実際の機内搭載システムに接続されたワークステーションにインストールすることもできる。この場合には、フラグの位置および／または状態ベクトルは、開発者がアクセスできる媒体、例えば、ホスト・プラットフォーム上の結果ファイルに記録される（ステップ４３）。フラグ位置がすべて記録されると、結果ファイルは閉じられ（ステップ４４）、テストは完了する（ステップ４５）。結果のすべてにチェックが行われる（ステップ４６）。結果がすべて正しい、またはＯＫのとき、最終ステップ４７はこれらの結果がすべてＯＫであることを示す。結果のすべてがＯＫでない場合、ステップ３６から４２が繰り返される。

図３は、本発明による方法を実施する、機内搭載システムのオペレーション・プログラムのテスト環境制御ユニット１の例を示している。制御ユニット１は、プロセッサ２、プログラム・メモリ３、データ・メモリ４および入出力インターフェース５を備える。プロセッサ２、プログラム・メモリ３、データ・メモリ４および入出力インターフェース５は、双方向通信バス６を介して相互に接続される。

プログラム７は、プロセッサ２によって、プログラム・メモリ３にインストールされた命令コードのチェーンを使用して実行される。プログラム７の目的は、機内搭載システムのオペレーションを操作および制御することである。プログラム７は、網羅してはいないが、中断ハンドラ８、ライブラリ９、スケジューラ１０およびアプリケーションのセット１１を備える。

ライブラリ９は、プログラム７によって活動化された制御機能のコレクションを収納する。中断ハンドラ８の目的は、プロセッサ２からの予期していない要求にリアルタイムで対処することだけでなく、テスト環境の多重タスクの共存を保証することである。スケジューラ１０は、プロセッサ２が実行しなければならないタスクの処理において、様々な優先基準および使用可能なリソースに応じて優先順位を自動的に決定できるようにするサービス・プログラムである。

プログラム・メモリ３は、エリア１２に、プログラム７の機能別順序付オペレーションを前述のように構築し、エラーまたは異常を訂正するために、検出されたエラーまたは異常の位置を示すことができるようにする命令を収納する。

プログラム・メモリ３は、エリア１３に、プログラム７内のフラグ用の状態ベクトルを獲得するための命令を収納する。各活動化されたフラグの位置およびその状態ベクトルは、データ・メモリ４に記録される。

プログラム・メモリ３は、エリア１４に、プログラム７の通常の実行を開始するための命令を収納する。オペレーション・ソフトウェアのプログラム７の実行は、命令ごとに順次実行され、フラグの状態ベクトルを漸次活動化する。機能内でエラーが発生すると、プログラム７の実行は停止する。エラーが見つかった機能の後にあるフラグの状態ベクトルは活動化されない。したがって、最後に活動化されたフラグの状態ベクトルはマーカを構成し、不良機能、すなわち、エラーを含む機能の位置を示す。

プログラム・メモリ３は、エリア１５に、逆実行オペレーションを開始するための命令を収納する。逆実行オペレーションは、エラーが検出された場合、不良命令を含む機能にまでプログラムを後方に再追跡できるようにする。開発者は、その機能の実行オペレーションを再始動するために、最後に活動化された状態ベクトルに関連付けられたフラグに位置付けられる。したがって、開発者は、単にその不良機能に対して逆実行オペレーションを実行する。

プログラム・メモリ３は、エリア１６に、フラグを介して収集された情報を使用できるようにする命令を収納する。これらの命令は、プログラム７をデバッグできるようにする。

プログラム・メモリ３は、エリア１７に、開発者が機能別インターバル間をスキップできるようにする命令を収納する。つまり、エリア１７の命令コードは、プログラム７が通常実行モードで実行されているか、逆実行モードで実行されているかに関係なく、開発者が、ある１つの機能別インターバルから別の機能別インターバルへスキップできるようにする。

したがって、本発明の機能別順序付けオペレーションは、逆実行オペレーションを単一の機能に限定するために不良命令チェーンを突き止める手段を提供するので、前述の情報から、このオペレーションはソフトウェアを効率よくデバッグできるようにすることが推定される。さらに、このオペレーションは、単一のデバッグ・フェーズ内でいくつかのエラーを訂正できるようにもする。

１ テスト環境制御ユニット； ３ プログラム・メモリ； ４ データ・メモリ；
５ 入出力インターフェース； ６ 双方向通信バス。

Claims (9)

1. 機内搭載システムのオペレーション・ソフトウェアをデバッグする方法であって、以下の連続するステップ、すなわち、
   ａ）実行パスを隣接する機能別インターバルに分割するために前記実行パスに沿ってフラグを配置することによりプログラムに前記フラグを付けるステップ（３１）と、
   ｂ）前記プログラムを通常に実行するステップ（３２）と、
   ｃ）前記フラグの状態ベクトルを使用して前記プログラムの実行状態を獲得するステップ（３３）と、
   ｄ）エラーが検出された場合、続いて、
   d-1)前記フラグの状態ベクトルに基づいて不良機能別インターバルを探索するステップ（３６）、
   d-2)この不良機能別インターバル内で前記プログラムを逆実行するステップ（４１）、
   d-3)前記エラーを判定して訂正するステップ（４２）
   を含み、
   前記フラグの状態ベクトルは、プログラムの実行開始時は非活動化されており、前記フラグの前の機能がエラーなしで実行されると活動化され、
   前記機能内で前記エラーが発生するとプログラムの実行が停止し、
   前記不良機能別インターバルを探索するステップは、前記実行パス内の非活動化されたフラグを探索することを含み、
   前記エラーはプログラムが停止した時に検出されることを特徴とする方法。
2. 前記プログラムはプロセッサ例外エラーの後に停止し、
   前記探索された前記非活動化されたフラグは、前記プログラムの前記通常に実行する実行パスにおける前記非活動化された最初のフラグであることを特徴とする、請求項１に記載の方法。
3. 前記エラーが見つかった前記機能別インターバルを改善するためのオペレーションを含むことを特徴とする、請求項１または２に記載の方法。
4. 前記機能別インターバルを改善するための前記オペレーションは、追加の入口および出口フラグ、および／または中間フラグを埋め込むステップを含むことを特徴とする、請求項３に記載の方法。
5. 前記不良機能別インターバルを探索する前記ステップは自動的に実行されることを特徴とする、請求項１から４のいずれか１項に記載の方法。
6. 前記不良機能別インターバルを探索する前記ステップは、開発者の介入によって対話式に実行されることを特徴とする、請求項１から４のいずれか１項に記載の方法。
7. 各フラグの位置、および前記プログラムの前記実行状態に関する情報をホスト・プラットフォーム上の結果ファイルに記録するステップを含むことを特徴とする、請求項１から６のいずれか１項に記載の方法。
8. 航空機搭載システムのオペレーションをシミュレートし、請求項１から７のいずれか１項に記載の方法を実施するプロセッサ（２）を備えることを特徴とするデバイス。
9. 前記プロセッサ（２）は、テストおよびデバッグ・ホスト・プラットフォーム上で仮想的にシミュレートされることを特徴とする、請求項８に記載のデバイス。

Images