AUTOSARの最新リリース「R22-11」（その2）＋SDVとAUTOSAR導入の共通点：AUTOSARを使いこなす（30）（3/4 ページ）
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第29回は、前回に続いて「AUTOSAR R22-11」について紹介するとともに、自動車業界で注目を集める「SDV」というバズワードとAUTOSAR導入の関係性について考えてみる。
2．AUTOSAR R22-11の概要（コンセプト＃6〜7）
前回申し上げました通り、2022年11月24日に「AUTOSAR R22-11」（Internal Release Number：R4.8.0）が発行されました。
このリリースの扱いは「minor release」であり、10の新規コンセプトの導入（2つを除きdraft扱い）と1つの継続コンセプトでの変更およびさまざまな機能拡張が行われています（表3）。
| No. | Title / Summary | FO | CP | AP | 補足 | Status |
|---|---|---|---|---|---|---|
| 1 | CAN XL | x | x | x | 機能拡張 | valid |
| 2 | Unified AUTOSAR Timing and Tracing Approach | x | - | - | 機能拡張（続編） | draft |
| 3 | MACsec | x | x | x | 機能拡張 | draft |
| 4 | V2X in AUTOSAR | x | x | - | 機能拡張 | valid |
| 5 | Firewall | x | - | x | 機能拡張 | draft |
| 6 | Service Oriented Vehicle Diagnostics (SOVD) | x | - | x | 機能拡張 | draft |
| 7 | DDS Support on CP | x | x | - | 機能拡張 | draft |
| 8 | SOME/IP Harmonization | x | - | x | 機能拡張 | draft |
| 9 | V2X support for China | - | x | - | 機能拡張 | draft |
| 10 | Secure Global Time Synchronization | - | x | - | 機能拡張 | draft |
| 11 | Deterministic Communication with TSN | - | x | - | 機能拡張 | draft |
| 表3 AUTOSAR R22-11での新規／継続コンセプト一覧（xは影響を受けるプラットフォーム） | ||||||
なお、表や文中に登場するプラットフォーム略称は以下の通りです。
- [FO]：AUTOSAR Foundation
- [CP]：AUTOSAR Classic Platform
- [AP]：AUTOSAR Adaptive Platform
では、残るコンセプトのご紹介（後半）に入ります。
2.1 コンセプト＃6（新規）：Service Oriented Vehicle Diagnostics (SOVD) [FO] [AP]
APで、ASAM SOVD（Service-Oriented Vehicle Diagnostics）を利用できるようにするものです。
AP EXP SOVD sec. 3.5に記載の通り、これはまだ第1ステップとして基本的なユースケース※9）のみをカバーしているだけであり、今後、さらにさまざまなユースケースに対応していく予定です（R23-11予定）。
※9）「基本的なユースケース」は、あくまで本コンセプト開発を行うグループ内で決められたものです。皆さまがお考えになる「基本的なユースケース」がカバーされているかどうかは分からないということに、注意が必要です。
2.2 コンセプト＃7（新規）：DDS Support on CP [FO] [CP]
DDS（Data Distribution Service）プロトコルのうち、基本的な通信機能のみと限定的ではありますが、CPでも対応しました（APではR18-03にてDDS network bindingを導入済み）。
これに伴い、CPに新規BSWモジュールであるDdsが追加されました。CP EXP Layered Software Architectureの63ページ目（page id：4dd66）のDDS関連BSWの図では分かりにくいのですが、DdsモジュールはSecOCと同様に、PduRからデータを受け取り、加工してまたPduRに戻す、という構造になっています（図2）。
詳細は申し上げることはできませんが（筆者もレビュアーとして参加しています）、このコンセプト開発では、途中に何度も構造面での大幅見直しが行われ、今の形に落ち着いています。
前述の通り、新機能の導入は、実際製品に機能実装してみて初めて分かる問題の解決（「使えればよい」にまで持っていく段階）だけではなく、実用段階を経て見えてくる使い勝手の改善も行われていきますので、安定までにはある程度の期間がかかることでしょう。
なお、「SOME/IPを置き換えるためにCPでDDSに対応したのではないか」という深読みをなさる方がいらっしゃるかもしれませんが、今はそのような大きな動きはありません。利用の要望があり導入された、という程度にニュートラルに捉えていただくのが良いと思います。SOME/IPとDDSのどちらが今後の主流になるのかを決めるのは市場の皆さまですし、たとえ現時点でプロトコルに何らかの弱点があったとしても、プロトコル自体の見直し含め行われていくことでしょう。
Copyright © ITmedia, Inc. All Rights Reserved.