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

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

[櫻井剛，MONOist]

AUTOSAR CPにおけるマルチコア対応の歴史

　AUTOSARが量産適用され始めた当初（2010年前後）は、ECUの多くはシングルコアマイコンを採用していました。ですから、AUTOSAR CPの開発も、シングルコアマイコンを（暗黙のうちに、でも自然に）想定していました^※2）。

　マルチコアマイコンを使う場合でも、当時は、AUTOSAR BSW群やそれらのサービスを利用するアプリケーションを1つのコア（AUTOSAR Core）に押し込めてしまい、残りのコア（non-AUTOSAR Core）は独自OSやスケジューラを使用する、というやり方が主流でした。

※2）このことは、BSWスタック（同じ機能グループのBSWモジュール群）での上位−下位モジュール間インタフェースAPIが、同期型（synchronous）を基本としていることに現れています。なお、異なるコア（あるいは同一コア上の異なるパーティション）をまたがるコールの際には、現在はRTE（Runtime Environment）内のSchM（BSW Scheduler）モジュールが提供するサービスが用意されています（SchM_Call API）。ただし、各BSWのSWS側では、SchM_Callを用いた場合の異常ケースや性能に対して、十分な考慮がなされているとは限りません。

　その後、ECUに要求される機能が高度化し、性能要求も高まるにつれ、マルチコアマイコンが使用されるケースも増えましたので、AUTOSARでもマルチコアへの対応は進められてきました。

　しかし、R4.4.0までは、実質的にはOSがマルチコア対応しているだけで、BSWとそのサービスを利用するアプリケーションはどこか1つのコアに押し込めてしまうしかありません。どうしても、BSWサービスを各コアでそれぞれ使いたいという場合には、各社固有の拡張を行うしかない^※3）、というのが実情でした。

※3）場合によっては、BSWなどの製品の保証が失われることを覚悟の上で、適切に改変権を得て、改造するという対応も行われています。なお、マルチコアマイコンの利用が広まった初期の頃には、改変権や保証の範囲、複数コアに同一BSWを複数回使用する場合のライセンス（1ライセンスでどこまでがカバーされるのか）についての考慮が不十分な場合も少なくありませんでした。BSWベンダーがユーザー側ユースケースの詳細をお聞きするのを嫌うユーザーは今もまだ少なくないと耳にしていますが、安全やライセンス（ひいては事業継続）などの観点から必要なことであることは、ぜひともご理解いただきたいところです。

　AUTOSAR CPでのマルチコア対応の歴史をまとめると、以下のようになります。

• R4.0.1（R4.xの初代）：AUTOSAR CPとしてマルチコア対応開始（Multi Core Architecturesコンセプト）
• R4.0.3：それ以前は別冊となっていたSWS Multi Core Os（MCOS）を、SWS Osに統合（それまでのSWS Osはシングルコア用Osに関する記述のみ）
• R4.1.1：EXP Multi Core Guide追加（BSWのマルチコア対応の手法として、SchM_Callによるパーティション間通信や、master-satellite approach（実装方法は標準化対象外／実装依存）などを提示）
• R4.2.1：ASIL QM Protectionコンセプト導入（ASIL／QM混在への対応強化：ASIL BSWとQM BSWの混在対応のためにEXP Multi Core Guideを内容拡充の上でEXP BSW Distribution Guideに改称、Trsted Applicationに対しても保護を掛けられるようにするなど）、EcuM fixedをマルチコア対応のために拡張（しかし、EcuM fixedはその後R4.4.0で廃止され、EcuM flexに一本化）
• R4.4.0：MCAL Multicore Distributionコンセプト導入（EXP BSW Distribution GuideにMCALのマルチコア対応能力の分類（MCAL Multi-Core Type）の定義を追加、AUTOSAR XMLにもパーティション割り付け可否などの情報を記述できるように変更、一部の同期APIを非同期に変更）。LET（Logical Execution Time）対応のためのコンセプトも導入
• R19-11: BSW Multicore Distributionコンセプト導入（後述）
• R20-11: Classic Platform Flexibilityコンセプト導入（EXP CP Software Cluster Design And Integration Guideline追加）（後述）

　2010年代中頃（R4.3.0前後）からは、CPでのマルチコアへの対応を一歩進めるための議論が始まりました^※4）。現在のWG-CP-MCBDワーキンググループ（Working Group Classic Platform Multi core BSW distribution）です。

※4）なお、標準化活動ですので、最初のステップは当然「ユースケース」の議論です。一般的には、標準化に値するユースケースなのか（それなりの利用が見込めるのか）が主に話し合われます。なお、そこで使用するであろうメカニズム／アイデアの提案も行われることはありますが、「ユースケース」が示せないものは、相手にされない場合もあります。これが欧米での標準化の一般的な順序（議論のお作法）ですが、日本では「プロダクトファースト」「メカニズムファースト」の傾向が強い場合もありますので、議論の際には違和感が生じ得ます（ただ、この違和感を理解することは、実際にその場に出向いて、身をもって体験しないと難しいのかもしれません。少なくとも筆者は、ユースケース提示の必要性を国内の方に説明する際、いつも苦労していますし、実際のところ、あまり成功しているとはいえません）。