如今，用户希望将他们的汽车根据个人偏好进行定制，通过添加功能并定期进行更新，就像他们对待移动设备一样。实现这些期望属性的一个构建模块是基于 Internet Protocol（IP）的通信；IP为新的设计模式打开了大门，因为它使得使用更高层协议成为可能。这些“中间件”协议应该被更详细地考虑。它们的定义特点是什么？哪些协议可以在汽车环境中使用？

将以太网引入汽车行业不仅大幅增加了可用带宽，还在汽车环境中建立了基于IP的通信。最初的应用主要集中在离车诊断，特别是闪存过程。传统领域如动力总成、车身和底盘继续使用控制器局域网（CAN）、本地互连子总线网络（LIN）和FlexRay等总线技术，并采用基于信号的、静态配置的通信方法。然而，将更多的通信转移到以太网技术，并广泛利用其优势，是合理的做法。

为此，汽车行业引入了一种新的物理层（"汽车以太网"或100BASE-T1）和第一个汽车中间件协议：SOME/IP（基于IP的可扩展面向服务的中间件）。一段时间以来，人们还对来自IT界和物联网（IoT）领域的协议进行了更多讨论。它们的主要特点是以数据为中心的方法。最感兴趣的协议是DDS（数据分发服务）和MQTT（消息队列遥测传输协议）。在某些个别应用中，REST（表征状态转移）也适用作为一种技术。它实现了用户交互中相关的拉取方法。然而，REST缺乏一项对于工程控制系统非常重要的特性：它无法以事件触发的方式发送数据（On Event）。在没有这种推送方法的情况下，该协议在车辆中的广泛使用不太可能。因此，在这里不再深入探讨REST。

本文提供了MQTT、DDS和SOME/IP的概述，并比较了这些协议在车辆通信方面的适用性。它们如何在电子控制单元（ECU）中实现，以及这对嵌入式架构有何影响？在系统级别上进行设计和建模时有哪些后果？

起源和通信范式

MQTT协议于1999年发布，并自2013年起由结构化信息标准促进组织（OASIS）管理。MQTT的两个主要版本是3.1.1版（ISO/IEC标准20922发布）和随后于2019年发布的版本5。MQTT的主要优点是其对资源的低要求以及在不可靠网络中的适用性，这使其在物联网领域广受欢迎。
在这里，MQTT依赖于一个中央的“代理”（服务器），它在发送者（发布者）和接收者（订阅者）之间传递信息（主题）。节点可以在特定主题下发布消息并订阅接收特定主题的消息。在这里，使用TCP作为传输协议（图1）。

DDS也使用了发布-订阅模式，但是没有中央代理（图2）。DDS的第一个版本于2004年由OMG（对象管理组）发布，现在可用的版本是1.4版。在DDS中，通信可以是单播或组播，这就是为什么同时使用TCP和UDP作为传输协议的原因。当使用组播时，UDP比TCP更能实现高效的通信。与MQTT相比，DDS的主要考虑因素是传输动态性和灵活性，以及其对具有大量节点的系统的可扩展性。

SOME/IP是专门为汽车使用而开发的唯一协议，于2013年发布。在这里，服务的提供者和消费者直接相互关联，没有中央代理。数据和功能根据面向服务的通信范式封装为服务。在服务接口的描述中使用方法、事件和字段（图3）。SOME/IP与DDS类似，利用单播和组播通信，并通常基于UDP。

通信设计和要素

在基于信号的通信世界中，信号周期性地发送或基于事件触发。没有原生的远程过程调用（RPC）通信模式或用于通知更改的原生动态订阅机制的计划。如果需要，它们在应用程序层面上会被手动模拟。SOME/IP固有地处理了这些范式。基于事件触发的数据传输也是与MQTT和DDS通信的基础。对于这两种协议，也意识到了RPC的必要性（MQTT版本5）。然而，它们并不直接支持，而是通过将多个主题组合为前向和返回通道来实现。
MQTT协议仅规定了最大长度为256兆字节的字节数组。有用数据（UTF8编码的字符串）的序列化和反序列化由发送方和接收方自主处理。另一方面，DDS提供了对数据的详细类型化和专用的传输协议。然而，与MQTT类似，它也涉及字节数组的序列化。在SOME/IP中，数据也被详细地进行了类型化。支持的数据类型的序列化在标准中定义。基于其4字节长度字段，SOME/IP允许具有最多4千兆字节负载的数据消息。

数据或服务的发布者和订阅者如何找到彼此？这是动态系统中的一个基本问题，尤其是在存在多个实例（即多个数据提供者）的情况下。SOME/IP的答案是所谓的“服务发现”，这是一种在运行时提供服务并可以订阅通知的机制。这种机制也存在于DDS中。另一方面，在MQTT中，由于存在中央代理（broker），实现方式不同。代理在运行时管理所有主题。要获取所有主题的列表，可以简单地通过在根级别使用通配符订阅所有主题。

通常使用服务质量（Quality-of-Service，QoS）参数来比较通信协议。这些参数包括数据传输速率、可靠性和容错性等。中间件协议并不涵盖所有特性，有些特性可能需要在应用程序的上一层进行实现。其中一些因素也会受到底层传输协议的影响。在MQTT中，唯一指定的QoS参数是可靠性。用户可以在发布（发送方到代理）和订阅（代理到接收方）之间选择三个不同的QoS级别。它们的范围从“发出并忘记”到包括历史值的交付确认不等。SOME/IP不定义自己的QoS机制，它依赖于应用程序和TCP、UDP的机制来实现。另一方面，DDS支持广泛的QoS机制。不仅实现了传输可靠性，还包括延迟和容错性。还提供了诸如软件看门狗、数据保存和元数据管理等功能，这可以在应用程序层面上节省很多工作量。

对嵌入式实现的影响

绝大多数今天具备以太网和因此支持IP的电子控制单元（ECU）都基于“AUTOSAR”（汽车开放系统架构）。在考虑将DDS、MQTT和SOME/IP嵌入到现有AUTOSAR解决方案中时，一个问题就出现了：它们能够多好地集成到现有AUTOSAR解决方案中？内存使用和处理器负载对于给定体系结构中的解决方案同样重要。AUTOSAR区分两个基本平台：经典平台（Classic Platform，CP）和自适应平台（Adaptive Platform，AP）。CP是为基于相对较小微控制器的传统控制系统设计的。配置在很大程度上是静态的，由OSEK操作系统控制。整个解决方案以单一二进制文件进行编译。它仍能够满足对实时能力和快速启动时间的严格要求。然而，通常情况下，这里使用的半导体芯片的RAM和ROM资源非常有限，特别是与AP系统中典型的半导体芯片进行直接比较时。作为高性能ECU的补充标准，AP设计为在基于POSIX的操作系统下在微处理器和应用核心上执行。AP所使用的典型半导体的资源也是可扩展的，因为它们通常使用外部闪存和RAM芯片进行操作。总体而言，AP在规定上更加注重灵活性：这种灵活性主要指的是后续添加的软件和更新能力。

在CP中，应用程序层通过运行时环境（“RTE”）与基本软件进行接口。在AP中，协议规范通过ARA:COM接口下面的协议绑定实现。对于SOME/IP，CP和AP都使用本地实现。但是，如果要使用AUTOSAR运行时环境进行DDS和MQTT应用程序，则今天通常的方法是访问现有的IoT实现并将其适应为AUTOSAR。在AP中已经定义了与DDS的绑定。因此，初步看来，AP的集成将是可能的，但需要适当的努力。但是对于CP来说情况并非如此，需要对RTE进行适配。另一方面，目前还没有计划将MQTT用于CP或AP（图4）。此外，所有协议都需要一种通过套接字进行通信的方式。在这里，重要的是考虑与TCP/IP堆栈的接口，特别是在CP中。SOME/IP直接放置在套接字适配器上，这也构成了SOME/IP协议头的一部分。在DDS和MQTT中，由于缺乏协议兼容性，这种方法是不可能的。原则上，在CP中可以在套接字适配器上放置没有PDU头选项或直接放置在TCP/IP上。

在评估三种中间件协议时，它们的资源需求也是有趣的。可以想象DDS由于协议的范围和其QoS功能，将对内存需求产生比SOME/IP更大的需求。因此，针对微控制器的DDS实现在其功能范围上通常非常有限。MQTT的资源需求主要取决于是否实现代理或终端节点。后者可以非常高效地集成到CP系统中。在将MQTT内存需求与SOME/IP进行比较时，仍需在未来的实现中进行验证。在考虑协议开销时也存在类似的情况。其许多功能和传输的元数据使DDS成为一个重量级协议。另一方面，MQTT仅有几个字节的头部，与SOME/IP相比是一个轻量级协议。

就数据吞吐量而言，在纯协议分析中，目前没有证据表明DDS在性能方面优于SOME/IP。但可以确定的是，MQTT的可扩展性较差。根据 broker 的实现方式，延迟会与需要管理的主题数量不成比例地增加。这使得在某些应用程序中使用MQTT更加困难。

在体系结构和系统设计上的差异

MQTT的中央代理在功能安全系统设计方面至关重要。在安全相关的系统中，这个代理必须实现冗余，因为它是潜在的单点故障。MQTT 5版本完全解决了这一问题：它提供了指定备用服务器地址的选项。在功能安全方面没有根本性障碍。与此同时，在大数据量的情况下，MQTT的中央代理成为瓶颈，必须进行相应的规模调整。
而在DDS和SOME/IP通信架构的分散布局中，不存在这个挑战。如果由不同的合作伙伴实施广泛的电气/电子架构，则需要一个标准化的交换格式。DDS和SOME/IP在这里受益于被纳入AUTOSAR标准（DDS仅在AUTOSAR Adaptive中），因此可以以标准化的方式进行描述。而这在MQTT中并没有实现，部分原因是由于所引用的类型和详细程度的差异。。

结论与展望

这三种协议对于特定应用具有特定的属性、优点和缺点。SOME/IP清晰地反映了它在汽车应用中的起源和定制。它可以在AUTOSAR中无缝集成，并在资源需求和可扩展性方面表现出色。然而，与DDS和MQTT不同，SOME/IP中没有定义QoS功能。如果某些应用需要这些功能，必须在应用程序或传输协议中实现。评估DDS时必须考虑使用目的。由于其广泛的规范和许多不同的功能，DDS的适合性非常广。然而，由于资源有限，生产使用始终需要更精确定制的版本。

最重要的是，MQTT以其简单性和低资源需求给人留下了深刻的印象。该协议设计用于在不可靠的通信通道上传输少量数据，并且非常适合将少量数据传输到后端。然而，目前在车辆通信中使用它仍有一些问题需要回答。特别是关于中央代理的功能安全设计和可伸缩性的问题。对于车辆应用程序来说，未来将展示DDS是否能够作为一种汽车新秀与已经建立起来的SOME/IP竞争。决定性因素将是考虑到的功能范围，以及哪种中间件解决方案为大多数以太网ECU提供了最佳的成本效益比。

本文主要翻译下面的文章：

https://cdn.vector.com/cms/content/know-how/_technical-articles/PREEvision/PREEvision_MiddlewareProtocols_ElektronikAutomotive_202003_PressArticle_EN.pdf

如对文章感兴趣，可以关注公众号：