テスト時間の短縮で製品開発ライフサイクルを加速する: V字モデルのナビゲーション

エレクトロメカニカルシステムは、エネルギーを機械的動作へ、またその逆へと変換します。センサやその他システムからの入力を使用して、機械、作動、および物理コンポーネントを制御する専用ソフトウェアを実行する制御エレクトロニクス (例: 電子制御ユニット) や組込コントローラ (例: ライン交換可能ユニット) を備えています。車両の推進のほか、航空機、地上車両、船舶の様々な機能を提供します。  

図1. 車両カテゴリと共通するエレクトロメカニカルシステムのタイプ

このようなシステムの機能、動作方法、設計要件は大きく異なることもありますが、エレクトロメカニカル車両システムの開発とテストは、同一の一般的なワークフローに従って行います。システムエンジニアは、車両のシステム、サブシステム、およびコンポーネントで満たすべき要件と車両全体の設計を行います。こういった各要件に対してそれぞれ個別のチームが、仕様に沿って適切な制御エレクトロニクス、ソフトウェア、機械コンポーネントを開発します。各チームは独自の開発プロセス (通常、アジャイルなど組織固有のニーズに応じた一般的な開発手法) に従って、エレクトロメカニカル車両システムにおける担当部分の設計と妥当性確認を行います。その後、段階的に反復を繰り返してシステムを構築、統合、テストした上で、完成車を生産します。

図2. エレクトロメカニカルシステムの一般的な製品開発プロセス

要件から設計、妥当性確認にいたるまでの進行プロセスは様々な方法で示されますが、その1つがV字モデル (図3) です。V字モデルは、混乱や数々の解釈があるものの、汎用テストアーキテクチャのメリットを検証し、設計プロセス全体のテストニーズに対応するための便利なフレームワークです。

図3. 開発プロセスと関連するテストタイプを表すV字モデルの手法

通常、V字の左側では、設計の意思決定の各段階における、上位の要件から下位の仕様に向かって詳細を示します。ここでの決定は、開発中のシステムの種類に応じて、様々なコンピュータ支援エンジニアリング (CAE) ツールを含むモデルベースの設計アプローチを使用することが多くなっています。このトピックについては、デジタル変革とデジタルツインに関する資料を参照してください。V字の一番下の部分では、システムは最下位レベルのコンポーネントに分解されており、設計は実装に変換可能で、コンポーネントの試作をすぐに作成できる状態です (ソフトウェアを実行する試作にコードを実装済みであるため、V字の下の部分は「実装」と呼ばれることがあります)。V字の右側では、これらを統合したものを示します。ベースレベルのコンポーネントから車両レベルまで各統合段階において、動作が仕様に沿っているか検証し、性能が要件に合致しているか妥当性確認を行います。

注: システム、サブシステム、およびコンポーネントの詳細が提供されると、図2に示すように、ソフトウェア、電子コンポーネント、および機械コンポーネントの開発が並行して進みます。必要な領域の専門知識を有する設計チームとテストチームが別々に開発プロセスを実施します。

注: 「検証」および「妥当性確認」という用語は無差別に使用されており、「V&V」という包括的な用語が使用されることもあります。一般的に、検証では「正しく構築しているか」ということを問います。そして一連の仕様と比較して、システムが予想通り (許容誤差、または範囲内で) 動作することを確認します。これに対して妥当性確認では、「正しいものを構築しているか」ということを問います。 完成したシステムで目的とするタスクを実行し、測定されたパフォーマンスが一連の要件に対して許容範囲であることを確認します。

以下のテストに関する簡単な説明と定義は、ほぼ製品設計プロセスで実施する順番通りですが、実際には非常に反復的に行われます。設計Vを通じて迅速かつ効率的に設計を進め、反復型の設計ができるということは、競争上の優位性をもたらすものであり、優れたテスト組織にとって重要な能力でもあります。V字モデルが批判されるのは、そのプロセスがウォーターフォール型の開発手法と同じように連続的であるためです。

MILテストでは、コントローラとプラントの両方をソフトウェアでモデル化します。このタイプのテストは設計プロセスの早期段階で行い、ソフトウェアシミュレーション環境でコントローラの戦略とシステム動作をテストします。

SILテストではプラントをモデル化して、選択した開発言語で記述、実行し開発システム (場合によっては仮想マシン) でコンパイル、実行した実際の制御コードにそのモデルを接続します。

PILテストはSILテストと似ていますが、デプロイされたシステムで使用する特定のプロセッサアーキテクチャやOS向けに、制御コードが記述、コンパイルされています。たとえば、特定の設定を行ったFPGAでコードを実行している場合、そのシナリオのコードをコンパイルして、実際の処理アーキテクチャで適切な機能を確保し、十分な空きリソースを保証します。特にECU (電子制御ユニット) で設計最適化を行う際にソフトウェアや機能の制限、トレードオフが必要になる場合、デプロイされた処理アーキテクチャやハードウェアを実装するのは複雑で時間のかかるプロセスであるため、このテストは独立したステップとなっています。

RCPは、実際のI/Oで実際のプラントに接続された、リアルタイムコントローラないしFPGAで動作する数学モデルを使って、制御スキームをすばやく反復するために使用されます。

HILは、実際の組込コントローラ上で、周辺の物理コンポーネントやシミュレーションされたセンサを使用するソフトウェアテストです。そのためECUは、信号調整、実際の負荷レベル、および欠陥生成機能を使って、実際の電気的なI/Oを実行します。

物理テストアプリケーションでは、トランスデューサベースの計測 (温度、圧力、ストレス/歪み、音、加速度、変位など) を使用して、テスト対象のコンポーネントまたはシステムの物理特性をテストします。アプリケーションサンプルとして、マイクロホンと加速度計からの音響/振動の計測を含む、ノイズ/振動/ハーシュネス (NVH) テストなどがあります。別のサンプルとして、予想される様々な作動条件下でDUTがどのように動作するかを決定することに重点を置いた、耐久性テスト/ライフサイクルテスト (高加速寿命試験 (HALT)、高加速ストレススクリーン (HASS)) もあります。

1. V字モデルの右側で、統合テストの隣接するレベルを表しています。通常、統合テストでは主に2種類のシステムを使用します。
   システムレベルテストで使用する単一の (サブ) システムへの、各種コンポーネントの統合をテストする場合は、テストリグを使用します。テストリグは、様々なベースレベルのコンポーネントを機能システムに統合するため、あらゆるテストを処理するのに非常に適しています。機能システムを用いることで、テストの設定と実行が容易になります。
2. システム統合ラボすなわち「Iron Bird」は、車両レベルのテスト用に複数のサブシステムを統合しており、実際の車両レイアウトやシステムの接続状況と近似しています。これは、システムオブシステムズのテストやシステム間の通信/対話/境界条件テストで使用されます。テストケースによっては、テスト用のインフラストラクチャからこのような規模を除外することによってのみカバーできるものもあります。試作車を作成し、実際のフィールド/飛行テストやトライアルを実施する前に実施する、最終レベルのテストです。

MROまたはデポテストは、数十年、数世代という長いライフサイクルを持つ車両システムのニーズに対応するサービス、修理、アップグレードを提供します。同じ装置や、修正したバージョンがシステムのテストリグに使用されることもあります。MROテストの課題は、テスタのハードウェアやソフトウェアの陳腐化の問題、人員の交代、システムの定期的なアップグレードによる要件変更など、プログラムのライフサイクルの各局面で効率的にテスト機能を維持することです。 

コストがかかるフィールドテストでは、通常、車両操作に関してできるだけ多くのデータが取得できるよう、車両に多くの計測器を装備します。考慮すべき重要事項は、重量/サイズ、テスト装置への電力供給、およびデータの保存/検索です。モデルは完璧ではなく、システム間のやり取りは複雑なので、以前のテスト手順では対応していない予期せぬ動作が発生することもあります。そのため、フィールドテストは時間とコストがかかるプロセスではありますが、製品開発プロセスにおいて重要な部分です。フィールドテストでは、操作の準備性を判断します。

開発プロセスと関連するテストについて一通り見てきましたので、統合テストアーキテクチャのメリットはご理解いただけると思います。試作の初期段階から、ソフトウェア/電気/機械の妥当性確認、システムレベルテストセル、システム統合ラボまでの設計サイクル全体のテストニーズに1つのプラットフォームで対応できるため、テスト開発期間の短縮やリソースのより有効な活用が可能になります。設計V字モデル全体および複数プログラム間で、装置と人の両方の相互運用性と代替性が高まります。テスト機能と反復に関して、迅速かつ簡単にV字モデルを実施するこの能力は非常に重要です。

統合テストアーキテクチャには、オブジェクト指向プログラミングモデルと類似したメリットがあります。同様の方法で同じタイプのシステムを開発する必要があることがわかっている場合は、プロジェクト全体で使用し、各プロジェクト固有の仕様にあわせてカスタマイズできる、主要なビルディングブロックに投資することができます。 

このプラットフォームベースのテストアプローチは非常に堅牢です。テストアーキテクチャを支える柔軟で拡張性に優れたプラットフォームを使用するため、システム要件の変更や予期せぬ将来の需要によって、システム機能やテスト機能の面で「破綻」するようなことがないからです。つまり、このアプローチを使えば、機能を明確に設計しないことで、今後予想される未知の要件に備えることができるということです。これは、今後必要と思われる柔軟性と拡張性を明確に設計しなければならない、機能が固定された専用のシステムよりもはるかに優れています。機能が固定されたシステムには、時間/コストと機能のトレードオフがあります。

迅速に反復し、コストを抑えた安全なテストを確実に行うには、開発プロセスのできるだけ早い段階で、できるだけ多くのテストを「フロントロード」する必要があります。これは、モデルベースの制御およびシミュレーションを使って、実験室で刺激や実世界環境を再現することで実現できます。そうすることで、以前はフィールドテストにおいてのみ可能だった解析を、システム統合ラボやシステムレベルのテストリグに移行できるようになります。実世界のフィールドの刺激信号を記録し、モデル制御の作動を介してシステムで「再生」するなどの技術により、この種のテストは向上しつつあります。
また、コンポーネントをシミュレートすることで、テスト要件を他のチームのスケジュールから切り離すこともできます。しかし、テスト結果で十分な忠実性を確保するには、コンポーネントのシミュレーションに使用されるモデルおよび手法の確度と有効性を、時間をかけて検証する必要があります。
また、複製が難しく、危険で極端なテストケースをテストしやすいというメリットもあります。テストカバレッジが広がると、設計の信頼性が向上します。

特定の機能に使用できるセンサ、アクチュエータ、計測器、またはソフトウェアの種類やブランドの選択肢が限られている場合があります。システム内の全く異なるパーツを連携させることは、テストシステムの設計コストで重要な部分です。特に、レガシーテスタの老朽化したシステムコンポーネントの改良や再設計を行う場合は、設計コストがかさみます。様々なI/Oや他社製のデバイス機能を搭載したプラットフォームを活用することで、再利用を最大限に生かし、統合作業を最小限に抑えて、効率性を改善することが可能です。構成/拡張可能な分散/同期I/Oアーキテクチャにより、設計プロセス全体のテストケースの様々なI/Oニーズに対応し、プログラム間での再利用を促進します。

計測がより高速、より大量に行われるようになっているため、非常に多くのデータが様々な形式で生成されています。また、より多くのレポート作成のニーズに対応するには、より多くのクライアントが設計サイクルの各種テストのデータにアクセスできるようにする必要があります。データを確実に使用できるようにし、そのデータが実際に使用されるようにすることが既に課題となっています。データを効果的に見つけてロードし、そのデータを対話式に視覚化して解析できるようにする必要があります。また、レポート作成を自動化することで作業にかかる時間を短縮する必要もあります。統合テストアーキテクチャでは、エンタープライズレベルかつITフレンドリーなデータ管理/システム管理フレームワークを提供し、データを負債ではなく資産とすることで、意思決定の改善、反復テストの削減、レポート作成の時間と労力の削減、および資産利用率/稼働時間の向上を実現しなければなりません。

世界中に分散された開発チームやテストチームは、各拠点にデプロイされたテスタを効果的に管理し、生成されたデータを関連付けるという課題を抱えており、その課題はますます増えています。分散したテストシステムとデータを効果的に管理することで、運用の見通しを改善し、ダウンタイムを低減し、生成されるデータの信頼性を向上させることができます。

ソフトウェア定義のテストプラットフォームに基づく統合テストアーキテクチャに投資することは、高度なエレクトロメカニカル車両システムの設計やテストを行うチームにとって最良のアプローチです。このアプローチにより、社内での独自開発や完全な請負契約と比べて、迅速なテスト開発、テストカバレッジの拡大、効率的な運用、迅速で能力の高いチーム、設備投資の削減、長期にわたるテストシステムの稼働時間と保守性の向上が実現します。