Adaptive Platform Release Overview(R24-11)

本記事の目的

AUTOSAR R24-11 (Adaptive Platform)の更新内容がなんとなく理解できること。

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

関連記事：
CPのReleaseOverview
去年のAPのReleaseOverview

参照文書

R24-11 Adaptive Platform Release Overview

2 Summary of Changes in Release R24-11

2.1 Concepts

2.1.1.1 Automotive API

[Overview]
新しい機能クラスターである「Automotive API Gateway」を導入する。これは、VISSプロトコルを使用して車両と標準化されたデータ中心の通信を可能にするインターフェースを提供する。このような機能クラスターは、公開された技術報告書で説明されているVSSデータモデルのARXML表現が必要。

[メモ]
以下に新しいドキュメントがリリースされている。
Explanation of Automotive API

以下の赤枠の部分が新規追加されたFunctional Cluster

「Automotive API」のユースケース：車両とリモートデバイス間の接続

Bluetoothなどでデバイスと車両を接続し、車両信号へのアクセスを可能にする。

メリット：

• 車両固有の技術を隠蔽
  車両ごとの複雑な技術的差異を抽象化し、統一されたアクセス方法を提供。
  例: デバイス側は車両の通信プロトコルやハードウェアの詳細を知らなくても良い。
• モバイルアプリ開発の支援
  車両データへのアクセスが簡略化されることで、アプリケーション開発が容易に。
  例: スマートフォンアプリで燃料残量や車両位置情報を取得。
• 互換性の向上
  車両データを標準的な形式で提供し、異なるメーカーやモデル間でのアプリケーション互換性を促進。

「Automotive API」のユースケース：クラウドベース

車両とスマートデバイス間の遠距離での接続にはクラウドベースのインフラが必要。
Automotive API Gatewayは車両内に配置され、クラウドのVISSサーバーにデータを提供する。

「Automotive API」のユースケース：車両内

Adaptive Applicationや、Non-AUTOSAR ECUとも共存するようなシステムを想定している。

以下、用語説明

・VSS（Vehicle Signal Specification）：
COVESA（Connected Vehicle Systems Alliance）によって策定された車両データの標準化モデルです。これは、車両の速度、タイヤの空気圧、室内灯など、多岐にわたる車両データを一貫して記述・正規化するためのオープンデータモデルとして広く採用されています。

目的：
統一されたデータアクセス:
車両データを、メーカーや車両タイプに依存せず、一貫して扱えるようにします。
→ 例: どのメーカーの車でも「Vehicle.Speed」という信号名で車速データにアクセス可能。
互換性の確保:
VSS標準カタログを使用することで、異なる車両間でも共通部分についての相互運用性を確保します。
柔軟性と拡張性:
メーカー独自のニーズに応じて、標準カタログを拡張・適応可能。標準部分との互換性は維持。

例：

・VISS（vehicle-information-service-specification）：
車両内のセンサーや制御ユニットから取得される情報や信号（車両信号仕様（VSS））にアクセスするためのサービス仕様です。この仕様は、COVESA（Connected Vehicle Systems Alliance）によって策定され、車両データへの標準化されたアクセス手段を提供します。

• Read
  車両信号やデータポイントの現在の値を取得する操作です。
• Update
  車両信号やデータポイントの値を変更する操作です。
• Subscribe
  特定のデータポイントに対する監視を設定し、その値が変化した際に通知を受け取る仕組みです。
• Unsubscribe
  既存のsubscriptionを解除します。

2.1.1.2 Safe API for Hardware Accelerators

※R23-11でも新規にリリースされた。
[Overview]
AUTOSAR Adaptive Platformにおいて、安全なハードウェアアクセラレータの利用のための汎用APIが導入されました。これにより、複雑なアルゴリズムを最も効率的にハードウェアで処理できるようになります。
AUTOSAR APにおける安全なハードウェアアクセラレーションの新しい要件文書が「ドラフト」ステータスで提供されました。また、説明文書は、コンセプトに関連する他のすべての文書との一貫性を保つために改名されました。

[メモ]
関係するドキュメントは3つあります。

以下のEXPには変更点はありませんでした。

以下のドキュメントは、「Minor narrative text updates」とだけ書いてありました。

要件がInitialReleaseになっていたので、要件が明確化されたという感じか。

2.1.1.3 Adaptive Platform Machine Configuration

[Overview]
AUTOSAR Adaptive Platformでのマシン設定におけるM2モデルを使った手法にはいくつかの欠点があります。これを解決するために、新しいモデリング手法が提案されました。この手法は、既存の制限を克服し、専門家がより柔軟に設定を記述できるようにします。

新手法はM2モデルに基づく現在の手法と比べて多くの利点があり、それはTPS APMCで説明されています。ただし、この新しい方法は段階的に導入され、既存のM2モデルは移行期間中も使用可能です。

この新手法の全体像はAUTOSAR Classic Platformの構成モデル（TPS Ecu Configuration）に似ていますが、Adaptive PlatformではClassic Platformで必要な制約が一部なくなり、よりシンプルです。

[メモ]
まず、M1レベル・M2レベルとは何か？
→M1レベルが、実際のターゲットシステム（車両、ECUなど）の構成を具体的に記述したモデルで、具体的な設定値や動作パラメータが含まれる。
それに対してM2レベルが、M1モデルを記述するための構造やルールを定義するメタモデルで、M1を生成するためのテンプレートやガイドラインとして機能する。

M2レベルの例：
ECUConfigSet: ECUの設定全体を表すテンプレート。
→ECUInstance: 個別のECUインスタンスを表現。
　→CANSettings: CAN通信の設定を表す部分。

M1レベルの例：
　EngineECU: エンジン制御用ECUの構成。
　→CANSettings:
　　→IPアドレスは192.168.1.10
　　　CAN通信のボーレートは500,000
　　　CANコントローラーは2つ。

以下が新しくリリースされたドキュメント：

2.1.1.4 DDS Protocols

[Overview]
このコンセプトの目的は、DDSのサービス指向通信プロトコルを中央集権化し、標準化することです。具体的には、以下の内容が含まれます：

1. DDSのサービス指向利用法を特定（ClassicおよびAdaptiveプラットフォームにおけるサービスインスタンス発見や、提供・要求されたサービスインスタンスの通信など）。
2. 利用法とDDSの概念（エンティティ、タイプ、トピック、QoSポリシー）やメカニズム（標準API呼び出し）との対応付けを定義。
3. DDSネットワークバインディングやAdaptive Platform通信管理機能クラスターを再設計し、必要に応じて対応付けを参照するように変更。

[メモ]
更新されたドキュメント

変更点概要：

• IEEE1722のSignal-Service-Translationネットワークバインディングを追加
• AP（Adaptive Platform）とCP（Classic Platform）間のSOME/IPエラー応答に関する相互運用性の問題を修正
• トランスポート障害条件の処理を追加
• MACsec暗号化保護のサポートを追加
• ヘッダーファイルを基にしたAPIテーブルを生成し、ara::comのC++ API記述を改訂
• すべてのara::com APIでエラーコードと違反を統一
• 編集上の修正およびバグ修正を実施

2.1.1.5 Deterministic Communication with TSN

[Overview]
「Extension for AP」では、IEEE1722で規定された一部のトランスポートプロトコル（AAF、61883_IIDC、RVF、CRF、TSCF、NTSCF）のサポートをAdaptive Platform（AP）に導入しました。
アプリケーションはRaw Data Streamsを通じてデータの転送を利用でき、IEEE1722で規定されたトランスポートプロトコル全体がサポートされます。また、アプリケーションはTSCFとNTSCFのトランスポートプロトコルを、IEEE1722でカプセル化されたバスフレーム（CANまたはLIN）をサービスにマッピングすることによって利用できます。

[メモ]

• AAF (Audio/Audio-Visual Transport Protocol)： AAFは、オーディオやオーディオビジュアルデータを転送するためのプロトコル。主に車載システムなどでオーディオコンテンツを効率的に伝送するために使用される。
• 61883_IIDC (IEEE 61883 - IIDC: Industrial Imaging Device Communication)： IEEE 61883は、デジタルビデオやオーディオの転送を規定するための標準。IIDCはその一部で、主に産業用画像処理デバイス間の通信をサポートする。これにより、カメラなどの画像処理機器がデータを交換できるようになる。
• RVF (Real-time Video and File Protocol)： RVFは、リアルタイムでのビデオ転送とファイル転送を効率的に行うためのプロトコルです。車載システムや他の高度なネットワークでのビデオデータの伝送に利用される。
• CRF (Constant Rate Factor)： CRFは、動画圧縮における品質制御のパラメータ。ビデオの品質を一定に保ちながら、データサイズを調整するための方法を定義します。特に動画エンコードでよく使用される。
• TSCF (Transport Stream Control Frame)： TSCFは、トランスポートストリームの制御を行うフレームです。主に通信システムにおいて、データの転送を制御するために使用される。
• NTSCF (Non-Transport Stream Control Frame)： NTSCFは、トランスポートストリームではなく、非トランスポートストリームの制御を行うフレーム。これも通信プロトコルにおいてデータ転送の管理を担う役割がある。