Architecture
AUTOSAR_EXP_PlatformDesignの3章をよんでいくぞい。
量が多くて、残りを見ただけで心が折れそう。
Logical View
APのアーキテクチャビューの概要説明。
ARA
ざっと読んだ感じ、大事そうな内容だけを抜粋。
AUTOSAR APで大事なのは以下。
1. AA（Adaptive Application）
→ Adaptive上で動作するアプリケーションのこと。
他のApplicationにサービスを提供する。
2. ARA（AUTOSAR Runtime for Adaptive Application）
→ AAを動かすためのランタイム。Functional Clusterによって
提供されるAPIから構成される。
3. Functional Cluster
→ Adaptive Platform Foundation（Adaptive Platformの他の仕様っぽい）や
Adaptive Platform Services（APの標準的なサービスを提供するもの）等を
含むもの
Language binding, C++ Standard Library, and POSIX API
基本的な言語仕様はC++らしい（ARAでもC++のライブラリが使えるようだ）。
また、OSのAPIはPSE51（POSIX準拠）とのこと。
ただ、C++標準ライブラリはPOSIXベースのAPIを一部包含しているようなので、
C++標準ライブラリとPSE51で同じ機能がある場合（スレッドライブラリ等）は、
プログラム内に混在させないことを推奨している。
言語に関しては、組込みプログラミング＝C言語のイメージが強かったのでちょっと新鮮。
（そういえば、組込み＝C言語ってのはアジア圏で顕著というのを聞いたことがあるような。。。）
Application launch and shutdown
アプリケーションのライフサイクルはExecution Management（EM）が管理しており、
アプリケーションのロード、起動、起動時のコンフィギュレーションをEMがやってくれる。
また、アプリケーションをいつ/どこで起動するか、終了するかはEMの範疇外（State Management（SM）とよばれる、システム全体の状態を管理する機能で行う）
Application interactions
PSE51はIPC（プロセス間通信）を提供していないので、AA間の直接的なやり取りを担うIFはない。
APでは、Communication Management（CM）がこの機能を担い、マシン内、マシン間のService Oriented Communicationを実現する。また、CMはサーバアプリ/クライアントアプリのトポロジの依存関係にかかわらず、サービス要求やサービス応答を行う。
Non-standard interfaces
AAやFunctional Clusterは、プロジェクトの要求を満たしている、AP以外の（標準化されていない）IFを使って実装されている場合があるが、APの移植性に影響するので、最小限にすべきである。
Physical View
APのPhysical Viewについて述べるよ。
OS，Process，and threads
マルチプロセスのPOSIX OSを利用するために、APのOSは「必須」である。各AAは、メモリ空間やNamespaceが論理的に独立したプロセスとして実装される。ひとつのAAが複数のプロセスを包含していてもよい。
（ここにいろいろ書いてあるが、次の文章に集約されるので省略）
OSの観点からすると、APとAAは、単に1つ以上のスレッドを持ったプロセス群である。それぞれのプロセス間に違いはなくAPの実装次第である。プロセスはIPCもしくはOSの機能を使って互いに通信できるが、AAはARAを介してのみ通信ができる点に注意すること。
Library-based or Service-based Functional Cluster implementation
AAはOS上のプロセスなので、AA間で強調動作を実現するにはプロセス間通信を使わざるを得ない。
しかし、以下のいずれかの設計を採用することで、対応が可能である。
- Functional Clusterをライブラリ化し、AAにリンクする設計（Library-basedな設計）
- サーバプロキシのライブラリをAAにリンクし、プロキシライブラリがCMの機能を利用する設計（Service-basedな設計）
Functional Clusterをいずれの設計にするかは、以下の方針に従うとよい
- APのインスタンス内でのみ使われる場合 -> Library-based
- APのインスタンス外でも使われている ｰ> Server-based
なお、Adaptive Platform FoundationのFunctional ClusterはLibrary-basedで、Adaptive Platform ServiceはServer-basedで作成されている。
The interaction between Functional Clusters
通常、AP同士は、実装依存の何らかの方法で互いに強調しあって動作しているため、IPCは厳密に使用する必要がある。publicとかprotectedのメソッドをIFはにすることでこのあたりをうまくやってくれ、とのこと。
また、一個前の仕様（AP18-03）でIFC（Inter-Functional-Cluster）の概念が導入され、Functional Clusterが他のFunctional ClusterにIFを提供できるようになった。（ただし、これはARAの範疇外＋厳密なAPの仕様ではない）
Machine/Hardware
APは、自身が動作するHW（実マシンや仮想化環境などは問わない）を保護する。
なんか他にも色々と書いてあるけど、結局これが大事っぽい。
どう保護するのかはわからないが。。。
Methodology and Manigest
個々のAAの独立性やアジャイル開発をサポートするために、APでは作業成果物（たとえば、サービス、アプリケーション、マシン、およびそれらの構成など）を標準化している。
MANIFEST
なんか色々と御託が並んでいるが、つまるところ以下（に関連する？）のことらしい。Manifestの定義はぱっと見た感じ存在しないので、Classic Platformを見たほうがいいのかなぁ。。。
- Application Design
- Execution Manifest
- Service Instance Manifest
- Machine Manifest
Application Design
AUTOSAR APのアプリケーションの作成に関連するアプリ設計に関連する仕様を記述するもの。AP Machineの開発には必要ではないが、Execution ManifestやService Instance Manifest内のアプリケーションの開発に必要な定義の設計を目的にしている。
Execution Manifest
AUTOSAR AP上で動作するアプリの開発に関連した仕様。Execution Manifestは実行ファイルに含まれるかたちで提供され、実行コードをMachine上にインテグレーションするために利用される。
Service Instance Manifest
サービス思考の通信機能に関する設定を定義する。Service Instance Manifestは実行コードに紐付けられ、サービス思考通信を使うという観点で実装される。
Machine Manifest
APが動作するMachineの開発に関連した仕様を記述するManifest。AUTOSAR APのインスタンスを生成するSWに紐付けられる。
Application Designや、異なる種類のManifestに加え、（なんやかんやいろいろあって）AUTOSARは、Software Componentの存在により、System Designをサポートできる。
以降の節で詳細が記述されることを期待して、省略。
Application Design
Application Designには、アプリケーションの作成に適用するための設計に関連したモデリングを記述する。Application Designは以下にフォーカスしている。
- ソフトウエアの設計と実装のためのデータ型
- サービス思考通信の中心となる要素となるService Interface
- アプリがアクセス可能なサービス思考通信方法の定義
- Persistent DataやFileへのアクセスの中心となるInterface
- アプリケーションがPersistent Storageにアクセスする方法
- アプリケーションがFileにアクセスする方法
- アプリケーションが暗号化ソフトにアクセスする方法
- アプリケーションがPlatformのHealth Managementにアクセスする方法
- アプリケーションがTime Baseにアクセスする方法
- ネットワークに伝送されるデータをSerializeにするためのプロパティ
- Webサービスと通信する中心の要素になるREST Service Interface
- ClientとServerの能力定義
- ソフトウエア開発を用意にするためのアプリケーションのグループ化
Execution Manifest
Execution Manifestの目的は、「AUTOSAR AP上のアプリケーションの開発に必要な情報を提供すること」である。Execution Manifestがあると、以下のことができるようになる。
- 同一マシン上で、同一アプリを複数回インスタンス化できるようになる
- 複数のマシンにアプリをデプロイできるようになり、マシンごとにアプリをインスタンス化できるようになる
Execution Manifestは以下の点にフォーカスしている
- アプリのインスタンスが開始する方法を定義するためのStartup Configuration
- Resoure Groupが割り当てるResource Management
Service Instance Manifest
サービス思考通信を実装するためには、汎用的な通信技術（SOME/IPなど）の仕様を設定する必要がある。Service Instance Manifestは以下にフォーカスしている。
- 特定の通信技術上のServiceを示す方法を定義するためのService Interfaceのデプロイ
- Service Instanceが要求する通信技術の資格情報に関する仕様を定義するためのService Interfaceのデプロイ
- E2E Protectionの設定
- Security Protectionの設定
- Log and Traceの設定
Machine Manifest
特定のハードウエアで動作しているAdaptive Platformのインスタンスに関する設定をするもの。
以下にフォーカスしている。
- Network ConnectionのConfiturationと、基本的な証明書の定義
- Service Discoveryに関する設定
- Machineの状態に関する定義
- 機能グループに関する定義
- Adaptive Platformの機能クラスタの実装に関する定義
- 暗号化モジュールに関する定義
- Health Managementに関する定義
- 時刻同期に関する定義
- 利用可能なHardware Resourceに関する記述