自动驾驶平台中间件，自动驾驶中间件之OME/IP通信机制介绍

很多朋友对自动驾驶平台中间件，自动驾驶中间件之OME/IP通信机制介绍不是很了解，每日小编刚好整理了这方面的知识，今天就来带大家一探究竟。

SOME/IP是大家熟知的以太网上层协议，但是它的诞生历史和协议内容却不太为人所知！SOME/IP的诞生是以太网引入汽车后的进一步发展，所以我们需要从车载以太网的历史说起。01.以太网被引入汽车。

2004年，宝马的OBD诊断端口使用了500 kbit/s的高速CAN总线，除去CAN协议本身的开销，通过OBD端口升级控制器的净升级速度降低到200 kbit/s，预计到2008年，软件更新的数据量将达到1GB。按照现在CAN的速度，更新一次软件要16个小时，肯定是不行的。内部讨论后，升级1GB数据的性能参数设为15min，转换速度约为9Mbit/s，因此考虑引入新的刷总线。

从当时已有的选择来看，只有MOST和USB可选。虽然Flexray的速度可以达到10Mbit/s，但是2004年还没有推出，2006年才会推出。2004年，大部分公交车仍然是MOST25，速度大约为7Mbit/s，勉强合格。2001年引入宝马，主要用于同步音频通信。然而，它也有一些缺点：

总线拓扑问题，因为大部分总线必须是环形拓扑，这就意味着在测试仪和网关之间必须增加另一个拓扑环，或者在连接测试仪之前必须连接一个临时的扩展环，增加了复杂度。资源要求高，为了达到7Mbit/s的最大带宽，需要1014B的包，需要64个包组成一个块(这是MOST-high协议的一部分)，也就是说光包的接收需要64KB的RAM，在当时是太多了。

新的接口，MOST25升级版，属于全新的接口，与现有的不兼容，需要另外一套诊断应用，这也意味着高成本。USB作为消费类设备的接口，在PC上非常常见，适合外接测试仪，通信速度高达480bit/s，远远高于需求。但是它的缺点太明显了：鲁棒性和抗扰度不够，而且为了保证信号的完整性，USB需要昂贵的线缆和连接器。

USB支持的最大线缆长度为4m，难以覆盖使用场景。有必要开发一个基于汽车的协议栈和驱动程序。

在上述现有的都不能满足需求后，宝马开始研究以太网，因为以太网是一种经过充分验证的技术，基础设施好，传输速度足够。

在评估以太网在汽车上的适用性时，最关键的部分是物理层。首先，预计像USB一样，需要昂贵的电缆和连接器来满足鲁棒性。宝马通过用非屏蔽双绞线替换以太网电缆来测试抗扰度。结果表明，非屏蔽电缆也满足要求，不需要做任何修改。

所以宝马开始把以太网应用到汽车上，包括组织联盟建立车载以太网标准，比如开放联盟，开始基于以太网的上层协议，比如下面要讨论的SOME/IP。02.什么是一些/IP？SOME/IP是可扩展的面向服务的中间件over IP的缩写，由宝马于2011年开发。名字清楚地表明它是一个中间件解决方案，可以实现控制器之间面向服务的通信。

更具体地说，一些/IP提供了广泛的中间件功能，如序列化、远程过程调用(RPC)、服务发现和订阅，以便ECU软件可以相互通信。

SOME/IP的一些主要特性：序列化和反序列化：将数据结构转换为字节序列或将字节序列转换为数据结构，有利于高效的数据传输。远程过程调用(Remote Procedure Call，RPC):是客户端需要从服务器端获取一些数据时采用的一种数据交换方式。RPC可以返回值，也可以不返回值，即客户端可以请求数据作为响应，或者只是调用一个函数来执行服务器端的一些任务。

服务发现：服务发现(SD)协议是一些/IP概念的基础。在面向服务的架构中，服务(功能实体——方法、事件或字段)必须是可发现的。某/IP SD协议管理此方面——是否提供服务或阻止其可用。

发布/订阅：客户端可以订阅服务器的内容，这样它就可以动态地从服务器接收更新的数据。某些/IP的发布/订阅功能推断客户需要什么数据(事件/字段)并共享相同的数据。发布/订阅由SOME/IP SD管理。2014年，部分/IP正式集成到AUTOSAR 4中。x，并且不断发展完善：AUTOSAR 4.0——完成了宝马部分/IP消息的初步整合；AUTOSAR 4.1-支持SOME/IP-SD及其发布/订阅功能；

AUTOSAR 4.2-添加transformer进行序列化和其他相关优化；AUTOSAR 4.3-修复了一些transformer bug，并为大量UDP包添加了一些/IP-TP协议，以及其他一些/IP-SD优化工作。SOME/IP协议SOME/IP协议首先定义了消息的格式，如下图所示。一些/IP消息格式(来自AUTOSAR)

消息ID消息ID通常也称为消息ID，长度为32位，包括16位的服务ID和方法ID。每个SOME/IP消息都有一个唯一的消息ID，类似于CAN ID。当定义为方法时，方法ID的最高有效位值为0；定义为事件时，方法ID的最高有效位为1，此时的方法ID也称为事件ID。每个服务应该由唯一的服务ID来标识；在同一个服务中，不同的方法和事件也有唯一的方法ID或事件ID作为标识。

长度字段的长度为32bit，指的是从请求ID到有效载荷的长度。请求ID(请求ID)请求ID长32位，由客户端ID和会话ID组成。客户端ID是客户端/服务器的唯一标识；Session ID是客户端和服务器端通信过程中每个调用的标识，可以根据不同的应用场景决定是否使用Session ID。

协议版本该字段长度为8位，用于指示当前使用的协议类型。该域目前固定为0x01。消息类型用于标识不同的消息类型，现有类型如下图所示，其中TP代表分包消息，根据AUTOSAR标准(R21-11)定义如下：消息类型表(来自ADAS和ECU)返回码。

返回代码用于指示消息是否已被成功处理，或者对请求中的错误内容给出反馈。下图是AUTOSAR(R21-11)中定义的返回码类型：返回码定义表(来自ADAS和ECU)有效载荷：数据段，用来放置要传输的数据。03.序列化

AUTOSAR还对一些/IP传输数据的序列化进行了标准化(数据结构转换为线性字节序列，或者相反，如下图所示)，除了支持AUTOSAR指定的基本数据类型(布尔类型，uint8、 uint 16、 uint 32，Sint8、 Sint 16、 Sint 32、 float 32和float64序列化示例(来源AutoSAR)04.SOME/IP通信机制

SOME/IP的通信机制包括远程过程调用、事件和字段。远程过程调用是指一个节点向另一个节点发送请求服务，也称为方法。常用于客户端向服务器发送控制命令，根据服务器是否有反馈分为请求/响应(R/R)和通信FireForget(FF)。事件类似于CAN消息，用于发布状态。根据实际应用场景，可以用不同的方式发送。字段用于表示函数的状态量。

可以发出控制命令，也就是Setter，通过方法；也可以通过方法，即Getter，请求获取状态；您还可以在状态改变时发送通知，即通知。

1.请求/响应(R/R)通信R/R是一种请求和响应的方法，是指客户端发出请求后，服务器需要返回响应消息。请求/响应通信方式(来源知网)2。fire forge (TF)通信客户端向服务器发送请求消息，服务器不会有响应消息反馈。FF通信中的客户端行为与R/R通信中的客户端行为相同，只是在FF通信中，请求消息的消息类型是REQUEST_NO_RETURN，而R/R的消息类型是RESPONS。FireForget沟通模式(来源知网)

3.Event Some/IP中定义了三种不同的事件模式，即周期性发送和值变化触发。

且该和值大于某个阈值。网络中某些/IP的事件传输是基于事件组的。要将事件组分配给每个定义的事件，同一事件可以存在于不同的事件组中，但不能定义空事件组。事件的发送和接收基于一些/IP的发布和订阅行为。在SD通信中，客户端订阅服务器的事件组，在正常的SOME/IP通信中，根据定义的发送行为、周期或值的变化触发事件的发送。事件传播模式(来源知网)4。田

字段表示一个函数的状态，可以用来表示某个状态量，比如门和窗。对于Setter，请求消息的有效载荷包含一个控制命令，用于设置表示状态量的字段；对于Getter，请求消息的有效载荷为空，服务器识别请求消息的消息ID，然后将字段表示的状态量放入响应消息的有效载荷中。

通知是指由字段表示的状态值。当字段表示的状态值发生变化或被外界触发时，会发送通知。

05.SOME/IP SD SOME/IP SD报文是一种特殊的SOME/IP报文，其报文格式与SOME/IP报文相同。不同的是，SOME/IP SD报文的SOME/IP SD头字段的报文ID、接口版本、报文类型、返回码是固定的，SOME/IP SD报文的SOME/IP SD部分还包括flag字段、reserved字段、Entry和Option字段。Some/IP SD消息的格式如下图所示：SOME/IP SD消息(来自AUTOSAR)标志。

Flags的第一个字节为标志字段，其高三位从高到低依次为重启标志位、单播标志位和初始数据控制标志位，低五位为保留位。条目数组服务的发现是通过SD消息的条目数组字段中携带的不同类型的条目来实现的，

条目用于同步服务实例的状态，并处理事件组的发布和订阅。根据条目在SD消息中的不同作用，SD的消息类型分为七种，其中Find消息、Offer消息和Stop Offer消息基于不同的机制周期发送，以同步服务实例的状态；订阅事件组消息，停止订阅事件组消息，订阅ACK消息，订阅NACK消息，处理事件组的发布和订阅。选项数组

SD消息中的条目通过引用选项数组中的选项来携带其他信息，例如配置信息、传输协议、端口号和IP地址。根据Option的功能不同，Option一般分为配置选项、单播IP地址选项、组播IP地址选项和SD通信IP地址选项。选项被配置为传输诸如服务名、协议类型、实例名等信息。IP地址选项分别指示节点单播和组播通信的地址信息和SD通信的地址信息。06.SOME/IP SD通信机制

在SD中，无论客户端还是服务器端，通信行为都分为Down和Available，Available下又分为初始等待阶段、重复阶段和主阶段。在停机阶段，该服务不可用。服务可用后，会立即进入初始等待阶段。这一阶段的首要作用是避免交通突发，防止拥堵；第二，可以将多个条目放入一个SD消息中，以减少消息的数量。

在重放阶段，客户机和服务器通过发送Find和Offer消息来快速同步服务消费关系。在主阶段，标清通信处于稳定状态。为了减少SD消息的数量，定义了客户端不发送Find消息，而服务器以相对较慢的周期发送Offer消息。

对于服务器，初始等待阶段的时间是INITIAL_DELAY_MIN和INITIAL_DELAY_MAX之前的随机值。当计数器超时时，将发送第一个offer消息，并进入重放阶段。此时会定时发送replay _ max offer消息。然后进入主阶段，在主阶段中，将以周期性的时间间隔CYCLIC_OFFER_DELAY周期性地发送Offer消息。如果接收到客户端发送的Find消息，服务器单播响应Offer消息。

服务端的状态跳转图(来源知网) 对于客户端来说，客户端在Down阶段不请求服务。若收到服务器发送的Offer报文，客户端存储该服务实例的状态，并启动该Offer报文的TTL计时器，此时若客户端请求服务，直接进入Main阶段。 在客户端需要请求服务后，进入Initial Wait阶段。

若收到服务器发送的Offer报文，取消计时器，直接进入Main阶段；若没有收到服务器发送的Offer报文，等待INITIAL_DELAY(位于INITIAL_DELAY_MAX和INITIAL_DELAY_MIN之间的随机值)，计时器超时后，发送一个Find报文，进入Repetition阶段。 客户端在Repetition阶段定期快速发送REPETITIONS_MAX次Find报文，若收服务器发送的Offer报文，停止当前阶段的计数和计时，进入Main阶段。

在Main阶段，SD通信已进入相对稳定的状态，这里定义客户端不发送Find报文，以降低SD报文数量。

客户端状态跳转图(来源知网)

黄飞

以上知识分享希望能够帮助到大家！