SOME/IP--协议英文原文讲解12（完结）

前言
SOME/IP协议越来越多的用于汽车电子行业中，关于协议详细完全的中文资料却没有，所以我将结合工作经验并对照英文原版协议做一系列的文章。基本分三大块：

1. SOME/IP协议讲解

2. SOME/IP-SD协议讲解

3. python/C++举例调试讲解

---

4.3 Compatibility Rules for Interface Version
The Interface Version identifies the Payload format. The Payload format is affected by
• the Service Interface specification
• the serialization configuration (e.g. usage of variable size arrays, size of length
fields, padding, TLV, SOME/IP-TP).
[PRS_SOMEIP_00937]
Upstream requirements: RS_SOMEIP_00003
The Interface Version shall be increased for any of the following reasons:
• incompatible changes in the Payload format
• incompatible changes in the service behaviour
• required by application design

Note: The Interface Version shall not be increased for compatible changes in the Payload format.
[PRS_SOMEIP_00938]
Upstream requirements: RS_SOMEIP_00003
The rules in [PRS_SOMEIP_00758] shall define the compatibility of changes of the
payload format. For complex data types the rules shall be applied recursively. X denotes a compatible change, an empty cell denotes an incompatible change.
Note:
This table is based on the specification of the SOME/IP protocol. As a rule of thumb,
interfaces are compatible if the receiver of data finds all expected information on the
expected locations.

这段内容讨论了 **SOME/IP 协议** 中 **接口版本（Interface Version）** 的兼容性规则，特别是关于 **Payload 格式** 和 **服务行为** 的变化。以下是详细解释：

---对于车厂而言一般不会用到这个字段，因为如果有变更的话，会直接更新释放矩阵表版本。不允许有多版本兼容的情况存在。

### 核心内容
1. **接口版本的作用**：
   - 接口版本用于标识 Payload 格式。
   - Payload 格式受以下因素影响：
     - 服务接口规范（Service Interface specification）。
     - 序列化配置（例如变长数组的使用、长度字段的大小、填充、TLV、SOME/IP-TP）。

2. **接口版本增加的规则**：
   - 在以下情况下，必须增加接口版本：
     - Payload 格式发生不兼容的变化。
     - 服务行为发生不兼容的变化。
     - 应用程序设计要求。

3. **兼容性变化的处理**：
   - 如果 Payload 格式的变化是兼容的，则不应增加接口版本。
   - 兼容性变化的规则在 [PRS_SOMEIP_00758] 中定义。

---

### 关键点
1. **不兼容变化**：
   - 不兼容变化是指接收方无法正确解析或处理 Payload 的变化。
   - 例如：
     - 更改字段的顺序。
     - 删除或重命名字段。
     - 更改字段的数据类型。

2. **兼容变化**：
   - 兼容变化是指接收方仍然能够正确解析和处理 Payload 的变化。
   - 例如：
     - 添加新字段（不影响现有字段的解析）。
     - 扩展字段的长度（不影响现有数据的解析）。

3. **复杂数据类型的兼容性**：
   - 对于复杂数据类型（如结构体、数组），兼容性规则应递归应用。
   - 例如，如果结构体中的某个字段发生不兼容变化，则整个结构体被视为不兼容。

下面表格列举了会引起内部版本号变更的payload的各种可能的情况：

The following legend to the table applies:
ENUM-REMARK: The "Receiver" of an Enumeration needs to know all values it can receive, while the "Transmitter" does not have to send all values the "Receiver" knows.
接收端必须知道它接收到的所有枚举的值的含义。发送端不需要发送所有的枚举给接收端
假如一个服务，给client1 和 client2 用到的枚举值的范围不一致 也是有可能的。
MAXIMUM-MESSAGE-SIZE (MMS): The compability in Classic Platform is limited by
the maximum configured size of message. This means that if the message size is configured
larger than necessary, additional text could be added and, independently of the message size
on tag, can be replaced by a new one.
OPTIONAL-METHOD-ARGUMENTS-REMARK: See note above [PRS_SOMEIP_00230].
DEFAULT-VALUE: A default value is required for this change to be compatible.
ZERO-TERMINATED: Strings are terminated with a "\0"-character(see [PRS_SOMEIP_00373],
[PRS_SOMEIP_00911], [PRS_SOMEIP_00912] and [PRS_SOMEIP_00913])

The column "Transmitter" refers to the side transmitting a SOME/IP message, which
can be the transmitter of an event (provider of the interface) or the method arguments
used by the caller of a method (user of the interface) or the method result returned by
the callee of a method (provider of the interface). The column "Receiver" refers to the
side receiving a SOME/IP message, which can be the receiver of an event (user of the
interface) or the method arguments forwarded to the callee of a method (provider of the
interface) or the method result forwarded to the caller of a message (user of the interface). For fields, compatibility is only given if both the "Transmitter" and the "Receiver"
columns are marked as compatible, because the same content will be transmitted by
the side defined by the provider of the interface (notification event, getter method) and
the user of the interface (setter method).

1. MAXIMUM-MESSAGE-SIZE (MMS)（最大消息大小）

• 解释：在 Classic Platform（经典平台） 中，消息的兼容性受到配置的最大消息大小的限制。也就是说，如果配置的消息大小比实际需要的要大，那么可能会附加额外的文本，且无论标签中的消息大小如何，最终可能会被新的消息替代。

• 影响：配置不当的消息大小可能导致不必要的数据被添加，或者消息内容被不期望地替换，这可能会影响系统的稳定性或传输的正确性。

2. OPTIONAL-METHOD-ARGUMENTS-REMARK（可选方法参数说明）

• 解释：这部分提到了可选方法参数的情况，具体的说明可以参考 PRS_SOMEIP_00230，这是一个SOME/IP协议相关的注释或标准文档编号。

• 作用：如果方法参数是可选的，那么需要特别注意它们的处理方式，以保证接口的兼容性。

3. DEFAULT-VALUE（默认值）

• 解释：对于一些变更或设置，必须提供一个默认值，以确保这些变更与现有系统兼容。如果没有默认值，可能会导致兼容性问题。

• 影响：默认值的缺失可能导致系统无法正常工作或接口不兼容，因此必须在设计时明确指定默认值。

4. ZERO-TERMINATED（零终止符）

• 解释：字符串在SOME/IP协议中使用 "\0" 字符来进行终止，表示字符串的结束。这是C语言等编程语言中常见的字符串终止方式。

• 参考：具体的规定可以参考 PRS_SOMEIP_00373，PRS_SOMEIP_00911，PRS_SOMEIP_00912 和 PRS_SOMEIP_00913 等文档。这些标准文档详细描述了如何处理字符串的终止符问题。

5. Transmitter（发送方） 和 Receiver（接收方）

• 解释：SOME/IP协议中的“发送方”和“接收方”分别指的是消息的发送方和接收方。
  • 发送方：可以是事件的发送方（接口的提供者），方法调用中的参数发送方（接口的使用者）或方法返回结果的发送方（接口的提供者）。
  • 接收方：可以是事件的接收方（接口的使用者），方法参数转发到方法调用方（接口的提供者），或者方法结果转发给方法调用方（接口的使用者）。
• 兼容性：对于字段的兼容性要求，如果“发送方”和“接收方”都标记为兼容，那么这个字段才算是兼容的。这是因为相同的内容会在接口提供者（例如通知事件、获取方法）和接口使用者（例如设置方法）之间传递。

---

1. SOMEIPTP_REASSEMBLY_TIMEOUT

• 描述：这个参数是一个可配置的计时器，用于接收SOME/IP-TCP分段的超时时间。简而言之，这是在接收SOME/IP协议段时，设置的最大等待时间。如果在这个时间内未完成接收，则认为该消息的接收超时。

2. Upstream Requirements（上游需求）:

• 提到的上游需求包括 RS_SOMEIP_00010 和 RS_SOMEIP_00014，这些是具体的标准或文档编号，说明该参数与其他要求或标准的关系。

3. Parameter Support in AP (应用平台):

• 这个参数在应用平台（AP）中的支持包括：
  • SomeipEventDeployment.segmentReceptionTimeoutTime，用于配置事件部署中段接收的超时时间。
  • SomeipMethodDeployment.segmentReceptionTimeoutTimeRequest，用于配置方法部署中段接收的超时时间请求。
  • SomeipMethodDeployment.segmentReceptionTimeoutTimeResponse，用于配置方法部署中段接收的超时时间响应。

4. Parameter Support in CP (控制平台):

• 在控制平台（CP）中，参数的支持包括：
  • SomeipTpChannel，指示SOME/IP协议中的传输通道。
  • SomeipTpRxTimeoutTime，指示接收超时时间。
  • EUCU_-SomeIpTp_00023，这是一个参考标准或文档，提供进一步的详细信息。

5. Mapping Table（映射表）

• 在表格的最后部分，提到这是 SOME/IP协议参数的映射表。通过这个表格可以了解在不同平台和不同实现中，如何映射和使用这些配置参数。

总结：

此图表主要描述了 SOMEIPTP_REASSEMBLY_TIMEOUT 参数的功能和如何在不同的系统平台（应用平台AP和控制平台CP）中进行配置和支持。该参数用于设置SOME/IP协议中，接收SOME/IP-TCP分段的超时时间，从而影响消息的传输和处理。

---

6 Protocol usage and guidelines
6.1 Choosing the transport protocol 关于如何选择传输协议
SOME/IP supports User Datagram Protocol (UDP) and Transmission Control Protocol
(TCP). While UDP is a very lean transport protocol supporting only the most important
features (multiplexing and error detecting using a checksum), TCP adds additional
features for achieving a reliable communication. TCP not only handles bit errors but
also segmentation, loss, duplication, reordering, and network congestion.
Inside a vehicle many applications requires very short timeout to react quickly. These
requirements are better met using UDP because the application itself can handle the
unlikely event of errors. For example, in use cases with cyclic data it is often the best
approach to just wait for the next data transmission instead of trying to repair the last
one. The major disadvantage of UDP is that it does not handle segmentation. Hence,
only being able to transport smaller chunks of data.
Guideline:
• Use TCP only if very large chunks of data need to be transported (> 1400 Bytes)
and no hard latency requirements in the case of errors exists
• Use UDP if very hard latency requirements (<100ms) in case of errors is needed
• Use UDP together with SOME/IP-TP if very large chunks of data need to be
transported (> 1400 Bytes) and hard latency requirements in the case of errors
exists
• Try using external transport or transfer mechanisms (Network File System, APIX
link, 1722, ...) when they are more suited for the use case. In this case SOME/IP
can transport a file handle or a comparable identifier. This gives the designer
additional freedom (e.g. in regard to caching).
The transport protocol used is specified by the interface specification on a per-message
basis. Methods, Events, and Fields should commonly only use a single transport protocol.

1. TCP：
 数据大于 1400个字节，且没有严格的延迟要求（可 > 100ms）
2. UDP
数据小于 1400 ，且延时要求较高（< 100ms）
3. UDP + TP分段
数据 大于 1400 且延迟要求高

6.2 Security Considerations for SOME/IP
[PRS_SOMEIP_00946] Restricting Server Connection from Clients
Upstream requirements: RS_SOMEIP_00002
A server may enforce communication policies to protect the server from malicious
or unauthorized clients. I.e. the server may reject subscriptions to eventgroups, or
method calls from unauthorized clients.
Note: These policies are beyond the scope of this specification. Such policies can be
based on the IP address of the client or any other means to identify the client.
[PRS_SOMEIP_00947] Restricting Client Connection to Server
Upstream requirements: RS_SOMEIP_00002
A client may enforce communication policies to protect the client from malicious
servers. I.e. the client may deny communication to unauthorized servers.
Note: These policies are beyond the scope of this specification. Such policies can be
based on the IP address of the server or any other means to identify the client.
总结：通过IP识别，server/client发现对方不认识 对于对方的连接或请求可以不予理会
 

---

0voice · GitHub