SOME/IP ( Scalable service-Oriented MiddlewarE over IP):运行于IP之上的可伸缩的面向服务的中间件。它在系统中其实就是一个中间件的存在,所谓“Middleware中间件”是一种独立的系统软件或服务程序。
基于以太网通信协议传输,SomeIp属于应用层,他就需要依赖传输层的TCP/UDP协议,一个SomeIP服务可以通过以下方式传输所有的Method,Event,Field,
1)TCP连接,2)UDP单播,3)UDP多播
在一帧以太网数据中的位置如下所示
车载以太网协议栈总共可划分为五层,分别为物理层,数据链路层,网络层,传输层,应用层,其中SOME/IP是一种应用层协议。
Method ID:分为Event/Notifier和Method,Event ID的最高位为1,一般像0x8001,0x8002等;Method最高位为0,例如0x0001。
Client ID:区分请求同一服务Service 的不同客户端,在整车系统中该值必须唯一。
Session ID:同一客户端请求同一服务Service 的次数;从0x0001 开始,达到0xFFFF 后,重新从0x0001 开始循环。
Message Type说明:
Return Code说明:
为了避免不必要的通信延时,SOME/IP 模块应该有能力同时处理20 条报文。
发送端可以封装多条SOME/IP 报文在一条以太网报文中。
接收端必须能够正确解析一条以太网报文中封装的多条SOME/IP 报文。
测试Case:SOMEIP_TEST_61 在一个UDP包中发送两条SOMEIP消息。DUT必须回复所有两条SOMEIP消息并发送正确的响应。如下图所示
在一个服务中,有服务端和客户端两个角色。对于同一个服务,只能存在一个Server,但可以同时存在多个Client调用服务。一个Service可以包含多个Method/Event/Field,Server和Client间的通讯就是通过RPC(Method/Event/Field)实现。
Mehod分为
1)FF(Fire&Forget)即Client向Server发送请求命令,Server解析后不需要回复Server。在Autosar配置中一般定义位S/R接口;
2)RR(Request & Response)即Client向Server发送请求命令,Server解析后,作出相应的响应。在Autosar配置中一般定义为C/S接口;
一个单向的数据传输,当订阅(SomeIP-SD)成功后,事件发生(只能是on change类型)时,Server端主动向订阅的Client端发布(Publish)信息。Event没有初始值,生命周期没有定义。在SomeIP实现中一般情况需要Trigger触发Event。
Field由下面三部分构成:
Getter(RR):获取,由 ,一般Payload中为空。Autosar中C/S接口。
Setter(RR):设置,由Client端发送数据到Server端,更改Server端的数据,并回复更改的值。Autosar中C/S接口。
Notifier(FF):通知,Client端订阅Server端服务成功后,Server端第一时间主动向Client端发送对应的数据通知。Autosar中S/R接口。
扩展请参考Autosar:1)SR接口(SenderReceiverInterface):SR接口主要是通过dataelement,来定义传输数据的每一个部分。SenderReceiverInterface可以用于1对1,1对多,多对1,即可以是多个发送方,也可以是多个接收方,可以定义一个或多个dataelement,但是不可以多个发送方对多个接收方,这在AUTOSAR中是不允许的。
2)CS接口(ClientServerInterface):C/S接口就是客户/服务接口,这个接口就是客户端来调用服务端的一个操作接口。意思是我想调用一个函数,而这个函数在其他的C文件中,就让RTE帮忙调用。
SomeIP在Autosar架构中的位置
SoAD:Socket Adapter 用以以太网中的Socket适配,主要将以太网传输的Socket和Pdu进行关联。SoAd的主要目的是在使用PDU的Autosar通信服务模块和基于Socket的TCP/IP堆栈之间创建一个接口。
PDUR:会将COM下发的信号数据分配到相应的协议总线上或将不同的协议变成同一信号上传给COM。
序列化(Serialization)指的是将数据结构或对象依据事先定义的规则转换成二进制串的过程;
反序列化(Deserialization)指的是将二进制串依据相同规则重新构建成数据结构或对象的过程。
如上图,在AUTOSAR中是指数据在PDU中的表达形式,可以理解为来自应用层的真实数据转换成固定格式的字节序,以实现数据在网络上的传输。软件组件将数据从应用层传递到RTE层,在RTE层调用SOME/IP Transformer,执行可配置的数据序列化(Serialize)或反序列化(Deserialize)。SOME/IP Serializer将结构体形式的数据序列化为线性结构的数据;SOME/IP Deserializer将线性结构数据再反序列化为结构体形式数据。在服务端,数据经过SOME/IP Serializer序列化后,被传输到服务层的COM模块;在客户端,数据从COM模块传递到SOME/IP Deserializer反序列化后再进入RTE层。
someip序列化和反序列是在SomeIpXf.c中实现的。其中一个序列化函数如下,前面是Someip header,后半部分是data序列化
1)对于固定长度的数据,SOME/IP transformer 不会因为对齐而自动填充数据;如果固定长度数据元素后面的数据需要填充,则必须在Interface 表格中明确定义这一点。
2)对于可变长度的数据,应考虑对齐而使用填充。
3) 对齐应从SOME/IP 报文的起始开始计算;为了简化代码生成器,目前对齐被限制为1 个字节的倍数(例如,8bits、16bits、32bits);本项目至少要支持4 字节的对齐。
4)如果在反序列化期间,比预期更多的数据交予SOME/IP transformer 处理;那些非预期的数据应该被忽略。
5) 如果在反序列化期间,比预期更少的数据交予SOME/IP transformer 处理;则应按照以下方式处理:
如果本地接收方可提供缺少的数据的预设值或初始值(在序列化表格中),则使用该值填充序列化流末尾缺少的元素。
如果无法提供可用的值,则反序列化中断。
根据测试规范《OA_Automotive_Ethernet_ECU_TestSpecification_Layer_3-7_v3.0》,可以通过CANOE5640设备编写脚本。其中一个测试case如下
协议栈对应测试Case:
以下是Tester端作为服务端,DUT作为客户端(一般DUT作为服务端)。
SOMEIP_ETS_103: SD_ClientServiceGetLastValueOfEventTCP;
SOMEIP_ETS_104: SD_ClientServiceGetLastValueOfEventUDPMulticast;
SOMEIP_ETS_105: SD_ClientServiceGetLastValueOfEventUDPUnicast。
下篇:车载以太网之SomeIP-SD协议
车载以太网之DoIP协议_第一篇