SOA通信中间件及其协议介绍

作者：姜鸿雷

[本文选自《智能汽车：新一代技术与应用》.姜鸿雷.电子工业出版社——书中第八章部分内容]

前言

SOA（面向服务的架构）的软件设计原则之一是模块化。模块化可以提高软件系统的可维护性和代码重用性，并且能够隔离故障。举例来说，自动驾驶系统可以分解为特定的任务模块，如数据采集、状态估计和任务规划等。为了完成各自的任务，这些模块需要相互交换信息。在现代操作系统中，将单个模块映射到独立的软件进程非常方便，这些进程可以位于同一计算设备上，也可以位于物理上独立的计算设备上。这使得进程间通信成为一个深入研究的问题，因为信息交换是通过进程间的通信来实现的。

一. 通信中间件

在软件定义汽车中，应用程序之间的跨进程或跨核通信是一个需要解决的问题。模块化架构为开发人员提供了便利，但也引入了对通信中间件的需求。

在没有使用通信中间件的情况下，开发人员需要自己定义数据的格式、发送方和接收方。然而，使用基于服务/数据的发布和订阅模式（如SOME/IP和DDS），开发人员只需要明确需要什么样的数据以及数据应该传递到哪里，而无需关注数据的发送方和发送方式。

以数据为中心是相对于传统的以消息为中心而言的，其本质区别在于通信中间件知道存储了什么数据并能够控制如何共享这些数据。对于传统的以消息为中心的中间件，程序员必须为发送消息编写代码，而对于以数据为中心的中间件，程序员只需为如何共享数据编写代码，然后可以直接共享数据值。

通信中间件可以采用点对点、消息队列和发布/订阅三种工作模式，SOME/IP和DDS都采用了发布/订阅模式。

在发布/订阅模型中，发布者和订阅者通过主题进行关联，双方不需要知道对方在何处，也不需要同时在线。这实现了通信双方在时间、空间和数据通信上的多维松耦合。

此外，与面向信号的CAN相比，DDS和SOME/IP都是面向服务的通信协议。两者的区别在于面向信号的数据传输始终循环发送，而面向服务的通信方式不同，只有在客户端请求或服务器通知特定订阅者时，才在客户端-服务器配置中交换数据。这确保了永远不会浪费带宽，并且仅在需要的时间和地点进行数据通信/交换。因此，面向服务的通信协议可以大大减少网络负载，提高通信效率。

在软件定义汽车时代，车内的所有可调用功能都被视为服务，并提供不同类型的调用接口，这些接口可以按以下方式分类：

1、API接口：提供各类函数的调用接口，使应用程序能够调用系统内部的功能实现函数。应用程序可以通过调用相关的API接口来提供和使用功能服务。

2、文件方式：以配置文件或设备文件的形式提供系统内部的调用能力。这些文件可以通过配置自动生成，包含有效的配置信息，并且可以在运行环境中被特定的程序读取和识别，实现特定的服务。

3、系统原生服务：操作系统和基础类库提供的可操作能力，包括对系统CPU和内存的监测、应用程序的监控、系统资源的划分等。此外，还可以调用C++、boost等基础类库。

4、IPC接口：各种IPC机制提供系统内进程间的调用能力，包括使用套接字（socket）、共享内存等进程间通信方式，以及使用特定的跨核通信方式如IPCF。

5、协议栈接口：通过网络协议栈提供跨平台的调用能力，包括SOME/IP、DDS、MQTT、HTTP等网络协议的调度服务、接口封装和协议转换等。

尽管在互联网领域中SOA（面向服务的架构）已经被应用了很长时间，但在汽车行业中，它算是相对较新的概念。在Adaptive AutoSAR框架中，通信管理模块包括进程间通信和网络协议栈。

鉴于汽车应用场景和通信需求的特殊性，许多互联网的SOA技术并不能直接应用于汽车领域。一般来说，SOA通信中间件系统的各个层面需要满足以下要求：

1、本地服务和远程服务之间的通信应该使用统一的接口描述语言（IDL）定义的文件作为契约。IDL是一种中立的接口描述语言，与具体的操作系统和编程语言无关。

2、SOA框架的底层核心功能应具备以下特点：服务发现、消息序列化、内部事件/消息处理和传输功能。应用程序、服务和操作系统之间可以通过标准的通信协议或服务接口相互通信或访问，特别是要满足传感数据的大数据吞吐传输需求。必须支持典型的车内通信协议，如SOME/IP协议、DDS规范等。服务发现功能应具备访问控制功能，以防止未经授权的用户进行窃听和侵入；传输功能应具备数据加密和签名等功能，以确保通信数据的安全性。

在未来，汽车将与更多的基础设施进行连接，为了实现与它们的连接，将需要使用不同的通信协议。

汽车SOA 通信架构

HTTP、MQTT、SOME/IP和DDS等协议都用于实现SOA架构中的通信，只是在不同的场景下承担不同的责任。例如，SOME/IP协议用于车内节点之间的服务通信，而HTTP和MQTT用于与互联网模块进行通信。尽管它们在实现机制上有些许差异，但它们可以相互切换使用。

MQTT、DDS、AMQP、REST和CoAP等协议都已被广泛应用，并且每种协议都至少有10种不同的代码实现。它们都宣称支持实时的发布/订阅物联网协议。然而，在具体的系统架构设计中，需要考虑实际场景中的通信需求，并选择适合的协议。各种协议的特点如表所示。

二、SOME/IP 介绍

2011年，宝马设计并提出了SOME/IP（Scalable Service-oriented Middleware over IP）协议。SOME/IP采用服务器-客户端的服务通信模式，并且具备高度可扩展性。SOME/IP协议是一种应用层协议，运行在TCP/UDP传输协议之上（车载以太网第四层以上）。它作为以太网通信的中间件，实现应用层与IP层之间的数据交互，使其不依赖于操作系统，并且兼容AUTOSAR和非AUTOSAR平台。因此，SOME/IP可以独立于硬件平台、操作系统和编程语言。

SOME/IP 协议架构

SOME/IP具备满足车用需求的特性，主要包括以下几个方面：基于服务的通信方式，占用空间小，与AUTOSAR兼容（其他中间件不具备兼容性），可伸缩性（适用于小型和大型平台），以及兼容性（可适用于车辆使用的各种操作系统，如AUTOSAR、OSEK、QNX和Linux）。

SOME/IP支持AUTOSAR CP、AUTOSAR AP以及非AUTOSAR平台之间的通信交互。宝马设计SOME/IP协议后，它被AUTOSAR纳入正式标准，并随着CP规范的发布而被广泛应用于车载以太网，因此可以说是AUTOSAR CP推动了SOME/IP的广泛使用。

在AUTOSAR架构中，SOME/IP-SD模块位于AUTOSAR BSW Mode Manager模块（BswM）和AUTOSAR Socket Adaptor模块（SoAd）之间。BswM模块提供了通用模式请求和服务请求之间的连接，而SoAd模块处理以太网堆栈和SD模块之间的服务请求。通过配置SoAd中的Socket Connection表，可以接收其他ECU的SD模块发送的单播和多播报文。

借助SOME/IP协议的高度平台扩展性，可以实现不同平台之间的数据交互，而统一的SOME/IP通信机制是不同平台通信的前提。为了在不同软件平台上运行SOME/IP，实现整车以太网上的SOA架构通信机制，AP规范中也同步引入了SOME/IP，因此在AUTOSAR系统中，CP和AP之间实现SOME/IP通信相对容易。

为了促进非AUTOSAR软件平台与车内CP和APECU之间的交互，GENIVI系统同样开发了一套开源的vSOME/IP软件源码，以便与CP/AP进行交互。然而，由于vSOME/IP是开源的，性能可能略有差异，因此需要统一的规范进行约束，以进行深度的二次开发。目前，全球最大的商用SOME/IP产品供应商是Vector，而开源版的vSOME/IP由GENIVI协会维护。

三、DDS 介绍

DDS（Data Distribution Service）是由OMG（Object Management Group）发布的分布式通信规范。OMG成立于1989年，是一个国际性、开放性、非营利性的技术标准联盟，由供应商、终端用户、学术机构和政府机构推动。OMG工作组致力于制定企业集成标准和开发可为数千个垂直行业提供现实价值的技术标准，其中包括统一建模语言SYSML、UML，以及中间件标准CORBA、DDS等。

DDS最早应用于美国海军系统，用于解决在军舰系统复杂网络环境中进行大量软件升级时的兼容性问题。随着DDS被ROS2和AUTOSAR引入，目前它已经广泛应用于航空、航天、船舶、国防、金融、通信、汽车等领域。

DDS的特点：

1、数据中心（Data Centricity）