AUTOSARの最新リリース「R19-11」とは（前編）：AUTOSARを使いこなす（14）（3/3 ページ）

[櫻井剛，MONOist]

Firmware over the Air（FOTA）（※CPのみが対象、draft扱い）

　今後、車両に搭載されるECU上の各種データを含むソフトウェアの更新は、より頻繁に行われるようになります。CPでは、ECUのソフトウェア更新のためのBootloaderは標準化の対象外としていましたが、書き換えに関する一定の取り決めの必要性が高まってきたことから標準化が進められてきました（JasParのワーキンググループの紹介ページのOTA技術WGに関する説明文で、このキーワードをご覧になった方もおいでかもしれません）。外部のテスターからCPベースのECUの更新を行うための要求事項やそれを実現するアーキテクチャ（書き換える側と書き換えられる側の構成：外部テスター−車内の（F）OTA Master（UCM Master）−（F）OTA Target ECUの3要素）、シーケンス（Rollback手順など）、ステートマシン、そこで使用するUDS診断通信サービスなどが示されています。

　なお、CPの既存モジュールへの機能変更などは現時点では特にありません（SWS文書の追加や変更は無く、RSとEXPを追加したのみ）。

　しかし、このConceptは後述のUCM Master Conceptや、Flashへの書き込み中の読み出し可否に強く依存しており^※1）、R20-11以降でさらに開発が進められます（see AUTOSAR CP R19-11 EXP FOTA, chap. 1）。

※1）read-while-write: ハード側の対応に加えて、Flash Driver（Fls）側での対応も必要

Socket Network Binding for ARA:com（Socket API、Raw Data Streams）（※APのみが対象、draft扱い）

　AD/ADAS関連のセンサーからの生データのような、長大なデータストリームをApplicationで直接操作しなければならない場合のために、Communication ManagementにRawDataStreamsのインタフェースが追加されました。

　R19-11ではまず受信できるように拡張しましたが、次のR20-11では送信側の拡張も行われます。

Recovery Action via Application（※APのみが対象, draft扱い）

　R19-03までのPHMでは、Recovery Actionとして以下の4つが定義されていました。

1. SMへのFunctionGroup切り替えの要求
2. EMへのState切り替えの要求
3. EMへのProcess Restartの要求
4. Watchdogを利用したリセット（実装依存, ex. WDTハードウェアへのトリガー出力の停止などによる）

　しかし、何らかの処理をApplication側で即座に行いたい（SM/EMを経由したくない）場合を想定し、R19-11では、Application側のError Handlerを事前に登録しておき、異常が検知されたときに呼び出せるようにもなりました。なお、これは、R19-03ではRecovery Actionの追加候補として挙げられていた「Forward error information to another PHM entity or an Application: not specified in this release.」のうち、「to an Application」の部分に相当します（「to another PHM entity」の部分や、もう一つの候補である「Diagnosticsへの通知」はR19-11では未定義）。

UCM Master（※APのみが対象、draft扱い）

　FOTA Conceptで登場した「書き換える側」のうち、外部テスターからデータを受け取り、車内の（F）OTA Target ECUの書き換えを行うのが、（F）OTA Master（UCM Master）の役割ですが、R19-03まではその役割はUpdate and Configuration Management（UCM）ではカバーされていませんでした。まずはAPベースのECU/Machineにその役割を追加しようとするのがこのConceptです。

　なお、あるUCM Masterが機能しなくなった場合には、代わりのECU（UCM Subordinate）にUCM Masterの役割を移すようなケースも想定しています。

Classic Platform（CP、概要のみ）

　紙面の都合もありますので詳細は次回に持ち越しますが、CPでの変更内容についても簡単にご紹介いたします。

　アーキテクチャ面では、Bulk NvData Manager（BndM、Non-Volatile Data Handling Enhancements関連）やBasic Software Multicore Library（Bmc、BSW Multicore Distribution関連）という2つのBSWモジュールが追加され、また、R4.4.0時点で既にobsolete扱いとなっていたLIN Network Management（LinNm）が削除されています。

表2　BSW一覧（Module ID順、R4.0.1〜R19-11までに追加／削除されたもの）（クリックで拡大）

R19-11の振り返りと近況

　筆者は2018年秋のリリースの後から安全関連の部会WG-SAF（Safety）に活動の中心を移し、それまでdocument ownerとして担当していたCPの通信関連の4つの文書のうち2つを他の方に引き継ぎ（比較的低難易度のものだったので、国内の方／企業に後任をお願いしてみたのですが、残念ながら今回は実現せず……引き続きお声掛けしていきます）、代わりにCPのSafety関連の2つの文書（SWS WdgMなど）の開発を担当することになりました。加えて、安全関連の文書、特にFOのSWS Health Monitoringや、APのSWS Platform Health Management（PHM）などの開発メンバー、安全観点での各種Conceptのレビューおよび変更管理委員会（CCB）でのWG-SAF側からの投票、という形で携わってまいりました。なお、所属するイーソルからは、筆者だけではなく日欧の複数のメンバーが、アーキテクチャやシステムテスト関連WGなどに参加し活動しています。

　会員向けリリースが一段落した後のWG-SAFの月例会合（2019年12月）は、ひょっとしたらメンバーが皆すっかりクリスマス休暇モードなのではないかと思っていたのですが、予想に反して（と言ったら失礼なのかもしれませんが）、次のリリースに向けての活発な議論が繰り広げられました。実は、このタイミングを利用して自分が担当するトピックに多めに時間を割いてもらい、片付けてしまえるかな、と期待していたのですが、少々甘かったようです。

　よく考えれば、アジア諸国などキリスト教圏以外の人も多数いますし、実はR19-11には間に合わなかったもの（＝心残り）が多数あるとみえて、「心機一転、今度こそ」という雰囲気にも満ちていました。標準化活動で私が主に関わっているものの一つである、APのPHM関連のインタフェース関連の議論では、これまでその妨げになっていた本質的な前提条件の見落としなども明らかにすることができましたので、良いスタートが切れたように思います。

次回に続く

　次回以降、量産開発で既になじみの深いClassic Platform（CP）での変更点についての詳細と、自動車E/Eシステムの今後を担うことが期待されている、Adaptive Platform（AP）での変更点をご紹介いたします。