KopherBit
AUTOSAR

SOME/IP サービスディスカバリ・サブスクリプション・TP：実践ガイド

SOME/IP-SD の Find / Offer / Subscribe フローから PDU ヘッダ、エンディアン、SOME/IP-TP の分割まで、KITE Pulse と ARXML を用いた実機キャプチャ手順を交えて Adaptive AUTOSAR の SOA 通信を整理します。

SOA 車載ネットワークにおける SOME/IP の位置づけ

SOME/IP（Scalable service-Oriented MiddlewarE over IP）は、AUTOSAR が定める車載 SOA 通信用のミドルウェアプロトコルで、Automotive Ethernet 上で伝送されます。従来の CAN / LIN は信号中心で PDU を周期送信するモデルですが、SOME/IP は ECU 間の関係をサービス提供者と消費者の関係として抽象化し、AUTOSAR Adaptive Platform の ara::com と対応します。サービスはメソッド・イベント・フィールドで構成され、イベントは publish / subscribe セマンティクスで、ノード探索は SOME/IP-SD によって実行時に行われます。プロトコルの規範文書は SOME/IP Protocol Specification（AUTOSAR FO R23-11）であり、本記事は 4.4.0 を前提とします。

メッセージ種別と通信パターン

SOME/IP は PDU ヘッダの Message Type と Method ID の使い方で 4 種類の通信パターンを区別します：

  • Request / Response：消費者が Request を送信し、提供者が Response を返す（同期呼び出し）。
  • Fire-and-Forget：消費者は Request を送信するが Response を期待しない（応答不要なコマンド向け）。
  • Notification：提供者が購読中の消費者にイベントをプッシュする。publish / subscribe の中核。
  • Error Response：メソッド失敗時に通常の Response を置き換え、Return Code を伝送する。

各メソッドは 16 bit の Method ID に対応し、イベントは同フィールドの上位領域（通常 0x8000 以上）を使ってメソッドと名前空間を分けます。

SOME/IP-SD：Find / Offer / Subscribe フロー

SOME/IP-SD（Service Discovery）は実行時にサービスを動的に発見するためのプロトコルで、UDP マルチキャストを用います。基本エントリは以下の通りです：

  • FindService：消費者が指定の Service ID / Instance ID の提供者を探す。
  • OfferService：提供者が IP / ポート / トランスポートを伴って提供開始を宣言する。
  • StopOfferService：提供者がオフラインになる際に消費者へ通知する。
  • SubscribeEventgroup：消費者が提供者の特定 Eventgroup に購読を要求する。
  • SubscribeEventgroupAck / Nack：提供者からの購読結果。

典型的なフローは次のようになります：

  1. 提供者が起動し、ブロードキャスト輻輳を避けるため Initial Wait Phase（ランダム遅延）に入る。
  2. Repetition Phase に移行し、間隔を伸ばしながら OfferService を再送する。
  3. Main Phase に入り、長めの固定周期で Cyclic Offer を継続する。
  4. Offer を受信した消費者が SubscribeEventgroup を返す。
  5. 提供者が SubscribeEventgroupAck を返し、ユニキャストまたはマルチキャストで Notification の配信を開始する。

アドレッシングモデル：Service / Method / Event / Eventgroup ID

SOME/IP メッセージは 4 つの 16 bit ID で識別されます：

  • Service ID：サービス種別。
  • Instance ID：同じサービス種別の複数インスタンスを区別する。SD とエンドポイント設定で使用される識別子で、PDU ヘッダ内のフィールドではない。
  • Method ID / Event ID：メソッドとイベントが同じフィールドを共有し、上位ビットで名前空間を分ける。
  • Eventgroup ID：購読の単位。1 つの Eventgroup に複数のイベントを束ね、消費者は 1 回の購読で全イベントを受信できる。

ARXML 上では ServiceInstanceToMachineMapping、ProvidedServiceInstance、EventHandler などで定義され、KITE Pulse は autosar-data crate で解析してデータベースツリーに展開します。

PDU ヘッダ構造とエンディアン

SOME/IP ヘッダは 16 byte 固定、ビッグエンディアン（network byte order）です：

フィールドbit 幅内容
Service ID16サービス識別子
Method ID16Method または Event ID
Length32Request ID 以降の残りバイト数
Client ID16同一ノード内の複数クライアントを区別（Request ID 上位）
Session ID16呼び出しごとのシーケンス番号（Request ID 下位）
Protocol Version8現行は 0x01
Interface Version8サービスインタフェースのバージョン
Message Type8Request / Response / Notification / Error / TP 各種
Return Code8E_OK またはエラーコード

ペイロードのエンディアンは ARXML の定義に依存し、SOME/IP 規格として固定されません。デコード側はデータベース定義に従う必要があります。

SOME/IP-TP セグメンテーション

ペイロードが UDP データグラム 1 個の容量（実装上の目安として 1400 byte 前後）を超える場合は SOME/IP-TP によって分割します：

  • Message Type に 0x20 ビットを立てて TP 派生（例：RequestTp、NotificationTp）であることを示す。
  • SOME/IP ヘッダの後に 4 byte の TP ヘッダが付く。上位 28 bit が Offset（オーバーフロー回避のため 16 byte 単位）、最下位 1 bit が More Segments flag を表す。
  • 受信側は Service / Method / Client / Session ID で分割を関連付け、More Flag = 0 のセグメントを最後とみなして再構成する。

TP は再送機構を提供しません。信頼性は上位層、または TCP トランスポート選択時の TCP 自体に委ねられます。

KITE Pulse での SOME/IP 実機キャプチャ

KITE Pulse は完全な SOME/IP スタックを内蔵しており、典型的な手順は次の通りです：

  1. ARXML をロード：サービス、イベントグループ、エンドポイントを定義した ARXML を DatabasePanel にドロップする。autosar-data で解析され Service / Eventgroup の階層が表示される。
  2. Ethernet チャネルを開く：ExplorerPanel から該当 NIC に対して open_eth_channel を実行し、SD マルチキャストを受信できる状態にする。
  3. サービスディスカバリを観測：PacketDecodePanel がマルチキャスト SD を Find / Offer / Subscribe に展開する。提供者の IP / ポート / トランスポートが想定通りかを確認する。
  4. Eventgroup を購読：対象 Service / Instance / Eventgroup に対し node_someip_subscribe Tauri コマンドで SubscribeEventgroup を送信し、TracePanel で Ack の到着を確認する。
  5. Notification をデコード：購読が成立すると、提供者からの Notification は ARXML の型で自動デコードされ、SignalPanel にドラッグしてリアルタイム描画できる。
  6. BLF へ録画：start_recording → save_recording で SOME/IP セッション全体を .blf として残し、後でオフライン解析する。

提供者側として動作させたい場合は node_someip_init と node_someip_offer コマンドを使用します。

よくある質問

マルチキャストアドレスの設定：SOME/IP-SD は通常、管理スコープの IPv4 マルチキャスト（239.x.x.x 範囲）を使用します。実際のアドレスは ARXML の SD configuration で決まり、ネットワーク機器側で対応する IGMP group がフィルタされていないことを担保する必要があります。

Initial Wait Phase に Offer が見えない：規格は提供者起動後にランダム遅延を経て Repetition Phase に入ることを要求しています。観測ウィンドウがその遅延より短いとサービスが見えていないように誤認しがちです。観測時間を延ばすか、SD 設定の InitialDelay 範囲を確認してください。

Repetition Phase の間隔：初期間隔と最大繰り返し回数は ARXML の InitialOfferBehavior によって決まります。OfferService の間隔は通常 2 倍ずつ伸び、最後に Main Phase の長い Cyclic Offer 周期へ切り替わります。発見系の不具合を調べる際は、Repetition と Main の時系列を TracePanel で見比べることで「Offer 自体が出ていない」のか「SubscribeEventgroupAck が返ってこない」のかを切り分けられます。

技術ナレッジへ戻る