必数百万ものシナリオをどのようにして作成するか？
テスト数の爆発的増大を避けるには？
テストの合格・不合格をどのように見分けるか？
必数百万ものシナリオをどのようにして作成するか？
テスト数の爆発的増大を避けるには？
テストの合格・不合格をどのように見分けるか？
Processor-in-the-Loopテスト
Processor-in-the-Loop（PIL）とは、テストしたいコードをターゲットのコンパイラでコンパイルし、ターゲットプロセッサ上で実行することです。しかし、なぜこのようなことをするのでしょうか。手書きコードで開発しているか、Matlab/Simulinkのようなモデルベース環境で開発しているかに関わらず、ほとんどの場合、ホストPC上の理想的な環境で実行するSoftware-in-the-Loop（SIL）を行っているはずです。ホストPCは通常、ターゲットプロセッサよりも遥かに高性能なCPUを搭載しておりますが、ターゲットプロセッサと異なるコンパイラを使用します。
ここで以下のような疑問が生じます。
ターゲットコンパイラがソフトウェアの振舞いに与える影響はどのように確認すれば良いでしょうか？（特に浮動小数点コードの取扱いに関して）
開発初期段階において実行時間やスタックサイズのようなターゲット上での実行に関する側面をどのように分析すれば良いのでしょうか？
ISO 26262に準拠するように可能な限りターゲットに近いテストを行うにはどのように実現すれば良いでしょうか？
このようなターゲットに依存する課題を、Hardware-in-the-Loop（HIL）シミュレータを使ったシステムレベルのテストで行うのは効率的ではありません。
課題を早期に発見するにはソフトウェアを小さな対象（ユニットなど）に分けてターゲットで個別にコンパイルし、Processor-in-the-Loop（PIL）シミュレーションを行います。
これは、評価ボードをホストPCに接続（USBなど）し、PCがボード上でのテスト実行を制御することにより実現されます。PILでは正しい機能の振舞いを確認できるだけでなく、テスト対象の関数がターゲットのCPUで十分な速度で実行され、CPUが負荷を処理できることも確認できます。
BTC EmbeddedPlatformは、PILを実行するための多様なオプションを提供します。
dSPACE TargetLinkモデルの場合は、TargetLinkのメカニズムを用いてProcessor-in-the-Loop（PIL）シミュレーションを直接実行できます。BTC EmbeddedPlatformは、利用可能なコンパイラとターゲットボードを自動的に検出し、Model-in-the-Loop（MIL）およびSoftware-in-the-Loop（SIL）に加えて、追加のシミュレーション環境として利用できます。TargetLinkは、評価ボードとマイコンの多くの組み合わせをサポートしています。サポートされる組み合わせは、以下のサイトで確認できます。 www.dspace.com.
TargetLinkユーザではない場合でもBTC EmbeddedPlatformはProcessor-in-the-loop（PIL）を行えるようにiSYSTEM winIDEAやLauterbach Trace32を統合するアドオン拡張機能を提供しています。
組み込みソフトウェア開発、モデルベースデザイン、自動コード生成、ISO26262準拠のテストに関する情報の公開
短い動画で当社製品の主な機能をご覧ください。
完全に自動化されたBack-to-Backテスト、Regressionテスト、Migrationテスト(自動テスト生成を含む)
Copyright © 2022 BTC Embedded Systems & BTC Japan
