3.  モデルベース開発　のプロセスについて

　この章も当方都合で恐縮ながら、過去に執筆した、「SecJournal2012（IPA誌）：世界一のため、創造のためのモデルベース開発(MBD)へ」から転載させていただきます。実際には　モデルベース開発のプロセスは　一様ではないが、わかりやすくするために、あるパターンで説明をしていることは、ご留意ください。

　●モデルベース開発のプロセス

これに対しモデルベース開発の模範的プロセス例を示す。ここでは5つのプロセスで事例説明したい(図8)。まず第1のプロセスは、Rapid-ECUと呼ばれる、内製の汎用制御コンピュータを活用する。試作に3カ月をかけることなく、朝思いついたアイデアは、昼にはプログラム化し、夕方には実車テストやテストベンチでの結果を見ることが出来る。つまり90日かかっていたことが1日で出来る手段である。ECUの試作を待たずにどんどん実機を使ったカラクリ研究開発を進める手段である。

第2のプロセスは、構想設計用MILS※10を活用した、エンジンも車も存在しない開発初期段階のモデルベース開発である。車両レベルでの走りや燃費、変速が再現出来る車両゙ル技術が求められる。走行するためには、制御モデルもドライバーモデルも路面モデルも必要である。SKYACTIVではこれらのモデルを活用し、エネルギー最適化を机上で徹底的に行った。その結果、燃費30km/Lの車

の姿も形も無い開発着手時期に、30km/Lで走る仮想車両モデルが出来上がっていた。そのモデルを規範として開発は進んでいったのである。つまり、開発初期段階において、燃費目標の整合は取られたことになる。

第3のプロセスは、前工程で配分された機能目標を形あるものへブレークダウンするプロセスである。各部門の詳細設計をサポートする詳細設計用MILSの活用である。この段階になると、エンジンモデルも車両モデルも詳細度を増し、それとつながる制御のモデルも詳細になる。モデルとしての計算は非常に重くなる。これを効率化するために、複数のコンピュータを並列処理させる特別なハードウェアに、これらの詳細モデルをインストールしての作業となる。これを持ってしてもエンジン燃焼モデルはスーパーコンピュータ上でないと動作出来ないほど計算が重いため、この解決のためには、IN/OUT関係だけ合わせ込んだ、計算が軽い統計モデルのようなものに置換して利用する。このようなモデルのハイブリット的な利用は、実用化技術としてなくてはならない工夫である。これらのモデルを使って、従来は実車でなければ出来なかったような車両レベルの総合診断を、1万通りでも10万通りでも、机上で自動実験可能である。

第4のプロセスはHILS※12を活用した、実機ECUの動作検証である。このプロセスでは、前工程で設計検証した結果通りとなるよう、答え合わせを行う。また、このプロセスになると、本物のセンサーやアクチュエータも繋いで、電気的な過渡応答やノイズの影響などを、効率的に検証していく。

第5のプロセスは、実機試作後のキャリブレーション(以下、キャリブレ)への活用である。エンジンのキャリブレの困難さを知らない方も多いはずなので説明する。燃料噴射のタイミングや量など、様々なパラメータを、あらゆる環境下で最適にするために、調整すべきパラメータ数が膨大にある。例えば、ある1つの定常MAP(600格子点)のキャリブレだけを説明するが、5パラメータを7水準ずつ変えて調整するだけでも、その組み合わせは、7×7×7×7×7×600で1千万通りを超え、これをすべてエンジンを回しながら確認するとなると途方も無い時間がかかる。そこでエンジンが完成したあと、実機エンジンのIN/OUTと等価なエンジンモデルを作るのに必要な基礎データを素早く計測し、作り上げたエンジンモデルを用いて机上でキャリブレすることを行っている。これについても、この技術が出来た頃、「ベテランエンジニアが実機でキャリブレした結果」vs「モデルベースでキャリブレした結果」を比較する実証実験を行った。結果は机上のほうが、燃費が数%良く、かつ所要期間もはるかに短かった。すでに現在の制御システム&パラメータは、人間の能力では全体が見渡せないほど複雑で膨大で、最適解がどこにあるのかを探し出せないうちに納期が来てしまうことを意味している。この傾向は、今後ますますひどくなることは間違いない。最適解を見渡すための道具としても、モデルベース開発は必須となる。

My BLOG

TopPage

CONTENTS

〜　ミスター・モデルベース開発　　　　　　　と呼ばれた男の独言　〜

ヘンジニア