検索
連載

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

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

Share
Tweet
LINE
Hatena

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

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る