Classic Platform Release Overview AUTOSAR CP R24-11

# 本記事の目的
AUTOSAR R24-11の更新内容がなんとなく理解できること。

本記事ではRelease Overviewに記載されていることは、[Overview]と記載する。
Overviewを読んで解釈した内容や、コメントについては[メモ]と記載する。

[過去の記事：R23-11の更新内容](https://qiita.com/issykatsu/items/bee6e6b4f93bcfa98e8b)

# 参照文書

[R24-11 Classic Platform Release Overview](https://www.autosar.org/fileadmin/standards/R24-11/CP/AUTOSAR_CP_TR_ReleaseOverview.pdf)

# 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の仕様](https://www.autosar.org/fileadmin/standards/R24-11/CP/AUTOSAR_CP_SWS_ISO15118Charging.pdf)


## 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）への移行をスムーズにする技術。

[参照：IEEE1722TransportLayer](https://www.autosar.org/fileadmin/standards/R23-11/CP/AUTOSAR_CP_SWS_IEEE1722TransportLayer.pdf)

「IEEE1722Tp」というコンポーネントが左側にあると思うが、ここでCAN/LINなどから受け取ったデータをカプセル化、IEEE1722形式に変換してEthernetに転送する。

![スクリーンショット 2024-12-30 16.09.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/d67a6255-2423-acd0-03c2-4de5662a3d12.png)

[参考文献:SHORT ETHERNET FRAMES:2021](https://www.ieee802.org/3/ad_hoc/ngrates/public/calls/21_1213/bierschenk_nea_01a_211213.pdf)
以下のようなゾーンアーキテクチャ上のECUで、CAN/LINなどの従来のプロトコルで通信している情報をうまく使いながら、Ethernetに統合するような場合、今回のUpdateは有効と理解した。

![スクリーンショット 2024-12-30 16.26.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/886b1b6a-73e3-7b98-33f3-e8b8fa27631e.png)



## 2.1.1.3 I2CDriver
[Overview]
I2C（インタ・インテグレーテッド・サーキット）は、2線式のシリアルデータバスです。フィリップス・セミコンダクター（現在のNXPセミコンダクター）によって開発されました。I2Cは、シンプルに構成されたバスシステムであり、自動車業界で広く使用されています。

[メモ]
ドライバ層にI2C通信ドライバが追加された。
[LayerdArchitecture](https://www.autosar.org/fileadmin/standards/R24-11/CP/AUTOSAR_CP_EXP_LayeredSoftwareArchitecture.pdf) にも追加されている。
![スクリーンショット 2024-12-31 12.07.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/d459a517-28de-b294-ba87-6a40979fb5f3.png)

[I2C Driver仕様(R24-11)](https://www.autosar.org/fileadmin/standards/R24-11/CP/AUTOSAR_CP_SWS_I2CDriver.pdf)


## 2.1.1.4 DDS Protocols
[Overview]
このコンセプトの目的は、以下の方法を通じてDDSサービス指向通信プロトコルを集中化し、均質化することです：

1. CPおよびAPにおけるDDSのサービス指向利用法を特定すること（例えば、サービスインスタンスの発見および提供されたサービスインスタンスと要求されたサービスインスタンス間の通信）。

1. 利用法をDDSの概念（エンティティ、タイプ、トピック、QoSポリシー）およびメカニズム（標準API呼び出し）にマッピングすること。

1. 必要に応じて、DDSネットワークバインディングまたはAP通信管理機能クラスターをリファクタリングし、マッピングを参照するようにすること。

[メモ]
仕様書の変更履歴には以下と記載されている。詳細までは確認できていない。

・一部の仕様項目の修正/改良
・受信および送信要件の詳細を追加
・リモート参加者に関する説明を明確化
・全ての仕様項目の検証を実施

[DDSの仕様書](https://www.autosar.org/fileadmin/standards/R24-11/CP/AUTOSAR_CP_SWS_DataDistributionService.pdf)