0# 前言

面向服务的架构（SOA）在软件设计领域占据着举足轻重的地位，其核心理念在于模块化。模块化不仅提升了软件系统的可维护性和代码重用性，还有助于故障隔离。以自动驾驶系统为例，该系统被细分为数据采集、状态估计和任务规划等多个模块。这些模块在执行各自任务时，需要频繁地进行信息交换。在当今的操作系统环境下，软件进程的独立性使得进程间通信成为一个不可或缺的议题。

0# 通信中间件

在软件定义汽车的时代，应用程序间的跨进程或跨核通信成为了一大挑战。模块化架构虽然为开发人员带来了便利，但同时也催生了通信中间件的需求。过去，开发人员往往需要自行定义数据的格式、发送方和接收方来进行通信。然而，有了通信中间件，如SOME/IP和DDS这样的服务/数据发布和订阅模式，他们只需关注所需数据的类型和传递目标，无需过多关心发送细节。

这种以数据为中心的通信方式，与传统以消息为中心的方式相比，其优势在于中间件能够更好地掌控数据存储和共享方式。在传统的模式下，程序员需要编写发送消息的代码，而在以数据为中心的模式中，他们只需定义数据共享方式，便可直接操作数据值。

此外，通信中间件还提供了点对点、消息队列和发布/订阅等多种工作模式。特别是发布/订阅模式，它允许发布者和订阅者通过主题进行关联，而不必了解彼此的具体位置或同时在线。这种松耦合的特性在时间和空间上为通信双方提供了更大的灵活性。 此外，与传统的面向信号的CAN通信相比，DDS和SOME/IP这类面向服务的通信协议展现出了显著的优势。在面向信号的数据传输中，数据是持续循环发送的，而面向服务的通信方式则更加灵活，它只在客户端有请求或服务器需要通知特定订阅者时，才会在客户端与服务器之间进行数据交换。这种方式不仅确保了带宽的有效利用，更实现了只在必要时刻进行数据通信的目标。因此，采用面向服务的通信协议可以显著减轻网络负担，提升通信效率。

在软件定义汽车的时代背景下，车内的各项功能都被抽象为服务，并通过不同类型的接口向应用程序提供调用能力。这些接口主要包括API接口、文件方式、系统原生服务、IPC接口以及协议栈接口等几种类型。API接口为应用程序提供了调用系统内部功能的接口；文件方式则通过配置文件或设备文件的形式提供了系统的调用能力；系统原生服务则涵盖了操作系统和基础类库提供的各种操作能力；IPC接口则负责处理系统内进程间的通信需求；而协议栈接口则通过网络协议栈为跨平台调用提供了支持。

尽管SOA（面向服务的架构）在互联网领域已经有着悠久的应用历史，但在汽车行业它仍是一个相对新颖的概念。特别是在Adaptive AutoSAR框架中，通信管理模块不仅涵盖了进程间通信的功能，还包括了网络协议栈的支持。鉴于汽车应用场景和通信需求的独特性，许多互联网的SOA技术并不能直接应用于汽车领域。因此，在设计和实现SOA通信中间件系统时，需要针对汽车行业的特殊需求进行定制化的开发工作。 为了确保本地服务和远程服务之间的顺畅通信，应采用统一的接口描述语言（IDL）来定义契约文件。IDL作为一种中立的语言，不受特定操作系统或编程语言的影响，为通信双方提供了共同的沟通基础。

SOA框架的底层核心功能需涵盖服务发现、消息序列化、内部事件/消息处理以及传输功能。这些功能使得应用程序、服务与操作系统之间能够通过标准通信协议或服务接口进行高效交互，尤其满足传感数据的大吞吐量传输需求。此外，框架还需兼容典型的车内通信协议，如SOME/IP协议和DDS规范等。在服务发现方面，应引入访问控制机制，以防范未授权用户的窃听和入侵行为；而传输功能则应支持数据加密和签名技术，从而确保通信过程的安全性。

随着汽车与越来越多基础设施的互联互通成为趋势，未来将面临使用多种通信协议的挑战。为此，我们需要不断更新和优化SOA框架，以适应这一变化并确保通信的稳健与安全。 汽车SOA通信架构

在SOA架构中，HTTP、MQTT、SOME/IP和DDS等协议各自扮演着重要角色，它们在特定场景下承担着不同的职责。例如，SOME/IP专注于车内节点间的服务通信，而HTTP和MQTT则主要负责与互联网模块的通信。尽管这些协议在实现细节上有所不同，但它们可以灵活切换以满足不同的通信需求。

此外，MQTT、DDS、AMQP、REST和CoAP等协议也已得到广泛应用，每种协议都有多种代码实现可供选择。这些协议都声称支持实时的发布/订阅物联网功能。然而，在实际的系统架构设计中，我们必须根据具体场景的通信需求来挑选最合适的协议。各种协议的独特特性如表所示。

0# SOME/IP详解

SOME/IP（Scalable Service-oriented Middleware over IP），这一协议由宝马在2011年精心设计并推出。它采用服务器-客户端的服务通信架构，并展现出卓越的可扩展性。作为一种应用层协议，SOME/IP在TCP/UDP传输协议之上运行（即车载以太网第四层以上），充当中间件的角色，负责实现应用层与IP层之间的数据交互。这种设计使得它不受操作系统的束缚，同时兼容AUTOSAR和非AUTOSAR平台。因此，SOME/IP真正实现了与硬件平台、操作系统和编程语言的独立。

SOME/IP协议架构详解

SOME/IP协议，这一由宝马在2011年推出的创新协议，为汽车行业带来了革命性的变革。其设计精巧，充分满足了车用环境的特殊需求，体现在以下几个方面：首先，它采用基于服务的通信方式，使得数据传输更加高效、占用空间更小；其次，与AUTOSAR的兼容性使得它能够轻松适应各种车辆平台；再者，卓越的可伸缩性使其适用于从小型到大型的各种车辆平台；最后，广泛的兼容性使其能够支持车辆使用的多种操作系统，如AUTOSAR、OSEK、QNX和Linux。

SOME/IP协议不仅支持AUTOSAR CP与AUTOSAR AP之间的通信交互，还与非AUTOSAR平台实现了无缝连接。其设计理念的创新性和技术的先进性得到了业界的高度认可，宝马设计SOME/IP后，它被正式纳入AUTOSAR标准，并随着CP规范的发布而广泛应用于车载以太网中。可以说，SOME/IP协议的广泛使用离不开AUTOSAR CP的推动。

在AUTOSAR架构中，SOME/IP-SD模块扮演着重要的角色。它位于AUTOSAR BSW Mode Manager模块和AUTOSAR Socket Adaptor模块之间，通过配置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（Data Distribution Service）。DDS是由OMG（Object Management Group）发布的分布式通信规范，旨在解决在复杂网络环境中进行大量软件升级时的兼容性问题。该规范最初在美国海军系统中得到应用，并随着ROS2和AUTOSAR的引入，已广泛应用于航空、航天、船舶、国防、金融、通信以及汽车等多个领域。

DDS以其独特的数据中心特性著称，与其他通信中间件迥然不同。在DDS中，数据共享以Topic为基本单元，应用程序能够轻松判断Topic所包含的数据类型，无需依赖其他上下文信息。此外，DDS还支持用户自定义的数据存储、发布和订阅方式，使得应用程序能够如同访问本地数据一样便捷地进行数据读写操作。 全局数据空间（Global Data space） 在DDS中，数据共享被构建为一个抽象的全局数据空间。这意味着，无论应用程序使用何种编程语言或操作系统，它们都能以一致的方式访问这个全局数据空间，如同访问本地存储空间一样便捷。尽管全局数据空间是一个概念性的存在，但在实际系统中，数据仍被存储在各个应用程序的本地空间内。在系统运行过程中，数据会根据需求进行传输和存储。具体而言，数据的发布者仅发送订阅者所需的数据，而订阅者则仅接收并存储本地应用程序当前所需的数据。 服务质量（Quality of Service） DDS不仅提供了灵活多变的QoS策略，还兼顾了数据共享的安全性，如应用程序身份认证、权限控制和数据加密等，从而满足了用户对数据安全性的高要求。

动态发现（Dynamic Discovery） DDS同样支持数据发布者和订阅者的动态发现，类似于SOME/IP-SD的功能。这意味着在运行过程中，通信节点能够自动发现对方并完成相关配置，实现即插即用的便捷性，无需手动配置地址或其他属性信息。

可扩展架构（Scalable Architecture） DDS架构的灵活性使其适用于多种计算环境，包括边缘计算、雾计算和云计算。在边缘计算中，DDS能实现高速设备间通信；在中间系统，它提供稳定的QoS和内容感知的信息流。此外，DDS还提供可扩展的信息访问和数据分发手段，方便集成信息系统并接入云端。

OMG DDS的适用范围广泛，无论是小型设备还是大型云计算系统，都能轻松应对。其超高速数据传输能力、出色的可用性和安全性，以及简化的分布式系统开发方式，使其成为物联网应用的理想选择。

安全（Security）

DDS为工业物联网环境提供了全面的安全保护，涵盖从边缘设备到云端的多个层面。它通过身份验证、访问控制、数据加密和数据完整性等机制，确保数据分发的安全性。这些安全措施在点对点对等架构上得以实现，且不会对实时通信性能造成影响。

目前，DDS已被广泛应用于车载中间件平台。AUTOSAR AP已将DDS标准网络绑定完整集成，而尽管AUTOSAR CP的标准规范不直接支持DDS，但通过一些变通方法仍可在CP上实现DDS的集成。此外，ROS2和CyberRT也采用了开源DDS作为其核心通信机制。针对自动驾驶领域的SOC芯片，如Xavier和Orin，都预装了DDS接口。

值得一提的是，RTI作为OMG组织的重要成员，不仅领导了DDS标准的制定，还推出了名为Connext的DDS品牌，即Connext DDS。然而，开源DDS如Fast DDS和Open DDS也备受关注。Fast DDS由RTI原核心团队成员在欧洲创立的eProsima公司推出，其源代码已在GitHub上免费开放。而Open DDS则由位于圣路易斯和凤凰城的Object Computing的ACE/TAO团队开发，与Fast DDS在技术上具有一定的相似性。这两类开源DDS都遵循OMG官方标准，并提供了去中心化、支持QoS机制和实时通信等特点。 尽管开源DDS对RTI的商用DDS构成了一定的竞争压力，但开源DDS在某些方面仍存在不足。例如，开源DDS的服务策略数量相对较少，仅为23个，与RTI DDS的50多个服务策略相比，其完整性显然不及前者。此外，RTI的DDS已成功通过ASIL-D认证，而开源DDS尚待达到此认证水平。

接下来，我们将对比SOME/IP与DDS这两种在域控中常用的通信中间件。

这两种协议都是面向服务的，采用数据为中心的发布/订阅模式。然而，它们在多个方面存在显著差异。首先，SOME/IP专为汽车领域设计，形成了一套针对汽车需求的通信标准，而在该领域具有深厚的积累。相比之下，DDS作为一个工业级别的强实时通信标准，具有更广泛的适应性，但应用于汽车或自动驾驶领域时可能需要特定裁剪。

其次，在灵活性和可伸缩性方面，DDS引入了诸多标准特性，如内容和时间过滤、传输无关的可靠性、持久性、存活性、延迟/截止时间监视以及可扩展类型等。当AUTOSAR AP与DDS结合构建通信框架时，该框架不仅与现有API和应用程序兼容，还能在可靠性、性能以及灵活性和可伸缩性方面带来显著优势。

再者，从订阅方和发布方的耦合程度来看，SOME/IP要求订阅方在传输数据前与发布方建立网络连接并确认服务可用性，这在一定程度上增加了节点间的耦合性。而DDS标准下，订阅方和发布方仅需在各自程序中订阅或发布传感器数据，无需关心连接细节。因此，DDS实现了服务的订阅方和发布方更彻底的解耦。

最后，关于服务策略的差异，DDS标准相较于SOME/IP提供了更为丰富的QoS选项。RTI DDS和开源DDS分别提供了50多个和20多个QoS策略，这些策略能覆盖大多数可预见的智能驾驶场景需求。 应用场景差异：从应用层面来看，SOME/IP协议因其专为汽车领域设计的特性，主要适用于车载网络，并局限于IP类型的网络环境。相比之下，DDS作为工业级别的强实时通信标准，其应用不受限于传输方式，能够支持包括非IP类型网络如共享内存、跨核通信以及PCIe等在内的多种环境。更进一步的是，DDS还为用户提供了全面的车联网解决方案，通过其独特的DDS Security和DDS Web功能，实现了一站式的“车-云-移动端”服务。 在商业实践中，SOME/IP与DDS确实存在一定程度的竞争，但它们各自在应用范围、灵活性以及服务策略上的不同，使得整车厂能够依据自身需求来挑选合适的通信中间件，甚至可以同时采用这两种技术。这正是AUTOSAR AP能够同时支持SOME/IP和DDS的原因所在。