Back-to-back Test パッケージ

BTC EmbeddedPlatformのBack-to-back Test パッケージは、入力ベクタの自動生成(時系列の入力値の作成)も含め、モデルとコード間のBack-to-back Testを完全に自動化します。

Back-to-back Test パッケージ

BTC EmbeddedPlatformのBack-to-back Test パッケージは、ソフトウェアモデル及びコード間でのBack-to-back テストを自動化するための製品です。従来では大きな工数が必要とされていた入力ベクタの生成(時系列の入力値の作成)も含め、BTC EmbeddedPlatformではBack-to-backテストに必要な全ての工程の自動化が実現されています。

ユーザ様からは、手動で行っていた従来のテストと比べて70%以上の工数を削減できたとご評価いただいております。

Back-to-back Testパッケージ

サポートするユースケース

* Requirements-based Testパッケージの機能はすべて含まれます。

追加可能なアドオン

 

Back-to-backテスト

モデルベース開発では、ソフトウェアは機能モデルから実装モデルへの作り込み、モデルからのCコード自動生成、 ターゲットコンパイラによるコンパイルとリンクといった過程を経て実装用のオブジェクトコードへと変換されていきます。機能モデルに続く成果物では、機能モデルの振る舞いを正として、同じ振る舞いをすることが求められます。この確認を行うためのテスト手法がBack-to-backテストです。

Back-to-backテストでは、比較対象のモデル及びコードの入力インタフェース群に対し、全く同じ時系列の入力値(入力ベクタ)を与えてシミュレーションが実行されます。モデル及びコードの振る舞いが同じであるとすれば、同じ入力を用いたシミュレーション対し、全く同じ出力が期待されます。そこでBack-to-backテストでは、出力インタフェースにおける出力値を比較することで振る舞いの一致・不一致が評価されます。

 

Back-to-backテストの自動化

Back-to-backテストには、大量の入力ベクタ群の作成、各種カバレッジの作成、比較対象毎の異なるシミュレーションフレームの作成、異なるデータタイプやスケーリングで記録された出力値の比較など、手動では膨大な工数を要し、また正確に行うことが困難な作業が伴います。BTC EmbeddedPlatformはこれら全ての工程を自動化しました。

 

 さらにスクリプトを用いれば、大量のモデルとコードを連続比較する、Back-to-backテストの完全な自動化も可能です。完全に自動化されたテストは昼夜を問わず連続実行されますので、エンジニアの方々の貴重な工数はテスト結果のレビューとテスト不合格が検出された場合のデバッグに集中することが可能です。自動化の手段は、MATLABスクリプト、及びJenkinsへの統合(アドオンTest Automation & Migration Suiteをご参照ください)に対応しています。

 

Back-to-backテストの比較対象

機能モデル (Simulinkモデル/TargetLinkモデル)

ソフトウェア機能モデルのモデリング及びシミュレーションにはMathworks社のSimulinkが広く活用されています。機能モデルは、Simulinkの標準のブロックセットまたはこれに追加されたdSPACE TargetLinkのブロックセットで構成されます。

そして構築された機能モデルは、Model-in-the-loop(MIL)シミュレーションと呼ばれるSimulinkのモデルシミュレーション機能を用いて、その振る舞いが要求通りであることが十分にテスト・検証されます。(機能モデルに対するテスト・検証をご希望の方は、Formal TestパッケージFormal VerificationパッケージRequirements-basedテストパッケージをご覧ください。)

十分にテスト・検証されたモデルは、"実行可能な仕様書"とも呼ばれており、この後の工程におけるリファレンスとして活用されます。Back-to-backテストでは、機能モデルのシミュレーション結果を正として、他のモデル及びコードのシミュレーション結果と比較されます。

実装モデル (Simulinkモデル/TargetLinkモデル)

機能モデルに対し、実装用のデータタイプやスケーリング、クラスやストレージといった情報が追加され、必要に応じて一部のブロックを実装用に差し替えたものが実装モデルです。実装モデルは一般的に自動コード生成機能を持つツールを用いて作成されます。自動コード生成用のツールとして代表的な製品はdSPACE社のTargetLink、Mathworks社のEmbedded Coderです。

実装モデルのテスト・検証には、機能モデルのときと同じくModel-in-the-loop(MIL)シミュレーションと呼ばれるSimulinkのモデルシミュレーション機能が用いられます。

Back-to-backテストでは、機能モデルと振る舞いが一致することが求められます。

ソースコード (Cコード)

実装用のソースコード(Cコード)はdSPACE社のTargetLink、Mathworks社のEmbedded Coderといった自動コード生成ツールによって自動的に生成されます。近年ではターゲットに依存しないANSI-C準拠のCコードが用いられるため、Visual StudioやMinGWといった汎用コンパイラによるSoftware-in-the-loop(SIL)シミュレーションがテスト・検証に用いられています。SILシミュレーションは追加の特別なデバイスを必要とせず汎用PC上で実行できること、Back-to-backテスト不合格となる大部分の原因を検出できること、またSimulink、Visual StudioなどのIDEの強力なデバッグ機能を活用できることから、Back-to-backテストでは特に重宝されています。

Back-to-backテストでは、機能モデル(及び/もしくは実装モデル)と振る舞いが一致することが求められます。

注) BTC EmbeddedPlatformのSILシミュレーションは、MATLAB/Simulinkで設定されたmexコンパイラ、Visual Studio、及びMinGWに対応しています。

オブジェクトコード

最後にターゲットコンパイラを用いてコードのコンパイル・リンクを行い、ターゲットプロセッサ上で実行可能なオブジェクトコードを得ます。オブジェクトコードのテスト・検証には、ターゲットプロセッサを搭載した評価ボード上でシミュレーションを行うProcessor-in-the-loop(PIL)シミュレーションが用いられます。PILシミュレーションではターゲット特有の仕様や最終的に利用するコンパイラオプションも含めた評価が可能です。特に浮動小数点実装においてはターゲット依存の振る舞いに注意する必要があるため、PILシミュレーションは重要な役割を担います。

Back-to-backテストでは、機能モデル(及び/もしくは実装モデル、ソースコード)と振る舞いが一致することが求められます。

注) BTC EmbeddedPlatformのPILシミュレーションは、dSPACE社の製品である各種評価ボードに対応しています。dSPACE社の評価ボードは様々なターゲットコンパイラとプロセッサに対応しており、TargetLinkと連携してPILシミュレーションを実施することができます。

 

Back-to-backテストとカバレッジ

Back-to-backテストによって十分なテストが行われたか(検証の完全性は十分か、テスト目的を適切に達成したか)は、モデルカバレッジ及びコードの構造カバレッジを通して評価されます。

最も代表的な構造カバレッジはModified Condition/Decision カバレッジ(MC/DC)です。他にも、Statementカバレッジ、Branch(Decision)カバレッジ、Functionカバレッジ、Callカバレッジなどが広く活用されています。BTC EmbeddedPlatformではこれらのカバレッジを自動測定し、レポートします。

BTC EmbeddedPlatformでは一般的な構造カバレッジの他に、ゼロ割、ダウンキャスト(オーバフロー/アンダーフロー)を評価するための追加のカバレッジゴールに対応しています。これらのカバレッジゴールはISO26262等の標準規格で直接求められているものではありませんが、実用において広く活用されている検査基準です。

Back-to-backテストで用いられる入力ベクタ群は、これらのカバレッジを十分に高めるものを準備する必要があります。

BTC EmbeddedPlatformでサポートされたカバレッジゴール一覧

アドオンModel Block Testを用いると、モデルのブロックの種類毎にユーザ定義のカバレッジを追加できます。

 

カバレッジ100%到達も可能な入力ベクタの自動生成

 入力ベクタの生成は従来のBack-to-backテストにおいて最も手間のかかる作業の一つです。前述の各種カバレッジが十分に高くなるよう、大量の入力ベクタを作成しなければなりません。多くの実践的なテストにおいて、図のような入力ベクタを数十~数百準備する必要があります。さらに、コードの構造によっては複雑な入力値を伴う数百ステップの実行の後にしか到達できない条件もあるかも知れません。これらを考慮しながら人の手によって入力ベクタを作成することは大変困難かつ根気の要る作業でした。

BTC EmbeddedPlatformではこの作業を自動化することで、より高いカバレッジの入力ベクタを自動で得られるようになりました。もはや入力ベクタの生成に経験や知識、労力はほとんど必要とされません。

 

到達不可能の証明によるより高いカバレッジ

コードにはデッドコードなどを要因として到達不可能な箇所や条件が存在することがあります。この到達不可能の証明を人の目によって行うことは知識・経験と大きな労力を要するため非常に困難とされています。

BTC EmbeddedPlatformの入力ベクタ自動生成は、コードを解析してカバレッジの高いベクタを生成するだけでなく、同時にカバレッジが上げられない箇所を検出、到達不可能であることを証明します。

図のコードカバレッジレポートにおいてオレンジ色で表示されている箇所が到達不可能が証明されたStatement、DecisionまたはConditionです。

この機能により、コードカバレッジ100% (到達不可能が証明された箇所を含む)か、それに非常に近いカバレッジでのBack-to-backテストを実現しています。 

 

浮動小数点実装対応

BTC EmbeddedPlatformのBack-to-backテストは、浮動小数点実装のコードにも対応しています。特別な操作は要りません。

しかし浮動小数点実装では非正規化数、Inf /-Inf、NaN、Flush-to-Zero、各種環境依存の最適化処理、振る舞いが標準規格 (IEEE 754 / IEC 60559、及びISO/IEC 9899)で定義されていないダウンキャストなど、開発及びテスト時に注意すべき点が多数あります。これらを適切に取り扱わなければ、解析が困難な誤差を大量に発生させたり、潜在する誤差を見落とす結果に繋がります。当社はこれらの注意点に対し、十分な知見を以て製品の開発及びサポートを行っております。浮動小数点実装でのBack-to-backテストをお考えのお客様は、評価を開始なさる際にBTC Japanサポートへお伝えください。ただツールの操作方法をお伝えするだけでなく、注意点を踏まえてサポート致します。

 

AUTOSAR対応

BTC EmbeddedPlatformのBack-to-backテストは、TargetLink及びEmbedded Coderによって生成されたAUTOSAR (AUTomotive Open System ARchitecture) 準拠のコードにも対応しています。特別な操作は要りません。

AUTOSAR準拠で実装されたコードに対し、適切なテストフレームを自動的に追加してBack-to-backテストを実施します。

 

リソース利用量の記録

BTC EmbeddedPlatformのBack-to-backテストでは、PILシミュレーションの実行中にリソースの利用量を評価することができます。シミュレーション中の毎ステップの実行時間、及びスタックの利用量が記録されます。 従来ではBack-to-backテストとは別に評価を行う必要のあったリソース利用量の評価を同時に行うことが可能です。ソフトウェアを統合し、ECUに搭載した際にリソース不足が検出された場合でも、これらの記録をもとに比較的負荷の高いコンポーネントを即座に特定することが可能です。

 

各種機能安全規格準拠

BTC EmbeddedPlatformのBack-to-backテストは、各種機能安全規格の最新版に準拠し、 ドイツTÜV Süd社による認証を受けています。

 

自動コード生成を利用していてもBack-to-backテストは必要?

はい、自動コード生成を利用していてもBack-to-backテストは必要とされます。実装モデルを作成する際に、ユーザによってデータタイプやスケーリング、クラスやストレージに誤った設定が与えられれば、そこから生成されるコードはモデルとは全く異なる振る舞いをすることがあります。また、実装用に差し替えたブロックが不適切であったり、実装の一部に手書きのコードやライブラリを用いた場合も、それを原因として振る舞いに誤差を生じる可能性があります。

 

図はスケーリングの設定が不適切であった際に誤差が生じた例です。他にもオーバーフローが原因で誤差が発生する場合や、複数のブロック間や外部コードとの間で同一の変数を利用して値が不適切に上書きされてしまう場合、コードでのゼロ割防止処理が原因で誤差が生じる場合など、様々な原因で誤差は生じます。これはツールの不具合ではなく、ユーザによる設定を原因として発生する誤差です。

 

浮動小数点実装でもBack-to-backテストは必要? 

はい、浮動小数点で実装していてもBack-to-backテストは必要とされます。モデルもコードも浮動小数点で、自動コード生成を用いれば振る舞いは常に一致するとお考えになる方もいらっしゃるかも知れません。しかし前述の自動コード生成を利用している場合にもBack-to-backテストが必要な理由でご紹介した誤差の要因のいくつかは浮動小数点実装でも有効です。

さらに浮動小数点実装では、コンパイラオプションの設定やターゲット依存の実装により、全く同じコードであったとしてもターゲットによって異なる振る舞いをする可能性があるため、より注意を要する部分があります。

 

図では、モデルとコードでタイプキャストが2例ずつ行われています。どちらも同じsingle floatの値を同じint32にキャストしており、一見違いは分かりづらいものです。しかしご覧の通りシミュレーションした結果の値は全く異なります。機能モデルと実装モデルの間ではこのような違いが生じるかも知れません。また、コード側でも二つの例は異なるシミュレーション結果となっています。さらにこれらのうち片方の値は、モデルの2例のどちらの値とも全く異なる値を取っています。実装モデルとソースコード、ソースコードとオブジェクトコードの間でもこういった誤差は生じ得ます。これはツールの不具合ではなく、浮動小数点の特性です。

 

Back-to-backテストに要求は必要? 

どのようなテスト・検証でも要求を考慮するに越したことはありませんが、Back-to-backテストに限っては必須ではありません。

もし要求に基づいて事前に設計モデルに対してRequirements-basedテストFormal Testによるテスト・検証を実施していた場合は、そこで利用したテストケースを入力ベクタとしてBack-to-backテストに再利用することが可能です。これでカバレッジが不足する分だけ、自動ベクタ生成で入力ベクタを追加することも可能です。

要求に基づいて生成されたテストケースはテスト対象ソフトウェアの重要な振る舞いや注意すべきコーナーケースを反映するため、同じカバレッジだったとしてもより良い質のテストを期待できます。 Requirements-basedテストFormal TestをBTC EmbeddedPlatform上で実施していた場合、テストケースの再利用は自動で行われますので、特別な操作は必要とされません。