【第4回】MBDによる開発プロセス

制御プログラムの開発プロセスはV字モデルで説明されることが多いですが、MBDにおいても基本的にはV字モデルを踏襲します。

ただし、V字モデルはプログラムの品質を確保するためのモデルを示したもので、プロセス（開発の手順、工程）を示すものではありません。実際のところ、開発や設計場面でV字のプロセスを意識される方は少ないのではないでしょうか。

V字モデルの意図はプロセスを表したものではなく、制御プログラムの品質確保の在り方をモデルとして示すものです。要件定義をシステム仕様、基本設計を制御仕様と読み替えると、V字の左右で評価のレベルが一致していることが分かり易いかもしれません。

要件定義に誤りがあると、システムテストを行うまで問題に気付かず大きな手戻りが発生します。場合によっては重大な不具合を見逃すことにつながりかねません。このため、要件定義の段階で目標とする機能・性能が得られるまで試作、テストを繰り返します。基本設計も同様で、検証されたものでなければ、結合テストやシステムテストの段階まで問題に気付かないことになりますので、試作ECUやテストベンチで基本設計の確かさを担保します。各工程で検証を行い、保証された成果を次の工程へとつなぎます。

このようにプロセスの各段階で品質の作りこみを行うことは、自工程完結の考え方によるもので、MBDにおいても同様のプロセスが必要となります。

従来からシステムをモデル化し、シミュレーションを使うことで開発プロセスの効率化が図ることが行われていますが、ここでは制御プログラムの設計にモデリングツールを使い、ソースコードを自動生成する開発スタイルについて考えます。

要件定義をシステム仕様、基本設計を制御仕様と置き換えてみると、V字の左側プロセスの成果物が右側の評価基準となり、分かりやすくないでしょうか。

システムテストでは、システムの挙動や性能が開発の狙い通りであることを確認する工程で、妥当性の検証と言います。結合テストでは、制御プログラムが制御仕様通りに動作していることを確認する工程で、これを一致性の検証と言います。MBDのプロセスも形の上ではV字モデルで表されますが、プロセスの詳細な手順には大きな変化があります。

コマンドラインのタイピングからグラフィカルな設計に代わっており、制御開発の上流では、プログラム言語の知識より物理的、制御工学的知識がより重要となります。

プログラム動作の確認作業も、コンパイラを行いECUへ実装してベンチテストを行う作業が、モデル設計から直接シミュレーションで動作確認を行うことができるようになり、大幅な工数削減が可能となります。

MBDのプロセス解説から話が逸れますが、MBDによる開発の仕方の参考になると思いますので、開発上流でのシミュレータの使い方について少し触れます。

開発した制御アルゴリズムの検証は初期においてはMILSが有効です。アルゴリズムをシミュレーションしながらモデル設計が進められますので、設計効率がよく、コーディングミスのようなうっかりミスも削減されます。

狙い通りに動作するかを確認するには、実機もしくはHILSによる検証が行われます。MILSで動作検証を行うこともありますが、ハードウェアによる制約や処理時間の制約を加味した評価が必要であり、これらに対応したMILSの構築は一般には困難です。

この場合、設計した制御アルゴリズムをマイコンの実装コードに変換してECUへ搭載しなければなりませんが、システム開発者にとって実装コードの設計は本来の仕事ではありませんので、組込みソフトの設計者に作成を依頼することになり、実装できるまで待ち時間が発生します。できれば開発したアルゴリズムを直ぐに試してみたいという要求もありますが、モデルを使って直接プラントシステムを動作させることはできません。

HILSにはシミュレーションモデルの入出力を実信号に変換する機能がありますので、この機能を使ってECUのI/Oを模擬したインターフェイスを作成すれば、制御モデルを使って実機を制御することができます。この機能に特化した装置をRPE（Rapid Prototype Ecu）と言います。基本的にはHILSと同じ機能を有しますので、ECUの内部データ取得のほか、プラント側の状態を計測や運転条件の設定の自動化も可能であり、評価の効率化を図れます。当然、実機の代わりにHILSを使うこともできますので、試作回数の削減や評価設備、スペースの削減にも繋がります。

RPEには通常、高性能なマイコンを使用しており、モデル演算をストレスなく実行できますが、外部割込みに弱い欠点がありますので注意が必要です。制御用マイコンに比べ、割込みハンドラー起動までの時間が長く、且つ、短時間での処理を要求される割込みでは、複雑なモデル演算の処理が間に合わない場合もありますので、この場合は試作ECUを使うか、OSや割込みハンドラーを搭載したRPEを作成することも考えられます。

上記のように検証された制御モデルから制御仕様書が作成されますが、元となる制御モデルは高性能なコンピュータ上で作成したものですので、製品に実装するためには、ECUのアーキテクチャに添った変更作業が必要となります。

パソコン上のモデルは64bitの浮動小数点で演算していますが、マイコン上で動作させるには32bitに変更する必要があり、場合によっては固定小数点演算に変更しなければなりません。その他、物理量を実際の制御量に変換したり、メモリの割当てを設定したりと、マイコンやECUのアーキテクチャに添った実装設計を行う必要があります。

面倒な作業のように思えますが、従来手法でも同様なプロセスを辿っていますので、MBD特有の問題ではありません。これらの変換作業が不要となるよう、専用のモデルブロックを準備して効率化することも出来ます。

余談になりますが、ハードウェアに起因する制約に依存せず、物理的、論理的に開発するスタイルをプラットフォームレス開発、ハードウェアのアーキテクチャに適合した基本的な処理やインターフェイスなどが準備された、特定の基盤上で開発するスタイルをプラトフォームベース開発といいます。

制御モデルはシミュレーション可能ですので、制御仕様書に書かれている設計内容をシミュレーションで確認しながら、実装設計が可能となります。このことから、制御モデルを実行可能な制御仕様書と呼ぶこともあります。

制御モデルにプラントモデルと結合し、閉ループのシミュレーションを行う為のプラットフォームを構築すれば、制御モデルのシミュレーション結果と実装モデルの実行結果を比較することで、データとして仕様と一致することが検証できます。

個人的にV字モデルは実際には成立しないと言ってきました。実際のプロセスは単純な一本の流れではなく、開発の時間軸のズレや組織的な隔たりがあり、単純な形になっていないからです。しかしながら、基本的な考え方を説明しようとすると、ウォーターフォールモデルやV字モデルになると言うことを今回改めて実感しました。

高い品質の製品を作るには、一つ一つの工程を確実に行うことが重要であり、そのためには、各プロセスの成果を明確に判断する基準があるということがＶ字モデルの基本だと考えます。