　なお、前回も書きましたように、APはまだ開発途上にあるものです。今回の内容は現時点（2019年2月）で最新のAP R18-10およびFoundation（FO） R1.5.0をベースにしていますが、今後のリリースによりまだまだ変化していきます。2019年中にも、計2回のリリースが予定されています（気が付いてみれば、もうすぐ次のリリースR19-03ですね）。

　どんな場合もそうですが、情報の鮮度には注意が必要です^※1）。その点、ご留意の上で本稿をお読みいただければと思います。

※1）私が2011年に書いたCPの解説記事が、2019年現在も検索上位に出てくるのですが、さすがにどうかと思います。何しろ、2011年当時はAUTOSAR CP R2.1やR3.xが主流だったころです。仕様自体の改訂などにより現在は有効ではない情報もありますので、くれぐれもご注意ください。

Adaptive Platform（AP）のアーキテクチャ

　ここでは、APのアーキテクチャに関して、AUTOSAR AP Explanation of Adaptive Platform Design（参考文献［1］）と、FOとAPそれぞれのRelease Overview（参考文献［2］、［3］）をベースに解説していきます。

図1　APのアーキテクチャ（論理面）（クリックで拡大）

　CPのアーキテクチャはBSW、RTEおよびApplication Layerの3階建てでしたが、APのアーキテクチャ（図1）では、AUTOSAR Runtime for Adaptive Applications（ARA）の上に、APにおけるアプリケーションであるAdaptive Application（AA）を載せる形になっています^※2、3）。

※2）なお、APのARAは、CPのRTEとは全く異なるインタフェースを提供しますので、CP用SW-CをAAとしてコードレベルで流用することはできません（逆も同様です）。

※3）Machineは、実際のプロセッサである場合や、hypervisorなどの上でのvirtual machineである場合があります。厳密な定義はまだなされていません。

　ARAは、CPのRTEやBSWに相当します。ARAは16個のFunctional Cluster（FC）と呼ばれる機能単位ブロックから構成され、大まかに以下の2つのグループに分けられています。

Adaptive Platform Foundation：APの基本機能を提供するライブラリ群（Library-based）。Procedure call（processを持たずに実現できるもの）、または、Machine内Inter-Process-Communication（IPC）を介してAAから利用
Adaptive Platform Services：APにおける基本サービス群（Service-based）。Communication Management（CM）を介してAAから利用

　各AA／FCは、それぞれの論理メモリ空間や名前空間（namespace）を持つ独立したプロセス（process）、またはその集合体として実装されます。AAからは、規定のC++形式のインタフェースを介して上記両グループのFCにアクセスします^※4）。

※4）これらのほかにも、AAに任意のサービスをさらに追加して利用することも可能ですが、その場合には機能や安全／セキュリティに関する干渉がないようにする必要があります。

　APにおける標準化のアプローチは、CPとは異なっています。簡単に言ってしまえば、AAから利用可能なARAの機能／サービスは規定されるものの、その内部構造については、CPのBSWの階層構造のような詳細を定義しません。

　なお、FCの一部の機能は現在のリリースではまだ実現されていませんが、今後のリリースで順次対応されていきます^※5）。

※5）制限事項に関するおおよその情報は、FO / AP Release Overview（参考文献［2］、［3］）の「Known technical deficiencies per document」の節に記載されています。R18-10の次のリリース以降での制限事項については、各リリースでのRelease Overviewをご覧ください。

Adaptive Platform Foundationとは

　　　　　　 1|2|3 次のページへ