HILシミュレーションへの継続的統合の最適化

HILシミュレーション向けのモデル開発における根本的な変化

ここ数年の間に、HILでのシミュレーションやテストが開発および妥当性確認の不可欠な要素としてますます確立されてきました。それに伴い、HILシステムを設計、導入、提供、利用および妥当性確認プロセスに統合する手法も大幅に変化しつつあります。たとえば、リアルタイムHILシミュレーションに使用するプラントモデルの開発や統合はこれまで、経験豊富な数名のモデリングおよびHILエキスパートが連携して行ってきました。しかし、HILシステムの数が増加し専門化が進むにつれて、従来の手法では克服できない多くの課題が生じるようになってきました。

また、排ガス規制の厳格化やパワートレインアプリケーションの電動化、ビークルダイナミクスやブレーキ機能、アクティブセーフティ機能における性能アルゴリズムの高度化、および自動運転などでのセキュリティ要件の増加に伴い、HILシミュレーションの要件はますます厳しくなっています。そのため、HILシミュレーションで使用されるモデルの範囲や精度に対する要求も増加し続けています。このようなことから、他の分野や部署で使用されているモデルを再利用する傾向が高まっています。時には、別の分野に固有のモデリングツールを使用して実装されたモデルでさえ再利用される場合もあります。

さらに、個々のシステムから大手OEMメーカーのHILファーム全体に至るまで、自動車メーカーやサプライヤが利用するHILシステムの数は急激に増加しています。このように、ECUとモデルバリアントの組み合わせが無数に増加したことによって、問題はさらに複雑化しています。そのため、複数のHILシステム間でモデルの管理や割り当て、展開を適切に行うことは非常に困難なのが現状です。

さらに付け加えると、以前よりも開発期間の短縮、生産性の向上、およびシステムの最大限の自動化が求められていることにより、ダウンタイムを最小限に抑えることが不可欠な状況が生み出されています。

このような状況に対して、

• 多くの異なるドメイン領域およびソースから、
• 適切に調整されたプロセスで、
• 高度に自動化された方法で、
• 最大限のプロセス信頼性で、
• 異なるHILシステム間を通じて、シミュレーションモデルを統合し使用できるようにするためには、新しいアプローチが必要となります。

言い換えれば、専門的なワークフローからの脱却と生産的な「モデルファクトリ」への移行が必要になっています。そのようなアプローチはすでに存在しています。それを活用すれば、以下に示すようなHILアプリケーションへの移行が可能になります。

継続的統合は最新のソフトウェア開発プロセス成功の鍵

最新のソフトウェア開発プロセスは、これらの新しい課題に対する最適なコンセプトを提供するだけでなく、非常に有益な方法でHILシミュレーションに適応させることができます。継続的統合はこれらのコンセプトの1つであり、大きな組織でもソフトウェア製品を大規模に開発できるようにするための効率的かつ迅速な方法を提供します。

継続的統合により、Agile Manifesto（アジャイルマニフェスト）の以下の原則を達成することができます。“Working software is the primary measure of progress.”（「実用的なソフトウェアを導入することが、進歩に向けた主要な対策である。」）継続的統合という重要なコンセプトを導入すれば、ソフトウェアの開発およびテストの方法を劇的に変え、この目標を達成できるようになります。このコンセプトではまず、スタッフは明確な責任と意思決定権限を持った小さなアジャイルチームとして組織されます。このチームでは、各業務を優先順位が付けられた未処理案件として整理し、上から順に作業します。このような方法で、チームはスプリントと呼ばれる小さな反復作業を繰り返し、1～4週間の期間内でソフトウェアを開発します。

アジャイル開発では、各反復プロセスにおいて製品の作業インクリメントが生成されます。このようなソフトウェアのインクリメンタル開発を実現するためには、すべての反復プロセスで計画、開発、構築、およびテストを1つのユニットテストに組み込む必要があります。これにより、開発プロセスにおいてインクリメントの品質が保証されます。このような枠組みはしばしば、ビルトイン品質と呼ばれます。そのため、継続的統合はウォーターフォール手法とは大きく異なります。ウォーターフォール手法では、開発およびテスト段階は相互に分離しています。

しかし、どのようにすればこのインクリメンタル開発は達成できるのでしょうか? このダイナミックな継続的プロセスでは、次のような多くの手法を活用できます。

• SVNまたはGitなどのツールを使用したソフトウェアのバージョン管理
• 現在の統合の自動的構築
• テストの自動実行
• コード品質の迅速なフィードバック
• テストの並列化とオーケストレーション

このように、継続的統合を達成するうえで、自動化および協調化されたテスト手法は不可欠となります。「Efficient Continuous Testing with dSPACE」の記事に、このメカニズムおよびこの独自の車載ソフトウェア開発手法に対するdSPACEの見解が説明されています。

HILシミュレーションに継続的統合を適用する際の成功要因

多くの車載ソフトウェア開発環境には、アジャイル手法や特に継続的統合がますます実装されるようになってきています。ここでは、テスト対象のコードに（リアルタイム性能などの）特殊な要件が求められるため、品質やテスト手法への要求も非常に厳しくなります。HILシミュレーションは、SILテストとともにテスト手法における不可欠な要素です。

継続的統合アプローチを用いたHILシミュレーションでは、実行可能なHILシステムを取得するためのプロセスが劇的に変化しています。特にHILシステムのコミッショニングと展開は、もはや専門家が経験則に基づいて逐次実行することでは対応できません。そうではなく、大規模なシミュレーションモデルの開発から複数のHILシステムの展開までのすべてのステップを並列に実行しなければなりません。

このようなプロセスでの標準的なタスクには、以下のものが含まれます。

• モデル間通信の設定
• モデルIO間通信の設定
• バスの設定
• タスクの設定
• リアルタイムアプリケーションのコンパイル
• HILへの配置

ただし、いくつかの企業では、継続的統合アプローチをHILテストに適用することで、既に非常に大きな成果を得ています。ここでは、2つの継続的統合サイクルが相互に作用しています。1つ目のサイクルはECUソフトウェア開発プロセスであり、2つ目のサイクルはHIL用のモデル統合プロセスです。dSPACEでは、お客様がこのプロセスを適切に導入できるようにするための総合的なサポートとアドバイスを提供しています。

次のような対策を講じると、HILシミュレーションの継続的統合を適切に導入することができます。

モデルのモジュール化

モデル構造を小さいユニットで構成しモジュール化することにより、堅牢で効率的な統合を容易に実現できます。モジュール型のモデル構造を使用すれば、アジャイル手法を用いるチームは、他の多くのチームによって構築されている大規模なモデルに妨げられることなく、自身が担当するモデルに責任を持ちつつ、（バーチャルやリアルタイムなどの）テストのさまざまな段階を通じてその品質をチェックすることができます。これにより、ビルトイン品質の達成が可能になります。このように、チームやモデルの管理を柔軟に行うことにより、パフォーマンスが非常に高いだけでなく変化にもすばやく対応できる開発サイクルが実現すると同時に、バリアントの管理も大幅に容易になります。

シミュレーションモデルを事前に準備

HIL統合プロセスは、ともすれば非常に時間がかかり非効率的になる場合があります。これは、統合プロセスにおける次の2つのステップがシステムモデル全体で毎回実行されることで発生します。

1. モデルコードの生成
2. モデルコードのコンパイル

ここでは、ほとんどの場合、モデルの個々の部分のみ（10 %未満）が反復して変更されるため、効率性が妨げられます。

そのため、これらの2つのステップをHIL統合プロセスから切り離し、モデル開発フェーズに移行するのが基本的な考え方です。たとえば、モデルの新しいバージョンを登録した際にこれら2つのステップを自動的に実行するようにします。この場合、各モデルは既に生成およびコンパイル済みのコードとして配布されています。これは、展開フォームモデルコンテナと呼ばれます。このアプローチでは、HIL統合プロセスのスピードが大幅に向上します。

命名規則によるインターフェースマッピングの管理

次の手法を使用すると、モデルをI/Oや他のモデルに接続する作業が非常に容易になります。

• ノルムが設定された名前をモデルポートに使用してポートをマッピング
• 一貫性のある方法に基づいて一意に特定されるポートを使用することにより、モデル交換シナリオの場合でも持続的な通信をセットアップすることが可能になります。

これにより、モデルインターフェースを変更した場合でもモデル交換プロセスを高度に自動化し、変更管理を効率的に行えるようになります。

バーチャルECUをデジタルツインとして使用

多くの場合、実ECUはHILシステムをセットアップする時点ではまだ入手できません。これにより、HIL開発およびテストプロセス全体が停止する場合があります。この問題を克服するためには、未入手のECUをシミュレーションで再現することが推奨されます。これを実現するには、ソフトECUと呼ばれる非常に単純なビヘイビアモデルを使用するか、またはより高度な方法として、既存のECUアプリケーションコードを使用してバーチャルECU（これにも、テストが必要なベーシックソフトウェアが含まれる場合があります）を構築します。ソフトECUとバーチャルECUは、未入手の実ECUのデジタルツインと解釈できます。ソフトECUとバーチャルECUを使用することにより、実ECUが入手可能であるかどうかに関わらず、いつでもシステムを実行できるようになるため、HILセットアップを大幅に迅速化することができます。

ソフトECUまたはバーチャルECUを使用すると、入手可能性の問題を解決できるだけでなく、テストをより継続的に実行できるようになります。なぜなら、単一のハードウェアコンポーネントが故障した場合でも、シミュレーション全体を実行できるからです。ただし、このアプローチ（特にレストバスシミュレーションが必要な場合）には、膨大なインフラストラクチャが必要になります。

移行の管理

多くの企業ではすでに、HILテストの生産性をさらに向上させるための鍵として、継続的統合プロセスを導入してモデル開発とHILアプリケーションを統合しようとしています。モデル構造のモジュール化、プリコンパイル済みのモデルコードの使用、インターフェースの管理、マッピング、ソフトECUまたはバーチャルECUの使用などを含む上記のベストプラクティスは、継続的統合を適切に導入するための重要な要素です。dSPACEの各種ツールやソリューションは、HILシミュレーションの継続的統合プロセスに対応しています。そのため、モデルビルド用のサーバや各種プロセスを高度に自動化した形でセットアップすることができます。また、当社ではクラウドベースの統合やビルドプロセス、およびビルド-アズ-ア-サービスビジネスモデルやインフラストラクチャといった新しいソフトウェアモデルの実用化も見込んでいます。dSPACEはこのような開発の最前線において、多くのお客様と密接に協力しつつ、さまざまな問題に取り組んでいます。dSPACEが提供するツールを使用すると、従来のモデル作成プロセスや納品プロセスを、柔軟かつ高度に自動化されたプロセスへと移行することができます。これらの新しいプロセスを使用すると、自動車の開発および妥当性確認に関連する現在の課題だけでなく、将来的に変化していくさまざまな要件にも対応していくことができます。

dSPACE：Your Partner in Simulation and Validation