SOMEIP协议重点一览

cengjili

前言

SOMEIP全称 Scalable service Oriented MiddlewarE over IP，看名字就知道这是一个基于以太网的以服务为中心的协议。特点有两个：基于以太网、面向服务。

SomeIP协议是一个汽车电子专有的协议，是一个硬生生被创造出来的协议。这个协议看似面向服务，实际上感觉还是有一点CP的味道，带点确定的成分存在，不是那么完全的动态。

本文仅仅是将SomeIP协议中一些重点内容进行梳理。

名词解释

Service：服务，一个功能

Service ID：服务号

Service Instance：服务实例，一个服务可以有不同的实例

Instance ID：服务实例号

Event：一个服务实例向这个服务实例的使用者发送消息

Event ID：事件号

EventGroup：1个或多个Event的逻辑组合

EventGroup ID:事件组号

Method:客户端向服务端请求其做某件事，服务端返回结果的调用形式。

Method ID：方法号

Message ID：消息号，由Service ID和Method ID或者Event ID组成的32位的数据

Client ID：ECU内客户端的唯一标识符

Session ID：会话ID号，每次调用递增

Request ID：由Session ID和Client ID组成

协议介绍

协议头



特别注意，当Message ID的Bit16置位时，表征Method ID等于Event ID，因此同一个服务既可以以Method也可以以Event形式提供数据。具体表现为：

1. 当以Method形式提供数据时，支持Request-Response,Fire-Forget(消息类型为0x01),Getter/Setter-Response。

2. 当以Event形式提供数据时，支持Notifier、on change、cycle、service discovery,Event的消息类型为0x02，返回码设置为0x00。

3. 消息类型0x00用于RR、Setter/Getter, 返回码设置为0x00,响应的消息类型为0x01, 返回码按需设置。

当有多个程序提供或者使用同一个服务时，Client ID须不同，并且唯一，即f(Service ID, ClientID)是一个可逆函数。SessionID从1开始计数到0xFFFF，再返回0x1。

在实际代码中，会有如下信息出现：







服务发现报文



当MessageID为0xFFFF 8100时，表征这是一个服务发现相关的报文，因为是Event，所以bit16置位以及消息类型为0x02，返回码为0x00，这个特点是所有Event报文均满足的。SD报文更加特殊的一点是ClientID为0x0000，只有SD报文会有这个特点，SessionID对于组播和单播需分别计数。



SD报文分为两个数组：

Entry数组

Option数组

Entry数组中每一个元素中均有两组首地址和长度，首地址表明Option数组的下标，长度表明这个下标索引的范围长度。例如:

两个数组有如下定义Entry[10] 、Option[100]，Entry[0]元素的第一个首地址为2长度2，第二个首地址为7，长度10。则第一个首地址索引Option[2] Option[3]两个元素，第二个首地址索引Option[7~16]总计10个Option元素。

Entry中一个关键字Type。Type定义和Option的关联以及TTL之间的关系如下图所示









服务类型Entry



重要信息有：Type必须为0x00或者0x01。内容有Service ID、Instance ID。

事件组类型Entry



重要信息有：Type必须为0x06或0x07。ServiceID、InstanceID，Eventgroup ID。

由服务发现报文可知，ServiceID、MethodID、InstanceID、EventID、EventGroupID在代码中自定义，实际由整车全局分配，且会体现在服务报文中。

Option信息

服务报文中Option字段划分成如下几个不同的含义：

Endpoint + Multicast Option：

1. IPv4 Endpoint Option（0x04）

2. IPv6 Endpoint Option(0x06)

3. IPv4 Multicast Option(0x14)

4. IPv6 Multicast Option(0x16)

5. IPv4 SD Endpoint Option (0x24)

6. IPv6 SD Endpoint Option(0x26)

它们都是由 Length + Type + Reserved1 + IP 地址 + Reserved2 + 协议类型 + Port 号组成。













Configuration Option:

长度+Type(0x01)+Reserve+( [len] [name] [=] [value])*n + [0]



0x05 ,a,b,c=,x,0x7def=123,’\0’ ==>> 第一段长度5，名字为abc,value为x, 第二段长度为7，名字def，值为123。



Load Balancing Option:

长度+Type(0x02)+Reserve+priority + weight

SomeIP启停

服务发现生命周期内的行为如下所示：



客户端请求服务发现时的行为：



CP侧的SomeIP套路要点



1. 服务发现报文走Sd模块

2. 正常的SomeIP报文走LdCom

Q&A

Service配置信息参考

服务号：0x1234,

实例号：0x5678,

UDP端口号：30509,

服务支持3类事件：

事件号：0x8777，0x8778，0x8779，

这三个事件分别属于3个EventGroup：0x4455,0x4465,0x4555





Event和EventGroup结构体信息





EventGroup中有一个event的集合，端口、地址。Event有ID、周期等信息。

Event数据交互全过程详解

地址1通过239.0.xx.xx多播地址发送Offer Service报文，源端口和目的端口均为1234，信息为：ServiceID 0x3015,Instance ID:0x0001，IP地址1，端口号：4567，UDP协议

地址2通过1234端口向地址1请求订阅时间组（subscribe EventGroup），请求订阅服务0x3015，Instance ID：0x0001,IP地址为地址2，端口号为：4567，事件组为0x01,0x02,UDP协议。

地址1向地址2回复订阅事件组ACK,端口为1234。

地址1向地址2通过4567端口发送SomeIP报文，报文类型为0x02（Notification），这是一个Event类型的报文，服务号0x3015，EventID:0x8003,0x8007。

SomeIP重要信息在通信中的体现

服务发现的端口号以及IP地址：只存在于配置文件中，如果不匹配，则无法实现服务发现。

Service ID：在服务发现报文Entry和SomeIP协议头中存在，在客户端和服务端的代码中存在。

Instance ID：在服务发现报文Entry和SomeIP通讯报文中存在，在客户端和服务端的代码中存在。

Event ID：只存在于配置和客户端服务端代码中，以及存在于SomeIP协议头中。服务发现不会携带此信息。

EventGroup ID:只存在于服务发现报文中。协议头中不存在此信息。

Method ID：Offer service并不携带此信息。只存在于文件配置和协议头中，如果服务端和客户端对Method ID定义的不同，应该无法正常通信。（没试过）

Client ID：存在于协议头中，这个信息并不存在于服务发现报文中。

Session ID：不定义这个数据，有SomeIP协议代码自行决定。

服务提供方和获取方所需的底层通信端口和地址：存在于SomeIP服务发现报文和文件配置信息中。

DDS与SomeIP 服务使用对比

DDS服务端和客户端只要知道一个Topic就可以通信起来了，DDS协议会自动实现服务发现，完成通信双方所需的端口和地址协议信。

而SomeIP要做很多静态配置，SomeIP看似是服务发现，实则需要知道整车网络的SomeIP配置，不然无法实现信息交互。写代码时，服务端和客户端需要知道太多信息了，仅仅知道一个Service ID并不能实现信息交互。