日経 xTECH Special 日経 xTECH 日経 xTECH Special

MBDは部分最適から全体最適へ一貫した活用で複雑化に対応

ADAS(先進運転支援システム)や自動運転などを背景に、クルマの電子制御システムはさらに複雑化し、その開発手法にも根本的な見直しが求められている。モデルベース開発(MBD)はその流れの中で注目されるようになったが、既に導入している開発現場でも部分的な活用にとどまっていることが多い。しかしシステムの複雑化は、部分的なMBD活用ではもはや追いつかないレベルに達している。開発プロセス全体でのMBD適用を各社が模索し始める中、細かい工程まで含めて一貫したMBDのソリューションを提供しているのがETAS(イータス)だ。

 車載を含め組み込みシステムは、開発作業で使用するプラットフォームと、開発したプログラムを動かすプラットフォームが異なるのが一般的。そのため、作ったプログラムをその場ですぐに実行することはできず、ターゲットとなるプラットフォーム向けに移植しなければならない。ターゲットとなるプラットフォーム、すなわちシステムに搭載する実機が未完成の段階ではテストできず、完成していたとしてもプログラム完成までにコンパイルとテストを何度も繰り返すことになり、大きな工数がかかる。

 MBDはその組み込みシステムの根本的な問題の解決に有効な手段として注目されるようになった。プログラムで行いたい制御の流れを、モデルを使った図で記述し、十分な検証を行ったうえでソフト開発に移り、そこでも検証を繰り返して完成度を高めてから実際のコードを生成する。制御プログラム完成後は実機に書き込み、制御対象の動きを再現するシステムと接続して検証し、最終的にはシステム全体を実車で検証する形で完成させる。

 MBDによる大きな効果の1つは、システム開発の個々のステップごとに検証を完結できる点だ。後工程で不具合が見つかってもその前工程まで戻る必要がなく、不具合の原因と影響範囲を限定できると同時に、ムダな開発や作業のやり直しを防げる。

 またMBDによる検証の中には自動化できるものもあり、無人で24時間シミュレーションを繰り返すことが可能だ。特に車載システムの場合は、さまざまな路面や天候の状況に応じたテストを実車ですべて行うのは限界があり、仮想環境でシミュレーションできる意義は大きい。実車走行テストには危険を伴うものもあり、ドライバーの安全確保という点でも効果的だ。

 MBDは、モデルで記述された制御を検証するMiL(Model-in-the-Loop)、そのモデルから作った制御ソフトウェアを検証するSiL(Software-in-the-Loop)、実機に書き込まれた制御ソフトウェアの一部分の機能を検証するFiL(Function-in-the-Loop)、実機に書き込まれた制御ソフトウェアを制御対象の動きを再現するシステムと接続して検証するHiL(Hardware-in-the-Loop)などがあり、ETASはこのMBDの適用に必要な一連のツールを取りそろえている。

 MBDは単体ツールの利用でも効果をもたらすが、クルマの電子制御システムが高度に複雑化する中では限界が見えつつある。そこでETASは開発プロセス全体をMBDでカバーするソリューションを打ち出している(図1)。

図1:システム開発のV字サイクルと、それぞれに対応するETASのMBDソリューション
[画像のクリックで拡大表示]

 特に計測・適合ツール「INCA」には定評があり、INCAを中心に制御設計から実装、テストや診断までの一連の工程をそれぞれカバーするツールを、統合的に扱えるようになっている。

 その他にもクルマ全体をモデル化する「LABCAR-MODEL」などがあるが、開発プロセス全体のカバーという中で特に象徴的なのは、モデルベース適合ツールの「ASCMO」だ。

パラメーターの最適値探索を自動化し、実機テストを76%減

 開発の最終段階では実機を使い、パラメーターを調整しながら最適値を見つけていく適合作業が必要になる。しかしハイブリッド電気自動車(xEV)などクルマの電動化や排気規制強化などで、適合に必要なパラメーターが急増しているのが実情だ。パラメーターの増加はその組み合わせをさらに複雑化させ、最適値を見つける作業を一層難しくしている。

 ASCMOはその適合作業を支援する。適合作業では通常、実機を使ったテストベンチで計測を行い、制御パラメーターの変更を繰り返しながら最適値を探索する。ASCMOは計測データから制御対象物のモデルを作成し、PC上で制御パラメーターの最適値探索を自動化し、テスト工数の削減を図る。

 ASCMOがクローズアップされるようになった背景にあるのが、欧州で始まった実車走行による排ガス試験「RDE」だ。より実際に近い走行状態でのテストを義務づけ、適合作業は複雑化している。日本でも2022年には同様の義務化が始まるとみられ、適合作業の改善がテーマになりつつある。

 ASCMOでは「どのパラメーターが、何に効くかを解析することができる」(ETASの技術部シニアマネージャの磯田一成氏)。複雑に絡み合ったパラメーターの依存関係を解きほぐし、テスト担当者に提示することで効率化を促進する。同社によるとASCMOを活用した実験計画法の導入により実機テスト工数76% 減を果たした事例もあると いう。

 制御対象物のモデル化と最適化機能により、PC環境上で適合パラメーターの最適値探索を自動で繰り返すことができる。「例えば燃費の最大化を目指した適合作業に活用すれば、燃費を究極まで高めることも可能」(磯田氏)ということだ。

モデルを外部へ出力して再利用

 ASCMOで作成したモデルは、外部へファイル出力し他の環境で再利用することができる。そのため、コンポーネント単位でモデルを作成した場合、適合に使用したモデルを他工程のMILS/HILSで再利用しシミュレーション精度向上も図ることができる。

 ASCMOのもう1つの特徴は、物理式にしにくい制御対象も、入出力の情報を統計処理してモデル化できること。例えばエンジンの燃焼は化学反応を伴う現象のため、簡易物理モデルは精度、詳細物理モデルは実行時間に課題がある。ASCMOではこれらも入出力の情報から統計モデル化し、精度よく高速でシミュレーションできるようにする。「Bosch 製エンジン制御ユニットを使用する場合、ASCMOから出力したモデルを組み込むことができ、当該ファンクションの適合作業自体が不要になるケースもある」(磯田氏)。

走行中の車両から集めたデータをプログラムの改善に生かす

 クルマの電子制御システム開発で、現在最もホットなテーマと言えば「自動運転」に他ならない。ADASから発展し、自動運転の実現を各社が目指す中、MBDにもそれを支援する仕組みが求められている。ETASがそのニーズに応えるために用意するソリューションの1つが「COSYM」だ。

 COSYMは、MBDの各工程で使うモデルやテストを共通化するための基盤。自動運転のシステムをMBDで検証するためには、クルマはもちろん、歩行者や障害物、天候や路面状況など、クルマを取り巻くすべてをモデル化しなければならない。しかし膨大なモデルを1つのベンダーが作ることは現実的に不可能だ。そこでCOSYMは、各社が開発したモデルを共通で使えるように結び付ける機能を提供する。実世界に近い3Dの環境で、可能な限りシミュレーションを行えるようにする。

走行中の実車データを集めて活用

 自動運転の開発ではモデルだけでなく、必要なテストの量も膨大なものになる。同社はそのためのソリューションとして、PLCS(Product LifecycleConnectivity Solution)を近く投入する予定だ。緊急ブレーキなどを搭載したレベル2の自動運転車から実際の走行データを取得し、意図しない動作を拾い上げて仮想環境に落とし込む。それを修正するパッチを開発し、クルマに書き戻すというサイクルを実現する。「何億kmも実車で走行するのと同等のテストになり、必要なインシデントを十分集められるようになる」(ETAS 名古屋オフィス技術部シニアマネージャの石川誠司氏)わけだ。

 PLCSのベースは、英国で2016年に始まった自動運転車の開発プロジェクト「MOVE_UK」。同社の筆頭株主であるドイツBoschがこのプロジェクトのメンバーであり、そこで蓄積したノウハウをソリューション化する。

 システム誤作動時の影響を具体的に検証するには、誤作動した際の再現映像も必要だ。同社はこのテーマにも、実世界の1つの映像について天候や時間帯などのパラメーターを変え、さまざまなバリエーションの映像を再現するシステムの開発に取り組んでいる。これも実車テストの削減とそれによる開発効率化を目指したものだ。

ビッグデータ化に対応

 しかしインシデントや誤動作時の再現映像が、実車走行に頼らずとも自動的に蓄積されるようになると、データが膨大になり、使い勝手の低下が懸念される。その問題に対応するために同社が用意しているのが、ビッグデータ処理のソリューション「EADM 」だ。

 EADMは、分散型のストレージと、ビッグデータ処理で定評のあるフレームワーク「Hadoop」をベースとする。さまざまなインシデントや映像を集約するようになるとデータはすぐにペタバイト級に達するが、EADMは分散保存されているデータを移動することなく、その中から検索条件に合う必要な情報を高速で抜き出し、自動運転の開発で活用できるようにする。EADMはMOVE_UKの中で一部既に使われている。欧州の先進的な取り組みをソリューション化したものなのである。

仕様策定段階でセキュリティ確保、ECUの暗号鍵管理などインフラも提供

 一方、クルマの電子化や自動運転は、クルマに「セキュリティ」という新たな問題をつきつけている。この点でも同社は「escrypt 」のブランドでソリューションを提供しているが、そのアプローチもMBD同様、開発プロセス全体をカバーする(図1、右下)。

 典型的なソリューションが、仕様策定時のリスク分析だ。開発したシステムに後でセキュリティ機能を施しても、もともとの仕様自体が穴だらけでは意味がない。そこで同社では、初期のシステム設計の段階で脆弱性を抽出するコンサルティングを提供している。

 仕様を策定し、コーディングが始まった段階では、コードレビューや侵入テストも行う。設計段階でセキュリティを十分考慮していても、「開発段階で技術者がデバッグのために付け加えた機能が、後で攻撃対象になったりすることもある」(サイバーセキュリティ本部長の後藤朝之氏)からだ。

 完成したクルマを外部からの攻撃から守るソリューションには、車載システム用のファイヤーウォール「CycurGATE」やECU間の通信を暗号化する「CycurLIB」、車載マイコン用のセキュリティスタック「CycurHSM」、ECUで動作する不正侵入検知防御ソフトウェア「CycurIDS」などがある。1台のECUが1つの機能を担うレベルから、複数のECUが協調して1つの機能を実現するようになる流れの中では、ECU単体のセキュリティだけでなく、ECU間の通信のセキュリティも担保する必要がある。そのための機能を提供するソリューション群だ(図2)。

図2:車載システム向けのセキュリティソリューション群。クルマを「車内」と「車外」から守る
[画像のクリックで拡大表示]
「車内」と「車外」からクルマを守る

 これらはいずれもクルマの「車内」に搭載されるものだが、同社はさらにクルマのセキュリティを「車外」から守るインフラも提供している。

 1つは、暗号鍵管理のホスティングサービス「CycurKEYS」と「プロダクションキーサーバー」。ECUを工場で量産する際、暗号鍵の管理が不十分だと、プログラムの不正書き換えなどの攻撃に使われかねない。プロダクションキーサーバーはその対策として、複数の暗号鍵生成、書き込み、紐付け、消去を厳密に管理する機能を提供する。

 スマートシステムの一部としてスマートフォンで車両のドアロック開閉やエンジン始動をNFC、BLE 経由でセキュアに制御する「CycurACCESS」やモニタリングを行うバックエンドシステム「CycurGUARD」も、クルマを車外から守る機能の1つだ。CycurGUARDは、セキュリティに異常が発生した場合にその通知を受け、最適な対処を行うための情報提供と連携を実現する。

 米国ではクルマの侵入検知機能の義務化に向けた審議が進むなど、クルマのセキュリティ対策は今後グローバルレベルでテーマになることは間違いない。その時代を見据えて「開発だけでなく、生産や運用保守、廃棄まで、クルマのライフサイクル全体をセキュリティ被害から守る機能を提供する」(後藤氏)のが、同社の車載内外システム向け包括的セキュリティソリューションの特徴だ。



お問い合わせ
  • イータス株式会社

    〒220-6217 横浜市西区みなとみらい2-3-5
    クイーンズタワーC棟17F

    https://www.etas.com

    TEL 045-222-0900(代表)

    FAX 045-222-0956

    E-mail:sales.jp@etas.com