今回は自動車の制御開発では当たり前となってきているモデルベース開発と実際の適用例を記載していきます。
モデルベース開発とは
まず、モデルベース開発の理解ですが、弊社では広義の意味で開発対象をモデル化し、そのモデルに基づいて制御やシステムを構築することであると考えています。開発目的やフェーズに応じたモデルの粒度で開発対象についてモデル化を行い、それに応じた構想や設計、検討を行っていることを指します。
従って、例えばエクセルやPythonなどの言語で表現されたモデルを使って制御等を構築していく場合、これらもモデルベース開発であると言えます。一方で、上記のようなものを用いてモデルを構築した場合には、モデルを視覚的に理解しにくいという点と実際にECUへ実装するコードの落とし込みに工数がかかるという点が課題となります。そこで開発現場では一般的にMathWorks社のMATLAB Simulinkが用いられます。
この図では足し算や伝達関数のブロックが出てきていますが、simulinkではこれらのブロックを線でつなぐことで四則演算や微分積分、無駄時間や前回値などの処理を記述し、モデルを構築することができます。また、ここで構築したモデルはsimulink CoderなどのMathworks社の製品を用いてオートコードでC言語に変換することが可能で、この変換されたC言語をマイコンに実装することができます。実用的にはマイコンのスペックにあわせてモデル作成時に変数の型を適切に設定したり、離散化ブロックを用いて全体のモデルを記述するなど、スムーズにマイコンに実装するためのモデル作成のノウハウが存在します。
モデルベース開発の特徴
一般的にはモデルベース開発には下記のような特徴やメリット・デメリットが挙げられます。
（東芝情報システム様ホームページを参考にさせて頂いております。）
特徴
1.モデルが動く仕様書になる
2.自動コード生成できる
3.適合・評価の精度向上と期間短縮
メリット
1.仕様書の品質向上
2.ソフト作成時の品質向上
3.検証時の品質向上（不具合の混入）
4.変更箇所の視覚化・管理
5.モデルの再利用ができる
デメリット
1.導入初期段階で一時的に設計工数が増える
2.教育・人材育成が必要
3.導入時に開発体制のリバランスが必要
基本的には開発の初期段階からモデルを用いることで、モデルによる各フェーズ間の業務の受け渡しが可能となる為、手戻りが少なくなったり、検証時間が短縮できることがメリットとなります。
例えば下の図はソフト開発プロセスの一例ですが、青枠で囲んだ設計フェーズにおいてもモデルを用いたシミュレーションを行うため、設計フェーズの工数が増加します。一方で、検証フェーズにおいてはシミュレーションで確認ができている部分が増えてきますので、フェーズに適した粒度でのモデル化ができている前提であれば実機検証でNGが出る割合が減るため、検証フェーズの工数が削減されます。
したがって、全体の工数削減につながるケースが多いものの、仕事のやり方が変わる為、設計工程の工数が増えて、検証工程の工数が減る形になり、新たにモデルベース開発を導入する際は人員の配置転換などの対応が必要となる場合もあります。
東芝情報システム様作成のモデルベース開発導入前後の工数の変化のグラフを転載致します。
システムのモデル化
モデルベース開発においては制御対象をモデル化していく必要があります。ここでは簡単なモデル化として運動方程式をsimulinkで記述してみます。
質量Mの物体が外力F、抵抗力R、速度比例の抵抗Cを受けて運動する場合を考えてみます。simulinkで記述する際は加速度を積分する形でモデル化をしていきます。
モデル化すると下記のようになります。ここではモデルのパラメータを質量 M = 10 [kg]、外力 F = 12 [N]、抵抗力 R ＝ 2 [N]、速度比例抵抗 C = 5 [N/(m/s)]としています。
上記のモデルをシミュレーションしてみます。手計算すると、速度０m/sでは(12-2)[N]/10[kg] = 1 [m/s^2]の加速度が発生、速度の平衡点は(12-2)[N]/5 [N/(m/s)] = 2 [m/s]となります。
モデルは正しくできていそうですね。
現実のところ、例えば減衰係数は速度に対して一定値であることは珍しいです。また、油圧のダンパ等を用いている場合は温度によって油の粘性係数が変化し、減衰係数が変化します。伸び側と縮み側で減衰係数が違うのも一般的かと思いますのでそのような特性を入れていく必要があります。以下の例ではLookUpTableを用いて速度に対する減衰係数が変化する状態を表現してみます。
このように一番簡単なモデルから検証を開始し、徐々にモデル化する対象を詳細に記述していきます。例えば、ハイブリッド車の燃費シミュレーターを内製する場合、エンジン、バッテリ、モータや発電機等といったコンポーネントを独自にモデル化しています。
車両におけるモデルベース開発の設計や検証で用いられる設備
モデルベース開発の設計や検証工程では下図のようなものが一般的に用いられます。
一番左はMILSやSILSと呼ばれるもので、主に計算機（パソコン）の中で制御対象をモデル化したプラントモデルを相手に制御コントローラの設計と動作確認をします。MILSはMATLAB Simulinkで記載されたのものを計算機の中でそのまま動かすことによって検証し、SILSにおいてはコントローラ部分をオートコードでＣ言語にした後、動作検証をするものです。MILSでコントローラを作る際にECUにそのまま実装できるような形で作られていれば、MILSとSILSの計算結果が異なるというケースはまれです。
左から２番目が、HILSと呼ばれるもので、実コントローラを車両を模擬するシミュレータと接続して実コントローラの検証を行います。このシミュレータにはdSPACE社のSCALEXIOが用いられることが多いです。実コントローラを用いることで、マイコンのリソースの使用状況を確認できることと、車両をシミュレータで模擬しているため、物理的、ソフト的な故障を発生させたときの実コントローラの挙動をみることができる点が大きな利点です。
右側二つの台上ベンチやシャシダイナモはモデルベース開発でなくても開発に用いられると思います。モデルベース開発における台上ベンチの使い方は実機での動作確認という意味合いだけでなく、台上ベンチに組み上げている実際の部品の挙動をモデルベース開発で用いている実機相当部分のモデルにフィードバックしてモデルの精度向上を行うことで、前工程での設計の精度を上げていくことができるという点です。ベンチでの結果とモデルの結果が異なる場合はモデルを修正して再度設計を行うといった開発運用となります。シャシダイナモにおいても同じで、実車の動きがこれまでのシミュレーション通りであるかを確認するだけではなく、実車の実験データをモデルに織り込むことでモデルのシミュレータの精度を高めて、設計の効率化を図ることができます。
このほかにもRCP(Rapid Control Prototyping)と呼ばれる汎用コントロラーと実制御対象を用いるパターンもあります。例えばdSPACE社のMicro Auto Boxと実際の車両という組み合わせで検証を行います。新しいシステムを搭載した車両などに対し、実コントローラへの実装工数を抑えて早く車両実験を行う目的でこの方法がとられます。
自動車の開発プロセス
モデルベース開発の適用例に進む前に自動車開発のプロセスについて述べます。自動車開発における上位の概念がきちんと下流にまで伝わっていないと、モデルベース開発に落とし込む際に設計の要件や検証工程の検証内容が本来の意図からずれてくることに繋がります。
上図に自動車開発プロセスの一例を示します。まず、コンセプト検討フェーズとして商品コンセプトや法規・規格の対応、競争力、ものづくりの観点から車両のコンセプトを決定します。その後そのコンセプトが実現可能か、技術的な検討を行います。この際、安全関連の検討や性能、コストなどの各種検討を技術検討に織り込んで検討をしていきます。その後、技術検討に基づいて製品としての各目標を策定します。最後に、策定した目標を達成できるように詳細設計検討を行っていきます。この図では制御関連について書いてあり、各要件や要求を織り込みつつ、制御システムの構成からロジックを作るところまで、詳細な設計検討を行っていきます。
モデルベース開発の自動車開発への適用例
前置きが長くなりましたが、本題の自動車開発への適用例を説明していきます。ここではハイブリッド車のコントローラの開発を例として説明していきます。
おおまかに燃費の目標策定からハイブリッドコントローラの実装までの開発の流れを示すと下図のようになります。
この図の左側が設計工程、右側が検証工程となります。左右で対応するフェーズにおいて、設計と検証がペアになっており、実際に設計したものがきちんとできているかを確認していきます。以下、一番上から説明していきます。
まずは燃費目標の策定ですが、各国の規制、インセンティブ、競合他社車との競争力等の切り口から決められることが多いです。次の車両システムの課題定義と各部品への目標値の割り付けでは燃費に影響するパラメータのうち、どの性能がどのくらい上がったらどの程度燃費が向上するはずという燃費改善への効果代をシミュレーションを用いて求めます。現実解がありそうなところを見定めて、各部品への目標値の割り付けが決まります。最初の燃費の目標値が厳しいと、各コンポーネントへの要求値も当然厳しいものとなります。ここで効果代の見積もりに誤差があると後工程に影響が大きいため、慎重にシミュレーションを行って算出していきます。
次に車両制御課題の定義と車両制御構想では前工程の燃費検討で行った各コンポーネントの動かし方を達成するにはどのような制御ロジックを組めば良いかというところを考えて、構想を立てていきます。そしてその構想に基づいて制御ロジックの設計と作成を行っていきます。社内でモデルベース開発の知見が蓄積されていくと、前工程の車両システムの課題定義のフェーズから精度のよい車両のモデルやコントローラのモデルを使うことができ、そのモデルをベースに制御のロジックも設計できるため、これらの工程が効率化できるようになっていきます。もちろん、適応する車両が異なるのが普通ですので、各コンポーネントのモデルなどの作り直しや、各部品の開発が進むにつれて各部品のモデルの作り直しが発生し、コントローラの設計し直しやシミュレーションを繰り返し行っていくことになります。
次はオートコードでロジック作成を行い、制御ロジックの単体検証を行います。ここでは主にMILSやSILSを用いてロジックが想定どおりの動きであるか、通常では想定されない範囲の入力が入ったときに異常な動作がないかを確認していきます。ロジックの構成から必要な入力条件を定義し、パソコンでシミュレーションを繰り返し行い、各制御ロジック単体での動作を保証していきます。
その後、作成した各ロジックをつなぎわせてコントローラ全体の挙動を確認していきます。ここではMILS/SILSだけでなくHILSも用いて検証が行われるのが一般的です。MILS/SILSの方がシミュレーション一回当たりにかかる時間が短い傾向ですので、MILS/SILSで確認するものとHILSで確認する項目を切り分けて、相対的にMILS/SILSで確認する項目に対してHILSで確認する項目を少なくすることでなるべく効率的に開発をしていきます。
次に各部品の台上ベンチでの単体検証を行った後、実際の車両をシャシダイナモやテストコースで走らせることで車両レベルでの達成度の評価を行います。車両に組み合わされた結果、各部品のばらつきの誤差が蓄積し、システムに組み上げた後の各部品のふるまいがこれまで台上ベンチで想定してきたものと少し異なる場合があります。燃費性能開発においてはシャシダイナモ上での実験結果とシミュレータでの実験結果を突き合わせて、シミュレータ側を補正し、制御コントローラの微調整を行っていきます。特にエンジンのトルクの出方や燃料消費量などの過渡的な動きは台上の結果と異なることも多く、実車での結果をベースとして調整が入ります。
最後の燃費の達成度の評価は最終的には燃費の認証試験によって評価されます。認証試験が最後の難関となります。
あとがき
今回は技術的なコラムとして自動車開発へのモデルベース開発の適用について記事にしてみました。モデルベース開発により開発中の手戻りが減少し、設計品質が向上すると考えております。既に自動車業界では一般に普及しているモデルベース開発ですが、一口にモデルベース開発といっても、開発の対象は何なのか、開発フェーズのどこに適用するのかというところで、やり方も規模感も異なりますので、小規模に導入できるような部分から自動車業界以外にもモデルベース開発が普及していくものと考えています。
ブルースカイテクノロジー（株）は20年から30年以上自動車業界で働いてきた人員が多数を占める、自動車の電動化および関連技術に特化した特異なコンサルティング及びエンジニアリングサービス会社です。
電動車両の開発・設計、車両の動的評価、分解調査、車両制御、モータ制御、リチウムイオンバッテリの研究開発や生産ラインの立ち上げといった専門的なご依頼はもちろん、各自動車コンポーネントの電動化コンサルティングや、新素材の電気自動車への適応コンサルティングまで、お客様のニーズに合わせたサポートが可能です。