【第8回】単体検査

制御プログラムの開発は、製品や開発規模にもよりますが、開発検討段階（新規制御アルゴリズム開発）、製品開発段階（仕様開発）、量産段階（搭載設計）に大別されます。

MBDの場合、テストの自動化や効率化について語られる事が多いですが、単体検査自体に要する工数はそれなりに大きく、開発の全ての段階において同じように実施されるわけではありません。各段階でECUやプラントのアーキテクチャが異なる場合がありますので、開発段階に応じた評価が必要となります。

開発検討段階では、モデリングとシミュレーションを繰り返し、動作を検証しながらモデリングしますので、できあがった制御モデルのアルゴリズムに問題がある場合は少ないと考えられます。

ただし、開発中のシミュレーションでは限られた条件下での簡易的な評価しかできませんので、実際の製品に搭載した場合と類似した環境を準備して、期待する効果や機能を評価する必要があります。

最も信頼性の高い評価は、製品相当の試作ECUに実装して試作機に装着して試験を行うことですが、これには相当の費用と工数が必用となります。

モデルを使ったシミュレーションで評価検討ができれば良いのですが、試作機や試作ECUがなければ精度の良いモデルをつくることができませんので、MBDであっても企画・構想段階では試作が必用となります。

開発する製品に比較的近い機種を改造して、試作機や試作ECUとして対応することが可能であれば、以下の方法で評価することができます。

ECUやプラントの製作品手配には時間、コストがかかるうえ、制御用マイコンの性能や機能に合わせたモデルの修正、モデルを搭載するBSWの開発などを行う必用がありますので、開発者にとっては大きな負担となりますので、製品化の段階で改めて再設計、評価することを前提として、実装評価を簡略化して製品開発段階に移行することも可能と思われます。

開発検討段階では、搭載するマイコンのメモリ容量や機能拡張を行っている場合や、特定のマイコンやECUで使用することを前提としない場合もあります。

このため、新規の制御モジュールを採用する際には、実際に搭載する製品のアーキテクチャに合わせて、設計を見直す必要がありますが、試作機や評価用ECUは入手困難な場合があります。

多くの場合は差分開発と思われますので、類似機種をベースとしたシミュレーションによる設計環境（仮想評価環境）を作ります。制御性能の評価や制御定数の決定などはできませんが、制御ロジックを評価・検証することができます。シミュレーションだけでなく、テスト・評価ツールも同時に作成しておけば、テストシナリオ注1※や判断基準の再利用ができますので、作業の大幅な効率化が可能です。

制御ロジックが固まれば、搭載するマイコンの命令コードレベルでの動作検証を行い、実機での適合を経て制御定数を確定し、制御仕様モデルおよび制御仕様書を作成します。製品仕様書は、量産段階における製品検査の判断基準となりますので、この段階で信頼性の高いモデルとして完成させることが重要です。

仕様モデルだけで量産モデルを作ることもできますが、制御の意図や検査結果の良否判断がつかない場合もありますので、制御仕様書として完成度の高いものが必用となります。

製品開発のプロセスの組み方によって、開発プロセスと量産プロセスが明確に区分できない場合もありますが、ここでは制御仕様書に基づき、量産製品に組込む制御プログラムの単体検査について説明します。

MBDでは、ソースコードを自動生成するツール（ACG:Auto Code Generation）やテストベクターを自動的に生成するツール（ATG:Auto Test Generation）を活用します。

概念的には次のような流れになります。

1. 仕様モデルから実装モデルに変換
2. ACGによりC言語ソースコードを作成
3. ATGによりテストベクターを生成
4. Back-to-Backテスト注2※の実施
5. MC/DCカバレッジ注3※を計測

具体的な作業内容については、使用する各ツールについての解説を参照してください。

一般的には、C言語のソースレベルでSILによるシミュレーションを用いて実施されます。機能安全規格では命令コードによる検証が求められますので、sPILSを用いて命令コードレベルでカバレッジテストすることができるツールとして、カバレッジマスターwinAMS注4※があります。

量産段階では、ハードウェアに微修正がある場合や他のモジュールの変更による影響がある場合、開発段階では、想定できなかった問題が生じることもあります。

ゼロ割やオーバーフローの発生などの問題点を形式的手法で検証するツールもありますが、こうしたカバレッジや形式的手法だけではカバーできない、潜在的な問題を検出するためのテストシナリオをできる限り準備しておく必要があります。

複数回の実行ではじめて異常と判定できるような場合や、積分誤差の積み重ねで制御が不安定になるような場合などは、単純に実行条件や入力値の変更だけのシミュレーションでは発見できません。このような不具合を発見するには、BSWに搭載してプラントモデルと接続したシミュレータ（MILE/SILS/HILS）を活用した動的な検査が必要となります。

単体検査とは言えないかもしれませんが、プロセスとしては制御モジュールの単体評価の範疇と考えます。

この段階で発見される不具合は仕様変更を必要とする場合があり、大幅な手戻りになりそうですが、シミュレーションの条件変更や実行回数、計測タイミングなどの検査手順や判定方法をテストシナリオとして自動化しておけば、仕様からの修正が必要となった場合にも短時間で再検査することができます。

最終的に信頼性を旦保できたモジュールは、再利用できるようテストシナリオと紐付けてデータベース化しておけば、他機種での流用や市場評価後の改善の際に活用することができます。

シミュレーションを使えば自動化が比較的容易にできますので、テストケースが増加しても工数負担は少なくてすみます。

MBDでは、モデル化技術やACG/ATGについて注目されることが多いですが、信頼性と生産性の高いプロセスや環境を構築することが重要です。

注1※ テストシナリオ : システムが問題なく動作することを確認するためのテスト手順
注2※ Back-to-Backテスト : 対象とするソフトウェアを旧バージョンや開発段階のソフトウェアと動作比較をすること。
ここでは、仕様モデル（実装モデル）と自動生成したソースコードを同一条件で実行した結果が同等であることを検証すること。
注3※ MC/DCカバレッジ : Modified Condition/Decision Coverage（改良条件判断網羅）プログラムの分岐と実行結果を網羅的にテストする手法のひとつ
注4※ カバレッジマスターwinAMS : ガイオ・テクノロジー社製の単体テストツール。同ツールのMBTオプション機能を用いてBack to Backテストを効率的に実施することができる。