SOME/IP 详解系列（2）—— 报文格式

前言

随着车载以太网技术的快速发展，SOME/IP得到了更多在车内网络应用的机会，同时作为SOA架构的重要支撑，也越来越受到人们的关注。但还是有很多人并不是真正的了解SOME/IP，王师傅打算通过《SOME/IP详解》系列的几篇文章，详细的介绍下SOME/IP的背景、定义、工作机制和应用场景，以及如何通过工具去进行SOME/IP的仿真和验证。

SOME/IP报头

通过上篇文章我们知道了SOME/IP是一个通信中间件，位于传输层之上，那么SOME/IP的数据在封装的时候就在传输层头部的后面。下图是一个普通以太网帧格式的示意图，在SOME/IP数据的前面依次是传输层TCP/UDP的头部，网络层IP的头部以及数据链路层的以太网帧头。本文主要介绍的内容是最后面SOME/IP数据的格式，也就是图片的下半部分。

SOME/IP报头的总长度为16个字节，共有9个字段。

Service ID / 16 bits

服务标识，该字段用来表示这条报文属于哪个服务，由用户或系统设计人员自行定义。

Method ID / Event ID / 16 bits

这个字段的第一个bit是标志位，如果标志位为0，表示后面15位为Method ID；如果标志位为1，表示后面15位为Event ID，如下图。

所以具体是Method还是Event，可以从该字段的值来区分，Method ID的范围为0x0000 ~ 0x7FFF，Event ID的范围为0x8000 ~ 0xFFFF。Method和Event为SOME/IP的两种通信方式，在后面的文章中会详细介绍。Service ID和Method ID/Event ID两个字段可以组成Message ID，每个Message ID在车内网络都是唯一的，可以用来标识某个服务的某个接口，该字段由用户或系统设计人员自行定义。

Length / 32 bits

长度，用于表示该字段之后的报头部分及载荷数据的总长度。即从Client ID字段开始一直到SOME/IP报文结束的总长度，单位为字节。所以如果要获取完整SOME/IP报文的长度，需在Length值的基础上加8，即Service ID，Method ID和Length字段的长度。

Client ID / 16 bits

客户端标识，服务器可通过该字段区分不同的客户端，在多个客户端同时请求或使用同一个服务器中的同一个服务时可使用。Client ID也可以设置为车内网络唯一的，这样可以直接用于标识出具体的节点，比如将其高字节设置为诊断逻辑地址。

Session ID / 16 bits

会话标识，可以用来区分来自同一发送者的多条请求，表示请求或消息的顺序。如果使用，应在每次调用后递增，其范围为0x0001到0xFFFF，当达到0xFFFF后，则循环至0x0001重新开始计数。对于请求/响应的method，客户端可通过Session ID来识别正确的响应，如果响应的Session ID与其发送的请求中不一致，应忽略。对于Event，有多种不同场景下的应用，如果不使用该字段，可置为0x0000，接收端直接忽略即可。

Protocol Version / 8 bits

协议版本，表示SOME/IP协议的版本，即SOME/IP的头部格式版本。发送端和接收端所支持的协议版本应一致，如果不一致则无法处理。其作用是通过识别该字段，获得对端的头部格式和协议版本，如果交互的多方支持多个版本，可相互兼容，但实际上该字段默认均置为1。

Interface Version / 8 bits

接口版本，表示接口的版本，在项目中为静态接口描述，即通信矩阵的版本。

Message Type / 8 bits

报文类型，用于表示SOME/IP报文的类型。通过该字段可以识别该报文是请求、响应、通知或者错误等。其中第三位为分段标志位（TP-Flag），用于表示该条报文是否被分段。

TP指SOME/IP-TP（Transport Protocol），是SOME/IP的传输协议，可以简单的理解为是分段传输机制，在下文中会详细介绍。

Return Code / 8 bits

返回码，用于反馈请求是否被正确处理，所以只会在响应或者错误类型的报文中才有意义。对于请求和通知类报文(REQUEST, REQUEST_NO_RETURN, NOTIFICATION) 该字段不使用，应置0x00。下表为每个返回码的值和对应的含义，虽然SOME/IP中定义了很多不同的返回码，但在项目里一般只能看到两种，E_OK和E_NOT_OK。

SOME/IP特殊报头

以上为标准的SOME/IP头部格式，此外，SOME/IP还有两种特殊的头部，分别是携带E2E字段的头部和SOME/IP-TP头部。E2E为端到端的通信保护，如果有功能安全相关的要求，可以在SOME/IP通信中加入E2E机制。如下图所示，E2E头部在SOME/IP头部后面（Return Code后，Payload前），E2E字段具体的格式和长度取决于所使用的E2E profile。

SOME/IP-TP为SOME/IP层的传输协议，在SOME/IP的标准中，对于底层传输协议的选择，有如下建议：

如果对实时性没有太高的要求，对于长度超过1400字节的数据，建议使用TCP协议进行传输；

如果对实时性要求较高，且数据长度小于1400字节，建议使用UDP协议进行传输。

但如果所传输的数据长度超过1400字节，并且对实时性有一定的要求，则可以使用UDP协议配合SOME/IP-TP来实现，如下图所示。

SOME/IP-TP报文的头部是在正常SOME/IP头部的后面（Return Code后，Payload前）增加了一个TP头部，包含Offset、RES和M三个字段，长度固定为32 bits。Offset为偏移字段，表示当前数据分段针对第一个数据分段所偏移的字节数，单位为16字节，如果本身即为第一个分段，则该字段置0（数据分段，segment，将较大的SOME/IP数据分成多个小的数据包，每个数据包均为一个数据分段，简称分段）。因为基于UDP传输的SOME/IP报文最大长度为1400字节，经计算1400÷16=87······8，所以针对上一个分段，这个字段的值最大的变化为87。RES为Reserved字段，默认置0。M为标志位，如果置1表示后续还有更多的分段（M表示more，more segment flag），如果置0表示为最后一个分段。SOME/IP-TP的传输协议有点类似IP的分片机制，将较大的数据包在SOME/IP层级分成多个数据分段（segment），确保每个分段的长度均小于1400个字节，然后再分别封装进UDP报文中，这样即可保证数据不会过长而被IP层分片，又可实现较低的时延。

SOME/IP-TP示例

如果要通过SOME/IP-TP传输一条长度为5880字节的请求报文，分段结果如下。
 

分段时，应最大化使用报文的可载荷长度，每个分段可承载的最大数据为1392字节，表中的8为SOME/IP头部Length字段后面的长度，4为偏移字段的长度，所以前四个分段的Length字段为1404，最后一个分段仅剩312字节（5880-1392×4=312），Length字段为312+8+4=324。Message Type为0x20，因为是请求，并且使用了SOME-TP，所以TP-Flag置1，即0x20。Offset分别是0、87、174、261和348，0表示为第一个分段，与原始数据相比无偏移，87为第二个分段，偏移为第一个分段数据的总长度，即1392 ÷ 16 = 87，以此类推。数据一共被分成了五个数据分段，所以前四个More Segment Flag均置1，表示后续还有分段，第五个置0，表示为最后一个分段。其余字段均按照SOME/IP头部规则正常填充即可。注意，所有分段数据的Session ID字段是相同的。接收端可通过Session ID来识别需要重组到一起的报文。

今天就先分享到这，希望帮助大家对SOME/IP报文的格式和字段有了大致的了解。下一篇文章会继续介绍SOME/IP的通信方式和数据类型。

欢迎关注王师傅的微信公众号“汽车以太网”