介绍连接ADAS和IVI主机的可能方法

汽车行业的消费者需求推动了复杂的车载信息娱乐系统（IVI）的发展，这些系统需要完全了解整个车辆及其周围环境。实施这样的高级方案需要在不同的主机环境中实现数据交换，例如高级驾驶辅助系统（ADAS）和IVI。本文分析了在汽车软件开发中使用的面向服务的架构中的不同通信机制，包括域内和跨域的通信。介绍了连接ADAS和IVI主机的可能方法，并从性能和它们支持的用例方面进行了分析。

I.简介

目前，汽车是世界上增长最快的行业之一。随着汽车所提供的功能的发展，电子控制单元（ECU）的数量也在增加，这导致了对更有效和更强大的数据交换机制的需求。此外，随着消费行业需求的不断增长，需要加强车载信息娱乐(IVI)系统，并构建信息娱乐应用程序，以感知更多关于车辆本身的信息。只有通过实现IVI系统与负责收集车辆及其周围信息的ECU之间的通信，才能实现这一目标。

在一般情况下，车辆由许多ECU组成，它们具有不同的架构，运行不同的 *** 作系统（OS），并相应地支持不同的使用情况。这些ECU根据其执行的任务，在语义上被连接到几个领域。车载软件方面的两个主要领域是高级驾驶辅助系统（ADAS）和前面提到的IVI。如前所述，为了建立一个支持高级功能的车辆系统，ECU必须能够交换信息，无论它们是属于同一领域还是不同领域。

本文将对汽车行业中使用的通信通机制进行全面研究。第1、2、3节通过收集和提供汽车以及其他领域各分支的已知事实来处理定性的研究方法。在第4节中，由于缺乏对所调查的例子进行比较的资料，有必要采用定量方法，进行更多的衡量。重点是面向服务的架构（SOA）方法，它与其他机制的比较，以及它在不同使用情况下的采用。在这个分析中，不仅要研究领域内和领域间的通信，而且还要考虑数据背景。

II.汽车行业的SOA原则

汽车中以太网利用率的提高，使得面向服务的架构范式被汽车行业所接受。也就是说，采用面向服务的架构的一个必要条件是设备上存在一个网络堆栈。由于车辆中的大部分组件已经使用以太网进行通信，所以通用网络堆栈已经存在。SOA的优势在于它允许建立可扩展和模块化的应用程序，使用ECU内部和ECU之间的通信机制，以及跨域的信息交换。SOA范式不依赖于 *** 作系统本身，这意味着每个ECU可以有不同的 *** 作系统（如Linux、Android、QNX）。 SOA方法在消费者领域已经很成熟，例如在网络和云服务中，基于超文本传输协议（HTTP）的API通常被用来在系统组件之间交换信息。然而，由于云和汽车应用的性质不同，HTTP不能用于汽车行业，必须创建一个新的协议。可扩展的面向服务的IP中间件（SOME / IP）是一个标准化的汽车解决方案，由两个主要的联盟支持：汽车开放系统架构（AUTOSAR）和互联汽车系统联盟（COVESA），前身是GENIVI。SOME/IP针对汽车领域进行了调整，在数据序列化和流量传输方面提供标准化。COVESA制作了一个通用API栈，将FRANCA框架应用于Linux和安卓平台，这使得它适用于IVI系统。 另一方面，AdapTIve AUTOSAR的ara::com适用于具有ADAS平台的性能主机。这两个堆栈都支持SOME/IP标准，为其互 *** 作性提供了可能。然而，目前还没有标准化的解决方案，支持在这两个堆栈之间进行信息交换。 在SOA架构中，多个客户端可以联系服务器模块，服务器模块以服务的形式向他们提供其功能，如图1所示。

图1 面向服务的中间件架构

III.可能的通信机制

在本节中，我们将分析汽车SOA中常用的通信机制，特别是在数据背景和数据交换的目的方面。根据需要传输的数据类型或其目的，可以使用不同的方法，如图2和表1所描述的。详细情况将在下文中讨论。

A. 共享内存

在两个域之间进行通信的情况下，使用共享内存很少适用。对于域间数据交换，这种方法只适用于两个域都位于一个多核ECU内的情况。由于具有不同安全完整性级别的域可以访问相同的内存空间，因此这种情况会遇到安全问题。有一种假设是，它可以通过使用管理程序来处理，但目前没有考虑。

对于域内通信，共享内存可用于交换常规数据，它不适用于从传感器收集数值并向执行器发送命令的情况。

图2 汽车领域的通信方式

表I 通信方式的比较

B. SSOME/IP和以太网

如前所述，SOME/IP依赖于TCP和UDP协议。它主要负责基于SOA的通信的序列化和反序列化。基于UDP的通信被推荐用于较小的数据量，而TCP更适合较大的数据量。SOME/IP是通信机制的代表，它易于扩展，因此最适合在汽车中建立SOA应用，它适用于域内和域间通信。也就是说，自适应AUTOSAR和COVESA对SOA的支持允许使用该特定平台的接口定义语言（IDL），生成和描述基于SOME/IP的通信中间件。这简化了开发，加快了在系统环境中整合算法的过程。然而，正如已经提到的，在不同的汽车领域之间没有标准化的通信方法，因此没有IDL或工具可以为这种目的提供自动中间件代码生成。

在汽车通信和软件建模标准中，数据是通过SOME/IP使用消息字段、方法和事件来交换的。AUTOSAR中的字段（或FRANCA中的属性）是由服务存储的值，可由服务器和客户端访问。客户端可以通过读取和/或设置字段值与服务器互动。订阅的客户可以得到关于字段修改的通知。当需要在服务端执行某个功能时，客户端使用这些方法。它允许客户端发送一些控制参数、请求更改或添加一些不是服务属性的数据。方法可以是可回应的，也可以实现为不响应的“清除并忽略”请求。AUTOSAR中的事件（或FRANCA中的推送）是用来通知感兴趣的客户关于服务方事件的机制。客户端可以订阅推送，从而接收有关信息。可以在服务端进行选择性发送，以便只通知选定的客户。

另外，在SOME/IP可以使用的场景方面也有一些限制。由于以太网提供的可靠性不足，在需要具有确定性命令执行的情况下，不适合向执行器发送数据。此外，它的利用对收集传感器的数据没有好处。传感器数据是在网络堆栈的较低层传输的，即使用原始以太网。此外，SOME/IP提供了传输一系列数据的能力，这些数据可以代表图像或视频内容（一系列图像），但在需要通过IP传输视频流的情况下，使用一些现有协议（如RTSP）更为方便。现有流媒体协议的优势在于对各种格式的内置支持以及在应用层面的现有支持。基于SOME/IP的SOA适用于流媒体管理，即控制流媒体的开始和停止、摄像机选择、视频格式选择等。

C. 其他车载通信机制

有几种通信机制对汽车使用情况很重要，如控制器区域网络（CAN）、本地互联网络（LIN）和FlexRay等。由于这种车载网络机制被认为是面向信号的架构的代表，而不是面向服务的架构，因此将不对其进行更详细的研究。但值得一提的是，本文还分析了数据环境，以太网在与执行器通信时，由于可靠性不足或价格昂贵，无法与车载网络相抗衡。CAN和FlexRay用于连接对确定性和可靠性要求最高的动力系统部件，如发动机、变速器和刹车，以及低成本的LIN，用于控制没有严格时间要求的电动设备，如座椅、窗户和门。

IV.方法比较

在前面的章节中已经描述了一些用于汽车系统组件之间通信的最常用机制。虽然面向信号的车内网络提供了确定性和低延迟性，但它们不容易扩展，也不适合用于连接SOA组件。这使我们有可能需要在共享内存方法和SOME/IP通信之间进行选择，这取决于应用程序是否需要在不同领域之间交换数据。

速度是共享内存的主要优势，这可以从表二提供的实验结果中看出。分析是根据同一设备内两个不同的应用程序之间交换的两种大小的数据来进行的，所以SOA和共享内存都适用。第一种情况(8字节)表示车辆在两个应用程序之间的传输状态。第二种情况(843千字节)是将从相机获得的帧传输到处理应用程序。

在第二种情况下，由于需要更大的数据量，对于共享内存的访问，需要使用一个字节来指示对内存的写入是否完成来实现同步。在两种数据大小上都进行了1000次测量，平均值在表中列出。很明显，共享内存方法的性能明显高于SOME/IP的性能。然而，这种机制没有那么灵活，因为它很少适用于域内的数据交换，并可能在安全方面造成问题，因为多个应用程序组件可以访问、修改一个内存位置的数据，并因此破坏数据。

表II 数据读取性能

共享内存方法的另一个缺点是缺乏一种机制来通知使用特定数据点的应用程序数据发生了变化。解决方案是使用轮询，定期检查应用组件使用的数据是否可用或被修改。这样的方法增加了应用逻辑的复杂性，影响了系统的整体性能。 与SOME/IP相比，SOA的额外好处是它可以用于异构平台之间的域间通信，例如在一方是带有AUTOSAR的ADAS系统，另一方是带有Android *** 作系统的IVI。由于可以为安卓建立COVESA的通用API，所以解决方案可以是SOME/IP。 建议在UDP上使用SOME/IP而不是TCP。应用层的交付是有保证的，但在事件的情况下则不能。

为了在OSI模型的第四层实现交付确认，事件通过TCP发送。下一个衡量的目的是检查速度方面的缺点，使用TCP而不是UDP，这带来了额外的可靠性，。在使用SOME/IP时需要考虑的一个有趣的问题是，大多数IVI系统是基于Linux内核的，在这种情况下，TCP连接有可能比UDP快。这可能会导致意想不到的行为，即通过UDP的通信时间比通过TCP的通信时间长。表三的测量结果显示，如果使用TCP，通过SOME/IP的方法调用的平均时间会更快，而且通过SOME/IP的SOA并不会因为带有可靠性TCP而降低速度。

表IIISOME/IP方法的调用性能

V.总结

本文提供了对汽车数据交换的不同方法的分析。通过数据传输的类型和背景，以及对域内和域间通信的适用性来比较各种方法，重点是ADAS和IVI的跨域连接。事实证明，面向服务的架构机制是最适合这种跨域结合的方法。他们的优点、缺点以及与其他方法的比较都一一做了介绍、评估和讨论。

未来的工作应该是在Android平台上实现SOA范式，因为Android被越来越多地用作IVI系统的解决方案。

 

审核编辑：刘清