【AUTOSAR】Specification of Communication Management（R21-11）を読んでみる（7.1章）

重厚長大機械メーカから転職して、A-SPICEでいうSYS工程（要求仕様作成）における

車載ソフトの開発に関わるようになってから１年くらい。結合試験で色々あって簡単なパケット変換（結局失敗）をしてみてからネットワークおもしろくね？となり、この前ネスペを受けるまでになりました。

SDV時代の車載アプリケーションはAUTOSARという規格に沿ったミドルウェア上で動くようになっています。AUTOSARにはCommunication Managementという通信を管理する機能が定義されているため、通信を理解する上でこの仕様書は読んでみたいところ。

ということで仕様書を上から読んでいってメモを書いていくことにしました。まだ１年の初心者なのでお手柔らかに。あと工程的に実装に関わっておらず、C++とかわかってません。

※アンダーラインは僕の感想です

7 Functional specification

7.1 General description

• Communication Management（以下CM）はAUTOSAR Adaptiveの機能クラスターの一つで、ara（AUTOSAR Runtime for Adaptive Applications）の一部

• CMはアプリケーション間の通信経路の構築及び監視をする。アプリ間というのはローカルの場合もリモートの場合もある

• IPC通信や外部Etherの場合もあるよってこと

• CMの機能は以下

• トランスポートプロコトルスタックとの統合と構成

• ミドルウエア機能（シリアライズ、Service Discovery（以下SD）、通信状態の管理）

• ミドルウェアということでOSとアプリケーションの橋渡しをしてくれる。OSがPOSIXだったら、POSIXの通信機能に乗せていい感じに通信してくれるのがCM

• 上述した通り、通信にはover SOME/IPの外部Etherと、IPC通信があるがアプリ実装で使うAPIは同じ

• ソースコードに書くAPIは同じ、外部EtherでSOMEIP通信したかったら、Manifestに記載してやればいいイメージ。とにかく疎結合な構成を目指しているっぽい

• 図7.1

• 図を見ると、アプリがara::com APIを叩くことで、CMが良きように通信してくれることがわかる

• 注意として、シリアライズ処理はアプリの実行コンテキスト（スレッド）で実施する

• ara::comがシリライズしてくれると思っていたが、そうではない

• ARA APIの設計制約について

• ara::com APIは通信方式や言語バインディングに依存しない

• 外部EhterであろうがIPCでろうが、C++であってもPythonでも同じやということ

• 動的通信をサポートする

No discovery by application middleware, the clients know the server but the

Server does not know the clients. Event subscription is the only dynamic

communication pattern in the application.

• すごい重要なことが書いてある。クライアントはサーバを意識するがサーバはクライアントをケアしない。アプリの通信パターンとして動的なものはEvent Subscriptionのみ

• アプリはService Discovery（SD）のAPIを使ってサービスインスタンスを検索し、使用する

• Manifestで静的な通信経路を記載できた気もするが、基本的にSDによって動的にクライアントがサーバを知り、サブスクライブし、通信をする

• API は、Evebt／Callback方式とpolling方式の両方をサポートしなければならない

• Event/Callback方式は、ハンドラを登録しておいて、メッセージが来たら処理関数が呼ばれる。ポーリングはアプリがメッセージ取得の関数を周期的に呼びだすイメージだが、、、こんなことする必要あるのかとは思った？まあRTEのスタイルと互換を持たせたいっぽい

• 同期的なコールバックベースの通信と非同期な通信の両方に対応すること

• あまり意識していなかったとは言えない...

• E2E保護や通信品質についてはこのAPIの対象外

7.1.2 Design decisions

• ara::com通信はProxyとSkeltonパターンを使用する

• 自分はよくクライアントがProxy、サーバがSkeltonなんて言うけど、厳密さに欠けていた。

• Proxyはクライアントアプリケーションのインスタンスであり、通信の中継を行う

• クライアントから見たフォワードProxy的な...？一般的なProxyと同じ意味っぽい

• Skeltonは提供するサービスをミドルウェアの通信インフラに接続するための仕組み。

• こっちもサーバから見たProxyみたいなもん

• ara::comはデータ受信時にコールバック関数を呼び出す仕組みを実装している

• Eventを受信したら勝手にハンドラを呼んでくれるのでポーリングしなくていい

• zero-copy機能を持っていて、ミドルウェアによるメモリマネジメントも含む

• zero-copyとは...受信データをアプリケーションにコピーせず直接渡すもの。ネットワークバッファをアプリが直接参照することで、スループット向上を図る

• ara::com APIはAUTOSARのサービスモデルと整合している

• サービス、インスタンス、イベント、メソッド等と整合

• APIレベルでフルSDとインスタンスの選択をサポートしている

• ara::comはC++11で導入されたstd::future, std::promiseをサポート

• ara:::comは実際の通信方式を抽象化する

• アプリは通信方式を意識しない

• サービスのバージョン管理をサポートしている

• サービスインターフェースにはMajorバージョンとMinorバージョンが存在。後方互換性がない場合はMajorバージョンを上げる

7.1.3 Communication paradigms

• AUTOSAR AdaptiveではService-Oriented Architecture(SOA)に基づくService-Oriented Communication (SoC)がメインの通信方式

• SoCによってランタイム中に動的に通信経路を確立でき、通信相手を事前に知らなくても通信できる

• サーバはサービスをOfferし、クライアントはFindする。Service Registryによって相手を発見しCallする

• Service Discovery の結果、IPC通信をするか外部Etherを使ったSOME/IP通信をするか決まる

7.1.4 Service contract versioning

• 設計フェーズではサービスインターフェースにメジャーバージョンとマイナーバージョンを持たせる

• 後方互換性のある（Eventの追加など）はまーなーバージョンの変更で対応。後方互換性のない場合は、メジャーバージョンを変更する

• メジャーバージョンの異なるIFはServiceDiscoveryが成立しない

• サービスインターフェースのバージョン管理として、設計フェーズとDeployフェーズの２段階に分けて考えている

• ServiceInterfaceをServiceInterfaceDeploymentで実際の通信仕様にマッピングする

• なのでバージョン違いのServiceInterfaceを複数デプロイすることが可能

• デプロイメントは外部通信の場合は必須。IPC通信など内部通信には必須ではない

• 原則として、バージョンが分かれる時はインスタンスも別れたはず

SWS_CM_99003

• バージョンの互換性の判断は、Service Discoveryフェーズで行われる

7.2 Raw Data Streaming

あまり馴染みがないのでさらっとだけ...

• ara::comのAPIを利用しつつ、SOMEIPを使わずに通信したい場合に使用する

• 例えば非AUTOSARとの通信に使用する

• RawDataStreamインスタンスを作成すると、ソケットを生成して通信してくれる。各種設定はManifestに書くべし

7.3 Communication Group

こちらもあまり馴染みないのでさらっと

• CGは一つのサーバと複数クライアントを持つ

• CGでサーバはブロードキャストとP2P通信が可能

• クライアントは通知に対してACKを返せる

• サーバはlistClients()→戻り値は接続しているClientIDで現在接続しているクライアントの一覧を確認できる

• ユニキャストもできる

• Eventと何が違うの？と思ったが

• App層からサーバに対して明示的にACKを返せる（Method FFを使うこともできそうだが…）

• サーバが接続されているクライアントを確認できる（Eventは送りっぱなし）

• 各種通信方式として

• broadcast()

• message()

• どちらも非同期関数（ara::core::Future）

• response：クライアントからの応答を通知。ClientIDと応答メッセージが含まれる

• CGの場合もClientとServerの接続はOffer, Find Serviceを使用

続きはこちら