1. Introduction （引言）

• 主要內容

  • 服務發現協議的主要任務：
    • 在車載通信中傳達被稱為服務的功能實體的可用性。
    • 控制事件消息的發送行為，實現僅向需要的接收者發送事件消息（即發布/訂閱功能）。

• 協議目的和目標

  • SOME/IP-SD用于以下方面：
    • 定位服務實例：幫助在車載網絡中確定服務實例的位置。
    • 檢測服務實例是否運行：能夠檢查服務實例的運行狀態。
    • 實現發布/訂閱處理：支持發布/訂閱模式，這是一種高效的消息傳遞機制，使得消息僅發送給對其感興趣的接收者。

• 依賴關系

  • 對其他協議層的依賴
    • SOME/IP-SD依賴于SOME/IP協議。SOME/IP本身支持TCP和UDP通信，但SOME/IP-SD被限制僅在UDP上使用SOME/IP。

2. SOME/IP Service Discovery (SOME/IP-SD)

2.1 General（概述)

• SOME/IP-SD用途包括定位服務實例、檢測服務實例是否運行、實現發布/訂閱處理。
• 在車載網絡中，服務實例的位置通常是已知的（可能是因為車輛網絡的架構相對固定，或者在系統設計和配置階段已經預先確定了各個服務實例的大致位置信息），所以服務實例的狀態是主要關注點，而服務的位置（如IP地址、傳輸協議和端口號）是次要關注點。
  ~ ?
  ~ ?
  ~ ?
• 如果一個服務實例需要在多個接口上提供服務，那么每個接口應使用一個單獨的服務器服務實例。
  • 智能家居燈光控制示例：智能燈光控制服務需通過不同接口控制燈泡。Wi-Fi接口上，手機等設備通過智能家居APP控制燈光，為此設一個服務器服務實例，按Wi-Fi協議處理手機APP請求并控制燈泡；Zigbee接口上，智能開關控制燈光，為其單獨設服務器服務實例，依Zigbee規范處理開關信號來控制燈泡，兩實例互不干擾，保障服務穩定。
• 如果一個服務實例需要配置為通過多個不同接口進行訪問，那么每個接口應使用一個單獨的客戶端服務實例。
  • 工業自動化數據采集示例：生產數據采集服務要從不同設備獲取數據。以太網接口，高端檢測設備連工廠網絡，為其配客戶端服務實例，按以太網標準與設備通信獲取檢測數據；RS485接口，老舊傳感器等設備提供基礎數據，為其設單獨客戶端服務實例，依RS485規范獲取數據，兩實例適應不同接口特性，確保數據采集準確。

2.2 SOME/IP-SD Message Format

2.2.1 通用要求

• 傳輸協議：明確規定SOME/IP - SD消息應通過用戶數據報協議（UDP）發送。
  

  • 服務發現消息應使用特定的服務ID（16位，值為0xFFFF）。
  • 應使用特定的方法ID（16位，值為0x8100）。
  • 使用由SOME/IP指定的uint32長度字段，該字段從長度字段之后的第一個字節開始，一直到 SOME/IP - SD 消息的最后一個字節結束。
  • 由于僅存在單個SOME/IP - SD實例，客戶端ID（16位）應設置為0x0000。
  • 如果配置了客戶端ID前綴，它也應適用于SOME/IP - SD。
  • 服務發現消息應具有會話ID（16位），并根據SOME/IP要求進行處理。
  • 會話ID（SOME/IP頭部）對于發送的每條SOME/IP - SD消息應遞增。
  • 會話ID（SOME/IP頭部）應從1開始，即使在回繞后也應為1。
  • 會話ID（SOME/IP頭部）不應設置為0。
  • SOME/IP - SD會話ID處理是按“通信關系”進行的，即每個對等方的廣播和單播。
    • 廣播示例
      • 車載網絡里，車輛控制系統向多個車載娛樂系統、傳感器廣播系統更新通知，分配會話ID 1001，接收方據此識別消息，后續廣播時發送方按規則遞增會話ID來維持有序通信。
    • 單播示例
      • 車載導航系統向路況信息服務獲取數據，發起請求時用會話ID 2001，服務按此知曉請求來源并回復含相同ID的響應，后續導航系統再請求就遞增ID（如2002），保證通信準確、可追溯。
  • 服務發現消息的協議版本（8位）應為0x01。
  • 接口版本（8位）應為0x01。
  • 消息類型（8位）應為0x02（通知）。
  • 返回碼（8位）應為0x00（E_OK）。

2.2.2 SOME/IP-SD Header

• Flags字段：
  
  • Reboot Flag（重啟標志）
    • 重啟標志在重啟后的所有消息中應設置為 1，直到 SOME/IP - Header 中的 Session - ID 再次從 1 開始循環，之后重啟標志設置為 0。
    • 重啟標志和 Session ID 的信息應分別為多播和單播單獨保存。
    • 重啟標志和 Session ID 的信息應針對每個發送者 - 接收者關系（即源地址和目的地址）分別保存。
    • 重啟的檢測應按如下方式進行（使用來自通信伙伴的當前數據包的新值和之前接收的最后一個舊值）：
      • 如果舊的 reboot == 0 且新的 reboot == 1，則檢測到重啟。
      • 如果舊的 reboot == 1 且新的 reboot == 1 且舊的 session_id > 新的 session_id，則檢測到重啟。
      • 如果新的 reboot == 1 且舊的 session_id > 新的 session_id，則檢測到重啟，這個是不可靠的。
  • 示例

    • 場景1 簡單重啟檢測

      • 初始狀態：車載信息娛樂系統重啟前，儀表盤系統記錄其最后一條消息中，reboot值為0，session_id為50。
      • 重啟后：信息娛樂系統重啟完成發送第一條消息，此時reboot值變為1，session_id變為1。
      • 檢測規則應用：根據規則“若舊reboot == 0且新reboot == 1，則檢測到重啟”，儀表盤系統可明確知曉信息娛樂系統已重啟。

    • 場景2 復雜重啟檢測

      • 初始狀態：車載通信系統重啟前，車載診斷系統記錄其最后一條消息中，reboot值為1，session_id為100。
      • 重啟后：通信系統重啟后發送第一條消息，reboot值仍為1，session_id變為90。
      • 檢測規則應用：依據規則“若舊reboot == 1且新reboot == 1且舊session_id >= 新session_id，則檢測到重啟”，診斷系統可判定通信系統已重啟。通過這些量化的數值變化及相應規則，能夠精準地檢測出系統的重啟情況，為車載網絡的穩定運行和故障排查提供了明確的依據和標準。
  • Unicast Flag 標識
    • 在所有 SD 消息中，該標志應設置為單播，即值為 1。這表明接收端支持使用單播方式接收消息，確保消息能夠準確地發送到特定的接收端。
    • 這一規定確保了在 SOME/IP - SD 協議的通信過程中，發送方能夠明確知道接收方是否支持單播接收。如果接收方不支持單播，可能會導致消息無法正確接收或處理，從而影響整個服務發現和通信的流程。通過這個標志位的設置，雙方能夠在通信前就對接收方式達成共識，保證通信的順利進行和數據的準確傳輸。
  • Explicit Initial Data Control Flag
    • 在新的版本中，該標志應該總是被設置為 1，表示支持顯式初始數據控制這一特性，以滿足特定的服務發現和數據交互需求。
    • 示例：
      在智能汽車電子系統中，有發動機控制單元（ECU1）、剎車控制單元（ECU2）、車身控制單元（ECU3）等。這些ECU通過SOME/IP - SD協議通信和服務發現，協同工作保障汽車正常運行與功能實現。
      • 汽車啟動時：各ECU初始化并建立通信連接。
      • ECU1操作與判斷：
        • ECU1需向其他ECU發發動機初始狀態信息。
        • 查看ECU2的Explicit Initial Data Control Flag，假設其為1（較新版本，支持顯式初始數據控制）。
        • ECU1向ECU2發送數據：
          • 在Eventgroup Entries中設Initial Data Requested Flag，指示是初始數據請求。
          • 詳細發送發動機初始狀態，如轉速1000轉/分鐘、溫度80攝氏度、燃油壓力3.5巴等。
          • ECU2接收后，因Explicit Initial Data Control Flag為1，能識別并按規則存儲處理，若發動機初始轉速高，可相應調整剎車系統預壓力。
        • 查看ECU3的Explicit Initial Data Control Flag，假設其為0（較舊版本，不支持）。
        • ECU1向ECU3發送簡單狀態碼“發動機正常啟動，狀態碼：001”，ECU3接收后僅知發動機正常啟動，不會接收詳細數據，避免因無法處理復雜數據而出錯。
• Reserved字段：
  • 位于 Flags 之后，是一個 24 位的 Reserved（保留）字段，為將來可能的擴展或協議兼容性預留空間，當前協議實現中暫未使用。
• Entries Array 與 Options Array 字段:
  • Entries Array：在 SOME/IP - SD Header 之后是 Entries Array，其中的條目需按到達順序處理，包含服務發現過程中的服務提供、訂閱等關鍵信息。
  • Options Array：Entries Array 之后是 Options Array，這兩個數組都以 uint32 類型的長度字段開始，用于統計后面數據（條目或選項）的字節數，方便接收方準確提取和處理數據。

2.2.3 Entry Format

• Service Entry Type（服務條目類型）：
  • 規定其大小為16字節，包含以下字段（按下圖順序）：
    
    • Type Field（類型字段）：uint8類型，編碼FindService（0x00）和OfferService（0x01）等操作。
    • Index First Option Run（第一個選項運行索引）：uint8類型，指示在選項數組中第一個運行的選項的索引。
    • Index Second Option Run（第二個選項運行索引）：uint8類型，指示在選項數組中第二個運行的選項的索引。
    • Number of Options 1（選項1的數量）：uint4類型，描述第一個選項運行使用的選項數量。
    • Number of Options 2（選項2的數量）：uint4類型，描述第二個選項運行使用的選項數量。
    • Service - ID（服務ID）：uint16類型，描述該條目所涉及的服務或服務實例的服務ID。
    • Instance ID（實例ID）：uint16類型，描述該條目所涉及的服務實例的服務實例ID，若一個服務的所有服務實例都相關，則設置為0xFFFF。
    • Major Version（主版本）：uint8類型，編碼服務（實例）的主版本。
    • TTL（生存時間）：uint24類型，以秒為單位描述條目的生存時間。
    • Minor Version（次版本）：uint32類型，編碼服務的次版本。
• Eventgroup Entry Type（事件組條目類型）：
  • [PRS_SOMEIPSD_00270]指出其大小也為16字節，包含以下字段（按下圖順序）：
    
    • Type Field（類型字段）：uint8類型，編碼Subscribe（0x06）和SubscribeAck（0x07）等操作。
    • Index First Option Run（第一個選項運行索引）：uint8類型，指示在選項數組中第一個運行的選項的索引。
    • Index Second Option Run（第二個選項運行索引）：uint8類型，指示在選項數組中第二個運行的選項的索引。
    • Number of Options 1（選項1的數量）：uint4類型，描述第一個選項運行使用的選項數量。
    • Number of Options 2（選項2的數量）：uint4類型，描述第二個選項運行使用的選項數量。
    • Service - ID（服務ID）：uint16類型，描述該條目所涉及的服務或服務實例的服務ID。
    • Instance ID（實例ID）：uint16類型，描述該條目所涉及的服務實例的服務實例ID，若一個服務的所有服務實例都相關，則設置為0xFFFF。
    • Major Version（主版本）：uint8類型，編碼該事件組所屬的服務實例的主版本。
    • TTL（生存時間）：uint24類型，以秒為單位描述條目的生存時間。
    • Reserved（保留）：uint8類型，應設置為0x00。
    • Initial Data Requested Flag（初始數據請求標志）：1位（I Flag），若服務器應發送初始數據，則應設置為1。
    • Reserved2（保留2）：uint3類型，若未另行指定，則應設置為0x0。
    • Counter（計數器）：uint4類型，用于區分同一訂閱者的相同訂閱事件組，若不使用，則設置為0x0。
    • Eventgroup ID（事件組ID）：uint16類型，傳輸事件組的ID。
• 條目引用選項相關內容 ：
  • Index First Option Run（第一個選項運行索引）：用于指示第一個選項運行在選項數組中的位置，索引0表示是SOME/IP - SD數據包的起始位置。
  • Index Second Option Run（第二個選項運行索引）：與第一個選項運行索引類似，用于指示第二個選項運行在選項數組中的位置，索引0同樣表示數據包的起始位置。
  • Number of Options 1（選項1的數量）：表示第一個選項運行的長度，若長度為0，則該選項運行中無選項。
  • Number of Options 2（選項2的數量）：表示第二個選項運行的長度，長度為0時，該選項運行無選項。
  • 存在兩種選項運行的原因及優勢

    • 存在First Option Run（第一個選項運行）和Second Option Run（第二個選項運行）兩種不同的選項運行。原因是預計有兩種不同類型的選項：一種是多個SOME/IP - SD條目間共有的選項，另一種是每個SOME/IP - SD條目特有的選項。支持這兩種選項運行是最有效的方式，既能滿足不同類型選項的需求，又能保持線格式的高效性。

    • 智能家居場景

      • 多個條目間共有的選項（First Option Run）：
        • 場景：智能照明服務與智能手機APP、智能音箱、智能控制面板等交互，各設備需燈光開關、亮度調節、顏色模式等通用控制選項，這些可被多SOME/IP - SD條目共享。
        • 示例：Index First Option Run 為 5 ，Number of Options 1 為 3 ，選項有開關（0 關 1 開）、亮度（0 - 100%）、顏色（0 白 1 暖光）。
      • 每個條目不同的選項（Second Option Run）：
        • 場景：智能手機APP有定時開關、音樂節奏燈光閃爍模式等個性化選項；智能音箱有喚醒詞、語音指令優先級、語音反饋音量等專屬選項，它們依設備特性適用于特定條目。
        • 示例：智能手機APP，Index Second Option Run 為 10，Number of Options 2 為 2，含定時開關時間、音樂節奏燈光閃爍模式；智能音箱，Index Second Option Run 約 12，Number of Options 2 約 3，含喚醒詞、優先級、反饋音量。

2.2.4 Options Format

• 用途：向條目傳輸如服務實例可達性（IP地址、傳輸協議、端口號等）的附加信息。
• 起始字段：
  • Length：uint16類型，指定選項長度（字節），不含自身和Type類型字段。
  • Type：uint8類型，指定選項類型。
  • Discardable Flag：1位，若接收方不支持且設為1，可丟棄選項。
  • 保留位：1 - 7位保留，設為0。
• 特殊情況：可變長度選項后接選項可能因前者長度而未對齊。

2.2.4.1 配置選項（Configuration Option）

• 用途：配置選項用于傳輸任意的配置字符串，可對服務的名稱或其配置等附加信息進行編碼。
• 基本格式：
  • Length（長度）：uint16類型，設置為配置選項占用的總字節數，但不包括16位長度字段和8位類型標志。
  • Type（類型）：uint8類型，應設為0x01。
  • Discardable Flag（可丟棄標志）：1位，如果接收方可以丟棄該選項，則設為1。
  • 保留位：第1位到第7位保留，設為0。
  • ConfigurationString（配置字符串）：動態長度，用于承載配置字符串。
• 配置字符串的具體格式要求
  • 應指定基于DNS TXT和DNS - SD格式的名稱 - 值對。
  • 格式應從一個單字節長度字段開始，該字段描述其后的字節數，之后是具有指定長度的字符序列。每個字符序列后又有一個長度字段和后續字符序列，直到長度字段設為0x00，表示配置字符串結束。
  • 字符序列應編碼一個鍵和可選的值，用等號（“=”）劃分鍵和值，鍵不應包含等號，至少有一個非空白字符，且鍵的字符應為可打印的US - ASCII值（0x20 - 0x7E），不包括等號（0x3D）。等號不應是序列的第一個字符；無等號的字符序列，鍵應被解釋為存在；以等號結尾的字符序列，鍵應被解釋為存在且值為空；單個配置選項中應支持具有相同鍵的多個條目。
  • 示圖
    
    

2.2.4.2 負載均衡選項（Load Balancing Option）

• 用途：用于對服務不同實例優先級排序，供客戶端依此選實例，附加于提供服務條目。
• 規則：
  • 查所有實例（設0xFFFF），選最高優先級且符客戶端自定標準（如限實例ID范圍，規范未定義）的實例。
  • 多最高優先級實例，按權重隨機選。
  • 提供服務條目無此選項且有多實例，將無選項實例視為最低優先級。
  • 查特定實例（非0xFFFF），不評估此選項。
• 負載均衡選項格式
  • 長度：uint16，設為0x0005。
  • 類型：uint8，設為0x02。
  • 可丟棄標志：1位，接收方可棄設1。
  • 保留位：1 - 7位保留，設0。
  • 優先級：uint16，值低優先級高。
  • 權重：uint16，值大選中概率高。

2.2.4.3 IPv4 端點選項（IPv4 Endpoint Option）

• 用途 ：由SOME/IP - SD實例用，指示端點信息，含本地IP、傳輸層協議（如UDP、TCP）及發送方端口號，這些端口用于事件和通知事件。

• IPv4端點選項規則與格式

  • 類型：設為0x04。
  • 具體內容：
    • 須指定IPv4地址、傳輸層協議（ISO/OSI第4層）及端口號。
    • L4 - Proto（uint8）依IANA/IETF設，0x06為TCP，0x11為UDP。
    • L4 - Port（uint16）設為第4層協議端口。
  • 格式：
    • Length（uint16）設0x0009。
    • Discardable Flag（1位）設0。
    • 1 - 7位保留，設0。
    • IPv4 - Address（uint32）傳單播IP地址為4字節。
    • Reserved（uint8）設0x00。

• 服務器端與客戶端規則：
  • 服務器端規則：服務器用 IPv4 端點選項與 Offer Service 條目，指示服務端點，最多一個 UDP 端點和一個 TCP 端點。
  • 服務器端與客戶端關聯規則 ： 服務器服務條目中端點作事件源，客戶端用 IPv4 端點選項在 Subscribe Eventgroup 條目中示自身 IP 及 UDP 和 / 或 TCP 端口號。
  • 客戶端規則：客戶端用 IPv4 端點選項與訂閱事件組條目，示自身 IP 及 UDP 和 / 或 TCP 端口號。
  • 服務器端示例
    • 在汽車電子系統中，有負責車輛狀態監測的服務器（如ECU），提供車輛速度、發動機溫度等服務。
    • IPv4端點選項設置：
      • IPv4地址：192.168.1.100（uint32類型，4字節傳輸）。
      • 傳輸層協議及端口號：
        • 用UDP傳車輛速度信息，UDP端口50000，IPv4端點選項中L4 - Proto設0x11，L4 - Port設50000。
        • 用TCP傳發動機溫度等重要數據，TCP端口8000，IPv4端點選項中L4 - Proto設0x06，L4 - Port設8000。
      • 其他設置：
        • 類型0x04。
        • 長度0x0009（uint16類型）。
        • 可丟棄標志0（1位）。
        • 1 - 7位保留，設0。
        • 保留0x00（uint8類型）。
    • 服務發現過程：其他車載設備（客戶端）服務發現時，服務器廣播含IPv4端點選項信息及服務的Offer Service條目，客戶端據此可知獲取車輛速度信息連UDP的192.168.1.100:50000，獲取發動機溫度信息連TCP的192.168.1.100:8000。
  • 客戶端示例
    • 車內儀表盤顯示系統為客戶端，需訂閱車輛速度變化事件和發動機溫度過高報警事件。
    • IPv4端點選項設置：
      • IPv4地址：192.168.1.200（uint32類型，4字節傳輸）。
      • 傳輸層協議及端口號：
      • 用UDP接收車輛速度變化事件，UDP端口60000，IPv4端點選項中L4 - Proto設0x11，L4 - Port設60000。
      • 用TCP接收發動機溫度過高報警事件，TCP端口9000，IPv4端點選項中L4 - Proto設0x06，L4 - Port設9000。
      • 其他設置：
        • 類型0x04。
        • 長度0x0009（uint16類型）。
        • 可丟棄標志0（1位）。
        • 1 - 7位保留，設0。
        • 保留0x00（uint8類型）。
    • 訂閱過程：儀表盤向服務器發訂閱事件組請求，含IPv4端點選項信息及訂閱事件，服務器收到后，知車輛速度變化事件發UDP的192.168.1.200:60000，發動機溫度過高報警事件發TCP的192.168.1.200:9000，保障系統正常運行與信息交互準確。

2.2.4.4 IPv6 端點選項（IPv6 Endpoint Option）

• 用途： 由SOME/IP - SD實例用，示端點信息，含本地IP、傳輸層協議（如UDP、TCP）及發送方端口號，這些端口用于事件和通知事件。

• IPv6端點選項規則與格式

  • 類型：設為0x06。
  • 具體內容：
    • 長度（uint16）設0x0015。
    • 可丟棄標志（1位）設0。
    • 1 - 7位保留，設0。
    • IPv6地址（uint128）傳單播IP地址為16字節。
    • 保留（uint8）設0x00。
    • L4 - Proto（uint8）依IANA/IETF設，0x06為TCP，0x11為UDP。
    • L4 - Port（uint16）設第4層協議端口（如30490）。
      

• 服務器端使用規則 ： 服務器將IPv6端點選項與Offer Service條目聯用，示服務端點（最多一個UDP、一個TCP），且這些端點作事件源，其源IP和源端口號用于端點選項。

• 客戶端使用規則：客戶端用IPv6端點選項在Subscribe Eventgroup條目中示自身IP及UDP和/或TCP端口號，表明接收事件位置。

2.2.4.5 IPv4 組播選項（IPv4 Multicast Option）

• 用途 ：IPv4組播選項由服務器用，宣告IPv4組播地址、第4層協議及組播事件和通知事件發送端口號，現僅支持UDP。
• IPv4組播格式
  • 類型：設為0x14。
  • 具體內容：
    • 長度（uint16）：設0x0009。
    • 可丟棄標志（1位）：設0。
    • 1 - 7位保留：設0。
    • IPv4地址（uint32）：組播IP地址以4字節傳輸。
    • 保留（uint8）：設0x00。
    • L4 - Proto（uint8）：依IANA/IETF設，現僅支持UDP（0x11）。
    • L4 - Port（uint16）：設第4層協議端口。

• 與訂閱事件組確認條目關聯: IPv4組播選項應被訂閱事件組確認條目引用。
• 服務器對其引用 : 服務器應引用IPv4組播選項，其編碼了服務器發送組播事件和通知事件的IPv4組播地址與端口號。
• IPv4組播選項用途示例
  • 校園網中，多媒體教學系統服務器向多教室設備推教學視頻流，設IPv4組播地址為239.0.0.1，傳輸層協議UDP，端口號8000，服務器發視頻流到該地址端口，組內設備可同時接收，省帶寬和資源。
  • IPv4組播選項規則與格式示例
    • 類型：設為0x14，作識別標簽。
    • 長度：設0x0009，劃定數據空間。
    • 可丟棄標志：設0，確保重要性。
    • 1 - 7位保留：設0，預留空位。
    • IPv4地址：如239.0.0.1，4字節傳輸。
    • 保留（uint8）：設0x00，保格式規范。
    • L4 - Proto：設0x11表UDP，適合實時推大量數據。
    • L4 - Port：設8000，如卸貨碼頭，指示接收信息處。
  • 與訂閱事件組確認條目關聯示例
    • 校園網中，教室設備向服務器發訂閱請求，服務器處理后返回確認條目，依規定引用IPv4組播選項，含地址239.0.0.1、協議UDP、端口8000，客戶端據此知接收方式及配置。
  • 服務器對其引用示例
    • 校園網里，服務器推教學視頻組播事件時，依要求引用設置好的IPv4組播選項，找到地址239.0.0.1和端口8000，按UDP規則打包視頻流發送，組內設備可接收，學生能正常觀看。

2.2.4.6 IPv6 組播選項（IPv6 Multicast Option）

• 用途： IPv6組播選項由服務器用，宣告IPv6組播地址、第4層協議及組播事件和通知事件發送端口號，現僅支持UDP。
• IPv6組播格式
  • 類型：設為0x16。
  • 具體內容：
    • 長度（uint16）：設0x0015。
    • 可丟棄標志（1位）：設0。
    • 1 - 7位保留：設0。
    • IPv6地址（uint128）：組播IP地址以16字節傳輸。
    • 保留（uint8）：設0x00。
    • L4 - Proto（uint8）：依IANA/IETF設，現僅支持UDP（0x11）。
    • L4 - Port（uint16）：設第4層協議端口。

• 與訂閱事件組確認消息關聯 : IPv6組播選項而非IPv6端點選項應被訂閱事件組確認消息引用。
• 服務器對其引用 : 服務器應引用IPv6組播選項，其編碼了服務器發送組播事件和通知事件的IPv6組播地址與端口號。

2.2.4.7 IPv4 SD 端點選項（IPv4 SD Endpoint Option）

• 用途 ：用于傳輸發送方SD實現的端點（IP地址和端口），在IP地址和/或端口號無法使用時，可識別SOME/IP - SD實例，例如在ECU代理服務發現處理多播流量的場景中。

• IPv4 SD端點選項使用規則

  • 包含次數：規定任何SD消息中該選項最多只能包含一次，這是為了避免信息冗余，確保消息結構高效且規范。
  • 包含條件：只有當SOME/IP - SD消息通過IPv4傳輸時，才應包含IPv4 SD端點選項，以此保證與傳輸協議的一致性，避免接收方處理時產生混淆或錯誤。
  • 在選項數組位置：若該選項存在，它必須是選項數組中的第一個選項，這樣便于接收方快速、準確地獲取發送方的關鍵端點信息，從而提高處理效率。
  • 與SD條目引用關系：該選項不能被任何SOME/IP - SD條目引用，以避免在消息處理過程中出現循環引用或不必要的復雜依賴關系，確保協議的簡潔性和穩定性。
  • 接收方處理規則：如果SD消息中包含IPv4 SD端點選項，接收方的SD實現應使用該選項的內容來替代源IP地址和源端口。這在復雜網絡環境（如網絡地址轉換、代理服務器存在等）下，能確保通信和服務發現的準確性與可靠性，對于回應接收到的SD消息以及重啟檢測都非常重要。

• IPv4 SD端點選項格式 ：

  • 長度：Length字段為uint16類型，應設置為0x0009。
  • 類型：Type字段為uint8類型，需設置為0x24。
  • 可丟棄標志：1位，應設置為0。
  • 保留位：Bit 1到bit 7，均應設置為0。
  • IPv4地址：IPv4 - Address字段為uint32類型，用于傳輸SOME/IP - SD的單播IP地址，以四個字節表示。
  • 保留字段：Reserved字段為uint8類型，應設置為0x00。
  • 傳輸協議：Transport Protocol字段為uint8類型，應設置為SOME/IP - SD的傳輸層協議（目前為0x11 UDP）。
  • 傳輸協議端口號：Transport Protocol Port Number字段為uint16類型，應設置為SOME/IP - SD的傳輸層端口（目前為30490）。

• 示例

  • 場景設定 ： 智能汽車中有自動駕駛單元（ECU1）、車輛狀態單元（ECU2）和遠程通信單元（ECU3），分別承擔不同功能。

  • 汽車行駛時，ECU2 檢測到輪胎壓力異常，要傳信息給 ECU1，但網絡復雜使其 IP 和端口不穩定。IPv4 SD 端點選項此時傳輸 ECU2 的真實 IP（192.168.1.10）和端口（5000）。

  • 發送消息時，IPv4 SD 端點選項在 SD 消息中最多含 1 次。

  • 車網支持 IPv4 和 IPv6，此次在 IPv4 環境下，ECU2 依規包含該選項，方便 ECU1 按 IPv4 規則獲取信息。

  • ECU1 接收消息時，IPv4 SD 端點選項若在首位，能迅速獲取 ECU2 端點信息。

  • ECU2 消息含多個 SD 條目，但都不引用 IPv4 SD 端點選項。

  • 因 ECU2 經 NAT，源 IP 變化，好在消息含 IPv4 SD 端點選項，ECU1 依規替代源 IP 和端口，確保通信準確，讓自動駕駛系統調整策略保障行車安全。

  • 在格式方面，Length 設 0x0015，Type 設 0x24，可丟棄標志為 0，保留位（Bit 1 - 7 設 0）預留空間，IPv4 - Address 傳 192.168.1.10 ，Reserved 設 0x00 預留空間。

2.2.4.8 IPv6 SD 端點選項（IPv6 SD Endpoint Option）

• 用途：用于傳輸發送方SD實現的端點，即IP地址和端口。當常規IP地址和端口號無法使用時，可借此識別SOME/IP - SD實例。
• 使用規則 ：
  • 包含次數：規定在任何SD消息中，IPv6 SD端點選項最多只能被包含一次，以避免信息冗余。
  • 在選項數組位置：若存在IPv6 SD端點選項，它必須是選項數組中的第一個選項。
  • 與SD條目引用關系：明確IPv6 SD端點選項不能被任何SOME/IP - SD條目引用，避免消息處理中出現循環引用或復雜依賴關系。
  • 接收方處理規則：若SD消息包含IPv6 SD端點選項，接收方的SD實現應使用該選項內容替代源IP地址和源端口。在復雜網絡環境（如NAT、代理服務器等導致源IP和源端口不可靠時），IPv6 SD端點選項能提供更準確穩定的端點信息，確保通信和服務發現的準確性與可靠性，對回應SD消息及重啟檢測至關重要。
• 格式：
  
  • 長度：Length字段為uint16類型，應設置為0x0015。
  • 類型：Type字段為uint8類型，需設置為0x26。
  • 可丟棄標志：1位，應設置為0。
  • 保留位：Bit 1到bit 7，均應設置為0。
  • IPv6地址：IPv6 - Address字段為uint128類型，用于傳輸SOME/IP - SD的單播IP地址，以16個字節表示。
  • 保留字段：Reserved字段為uint8類型，應設置為0x00。
  • 傳輸協議：Transport Protocol字段為uint8類型，應設置為SOME/IP - SD的傳輸層協議（目前為0x11 UDP）。
  • 傳輸協議端口號：Transport Protocol Port Number字段為uint16類型，應設置為SOME/IP - SD的傳輸層端口（目前為30490）。

2.2.5 Service Entries（服務條目）

2.2.5.1 查找服務條目（Find Service Entry）

• 查找服務條目用途及發送條件 ：查找服務條目類型用于查找服務實例，僅在服務當前狀態未知時（未收到有效服務提供消息或之前消息失效）才發送。

• 查找服務條目字段設置規則

  • 類型：設為0x00（FindService），標識查找服務類型。
  • 服務ID：設為要查找服務的ID，精準指向目標服務。
  • 實例ID：返回所有實例設為0xFFFF，返回單個特定實例設為其ID，提供靈活查找方式。
  • 主版本：設為0xFF返回任何版本服務，設為其他值僅返回特定主版本服務，可按需精確查找。
  • 次版本：設為0xFFFF FFFF返回任何版本服務，設為其他值僅返回特定次版本服務，精細控制版本。
  • 生存時間（TTL）：設為條目生存時間，超時視為不存在；設為0xFFFFFF在下一次重啟前一直有效；不應設為0x000000，此為停止提供服務條目。

• 查找服務條目與其他選項的關系

  • 發送方不應在查找服務條目中引用端點選項和多播選項，可能為保持簡潔專注。
  • 接收方應忽略查找服務條目中的端點選項和多播選項，確保處理一致性和規范性。
  • 其他選項（非端點和多播選項）仍允許在查找服務條目中使用，在保證核心功能前提下提供靈活性，由相關規則關聯確定。

2.2.5.2 提供服務條目（Offer Service Entry）

• 用途 : 提供服務條目類型用于向其他通信伙伴提供服務。

• 提供服務條目字段設置規則

  • 類型：設為0x01（OfferService），標識提供服務類型。
  • 服務ID：設為所提供服務實例的服務ID，明確服務。
  • 實例ID：設為所提供服務實例的實例ID，指向具體實例。
  • 主版本：設為所提供服務實例的主版本。
  • 次版本：設為所提供服務實例的次版本。
  • 生存時間（TTL）：設為服務實例生存時間，超時視為未提供；設為0xFFFFFF在下一次重啟前一直有效；不應設為0x000000，此為停止提供服務條目。

• 提供服務條目與端點選項的關系

  • 提供服務條目應至少引用一個IPv4或IPv6端點選項，表明服務可到達方式。
  • 若支持IPv4，服務所需每個傳輸層協議（UDP和/或TCP）應添加IPv4端點選項。
  • 若支持IPv6，服務所需每個傳輸層協議（UDP和/或TCP）應添加IPv6端點選項。

2.2.5.3 停止服務條目（Stop Offer Service Entry）

• 用途 ：該條目類型用于停止提供服務實例，由相關規則關聯確定。

• 停止提供服務條目字段設置規則： 應完全按要停止的提供服務條目設置字段，僅生存時間（TTL）設為0x000000。

2.2.5.4 在條目中選項的使用方式和規則（Usage of Options in Entries）

2.2.6 服務與事件的端點處理（Endpoint Handling for Services and Events）

• 服務發現與端點選項的 IP 地址和端口號處理: 若靜態配置的IP地址和端口號與端點（Endpoint）及多播（Multicast ）選項（Options）中傳輸的不同，服務發現需用后者覆蓋。
• 端點選項用于事件傳輸: 端點選項（Endpoint Option）中的IP地址和端口號用于傳輸事件（events）和通知事件（notification event）。
• UDP場景下的端點選項使用 : 使用UDP時，端點選項用于事件和通知事件的源地址、源端口，也是客戶端發送方法請求的地址。
• TCP場景下的端點選項使用 : 使用TCP時，端點選項用于客戶端接收TCP事件需打開TCP連接的IP地址和端口。
• 服務可同時使用UDP和TCP : SOME/IP允許服務同時使用UDP和TCP。
• 消息傳輸協議的配置決定 : 消息傳輸協議由配置決定，服務可同時用UDP和TCP端點，但每個服務元素需配置使用TCP或UDP。
  • 示例： 汽車車身控制系統中車窗升降服務，車窗升降狀態實時反饋事件因實時性要求高，配置為 UDP 傳輸；車窗控制軟件更新事件因需確保數據完整準確，配置為 TCP 傳輸，且明確實時反饋事件不能同時通過 TCP 傳輸，確保系統穩定高效通信。
• 同時強調: 配置中要限制通過TCP/UDP提供的方法和事件，且同一事件不能同時通過TCP和UDP提供。

2.2.6.1 服務端點（Service Endpoints）

• 端點選項含義：其表示服務實例在服務器端可被訪問及發送事件的IP地址和端口號。
• 事件發送端點限制：規定服務實例事件只能從提供服務條目中端點選項給定的端點發送。
• 多服務實例消息區分：規定若ECU提供多服務實例，SOME/IP消息應通過提供服務條目中端點選項傳輸的信息區分。

2.2.6.2 事件組端點（Eventgroup Endpoints）

• 規則說明：
  • 訂閱事件組條目里的端點選項用于給服務實例發送單播UDP或TCP的SOME/IP事件。
  • 這些端點選項是客戶端側的IP地址和端口號。
  • TCP事件經客戶端發訂閱事件組條目建立的TCP連接傳輸。
  • 初始事件從服務器到客戶端單播傳輸。
  • 訂閱事件組確認條目最多引1個多播選項（IPv4或IPv6），多播選項設為UDP傳輸協議，客戶端快開相關端點免錯過多播事件。
• 示例及后續操作：
  • 服務器有服務實例的UDP端點SU和TCP端點ST。
  • 客戶端開TCP連接。
  • 客戶端發帶UDP端點CU（單播）和TCP端點CT的訂閱事件組條目。
  • 服務器回復帶多播MU的訂閱事件組確認條目。
  • 然后：客戶端調服務器方法；請求從CU到SU，響應從SU到CU；TCP時，請求從動態端點到ST，響應從ST到CT；服務器發單播UDP事件：SU到CU；發單播TCP事件：ST到CT；發多播UDP事件：SU到MU。
  • 注意多播端點在客戶端用多播IP地址，TCP不能用于多播通信。

2.3 Service Discovery Messages

• 所有SD消息都發往SD_PORT，確保發送規范一致。
• SD_PORT用作SD單播/多播消息的源端口，便于識別管理消息來源。
• 單播SD消息一般以SD_PORT為目的端口，特殊情況按SD端點選項定義。
• 所有SD多播消息用SD_MULTICAST_IP發送，助準確傳輸接收，避免混淆。
• 此外，可用之前指定的頭部格式構建不同條目和消息。

2.3.1 訂閱事件組條目（Subscribe Eventgroup Entry）

• 具體規則：
  • 條目類型及用途：
    • 該條目類型用于訂閱事件組，由相關規則確定。
  • 條目字段設置方式：
    • 類型設為0x06（SubscribeEventgroup）。
    • 服務ID設為含訂閱事件組的服務實例的服務ID。
    • 實例ID設為含訂閱事件組的服務實例的實例ID。
    • 主版本設為訂閱事件組的服務實例的主版本。
    • 事件組ID設為所訂閱事件組的事件組ID。
    • 次版本設為訂閱事件組的服務實例的次版本。
    • TTL設為訂閱有效期，0xFFFFFF時條目到下次重啟前有效，不能設為0x000000（視為停止提供服務條目）。
    • 保留字段設為0x00，直到另有通知。
    • 客戶端發序列中首個訂閱觸發初始事件發送時，初始數據請求標志設為1，否則為0。
    • 保留字段2設為三個0位。
    • 計數器用于區分同一服務同一事件組的并行訂閱（僅端點不同），不用設為0x0。
  • 條目與端點選項的引用：
    • 訂閱事件組條目應引用一個或兩個IPv4和/或一個或兩個IPv6端點選項（一個用于UDP，一個用于TCP）。

2.3.2 停止訂閱事件組（Stop Subscribe Eventgroup）

• 條目類型及用途：該條目類型用于停止對事件組的訂閱。
• 條目字段設置：與要停止的訂閱事件組條目字段設置相同，僅TTL設為0x000000。
• 條目與選項的引用：應引用與訂閱事件組條目相同的選項（含端點和配置選項等）。

2.3.3 訂閱事件組確認（Subscribe Eventgroup Ack）

• 條目類型及用途： 該條目類型用于指示訂閱事件組條目已被接受。
• 條目字段設置方式：
  • 類型設為0x07（SubscribeEventgroupAck）。
  • 服務ID、實例ID、主版本、事件組ID、TTL、保留字段、初始數據請求標志、保留字段2和計數器與被回復的訂閱事件組的值相同。
• 條目與多播選項的引用：引用多播傳輸事件和通知事件的確認條目應引用IPv4多播選項和/或IPv6多播選項。

2.3.4 訂閱事件組否定確認（Subscribe Eventgroup Nack）

• 條目類型及用途：此條目類型用于指示訂閱事件組條目未被接受。
• 條目字段設置方式：
  • 類型設為0x07（SubscribeEventgroupAck）。
  • 服務ID、實例ID、主版本、事件組ID、計數器和保留字段與被回復的訂閱事件組值相同。
  • TTL設為0x000000。
• 不接受訂閱的原因：
  • 如服務ID等組合未知
  • 客戶端未開所需TCP連接
  • 引用選項有問題
  • 服務器資源問題等。
• 客戶端收到否定確認后的處理：
  • 客戶端收到需TCP連接的訂閱事件組否定確認后，應檢查TCP連接，必要時重啟。檢查包括：查是否收到其他事件組數據；發Magic Cookie消息等TCP ACK；重新建立TCP連接。

2.4 Service Discovery Communication Behavior

2.4.1 Startup Behavior

服務實例或事件組發送條目分三個階段：

• 初始等待階段（Initial Wait Phase）

  • 觸發條件
    • 客戶端層面：客戶端如同急切想出門玩耍的孩子，當連接外界的“門”（所需接口鏈路）開啟，且“媽媽”（應用程序）下達出門指令（請求客戶端服務），服務發現就像貼心管家，進入此階段，著手籌備服務安排。
    • 服務器層面：服務器類似商店，店門（接口鏈路）打開且店內商品（服務器服務）準備就緒（可用）時，服務發現作為“店員”進入該階段。不過存在店門開了，但商品尚在整理（服務尚未可用）的情況。系統啟動好比商場全面開業，不僅店內商品要齊全，配套的安保系統（外部傳感器）、電梯（執行器）等都需正常運轉，服務實例準備好服務內容，待顧客（應用程序）詢問時，開啟服務查找流程。
  • 等待時長
    • 服務發現依據INITIAL_DELAY決定等待時間，INITIAL_DELAY類似有最小、最大刻度的魔法沙漏。服務發現像調皮小精靈，在這兩個刻度間隨機選定一個時長，并且同一商場（接口）內的所有店鋪（服務實例）都遵循這一隨機等待時間。等待結束后，便發送消息宣告可提供的服務 。

• 重復階段（Repetition Phase）

  • 開啟標志 ：當第一條消息發出，如同閃亮星星升空，服務實例們如同聽到哨聲的運動員，集體進入重復階段。
  • 操作規則：
    • 等待策略：按REPETITIONS_BASE_DELAY確定等待時間，每次發完消息，下次等待時長翻倍，類似運動員起跑倒計時逐步拉長間隔。
    • 發送限制：此階段發送消息次數受限，最多為REPETITIONS_MAX次。
    • 階段轉換：若收到對方回應（對應的提供條目），如同比賽結束哨聲響起，立即停止發送查找消息，轉入主階段，主階段不再發送查找消息。若REPETITIONS_MAX設為0，就像運動員跳過預賽，直接從初始等待階段進入主階段 。例如，REPETITIONS_BASE_DELAY為100ms，REPETITIONS_MAX為2時，先等100ms（2^0 * 100ms）發消息，接著等200ms（2^1 * 100ms）再發消息。

• 主階段（Main Phase）

  • 開啟時機 ：重復階段結束，恰似戲劇中場休息完畢，主階段正式開場。

  • 發送規則 ：

    • 開場準備：提供者如同舞臺主角，在首次登臺（發送第一個提供條目消息）前，按1 * CYCLIC_OFFER_DELAY時長等待，進行狀態調整。
    • 周期性發送：若設置CYCLIC_OFFER_DELAY，消息會如同時鐘指針般周期性出現。每次給特定服務實例發送消息后，間隔1 * CYCLIC_OFFER_DELAY再發送下一條。
    • 特殊限制：此階段查找消息（查找服務和查找事件組）不能持續循環發送。而訂閱事件組條目類似舞臺特效，會由周期性發送的提供條目觸發顯現。只要消息有效且設定CYCLIC_OFFER_DELAY，便先等待CYCLIC_OFFER_DELAY時長，然后發送消息披露服務詳情 。

2.4.2 Server Answer Behavior

• 服務發現需運用配置項REQUEST_RESPONSE_DELAY，對多播SOME/IP - SD消息中接收的條目延遲應答。該規則適用于兩種情形：
  • 接收到多播的查找條目后，發送提供條目（無論單播或多播）。
  • 接收到多播的提供條目后，發送單播的訂閱條目。
• 若單播消息用單播消息應答，REQUEST_RESPONSE_DELAY不適用。
• REQUEST_RESPONSE_DELAY由最小值和最大值指定。
• 實際延遲在REQUEST_RESPONSE_DELAY的最小值和最大值之間隨機選擇。
• 對于基本實現，所有查找服務條目，無論單播標志狀態，都用單播傳輸的提供服務條目應答。
• 為優化目的，有以下可選支持行為：
  • 在主階段，若接收到單播標志設置為1的查找消息，且上次提供消息在不到1/2 CYCLIC_OFFER_DELAY之前發送，應以單播響應回復。
  • 在主階段，若接收到單播標志設置為1的查找消息，且上次提供消息在1/2 CYCLIC_OFFER_DELAY或更長時間之前發送，應以多播響應回復。
  • 若接收到單播標志設置為0（多播）的查找消息，應以多播響應回復（此僅在早期遷移場景需要，未來將不再需要）。

2.4.3 Shutdown Behavior

1. ECU的服務器服務實例在重復和主階段被停止時，需發送停止提供服務條目。
2. 服務器服務實例在初始等待、重復或主階段鏈路斷開，鏈路恢復且服務可用時，服務發現進入初始等待階段。
3. 客戶端服務實例在初始等待、重復或主階段鏈路斷開，鏈路恢復且服務仍被請求時，服務發現進入初始等待階段。
4. 服務器發送停止提供服務條目時，服務器端刪除該服務實例的所有訂閱。
5. 客戶端收到停止提供服務條目時，客戶端刪除該服務實例的所有訂閱。
6. 客戶端收到停止提供服務條目時，不應發送查找服務條目，而應等待提供服務條目或狀態變化。
7. ECU的客戶端服務實例在主階段被停止時，服務發現發送停止訂閱事件組條目用于所有已訂閱的事件組。
8. 整個ECU關閉時，為所有服務條目發送停止提供服務條目，并為事件組發送停止訂閱事件組條目。

2.4.4 State Machines

2.4.5 SOME/IP-SD Mechanisms and Errors

• 軟狀態協議（Soft State Protocol） SOME/IP - SD被設計為軟狀態協議，這意味著條目具有生命周期，需要刷新以保持有效（將TTL設置為最大值可關閉此功能）。

• 初始等待階段（Initial Wait Phase）

  • 引入原因：
    • 為了避免啟動電子控制單元（ECUs）時事件的歪斜，防止流量突發。
    • 允許ECUs收集服務發現（SD）消息中的多個條目。

• 重復階段（Repetition Phase）

  • 引入目的：
    • 實現客戶端和服務器的快速同步。如果客戶端啟動較晚，能快速找到服務器；如果服務器啟動較晚，客戶端也能快速被發現。
    • 重復階段通過指數級增加兩條消息之間的時間間隔，避免過載情況，保持系統同步。

• 主階段（Main Phase）

  • 行為：在主階段，服務發現（SD）試圖穩定狀態，因此不再發送查找服務（Find Services），僅在循環間隔（例如每秒）發送提供服務（offers），以此降低數據包速率。

• 請求 - 響應延遲（Request - Response - Delay）

  • 配置及作用：SOME/IP - SD應配置為通過請求 - 響應延遲來延遲對多播消息中條目的應答。這在具有許多ECUs的大型系統中很有用。當發送包含許多條目的服務發現消息時，不同ECUs會同時到達并回復，這會給接收所有這些回復的ECU帶來很大壓力，而此配置可緩解該問題。

2.4.6 Error Handling

2.5 Publish/Subscribe with SOME/IP and SOME/IP-SD

• 與SOME/IP請求/響應機制不同，存在客戶端需從服務器獲取參數但不想每次都請求的情況，即通知和關注事件及字段。

具體規則及說明

1. 客戶端注冊：
   • 需事件和/或通知事件的客戶端應在運行時用SOME/IP - SD向服務器注冊，引用多個相關規則。
2. 通知交互序列：
   • 客戶端發SOME/IP - SD: SubscribeEventgroup()，服務器回SOME/IP - SD: SubscribeEventgroupAck()，然后服務器發多個SOME/IP: Event()給客戶端。
     
3. 服務器重啟處理：
   • 若客戶端能可靠檢測服務器用SOME/IP - SD消息重啟，可選擇僅在服務器重啟后（TTL設最大值）響應Offer Service消息，且要確保即使服務器SOME/IP - SD消息丟失也能可靠操作。
4. 初始事件請求：
   • 客戶端無事件組有效訂閱時，應設初始數據請求標志明確求初始事件；若發額外Subscribe Eventgroup條目且之前Subscribe的TTL未過期，不應求初始事件。客戶端明確求初始事件原因包括未訂閱、上次Subscribe Eventgroup條目后鏈路斷開/連接、未收到Subscribe Eventgroup Ack、檢測到服務器重啟等。
5. 重復事件處理：
   • 若客戶端訂閱含相同事件或字段的多個事件組，服務器不應發重復常規事件。
     

• 客戶端注銷規則：客戶端應通過發送TTL = 0的SOME/IP - SD Subscribe Eventgroup消息（即Stop Subscribe Eventgroup）從服務器注銷。
  
• 服務器端訂閱刪除規則 ： 若服務器發送事件或通知事件后出現相關SOME/IP錯誤，如無法到達通信伙伴、TCP連接錯誤等，服務器上的SOME/IP - SD應刪除該訂閱。

• 若服務經TCP提供且客戶端依配置TCP訂閱，客戶端發訂閱事件組條目前先與服務器建TCP連接。

• 客戶端發訂閱事件組條目后，服務器應發確認條目。

• 客戶端發后等確認，若未收到且下一條目未發：

  • 服務器顯式初始數據控制標志為0，客戶端發停止訂閱和原訂閱條目于同一消息。
  • 服務器標志為1，客戶端將下一條目初始數據請求標志設為1。

• 上述行為應對通信短暫中斷，降消息丟失影響，新初始事件會觸發。

• 對查找服務條目反應的提供服務條目，不適用客戶端等待確認規則，因單播提供發訂閱后收多播提供，未收確認前客戶端不抱怨，此也為應對通信中斷，接收停止訂閱與訂閱組合方會發初始事件降影響。

• 若初始值受關注且客戶端顯式初始數據控制標志為0，服務器發訂閱事件組確認條目后立即發初始通知/事件。

• 服務器依標志發通知：

  • 收到訂閱事件組條目初始數據請求標志為0且SOME/IP - SD頭部標志為1，不發通知/事件。
  • 收到條目兩標志均為1，發確認條目后立即發初始通知/事件。

• 訂閱純事件時不發初始值（字段可）。

• 字段通知器事件消息在訂閱（字段和非純事件）時發。

• 訂閱有效且更新時不發初始事件。

• 接收停止訂閱/訂閱組合觸發字段通知器初始事件，初始事件在訂閱事件組確認條目后發。
  

• 客戶端訂同一服務實例不同事件組，若事件組在不同SOME/IP - SD消息含相同字段，服務器應分別為各訂閱發該字段初始事件。

• 若事件組在相同SOME/IP - SD消息含相同字段，服務器可只發一次該字段初始事件。

• 若服務器架構支持，可只發一次初始事件來優化。
  
  

• SOME/IP - SD應在達到訂閱者數量閾值時，自動從單播切換到組播。

• SOME/IP SD協議支持通信端點隱式配置和訂閱者注冊，基于靜態配置，不使用網絡SD消息。

• 不同項目可能有基于靜態配置用服務的用例，無網絡服務發現，隱式注冊時無查找或訂閱消息交換，服務可在盒子外使用，預配置非SOME/IP或SOME/IP SD部分，配置和實現項目特定。

• 以下條目僅通過單播傳輸：訂閱事件組、停止訂閱事件組、訂閱事件組確認、訂閱事件組否定確認。