AUTOSARの最新動向：2016年3月版：AUTOSAR〜はじめの一歩、そしてその未来（7）（3/3 ページ）

筆者へのAUTOSAR関連の問い合わせで、最近になって急激に増えているトピックが幾つかある。今回はそれらのトピックをまとめる形で、「AUTOSARの最新動向：2016年3月版」と題してお送りしよう。

[櫻井剛（イータス RTAソリューション シニア・コンサルタント），MONOist]

AUTOSAR Adaptive Platform（AP）／AUTOSAR Foundation（AF）および自己診断系のBSWの入手性

　2015年8月掲載の連載第1回では、その存在のみを紹介したAUTOSAR Adaptive Platformであるが、最近問い合わせが増えてきたのでここで少し説明させていただこう^※7）。

　自動運転（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導入により、基本的な型や支援体制をどのように変えていくかの見極めと必要な活動の実施」に関連する内容を続ける。キーワードは「再利用」を予定している。

注釈

※7）出典：7th AUTOSAR Open Conference (Detroit, 2014-10-22) http://www.autosar.org/fileadmin/files/events/2014-10-22-7th-autosar-open/Current_Status_and_Future_of_AUTOSAR_Bechter.pdf、8th AUTOSAR Open Conference (Tokyo, 2015-10-29) http://www.autosar.org/fileadmin/files/events/2015-10-29-8th-autosar-open/AUTOSAR_8AOC_Adaptive_Platform_Bechter.pdf、http://www.autosar.org/fileadmin/files/events/2015-10-29-8th-autosar-open/AUTOSAR_Overview_Camargo.pdf、および、Automotive Software Frontier 2016 (2016-03-09)におけるトヨタ自動車株式会社 西川氏講演資料（A1-5：AUTOSAR 〜Current Achievements and Future Activities〜）

お知らせ

　筆者が現在所属するイータスでは、AUTOSARをはじめ車載ソフトウェア開発に関する「よろず相談会」を随時開催しています（要事前予約、初回無料）。詳しくは、申し込み用Webサイトまで。

【筆者紹介】

櫻井 剛（さくらい・つよし） イータス株式会社 RTAソリューション シニア・コンサルタント

2014年よりイータス株式会社。ECU開発（1998年〜）やAUTOSAR導入支援（2006年〜）における経験を生かしし、2015年現在、AUTOSARに関する全般的な支援業務、および、機能安全を含むシステム安全に関する研究に従事。修士（工学）およびシステム安全修士（専門職）。

・イータス株式会社
http://www.etas.com/ja/