5 <自動車応用>車載システム向けのドメインごとの特徴とマルチコア対応

車載システムは、提供する役割により、ADAS(先進運転支援システム)/AD(自動運転)系や制御系など、いくつかのドメインに分類できる。現状の開発では、開発者はドメインの違いをあまり意識しないまま、モデルベース開発を行ったり、ハンドコードされた過去の資産を活用したりしている。

シングルコアの上でシステムを動かす場合は、ドメインの違いを意識しなくても、開発は順調に進んだ。しかし、従来の意識のまま、マルチコアやメニーコアのシステム開発に臨むと、さまざまなトラブルに遭遇する。例えば「期待した性能を引き出せない」、「リアルタイム制約を満たせない」などのトラブルである。このような問題を回避するためには、ドメインごとに異なるハードウェアアーキテクチャやソフトウェアの処理特性の理解が欠かせない。

本章では、まず車載システムのドメインごとの特徴について整理し、その後、各ドメインのシステムをマルチコアやメニーコアへ対応させる際に考慮すべき事項について説明する。

  • 本章の対象読者
    • 知識・経験:レベル2(初級者)
    • マルチコアの知識あり、車載システムの開発経験少ない
    • プロセス:要件定義、設計、実装
    • ドメイン:自動車
    • キーワード:コデザイン、ヘテロジニアスマルチコア、ホモジニアスマルチコア、リアルタイム制約
  • 本章を読んで得られるもの
    • 車載システムのドメインごとのハードウェアアーキテクチャの違いが分かる。
    • 車載システムのドメインごとのソフトウェア処理特性の違いが分かる。
    • マルチコアやメニーコアへの実装を前提とした車載システムの要件定義や設計指針の立案が、スムーズに進められるようになる。

本章をはじめ、車載システムの説明の中でよく登場する略語を以下に記載する。

  • AD(autonomous driving):自動運転
  • ACC(adaptive cruise control):車間距離制御
  • ADAS(advanced driver assistance systems):先進運転支援システム
  • AEB(advanced emergency braking):衝突被害軽減制動制御
  • EV(electric vehicle):電気自動車
  • FCW(forward collision warning):前方衝突警告
  • LDW(lane departure warning):車線逸脱警報
  • LKA(lane keeping assist):車線逸脱防止支援
  • IVI(in-vehicle infotainment):車載情報通信システム
  • TSR(traffic sign recognition):交通標識認識

5.1 ドメインによるハードウェアとソフトウェアの基本構造の違い

車載システムは、その特徴によりいくつかのドメインに分類できる。ドメインには最適なソフトウェアとハードウェアの組み合わせが存在する。ここではソフトウェアを論理層、ハードウェアを物理層ととらえ、それぞれの基本構造を述べていく。

  • ソフトウェア(論理層)
    • ADAS/AD
    • エンジン/EVモータ制御
    • その他(コネクテッド/IVIなど)
  • ハードウェア(物理層)
    • ヘテロジニアス(マルチコア)SoC
    • ホモジニアス(マルチコア)SoC
    • ヘテロジニアスSoC with セキュアゾーン
    • マルチコア/メニーコアMCU(マイクロコントローラ、汎用品)
図 1: 基本構造

5.1.1 ADAS/AD系の基本構造

ADAS/AD処理には、センシング処理や識別処理、プランニング処理、アクチュエータ処理などがある。これらを同時に処理するため、タイプの異なるプロセッサコアを搭載したヘテロジニアスSoCを使用する。

  • 論理層の特徴
    • センサからの識別処理
    • 車両制御
    • 高負荷制御
  • 物理層の特徴
    • 画像処理
    • 電波処理
    • ディジタル信号処理
    • GPU処理
図 2: ADAS/AD系ドメインの基本構造例

5.1.2 制御系(エンジン、EVモータ)の基本構造

制御系処理(エンジン、EVモータ)には、リアルタイム処理が必須である。ハードウェア処理とソフトウェア処理を組み合わせてリアルタイム制約をクリアする。リアルタイム処理を行うこと、および安全機構を組み込むことを目的とするため、高性能なSoCではなく、ロックステップ機構などを持つ汎用品のマルチコア/メニーコアMCUを使用する。

  • 論理層の特徴
    • 回転制御
    • 内燃機関制御
    • リアルタイム制約
  • 物理層の特徴
    • ロックステップ機構
    • 複数のセンサ入力
    • 耐熱
図 3: 制御系ドメインの基本構造例

5.1.3 その他のシステムの基本構造

このほかに、IVIやコネクテッドといったドメインがある。特徴としては、車載(車内)の情報通信処理、および車外との情報通信インターフェースを持つ。そのため、さまざまな情報を取りまとめるための各種プロセッサコアを搭載したSoCを使用する。

  • 論理層の特徴
    • 通信ネットワーク処理
    • マルチメディア処理
    • セキュリティ
  • 物理層の特徴
    • ディジタル信号処理
    • セキュアチップ搭載
図 4: その他のシステムの基本構造例

5.2 ドメインによるソフトウェア処理の違い

車載システムは、ドメインごとにソフトウェア処理に求められる要件が異なり、それぞれの特徴に合ったソフトウェアアーキテクチャが存在する。

  • ADAS/AD系
    • 高負荷処理の制御とリアルタイム制御を共存させなければならない。
  • 制御系(エンジン、EVモータ)
    • 厳格なリアルタイム制御が必須となっている。

5.2.1 ADAS/AD系のソフトウェア処理

5.2.1.1 ADAS/AD系のソフトウェア処理の概要

ADAS処理では、人が運転してそれをソフトウェアがアシストする。AD処理では、ソフトウェアが運転してそれを人がアシストする。運転主体は異なるが、ADAS処理、AD処理ともにソフトウェアは、認識処理、認知処理、判断処理、制御処理から構成される。

ADAS/AD系の認識処理と認知処理には、高い処理性能(高負荷処理)が要求される。

ADAS/AD系の制御処理には、「アクチュエータに指示を出す」などのリアルタイム処理が要求される。

図 5: ADAS/AD系のソフトウェア処理

5.2.1.2 ADASのソフトウェア処理構成(ACC・AEB機能)

ADASが人の運転をアシストする機能は、非常に多岐にわたる。ここでは、カメラを使用したACC・AEB機能を例に説明する。

ACC機能の基本動作は、道路の白線を検出しながら、前方の車両を検出して追走する。前方の車両が検出されない場合は、自走で速度を一定に保ちながら車の挙動を制御する。

AEB機能の基本動作は、車両前方に突然飛び出してきた物体に対し、衝突による衝撃を軽減するため、ブレーキを制御する。

これらのソフトウェア処理は、白線抽出処理、前方車両抽出処理、(白線に沿った)パスプランニング処理、自走処理、画像処理、アクチュエータ処理から構成される。

図 6: ACC・AEB機能のソフトウェア構成例

5.2.1.3 ADASのソフトウェア処理に求められる要件

白線抽出処理、前方車両抽出処理、パスプランニング処理は、前回の処理結果に今回の処理結果を重畳する場面が多い。場合によっては識別する物体が極端に増え、突然、高負荷の状態になることもある。このため、リアルタイム処理よりもむしろ、高負荷時に破たんしないように、いかにして適切に処理(タスク)をさばいていくかが重要になる。

自走処理やアクチュエータ処理は、車の挙動を決定し、目的のタイミングで必要な指示を出さなければならないので、リアルタイム処理が重要になる。

図 7: ADASのソフトウェア処理に求められる要件

5.2.1.4 ADのソフトウェア処理構成

AD処理では、ソフトウェアが運転を行う。その多くは、認識処理、認知処理、判断処理、制御処理から構成される。

認識処理では、主にカメラやLiDAR(light detection and ranging)、ミリ波レーダなどを利用して物体を認識する。

認知処理では、認識物体情報の統合処理(フュージョン)、GPSなどから入力される地図情報と認識物体情報の統合処理、自車周辺の移動体の行動予測、経路・空間地図やリスク地図の作製などを行う。

判断処理では、運行計画処理や軌道制御処理などを行う。

制御処理ではアクチュエータ群に指示を出し、車両の挙動を制御する。

図 8: ADのソフトウェア構成例

5.2.1.5 ADのソフトウェア処理に求められる要件

認識処理、認知処理、判断処理については、各種情報の統合処理、地図作製、運行処理など、扱う処理量がADASと比較にならないほど多くなる。

試作段階でそれぞれの処理量を確認し、どのような負荷分散方式を量産設計に盛り込むかを検討することが望ましい。

制御処理は、車両の制御指示を行うため、リアルタイム処理が要求される。

図 9: ADのソフトウェア処理に求められる要件

5.2.2 制御系のソフトウェア処理

制御系(エンジン、EVモータ)のソフトウェア処理には、厳格なリアルタイム処理が要求される。エンジンやモータの回転数に応じて、適切に制御することが求められる。

5.2.2.1 エンジン制御のソフトウェア処理構成

エンジンの回転数に応じて吸気→圧縮→燃料噴射→点火を行う。

それぞれの制御処理が、V型エンジン、直列型エンジン、気筒ごとに複雑にからみ合う。

図 10: エンジン制御のソフトウェア構成例

5.2.2.2 EVモータ制御のソフトウェア処理構成

EVモータ制御には、エンジン制御のような内燃機関を制御するための処理は存在しないが、低速域から高速域(毎分0~18000回転くらい)までモータの回転角速度制御をシームレスに行う必要がある。

回転角速度を処理するためのタイマ割込みは、μsオーダの処理となる。

図 11: EVモータ制御のソフトウェア構成例

5.3 ドメインごとの並行処理とマルチコア/メニーコア対応

これまで、車載システムはドメインごとに特徴ある性質を有していることを述べた。以下では、これらの性質を押さえながら、マルチコア/メニーコアに対応していくための指針を述べる。

5.3.1 ADAS/AD系の並行処理とマルチコア/メニーコア対応

 1.2.1 で示したADASのACC・AEB機能のソフトウェア処理を例に、マルチコア/メニーコア対応の構成例と指針を述べる

5.3.1.1 SMP(symmetrical multi-processing)OSを導入した場合

 1.2.1 で示したように、ADAS処理は、

  • 高負荷処理:高い負荷性能が求められる処理
  • リアルタイム処理:リアルタイム制約を満たすことが求められる処理

に分けられる。それぞれの処理は、別々のプロセッサコアに割り当てる。

高負荷処理については、複数のプロセッサコアを割り当て、SMP OSを導入して負荷分散を行う(SMP OSがタスクを複数コアへ自動的に振り分ける)。

リアルタイム処理に対してリアルタイムOS(RTOS)を導入するかどうかは、接続ペリフェラルや他のプロセッサコアから入ってくる情報をどのくらいの速さでさばかなければならないか(ソフトリアルタイム性)に基づいて決定する。ベアメタル(OSなし)で十分の場合は、無理にリアルタイムOSを導入する必要はない。

マルチコア/メニーコア対応の構成例は、 図 12 のようになる。

図 12: ACC・ABE機能のマルチコア/メニーコア対応

5.3.1.2 SMP OS導入時のタスクの分化について

SMP OSを採用することで、タスクをそれぞれのコアへ自動的に振り分ける負荷分散のメリットを享受できる。このときのタスクの分化(分割)は必要最小限に留めることが重要。タスク数は「割り当てコア数+せいぜい1~2」となることが望ましい。

コア数以上にタスクを分化しても、コンテキストスイッチやタスク状態遷移のオーバーヘッドなどにより、性能が頭打ちになることが知られている。関数コールの方が、必要なレジスタ情報をスタックに積むだけなので、当然、処理は早い。タスクを増やししすぎると、逆に性能は出なくなる。

タスクの分化の際には、採用したOSのタスクスイッチングオーバーヘッドまで考慮して、タスク処理時間を設計しておく。こうすることで、タスクのデッドラインに抵触せず、OS導入のメリットを最大限享受できる。ただし、複数コアになることでデッドライン設計や検証作業はかなり難しくなる。

組込みシステムで使用するOSは、それぞれ性格や特性が異なるので、OSを採用する前に調査を行い、その特徴を把握してから導入することを推奨する。

5.3.1.3 SMP OSを導入しない場合

SMP OSを導入しない場合は、各処理をタスク化し、それらを人手で(または、ツールの支援を受けながら)コアへ割り付ける。コア数が、そのままタスク化した処理数になる。

人手で割り付ける場合、プロセッサ資源を効率よく使用できるかどうかは、設計者のスキルに依存する。

SMP OSを採用する、採用しないにかかわらず、マルチコア・メニーコアでプロセッサ資源を効率よく利用するためには、設計から検証まで並列化ツールチェーンを利用することを推奨する。人海戦術には限界がある。

マルチコア/メニーコア対応の構成例は、 図 13 のようになる。

図 13: ACC・ABE機能のマルチコア/メニーコア対応

5.3.2 制御系の並行処理とマルチコア/メニーコア対応

制御系のソフトウェア処理について、マルチコア対応の構成例と指針を述べる。

5.3.2.1 制御系のマルチコア対応

制御系のソフトウェア処理は、割込み処理、タイマ処理、mainループが基本となる。

リスクを上げないように、またなるべく安全にマルチコアを使用するため、

  • 仕様の分割
  • 割込みの分散
  • フィードバック制御
  • 処理タイミングによる分割

に配慮して、処理を複数コアへ割り付ける。

メモリ参照を可能な限りローカル化する設計、およびコア間におけるペリフェラルのアクセス競合(例えばGPIOなど)を生じさせない設計が前提となる。

資源共有は、スピンロックの発生によって処理が止まる可能性がある。これは、ハードリアルタイムが求められる制御処理では致命傷となる。アクセス競合を発生させないように十分に注意を払って、各コアへメモリやペリフェラルを割り当てる。

5.3.2.2 エンジン制御フローチャート

エンジン制御の基本的なフローチャート例を、 図 14 に示す。

図 14: エンジン制御フローチャート例

5.3.2.3 マルチコア構成例

図 14 のエンジン制御フローを例に、マルチコア対応の構成例を 図 15 に示す。

コア割り当て

  • Core 0:エンジン制御のメイン処理
  • Core 1:回転数割込み処理
  • Core 2:1msタイマ処理
  • Core 3:ダイアグノーシス処理
    • メイン処理のダイアグノーシスは、メイン処理に影響を与えない範囲で別のコアに割り当てることが可能。
図 15: エンジン制御処理のコア割り当て例

5.3.2.4 その他の注意事項

本章では4コアへ割り当てる例を示したが、メニーコアMCUを使用することも可能。

  • 割込み処理が複数ある場合に、Core 1、Core 2以外のコアにも割込み処理を割り当てる(割込み処理負荷分散)。
  • タイマ処理も、同じように複数コアへ割り当てる(タイマ処理負荷分散)

エンジンの気筒ごとにコアを割り当てる案も考えられる。しかし、コアごとの物理特性(クロックのぶれなど)が微妙に異なるため、注意が必要。

  • 上死点、下死点前後の制御処理やクランク角の制御処理などに影響を与え、処理が破綻してしまう可能性がある。

5.4 まとめ

車載システムは、提供する役割により、いくつかのドメインに分類できる。本資料では、組込みソフトウェア開発の立場で、それぞれの特徴について記述した。

マルチコア・メニーコア開発を行うにあたり、ドメインごとに異なるハードウェアアーキテクチャやソフトウェアの処理特性の違いを理解しておくことが重要になる。

ADAS/AD系と制御系のドメインについて、それぞれのソフトウェア処理、およびマルチコア/メニーコアに対応するための構成例や指針を記載した。

5.5 参考文献

  1. 新井 宏;オーム社『自動車の電子システム』,「2章 エンジン制御」、pp.50-53、2014年10月.

  2. 児島 隆生、長田 健一、伊藤 浩朗、堀田 勇樹、広津 鉄平、小野 豪一;「自動運転の高度化を支える知能化技術」、日立評論、

  3. http://www.hitachihyoron.com/jp/archive/2010s/2017/05/pdf/p52-56_10A03.pdf,2017年5月.

  4. 東芝デバイス&ストレージ株式会社;「HEV/EVシステム」、自動車, https://toshiba.semicon-storage.com/jp/application/automotive/ecology/hev-ev.html

  5. Evsmart Blog;「電気自動車の仕組み」、電気自動車 一般, http://blog.evsmart.net/electric-vehicles/how-electric-car-works/

  6. Autoware;「Open-Source To Self-Driving」、Autoware, https://github.com/CPFL/Autoware/

  7. 株式会社ZMP;「ADASの開発に関する基本情報」、自動運転・ADASを知る、https://www.zmp.co.jp/knowledge/adas_dev/

  8. Technical Direct;「次世代車載情報通信システム(In-Vehicle Infotainment system、IVIシステム) スマートドライブによる無限の可能性を開発 未来の新テクノロジーに、ドライブ・イン!」、http://www.technical-direct.com/jp/category/ivi/ 、2013年12月3日.

  9. Technical Direct;「IAA2015レポート:自動車技術の最重要トレンド、コネクテッド・カー」、 http://www.technical-direct.com/jp/category/ivi/ 、2015年10月2日.