車載網絡技術--SOME

文章目錄

- 前言
- SOME/IP概念
- SOME/IP協議格式
- SOME/IP功能介紹
- - 序列化
  - - 序列化規則
  - 發布和訂閱
  - 服務發現（SOME/IP-SD）
  - SOME/IP-TP協議使用場景
  - - SOME/IP-TP協議
- 參考文章：

前言

本文介紹了SOME/IP協議的具體內容，包括報文格式，協議選擇、序列化、服務發現等。同時介紹了SOME/IP-TP協議。

SOME/IP概念

SOME/IP是一種汽車中間件解決方案，SOME/IP全稱：Scalable service-Oriented MiddlewarE over IP（位于IP協議蹭之上的一種面向服務的可擴展的中間件），是一種基于以太網的協議，提供面向服務的接口。由寶馬集團在2011年設計開發，并在2014年集成進AUTOSAR4.X中。并且是唯一已知的集成到AUTOSAR 4.x版本中的中間件。

SOME/IP協議是在IP層之上的，屬于應用層協議。

為什么需要SOME/IP？

傳統汽車協議的局限性：傳統的汽車協議如 CAN、MOST、LIN 和 Flexray 等，存在帶寬有限的問題，難以滿足現代汽車日益增長的高數據傳輸需求。基于IP網絡，SOME/IP能夠利用現有的IP網絡基礎設施，提供服務發現、描述、配置以及調用等功能
SOME/IP的可擴展性：SOME/IP能夠實現不同硬件平臺，不同操作系統或嵌入式固件之間的可擴展和互操作

SOME/IP協議格式

SOME/IP協議由消息頭(header)和數據段(payload)組成。

message ID是唯一的。前16位標識服務，后16位標識方法
1. 對于Method，Method ID的第一位為0，對于Event，Method ID的第一位為1

Length(32 bit)標識后續的Request ID到payload的字節長度。
Request ID(32 bit)由2個字節的Client ID 和2個字節的Session ID組成。Client ID用于區分使用同一Method的不同客戶端，session ID由數據的發送方每發送一次數據+1，從0x1加到0xffff后，從1重新開始，用于區分每一條消息

client ID只有兩個字節，能夠同時支持多少客戶端？支持65536個

Protocol Version協議版本號，目前該值為1
Interface Version接口版本號，一般由服務者提供者定義
Message Type 用于標識消息的類型，例如Error，REQUEST, RESPONSE等

Return Code用來標識請求是否被處理
payload長度可變，攜帶的是真正的數據

說明：

SOME/IP報文可以選擇UDP或者TCP進行傳輸。使用UDP時一般payload大小在0~1400字節，大于1400字節時，應當使用TCP對負載分段。

對于TCP和UDP的選擇并非強制，一般來說要求低時延用UDP，數據大用TCP

要求低時延且數據大可以用UDP結合SOME/IP-TP。后文會詳細介紹SOME/IP-TP

SOME/IP功能介紹

SOME/IP支持的中間件功能：序列化、遠程過程調用、服務發現、發布與訂閱。

序列化

序列化指的是講數據結構或對象按照事先定義的規則轉換成可存儲、可傳輸的線性字節流或特定格式文本（如 JSON、XML）的過程。與之相反的逆過程稱為 “反序列化（Deserialization）

在AUTOSAR中，軟件組件將數據從應用層傳遞到RTE層，在RTE層調用SOME/IP Transformer，執行可配置的數據序列化或者反序列化

SOME/IP 不自動插入填充字節，若需對齊（如 32 位數據對齊到 4 字節地址），需用戶在結構體定義時顯式添加保留字段

序列化規則

SOME/IP 不自動插入填充字節，若需對齊（如 32 位數據對齊到 4 字節地址），需用戶在結構體定義時顯式添加保留字段

SOME/IP序列化與反序列采用LTV（Length-Type-Value）格式來進行的。并且Value中包含因字節對齊的填充

LTV的規則并非需要嚴格遵守

數據類型	是否嚴格遵守 LTV	說明	類比
所有基本類型 (uint8, int32, float64, boolean)	否	只有 V。L 和 T 由接口定義隱含。	就像 C 語言中的 `struct { int a; char b; }` ，成員位置和大小固定。
字符串、數組、結構體、聯合體	是	必須包含顯式的 L（長度字段）。T 可能顯式（聯合體）或隱含。	就像網絡協議中的 TLV 或 JSON 中的 `{"key": "value"}`，需要自描述性。

同時為了兼容性，還可以新增一個兩字節的Tag在序列化中。是否使用帶Tag的序列化，取決于對應ARXML文件中的配置。當使用帶有tag的序列化時，即使發送方新增結構體的成員，舊版本的接收方也可以安全跳過不認識的字段，從而實現兼容。

舉例如下：

ECU A（軟件版本 1.0）向 ECU B 發送一個結構體VehicleData，包含speed和rpm兩個成員。
后來，軟件升級了。ECU A 更新到版本 2.0，VehicleData結構體增加了一個新成員 gear。 ECU B 沒有升級（還是版本 1.0），它收到來自版本 2.0 的 VehicleData 消息時，遇到gear對應的tag，會自動跳過解析這個字段。

發布和訂閱

Method方法（請求/響應交互模式）
1. Request/Reponse客戶端發送請求，服務端應答
2. Fire/Forget 客戶端發送請求，服務端不需要應答
Event事件（事件通知模式）
1. 單項數據傳輸，client訂閱Server服務，Server發布信息到Client（當數據變化時才發送，適合實時狀態監控，告警通知等）
Field字段（遠程屬性訪問模式）
1. 分為Notifier、Getter、Setter，分別表示Server向Client主動發送消息、client向server請求數據，以及Client修改Server的數據

一些區別：

Method：是客戶端主動發起的 “請求 - 響應”（如 “查詢當前車速”），只需知道服務地址即可直接調用，無需提前訂閱；
Event 和 Field中的notifier：Event是服務端主動推送的 “通知”（如 “車速超過 100km/h 時自動推送警告”）， Field中的notifier是客戶端必須先通過 SD 服務告知服務端 “我需要接收這些通知”，服務端才會針對性推送。
Field和Event的區別：Field是一個持續存在的變量，如多媒體音量、車速、環境溫度等。這些可以在任何時刻獲取；而Event指的是一個事件，事件沒有就不發生，比如發生碰撞、出現故障等

服務發現（SOME/IP-SD）

SOME/IP-SD（Service Discovery）是 SOME/IP 協議中用于服務發現的一種機制，允許網絡中的客戶端動態地發現和定位服務實例。

SOME/IP-SD服務只能采用UDP的兩點原因：

SD服務需要進行組播，而TCP協議是點對點協議，無法進行組播；
SD服務往往需要快速廣播或組播通知，UDP無連接特性更適合這種場景

功能：

定位服務實例：幫助在車載網絡中確定服務實例的位置，雖然在車載網絡中服務實例的位置通常是已知的，但 SOME/IP-SD 仍能提供更準確和動態的定位信息。
檢測服務實例狀態：能夠檢查服務實例的運行狀態，及時了解服務是否可用。
實現發布 / 訂閱處理：支持發布 / 訂閱模式，使得消息僅發送給對其感興趣的接收者，提高了通信效率和靈活性。

工作原理：

初始等待階段：服務提供者和客戶端在啟動后，會等待一段時間（在 InitialDelayMin 和 InitialDelayMax 之間隨機）再發送第一條 SD 消息，以避免啟動時的網絡擁塞，允許節點在網絡中穩定后再進行通信。
重復階段：服務提供者和客戶端按照固定的時間間隔（如 100ms 的倍數）重復發送 SD 消息，加快兩者之間的同步速度，確保服務信息的及時更新。
主階段：服務提供者進入周期性發送 Offer Service 消息的階段，客戶端則根據需求發送 Find Service 消息，實現服務的持續發現和動態管理，確保客戶端能夠及時獲取到最新的服務信息。

消息格式：

傳輸協議：SOME/IP-SD 消息通過用戶數據報協議（UDP）發送。
服務 ID：固定為 0xFFFF，表示這是一個服務發現相關的消息。
方法 ID：固定為 0x8100。
長度字段：使用由 SOME/IP 指定的 uint32 長度字段，該字段從長度字段之后的第一個字節開始，一直到 SOME/IP-SD 消息的最后一個字節結束。
客戶端 ID：應設置為 0x0000。

SOME/IP-TP協議使用場景

由于TCP協議需要連接過程，因此針對低時延的數據傳輸，往往采用UDP傳輸數據。而使用UDP傳輸大數據時，例如4M數據。由于UDP頭部的長度采用2字節記錄，因此UDP報文的最大長度約為64K。但其實在數據鏈路層MTU的長度為1500字節，除去頭部占用的字節，大概真正攜帶的數據有1400多字節。因此超過這個字節數就會被IP層被動分片。而采用UDP傳輸時，由于無重傳機制等，任意一個分片丟失都將會導致UDP這次傳輸的數據全部不可用，這是無法接受的。因此在使用UDP傳輸時，一般由應用層主動分片，并配有序號、校驗、重傳的機制。這也是SOME/IP-TP、QUIC等應用層協議處理UDP的思路