本記事の目的
AUTOSAR R24-11の更新内容がなんとなく理解できること。
本記事ではRelease Overviewに記載されていることは、[Overview]と記載する。
Overviewを読んで解釈した内容や、コメントについては[メモ]と記載する。
参照文書
R24-11 Classic Platform Release Overview
2 Summary of Changes in Release R24-11
2.1.1.1 Charging Interface
[Overview]
ISO15118-2 充電規格をAUTOSAR CPに統合。
※R23-11の変更点：「ChrgM」の追加
[メモ]
コンポーネント名が「ChrgM」ではなく「ISO15118Chrg」に変更になったり、
図や章の追加がされている。
Specification of ISO15118 Chargingの仕様
2.1.1.2 Deterministic Communication with TSN
[Overview]
このコンセプトでは、「レガシー通信（CANおよびLIN）のために、AUTOSAR通信スタック内でIEEE1722が規定するトンネリングプロセスを完了すること」に焦点を当てています。
具体的には、AUTOSAR CP上で「TSCF」および「NTSCF」サブタイプのIEEE1722ストリームを完全にサポートすることを目的としています。
これにより、AUTOSAR CPの通信スタックは、ネットワーク上でAVTPストリームとして転送されるACFメッセージとしてのIEEE1722カプセル化バスフレーム（例：CANフレーム）を処理することが可能になります（いわゆるレガシー通信のトンネリング）。
注意：AUTOSARは、IEEE1722カプセル化されたCANおよびLINフレームをACFメッセージとして転送することをサポートしています。他のバスタイプ（例：FlexRay）は、将来的に追加される可能性があります。
[メモ]
IEEE1722：Audio Video Transport Protocol (AVTP) を定義する規格であり、AVB（Audio Video Bridging）またはTSN（Time-Sensitive Networking）フレームワークの一部として設計されています。主にリアルタイムオーディオ、ビデオ、制御データの通信を目的とし、高精度な時間同期と低遅延を実現します。
TSCF（Time Sensitive Control Format）：タイムクリティカルな通信を対象としたデータフォーマットまたは制御フレームの一種です。AVTP（Audio Video Transport Protocol）内で、リアルタイム性が求められる制御データのフローを管理する役割を果たします。
NTSCF（None Time Sensitive Control Format）：NTSCFは、リアルタイム性が必須ではない制御データやイベント駆動型通信に適したフォーマットです。
非同期的なデータ転送に対応し、より柔軟な通信方式を提供します。
ACF(Audio Control Frame)：AVTPの一部であり、特に制御メッセージや同期情報の転送を行うためのフレーム形式です。
トンネリングプロセスとは：
従来のプロトコル（CAN/LINなど）資産を活用しながら、新しいネットワークアーキテクチャ（Ethernet）への移行をスムーズにする技術。
「IEEE1722Tp」というコンポーネントが左側にあると思うが、ここでCAN/LINなどから受け取ったデータをカプセル化、IEEE1722形式に変換してEthernetに転送する。
参考文献:SHORT ETHERNET FRAMES:2021
以下のようなゾーンアーキテクチャ上のECUで、CAN/LINなどの従来のプロトコルで通信している情報をうまく使いながら、Ethernetに統合するような場合、今回のUpdateは有効と理解した。
2.1.1.3 I2CDriver
[Overview]
I2C（インタ・インテグレーテッド・サーキット）は、2線式のシリアルデータバスです。フィリップス・セミコンダクター（現在のNXPセミコンダクター）によって開発されました。I2Cは、シンプルに構成されたバスシステムであり、自動車業界で広く使用されています。
[メモ]
ドライバ層にI2C通信ドライバが追加された。
LayerdArchitecture にも追加されている。
2.1.1.4 DDS Protocols
[Overview]
このコンセプトの目的は、以下の方法を通じてDDSサービス指向通信プロトコルを集中化し、均質化することです：
-
CPおよびAPにおけるDDSのサービス指向利用法を特定すること（例えば、サービスインスタンスの発見および提供されたサービスインスタンスと要求されたサービスインスタンス間の通信）。
-
利用法をDDSの概念（エンティティ、タイプ、トピック、QoSポリシー）およびメカニズム（標準API呼び出し）にマッピングすること。
-
必要に応じて、DDSネットワークバインディングまたはAP通信管理機能クラスターをリファクタリングし、マッピングを参照するようにすること。
[メモ]
仕様書の変更履歴には以下と記載されている。詳細までは確認できていない。
・一部の仕様項目の修正/改良
・受信および送信要件の詳細を追加
・リモート参加者に関する説明を明確化
・全ての仕様項目の検証を実施