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

[櫻井剛，MONOist]

R19-11で導入された11個のConcept

　R19-11で導入された11個のConceptと、影響を受けるプラットフォームの一覧を表1に示します。

Concepts	FO	CP	AP	補足	State
DoIP Extension	x	x	x	CP/AP関係強化（＋機能拡張）	Draft
IPsec Protocol	x	x	x	CP/AP関係強化（＋機能拡張）	Incorporated
Abstract Platform System Description（VFB++）	x	-	x	CP/AP関係強化	Draft
Signal Service Translation	x	x	x	CP/AP関係強化	Draft
BSW Multicore Distribution	-	x	-	機能拡張	Draft
ServiceVersioningARAcom	-	x	x	機能拡張	Draft
Non-Volatile Data Handling Enhancements	-	x	-	機能拡張	Draft
Firmware over the Air（FOTA）	-	x	-	機能拡張	Draft
Socket Network Binding for ARA:com	-	-	x	機能拡張	Draft
Recovery Action via Application	-	-	x	機能拡張	Draft
UCM Master	-	-	x	機能拡張	Draft
表1　Concept一覧（R19-11、xは影響を受けるプラットフォーム）

　ここからConceptのそれぞれについて簡単に解説します。

DoIP Extension（※FO/CP/APが対象、draft扱い）

　Ethernet経由での診断通信プロトコルDiagnostics over IP（DoIP）の標準規格はISO 13400-2です。ISO 13400-2:2012までは車両外にある外部テスター（external tester）とECUとの間の診断通信が対象でしたが、AUTOSARと並行して改訂が進められ、2019年12月13日に発行されたばかりのISO 13400-2:2019では、車両内に設置される内部テスター（internal tester）とECUとの間の診断通信もカバーするようになっています。

　DoIPに関しては、AP R19-03はそもそも事実上未対応であり、またCP R4.4.0ではDoIPモジュールは存在するものの外部テスター対応のみでした。今回のR19-11で、AP/CPともに両種テスターとの通信に対応させるための拡張が行われました。CP DoIPモジュールでは、両種の違い（activation line、vehicle announcement、動的IPへの対応の要否）に対応するためのconfiguration面の見直しが中心ですが、activation lineの状態変化とvehicle announcementの開始をDoIPモジュールに通知するための2つのAPIも追加されています。

IPsec Protocol（※FO/CP/APが対象）

　通信のセキュリティに関しては、これまでも、LIN以外の各種ネットワークで利用可能なSecure On-board Communication（SecOC, CP R4.2.1で導入され、R19-11でも細かな修正が多数行われ、また、chap. 11のFVM関連の説明も改訂されています）や、Ethernet向けのTransport Layer Security（TLS 1.2、CP R4.4.0で導入）に対応していました。しかし、TLSはTCPの上に実装されるものであり、例えば、TCPの下のIPのレベルでのパケットに対する改ざん検知が必要な場合には対応できません。

　そのようなニーズに対応するために、R19-11ではSecurity Architecture for the Internet Protocol（IETF RFC 4301、いわゆるIPsec-v3）に対応しました。なお、CPのTCP/IPモジュールでは、IPsecのtunnel modeには現時点では未対応（transport modeのみ対応）であり、またIPv6やmulticastにも未対応です。

Abstract Platform System Description（VFB++）（※FO/APが対象、draft扱い）

　各ECUで採用するソフトウェアプラットフォーム（AUTOSAR CP/APのいずれか、あるいはnon-AUTOSARか）が未定の段階でもシステム全体をモデリングできるようにするために、この改良が行われました。

　なお、実際の変更内容はメソドロジおよびテンプレート面が中心です。またR20-11に向けてさらに改良されていきます。

Signal Service Translation（※FO/CP/APが対象、draft扱い）

　APとCPの通信方式の違いは物理層だけにとどまりません。前者はサービス指向通信（service-oriented communication、ServiceInterfaceによる）のみ、後者はシグナルベース通信が中心です（signal-based communication、SenderReceiverInterfaceおよびClientServerInterfaceによる）。しかし自動車の電気／電子（E/E）システムには両者が混在することになります。両者をつなぐためには、シグナル／サービスの双方向での変換が必要になります。

　APのFCとしては当初はSignal to Service Mappingという独立したものが用意されていましたが、R19-11ではCommunication Managementに統合されています。成熟度はともかく、Service Discoveryや通信路の保護（セーフティのためのE2EやE2E Profileの変換、セキュリティのためのTLS/SecOC/IPsecなど）への考慮も行われています。

　逆方向の変換（Service to Signal Mapping）を行うCPではSystem Templateに多くの変更が入っています（FCやBSWの機能面よりもメソドロジ＆テンプレート面、つまりモデリングの面の方がむしろ重要かもしれません）。

BSW Multicore Distribution（※CPのみが対象、draft扱い）

　CP R4.4.0で導入されたMCAL Multicore Distribution Conceptに続く、マルチコアのシステム上でのBSW分散配置を扱うConceptです。今回は通信関連のBSW群が対象となっています。処理負荷の分散を可能にしつつもコア間のやりとりを極力小さくするという方針のもとに、PduRを中心として、その上位レイヤー（BusMirroring、Com、Dcmなど）や、その下位レイヤー（CAN stackなどの通信関連BSW群）を、各コアに分散配置できるように拡張したものであり、PduRをはじめとして多数のBSWが影響を受けています。

　また、これに関連して、Basic Software Multicore Library（Bmc）が追加されています。これは、コア間の調停のための、flag操作やstore/load/exchangeなどの基本的な演算を行うリエントラントな関数群を含みます。

ServiceVersioningARAcom（※CP/APが対象、draft扱い）

　SOME/IP Service Discovery（SOME/IP-SD） Protocolは、サーバが提供可能（OFFER）なサービスと、クライアントが要求（FIND）するサービスをつなぐためのプロトコルです。しかし、サーバやクライアントは同時に更新されるわけではなく、また、引数や型などを変えずに済む保障もありませんし、それらが変わらなくても振る舞い面での後方互換性が失われる可能性もあります。一方が更新された場合に、互換性があればつなぎ、無ければ提供を拒否できるようにするための拡張が行われました（minor versionによる判定条件の明確化だけではなく、特定バージョンの組み合わせでの不具合の回避のためのblack list機能を追加）。

Non-Volatile Data Handling Enhancements（※CPのみが対象、draft扱い）

　AUTOSAR CP R4.4.0までの不揮発メモリスタックは、Data FlashやEEPROMへのアクセスがいつでも行われ得る、と想定した設計になっています。一方、ECUや車両の生産ラインで書き込まれるデータは、一度書き込まれたら更新されることがないもの（Write Once）なども少なくありません。NVRAM Manager（NvM）モジュールでは、Write Onceなどは表面的には考慮されていますが、実際のNvMなどのBSWモジュール内でのリソース利用効率改善などは実装に大きく左右されます。また、不揮発メモリスタックだけではなくRTEも含めて考えれば、さらなる改善の余地が残されています。また、生産ライン内での滞留時間は製造コストに少なからず影響しますが、SW-C/RTE/BSWを利用すると、データコピーの回数などの理由もあり、どうしても書き込み時間が長くなりがちです（筆者も、RAM不足や書き込み時間の問題でお困りのお客さまにはあえて不揮発メモリスタックを介さない形での最適化をご提案したことが何度もあります）。不揮発メモリスタックのBSWの改良だけではどうにもならないことから、通信スタックでのLarge Data COM（LdCom）と同様なアプローチの新規BSWであるBulk NvData Manager（BndM）を導入し、併せて、RTEにも手を入れました。

　なお、BndMは、NVRAM Manager（NvM）とは異なりFlash Driver（Fls）を直接制御します。従って、Flsの上位レイヤーとの関係は、1）Fee経由でのNvMへの接続と、2）直接のBndMへの接続の2パターンが出てくることになりますが、R19-11時点ではFeeやFlsでの排他制御を行っていません。そのため、統合（integration）時に排他制御について考慮する必要があります（see AUTOSAR CP R19-11 SWS Fee, sec. 4.1 Limitation）。また、BndMは現時点では独立したBSWとなっていますが、次のリリース（R20-11）以降、NvMに統合される可能性もあります（see AUTOSAR CP R19-11 SWS BndM, chap. 1）。