JP2010539576A - 航空機搭載システムのオペレーション・ソフトウェアの妥当性をテストするための自動スクリプト生成の方法および同方法を実施するためのデバイス - Google Patents

Abstract

本発明は、航空機搭載システムのオペレーション・ソフトウェアの妥当性をテストするためのスクリプト生成の方法であって、以下のステップ、すなわち、
ａ）入口点および停止点をそれぞれ、テストされるオペレーション・ソフトウェアの機能の先頭および末尾に位置付けることにより、開発者が対話式に妥当なテスト・ケースを識別するステップ（２０）と、
ｂ）停止点および入口点の位置を介して前記機能の変数の状態を観察および記録するステップ（２２）と、
ｃ）第１に、テスト・ケースの識別中に観察される変数の状態を分析することにより、および第２に、テスト・スクリプトをソース・コード（１３）の形で生成することにより、テスト・スクリプトを自動的に生成するステップ（２６）と、
ｄ）生成されたテスト・スクリプトのテストをテスト実行環境で自動的に実行するステップ（３０）と
を含むことを特徴とする方法に関する。

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これを達成するために、コンピュータのオペレーション・ソフトウェア用のテスト実行環境がいくつかのテスト・プログラムを生成する。ただし、そのテスト・プログラムは、多くの場合、相当な量の命令コードを表し、その量は、テストされるソフトウェアの命令コードの量より重大であることも多い。

現在、テスト・プログラムの開発は、テスト・ケースごとに行われている。テスト・ケースとは、テストの目的に達するために実施されるオペレーション・パスを指す。すなわち、テスト・ケースは、実施されるテスト、実行されるテスト・シナリオ、および期待される結果のセットによって定義される。したがって、コンピュータへのロード用のオペレーション・ソフトウェアのための各テスト・ケースは、そのテスト・ケースをシミュレートするプログラムに関連付けられる。これらのテスト・プログラムは開発者によって作成され、開発者は、テストされるソフトウェアの機能、機能のコンテキスト、および機能の実行条件を完全に理解している。テスト・プログラムの開発は、次の２つの基本的ステップを経る。すなわち、テスト・データの設計に関する第１のステップおよびテスト・プログラム用の命令チェーンを書くことに関する第２のステップである。

テスト・プログラムの開発は、開発者によって行われる反復的連鎖の手作業にさらされる。この反復的連鎖の手作業は、エラー導入の重大発生源である。

この問題を解決するために、テスト・ケース・データの生成を可能にするように自動テスト生成プログラムが開発された。テスト・ケース・データを生成するそのような方法では、開発者は各テストの目的を形式言語で表し、次にこれらの目的をプログラミング言語に変換しなければならない。このようにしてモデル化された各目的がテスト・ケースを構成する。

しかし、各テストの目的のこのような表し方は、単純な機能の単純な目的に適用できるだけで、各目的のこのような表し方を自動化することは、産業規模で実施するのは困難である。

本発明の目的は、前述された手法の欠点を克服することである。これを達成するために、本発明は、テスト・プログラムの自動的な生成、および実行されるテストの妥当性のチェックを可能にする方法に関する。

本発明による方法を実施すると、テスト・プログラムの開発を手作業に頼る必要がなくなるので、テスト・フェーズのコストが軽減される。本発明は、実行されるテストに基づいた開発に応じて増分式にオペレーション・ソフトウェアの開発が行われるので、テスト・プログラムの開発に関して、このように柔軟性のレベルを可能にする。実際には、テスト・プログラムはオペレーション・ソフトウェア・テストと並行して開発されるが、そのことは、少なくとも１つのテストに基づいた開発が行われるたびに、オペレーション・ソフトウェアがテストされるのと同時にテスト・プログラムが開発される。

本発明は、これらのテスト・プログラムの統合がアンロールされたスクリプトから自動的に行われ、開発者によって対話式に検証されるので、テスト・プログラムの信頼性が改善されることも可能にしている。

より厳密には、本発明は、航空機搭載システムのオペレーション・ソフトウェアの妥当性をテストするためのスクリプト生成の方法であって、以下のステップ、すなわち、
−入口点および停止点をそれぞれ、テストされるオペレーション・ソフトウェアの機能の先頭および末尾に位置付けることにより、開発者が対話式に妥当なテスト・ケースを識別するステップと、
−停止点および入口点の位置を介して前記機能の変数の状態を観察および記録するステップと、
−第１に、テスト・ケースの識別中に観察される変数の状態を分析することにより、および第２に、テスト・スクリプトをソース・コードの形で生成することにより、テスト・スクリプトを自動的に生成するステップと、
−生成されたテスト・スクリプトのテストを実行環境で自動的に実行するステップと
を含むことを特徴とする方法に関する。

本発明は、以下の特性の１つまたは複数を有することもできる。
−変数の状態を観察および記録するステップと、テスト・スクリプトを自動的に生成するステップとの間で、テスト・ケースの妥当性をチェックする検証ステップが実行され、開発者はテストされる機能の実行が、観察される変数の状態に関して妥当であるかを決定できる。
−テスト・スクリプトの生成はテスト・ケースごとに行われる。
−自動的にスクリプトを生成するステップと、自動的にスクリプトを実行するステップとの間で、テスト・スクリプトのソース・コードを機械言語の同等のソース・コードに自動的に変換するために前記ソース・コードのコンパイルが作成される。
−コンパイルの後にテスト・スクリプト行編集オペレーションが行われ、開発者によって選択されたテスト実行環境で実行および使用できる２進数コードが生成される。
−選択されたテスト実行環境のタイプにそのまま適合する形でテスト結果が生成される。

本発明は、航空機搭載コンピュータのオペレーションをシミュレートするデバイスにも関し、そのデバイスは、前に定義された方法を実施するという特徴がある。

本発明は、以下の特性も有する。

デバイスは、事実上、テストおよびデバグ用ホスト・プラットフォーム上でシミュレートされる。

本発明は、制御ユニットにロードできて、制御ユニットにロードされ、実行されると、前に定義された方法を実施する命令シーケンスを含むテスト・プログラムにも関する。

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

本発明の方法のオペレーション図である。 オペレーション・ソフトウェア用のテスト・プログラムが生成できるようにした、テスト実行環境の制御ユニットの概略図である。

本発明は、開発フェーズ全体にわたって、オペレーション・ソフトウェアをテストするためのスクリプトの自動生成を可能にした方法に関する。この方法は、開発中にオペレーション・ソフトウェアに行われた各変更が考慮できるようになっている。

オペレーション・ソフトウェアの概念は、プログラムのセットを含むと定義される。記述された一連の命令のセットを含むプログラムは、これ以降、命令チェーンと称する。スクリプトは、特定のタスクを実行する、記述された命令のセットである。

また、本発明の方法は、一連のステップによって、開発の進展に合わせてオペレーション・ソフトウェアに実行される各テストの妥当性を制御することもできる。

図１は、本発明の方法のオペレーション図を表す。このオペレーション図は、本発明の実施形態の１つのモードに対応する。このオペレーション図は、テスト・ケースが開発者によって対話式に識別されるステップ２０を含む。テスト・ケースの概念は、本明細書では、すでにデバッグされたオペレーション・ソフトウェアの命令チェーンが正しくその仕様を満たしているだけでなく、機内搭載システムのコンピュータによるその実行が前記システムのいかなる誤動作も引き起こさないことをチェックするために開発者によって定義されるシナリオである。本発明の範囲内で、開発者は、オペレーション・ソフトウェアをできるだけ多く働かせるためにいくつかのテスト・ケースを定義することができる。この開発者は、入手可能なデバッガを使用し、それにより、その開発者は、特に命令チェーン内で、起こり得るエラーを調査することができる。また、このデバッガは、入口点および出口点または停止点をそれぞれ、テストされるオペレーション・ソフトウェアの機能の先頭および末尾に位置付けることにより、テストの実行が制御されるようにすることもできる。テスト実行制御は、特に、開発者によって選択された、重要な変数として知られる変数の状態を観察するステップを含む。これらの重要な変数とは、開発者が、得られた値は期待された値であることをチェックできるようにする変数である。

ステップ２１でテストの妥当性の検証が行われ、観察された変数の状態について、テストの実行が妥当であるかどうかの決定ができる。そのテストが妥当である場合には、ステップ２２は、観察された変数の状態のすべてを保存することにより妥当なテストを記録するために、開発者に妥当性検証インターフェースを提供する。テストが妥当でない場合には、その方法はステップ２０から繰り返される。

妥当なテストを記録するためのステップ２２が適用されると、ステップ２３で、開発者のアクションおよび決定に基づいて新しいテスト・ケースの検証が行われる。新しいテスト・ケースが検出されると、その方法はステップ２０から繰り返される。新しいテスト・ケースが検出されない場合、テスト・スクリプトを生成するためのステップ２６が適用される。このステップ２６は、前に２つの中間ステップ２４および２５が先行する。ステップ２４の目的は、テスト実行環境のパラメータがその開発者によって設定されたかを検出することである。これらのパラメータは、テスト実行環境のタイプが選択できるようにし、それに合ったテスト・スクリプトが生成されなければならない。パラメータが検出されると、ステップ２５は、テスト・スクリプトを生成するためにこれらのパラメータを考慮に入れることで行われる。

テスト・スクリプトを生成するためのステップ２６は、スクリプト生成プログラムによって自動的に実行される。このスクリプト生成プログラムは、第１に、変数の制御された状態を分析し、その状態が、妥当なテスト・ケースを識別するステップ２０の後で記録され、第２にテスト・スクリプト用のソース・コードを生成する（ステップ２７）。

ソース・コードを生成するこのオペレーションは、テスト・ケースごとに実行される。ソース・コードは、通常のプログラミング言語でそのまま提示され、そのため、ソース・コードは、ソフトウェア開発者の大多数によって理解されやすい。

ステップ２８で、ソース・コードのコンパイルが作成され、テスト・スクリプト用のソース・コードが機械言語の同等のスクリプトに自動的に変換できるようになる。このコンパイルの後にテスト・スクリプト行編集オペレーションが行われ、ステップ２９で、ステップ２４で選択されたテスト実行環境、または事前に構成されたテスト実行環境で実行および使用できる２進数コードが生成される。

ステップ３０で、テスト・スクリプトの２進数コードがテスト実行環境で自動的に実行される。ステップ３１で、オペレーション・ソフトウェアに実行されたテストの実行からの結果が、開発者によって選択されたテスト実行環境のタイプにそのまま適合する形式で生成される。

本方法は、オペレーション・ソフトウェアのテスト実行環境の任意のタイプに適合できる利点がある。したがって、本方法は、仮想または実環境の任意のタイプに適合させることができる。

本発明の方法では、生成されたテスト・スクリプトはそのままで妥当であり、エラーは免除されている。実際には、テスト・スクリプトの妥当性検証フェーズ中、前記スクリプトの１つに妥当性検証が行われないと、そのことは１つのエラーの発見に対応し、そのため、暗黙で、オペレーション・ソフトウェアのテストされた機能の訂正が行われる。

図２は、テスト実行環境の制御ユニット１の概略図であって、機内搭載システム（図示せず）へのロード用のオペレーション・ソフトウェアのテスト・スクリプトが生成できることを示している。図２は、テスト実行環境の制御ユニット１の例を示している。テスト実行環境は、実施形態の様々なモードにより、実質的には、ワークステーションなどのホスト・プラットフォーム上で、または１つのエミュレータ・タイプのハードウェア機器に基づいてシミュレートされる。テスト実行環境とは、機内搭載システムのオペレーション・ソフトウェアのチェック、訂正およびテスト、ならびにオペレーションのバーンインの実行が可能な環境を指す。テスト環境の制御ユニット１は、網羅的ではないが、プロセッサ２、プログラム・メモリ３、データ・メモリ４および入出力インターフェース５を備えている。プロセッサ２、プログラム・メモリ３、データ・メモリ４および入出力インターフェース５は相互に双方向通信バス６を介して接続されている。

プロセッサ２は、制御ユニット１のプログラム・メモリ３に記録された命令コードによって制御される。

プログラム・メモリ３は、エリア７に、妥当なテスト・ケースを識別するための命令を有する。この識別により、従来のデバッガで使われている多機能インターフェースを介した開発者の対話が可能になる。これらの機能の中には、特に、実行制御点を、テストされるオペレーション・ソフトウェアの機能の先頭に位置付けることができる機能がある。別の機能では、停止点を機能の末尾に位置付けることができる。この開発者の対話により、開発者は、その機能の実行が正しく行われたかを判定するために変数の状態を制御することができる。

プログラム・メモリ３は、エリア８に、妥当性検証オペレーションを行うための命令を有する。この妥当性検証は、変数の制御された状態のすべてを自動的に記録することで行われる。これらの状態は、妥当なテスト・ケースの記録１２を構成する。また、この妥当性検証により、制御された状態のすべてが編集できるようになる。これらの制御された状態が、妥当性検証が行われたテスト・ケースの参照値になる。

プログラム・メモリ３は、エリア９に、テスト・スクリプトを生成するための命令を有する。このテスト・スクリプトの生成は、記録１２の変数の状態を分析した結果として行われる。このテスト・スクリプトの生成は、ソース・コード１３の形で提示される。それは、テスト・ケースごとに提示される。

プログラム・メモリ３は、エリア１０に、機械言語に変換するためのソース・コード１３のコンパイルを作成するための命令を有する。このコンパイルの後、ソース・コード１３（機械言語で書かれている）を実行可能な２進数コード１４に変換するために行編集オペレーションが行われる。

プログラム・メモリ３は、エリア１１に、出力にテスト結果１５を生成するためのテスト・スクリプトを実行するための命令を有する。

１ 制御ユニット； ３ プログラム・メモリ； ４ データ・メモリ；
５ 入出力インターフェース； ６ 双方向通信バス； １２ 記録；
１３ ソース・コード； １４ ２進数コード１４； １５ 結果。

Claims (9)

1. 航空機搭載システムのオペレーション・ソフトウェアの妥当性をテストするためのスクリプト生成の方法であって、以下のステップ、すなわち、
   ａ）入口点および停止点をそれぞれ、テストされる前記オペレーション・ソフトウェアの機能の先頭および末尾に位置付けることにより、開発者が対話式に妥当なテスト・ケースを識別するステップ（２０）と、
   ｂ）前記停止点および前記入口点の位置を介して前記機能の変数の状態を観察および記録するステップ（２２）と、
   ｃ）第１に、前記テスト・ケースの前記識別中に観察される前記変数の状態を分析することにより、および第２に、テスト・スクリプトをソース・コード（１３）の形で生成することにより、テスト・スクリプトを自動的に生成するステップ（２６）と、
   ｄ）前記生成されたテスト・スクリプトのテストをテスト実行環境で自動的に実行するステップ（３０）と
   を含むことを特徴とする方法。
2. 前記変数の状態を前記観察および記録するステップと、テスト・スクリプトを前記自動的に生成するステップとの間で、前記テスト・ケースの妥当性をチェックする検証ステップが実行され、前記開発者はテストされる機能の実行が、観察される前記変数の状態に関して妥当であるかを決定できることを特徴とする、請求項１に記載の方法。
3. 前記テスト・スクリプトの前記生成がテスト・ケースごとに行われることを特徴とする、請求項１および２のいずれか一項に記載の方法。
4. 前記自動的にスクリプトを生成するステップと、前記自動的にスクリプトを実行するステップとの間で、前記テスト・スクリプトのソース・コードを機械言語の同等のソース・コードに自動的に変換するために前記ソース・コードのコンパイルが作成されることを特徴とする、請求項１から３のいずれか一項に記載の方法。
5. 前記コンパイルの後にテスト・スクリプト行編集オペレーションが行われ、前記開発者によって選択されたテスト実行環境で実行および使用できる２進数コードが生成されることを特徴とする、請求項４に記載の方法。
6. 前記選択されたテスト実行環境のタイプにそのまま適合する形でテスト結果が生成されることを特徴とする、請求項１から５のいずれか一項に記載の方法。
7. 請求項１から６のいずれか一項に記載の方法を実施することを特徴とする、航空機搭載コンピュータのオペレーションをシミュレートするデバイス。
8. 事実上、テストおよびデバグ用ホスト・プラットフォーム上でシミュレートされることを特徴とする、請求項７に記載のデバイス。
9. 制御ユニット１にロードできて、前記制御ユニットにロードされ、実行されると、請求項１から６のいずれか一項に記載の方法を実施する命令シーケンスを含むテスト・プログラム。

Images