前言
随着传感器的数量越来越多，数据来源越来越多、规模也会越来越大，那这些多源异构数据如何在芯片之间、在各任务进程之间高效、稳定地传递，确保“在正确的时间，传递正确的数据，并确保数据抵达正确的地点”呢？会有哪些信息在模块之间共享？如何将这些信息发送编码到消息中？如何将消息从一个模块传递到另一个模块？如何在接收到消息后解码？各个模块间的通信分别花了多长时间？在OTA的时候，进程如何不被打断？
这些问题，都需要通过“通信中间件”来解决。
在自动驾驶领域，中间件的功能涉及到通信、模块升级、任务调度、执行管理，但其最主要的功能还是通信。当前市场上，无论是Cyber RT还是 ROS，基本上90%的功能就是通信，狭义上说它们就是通信中间件（又被称为“消息中间件”）。
那么，好的通信中间件应当具备哪些特征？通信中间件可分为哪些类型？常见的SOME/IP和DDS的优劣势各是什么？市场格局将会如何演变？接下来，我们将对这些内容做个简单的梳理。
一．自动驾驶需要怎样的通信中间件？
传统的网络通信中，在TCP协议下，信息发出后，接收方需要发出一个信号，告诉发送方“我收到了” ，如果没收到这个信号，那下一条信息就不能发出；在UDP传输方式下，不管接收方有没有收到，发送方都会一直发。
以往，在没有用通信中间件的时候，为了开发上层应用，开发者们需要自己去定义数据的格式、定义数据的发送方和接收方；但有了SOME/IP和DDS这种“以服务/数据为中心”的发布和订阅模式，开发者们只需明确我需要什么样的数据、数据传到哪儿，而无需知道数据是由谁发出的、怎样发出的。
以数据为中心，是相对于传统的“以消息为中心”而言的，其本质区别在于通信中间件知道它存储了什么数据、并能控制如何共享这些数据。
对传统的以消息为中心的中间件，程序员必须为发送消息编写代码，而对以数据为中心的中间件，程序员只需为如何及何时共享数据编写代码，然后就可以直接共享数据值。
通信中间件包括点到点、消息队列和发布/订阅三种工作模式，SOME/IP和DDS都采用了发布/订阅模式。
点到点模式具有很强的时间和空间耦合性，使得通信灵活性受到很大限制；消息队列模式通过一个消息队列来传递消息，解决了通信双方时间和空间松耦合的问题，但不能实现消息消费者通信的异步，并且还存在服务器瓶颈和单点失效的问题，可靠性得不到保障；发布/订阅模型中，发布者和订阅者通过主题相关联，双方不必知道对方在何处，也不必同时在线，实现了通信双方在时间、空间和数据通信上的多维松耦合。
此外，相比于面向信号的CAN，DDS和SOME/IP都是面向服务的通信协议。两者的区别在于：面向信号的数据传输，不管网络需不需要，它始终会不断循环发送；而面向服务的通信方式则不同，仅当客户端请求或服务器通知特定订阅者时，才在客户端-服务器配置中交换数据，这就确保了永远不会浪费带宽，并且仅在需要的时间和地点进行数据通信/交换。
因此，面向服务的通信协议，能够大大减少网络负载，提高通信效率。
上汽工程师殷玮在一篇文章中说，通信中间件的引入整体上可以帮助开发人员提高工作效率。
SOME/IP和DDS均已被纳入AUTOSAR AP的平台标准中。
创景信息科技公司在官方微信公众号上的一篇文章中说道：“撇开商业利益不谈，从工程角度来看，将AUTOSAR和DDS结合起来的最大优势是功能域和网络拓扑不再是对手，而是车辆中的盟友。网络拓扑结构能够更好地适应车辆的物理约束，而功能域可以在物理车辆的顶部提供了一个灵活的覆盖层。”
通信中间件应该包括以下几个模块:数据类型规范语言、消息传递系统、日志/回放工具和实时分析工具。这些模块应具有如下特征：
1.数据类型规范语言应独立于平台和具体的编程语言，以消除用户实现编组（Marshalling）代码的需要，同时保证运行时类型的安全性；
2.消息传递系统需要在不同的进程之间传输消息，并提供低延时的消息传递功能，且消除对中央通信的依赖，从而使混合模拟、记录和实时数据源的工作更容易；
3.需要提供大量的日志记录、回放和流量检查工具，以简化常见的开发和调试任务。
衡量一款通信中间件好坏的标准主要有如下几点：
1.接口是否方便？接口方便是很多人喜欢用ros的原因。
2.是否安全、稳定？安全，即通信的过程中不能出现数据丢失的问题；稳定，比如，发布订阅的进程连续开几天几夜也不能宕机。
3.传输可支持多少节点、跨多少内核？
4.在不同通信场景和通信需求下，是否可以进行灵活快速的配置？
5.吞吐量、时延。发送同样大小的数据包，吞吐量是否更高，延迟是不是比用别的方法更低？
吞吐量，即单位时间内通过的数据量有多少；时延，即数据包传输的延迟性有多少。如果通信速度很慢，感知到的信息要经过200毫秒才能传递到执行系统，那感知做得再好也无济于事。
车速越高、数据量越大的场景，对中间件的数据吞吐能力和时延的要求就越高。某通信中间件厂商反应，他们的产品在乘用车市场上卖得特别好，但在商用车市场上反响就不行，一个原因就是商用车的驾驶场景简单，对中间件数据吞吐能力、时延的要求比较低。
二．常见的通信中间件
根据源代码是否开放，通信中间件可简单地分为闭源和开源两种。闭源的通信中间件主要有Vector公司的SOME/IP、RTI公司的DDS等;开源的通信中间件主要有OPEN DDS、FAST DDS、Cyclone DDS等。
下面，我们将对这几类通信中间件做个简单的介绍。
01 SOME/IP
SOME/IP的全称为：Scalable service-Oriented MiddlewarE over IP，是一种面向服务的传输协议。严格地说，SOME/IP不是一款特定的产品，而是一种技术标准。其最早由宝马在2012-2013年开发，并在2014年集成进AUTOSAR 4.2.1中。
当前，全球最大的商用SOME/IP产品供应商是Vector。 开源版的SOME/IP则是由Genivi协会来维护的。
02 DDS（Data Distribution Service）
提起DDS，就不得不提OMG组织。OMG是一个国际化的、开放的、非盈利的计算机行业标准协会，很多大家熟悉的标准(如uml)，都出自于OMG。DDS也是OMG组织推出的标准之一。
DDS的全称为Data Distribution Service（数据分发服务)，是由OMG发布的分布式通信规范，采用发布/订阅模型，提供多种QoS服务质量策略，以保障数据实时、高效、灵活地分发，可满足各种分布式实时通信的应用需求。
DDS将分布式网络中传输的数据定义为“主题”，将数据的产生和接收对象分别定义为“发布者”和“订阅者”，从而构成数据的发布/订阅传输模型。各个节点在逻辑上无主从关系，点与点之间都是对等关系，通信方式可以是点对点、点对多、多对多等，在QoS的控制下建立连接，自动发现和配置网络参数。
DDS最早应用于美国海军，用于解决舰船复杂网络环境中大量软件升级的兼容性问题，后来扩展至航空、航天、船舶、国防、金融、通信、汽车等领域，包括作战系统、船舶导航和控制系统、船舶防御系统、无人机驾驶系统和地面控制系统、装甲车辆控制系统、仿真和培训系统、雷达处理和空中交通管理系统、金融系统等。
2018年，DDS首次被引进AUTOSAR AP，作为可选择的通信方式之一。2018年3月，DDS的主要提供者RTI公司宣布，AUTOSAR AP的最新版本（版本18-03）已经具有DDS标准的完整网络绑定。
ROS 2和Cyber RT的底层都使用了开源的DDS，将DDS作为最重要的通信机制。与此相对应的是，Xaver、Orin等面向自动驾驶的SOC芯片上也都预留了DDS接口。
AUTOSAR CP的标准规范中是不支持DDS的，但做一些变通后，也可以在CP上集成DDS。
全球范围内，DDS市场份额最大的供应商（80%左右）的是成立于1991年的美国RTI公司（全称为Real-Time Innovations）。RTI作为OMG组织董事会的成员，主导了DDS标准的制定，从2004年开始负责主持DDS工作组的工作，目前已经成为这个行业的领导者，对DDS标准有足够的权威。
RTI开发的DDS品牌名为Connext,，因此又被称为Connext DDS。
03 开源DDS：FAST DDS与OPEN DDS
开源DDS，主要是相对于商用的RTI Connext DDS等而言的，其也是根据OMG官方标准开发的，但源代码开放。
在自动驾驶领域比较有影响力的开源DDS是由RTI原核心团队成员在欧洲创办的eProsima公司推出的FastDDS。在eProsima将FastDDS的源代码开放出来后，用户可以直接在github上免费下载。但FastDDS使用起来比较麻烦，这个时候，用户就需要通过向eProsima支付费用来取得支持。
OpenDDS 由位于圣路易斯和凤凰城的的Object Computing的 ACE/TAO 团队开发，它和FastDDS具有一定的相似性——两者都是基于RTPS实现的，面向数据的通信框架，遵循的是同一标准。这类框架的典型特征是去中心化，支持QoS机制，支持实时通信。通常会绑定如protobuf等序列化工具。
在许多情况下，FastDDS 、OpenDDS可以跟RTI的Connnext DDS互操作/通信。当然，具体还得看场景。比如开源DDS 的QoS（服务策略）有 23个，大家都用这23个QOS交互，那就能互操作；如果Connext用的是超出这23个自定义范围的QoS，那么开源DDS就解析不了。此外，如果用的是OMG没开源的DDS工具，那也没法互操作。
国内某中间件厂商负责人介绍，出于成本的考量，英伟达的Xavier自带的Driver.OS中便采用了FastDDS或OpenDDS这样的开源DDS。
RTI方面认为，开源DDS是其最大的竞争对手。
当然了，开源DDS的使用门槛也很高。比如，RTI DDS的服务策略有50多个，但开源DDS的服务策略只有23个，完整程度远不及前者。此外RTI的DDS已经通过了ASIL-D的认证，但开源DDS还没有。
而据华玉通软联合创始人毕晓鹏的解释，基于开源版本DDS研发的通信中间件存在“稳定性不足”的问题。
04 MQTT（开源）
MQTT是由IBM开发的即时通讯协议，其全称是Message Queuing Telemetry Transport （消息队列遥测传输）。MQTT协议也采用发布/订阅模式，所有的物联网终端都通过TCP连接到云端，云端通过主题的方式管理各个设备关注的通讯内容，负责将设备与设备之间消息的转发。
由于延时控制等方面功能较差、服务策略也比较少，MQTT不适用于高速项目和大型项目，但可用于低带宽、不可靠的网络场景，提供基于云平台的远程设备的数据传输和监控。在自动驾驶领域，MQTT比较典型的应用场景是V2X。
此外，MQTT在低速车领域也同样适用。它体积极小，并能提供简单的QoS保证，非常适合玩具车，扫地车等功能简单、硬件资源有限的项目。
MQTT也是开源的通信中间件。
三．SOME/IP & DDS
现阶段，SOME/IP和DDS是自动驾驶上用得最多的两类通信中间件。上文已经提到，两者的共同点主要有：都是面向服务的通信协议；都采用了“以数据为中心”的发布和订阅模式。那么，两者的主要区别又有哪些呢？
01 应用场景不同
SOME/IP是专为汽车领域而生的，它针对汽车领域的需求，定义了一套通信标准，并且，在汽车领域深耕的时间比较长；DDS是一个工业级别的强实时的通信标准，它对场景的适应性比较强，但在用于汽车/自动驾驶领域时需要做专门的裁剪。
02 灵活性、可伸缩性不同
相较于SOME/IP，DDS引入了大量的标准内置特性，例如基于内容和时间的过滤、与传输无关的可靠性、持久性、存活性、延迟/截至时间监视、可扩展类型等。当AUTOSAR AP与DDS一起构建一个通信框架时，该框架不仅可以与现有ara::com api及应用程序兼容，而且在可靠性、性能、灵活性和可伸缩性等方面，都可以提供重要的好处。
03 订阅方和发布方是否强耦合
在SOME/IP中，在正常数据传输前，client需要与server建立网络连接并询问server是否提供所需服务，在这个层面上，节点间仍然具有一定耦合性。服务的订阅方需要知道server在哪里，服务的发布方需要告知server提供哪种服务，例如写一个程序，需要用到传感器数据，这个程序要去询问server是否可以提供传感器数据；而在DDS标准下，每个订阅方或发布方只需要在自己的程序里面订阅或发布传感器数据就行了，不需要关心任何连接。可以理解为，在DDS中，服务订阅方和发布方的解耦更加彻底，需要什么数据，写一行代码就行了，不需要再去做绑定。
04 服务策略不同
较好的QoS（服务策略）是DDS标准相比于SOME/IP最重要的特征。
SOME/IP只有一个QoS，即可靠性的定义；而RTI DDS和开源DDS里面分别有50多个和20多个QoS，这些QoS基本上能涵盖绝大多数可以预见到的智能驾驶场景。
QoS具体是个什么东西，它有何用途？华玉通软联合创始人兼技术副总裁毕晓鹏举了几个例子：
（1）通信中的传输优先级、数据可靠性、资源限制、时间过滤等，都需要在QoS里面设置。
（2）数据传输过程中可能会出现丢帧现象，也就是说，不是每一帧都能达到接收端。针对这种现象，我们需要考虑场景需求。如果是关键信息（报警指令），我们需要发送方重发，如果是非关键信息（高频传感数据），系统就不必把丢失的部分都找回来，这些都只需配置QoS的reliability就可以了。
（3）在感知系统有冗余的情况下，一旦一个传感器宕机，就需要第二个传感器补上来。针对这种情况，QoS可以配置一个ownership，对两个传感器的数据做优先级高低的区分。配置之后也不需要重新编译，因为它是动态部署的，配置完之后就可以按照最新配置运行，去完成不同节点之间的发布订阅。
（4）.DDS的解耦模式允许某一主题发布方在没有订阅方的情况下仍然发布数据，但后加入的订阅方也许对这一主题的历史记录感兴趣。例如，新节点上线后需要去监控其他节点的运行情况，这些节点也许每隔较长一段时间才发布一个信息说自己“运行正常”，那么这个新上线的节点就需要去了解其他节点发布的历史信息以确定其运行状态，也就是它希望能收到其上线之前其他节点发布的历史数据。这种情况，只需要简单配置QoS就可以实现，新节点可以获知上线之前多长时间、多长节点的数据流，去关注它的历史数据等等。
（5）负责监控的新节点上线后，需要去监控其他节点的运行情况。通常，这些节点每个小时发布一个信息说自己“运行正常”，但也有可能这个“运行正常”的节点先发布了，过半小时之后监控节点才发布，那这时候，监控节点是否还能收到其上线之前其他节点发布的数据？这种情况，也是需要通过QoS去配置的，QoS可以去配置订阅新节点上线之前多长时间、多长节点的数据流，去关注它的历史数据等等。
进一步说，QoS能够提供实时系统所要求的性能、可预测性和资源可控性，并且能够保证发布/订阅模型的模块性、可量测性和鲁棒性等。因此，DDS能够满足非常复杂、非常灵活的数据流要求。
相比之下，SOME/IP只解决了发布订阅问题，但由于没有这些QoS，结果便是，很多本来可用自动配置服务策略来实现的功能，都需要通过软件开发人员写代码才能实现，这会浪费大量的时间。
此外，由于没有QoS，SOME/IP在数据量大的时候，无法解决丢包的问题，进而造成指令被卡在某个地方发不出去，然后，整个系统就无法正常运作了。
05 应用场景不同
从应用场景的角度来看，SOME/IP比较偏向于车载网络，且只能在基于网络层为IP类型的网络环境中使用，而DDS在传输方式上没有特别的限制，对基于非IP类型的网络，如共享内存、跨核通讯、PCI-e等网络类型都可以支持。而且，DDS也有完备性的车联网解决方案，其独有的DDS Security，DDS Web功能可为用户提供车-云-移动端一站式的解决方案。
在商业落地中，DDS和SOME/IP是直接竞争关系。据一位RIT方面的代表透露,对用户而言，DDS和SOME/IP是“二选一”。
当然，“DDS优于SOME/IP”主要是DDS厂商的说法，为避免本文观点被厂商们的立场左右，笔者又带着这些质疑向Vector蔡守群求证。对此，蔡守群的解答如下——
“现在很多人说DDS优于SOME/IP，很大程度上是从功能丰富性的角度去考虑的。确实，DDS包含的功能是多于SOME/IP的，但仅仅因为这个原因就说DDS优于SOME/IP是不合适的。这就如同拿一部车去跟一个发动机进行对比一样：
SOME/IP是AUTOSAR CP的产物， AUTOSAR的设计原则就是将功能模块化，通过提高模块颗粒度的方式来实现模块的高度可复用性；然后再通过不断复用、不断测试的方式来提高模块的质量，因此，SOME/IP产生之初就没考虑要不断增加功能。比如，跟SOME/IP结合使用的SD就是一个单独的模块。
相比之下，DDS额外提供的QoS，在AUTOSAR CP中是基于VLAN实现在以太网控制器驱动中的；数据则保存在AUTOSAR中有单独的存储管理模块；Security在AUTOSAR中也有对应的通信安全和加密管理模块。
“DDS厂商们认为，相比于SOME/IP，DDS除了提供了一个通信协议之外，还有其他可用的功能。但实际上，这些功能无论在CP还是在AP中，是有其他功能模块进行补充的，可以基于系统需求进行选择部署的，SOME/IP也只是CP/AP中一部分。
“另一方面，DDS丰富的功能必然导致它需要占用更多的资源。在车载MCU领域，资源是一个非常敏感的话题，要在MCU（包括SoC芯片的实时性内核）中运行DDS，只能人为地进行项目级功能裁剪，很难做到跨项目、跨平台的复用，因而很难做到成熟的产品化；并且，开发阶段的工程化裁剪以及后续的测试都会大幅度增加项目成本。
“当然，这也只是我个人看到的当前状况，不知道商业版的DDS是否已经在考虑进行DDS内部的功能模块化、工具可配置化，以弥补这方面的不足。（九章智驾在向RTI代理商创景科技方面求证后得到的反馈是：从我们目前已量产应用的项目来看，有多位客户在多代含MCU的产品中都部署了DDS，DDS在复用性方面并未出现“不成熟”的问题。）
“此外，DDS还有一个问题就是当前还无法完美接入进现有的车载电子电气设计、开发、测试工具链中。虽然说我们已经着手在设计（PREEvision）、测试（CANoe）中去支持DDS，但这方面的工作也才刚刚开始，双方的工具都需要不断测试磨合，短期内是做不到无缝兼容的。
“从协议上看，DDS是一套面向数据的访问系统，适合多节点、大数据交互的应用场景；SOME/IP是一套面向服务的访问系统，可以很方便地用于RPC（远程过程调用）以及变更通知。对于数据吞吐量，从有效数据的占比来看，DDS和SOME/IP的性能没有明显的差别。
“所以，我一直认为DDS和SOME/IP是会并存于车载通信中的，APP可以基于应用场景选择合适的通信通道。这也是为什么在AUTOSAR AP中是既支持DDS又支持SOME/IP的。”
