SOME/IP 服務探索、訂閱與 TP：實戰解析

SOME/IP 在 SOA 車載網路中的位置

SOME/IP（Scalable service-Oriented MiddlewarE over IP）是 AUTOSAR 為車內 SOA 通訊定義的中介層協定，承載於 Automotive Ethernet 之上。傳統 CAN / LIN 採用以訊號為中心、PDU 週期廣播的模型；而 SOME/IP 將 ECU 之間的關係抽象為「服務提供者—服務消費者」，與 AUTOSAR Adaptive Platform 的 ara::com 對應。一個服務（Service）由 method、event、field 組成，事件採用 publish / subscribe 語義，並透過 SOME/IP-SD 在執行期完成節點發現。SOME/IP 規範由 SOME/IP Protocol Specification（AUTOSAR FO R23-11）定義，本文以 4.4.0 版為基礎。

訊息類型與通訊模式

SOME/IP 透過 PDU 標頭中的 Message Type 與 Method ID 區分四種通訊模式：

Request / Response：消費者送出 Request，提供者回 Response（同步調用）。
Fire-and-Forget：消費者送出 Request 但不等待 Response（適用於不需確認的命令）。
Notification：提供者主動推播事件給已訂閱的消費者，是 publish / subscribe 的核心。
Error Response：當 Method 執行失敗時取代正常 Response，攜帶 Return Code。

每個 Method 對應一個 16-bit Method ID；事件則使用 Method ID 的高位區段（通常 0x8000 以上）以與 method 區分。

SOME/IP-SD（Service Discovery）是 SOME/IP 的執行期動態發現協定，使用 UDP 多播。基本訊息有：

FindService：消費者尋找特定 Service ID / Instance ID 的提供者。
OfferService：提供者宣告自身可用，定義 IP / Port / 傳輸層。
StopOfferService：提供者下線時通知消費者解除繫結。
SubscribeEventgroup：消費者向提供者訂閱某個 Eventgroup。
SubscribeEventgroupAck / Nack：提供者回覆訂閱結果。

整體流程通常為：

提供者啟動，進入 Initial Wait Phase（隨機延遲，避免廣播風暴）。
進入 Repetition Phase，以遞增間隔重發 OfferService。
進入 Main Phase，以較長的固定週期 (Cyclic Offer) 持續廣播。
消費者收到 Offer 後送出 SubscribeEventgroup。
提供者回 SubscribeEventgroupAck，並開始把 Notification 發送至訂閱端（單播或多播均可）。

定址模型：Service / Method / Event / Eventgroup ID

SOME/IP 訊息以四個 16-bit ID 完成定址：

Service ID：識別服務型別。
Instance ID：同型服務的多執行個體區分（SD 與 endpoint 設定使用，並非 PDU 標頭欄位）。
Method ID / Event ID：Method 與 Event 共用同一欄位，依高位 bit 區分。
Eventgroup ID：訂閱單位。一個 Eventgroup 可包含多個 Event，消費者只需訂閱一次即可取得整組。

對應到 ARXML，這些 ID 由 ServiceInstanceToMachineMapping、ProvidedServiceInstance 與 EventHandler 等元素描述，KITE Pulse 透過 autosar-data crate 解析後填入資料庫樹。

PDU 標頭欄位與 Endianness

SOME/IP 標頭固定 16 bytes，Big-endian（network byte order）：

欄位	寬度	說明
Service ID	16	服務識別
Method ID	16	Method 或 Event ID
Length	32	從 Request ID 起算的剩餘長度
Client ID	16	區分同一節點的多個 client（Request ID 上半）
Session ID	16	對話流水號（Request ID 下半）
Protocol Version	8	目前為 `0x01`
Interface Version	8	服務介面版本
Message Type	8	Request / Response / Notification / Error / TP 變體
Return Code	8	`E_OK` 或錯誤碼

Payload 以 little-endian 或 big-endian 編碼依 ARXML 定義，並非由 SOME/IP 規範強制；解碼端必須以資料庫設定為準。

SOME/IP-TP 分段

當 Payload 超過單一 UDP datagram 容量（通常以 1400 bytes 為實作上限）時，必須使用 SOME/IP-TP 分段：

Message Type 加上 0x20 bit 表示為 TP 變體（例如 RequestTp、NotificationTp）。
標頭尾端附加 4 bytes 的 TP header：高 28 bits 為 Offset（以 16 bytes 為單位，避免溢位），低 1 bit 為 More Segments flag（簡稱 More Flag）。
接收端依 Service / Method / Client / Session ID 將分段重組為原始訊息，最後一段 More Flag 為 0。

TP 不提供重傳，可靠性由上層或 TCP（若選用 TCP transport）處理。

在 KITE Pulse 上實測 SOME/IP

KITE Pulse 內建完整 SOME/IP 堆疊，常用流程如下：

載入 ARXML：將描述服務、事件群與 endpoint 的 ARXML 拖入 DatabasePanel，工具會以 autosar-data 解析並列出 Service / Eventgroup 階層。
開啟 Ethernet 通道：在 ExplorerPanel 中對 NIC 呼叫 open_eth_channel，以便接收 SD 多播。
觀察 Service Discovery：PacketDecodePanel 會把多播 SD 訊息拆解為 Find / Offer / Subscribe 等項目，可確認提供者的 IP / Port 是否符合預期。
訂閱 Eventgroup：以 node_someip_subscribe Tauri 指令對指定 Service / Instance / Eventgroup 發送 SubscribeEventgroup，並在 TracePanel 觀察 Ack。
解碼 Notification：訂閱成功後，提供者推送的 Notification 會以 ARXML 中的型別自動解碼為訊號值，可拖入 SignalPanel 即時繪圖。
錄製為 BLF：以 start_recording → save_recording 將整段 SOME/IP 流量保留為 .blf，供後續離線檢視。

需要扮演提供者時，可改用 node_someip_init 與 node_someip_offer 指令。

常見問題

多播位址設定：SOME/IP-SD 預設使用 IPv4 administratively-scoped multicast（常見為 239.x.x.x 範圍）；實際位址由 ARXML 中的 SD configuration 決定，工程必須確保交換機未過濾對應的 IGMP group。

初始 Wait Phase 沒看到 Offer：規範要求提供者在啟動後等待一個隨機延遲再進入 Repetition Phase。若整段觀察視窗短於該延遲，可能會誤判為「服務未上線」，建議延長觀察時間或檢查 SD 設定中的 InitialDelay 範圍。

Repetition Phase 間隔：該階段的初始間隔與最大重複次數由 ARXML 中的 InitialOfferBehavior 決定；之後每次 OfferService 之間的間隔通常以 2 倍方式遞增，最終切換至 Main Phase 的固定 Cyclic Offer。在偵錯網路發現問題時，比對 Repetition / Main 兩階段的時序可快速定位「offer 出去卻無人接收」與「subscribe ack 漏回」的差異。