车内的中间件协议:是面向服务,还是以数据为中心,或是RESTful?
Posted Vector维克多
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了车内的中间件协议:是面向服务,还是以数据为中心,或是RESTful?相关的知识,希望对你有一定的参考价值。
如今,用户希望像自己的移动设备一样,可以根据自己的喜好来调整自己的汽车,扩展它的功能,并对其进行定期更新。实现这些需求的基本技术要素是基于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
结构和系统设计的差异
在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 -
▼ 即将举行的在线研讨会
我知道你在看哟
以上是关于车内的中间件协议:是面向服务,还是以数据为中心,或是RESTful?的主要内容,如果未能解决你的问题,请参考以下文章