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部分，配置和实现项目特定。

• 以下条目仅通过单播传输：订阅事件组、停止订阅事件组、订阅事件组确认、订阅事件组否定确认。