前言
SOME/IP协议越来越多的用于汽车电子行业中，关于协议详细完全的中文资料却没有，所以我将结合工作经验并对照英文原版协议做一系列的文章。基本分三大块：
1. SOME/IP协议讲解
2. SOME/IP-SD协议讲解
3. python/C++举例调试讲解
Note: This means that the implementer of an ECU can define the Client-IDs as required by his implementation and the provider does not need to know this layout or definitions because he just copies the complete Request-ID in the response.
server不需要关心requestID的布局和内容 ，只需要拷贝回复就行
ClientID可用于区分不同的 ECUs
[PRS_SOMEIP_00702]
Upstream requirements: RS_SOMEIP_00025, RS_SOMEIP_00027
The Client ID is the unique identifier for the calling client inside the ECU. The Client
ID allows an ECU to differentiate calls from multiple clients to the same method.
每个ECU有唯一ClientID , 用来区分对同一方法的请求。一般情况client的IP port 足以区分不同的client，server端不用校验关心clientID。
也意味着每个ECU 如果运行多个SOME/IP-Client（ip/port会不一样）但ClientID必须一样。
[PRS_SOMEIP_00703]
Upstream requirements: RS_SOMEIP_00002, RS_SOMEIP_00025, RS_SOMEIP_00027
The Session ID is a unique identifier that allows to distinguish sequential messages
or requests originating from the same sender from each other.
# 对于server而言clientID 是区分不通ECU，但是同一个ECU发送的连续消息(notify)或请求(method/getter/setter)
就需要通过sessionID来的唯一性来区分了。
两种情况：
1. method/getter/setter --> client在未超时等待回复之前，继续请求 则用sessionID来区分
2. 不区分情况（除了下面的情况）sessionID 只管加1。
另外：
3. notify --> 大消息需要分包发送 --> 在分包发送的所有子包seesionID都一样。
注：一个ECU多个client的情况对于同一请求时sessionID可以相同，i
p/port有做区分了。
[PRS_SOMEIP_00532]
Upstream requirements: RS_SOMEIP_00025, RS_SOMEIP_00027
The Client ID shall also support being unique in the overall vehicle by having a
configurable prefix or fixed value (e.g. the most significant byte of Client ID being the
diagnostics address or a configured Client ID for a given application/SW-C).
# 每个ECU有唯一ClientID , 用来区分对同一方法的请求。又是在车辆中ClientID 又分出来前8位作为前缀来区分车辆（SOMEIP有可能跨车辆通信）
[PRS_SOMEIP_00932]
Upstream requirements: RS_SOMEIP_00027
In case Session Handling is not active, the Session ID shall be set to 0x00.
未激活态（没有请求-回复成对出现的场景）需要设置为0
一问：SOME/IP的offer报文中 sessionID可以设置为0吗？
在 SOME/IP 协议中，sessionID 是用来标识会话的唯一标识符。根据 SOME/IP 协议的定义，sessionID 的设置通常是由服务端生成的，并且它的值应该是唯一的，用于区分不同的会话。
理论上，sessionID 可以设置为 0，但是通常不推荐这么做。因为 0 作为 sessionID 在一些情况下可能会引起歧义，特别是在会话管理方面，可能导致客户端和服务端无法正确区分不同的会话。
如果没有特定的理由（如系统设计要求），通常 sessionID 应该是一个非零的唯一值，以确保会话的唯一性和稳定性。
二问：sessionID是管理会话的，是用来区分client端同一个ECU连续请求的，那对offer报文而言没有会话的概念啊（因为没有请求-回复成对出现），仅是server端自己的行为。sessionID为啥不推荐设置为0？
你说得对，offer 报文并不涉及请求-回复的配对，因此对于 offer 报文来说，sessionID 并没有管理会话的作用。在 offer 报文中，sessionID 主要用于标识服务端的行为，而不是客户端的请求。
关于是否推荐将 sessionID 设置为 0，这里的关键是协议和实现中的约定。虽然在 offer 报文中，sessionID 可能没有严格的会话管理功能，但是：
-
一致性：为了与后续的请求/响应报文保持一致，许多实现会选择将
sessionID设为非零值，避免在后续的报文中使用0作为有效标识符。这样做是为了避免不必要的混淆或冲突。 -
协议兼容性：某些协议或库可能会对
sessionID = 0的情况有特殊的处理，或者在某些实现中可能会假设0表示某种特殊情况（例如，表示没有分配会话标识符）。虽然这种情况不常见，但仍然存在一定的风险。 -
扩展性和可维护性：虽然目前没有会话的概念，未来的协议扩展或实现可能会在
offer报文中加入会话管理的需求。为了保证协议的可扩展性和兼容性，一些实现会避免使用0作为sessionID，以减少后期维护的复杂性。
综上所述，虽然技术上 sessionID = 0 在 offer 报文中是可行的，但为了避免潜在的问题，通常还是推荐使用非零的 sessionID，即使它并不直接影响 offer 报文的功能。
三问：那什么情况下sessionID需要设置为0？
sessionID = 0 在 SOME/IP 协议中通常是在某些特殊情况下使用的，主要有以下几种情况：
1. 无会话标识的初次请求
在某些情况下，sessionID = 0 可以用来表示没有会话标识的初始请求。这通常发生在：
- 服务发现阶段：当客户端首次发起与服务端的通信时，可能没有一个具体的会话标识符。在这个阶段，
sessionID可能被设为0，表示没有关联的会话。 - 服务提供报文：如
offer报文，它通常没有具体的会话关联，因此可以将sessionID设置为0，表示这只是一个服务提供的通知，并不关联某个特定的会话。
2. 没有会话的特定报文
有时 sessionID = 0 可以用来表示没有会话的特殊报文，这些报文不会触发请求-响应的对等操作。例如：
- 心跳报文：一些心跳或生命检查报文可能不需要会话标识符，可以将
sessionID设置为0。 - 服务生命周期管理报文：当服务启动、停止或重新初始化时，服务端可能会发送一些不与具体会话相关的通知报文，
sessionID可以设置为0。
3. 特殊标识符
在一些自定义的实现中，sessionID = 0 可能用作特殊的标识符，例如：
- 用于表示某些不依赖于会话标识符的全局广播消息。
- 服务端在提供服务时，可能会使用
sessionID = 0来表示“无会话”的服务或通知，而不是关联到特定的客户端会话。
4. 初始化或配置过程
在系统的初始化或配置阶段，sessionID 可能被设置为 0，用于表示这不是一个正式的会话请求。这些报文通常用于协商协议、配置服务，或者进行一些系统级别的初始化操作。
总结：
sessionID = 0 主要用于那些不涉及具体会话的报文，通常是在服务发现、初始化、特殊通知或者无会话的情形下使用。对于不依赖会话标识符的报文，这种做法可以简化实现，同时避免与会话管理产生冲突。
如果是在正常的请求-响应流程中，sessionID 通常不应该是 0，因为它用于区分不同的会话，确保客户端和服务端之间的状态管理。
[PRS_SOMEIP_00933]
Upstream requirements: RS_SOMEIP_00027
In case Session Handling is active, the Session ID shall be set to a value within the range [0x1, 0xFFFF]. --- sessionID的范围
[PRS_SOMEIP_00934]
Upstream requirements: RS_SOMEIP_00027
In case Session Handling is active, the Session ID shall be incremented according to
the respective use case (detailed information about dedicated use cases is contained
in separate specification items (e.g., [PRS_SOMEIP_00533]).
[PRS_SOMEIP_00533]
Upstream requirements: RS_SOMEIP_00012, RS_SOMEIP_00027
Request/Response methods shall use session handling with Session IDs. Session ID
should be incremented after each call.
[PRS_SOMEIP_00521]
Upstream requirements: RS_SOMEIP_00012, RS_SOMEIP_00027
When the Session ID reaches 0xFFFF, it shall wrap around and start again with 0x01
针对于methods的Request/Response 没调用一次sessionID递增1，递增到0xffff后再下一次就变成0x01了。
getter/setter 不用递增。不可设置为0
notify也不用递增。可设置为0
SD报文的sessionID 可以随意设置，client端对于SD报文的回复中的sessionID也不应判断。
[PRS_SOMEIP_00739]
Upstream requirements: RS_SOMEIP_00012, RS_SOMEIP_00027
For request/response methods, a client has to ignore a response if the Session ID of
the response does not match the Session ID of the request
对于client 收到的method回复中的client不是自己期望的sessionID 则忽略这条回复。
[PRS_SOMEIP_00935]
Upstream requirements: RS_SOMEIP_00012, RS_SOMEIP_00027
For notification messages, a receiver shall ignore the Session ID in case Session Handling is not active.
对于notify消息，client不用关心 sessionID （就算是0）
[PRS_SOMEIP_00936]
Upstream requirements: RS_SOMEIP_00012, RS_SOMEIP_00027
For notification messages, a receiver shall treat the Session ID according to the
respective use case (detailed information about dedicated use cases is contained in
separate specification items (e.g., [PRS_SOMEIP_00741]) in case Session Handling
is active.
结合 741 ：
notify事件 的sessionID 如果设置为激活态则可以有其它用途：如果是大消息则分包发送，根据sessionID来组包。比如收到1 ， 2， 3， 4，1当又收到1时则把前面的4包进行组包。注意：大消息的可搭配message_type: TP_XXX的类型使用（下面讲），也可不搭配。
当然双方标记次消息没有组包功能的话，则可以随便设置sessionID.
扩展：UDP的大消息会在IP层进行分包，接收端IP层重新组包，SOMEIP的UDP大消息发送，如果没有丢包或错帧干扰，则会接收到完整的大消息。
TCP的大消息不会把分包交给IP层 ，会自己在TCP层做好分包。如果SOMEIP的大消息发出，虽然不会丢包但会在server端收到不完整的多包数据，甚至第二包数据开始都没有SOMEIP头。
综上所述：如果像车内这种TTL路由不超过3次的局域网 不怕UDP丢帧可以用UDP发送SOMEIP大消息。否则TCP发送SOMEIP大消息 则需要用到sessionID来进行分包组包。
4.1.2.5 Protocol Version [8 Bit]
The Protocol Version identifies the used SOME/IP Header format (not including the
Payload format). -- 协议版本号仅用于区分header 格式的不通 ，不针对Payload的格式。
[PRS_SOMEIP_00052]
Upstream requirements: RS_SOMEIP_00027, RS_SOMEIP_00041
Protocol Version shall be an 8 Bit field containing the SOME/IP protocol version. -- 占一个字节
[PRS_SOMEIP_00050]
Upstream requirements: RS_SOMEIP_00027, RS_SOMEIP_00041
The Protocol Version shall be increased, for all incompatible changes in the SOME/IP
header. A change is incompatible if a receiver that is based on an older Protocol
Version would not discard the message and process it incorrectly.
如果header的格式和定义有所改变，则版本号需要改变--这是AUTOSAR协议组织干的事。
写程序的人需要根据版本号做兼容解析处理，不能直接丢弃消息---目前就一个版本。
Note:
Message processing and error handling is defined in chapter 4.2.6.3 (error processing
overview) -- 版本不匹配的错误码回复 在后面有讲
Note:
The Protocol Version itself is part of the SOME/IP Header, therefore the position of the
protocol version in the header shall not be changed.
为什么要强调版本号在SOMEIP头第15个字节的位置不可改变：因为后面如果SOMEIP的版本迭代，其它字段的位置可能会被改变，但是第15个字节必须还是版本号，因为要依赖识别版本迭代。
Note:
The Protocol Version shall not be increased for changes that only affect the Payload
payload的格式变化 不能引起协议版本号的增加。
format.
[PRS_SOMEIP_00051]
Upstream requirements: RS_SOMEIP_00027, RS_SOMEIP_00041
The Protocol Version shall be 1.
这份协议文档 对应的SOMEIP版本号 为1
4.1.2.6 Interface Version [8 Bit]
[PRS_SOMEIP_00053]
Upstream requirements: RS_SOMEIP_00003, RS_SOMEIP_00027
Interface Version shall be an 8 Bit field that contains the Major Version of the Service
Interface. -- 占一个字节
内部版本号的内部什么意思？
内部是用户自己对服务的定义的意思，client端需要和server端针对此服务进行版本号对齐。
比如服务的某个method的参数发生了变化，导致双方通信错误。
server和client可能有多个服务，每次一个服务做了修改，升级这个服务的内部版本号还是所有服务的版本号都跟着升级 需要使用者自己考虑。
4.1.2.7 Message Type [8 Bit]
TP_XXX --->是大消息分包的意思。
[PRS_SOMEIP_00701]
Upstream requirements: RS_SOMEIP_00008, RS_SOMEIP_00027
Regular request (message type 0x00) shall be answered by a response (message
type 0x80), when no error occurred. If errors occur an error message (message type
0x81) shall be sent. -- 容易理解 自己看
It is also possible to send a request that does not have a response message (message
type 0x01). -- Fire&Forget消息 简称 F&F消息 -- 不用回复的消息
For updating values through notification a callback interface exists
(message type 0x02).
[PRS_SOMEIP_00367]
Upstream requirements: RS_SOMEIP_00027, RS_SOMEIP_00051
The 3rd highest bit of the Message Type (=0x20) shall be called TP-Flag and shall be
set to 1 to signal that the current SOME/IP message is a segment. The other bits of
the Message Type are set as specified in this Section.
第三个最高位0x20是TP标志 表示传输协议，表示大消息传输 可用于文件传输等，需要搭配sessionID 使用
Note:
Segments of the Message Type Request (0x00) have the Message Type (0x20), segments
of the Message Type Response (0x80) have the Message Type (0xa0), and so
on. For details see (Chapter 4.2.1.4)
0x20是分段的0x00, 0x0a是分段的0x80
容易理解 自己看
4.1.2.9 Payload [variable size]
In the payload field the parameters are carried. The serialization of the parameters will
be specified in the following section. -- 序列化在下面的章节讲
The size of the SOME/IP payload field depends on the transport protocol used.
payload的大小 受它使用TCP/UDP传输协议决定
[PRS_SOMEIP_00382] SOME/IP payload size using UDP
Upstream requirements: RS_SOMEIP_00006, RS_SOMEIP_00010
With UDP the SOME/IP payload size should be between 0 and 1400 Bytes. Payload
sizes greater than 1400 Bytes should be supported with TCP and segmentation of
payload (see also [PRS_SOMEIP_00730]).
低于1400个字节 可以用UDP传输，否则应该用TCP传输 或是 UDP分包传输。
Note:
The recommendation to 1400 Bytes improves change compatibility on the protocol
stack (e.g. changing to IPv6 or adding security means).
Payload might consists of data elements for events or parameters for methods.
https://github.com/0voice
