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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3.1.1 SMP（symmetrical multi-processing）OSを導入した場合

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

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

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

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

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

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

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 のようになる。

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

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

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

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

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

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

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

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

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

5.3.2.3 マルチコア構成例

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

コア割り当て

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

5.3.2.4 その他の注意事項

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

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

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

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