本記事の背景
SOME/IPについて、インプットした内容をまとめる。
目的：SOME/IPについて、何も知らない人がこの記事を見た人が、なんとなくわかった気になること。
※出典にあることを自分なりに解釈してまとめただけです。
正確な情報は、仕様書等を参照ください。
AUTOSAR Adaptive Platformの技術について勉強していかなければならないが、なかなかイメージがつきにくいため、Classic PlatformとAdaptive Platformのどちらでも対応できるプロトコルであるSOME/IPをきっかけに、理解を深めていきたいと考えた。
AUTOSARの仕様書は正直読みずらく、VectorさんのはじめてのSOME/IPや、youtubeの動画解説SOME/IPプロトコルとは - SOME/IPの概要と通信仕様が分かりやすい。概要理解だけならこれを見れば良い。
僕なりの解釈や、もう少し詳細な仕様まで、この記事では記載できればより良いと考えている。時間があるときにちょこちょこ更新していきたい。
更新履歴
2023/06/04 初版(R22-11を反映)
出典
↓ここに参照する仕様のリンクがまとめられている。
AUTOSAR仕様一覧
Specification on SOME/IP Transport Protocol R21-11
Specification of SOME/IP Transformer R21-11
SOME/IP Protocol Specification R21-11
Example for a Serialization Protocol (SOME/IP)
Vector:SOME/IPプロトコルとは - SOME/IPの概要と通信仕様
Vector:サービス指向のソフトウェアアーキテクチャー:
AUTOSAR Classic/Adaptiveシステムのギャップを埋める
次世代車載システム向けサービス指向ミドルウェア SOME/IP-SDの性能評価
背景
Connected（コネクティッド）、Autonomous/Automated（自動化）、Shared（シェアリング）、Electric（電動化）といった、「CASE」と呼ばれる新しい領域で技術革新が進んでいる。（詳細省略）
今後は外部のネットワークと接続し、車両が出荷後も機能をアップデートできるような機能（OTA：Over The Air）が追加され、車がスマートフォン化していくと言われている。
そういう流れの中で、現状の資源や機能をうまく活用していくことが大事だが、ECUの各機能を外部から利用するのは容易ではない。
その課題を解決するため、車にも「SOA：Service oriented Architecture」という設計手法の導入が進んでいる。SOAとは、アプリケーションの処理や機能を「サービス」として切り出して部品化するようなアーキテクチャのことである。
SOAはアプリケーションの機能が「サービス」という形で独立しているため、機能を再利用しやすい点が利点である。
特にドメインコントローラECUなどに適用するAUTOSARのAdaptive Platformにも採用されている設計手法である。
車のスマートフォン化にも迅速に対応できることが狙い。
例えば、以下の図のように、ACC（Adaptive Cruise Control System）とLDW（Lane Departure Warning：車線逸脱警報）の機能を持つECU1があったとして、ACCとLDWは「サービス」という形で独立しているので、例えばリソースの制約で「LDW」をECU1からECU2に移したい場合でも、柔軟に対応できる。
SOME/IP
SOME/IPとは、「Scalable service-Oriented MiddlewarE over IP」の略語で、
SOAに対応する車載通信プロトコルとして開発された。
※BMWが中心となって提案したらしい。AUTOSAR仕様の一部となっている。2011年なので結構前ですね。
TCP/UDPの上位プロトコルとなり、インフォテインメント、周辺カメラシステムなどに適用されている。
SOAのようにECUの機能を「サービス」という単位として定義。
サービスを使用する時は、ネットワーク上にあるサービスを検索し、検知したサービスを組み合わせてシステムを構築する。
SOME/IP通信仕様は主に2種類ある。
-
SOME/IP-SD（Service Discovery）
ネットワーク上にあるサービスを検索して使用する処理。SOME/IP-SDを使用すると、必要な時に必要なサービスを検索して使用するため、ネットワーク上のサービスを動的に参照/使用できる。
クライアントは、サブスクライブしたいイベントグループをサーバーへリクエストする。サーバーはクライアントからのリクエストを受け取り、承認する。EventNotification / Field Notification の2種類の方法でサーバーからクライアントへ値を送信する。 -
Remote Procedure Call
処理の実行を他のソフトウェアに依頼する処理。高負荷な処理を遠隔のバックエンドサーバーなどに依頼できるため、自分自身の処理負荷を軽減できる。
SOME/IP-SD（Service Discovery）
ECU間でどのようなやり取りをするかの仕様は、バージョンは古いが以下を参照するのが分かりやすい。
Example for a Serialization Protocol (SOME/IP)
はじめてのSOME/IPの図9を抜粋：
Remote Procedure Call
Remote Procedure Callの処理はGetter / Setter、Method call、Fire & forgetの3つに分けられる。
SOME/IPプロトコルとは - SOME/IPの概要と通信仕様参照：
使い所：
- Getter / Setter：車載システム上のECUから何か情報を得たい時、設定したいとき（例：ADASカメラの転送レートの取得・変更処理など）
- Method call：処理結果が得たいとき（例：ナビゲーションのルート演算処理を要求するとき）
- Fire & forget：処理結果は不要なとき（例：カーエアコンのスタート・ストップ処理など）
SOME/IP-SDのメッセージフォーマット
-
E2Eなし
-
E2Eあり
-
SD(Service Discovery Format)
-
Entries Array type1
-
Entries Array type2
-
Option Array
実装について
どう実装されるかというと、Adaptive PlatformはC++、Classic PlatformではCでプログラムされる。
Vector:サービス指向のソフトウェアアーキテクチャー:
AUTOSAR Classic/Adaptiveシステムのギャップを埋める 図4参照：
上記のようにAdaptive PlatformではService Interfaceとして用意されているが、
Classic Platformでは、SWC毎のRte Portとして定義されたIF(Client/Server、Sender/Receiverなど)で実装されることになる。
もともと、Classic Platformしかない時代に、AUTOSARのコンセプトとして仮想機能バス（VFB：Virtual Function Bus）を使って下位のECUのハードウェアやネットワーク・プロトコルを意識することなく設計できるというのがAUTOSARの利点の一つと言われていたが、
僕の経験上、Classic Platformの設計をしていくと、部品としてSWCを分解して設計していくことになる。
SWCの持つRte Ifが今回のService Interfaceと粒度が合うかというと、細かすぎるように感じた。
それは設計者があくまで開発対象のECUしか意識できていないからではないかと思う。
開発対象のECUラインナップのみを考慮すれば良いのであればそれで良いが、
今後は、「サービス」として他のECUにも適用できる粒度の設計ができているか、という観点で外部公開IFを検討していくスキルが必要なのかもしれない。
（そんなECU設計ができるような機会は滅多にないだろうけど。。）
気になる点
-
セキュリティ的な問題（車載Ethernet通信において認証や暗号化の対策がされていない）はあるようで、
SDのFind Serviceのメッセージを送信しまくることで、ServiceIDを発見できるような攻撃もあるようだ。
参照：記事：自動車ハッキングのためのSOME/IPサービス列挙 -
動的なネットワークの設計に伴う通信遅延
SOME/IP-SDの動作フェーズの一つである、Initial Wait Phaseでは、ネットワークの負荷軽減のため、「ランダム時間だけ待機する」処理が実装されている。
その設定によっては通信遅延が発生することの研究がなされている。
参照：次世代車載システム向けサービス指向ミドルウェア SOME/IP-SDの性能評価
従って、パラメータ「SdServerTimerInitialOfferDelayMin」「SdServerTimerInitialOfferDelayMax」などを決める際には、ECUの個数やバス負荷設計、サービス開始遅延の閾値など様々な情報をインプットに決めていく必要がある。
