如今，用户希望像自己的移动设备一样，可以根据自己的喜好来调整自己的汽车，扩展它的功能，并对其进行定期更新。实现这些需求的基本技术要素是基于IP(Internet Protocol)的通信。IP为新的设计模式开辟了道路，因为基于IP可以使用更高层的协议。我们需要对这些更高层的“中间件”协议进行详细检查，它们的定义特性是什么？哪些是可以在汽车环境中考虑使用的？

以太网技术引入汽车工业，不仅大大增加了可用带宽，而且在汽车环境中建立起了基于IP的通信。以太网最初的应用是跟车外交互的诊断，尤其是ECU刷写。传统的动力域、车身域和底盘域继续使用传统总线技术，例如CAN、LIN和FlexRay，并采用基于信号的方式来配置通信。不过，将更多的通信转移到以太网上，充分利用以太网的技术优势是很有意义的。

汽车工业引入了一个新的以太网物理层(“车载以太网”/100BASE-T1)和第一个汽车中间件协议：SOME/IP(Scalable service-Oriented MiddlewarE over IP)。一段时间以来，对来自于IT行业和物联网(IoT)领域的协议的讨论越来越多。这些协议的主要特点是以数据为中心，包括DDS(Data Distribution Service)和MQTT(Message Queuing Telemetry Transport Protocol)。REST(REpresentational State Transfer)也适用于个别的应用场景。然而，REST缺少一个对于工程控制系统很重要的特性：不能以事件触发的方式(on Event)发送数据。如果不支持这种特性，协议就不可能在汽车领域得到广泛的应用，这就是为什么本文不再进一步讨论REST的原因。

本文将对MQTT、DDS和SOME/IP进行概述讨论，比较它们在车内通信的适用性，并尝试回答如下问题：

如何在ECU内实现？

对嵌入式结构有什么影响？

在系统级设计和建模方面有什么影响？

01

起源和通信规范

MQTT于1999年发布，自2013年起由OASIS组织进行管理。MQTT的两个主要版本是3.1.1版(在ISO/IEC标准20922中发布)和后续2019年发布的第5版本。MQTT的主要优点是资源需求低和在不可靠网络中的适用性，这使其在物联网领域很受欢迎。MQTT依赖于一个中央“服务器”(Broker)，它会在发送者(Publisher)和接收者(Subscriber)之间传递信息(Topic)。节点可以在某些主题下发送报文，也可以订阅接收某些主题下的报文。MQTT使用TCP作为传输协议(如图1)。

Figure1:System logic of communication of the MQTT protocol communication with quality of service (QoS)parameters

DDS同样使用发布者-订阅者的模式，并且不需要“服务器”就可以进行交互(如图2)。第一版DDS规范由OMG在2004年发布的，当前最新版本是1.4。在DDS中，通信可以是单播形式也可以是多播形式，这就是为什么TCP和UDP两者都可以作为传输协议。当采用多播形式的时候，UDP比TCP更加高效。和MQTT相比，DDS首要考虑的是动态传输和灵活性，以及在拥有很多节点的系统内的适用性。

Figure2:System logic of communication of the DDS protocol

SOME/IP于2013年发布，是唯一专门为汽车应用开发的协议。在SOME/IP中，服务的提供者和使用者彼此直接关联，没有中央“服务器”。SOME/IP将数据和功能都封装在服务中，Method、Event和Field被用于描述服务接口(如图3)。SOME/IP和DDS一样，采用单播和多播通信，并且通常是基于UDP的。

Figure3:System logic of communication of the SOME/IP protocol

02

通信设计和要素

在基于信号的通信领域，信号是周期性发送，或者事件触发的。远程过程调用(RPC)的本地通信机制或本机动态订阅机制不支持变更通知。如果需要，可以在应用层手动模拟实现变更通知，而SOME/IP与生俱来可以支持此机制。事件触发的数据传输同样也是MQTT和DDS通信的基础。而对于这两种协议，虽然RPC(MQTT Version 5)的必要性也被意识到了，但是它们不能直接支持RPC，而是需要通过转发和返回通道来组合多个主题去实现。

MQTT协议规定了字节数组最大长度为256M字节，有效数据(UTF8编码字符串)的序列化和反序列化可以由发送方和接收方自主处理。DDS提供的数据有详细类型和专用传输协议，然而和MQTT一样，它也会涉及字节数组的序列化。SOME/IP详细定义了数据类型，同时定义了支持的数据类型的序列化。SOME/IP允许基于其4 字节长度字段的数据报文的有效负载高达4GB。

数据或者服务的发布者和订阅者如何找到彼此呢？在动态系统中，这是一个基本问题，尤其是在有多个实例(即有多个数据提供者)的情况下。SOME/IP采用“服务发现”来解决这一问题。“服务发现”是一种在运行时提供服务和订阅通知的机制，在DDS中也存在这种机制。MQTT的实现机制有所不同，因为有中央“服务器”的存在，“服务器”在运行时会管理所有的主题。如需获得所有主题的列表，可以在根级别，通过通配符订阅所有主题。

服务质量(QoS)参数通常被用来比较通信协议的优劣，它们包括数据速率、可靠性和容错性等参数。如果中间件协议并没有涵盖所有的特性，则需要在应用程序中，即更高层面上来实现，其中一些参数也会受到底层传输协议的影响。在MQTT中，唯一指定的QoS参数就是可靠性。用户可以在发布(发送方到“服务器”)和订阅(“服务器”到接收方)三种不同的QoS级别之间进行选择，它们的支持范围从发送后不负责，到包含历史值在内的发送后确认。SOME/IP并没有定义自己的QoS机制，它依赖于应用程序以及TCP和UDP的通信机制。DDS支持广泛的QoS机制，不仅实现了传输的可靠性，还实现了延迟容忍性和容错性，同时还提供了软件看门狗、数据保存和元数据管理等功能，这些功能可以让应用程序节省大量工作。

03

对嵌入式实现的影响

目前绝大多数支持以太网和IP的ECU都是基于AUTOSAR(AUTomotive Open System

ARchitecture)开发的。当考虑DDS、MQTT和SOME/IP的嵌入式实现时，会出现一个问题：怎样才能把它们集成到现有的AUTOSAR解决方案中呢？在既定的软件架构中，解决方案带来的内存使用和处理器负载也很重要。AUTOSAR拥有两个基础平台：经典平台(CP)和自适应平台(AP)。CP是为传统控制系统而设计的，一般使用相对较小的微控制器，配置基本上是静态的，由符合AUTOSAR标准的操作系统控制。整个解决方案是以二进制形式整体编译的，能够满足实时性和较短启动时间的严格要求。然而一般来说，CP使用的微控制器具有非常有限的RAM和ROM资源，特别是和AP系统所使用的微处理器相比较。作为高性能ECU的补充标准，AP被设计为在微处理器上执行，运行在POSIX标准操作系统上。AP系统的内存资源一般是可扩展的，因为它们通常使用外部Flash和RAM芯片。总的来说，在AP中，灵活性得到了很好的体现，这种灵活性主要指后期增加或者更新软件功能。

在CP中，应用层和基础软件通过运行时环境(RTE)连接在一起；在AP中，协议规范的实现是通过ARA:COM接口下的协议绑定。对于SOME/IP，CP和AP都已有实现。然而对于DDS和MQTT，目前的方法是通过集成已有的物联网领域的实现，并将它们适配于AUTOSAR。AP中已经定义如何绑定DDS，所以初步看来，经过适当的工作，将DDS和AP集成在一起是可能的。CP的情况大不一样，支持DDS需要对RTE进行比较大的调整，所以目前还没有这方面的规范计划。另一方面，CP或者AP都还没有支持MQTT的计划(如图4)。此外，所有的协议都需要通过Socket进行通信。这时很重要的一点就是要考虑TCP/IP协议栈的接口，尤其是在CP中，SOME/IP协议头的一部分被直接放在Socket适配器中，这个方法对于DDS和MQTT是不可能的，因为缺乏协议兼容性。

Figure4:the DDS, SOME/IP and MQTT middleware protocols in the layer model and their link to AUTOSAR

在评估这三种中间件协议时，资源需求是很重要的评价指标。由于协议的能力和QoS特性，可以想象DDS对内存的需求比SOME/IP大得多。因此，实现可用于微控制器的DDS，通常其功能范围非常有限。MQTT的资源需求主要取决于实现的是“服务器”还是终端节点。如果是后者，理论上可以非常高效地集成在CP系统中。而MQTT跟SOME/IP内存需求比较的准确结果，则需要通过实现来验证。同样的情况也存在于对协议开销的比较上，DDS的许多特性和传输的元数据使得它成为一个重量级的组件；另一方面，与SOME/IP相比较，MQTT的报头中只有几个字节使其成为一个轻量级协议。

关于数据吞吐量：从单纯的协议分析来看，目前还没有证据表明DDS在性能方面优于SOME/IP。可以肯定的是，MQTT扩展性比较差，在基于“服务器”的实现方式下，需要管理的主题数量的增加会导致延迟量不成比例地增加，这使得在某些应用程序中使用MQTT变得更加困难。

04

结构和系统设计的差异

在功能安全系统设计方面，MQTT最关键的就是它的中央“服务器”，该“服务器”必须在功能安全相关的系统中进行冗余处理，因为它是潜在的单点故障。MQTT第5版在这一方面得到了很好的解决：有一个选项可以指定备用服务器的地址，这样对于功能安全就不存在重大的障碍。与此同时，在数据量大的情况下，MQTT的中央“服务器”还有处理瓶颈，必须对其进行相应的调整。

在DDS的分散布局和SOME/IP通信架构中就不存在这个挑战。如果电子电气架构由不同的合作伙伴来实现，就需要一个标准的交换格式。DDS和SOME/IP得益于被纳入AUTOSAR标准(DDS仅在Adaptive AUTOSAR中)，因此它们可以用标准化的方式来描述。这在MQTT中没有实现，部分原因是在定型和细节深度的引用差异。

05

结论与展望

对于给定的应用程序，这三种协议都有各自的特性和优缺点。SOME/IP清楚地展示了它的起源，同时它是针对汽车应用定制的，可以无缝部署在AUTOSAR中，并且在资源需求和可伸缩性方面表现优异。但是与DDS和MQTT不同，在SOME/IP中没有定义QoS的特性。如果某些应用程序需要这些特性，则必须在应用程序或者传输协议中实现它们。评估DDS时必须考虑其使用目的，由于其广泛的规范和许多不同的特性，DDS非常适合于很多应用程序。然而由于资源有限，量产时总是需要考虑实现更精确的定制版本。

最重要的是，MQTT以其简单性和低资源需求给人留下深刻印象。该协议是为了在不可靠的通信通道上传输少量数据而设计的，它非常适合将少量数据传输到后端。然而目前，如果汽车通信想使用MQTT，还需要解决几个问题，特别是，存在关于中央“服务器”功能安全设计和可伸缩性的问题。对于车内应用程序，未来将会看到DDS是否能够成为与现有SOME/IP竞争的新产品。决定的因素将是功能范围，以及哪个中间件解决方案能为大多数以太网ECU提供最佳的成本效益比。

- END - 

▼ 即将举行的在线研讨会

我知道你在看哟