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

　本稿の執筆開始時点では、関東よりもだいぶ遅いですが、自宅周辺（新潟）も春を迎え桜が満開でした（執筆に手間取り、もう散ってしまいましたが）。皆さんもお楽しみになれましたでしょうか？

　昼休憩で時折散歩に出かけた折に、花粉とコロナを気にしながらも、ちょっとした花見気分を味わうことができました。かと思えば、その数日後の朝には、4月なのに氷点下にまで気温が下がり、クルマのフロントガラスが凍り付き、路面はところどころツルツルに……。

　スタッドレスタイヤからノーマルタイヤに履き替えた方も少なくなかったので、ちょっとした騒ぎです。

　桜の花びら（凍結していなくとも、これを踏んでトルクを掛ければ結構滑ります）が凍った路面に貼りついている中を、恐る恐る歩く、あるいは走らせる……。これも、新潟の春には時折見られる光景です。

　自動運転の技術が進み、うまく対応されればいいですね（運行設計領域（ODD）の設定にも大きく左右されるでしょうけれど……）。

⇒連載「AUTOSARを使いこなす」バックナンバー

AUTOSAR Classic Platformでのマルチコア対応が新たなステージに

　さて、前回ご紹介しましたように、R20-11では、AUTOSARの新世代プラットフォームであるAdaptive Platform（AP）の開発の陰で、Classic Platform（CP）において「Classic Platform（CP） Flexibility」と呼ばれるコンセプトが導入されました。

　また、それ以前のリリースでも、「MCAL Multicore Distribution」（R4.4.0）および「BSW Multicore Distribution」（R19-11）が導入されています。

　これらは、マルチコアマイコンを搭載した大規模ECUへの対応を強化するためのものであり、AUTOSAR CP R4.x系を新たな世代に進化させるためのコンセプト群です。

　APの標準化と製品開発が進む中でも、高い安全性が求められる分野（特に、ISO 26262 ASIL D）で利用可能なAP向けデバイス（主にはMMUを持つプロセッサ）はまだ市場には出そろっていません（表1）^※1）。このため、当面は引き続きCP向けデバイス（主にはMMUを使わないマイコン）とCPベースのソフトウェアに依存せざるを得ないという事情もありますので、「延命措置」「つなぎ」という見方もできるかもしれません。

表1　AUTOSARのClassic Platform（CP）とAdaptive Platform（AP）、一般的なIVI（車載情報機器）向けプラットフォームの比較（クリックで拡大）

　しかし、それだけだと見なしてしまうのは早計でしょう。

　実は、今回のCP Flexibilityには「仕事のやり方」を変えるための改良、もっと言えば「分散開発で諦めること、諦めないこと」の共通認識を確立する、という側面も潜んでいます。

　CP Flexibilityコンセプトの開発には、筆者もWatchdog Manager（WdgM）モジュールの規格書の文書責任者（document owner）として関わっています。あいにく標準化作業中の内容については守秘義務があるためご紹介できませんが、今回は、公開情報の範囲でお伝えしていきたいと思います。