Some/IP学习笔记1

[2.SOME/IP 报文格式](#2.SOME/IP 报文格式)

1.概述

SOME/IP全称为Scalable Service Oriented MiddlewarE Over IP，是车载以太网技术中的核心内容，它为网络提供了面向服务的通信方式。一个服务可以包含0个或者多个事件（events），方法（methods）和fields。

Events提供周期性发送的数据或者有变化的数据（从provider到subscriber），单向数据传输；

Methods为subscriber提供远程调用，供subscriber端使用；

Fileds由以下组合；

从provider向subscriber发送变更数据的通知
Subscriber可调用的getter，用于显示向provider提供值
Subscriber想要更改provider端的值时可以调用的setter

Filed中的通知与event的区别在于：event只会在变化时发送，通知除了上述上述功能，还会在订阅后直接发送数据。

在Autosar ECU中，SOME/IP架构如下：

下图为车载SOME/IP的通信demo：

其中，车载以太网100BASE-T1和1000BASE-T1对比如下：

|----------|----------------|---------------|
| | 100BASE-T1 | 1000BASE-T1 |
| 线缆类型 | 1对UTP | 1对UTP |
| 通信方式 | 全双工 | 全双工 |
| 编码方式 | 3B2T to PAM3 | 3B2T to PAM3 |
| 传输频率及位时间 | 66.666MHz/15ns | 750MHz/1.33ns |
| 传输距离 | 15m | 15m |
| PoDL | 支持 | 支持 |
| | | |

2.SOME/IP 报文格式

OSI七层模型中，数据从应用层到物理层经过层层封装然后传输，上三层的数据流在传输层被封装层数据段，在网络层数据段被封装成数据报，在链路层被封装为数据帧，最后在物理层编码陈比特流进行传输，如下：

SOME/IP属于应用层，以中间件的形式为应用层和下层提供通信接口；它用于面向服务的通信，主要特点为：降低负载、兼容AUTOSAR、实现方法复用、扩展，其数据结构如下：

|------------------------|-------------------------------------------|
| 报文格式 | 解释 |
| Message ID(Service ID) | 服务的ID号，16bits，用于标识一个服务(0+15bit MessageID) |
| Message ID(Method ID) | 方法的ID号，16bits，用于标识一个方法(1+15 bit EventID) |
| Length(Byte 0,1) | 报文长度，从Request ID到报文结束的总长度 |
| Length(Byte 2,3) | 报文长度，从Request ID到报文结束的总长度 |
| Request ID(Client ID) | 客户端ID，16bits，区分不同客户端 |
| Request ID(Session ID) | 会话ID，区分同一客户端的连续消息或请求 |
| Protocol Version | 协议版本号 |
| Interface Version | 服务接口版本 |
| Message Type | 报文类型 |
| Return Code | 返回码 |
| Payload | 数据段，需要传输的相关数据 |

Message Type

|--------|-----------------------|-----------------------|
| Number | Value | Description |
| 0x00 | REQUEST | 请求并期望响应 |
| 0x01 | REQUEST_NO_RETURN | 请求但不期望响应 |
| 0x02 | NOTIFICATION | 一个通知/事件回调的请求，不期望有响应 |
| 0x40 | REQUEST_ACK | 0x00的ACK确认 |
| 0x41 | REQUEST_NO_RETURN_ACK | 0x01的ACK确认 |
| 0x42 | NOTIFICATION_ACK | 0x02的ACK确认 |
| 0x80 | RESPONSE | 响应 |
| 0x81 | ERROR | 响应中包含错误 |
| 0xC0 | RESPONSE_ACK | 0x80的ACK确认 |
| 0xC1 | ERROR_ACK | 0x81的ACK确认 |
| 0x20 | TP_REQUEST | TP请求并期望响应 |
| 0x21 | TP_REQUEST_NO_RETURN | TP请求但不期望响应 |
| 0x22 | TP_NOTIFICATION | 一个TP通知/事件回调的请求，不期望有响应 |
| 0xa0 | TP_RESPONSE | TP响应 |
| 0xa1 | TP_ERROR | TP响应中包含错误 |

Return Code

|-----------|---------------------------|------------------------|
| Number | Value | Description |
| 0x00 | E_OK | 没有错误发生 |
| 0x01 | E_NOT_OK | 发生了没有指定的错误 |
| 0x02 | E_UNKNOWN_SERVICE | 未知的服务ID |
| 0x03 | E_UNKNOWN_METHOD | 服务ID预定义相符，未知的Method ID |
| 0x04 | E_NOT_READY | 应用程序没有运行 |
| 0x05 | E_NOT_REACHABLE | 运行该服务的系统不可用 |
| 0x06 | E_TIMEOUT | 发生超时 |
| 0x07 | E_WRONG_PROTOCOL_VERSION | SOME/IP协议版本不支持 |
| 0x08 | E_WRONG_INTERFACE_VERSION | 接口版本不匹配 |
| 0x09 | E_MALFORMED_MESSAGE | 反序列化错误 |
| 0x0a | E_WRONG_MESSAGE_TYPE | 接收到不符合预期的消息类型 |
| 0x0b-0x1f | RESERVED | 预留 |
| 0x20-0x5E | RESERVED | 用于服务和方法的特定错误，由接口规范指定 |

Payload之前的称为SOMI/IP Header

****Payload：****用户自定义数据，由工程师根据节点功能需求对每个服务或方法中的数据进行详细定义。

如果有E2E通信，E2E Header应该放在Payload之上，如下：

SOME/IP的传输必须封装到OSI第四层的报文中进行传输，即封装到UDP/TCP中，需要注意的是使用TCP进行传输时，必须由Client来建议连接或者终止。

3.数据结构序列化

序列化基于接口规范定义的参数列表。接口规范定义了PDU中所有数据结构的确切位置，并且必须考虑存储器对齐。对齐用于通过在数据之后插入填充元素来对齐数据的开头，以确保对齐的数据从特定内存地址开始。