Simulink Tester Issues

From T-VEC Wiki (Japanese)

このセクションは、潜在的な制限、問題や、SimulinkやStateflowを使ってT-VECを使用するためのガイダンスに関して記載しています。

Contents 1 ガイダンス 1.1 T-VECベクタ生成の失敗 1.2 S-Functions 2 制限 2.1 シミュレーション用テストドライバ：状態値の初期化 3 課題 3.1 インラインやカバレッジ 3.2 テストベクタ生成の失敗 3.3 シグナルレンジ管理 3.4 モデルカバレッジ対コードカバレッジ 3.5 テストシーケンスベクタ状態変数初期化 3.6 テストドライバ生成 3.7 マッピング情報付きでトランスレートする場合の、状況による違い 3.8 無効となった信号名などの影響

ガイダンス

T-VECベクタ生成の失敗

テストベクタの失敗が発生すれば、モデル（TTM/Simulink）に適用する一般的なガイドラインがあります。 VGS Issues and Guidelines を参照して下さい。

S-Functions

S-Functionsにより、ユーザがMATLAB、C、C++、AdaやFortranを含む様々なプログラミング言語を通して、シミュレーションやコード生成のために新しいブロックの意味を指定することができます。S-Functionを参照するサブシステムのために、このブロックの意味は、テスト生成をサポートするのに必要ですが、これらの意味は、標準的なアプローチでは、トランスレータによってアクセスすることはできません。

S-Functionの変換をサポートするために、トランスレータは、S-Functionに代わるSimulinkサブシステムの置換を必要とします。S-Functionに代わるサブシステムは、プリミティブなSimulinkブロックとして、S-Functionの機能を記述します。S-Functionの代わりにされるSimulinkサブシステムは、S-Functionブロックのコメントに特別なタグを入れることで指定されます。

S-Function代用タグを設定する方法は、Simulink Testerユーザーズガイドに示されています。

制限

シミュレーション用テストドライバ：状態値の初期化

T-VECは、ユニットディレイのようなフィードバックを実現するための、状態値を含むテストベクタを生成します。これは結果的に状態値ですが、現状、状態値をセット（初期化）するための制御メカニズムが、Matlabシミュレータにありません。

課題

インラインやカバレッジ

Simulinkのインライン・サブシステムの使用は、テストやモデルカバレッジに影響を与えます。モデルがインラインされたサブシステムを含むならば、そのようなデザインに準じて、ユーティリティ（下位層のサブシステム）を介して一つのパスを取得しない、カバレッジの不足が起こり得るでしょう。

これは、design models と requirements models の典型的な対比です。例えば、デザインには、全てのアプリで必要とはならない、再利用可能/汎用なコンポーネントを含んでいます。

例として、：サブシステムXは、2つのパスで入力Aを持つユーティリティ。

A >= 0 then do something

A < 0 then do something

ここでサブシステムYは、サブシステムXをインラインし、信号Aに関する入力が >=0の時のみ、サブシステムXを参照します。そのため、A<0の時のパスに、モデルまたはテストカバレッジが存在しない。

唯一の解決法は、それらが独立してテストされるように、単独のアトミックファンクションとみなされるようにすることです。

テストベクタ生成の失敗

T-VEC VGS の解析は、システムの階層を渡って、全DCP をモデルチェックし、テストベクタを生成することから、網羅的であるといえます。テストベクタ生成に失敗する殆どの原因は、DCP上のコンストレインツが、サブシステムのDCPの階層を介して、満足されないというようなモデルの欠陥です。

しかしながら、テストベクタを生成することができるはずなのに、失敗するケースがあります。例えば、信号の範囲がデフォルトのままである場合。入出力範囲のデフォルト設定 default settings for ranges values がありますが、これらはアプリケーションによっては、適切でない場合があります。

T-VECは、標準ブロック（サポートブロックは、Simulink Tester GUIから、ViewのLibraryで参照）を高い比率でカバーしますが、T-VECがベクタを生成できないケースがあります。例えば、

• 動的配列の領域確保（dynamic array indexing）
• 一定の不連続動作（繰り返し変数に関わるような）

Auto Rotate Convergence Fix Mode Test Vector Generation設定は、これらの問題に対処することができるメカニズムの一つです。また、特定の収束モードに依存することなく、他の内部メカニズムは、自動的に適用されます。 T-VECテスト生成アルゴリズムは、これらの状況に対処するための進化を続けています。しかし、そのような状況が発生しないという保証はありません。何らかの問題があれば、support@t-vec.com にご連絡下さい。

シグナルレンジ管理

アーキテクチャの変更（システムの分解など）により、信号名が削除されるようなことがあります。例えば、サブシステムx\y\zの階層的な範囲で信号Aが定義されている場合に、サブシステムyが削除されると、その信号は未定義となり、シグナルレンジファイル（.srf）から削除されます。

トランスレータは、実行される毎に、シグナルレンジファイル（.srf）のバックアップコピーを作成しています。また、.srfファイルへの変更毎に詳細をログファイルに残します。そのため.srfファイルに予期しない変更があった場合でも、元に戻すことが可能です。

モデルカバレッジ対コードカバレッジ

テストベクタ生成は、モデル内全てのパス（DCPs）に対して、テストベクタを見つけようとします。ここでカバレッジは、model coverageを意味し、このモデルカバレッジは、コードのカバレッジ（例：MC/DCカバレッジ）を保証するものではありません。例えば、コード生成ツールにより、例外状態をチェックし処理するためのコードを付け加えられることが有り得ます（例：safety code around square root function）。 Simulink Testerは、アサーションや、追加のカバレッジ設定のメカニズムを提供し、このような状況をカバーする追加のテスト生成をサポートしています。また、Simulink TesterにLDRA社 TBrunツールを統合することで、coverage measures が提供され、FAAの認証用のエビデンス作成をサポートします。

テストシーケンスベクタ状態変数初期化

シーケンシャルなテストベクタ（Test Sequence Vectors(TSVs)）は、ターゲットサブシステムを複数回参照して生成します。これは、トランスレータに提供される設定を基にして、特別なT-VECサブシステムを生成することで、実現しています。これらTSV用のサブシステムは、1つ以上のテストシーケンスを含みます。各テストシーケンスは、ターゲットサブシステムへの、1つ以上の参照を含みます（例：テストされるサンプル回数など）。また、ターゲットサブシステムが参照されるごとの、ターゲットサブシステムの入力も含まれます。これらの入力値の名前には、それぞれのサブシステムへの参照が付加されます。 そえゆえ、もしサブシステムが2つの入力（inputAとinputB）を持つなら、2つの参照を含むTSVサブシステムは、それぞれ入力inputA_1, inputB_1と, inputA_2 and inputB_2となります。各サブシステムへの参照の入力値は、参照レベル、テストシーケンスレベル、サブシステムレベルでの設定を通して制御されます。

Simulinkの多くのブロックは、特定の状態初期値、ユニットディレイ、integrator、などを持っています（ステートマシンの初期状態を持つstateflowなども）。 T-VECは、ベクタ生成中にこれらの初期値を使用するメカニズムを持っています。

• T=0 - システムが最初の実行サイクルである時のテストベクタを生成（状態初期値を用いる）
• T>=0 - 状態初期値、および初期値以外のサイクルでテストベクタ生成を設定
• T>0 - 初期状態を無視し、初期化や割り当てなどではなく、収束を通して解決される状態値
• Ignore - 無視（状態変数を持たないブロックなど）

デフォルトでは、状態変数がない場合は2つのベクタ、状態変数ある場合は4つのテストベクタの、両方のケースで、ベクタを生成します。 この仕組みにより、状態変数に関わる制御やロジックのテストが適切に行われます（State Variable Inits Example）。

テストドライバ生成

テストドライバー生成用の、オブジェクトマッピング情報の、シグナル名と実装コード上の名前の関連付けを手動で行う必要が起こり得ます。これは、いくつかのSimulinkブロックタイプや、あるStateflowモデリング構造に当てはまります。単に、変数名、関数の引数順序などを予測できないケース。 RTWの動作・選択から、テストドライバマップファイルを完全に自動生成することの出来る、APIはありません。

現在のスキーマには、全てのマッピング記述子は、Perlを通してターゲットファイルに受け渡されます。 Perlスクリプトは、新しい交換用マップ情報を含む、外部ファイルを解析します。 マッピングは、記述子またはマッピングキーで定義されます。 もしperlスクリプトが一致を見つけると、ファイルをもとに置き換えを行います。 この機能は、perlスクリプトを通して直接拡張されます。

マッピング情報付きでトランスレートする場合の、状況による違い

ディフォルトでは、サブシステムに対するファンクションネームオプションは”Auto”です。ＲＴＷがこれらファンクションネームを引出す処理は、sl2tvec にはわかりません。結果、単にモデルファイルのみが変換されるのであれば、ファンクションネームを推測する必要があります。しかしＲＴＷマッピングファイルと合わせてモデルを変換するのであれば、トランスレータはマッピングからファンクションネームを特定できるようになります。リユーザブル・サブシステムの場合、その定義は同じファンクションネームで処理される場合のみ共有できるでしょう。リユーザブル・サブシステムは、それぞれに異なって用いられるので、マッピングファイルとあわせてモデルを変換すると、異なった数のリユーザブル・サブシステム、異なる名前のリユーザブル・サブシステムを得ることになってしまうでしょう。

無効となった信号名などの影響

トランスレータ実行時に、モデル上の信号ラベルを用います。これらラベルは伝播の影響が加味され、変わってしまうことがあるでしょう。信号のラベルが変更されたり、ライブラリの移動など。ラベルが無効になってしまったら、トランスレータは正しく実行されずに、以下のようなエラーを発行します:

Determining signal dimensions..ERROR SL0086:

Signal dimensions are not consistent for block "Bus_Selector" in subsystem "example" (block expects an input labeled signal2, but could not find it in the input signal)

WidthIndex 1, BusLabel signal1, Output signal2

WidthIndex 2, BusLabel signal3, Output signal2

ERROR SL0115: signal dimension is invalid for signal "signal2" from block "Bus_Selector" <dimension: 0>

..Done.

Translation Aborted!

このようなエラーを避けるには、モデルをエクスポートする前に、Edit | Update Diagramのメニュー実行や、Ctrl + D をしてアップデートしましょう。