　自動運転（AD）やADAS、それらに組み合わせて利用されるCar2X（V2Xとも）通信などの用途では、今後、動的な通信コンフィギュレーションや動的アーキテクチャ（メニーコア対応を含む）の要求が高まることは想像に難くない。従来のOSEK／VDX系RTOS（AUTOSAR OS）は、静的アーキテクチャに基づいており、それらへの対応は容易ではない。

　そこで、POSIXベースの動的アーキテクチャに基づく新たなAUTOSAR Adaptive Platform（AP）の開発が現在進められている。APの最初の規格文書（R1.0.0）の発行は2017年3月末に予定されている。APについては、BSW相当の部分の実装の配布も行われるとのことであるが、いずれにしてもAPを開発や量産に適用できるようになるには、もうしばらく時間がかかる。

　なお、APと対比する形で、従来型AUTOSARはClassic Platform（CP）と呼ばれるようになった。今のところAPはCPを完全に置き換える存在とは考えられておらず、2015年10月29日に東京で開催された「8th AUTOSAR Open Conference」の質疑応答においても、置き換えを明確に否定する旨の回答がなされている。

　また、これまでNon-AUTOSARのソフトウェア構造を採用するECUでは、AUTOSAR XMLで定義されたネットワーク定義などのシステム設計情報を直接利用することが困難であり、その開発における負担や変更などの際のリードタイムは通常のECUに比べて大きかった。

　しかし今後は、CPとAPの両方のECUに関する横断的な設計情報を、AUTOSAR XMLで定義されたネットワーク定義などのシステム設計情報に反映することができるようになる。もちろん、その横断的な設計情報はCPとAPのそれぞれのECUの開発に直接利用できる。特に、Gateway（ゲートウェイ）ECUの開発では、横断的に定義された情報を利用できるか否かが、開発効率の観点からは鍵となるから、今後の開発には重要になる。

　このように、CPとAPの両方にまたがるような基盤を切り出し整備していくのが、AUTOSAR Foundation（AF）である。AFの最初の規格文書（R1.0.0）の発行は、CP R4.3.0の発行とあわせて2016年10月末に予定されている。

自己診断系のBSWの入手性

　最新バージョンのAUTOSARであるR4.2.2では、ハードウェア自己診断（BIST：Built in Self Test）用のMCAL BSWを用意している。

Core Test（CorTst）：CPUの自己診断
Flash Test（FlsTst）：Flashの自己診断
RAM Test（RamTst）：RAMの自己診断

　これらのBSWは、当然ながらハードウェアの故障モードの想定を基に作られるため、対象のマイコンの開発元から提供されるのが通例である。しかし、実際には提供されている品種が極めて限られており、そのことが広く認知されているとは言い難い。

　自動車メーカーやECUサプライヤ側での要求仕様の議論において、この点での想定と現実のズレが問題となることも多い。ISO 26262に基づく開発において、安全目標（safety goal）を各要素への要求にブレークダウンしていく際、これらのBSWにより提供される機能が利用可能なのを前提とすることも多いが、そのような場合には、マイコンの開発元に確認が取れるまでは確定させるべきではない。早急に確認し、入手できないのであればいち早く代替案に切り替えるべきである。

　一般に、マイコンの選択に当たっては、「そのマイコン用のMCALパッケージの存在の有無」だけしか確認されないことが多い。しかし、それだけでは十分ではない。「MCALパッケージに必要となる個別BSWが含まれるか、また、各BSWは、必要とする機能に対応しているか」を確認することが重要である。

　次回は、本連載の締めくくりとして、「量産開発を通じてのAUTOSAR導入」の2つ目の側面である「AUTOSAR導入により、基本的な型や支援体制をどのように変えていくかの見極めと必要な活動の実施」に関連する内容を続ける。キーワードは「再利用」を予定している。