最近よく耳にする「モデルベース開発＝MBD」は、自動車開発における開発ツールのことで、開発エンジニアが利用するものであり直接ユーザーには関係はしない。だが、この開発ツールによって、クルマは劇的に変えることができるので各社取り入れているのだ。クルマが動くことは物理の基本であり、どのように動かすか？を数値化して開発していく手法だ。それは、エンジンを動かすことも、ハンドルを切ることも、クルマがロールする、ピッチングするなど、すべてが数値化されたデータをもとに開発していくプロセスだ。
ユーザーにも恩恵はある
おおまかに説明すると、目標性能に向けてどのように数値を積み上げていくのか？ というのがその概念。そのプロセスにおいて、人的ミスがなくなる仕組みがある。つまりコンパイル（変換）の専門家を不要とするため、開発周期が極端に短縮できる、試作機を激減させることができる、などといったことがMBDの特徴とメリットになる。エンジニアの書いた仕様書をC言語に変換するとき、C言語を書くのは人だ。エンジニアとは同一人物ではないから、誤解釈もある。そうした場合、修正に数週間かかり、間違いを探す時間もかかる。ところがMBDでは数値化できたものをエンジニアがモデルという「ブロック線図」（後述）にすることでC言語へ自動でコンパイルされ、コンピューターは動く。そこには誤解釈がなく、また間違いをエンジニア自身で修正するといったことができるのだ。
そしてMBDで開発されたクルマは、ドライバーから要求されたことに対し、正確に回答できるようになるという特徴があるのだ。例えば大昔、エンジンはアクセル開度だけで燃料の噴射量が決まっていた（吸気容量はおいといて）。 しかし、いまはアクセル開度と踏み込んだスピード（時間）という要素も加わっているため、ドライバーが急いでいるのか、普通の加速を求めているのか？判定できるようになっている。それによって、燃料の噴射量もかわってくるわけで、出力特性も期待どおりになるということがある。これもMBDツールを使っているからできることなのだ。
つまりアクセル開度が同じ50％だとしても、そこまでに到達するまでの時間が1秒と2秒ではドライバーの「急ぎ具合」が違うわけで、その急ぎ具合に合わせて燃料をコントロールし、イコール、馬力をだすのか、出さなくてもいいのかということが判定されているというわけだ。そのためにはアクセル開度と開度速度から計算される数値があり、それをエンジンレスポンスを鑑みて、1/10secとか1/100sec単位で数値を積み上げていくと期待値どおりの加速が得られるというわけだ。
それが電気モーターになればICE（内燃機関）よりはるかに細かく制御ができる1/1000sec、1/10,000secの世界があるというわけだ。これがエンジンだけでなく、ステアリングだとしたら、どれくらいのスピードで転舵しているかによって、パワーステアリングのモーターアシスト量を変更し、期待値通りにクルマが曲がるということにつながっていくわけだ。
では、さっそく、各プロセスにおいてMBDとは何か？をみてみよう。
マイコンへの指令をどうするか
MBD（Model Based Development）は机上でできたものを実装して動かし、そして検証し、量産へとつなげる技術のことで、メカトロニクス全般にわって、開発するためのソリューションというのがMBD＝モデルベース開発だ。それでもまだ何のことか？よくわからないと思うので順を追ってみてみよう。
PCを使った机上のシミュレーション技術は、これまでにも利用されてきている。それはモデルベース設計と言われているもので、それは、ここで紹介するモデルベース開発の一部に過ぎない。
現代のクルマには、雨量感知式ワイパー、オートライト、オートエアコンなど快適に自動車ライフをおくれる機能があり、一方で燃費が良くなり、排ガスがどんどんクリーンになり、そしてハンドリングも意のままに操れるクルマが数多く発売されてきている。その背景には車載するコンピュータが多数存在し、それらの制御によるものであることは容易に想像がつく。
では、一台のクルマに一体いくつのマイクロコンピュータ（ECU）が搭載されているのだろうか？個体差はあるものの、50～100個程度のコンピュータが搭載されている。それらはセンサーから得た情報をもとにアウトプットデータを作り（I/O）、作動させている。これらのマイコンに書かれている制御ロジックのCコード（コンピューター言語）を並べてみると、700万行から1000万行にも及ぶ文字列が書かれているらしい。それが各マイコンに分散されているので、複雑にもなってきているわけだ。
例えばエンジン制御を考えた場合、制御のための仕様書はA4サイズで20cmもの厚さになるほどの量になるという。しかも、仕向け地によって制御を変更するとなると、さらに複雑になり、仕様書は増える一方だ。したがって、制御、ソフトウエアの重みは年々増してきていることは理解できる。したがって開発工数、費用もソフトウエアの占める割合は5割以上というのが現状でもあるのだ。
従来のVサイクル開発とは何か
これまでは、こうした仕様書からソフトウエアの構造設計、モジュール設計、詳細設計という工程を経てからコーディングされ、単体テスト、モジュールテスト、統合テストが行なわれ、さらに実機を生産し、仕様書どおりに正常稼働するのか？を自動車メーカーは繰り返し試験してきている。
一般的なV-サイクル開発は各レベルに仕様書が存在し、それに対応する試験結果が求められる。そして各レベルの仕様書と試験結果の間には人間の操作が加わっているというのが従来の開発プロセスだ。
そこに革新的な技術として、Vサイクルと同じような考え方の開発プロセスを持ちながら時間とコストの削減、人的ミスを防ぐことなどのメリットがある「モデルベース開発＝MBD」というソリューションがあり、それが近年、車両開発の常識となってきているのだ。
その理由としてモデルベース開発は開発プロセス全体を通じて使うことができるし、個別の開発フェーズでのみ利用することができるので、カーメーカーの都合に応じて利用できる点も、一般化している理由だ。
dSPACEがMBDのパイオニアだ
クルマの制御プログラムはどうやって作られているのか？ ということを知る機会は少ない。今回インタビューしたdSPACE社は、ここまで説明したように、メカトロニクスを行なっている電子制御装置を開発するためのソリューション・ツールを提供する企業で、本社はドイツ・パダーボーンにある。
マツダのスカイアクティブや現行型メルセデス・ベンツCクラス（W205型）の開発はこのdSPACEのモデルベース開発によって造られたものだ。ちなみに、dSPACEのモデルベース開発を使って車両開発している企業は、ダイムラー、BMW、アウディ、フォルクスワーゲン、ポルシェ、トヨタ、ホンダ、日産、マツダ、スズキ、三菱、スバル、GM、フォード、FCA、ボッシュ、コンチネンタル、デンソー、日立オートモティブシステムズなどで、ある意味総ナメ状態だ。それほど、要求されている技術でもある。
ではMBDで開発されたものは何か？ ひと言で言えば、前述のVサイクル開発の領域全般に及んでおり、その結果、開発プロセスの内容は従来よりも効率よく、低リスクで開発できているということになる。
ここが大事！これがMBDの正体だ
従来であれば、PC上のシミュレーションが終わり、問題がなければ制御開発者が仕様書を作成し、その仕様書を見ながらプログラマーがコーディング作業でCコードを生成し、それを検証するという手順だ。その間に、人の手による仕様書での記入漏れやCコードを生成するための理解とコーディング作業があり、そこには人的ミスの存在がある。さらに完成までに数週間から数か月という時間も費やされている、というのがこれまでのカーメーカーの現状だ。
具体的には、まず、要求分析（仕様書）にある制御ロジックや制御対象が計算式などで表されているものを、ブロック線図にしたものをつくる。これを「モデル」と呼んでいる。このブロック線図がキーテクノロジーの一つであり、ブロック線図にすることにより、ビジュアルで分かりやすく、なおかつシミュレーションでき、さらにこのモデルをプロセッサー（CPU）に実装できるので「動く」仕様書として使えるものなのだ。
こうしてできたモデルであれば、担当ではない他の人にこのモデルを渡してもテスト対象は常に、同じ挙動をしてくれるというメリットが生まれる。つまり、だれがやっても同じ結果が出てくるというメリットがある。
コンピュータにおけるプログラム言語が、かつてのアッセンブリ言語からC言語になり、その進化版の「モデル」を開発したとも言える。モデルはCコード変換するまえの計算式をブロック線図化することで、メリットを産むものでモデル言語と言ってもいいかもしれない。抽象度がどんどん進化したことで、見た目の分かりやすさがあるから、理解しやすいという特徴を持っている。したがって、アイディアを共有しやすいという特徴も生まれてくる。
そしてこのモデルを使ってCコードを自動生成し、I/O（インプット・アウトプット）を含んだものを実装することができるというのも特徴で、この部分はdSPACEが開発したものだ。つまり、Cコードへのコンパイル（変換）が人の手を介さず、自動で生成できるため、人的ミス、作成時間の短縮というメリットを産んでいる。これもモデルベース開発の特徴とメリットでもある。
量産化へのプロセス
モデルベース開発では、PC上のシミュレーションで使った制御対象のモデル（制御されるエンジンや車両）と制御モデル（ECUの中に入るロジック）二つのモデルを使って次のプロセスへ進む。制御モデルをRCP（Raid Control Prototype）という試作のECUに実装する。この時にI/O (アイオー（Input/Output）、A/D（アナログ/デジタル）変換, D/A（デジタル/アナログ）変換, デジタル入出力など)も含めて設定できる。つまりRCPを介して実機のエンジンテストが仕様書どおりに稼働するのか試験できるわけだ。
PCのシミュレーションがOKで、実装し、テストするという流れが半日程度の時間でできるという、時間的な効率も高い。この段階でロジックに問題があればPCに戻せる。修正してコントローラーに戻せば量産のECUを作るプロセスへと移行できるスピードがある。
RCPはシミュレーションから実装までの仕様書作成、コーディングという作業はここでも自動で行なうことが可能で、人の手が全く入らないため人的ミスが存在しない。さらにプログラマーの入力作業自体に数週間から数か月かかっていた作業も、自動生成されるので数時間で完成してしまうというものなのだ。
このことは、逆にエンジニアがプログラマーからのコーディング作業を待たずとも、仕様書を完成させることができるわけで、ここでも時間とコスト、そして開発効率を大幅に削減できるメリットをもっている。
検証プロセス
さて、モデルベース開発は、今度は検証作業に移る。RCPからのデータを量産用のCコードに変換し、シミュレーション検証をする。そこでは最終の車両による検証の前に、このロジックが正しいのか？ほかのソフトとの連携は問題ないのか？という検証を行なう。この段階ですでに量産用のECUを使って検証する。それがHILS（Hardware in the Loop Simulator）という装置を使ってのシミュレーションテストになる。これもdSPACEの主要製品である。
このときの制御対象はまだ、最終の完成車両ではなく、リアルタイム・シミュレーターで、名称の由来でもある。検証対象がハードウエア（エンジンやモーターを稼動する制御ECU）になり、クローズドループで循環しての検証となるので、HILSという名称になっている。つまり、検証の対象がエンジンやモーターを稼動する制御ECUなどのハードで、HILSでシミュレーションされている制御対象のエンジンを正常稼動できるか、コンポーネント部品、構成は正しいのか？システムは正常作動するか？そして仕様書は正しいのか？という検証になる。
ここで不具合があってもRCPに戻すだけで、そこではプログラマーを介さずとも、エンジニアにより仕様書の変更が可能で、再び量産データへのコーディングも自動で行なわれるわけだ。こうして制御プログラムが完成して実機テストを経て、生産開始となる流れなのだ。
マツダのスカイアクティブもMBDを利用
モデルベース開発の説明として、ここではエンジン制御をたとえ話としているが、マツダのスカイアクティブはこのMBDを使って開発されている。また、冒頭で言っているように、マイコン制御されているものすべてにモデルベース開発は対応することができる。例えば電動パワーステアリングのEPSと横滑り防止のESC、四輪コーナリングブレーキ制御EBC（ABS)などの制御にモデルベース開発がメリットを生み出す。それが最近発表されたマツダのG-ベクタリング・コントロールの開発背景でもある。
さらに、マイコン制御されるものすべてを統合して、開発したクルマがメルセデス・ベンツのW205型Cクラスなのだ。都市伝説のように、「輸入車の初期モデルは買うな、モデル末期がベストなコンディションだ」という話があるが、アウディでは2002年投入のA8では発売後の仕様変更が多少あったという。それが2007年発売のA5では発売後の仕様変更は全くなくなっているのだ。
これはモデルベース開発の領域の広さがかかわっているのだろう。すべての領域でモデルベース開発が利用されていれば、開発直後からエンジニアが目指した目標性能に達しているということが実現するわけだ。
このことはわれわれユーザーにも多大な恩恵を産むだろう。それは感じにくい部分かもしれないが、逆に言えば当たり前のことがキチンとできるようになったということだ。そしてこの先、自動運転の領域に入れば、ますます、モデルベース開発は必要となってくることが分かる。
ADAS開発に欠かせない仮想検証
ここまでで制御プログラムの開発の流れと、モデルベース開発のかかわり方を見てきた。こうして俯瞰して考えてみると、革新的でもあり、効率性のよい開発技術であることを感じる。ｄSPACEジャパン株式会社社長の宮野 隆氏はこのモデルベース開発は目前に迫る自動運転技術には欠かせないものだと位置づけている。
宮野氏は以前からインテークマニホールドやインジェクターのシミュレーションを長く経験してきた経緯もあり、モデルベース開発の将来性に強く魅力を感じたはずだ。宮野氏は1980年にミクニに入社し、マイコンでエンジンを回す研究をしていたという。当時はキャブレターからインジェクションに変わるタイミングで、Lジェトロの燃料噴射によるエンジン制御が求められていた時代だ。
その宮野氏によれば、この先、自動運転のレベル3の領域にはADAS（先進運転支援技術）技術が必須であり、開発にはシミュレーション技術がなくてはならないという。したがってモデルのシミュレーションだけでなく、ECUも含めた全部のシミュレーションが必要になってくるわけで、ｄSPACEとしてPCベースの仮想検証シミュレーションでECUを検証する方法を提案している。
それは、VEOSという仮想検証という次なるステップが必要だという。この技術がなければADASは実現しないのではないか？ということだ。自動運転を安全に実用するためには色々な状況をテストする必要がある、その為には色々なケースを高速に仮想的に検証する必要がある。 ボッシュの論文によれば、自動運転をするにはクルーズコントロール制御の10の6乗の実車テストが必要だという。つまり、100万倍のテスト量ということで、1万倍のスピードのバーチャルでテストしたとしても100年かかる。そのためには次なるステップがなければ実現しないというわけだ。
さて、こうした自動車開発における、進化はユーザーには直接見えないものの、手にするクルマにはこれだけの技術がかかわっているということが少しでも理解できると、サイトのポリシーでもある「いいクルマは何故いいのか？」の片鱗が見えてくる。
*資料提供：dSPACEジャパン株式会社
