HILSは右バンクだけのものではない

V字プロセスを組織図として捉えていませんか？

モデルベース開発の説明では、V字プロセスの図がよく使われます。

左側には要求分析や設計、モデル作成が並び、右側には単体試験、結合試験、システム試験などの検証工程が並びます。

そして、HILSは右バンク側の検証手段として記載されることが多くあります。

この図をそのまま組織の役割分担に当てはめると、

「HILSは右バンクにあるので、実験部署や評価部署が担当する」

という整理になりがちです。

もちろん、実験部署がHILS設備を管理し、評価を担当すること自体に問題があるわけではありません。

しかし、HILSを右バンクの評価専用設備として扱ってしまうと、モデルベース開発が目指していたはずのシフトレフトが進みにくくなることがあります。

V字プロセスは、部署の境界を表す図ではない

V字プロセスは、設計と検証の対応関係を整理するための考え方です。

左バンクで定義した要求や設計内容を、右バンクでどのように確認するかを対応付けています。

そのため、

• 左バンクは設計部署
• 右バンクは実験部署
• HILSは実験部署の設備

という組織図を表しているわけではありません。

ところが、V字プロセスを部署ごとの担当範囲として捉えてしまうと、設計者はモデルやソフトウェアを作成し、完成したものを実験部署へ渡す形になります。

実験部署は、受け取ったものをHILSで評価し、不具合があれば設計部署へ差し戻します。

この流れは、一見するとV字プロセスに沿っているように見えます。

しかし実態としては、

設計
↓
実装
↓
評価
↓
手戻り

という、従来型のウォーターフォール開発と大きく変わらないことがあります。

設計者がHILSを使えないという問題

シフトレフトの目的は、問題をできるだけ早い段階で見つけることです。

設計者がHILSを活用できれば、正式な評価工程へ進む前に、さまざまな確認ができます。

例えば、

• ECU入出力の整合性確認
• 通信異常時の挙動確認
• センサ故障や断線時の確認
• 境界値や異常値に対する確認
• 実時間処理の確認
• 制御モデルと実装コードの挙動比較
• 他ECUやプラントとの組み合わせ確認

などです。

ところが、HILSが実験部署の評価専用設備になっていると、設計者が自由に使用できないことがあります。

利用には正式な依頼や予約が必要で、評価仕様書や完成したソフトウェアがなければ試験できない場合もあります。

その結果、設計途中で少し確認したい場合でも、気軽にHILSを使えません。

これでは、HILSという高度な設備があっても、問題を早期に発見するための環境として十分に活用されません。

「HILSの管理者」と「HILSの利用者」は分けて考える

ここで重要なのは、HILSをどの部署が所有するかではありません。

設備管理、安全管理、校正、保守、試験品質の保証などを考えると、実験部署や評価部署がHILSを管理することには合理性があります。

一方で、HILSの利用まで実験部署に限定する必要はありません。

例えば、HILSの活用を次のように分けて考えることができます。

設計段階でのHILS活用

設計者や制御開発者が、正式評価前の確認に使用します。

この段階では、原因調査や試行錯誤を含め、比較的自由にHILSを使えることが重要です。

試験結果を合否判定するというよりも、設計を良くするための検討環境として使用します。

正式評価でのHILS活用

評価部署や実験部署が、定められた試験仕様や判定基準に基づいて使用します。

こちらは品質保証や第三者性、再現性、証跡などが重要になります。

同じHILSであっても、設計検証と正式評価では目的が異なります。

この二つを分けて設計することで、シフトレフトと品質保証を両立しやすくなります。

HILSは「最後に試験する設備」ではない

HILSは、完成したソフトウェアを最後に評価するためだけの設備ではありません。

MILS、SILS、PILS、HILSは、単純に開発工程の後ろへ順番に並ぶものではなく、設計の成熟度や確認したい内容に応じて使い分ける検証環境です。

必要に応じて、設計者がMILSとHILSを行き来することもあります。

HILSで見つかった現象をモデル上で再現し、制御ロジックを修正して、再度HILSで確認することもあります。

この繰り返しこそが、モデルベース開発の重要な部分です。

HILSを右バンクの特定工程に固定してしまうと、この設計と検証の反復が難しくなります。

モデルベース開発は、ツール導入だけでは変わらない

SimulinkやHILSを導入しただけで、モデルベース開発が実現するわけではありません。

従来の部署分担や承認プロセスをそのまま残し、使用するツールだけをモデルやHILSに置き換えると、開発の流れはほとんど変わらないことがあります。

モデルベース開発を進めるうえでは、

• 設計途中で検証できる環境
• 設計者が試行錯誤できる運用
• モデル、試験環境、試験結果を共有する仕組み
• 設計検証と正式評価の役割分担
• 不具合を前工程へ素早く戻す仕組み

まで含めて考える必要があります。

まとめ

V字プロセスの右バンクにHILSが描かれているからといって、HILSを右バンクの部署だけが使用する必要はありません。

V字プロセスは部署の境界を示す図ではなく、設計と検証の対応関係を示すものです。

実験部署や評価部署がHILSを管理しながら、設計者も早い段階から利用できる。

そのような環境を作ることで、HILSは単なる最終評価設備ではなく、設計品質を高めるための開発環境になります。

モデルベース開発で重要なのは、従来の開発工程にモデルやHILSを当てはめることではありません。

モデルやシミュレーションを活用し、設計と検証を早い段階から繰り返せる開発プロセスへ変えていくことです。