AUTOSARの歴史と最新動向に見る、Classic PlatformとAdaptive Platformの関係：AUTOSARを使いこなす（6）（1/4 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第6回では、2018年11月時点でのAUTOSARの最新動向を紹介するとともに、Classic PlatformとAdaptive Platformの関係について説明する。

[櫻井剛，MONOist]

はじめに

　前回の掲載（2018年9月）から少し時間がたってしまいましたが、この間、2018年10月31日にはAUTOSARから新たなバージョンの文書群が公開されました（実際のリリース通知は、ドイツ時間でも2018年11月1日に入ってしまってから送られたようでしたが……）。

• AUTOSAR Foundation（FO） R1.5.0
• AUTOSAR Classic Platform（CP） R4.4.0
• AUTOSAR Adaptive Platform（AP） R18-10

　今回はちょうどよいタイミングですので、AUTOSARを活用できるようにするためにご注意いただきたいこととも関連付けながら、AUTOSARの変更点の概要についてご紹介していきたいと思います。また、「Adaptive Platformは、Classic Platformを置き換えるのか？」というよくある問いに対して、現状の課題も絡めながらお答えしていきたいと思います。

　なお、2018年11月7日に中国・上海で「11th AUTOSAR Open Conference」も開催されましたが、資料はAUTOSAR内および出席者のみの公開とされているため、今回はその内容には触れません。

その前におさらい：AUTOSARの歴史と現在の各文書群の関係

　AUTOSARは2002年から設立準備が進められ、2003年に正式発足しました。

　当時は、現在よりもさらに性能面やROM／RAMなどのリソース面の制約が厳しく、私自身が関わっていた量産車向けボディー系ECUの開発でも、CAN通信が必要なければ8ビットマイコンとアセンブラ言語がまだ多く使われていました。CAN通信を必要とする場合でも、16ビットマイコンが主流だった頃です。

　新たな機能が続々と導入され、複数の役割を持つECUが増えていき、それでもしかし、消費電力の抑制、起動に要する時間の短縮、リアルタイム性や信頼性などの確保と両立させなければなりませんでしたから、開発規模は急速に大きくなり、開発チームの人数も増え（残念ながら、人財の補充は後手になりがちでしたが）、分業化や分散開発も進んでいきました。必然的に、分散開発やソフトウェアの再利用を進めるためのプラットフォーム整備は急務とされていました。

　一部の自動車メーカーでは、どの種類のECUでも使用される部分（OSや通信、診断など）の標準モジュールの利用の推奨または義務化も行われていましたし、車両の個別機能を実現するアプリケーション部分を自動車メーカーから供給することも行われるようになっていました。

　その当時、欧州を中心に、車載ECUの開発で既に広く使われていた基本ソフトウェア標準規格が、以下の文書群に代表されるOSEK/VDXです。

• Operating System（OS、現在のISO 17356-3:2005）
• Communication（COM、同ISO 17356-4:2005）
• Network Management（NM、同ISO 17356-5:2006）

　なお、OSEK/VDXの公式Webサイトは閉鎖されており、確認時点（2018年11月24日）ではISO文書の検索ページにリダイレクトされています（2016年後半に確認した際には、AUTOSARの公式Webサイトにリダイレクトされていたのですが、変更されたようです）。

　AUTOSARは、これらの既存の資産や知見（ソフトウェアアーキテクチャ面に関する標準規格であるOSEK/VDX OSやCOMに限りません、またNMはAUTOSARで新たな方式を採用しています）を利用しつつ、さらに多くの課題に立ち向かうことを目指して、構築が進められてきました。最初は、ごく基本的な機能をサポートするところからスタートし、2005年6月にR1.0が発行されました。その後、2008年ごろから量産車に本格的に適用されるとともに、イーサネット（Ethernet）、グローバル時刻同期（Global Time Synchronization）、機能安全／セキュリティ対応のためのさまざまな機能拡張や、自動車メーカーとサプライヤー間の設計情報の授受の効率化やカバー範囲の拡大、そして、設定作業などの自動化を容易にするため枠組み（Methodology and Template）の幾度かの大きな拡張などを経て、2018年11月現在で最新のClassic Platform（CP） R4.4.0に至っています。

　ところで、CPは、最初からClassicと名付けられていたわけではありません。実際、R4.2.2（2015年発行）までは単に「AUTOSAR」と呼ばれていました。しかし、この少し前から、各種の運転支援技術や自動運転技術の量産車への本格的な導入が進められており、車内だけではなく車外のさまざまな相手との動的な通信（Connectivity）や強力な演算能力を、積極的かつ効率的に活用していくには、1990年代の想定に基づいて作られたシングルコアCPU向けOSEK/VDX OSをベースとした静的なOSだけでは将来立ち行かなくなることは明らかでした（OSEK/VDX OSのVer. 1.0は1995年発行です。それに基づくAUTOSAR OSはR4.xでマルチコア対応のための各種拡張も行われていますが）。「（ソフトウェアアーキテクチャなどによる制限がある中で）使える範囲だけ使う」ということでは、限界があります。

　そのため、動的OSを採用したAdaptive Platform（AP）の構想が検討され、2017年3月にその最初のバージョンであるAP R17-03が公開されました。これに伴い、従来の「AUTOSAR」を「AUTOSAR Classic Platform（CP）」と呼ぶようになりました。

　当然ながら、CPベースのECUとAPベースのECUが同じネットワーク上に接続されるようになりますので、通信プロトコルやデータ交換形式などCPとAPの共通部分も存在します。それを既存のCPから切り出し、APの登場にあわせて拡張した部分が、AUTOSAR Foundation（FO）と呼ばれる部分です（図1）。

図1　AUTOSAR文書群の全体像

　なお、現時点では、CPとFOのバージョン表記と、APのバージョン表記の方式は異なります（図2）。

図2　バージョン表記の方式（クリックで拡大）

　また、FOとCP／APのバージョンには組み合わせ制約があります（表1、2）。

	CP	FO
CPとFOのバージョン組み合わせ	R4.3.0	R1.0.0
	R4.3.1	R1.3.0
	R4.4.0	R1.5.0
表1　CPとFOのバージョン組み合わせ制約 出典：AUTOSAR FO/CPの各バージョンのTR Release Overview

	AP	FO
APとFOのバージョン組み合わせ	R17-03	R1.1.0
	R17-10	R1.2.0
	R18-03	R1.4.0
	R18-10	R1.5.0
表2　APとFOのバージョン組み合わせ制約 出典：AUTOSAR FO/APの各バージョンのTR Release Overview