AUTOSAR Adaptive Platformとは？：AUTOSARを使いこなす（7）（2/3 ページ）
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第7回では、AUTOSAR Classic Platformに次いで新たに登場したAUTOSAR Adaptive Platformについて説明する。
先述の要素は他の分野でもしばしば「ゲームチェンジャー」として登場するものですが、こういった背景を踏まえて登場したのがAPです。APを検討していることとその名称について一般に初めてアナウンスされたのは、2014年10月にデトロイトで開催された「7th AUTOSAR Open Conference」です。AUTOSAR内では、2013年頃までに将来要求されることの要件の想定がまとめられ、2015年にAPを（当時の）AUTOSARの拡張版として開発することが正式に決められました［2］。
要求事項や通信プロトコルなど、AP／CPで共通の内容を定義するFoundation（FO）の初版である「FO R1.0.0」が2016年11月にリリースされ、その後、APの初版である「AP R17-03」が2017年3月にリリースされています。以降、半年ごとにリリースされており、少なくとも2019年末までは半年ごとのリリースが続けられます［3］。
AUTOSARの文書体系と公開されているスケジュール情報を図1および図2に示します。
意外に重要なアーキテクチャ以外の側面
このAPの標準化を進めるにあたり、上記のソフトウェアアーキテクチャ面の要件だけではなく、以下のようなことも重要なポイントとして取り入れられています。
- 他分野の人材や知見の積極的な取り込み：従来の車載分野の外からの知見を積極的かつ効率的に活用するために、それらの分野の方々が扱いなれた技術や開発スタイル（例：POSIX APIや、ROSなどでも使用されているDDS（Data Distribution Service、OMGによる）仕様、アジャイル型開発など）を取り入れ、参加の障壁を下げ、他の標準化団体とも協調する
- サイクルを速く回す標準化活動スタイル：安定状態にあるCPとは異なり、「アイデアや議論の結果を形にして動かしてみて、検証し得られた結果を反映する」という、サイクルを回すスピード確保を優先した進め方を取る。具体的には、CPとはある程度独立しての開発や、アジャイル型開発方式の採用、標準化を行うワーキンググループ（WG）によるレファレンス実装（規格文書がリリースされた後に各社が実装を行うことで初めてvalidationが行われるというスタイルではなく、標準化活動の一部として実装を行いそこでvalidationを行う）、短いサイクルでのリリースなど
ちなみに、筆者はCP中心に活動してきたのですが、2018年からとうとうAPの開発にも参加するようになりました（FT-SAF：Feature Team Safetyで、通信路の誤り検出能力の評価・向上と、処理実行内容の健全性確保のためのメカニズムに関する標準化を、document ownerの1人として行っています）。「従来型開発スタイルに慣れ親しんできて、保守的傾向のある人たちにも、アジャイル型のスタイルなど、他分野の文化を浸透させる」という意図もあるのではないか、なんてことも感じています（意図を確認したことはまだありませんが……）。
一般に、標準化活動単体のために人材や工数を確保することはなかなか難しいのですが、こういった副次的な効果を関連付ければハードルを下げることができるかもしれません。ひょっとすると、自社や開発チームにアジャイル型開発スタイルを導入したいとお考えの方は、事前の実地経験を積むために、AUTOSAR APの標準化活動の場を利用するのも1つの手かもしれません。
筆者が勤めるイーソルの権藤（取締役CTO 兼 技術本部長の権藤正樹氏）や筆者自身のように、現地に毎月渡航して参加するのは負担が大きいとは思いますが、国内からも多くの方が参加するFT-ST（System Test）であれば相対的には負担は小さいと思いますので、ぜひご検討いただければと思います。
Copyright © ITmedia, Inc. All Rights Reserved.