マルチコアマイコンへの対応で進化するAUTOSAR Classic Platform（前編）：AUTOSARを使いこなす（19）（3/3 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第19回では、AUTOSAR Classic Platformにおけるマルチコアマイコンへの対応について解説する。

[櫻井剛，MONOist]

10年前に始まった自動車制御分野へのマルチコアマイコンへの導入

　自動車の制御分野でもマルチコアマイコンに手が届きやすくなった頃（10年くらい前でしょうか）には、「思ったよりも性能が出ない、コア数が2倍になっても、処理能力を1.4倍に持っていくのですら一苦労だ」というお話をよくお聞きしました^※5）。実際、もともとシングルコア上で動作していたものを、複数のコアに分散して並列処理させようとしても、あらかじめ並列化しやすい処理内容やアーキテクチャになっていなければ、性能向上の限界はすぐにやってきます。

※5）当時、それまでRTOSをお使いではなかった方々からは、ため息交じりに「OS側でマルチコア上でのアプリの実行を最適化してくれるようにならないものかね？」というお言葉を何度もいただきましたが、筆者が所属するイーソルの「eMCOS」のような、マルチコアでもシングルコアと同様なプログラミングを可能にするものは、答えとまでは言わずとも有効な手段にはなり得るでしょう。

　アプリケーションに関しては並列化ツール^※6）を用いて解決／改善できる場合もありますし、そもそも、複数のシングルコアECUで動作しているソフトウェアを、1つのマルチコアECUに統合するような場面であれば、影響は小さくできるよう見えるかもしれません。しかし、BSWのサービスを利用しているのであれば、BSW側の対応状況に左右されてしまいます^※7）。

※6）例えば、モデルベース並列化ツールの「eSOL eMBP」など。

※7）もちろん、BSWサービスが各コア上で独立に提供されている場合は別です。これは、ハイパーバイザー（Hypervisor）を用いたECU統合の代表的なパターンの1つです。なお、ハイパーバイザー上に同じBSWセットを複数インスタンス搭載する場合、※2）でご紹介した、マルチコアでの改変権や保証の範囲、同一BSWの複数回使用時におけるライセンスの扱いと同様の議論があります。ただ、少数コアのマルチコアからメニーコアへの移行やECU統合が進んでいくにつれ、事情も変わっていくことでしょう。BSWベンダー側としても、n個のECUが1個に統合されることで、ライセンス売り上げがn分の1になり、品質リスクとサポート工数がn倍になるようなビジネスモデルでは、当然ながら事業継続が難しくなります。

R4.4.0とR19-11におけるマルチコアへの対応

　R4.4.0の「MCAL Multicore Distribution」では、MCAL（Microcontroller Abstraction Layer）のBSWモジュールのサービスを他のコアから利用できるように、多くのMCAL API（主にI/O関連：Adc、Dioなど）が同期型（synchronous）から非同期型（asynchronous） に切り替えられました。また、マルチコアマイコン上でMCALを使用する場合、複数コアからAPIを利用できるか否か、APIの実行がどのコアで行われるか、周辺機能を複数コアに割り付けることができるかなどの、MCALとしてのマルチコア対応の有無やその方式の把握が必要となります。そこで、その表現方法（EXP BSW Distribution Guideのマルチコア対応能力（MCAL Multi-Core Type）の分類）が追加され、併せてパーティションへの割付可否などの情報をAUTOSAR XMLに記述できるようになりました。

　また、ハードウェアの実行速度や構成が変わったり、搭載するソフトウェアの追加、変更があれば処理実行スケジューリングも変わったりしてしまいます。その場限りのスケジューリング最適化やタイミング保証とするのではなく、変化に対して影響を受けにくくする^※8）ための手法の一つとして「LET（Logical Execution Time）」への対応もR4.4.0で行われました。

※8）「変化に対して影響を受けにくくする」という表現は、「設計や実装、Configuration、そして、検証内容の広義の再利用」と言い換えることもできます。

　R19-11で追加された「BSW Multicore Distribution」は、通信関連のBSW群が対象となっています。処理負荷の分散を可能にしつつもコア間のやりとりを極力小さくするという方針のもとに、PduRを中心として、その上位レイヤー（BusMirroring、Com、Dcmなど）や、その下位レイヤー（CAN stackなどの通信関連BSW群）を、各コアに分散配置できるように拡張したものであり、PduRをはじめとして多数のBSWが影響を受けています。

　また、BSWモジュールの動作を他のコアから制御できるようにするために、関係するAPIは同期型（synchronous）から非同期型（asynchronous）に切り替えられています。さらに、これに関連して、Basic Software Multicore Library（Bmc）が追加されています。これは、コア間を調停するための、flag操作やstore／load／exchangeなどの基本的な演算を行うリエントラントな関数群を含みます。

後編に続く

　思ったよりボリュームが大きくなってしまいましたので（「またか」といわれてしまいそうですが）、今回はここまでとします。次回は、後編としてR20-11における「CP Flexibility」の登場の背景や、変更内容とその意味合いをご紹介いたします。

　アプリの小さな変更が全体に影響を及ぼし得ることや、インテグレーターの負担増大（規模増大で全体把握が一層困難になっていくこと）、大規模ECUではRTEのコード生成やビルドにかかる時間が極端に大きくなることなど、今のECUソフトウェアのインテグレーション作業や分散開発での課題^※9）、それらがどう解決されるのか、そして、その解決にあたり「ユースケースの想定」がどのように影響してくるのか（「ユースケースの想定」を外れた場合の結末も含む）などについて述べたいと思います。

※9）筆者が講師を務めている「AUTOSAR Classic Platform（CP）入門トレーニング」でも、インテグレーターの負担がもともと大きいことをお伝えしてきましたが、今回の記事執筆を機に、マルチコアの大規模ECUでの追加負担を整理しているところです。次回の後編ではその一部をご紹介します。