目录
[1.SOMEIP Transformer](#1.SOMEIP Transformer)
[1.1 SOME/IP on-wire format](#1.1 SOME/IP on-wire format)
[1.2 协议指定](#1.2 协议指定)
[2. SOMEIP TP](#2. SOMEIP TP)
[2.1 SOME/IP TP Header](#2.1 SOME/IP TP Header)
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做以下处理：
- 构建payload、设置独立的request ID、设置协议版本、设置接口版本、设置请求的message类型，returncode=0；
- 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的认知还比较浅显，全是基础概念，所以接下来要进一步深入，搭建测试环境，入门车载以太网