SOME/IP学习笔记3

目录

1.SOMEIP Transformer

1.1 SOME/IP on-wire format

1.2 协议指定

2. SOMEIP TP

2.1 SOME/IP TP Header

3.小结

---

1.SOMEIP Transformer

       根据autosar CP 相关规范，SOME/IP Transformer主要用于将SOME/IP格式的数据序列化，相当于一个转换器。总体框架如下：

       如上图，SWC通过RTE处理数据，然后RTE执行相关的SOME/IP转换，将数据序列化转换为线性模式；接收端进行反序列化，最后传给另一个SWC。

1.1 SOME/IP on-wire format

        车载网路中PDU数据格式如下：

• 报文长度限制

        当前用于CAN或FlexRay的数据长度限制为4095bytes；因此一个包含Header的SOME/IP报文不应该超过4095bytes。

• 大小端

        Header均以大端表示，payload由SOMEIPTransformationDescription表示。

• Header

        详见报文格式Some/IP学习笔记-CSDN博客

• 参数和数据结构的序列化   

        支持序列化的基础数据类型如下：

        结构体的序列化：

        按照深度优先遍历的顺序进行序列化；如果需要对齐，在AUTOSAR数据类型中插入保留/填充元素，因为SOME/IP实现不会自动添加此类填充。

        例如，如果一个结构包含一个uint8和一个uint32，它们只是顺序写入缓冲区。这意味着uint8和uint32的第一个字节之间没有填充；因此，uint32可能没有对齐。因此，系统设计者必须考虑向数据类型添加填充元素，以实现所需的对齐或全局设置。

        如果SomeiptTransformationProps的属性sizeOfStructLengthField设置为大于0的值，则应在为其定义SomeiptTransformationProps的序列化结构之前插入长度字段。结构体的序列化有如下两种方式：

1.2 协议指定

        协议又分为Client/Server和Sender/Receiver

• Client/Server通信

对于SOME/IP的请求message，Client端的SOME/IP transformer对payload和header做以下处理：

1.  构建payload、设置独立的request ID、设置协议版本、设置接口版本、设置请求的message类型，returncode=0；
2.  Server端的SOME/IP transformer应构建header，并处理payload、设置messageType为RESPONSE。

• Sender/Receiver通信

        这里留个记录，暂时没有看到这里来

2. SOMEIP TP

        SOME/IP TP主要是将SOME/IP packet碎片化(UDP packet无法存放完整帧)，接收端重新组装。

2.1 SOME/IP TP Header

        当MessageType中TP-Flag置1后，header变为如下结构：

        这里多出了4字节的内容，分别是28bit的offset、3bit的reserved bits和1bit 的More Segment Flag

• TP-Flag处于第18位。
• Offset Field：紧跟在return code，随着SOME/IP segment的发送或接收增加。每增加1相当于16个bytes已经接受或传输，例如offset值为92，表示已经传输了92*16=1472个字节的数据。
• More Segment Flag置1，表示继续有SOME/IP PDU segment传输。

        现在假设要发送一个5571byte的SOME/IP报文、数据长度为8+5571；表示报文长度为8字节，总长为5571.

        现在将其分为5个连续的SOME/IP segments，每个最长payload为1392bytes。那么对应划分如下：

        8为报文长度、4为offset+res+m、1392为payload长度。

        结合上述，前4个segment总体结构如下：

        最后一个为:

3.小结

        总结一下，目前对于SOME\IP的认知还比较浅显，全是基础概念，所以接下来要进一步深入，搭建测试环境，入门车载以太网