Explanation of Adaptive Platform Design

# 背景
Adaptive Platformについて、自分なりに[R23-11にてリリースされたAUTOSAR_AP_EXP_PlatformDesign](https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_PlatformDesign.pdf)のうち、気になる部分をまとめた内容を記載する。
あくまで気になる部分だけなので、詳細は本文を見てほしい。

※Adaptive Platformは自由度が高いアーキテクチャになっているため、Classic Platformと比べて意図的に詳細まで記載されていないことがある。

※私のようなCP開発に慣れていて、動的なOSの開発経験がないようなポンコツ技術者にとってはハードルが高い:frowning2:

# 参考文献
※3章までの概要は以下を参照するとわかりやすい。
[AUTOSAR Adaptive Platformとは（ヴィッツの紹介ページ）](https://www.witz-inc.co.jp/technology/autosar.html)

# 4 Architecture

## 4.1 Logical view
アダプティブアプリケーション（AA）は、ARA（AUTOSAR Runtime for Adaptive applications）上で動作する。
ARAは、下記のいずれかに属するFunctional Clusters（FC）が提供するインターフェースで構成されている。
1. Adaptive Platform Foundation：基本サービスを提供
1. Adaptive Platform Services：プラットフォーム標準サービスの提供
1. Standard Application/Interfaces：標準化されたアプリケーションまたはインタフェース
1. Vehicle Services：車両レベルのサービスを提供

![スクリーンショット 2024-01-06 12.04.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/699e0c2a-7e17-4e27-34eb-05d8c4cd8eeb.png)

* AAは、どのFCの機能か意識する必要はない。
* 今後のリリースでFCが追加されていく可能性あり。
* (要確認)Platform Foundationと、Platform Serviceをどう分類しているのかいまいち理解できていない。
* C++標準ライブラリもARAの一部として利用可能。
OS API については、POSIX 標準のシングルプロセスプロファイルであるPSE51インタフェースのみが ARA の一部として利用可能。

PSE51：組み込みリアルタイムシステムの目的で作成されたPOSIXのサブセット。

## 4.1.2 Supported protocols, safety and security features
APは、以下のようなプロトコル、安全性、セキュリティ機能をサポートしている。

* サポートしているプロトコル
![スクリーンショット 2024-01-06 12.13.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/c4ac1c79-1635-8616-14ef-787418e3e48c.png)

以前紹介した[SOME/IP](https://qiita.com/issykatsu/items/76bf1e65776049b7462b)プロトコルや、TCP/UDPなどもある。

* 安全機能
![スクリーンショット 2024-01-06 12.21.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/cfe2e893-a3b4-0e2d-3811-9106953d6349.png)
ウォッチドッグ機能はPlatform Health Managementが対応。


* セキュリティ機能 
![スクリーンショット 2024-01-06 12.23.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/8b820552-7300-624d-ed54-06099a3be5f2.png)

CPでも存在していたSecOCはCommunication Management、侵入検知（IdsM）や、CryptographyはCP同様独立して存在。




## 4.1.4 Application launch and shutdown
アプリケーションのライフサイクルは、Execution Management（EM）によって管理される。
アプリケーションのロード/起動は、EMの機能を使って管理され、アプリケーションを起動するには、システム統合時または実行時に適切なコンフィギュレーションが必要。
EMから見ればすべてのFCがアプリケーションであり、EM自体を除けば同じ方法で起動される。

注意：アプリケーションの起動や終了の決定がEMによって行われるのではなく、State Management（SM）と呼ばれる特別なFCがコントローラであり、システムの設計に基づいてEMを制御し、異なるステートの調停・システム全体の動作を制御する。

# 6 Execution Management（EM）
EMは、アダプティブプラットフォームの初期化やプロセスのスタートアップ/シャットダウンを含む、システム実行管理の全てを担当する。

マシンが起動すると、OSが初期化され、EMがプラットフォームの初期プロセスとして起動する。
Adaptive Platform Foundationの他のプロセス（FC）は、EMによって起動されます。Adaptive Platform Foundationが稼働した後、EMはAdaptive Applicationのプロセスを起動し続ける。
EMはマシンマニフェストと実行マニフェストで指定された依存関係に基づいて、プロセスの起動順序を決定する。
![スクリーンショット 2024-01-06 22.42.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/5fdc17ce-7fee-6d20-1039-311f260304b8.png)

* Trasted Platform(詳細は6.5章参照)
EMはオプションで、トラストアンカーから信頼の連鎖を維持しながらAdaptive Platformを開始する、認証されたスタートアップをサポートする。
認証されたスタートアップの間、実行管理はアプリケーションの真正性と完全性を検証し、違反が検出された場合は（オプションで）その実行を阻止する。
これらのメカニズムにより、Trasted Platformを確立することができる。


## 6.3 Execution Management Responsibilities
EMができること：
1. プラットフォームライフサイクルの立ち上げ 
EMはAPの起動フェーズの一部として起動し、APとデプロイされたアプリケーションの初期化を担当。
1. アプリケーションライフサイクル管理 
EMは、デプロイされたアプリケーションのスタートアップとシャットダウンの責任を負う。
EMは、実行依存関係に基づいて起動/シャットダウンの順序を決める。
1. 状態管理サポート 
Platformのスタートアップ後、EMはプラットフォームとアプリケーションのライフサイクル管理を制御するサービスをSMに提供。

# 7 State Management
State Management（状態管理）は、主にECU（電子制御ユニット）開発プロジェクト固有なFCであり、最終的な実装はシステムのインテグレータによって行われる。
プロジェクトのニーズ（入力イベントの処理、これらのイベント/リクエストの優先順位付け、それに対応する内部状態の設定など）に応じて、State Managementは1つ以上のステートマシンで構成される。

State Managementは、プロジェクト固有のara::comサービスインターフェースを介してAdaptive Applicationsと連携する。

SMができること：
• FunctionGroupsを特定の状態に設定するよう要求
• （部分的な）ネットワークの無効化 or 有効化の要求
• マシンのシャットダウンまたは再起動要求
• 他のAdaptive（Platform）Applicationsの動作に影響を与える
• プロジェクト固有のアクション実行
• Platform Health ManagementまたはEMからの通知に基づいてエラーから復帰
• ダイアグからの要求に基づいて、プロジェクト固有のリセット実行
• UCM（Update and Configuration Management)からの要求に基づいて、ソフトウェアクラスタをインストール、更新、または削除するためのソフトウェアクラスタの準備と検証

State Managementは、ara::comを介して'Trigger'および'Notifier'フィールドを提供する。
SMは基本的に'Trigger'を受け取ると、内部でステートマシン処理を実行し、何かあればその効果を'Notifier'フィールドに提供する。

例：
![スクリーンショット 2024-01-06 23.30.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/54088bb6-d978-02eb-0d5d-b76d5c65850c.png)

SMControlApplicationがSMに対して、Triggerをかける。
このとき、値は「1」なので、状態は「Off」から「Parking」になる。
この状態遷移時のアクションリストには、別の状態遷移や「SMができること」で説明したネットワークの無効化 or 有効化の要求などが設定されている。
そこからEM経由で、プロセスを実行しようとするが失敗し、それをウォッチドッグ相当のPHMが監視しているため、エラーを検知し、状態を「Fallback」状態に遷移させる。

他の機能クラスタやアプリケーションからのSMへのアクセスは、IAM（Identity and Access Management）などによってセキュアにする必要がある。

# 14 Identity and Access Management
Identity and Access Management (IAM)は、特権の分離と、権限昇格攻撃に対する保護を導入している。
IAMは、リソースへのリクエストに対するアクセス制御のためのフレームワークを提供する。
IAMはPDP（Policy Decision Point）とPEP（Policy Enforcement Point）の二つのロジックで、特定のリソースへのアクセスがサブジェクトに許可されているかどうかを検証し、リソースへのアクセスを許可する。
![スクリーンショット 2024-01-07 0.13.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/9dcc0d9f-4dc6-28fa-def2-43dc7a116057.png)
1. サブジェクト(Adaptive Applicationなど)がリソースへのアクセスを要求
1. PEPはPDPにサブジェクトがアクセス権があるか問い合わせる
1. PDPはマニフェストを解析し、サブジェクトの要求がマニフェストと一致するか検証し、結果を返す。