(57)【要約】  本発明は、航空機搭載のオペレーション・ソフトウェアのデバッグ・フェーズ中に扱われる情報の量を処理するための方法であって、ａ）進行ポイントをプログラムの各機能に配置することによりオペレーション・ソフトウェアの実行経路を機能別インターバルに分割するステップ（３２）と、ｂ）各進行ポイントに関連する制御ポイントを配置するステップ（３３）と、ｃ）プログラムの正常な実行ステップであって、実行状態の記憶は進行ポイントのための前に記憶された実行状態の削除を生じさせることになる、各進行ポイントの場所におけるプログラムの実行状態を記憶するステップと、エラーの検出直後に、欠陥機能に対応する進行ポイントを探索するステップと、ソフトウェア開始実行状態を探索するステップ（４１）と、開始実行状態を再生成するステップ（４２）と、欠陥機能内のエラーを訂正するステップ（４４）と、プログラムを再実行するステップとを備える、プログラムの正常な実行ステップとを備えることを特徴とする方法に関する。
2010539577.tif 000002
【特許請求の範囲】
【請求項１】
搭載システムのためのオペレーション・ソフトウェア・プログラムのデバッグ・フェーズ中に扱われる情報の量を処理するための方法であって、
ａ）進行ポイントを前記プログラムの各機能に配置することにより前記オペレーション・ソフトウェアの実行経路を機能別インターバルに分割するステップ（３２）と、
ｂ）各進行ポイントに関連するチェックポイントを配置するステップ（３３）と、
ｃ）前記プログラムの正常な実行ステップであって、
c-1)各進行ポイントの場所における前記プログラムの実行状態の記憶と、
c-2)前記進行ポイントのための前に記憶された実行状態の除去を生じさせることになる実行状態の記憶と、
c-3)エラーの検出直後に、
陥機能に対応する前記進行ポイントを探索するステップ、
ソフトウェア開始実行状態を探索するステップ（４１）、
前記開始実行状態を再生成するステップ（４２）、
前記欠陥機能内の前記エラーを訂正するステップ（４４）、
前記プログラムを再実行するステップ
を備含む、前記プログラムの正常な実行ステップと
を備えることを特徴とする方法。
【請求項２】
単一の実行状態がデータ・メモリに一度に記憶されることを特徴とする、請求項１に記載の方法。
【請求項３】
機能の前記正常な実行後に、前記機能に対応する前記進行ポイントが非アクティブ状態からアクティブ状態に変わることを特徴とする、請求項１または２に記載の方法。
【請求項４】
前記欠陥機能の前記探索は、最後のアクティブ進行ポイントを探索することから成ることを特徴とする、請求項３に記載の方法。
【請求項５】
進行ポイントの状態を有する進行ポイントのリストが記憶されることを特徴とする、請求項３または４に記載の方法。
【請求項６】
航空機搭載のコンピュータのオペレーションをシミュレートするデバイスであって、請求項１から５のいずれか一項に記載の方法を実施することを特徴とするデバイス。
【請求項７】
前記プログラムの実行状態を記憶することができるデータ・メモリ（４）を含むことを特徴とする、請求項６に記載のデバイス。
【請求項８】
前記プログラムがユニット上にロードされ、実行されるときに、請求項１から５のいずれか一項に記載の方法を実施するためにコード・シーケンスと共に制御ユニット（１）上にロードされる、搭載航空機システム用のオペレーション・ソフトウェア・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、航空機搭載のオペレーション・ソフトウェアのデバッグ・フェーズ中に扱われる情報を処理するための方法に関する。この方法は、開発者が情報の量を、したがって搭載オペレーション・ソフトウェア内のエラーを調査および訂正するために必要とされるメモリ・リソースを、かなり低減することができるようにする。
【背景技術】
【０００２】
本発明は、航空分野に限らないが、とりわけ搭載オペレーション・ソフトウェアをテストするのに特に有利な用途を有する。
【０００３】
安全のために、航空機に搭載して使用されるように設計されたシステムは、オペレーション・テストを受ける必要があり、そのテスト中に、そのようなシステムを備える航空機が飛行すること、さらにはコマーシャル・サービスに供されることを許可される前に、上記システムは認可要件を満たすことが実証されなければならない。
【０００４】
インストール前に、これらのシステムは、とりわけ、認可機関によって設定された保全性および安全性要件を満たすことを検証するために、広範囲にわたるテストを受ける。具体的には、これらの搭載システムは、飛行に関する機能など、航空機にとって重要でありうる機能を実行するように設計された特別の計算機でよい。これらのシステムは、以下では、コンピュータと呼ばれる。
【０００５】
現在のシステムのアーキテクチャでは、各コンピュータは、フライト・コマンド用途など、同種類の１つまたは複数の用途専用であることが非常に多い。各コンピュータは、ハードウェア部分およびソフトウェア部分を含む。ハードウェア部分は、少なくとも１つの中央処理装置（ＣＰＵ）、およびコンピュータがコンピュータネットワーク、外部装置などにそれによって接続される少なくとも１つの入／出力構成要素を有する。
【０００６】
航空分野で実施されることが多い搭載システムの必須の特性は、そのようなシステム専用の機能を実行するいかなる不必要な手段をもできるだけ防止するアーキテクチャ、ハードウェアおよびソフトウェアの両方に関する。
【０００７】
したがって、広く普及している用途において一般に見られるシステムと違って、航空分野においては、コンピュータは複雑なオペレーティング・システムを備えていない。さらに、ソフトウェアは、中央処理装置によって理解される言語にできるだけ近い言語で作成され、利用可能な入力および出力は、航空機のセンサまたは他の部分からの情報、あるいはアクチュエータまたは他のアイテム用に設計された情報など、システムを動作させるのに必要なものだけである。
【０００８】
このタイプのアーキテクチャの利点は、そのようなシステムのオペレーションに対するそのずっと大きな制御である。このアーキテクチャは、システムのオペレーションのいくつかの態様が、制御されていないパラメータの関数であり、そうでなければアプリケーション・ソフトウェアと同じ安全性実証を必要とする複雑なオペレーティング・システムに依存しない。このシステムは、そのシステムに属する機能を実行するために絶対必要な手段を有するだけなので、より簡単であり、より脆弱でない。
【０００９】
その代わりに、そのようなシステムのオペレーションを観察することはずっと難しい。例えば、このシステムは、一連のオペレーションが適切に行われていることを検証すること、またはそのパフォーマンスと対話することを可能にするキーボードまたはスクリーンなどの従来のヒューマン−マシン・インターフェースを有せず、ソフトウェアの開発およびテスト中に必要なチェックを実行するのを難しくする。
【００１０】
コンピュータのソフトウェア部分は、考えられた用途に特有であり、システムがどのように動作するかを定義するアルゴリズムに対応する論理命令でコンピュータが動作することを保証するソフトウェアを含む。
【００１１】
システムがサービスに供される前に、および航空機がサービスに供される前に、システムが認可されるように、計算機はテスト・フェーズを受ける。
【００１２】
知られているやり方では、テスト・フェーズは一般に、コンピュータの処理の各ステップにおいて、上記計算機がシステムの予期されるオペレーションを満たすように設定された仕様とのコンプライアンスを検証することを必要とする。
【００１３】
とりわけソフトウェアでは、この仕様とのコンプライアンスは、ソフトウェアの最も簡単な構成要素を検証するステップから、すべての構成要素がターゲット・コンピュータに統合される完全なソフトウェアの統合ステップまでの連続ステップにおいて達成される。
【００１４】
第１のステップで、テストされうる最も簡単なソフトウェア要素が、ユニット・テストと呼ばれるテストを受ける。これらのテスト中に、個々に取り上げられたソフトウェア要素の論理命令またはコードが設計要件に従って完成されていることが検証される。
【００１５】
統合ステップと呼ばれる第２のステップで、それぞれ別々にテストされた様々なソフトウェア構成要素が統合され、ソフトウェア構成要素がそこで対話するアセンブリを形成する。これらの様々なソフトウェア構成要素は、ソフトウェア構成要素が特に上記構成要素間の機能的インターフェースにおいて適合性があることを検証するために、統合テストを受ける。
【００１６】
第３のステップで、ソフトウェア構成要素アセンブリは、ソフトウェア構成要素アセンブリがそれ用に設計されたコンピュータに統合される。次いで、コンピュータに統合された構成要素のセットによって形成されたソフトウェアが仕様に従っていること、すなわち予期された機能を実行し、そのオペレーションが安全で信頼できることを実証するために、妥当性検査テストが行われる。
【００１７】
ソフトウェアが安全であることを保証し、認可要件を満足するために、このテスト・フェーズ中に、ソフトウェアが受けるテストがすべて、適切なレベルの尤度で、ソフトウェアがそこに組み込まれているシステムのための安全性要件に従っていると結論を下すことを可能にすることを実証することも必要である。
【００１８】
テスト・フェーズ中にソフトウェアに対して行われる様々なテストは、（コンピュータの適切なオペレーションに、ならびにその結果として航空機およびその安全性に、影響を与える可能性がある）故障が上記ソフトウェアで生じる可能性があり、万一故障が生じた場合は、ソフトウェアはその故障を制御できることを保証できる。
【００１９】
しかし、テスト・フェーズ中には、および特に異常が検出されたときの調査オペレーションのためには、ソフトウェアがそこにインストールされるコンピュータの入力パラメータおよび出力パラメータが期待値を満たすことだけでなく、ソフトウェアの内部挙動の一部が正しいことをも保証することが必要な場合が多い。
【００２０】
この場合、搭載用途用のコンピュータに特有のアーキテクチャのせいで、通常、特別のデバイスおよび方法を実施することなくソフトウェアのオペレーションを観察することは、非常に難しい。
【００２１】
第１の知られている方法は、エミュレータを使用して、インストールされているソフトウェアと共にテストされるコンピュータと関連プラットフォームとの間にファイル配信システムをセットアップすることを必要とする。エミュレータを使用して、デバイスは、関連プラットフォーム上のコンピュータ・ユニット、コンピュータ・プロセッサの論理オペレーションをシミュレートすることができる。
【００２２】
エミュレータを必要とするそのようなオペレーティング・モードでは、コンピュータ・プロセッサは、プロセッサ・エミュレーションを有する関連プラットフォームとインターフェースするプローブに取り替えられる。
【００２３】
したがって、テストしているソフトウェアは、プロセッサを除外して、コンピュータ上で実行されること、および、関連プラットフォームの機能によって、入力／出力ユニットへのシミュレートされた入力に応答してなど、上記入力／出力ユニットの出力を観察して、ソフトウェアのオペレーション、その内部故障のいくつかを観察することが可能である。
【００２４】
この第１の方法は多くの不利な点を有する。実際に、テストされるべき各タイプのコンピュータは、特定のテスト・ベッド、または少なくともテスト・ベッドのための非常に特定の構成を必要とする。テスト・ベッドは、具体的には、テストされるコンピュータと対話するための手段と、コンピュータ・プロセッサ（１つまたは複数）をエミュレートするための手段と、テスト・プログラムを実行するための手段とを含むセットである。
【００２５】
各プロセッサは、エミュレーション・ソフトウェアのためにも、問題のためにも、プロセッサの代わりに働く特定のエミュレータを必要とするので、エミュレータは、コンピュータによって定義されているようにその数を増やされなければならない。
【００２６】
さらに、エミュレータを介して調査される可能性は、一般に、限定されている。さらに、所与のプロセッサに特有の機械語を用いて作業する必要があることは、開発者は機械プログラミングのエキスパートでなければならないことを意味する。
【００２７】
さらに、エミュレータは、通常、大量に生産されない高価な製品である。このタイプの製品のライフスパンは非常に短い（６カ月から２年）が、一方、開発およびテスト（規制、産業界の反応）のための手段は、航空機プログラムの持続期間の間（２０年以上）動作可能に保持されなければならない。これは、結果として、解決するのがますます難しくなる陳腐化関連の問題を生じる。
【００２８】
したがって、このエミュレータの解決策は、その限られた調査パフォーマンス以外に、インストールするのに費用がかかり、維持するのに費用がかかるので適切ではない。
【００２９】
コストはまた、安全設計として機能的冗長性を保証するために、通常、様々なプロセッサ・モデルが使用され、エミュレータ要件を増やすので、有害である。
【００３０】
エミュレータに関連する問題を克服することを意図された第２の方法は、テストされるプログラムを実行する際にコンピュータのオペレーションをシミュレートするためにホスト・プラットフォームを使用することを必要とする。この場合、テストされるソフトウェアは、テスト・ベクトルを読み出すためか、それともテスト結果を記録するために、ホスト・プラットフォーム・ファイルにアクセスしなければならない。
【００３１】
テストされるソフトウェアは、当然、ホスト・プラットフォーム・ファイル・システムにアクセスするための機能を含まないので、これらのアクセス機能を含めるために、テストされるソフトウェアを修正することが必要である。
【００３２】
情報を転送するために、一般に、シミュレートされたテスト環境によって出されるシステム・コール命令が使用される。システム・コール命令は、例えば、ファイルを開く、ファイルを書き込む、さらには、ファイルを読み出すようにとの命令でよい。システム・コール命令は、システム・コール命令をホスト・プラットフォーム上でシステム・コールに変換するホスト・プラットフォームのオペレーティング・システムによってインターセプトされる。
【００３３】
この第２の方法はまた、不利な点を有する。ファイルは非常に様々なので、アクセス機能を開発することはホスト・プラットフォームおよびそのオペレーティング・システムに高度に依存する。さらに、本方法を実施するときに実際の問題を引き起こす空間（開発チームが世界のあちこちに散在している場合）および時間（ホスト・プラットフォームの取替え）と同じだけ様々なホスト・プラットフォームがある。
【００３４】
これらの問題は、オペレーティング・システム機能を修正することができるエキスパートは、テストの専門家に委託することができないそのようなファイル・システム・アクセス機能を開発するために必要とされるスキルを有しなければならないことによっていっそうひどくなる。
【００３５】
その結果として、この方法は、高価で、実施するのが難しい。
【００３６】
さらに、この方法は、テストされるソフトウェアに関して高度に邪魔になり、テストのためにソフトウェアを修正することは、ソフトウェア自体のオペレーションを邪魔するリスクを引き起こす。
【００３７】
コンピュータ・テスト・フェーズ中に、またはテスト中に、オペレーション・ソフトウェアの実行の中断がありうる。この中断は、オペレーション・ソフトウェアのパフォーマンスの停止として、または、ソフトウェアがコード内の無限ループに入り込むことによって生じる。開発者は、その場合、コード内の異常またはエラーを調査して、それらを訂正しなければならない。この調査は、実行経路内の連続するセットポイントが、正常な実行に関して逆の順序で現れる実行によって行われる。言い換えれば、エラーを含む可能性があるコード・シーケンス（すなわち、１つまたは複数のエラーを含むすでに実行されたコード・シーケンス）が開始され、シーケンスが再実行される。この調査は、逆実行と呼ばれる。
【００３８】
この逆実行は、一連のコードの行から成るオペレーション・ソフトウェアの実行経路におけるどのポイントにおいても、開発者がコードの進行を理解することを必要とする。しかし、開発者は、エラーが実行経路内のどこにあるか分からない。したがって、開発者は、逆実行がコードの行をいくつ含まなければならないか分からない。さらに、搭載ソフトウェアでは、逆実行は正常な実行と同じ言語または機械語で行われなければならない。したがって、開発者が、コード・シーケンスを分離してエラーを見つけるために、オペレーション・ソフトウェア・プログラムのパフォーマンスを適切に理解することは難しい。さらに、エラーまたは異常を見つけるために、欠陥シーケンスにおいてどこまで行くべきかを開発者に示すために逆実行を制御またはモニタリングする方法はない。
【００３９】
その複雑さを考えれば、エラー探索は数時間から数日までのかなりの時間を必要とし、その結果として、生産性および労働の点から、デバッグ・フェーズのために比較的高いコストが生じる。
【００４０】
さらに、問題の逆実行を行うためには、まずプログラムの実行の状態に関する情報がキャプチャされ、返されなければならない。このキャプチャされた情報はすべて、後で再生成されるためにデータ・メモリに記憶される。しかし、プログラム実行経路は長い可能性がある。かなりの量のデータが扱われ、記憶されるので、メモリ・リソースの容量に関して問題が生じる可能性がある。
【００４１】
上記で概説された問題を解決するために、いくつかの解決策が開発されてきた。１つの解決策は、扱われるデータをすべて圧縮することである。この解決策は、圧縮率がランダムである（扱われるそれぞれ異なるデータに基づいて変わる）ので、非効率である。さらに、圧縮オペレーションの終了時の増大したメモリ空間は、データ圧縮の高いコストの割には比較的小さいようである。
【００４２】
第２の解決策は、厳密に必要なデータだけをキャプチャすることによりデータを低減することを必要とする。この第２の解決策で使用される方法は、コピー・オン・ライトと呼ばれる。この解決策は、情報のセットの定期的な検証に基づいて、修正されたデータ・ページだけをキャプチャするので、次に続く再生成のために最少量の情報を有することが可能になる。
【００４３】
第１の解決策と違って、このキャプチャのコストは最小である。しかし、行われる再生成は、元の実行状態の各再構成が、プログラムの開始からキャプチャされたチェックポイントすべてから設定されるので、特に対話式デバッグ中には比較的長い時間を必要とする。
【発明の概要】
【発明が解決しようとする課題】
【００４４】
本発明の目的は、前述の不利な点を改善することである。このために、本発明は、搭載オペレーション・ソフトウェアのデバッグ・フェーズ中に扱われる情報の量を処理するための方法を提供する。
【課題を解決するための手段】
【００４５】
本発明の方法は、搭載システムに帰することができるメモリ・リソースのニーズを低減し、最適化することができる。このために、本発明の方法は、オペレーション・ソフトウェアの実行経路を機能別インターバルに分割し、所与の場所でテストされるソフトウェアの実行の状態に関係する情報をキャプチャし、それに続いてこの情報を返すことを提案する。
【００４６】
より具体的には、本発明は、搭載システムのためのオペレーション・ソフトウェア・プログラムのデバッグ・フェーズ中に扱われる情報の量を処理するための方法であって、
ａ）進行ポイントをプログラムの各機能に配置することにより上記オペレーション・ソフトウェアの実行経路を機能別インターバルに分割するステップと、
ｂ）各進行ポイントに関連するチェックポイントを配置するステップと、
ｃ）プログラムの正常な実行ステップであって、
−  各進行ポイントの場所におけるプログラムの実行状態の記憶と、
−  上記進行ポイントのための前に記憶された実行状態の除去を生じさせることになる実行状態の記憶と、
−  エラーの検出直後に、
−−  欠陥機能に対応する進行ポイントを探索するステップ、
−−  ソフトウェア開始実行状態を探索するステップ、
−−  開始実行状態を再生成するステップ、
−−  欠陥機能内のエラーを訂正するステップ、
−−  プログラムを再実行するステップ
を含む、プログラムの正常な実行ステップと
を備えることを特徴とする方法に関する。
【００４７】
本発明はまた、
−  単一の実行状態がデータ・メモリに一度に記憶される特徴、
−  ある機能の正常な実行後に、その機能に対応する進行ポイントが非アクティブ状態からアクティブ状態に変わる特徴、
−  欠陥機能の探索は、最後のアクティブ進行ポイントを探索することから成る特徴、
−  進行ポイントの状態を有する進行ポイントのリストが記憶される特徴
のうちの１つまたは複数を有してよい。
【００４８】
本発明はまた、航空機搭載のコンピュータのオペレーションをシミュレートするデバイスであって、上記で定義された方法を実施することを特徴とするデバイスに関する。
【００４９】
このデバイスは、プログラムの実行状態を記憶することができるデータ・メモリを含んでよい。
【００５０】
本発明はまた、プログラムがユニット上にロードされ、実行されるときに、前述の方法を実施するためにコード・シーケンスと共に制御ユニット上にロードされる、搭載航空機システム用のオペレーション・ソフトウェア・プログラムに関する。
【００５１】
本発明は、以下の説明を読み、添付の図面の図を研究することにより、よりよく理解されることになる。それらの図は、例示のために提示されるものであり、本発明を限定するものではない。
【図面の簡単な説明】
【００５２】
【図１】本発明における方法の機能図である。
【図２ａ−２ｂ】本発明の方法がそこで実施されるデバイスの概略図である。
【発明を実施するための形態】
【００５３】
オペレーション・ソフトウェアは、プログラムのセットから成る。プログラムは、以下では命令ストリングと呼ばれる、書かれた命令シーケンスのセットから成る。これらの命令ストリングは、それらの発生順に、すなわち、第１の命令から最後の命令まで、正常に実行される。発生順に実行されるこれらの命令ストリングは、プログラムの正常な実行経路を形成する。
【００５４】
プログラムを効果的にデバッグするために、すなわち、エラー、設計欠陥、およびプログラムの動作の仕方の異常を見つけて訂正するために、本発明の方法は、エラーまたは異常がどこにあるかをタグに基づいて判定することができるように、プログラムの実行経路にタグを配置することを提案する。タグは、プログラム内の特定の場所として配置される仮想マーカである。これらの場所は、例えば、プログラム内の様々な機能の開始または終了に対応する。機能は、全体として特定のオペレーションを行う命令のシーケンスである。プログラムの機能は、次々に実行される。タグは、例えば、プログラム内の機能の中の各入口ポイントおよび各出口ポイントに配置される。タグが各プログラム機能の入力および出力に配置されると、タグは、プログラムを通る機能パスを形成するように言われる。
【００５５】
各タグは、進行ポイントおよびチェックポイントを有する。
【００５６】
進行ポイントは、プログラム内の特定の場所に配置されうる仮想マーカである。プログラム内の進行ポイントのための場所は、タグに関して前に説明された場所である。進行ポイントは、プログラムが実行されるときの参照ポイントである。理解できるように、進行ポイントは、次に、（１つまたは複数の異常あるいはエラーに遭遇したときに）逆実行中のプログラムの進行の中断時に配置される、プログラムの中の実行経路の進行内にチェックポイントを形成する。プログラムの実行経路に沿ってこれらの進行ポイントを定期的に配信することは、遭遇したエラーまたは異常を探索することをより容易で、より迅速にする。この配信は、機能的でよく、進行ポイントは、プログラムの実行経路を隣接する機能別インターバルに分割する。
【００５７】
各タグの制御経路は、プログラム実行中に使用される様々なデータがそこに記録されるメモリのイメージに対応する状態ベクトルである。チェックポイントは、タグが配置されているプログラムの場所である所与の場所におけるプログラムの実行状態を示し、これはチェックポイントからの情報を有するメモリを後で再初期化することを可能にする。各進行ポイントに関連するチェックポイントがある。チェックポイントは、２つの一時的に連続したタグ間でのプログラムの実行によって参照される情報すべてから成る。したがって、このセットは、プログラムが２つのタグ間で再実行されるために必要とされ、かつ十分である最小のセットである。
【００５８】
各進行ポイントは、２つの状態、すなわち、アクティブ状態および非アクティブ状態を有しうる。その状態（アクティブまたは非アクティブ）以外に、進行ポイントは、プログラムが進行ポイントのアドレスまで実行されたときに行うべき処理を識別する情報と共に、関連するプログラム・アドレスを含む。プログラムの開始時には、進行ポイントはすべて非アクティブである。進行ポイントに対応するチェックポイントはすべてニュートラルである、すなわち、いかなる情報をも含まない。
【００５９】
機能が正常に実行されるたびに、機能の終了時にまたは次の機能の開始時に配置された進行ポイントは、アクティブ状態に変わる。次いで、この進行ポイントに関連するチェックポイントは、進行ポイントの場所におけるプログラムの実行状態をキャプチャまたは記憶する。
【００６０】
プログラムの正常な実行中に、（機能の終了時に、または次の機能の開始時に）正常に実行された機能の後に配置された進行ポイントは、非アクティブ状態からアクティブ状態に変わる。進行ポイントがアクティブ状態に変わると、プログラムの実行状態は、この進行ポイントに対応するチェックポイントによってキャプチャされる。言い換えれば、プログラムの所与の場所におけるプログラムの実行ポイントは、データ・メモリに記憶される。
【００６１】
本発明によれば、同じ実行状態がデータ・メモリに同時に記憶されるように、プログラムの様々な実行状態が単一のデータ・メモリに次々に連続して保存される。記憶されている実行状態は、最後にキャプチャされた実行状態であり、これは最後のアクティブ進行ポイントの場所におけるプログラムの実行状態である。本発明では、この最後の実行状態の保存だけが、逆実行時に、プログラムの実行状態を後で再生成するために必要とされると考えられる。一実施形態では、実行状態をキャプチャすることは、前の実行状態の記録を削除する。他の実施形態では、記録された各実行状態の後に、前に保存された実行状態が削除され、その結果、データ・メモリは、１つの実行状態だけ、すなわち、逆実行中にプログラムをステップスルーために使用される実行状態だけを含む。
【００６２】
エラーが生じると、開発者は、プログラムの中の上記エラーを見つけるためにプログラムの逆実行を行う。この逆実行は、そのチェックポイントがプログラムの状態に関する情報をキャプチャした最後の機能である、最後のアクティブ進行ポイントに対応する機能内のコードの第１の行においてプログラムの実行をステップスルーするために、プログラムの正常な進行とは逆にプログラムを実行させることを可能にする。
【００６３】
進行ポイントのリストは、これらのポイントそれぞれにおける状態と共に記憶される。したがって、プログラムの実行が中断されると、最後のアクティブ進行ポイントが見つけられ、プログラムの場所がこの進行ポイントに対してセットされる。次いで、保存されている実行状態がないかデータ・メモリを探索し、保存されている実行状態に関するデータを使用して、その場所からプログラムを再実行する。
【００６４】
したがって、本発明によれば、プログラムの命令ストリングをステップスルーし、欠陥命令ストリングの場所を識別するために、進行ポイントをたどることにより逆実行が実行される。したがって、逆実行は、単一の機能別インターバルの中で実行されうる。この機能別インターバルで欠陥ストリングまたはエラーが検出されると、開発者は、ストリング内のエラーまたは異常を調査し、次いで、それを訂正する。
【００６５】
チェックポイントを使用して、プログラムは、最後のアクティブ進行ポイントの場所から再実行されうる。プログラムをステップスルーすることは、開始実行状態が取り出されることを必要とする。本発明によれば、この取出しおよび実行状態は、メモリ空間として、実行状態に対応する場所だけを必要とする。さらに、進行ポイントとチェックポイントとの間のリンクは、開始実行状態を迅速に取り出すことを可能にする。
【００６６】
図１は、本発明における方法の例示的機能図である。この方法は、デバッグ・フェーズを初期化するための準備ステップ３１を含む。このステップは、デバッグ・フェーズの適切なパフォーマンスにおいて使用される様々なパラメータを再初期化する。
【００６７】
ステップ３２で、オペレーション・ソフトウェア・プログラムの実行経路において、均一、かつ適切な分割が行われる。この分割は、プログラムの実行経路におけるいかなるインターバルにも関連するオペレーション・コンテキストを識別することを可能にする。
【００６８】
ステップ３３で、上記実行経路を機能別インターバルに分割するために、プログラムの実行経路に沿った進行ポイントが配信される。各進行ポイントは、チェックポイントに関連する。チェックポイントおよび進行ポイントはすべてタグを形成する。各進行ポイントは、パッシブな役割を有し、プログラムの実行時にステップ・ポイントを示すインジケータにすぎない。チェックポイントは、アクティブな役割を有する、すなわち、２つの異なる状態（アクティブまたは非アクティブ）を有しうる。チェックポイントの役割は、プログラム内の特定の場所で、指定された時間に、実行状態情報をキャプチャすることである。
【００６９】
ステップ３４で、プログラムは正常に実行する。ステップ３５として、テスト・ループがプログラムに適用される。このステップ３５で、進行ポイント上で通過が検出される。プログラム実行中に進行ポイント上の通過が検出された場合、すなわち、進行ポイントが横切られた場合、ステップ３６が適用される。そうでなければ、ステップ３４が繰り返される。
【００７０】
ステップ３６で、プログラムの実行状態が所与の場所でキャプチャされる。このキャプチャされたプログラム実行状態は、ステップ３７で記憶される。
【００７１】
ステップ３８は、プログラム内のエラーを検出するためのステップである。プログラム内にエラーが検出された場合は、ステップ３９が適用される。そうでなければ、ステップ４０が適用される。
【００７２】
ステップ３９で、プログラムの実行は停止する。次いで、ステップ４１で、プログラムの開始実行状態が判定される。この開始実行状態は、ステップ３７中にデータ・メモリに記録された最後の実行状態である。
【００７３】
ステップ４２で、エラーなしで実行された最後の機能の終了時のプログラムの実行状態である開始実行状態が再生成される。開始実行状態の再生成は、実行経路のために機能別インターバルのコンテキストを返すことを可能にする。
【００７４】
ステップ４３で、逆実行が実行され、プログラムは最後のアクティブ進行ポイントから再実行され、アクティブ進行ポイントに関連するチェックポイントによってキャプチャされたものを実行状態と考える。
【００７５】
ステップ４４で、欠陥ストリングをステップスルーし、次いでプログラム内のエラーを訂正するために、欠陥機能内の根本原因が調査される。
【００７６】
ステップ４５で、デバッグ・フェーズが終了したことが検証される。デバッグ・フェーズが終了した場合は、プログラムは、その全体において実行されうる（ステップ４６）。そうでなければ、ステップ３４に戻り、ステップ３４から４５を再実行する。
【００７７】
プログラムにエラーがないときには（ステップ３８）、ステップ４０が適用される。ステップ４０で、開発者が機能別インターバルにおけるジャンプを対話式に要求したかどうかが判定される。機能別インターバルにおけるジャンプが要求された場合、ステップ４１およびそれに続くステップが適用される。そうでなければ、ステップ３４が再度適用され、プログラムの実行を継続することを可能にする。本発明では、プログラムを通過することは自動的に行われうる、すなわち、開発者は単一の機能の中に追加のタグを配置することを選択する。これらの追加のタグは、入口タグ、出口タグ、および／または中間タグでよい。対話式に通過するか自動的に通過するかに関する選択は、開発者自身によって行われる。対話式に通過することは、探索インターバルを改善しエラーを訂正することを可能にし、これは上記インターバルを低減することができ、したがって、エラーを検出することをより容易にする。
【００７８】
上記から、本発明における方法は、チェックポイントおよび進行ポイントを介してキャプチャされ、次いで取り出されるデータは、単一の実行状態に対応するデータだけなので、知られている方法に比べて少量の情報を使用してデバッグすることを可能にすることが理解される。プログラムは、少量の実行状態情報を有する。さらに、そのような再生成のコストは、再生成されるべきプログラムの開始実行状態の位置、またはデータ・メモリ４のサイズに依存しない。
【００７９】
図２ａは、航空機搭載のオペレーション・ソフトウェア用のテスト環境のためのコマンド・ユニット１の一例を示す。諸実施形態によれば、テスト環境は、事実上、ホスト・プラットフォーム上でシミュレートされてもよく、それともエミュレータ・ハードウェアに基づいてシミュレートされてもよい。
【００８０】
コマンド・ユニット１は、プロセッサ２、プログラム・メモリ３、データ・メモリ４、および入／出力インターフェース５を含むが、それらに限定されない。プロセッサ２、プログラム・メモリ３、データ・メモリ４、および入／出力インターフェース５は、双方向通信バス６によって相互に接続される。
【００８１】
図２ａでは、デバッグ・フェーズ中のオペレーション・ソフトウェア７が概略的に示されている。プログラム７は、実行経路８を含む。実行経路８は、命令コードの行のセットを有する。実行経路８は、機能別インターバルを形成するために、均一、かつ適切に分割される。したがって、デバッグ・フェーズ中、プログラム７は、プロセッサ２、プログラム・メモリ３、およびデータ・メモリ４と絶えず接続されている。
【００８２】
ゾーン９で、プログラム・メモリ３は、プログラム７にタグを付けるための命令を含む。プログラム７にタグを付けることは、進行ポイント１０を実行経路８に沿ってセットすることを可能にする。各進行ポイント１０は、機能別インターバルに関連する。プログラム７にタグを付けることはまた、チェックポイント１１、１２、１３、１４、および１５をそれぞれの進行ポイント１０に関してセットすることができる。ゾーン２１で、プログラム・メモリ３は、プログラム７を実行するための命令を含む。プログラム実行７は、命令ごとに実行経路８をステップスルーする。プログラム７の実行経路をステップスルーすることは、進行ポイント１０に沿っての動きの妥当性を検査する。進行ポイントを順次横切ることは、チェックポイント１１、１２、１３、１４、および１５をアクティブ化する。ゾーン２２で、プログラム・メモリ３は、プログラム７についての開始実行状態に関する情報をキャプチャするための命令を含む。チェックポイント１１、１２、１３、１４、および１５を順次アクティブ化することは、プログラム７の開始実行状態をキャプチャする。ゾーン２３で、プログラム・メモリ３は、プログラム７のための開始実行状態に関する情報を記憶するようにとの命令を含む。この情報は、データ・メモリ４に記憶される。ゾーン２４において、プログラム・メモリ３は、記憶されている実行状態に関する情報を取り出すための命令を含む。図２ｂには、データ・メモリ４に関するさらなる詳細が示されている。
【符号の説明】
【００８３】
１  コマンド・ユニット；  ２  プロセッサ２；  ３  プログラム・メモリ；  
４  データ・メモリ；  ５  入／出力インターフェース；  ６  双方向通信バス；  
７  プログラム；  １１、１２、１３、１４、１５  チェックポイント。
【図１】
2010539577.tif 000003
【図２】
2010539577.tif 000004
【国際調査報告】
2010539577.tif 000005
2010539577.tif 000006
2010539577.tif 000007
2010539577.tif 000008
2010539577.tif 000009
2010539577.tif 000010