4.1.2 Header 头部

whs_csdn

已于 2023-03-17 09:52:05 修改

阅读量171

点赞数 1

文章标签：测试工具 Powered by 金山文档

于 2023-03-10 14:22:36 首次发布

本文链接：https://blog.csdn.net/whs_csdn/article/details/129441864

版权

报文头的结构应包括

Message ID(Service ID/method ID)[32bit] //即报文ID（号）占4字节这里提示1字节8bit哦字节的英语是byte 位的英语是bit 注意区分）

Length 32bits 长度

Request ID(client ID/session ID) [32 Bits] //请求ID

Protocol version [8Bits] //协议 ID

Interface Version [8 Bits] //接口ID

Message Type [8 Bits] //报文类型

Return Code [8 Bits] //返回代码

//以上提到的英文单词必须记住哦，不然工作中别人说啥你都不清楚，也注意一下发音

如下图所示

//图中payload是负载长度可变（因为报文内容长度不是固定的，比如你发微信给别人，文字信息就可以理解为这里的负载payload）

//covered by length 是说图中第二行length 的长度说的是从这段内容的长度

如果应用了端到端（E2E）加密通信保护，则端到端加密报头放置在返回码之后，这取决于为端到端加密报头选择的偏移值。默认偏移值是64位，它将E2E报头完全放在返回码和有效载荷之间。

如下图所示 //对比可以看出，有E2E的在payload前会有E2E的header（头部）

出于互操作性的原因，对于所有实现的SOME/IP，头布局应该是相同的。字段按传输顺序显示，即左上角的字段先传输。

//比如说someip报文：0x1234 0x5678 0x0000 0x0001 ....... 0x1234是service ID 0x5678 是methodid

// 0x0000 0x0001 是length

4.1.2.1Message ID [32 Bit]

message ID 应该是32位，用来标明以下内容：

一个应用的RPC（远程调用）调用方法

明确事件

注意:MessageID的分配取决于用户/系统设计人员。但是，Message ID被假定为整个系统(即车辆)的唯一标识。

4.1.2.2 Method ID [15 Bit]

方法调用的Message ID需要结构化在 2^16个service(2的16次方因为他占16位) 2^15(2的15次方因为他占15位)个method 的ID中，如表所示

4.1.2.3 Event ID [15 Bit]

事件组是服务内field的事件（event）和通知（notification）事件的逻辑分组，以便允许订阅。

事件和通知使用RPC传输，事件的结构如表所示

//大写加粗哦 event ID 前面1bit是1 methodID前面的1bit是0

不能使用空事件组。

事件（event）和字段通知器（field notifier）被映射到至少一个事件组。

4.1.2.4 Length [32 Bit]

长度字段应该包含字节长度为，从request ID/clientID开始，直到SOME/IP消息结束。

4.1.2.5 Request ID [32 Bit]

RequestID允许提供者和订阅者区分同一方法、事件、getter或setter的多个并行使用。

RequestID对于提供者和订阅者组合(即一个订阅)应该是唯一的

在生成response message时，提供者（服务端哦）应该将请求ID从请求复制到response message里。

注意：这允许订阅者将响应映射到已发出的请求，即使有多个未完成的请求。

在响应到达或预期不再到达(超时)之前，不能重用请求id。

Structure of the Request ID

在AUTOSAR中，请求ID应由客户端ID和会话ID组成，如表所示

注意:

这意味着ECU的实现者可以根据实现的需要定义client- id，而提供者不需要知道这种布局或定义，因为他只需要在响应中复制完整的Request-ID

client ID是ECU内调用客户端的唯一标识符。client ID允许ECU区分多个客户端对同一方法的调用。

session ID（会话ID）是一个唯一的标识符，允许区分来自同一发送方的连续消息或请求。//比如我给小明打电话分为第一次、第二次

客户端ID还应支持通过具有可配置的前缀或固定值(例如，客户端ID的最重要字节是诊断地址或为给定应用/SW-C配置的客户端ID)在整个车辆中是唯一的。

如果会话处理不活跃，session ID应该设置为0x00。

如果会话处理处于活动状态，则session ID应设置为范围[0x1, 0xFFFF]

在会话处理处于活动状态的情况下，session ID应该根据各自的用例增加(关于专用用例的详细信息包含在单独的规范项中(例如，

请求/响应方法应该使用带有会话id的会话处理。session ID应该在每次调用后递增。

当session ID达到0xFFFF时，它将从0x01重新开始

对于请求/响应方法，如果响应的Session ID与请求的Session ID不匹配，订阅者必须忽略响应

对于通知消息，如果会话处理不活跃，接收方应该忽略会话ID。

如果会话处理是活动的，对于通知消息，接收方应该根据各自的用例来处理会话ID(关于专用用例的详细信息包含在单独的规范项中(例如，[PRS_SOMEIP_00741] 后面有提到)。

4.1.2.6 Protocol Version [8 Bit]

协议版本标识所使用的SOME/IP报头格式(不包括有效载荷格式)。

协议版本应该是一个包含SOME/IP协议版本的8位字段。

对于SOME/IP报头中所有不兼容的更改，协议版本应增加。如果基于旧协议版本的接收方不丢弃消息并不正确地处理消息，则更改是不兼容的。

注意:消息处理和错误处理在4.2.6.3章中定义(错误处理概述

注意:协议版本本身是SOME/IP报头的一部分，因此协议版本在报头中的位置不应被改变。

协议版本为1 //目前 protocol version 都写1就行

4.1.2.7 Interface Version [8 Bit]

接口版本应该是一个8位字段，包含服务接口的主要版本。

4.1.2.8 Message Type [8 Bit]

MessageType字段用于区分不同类型的消息，应该包含如下表所示的值

Number	Value	Description
0x00	REQUEST	期待回复的请求 (even void)
0x01	REQUEST_NO_RETURN	一个FF请求
0x02	NOTIFICATION	没有响应的通知/事件回调请求
0x80	RESPONSE	回复信息
0x81	ERROR	回复包含一个错误
0x20	TP_REQUEST	A TP request expecting a response (even void) //SOME/IP-TP报文期待回复的请求
0x21	TP_REQUEST_NO_RETURN	A TP fire&forget request //SOME/IP-TP报文一个FF请求
0x22	TP_NOTIFICATION	A TP request of a notification/event call back expecting no response //SOME/IP-TP报文没有响应的通知/事件回调请求
0xa0	TP_RESPONSE	The TP response message //SOME/IP-TP报文的回复报文
0xa1	TP_ERROR	The TP response containing an error //SOME/IP-TP报文的回复报文包含错误

当没有发生错误时，常规请求(消息类型0x00)将由响应(消息类型0x80)回答。如果发生错误，将发送错误消息(消息类型为0x81)。

也可以发送没有响应消息(消息类型0x01)的请求。为了通过通知更新值，存在一个回调接口(消息类型0x02)。 //注意：有回调和没回调的区别

消息类型(=0x20)的第三高位称为TP-Flag，应该设置为1以表示当前的SOME/IP消息是一个segment。消息类型的其他位在本节中指定。

消息类型请求(0x00)的段具有消息类型(0x20)，消息类型响应(0x80)的段具有消息类型(0xa0)，依此类推。详见(4.2.1.4章)

4.1.2.9 Return Code [8 Bit]

返回码应使用，表示请求是否被成功处理。为了简化报头布局，每条消息都传输字段ReturnCode。

表4.6显示了特定消息类型允许的返回码返回码应使用，表示请求是否被成功处理。为了简化报头布局，每条消息都传输字段ReturnCode。表4.6显示了特定消息类型允许的返回码

4.1.2.10 Payload [variable size]

在有效载荷字段中携带参数。参数的序列化将在下一节中说明。

SOME/IP有效载荷字段的大小取决于所使用的传输协议。使用UDP,SOME/IP有效载荷应该在0到1400字节之间。限制为1400字节是为了允许未来对协议栈的更改(例如更改为IPv6或添加安全手段)。由于TCP支持有效载荷的分段，因此自动支持更大的尺寸。

有效负载可能由事件的数据元素或方法的参数组成

4.1.3 Endianess

SOME/IP报头应按网络字节顺序(大端序)编码。

payload内参数的字节顺序应由配置定义。 //即开发人员自己定

以上做个总结通信协议就像写信一样，或者发微信吧，message ID就像对方的微信号，RequestID、protocol ID....就像相当于自己的微信号，必须知道双方的“微信号”你才能发信息 ... 所有的ID都是一个作用，为了让双方能理解对方的信息，payload就是信息，后面讲到的序列化就是payload应该怎么填充，比如写信开头必须先写“收件人名字你好”等等。length就是说你这封信要写多长，因为写太多了“信封可能容纳不下”（即UDP协议限制的最大负载字节数）

好的继续吧