智能网联汽车多源信息集成平台技术研究

朱赛春，陈效华，刘华仁，纪明君

（北汽集团新技术研究院，北京 101300）

随着汽车技术从机械化到“三电化”的发展，以智能化、网联化为重要特征的驾驶自动化系统（Driving Automation System）的开发毫无疑问地成为汽车产业发展的重要方向。产品开发要适应市场的需要，产品需求要符合用户需求特征。从计算机行业的大型机到个人计算机再到消费电子的发展历程来看，智能网联汽车以消费电子和共享服务为特征的功能需求多样化和用户体验个性化将成为整车厂产品研发的关注点。

引用格式：

另一方面，自动驾驶的主动安全系统，感知和监视车辆内外状态环境，识别周边事物及对车辆、占有物和道路使用者的潜在危险，通过驾驶员告警、车辆系统调整、车辆子系统主动控制等手段，自动介入而帮助避免或减轻碰撞。其中，通过对目标和事件的感知、识别、分类和预判来监视驾驶环境，并对目标和事件进行反应与执行，均需要将大量的传感器集成在汽车电子电器系统上，大量的单片机及电子控制单元（Electronic Control Unit，ECU）等复杂设备都迫切需要智能互联，以满足人机界面（Human Machine Interface，HMI）、机对机界面（Machine to Machine Interface，MMI）操作的便利性、复杂性以及驾驶员、零部件之间信息传达的智能性设计要求。

汽车研发将以系统研发的平台化技术、零部件快速集成与验证技术为支撑点，以快速迭代的生产模式为方向进行变革。而平台开发的中间件技术以及基础软件设计规范及接口的定义，将成为各整车厂引领本次变革的制高点和必须掌握的核心技术。

1 系统设计目标与要求

平台中间件的设计与开发须达成4个目标：（1）支持零部件灵活部署。（2）支持零部件快速集成。（3）支持产品早期验证[1]。（4）支持快速迭代的生产模型[2]。根据HMI架构平台设计目标，平台中间件的设计要达到8个目标：（1）支持HMI架构上显示与功能逻辑的分离。（2）形成企业标准的车载应用逻辑开放接口规范（Pro fi le）。（3）灵活配置HMI功能。（4）快速切换HMI风格。（5）支持迭代开发，缩短HMI功能开发周期[3]。（6）缩短HMI与Tier1&2集成开发时间，整车开发周期由通常两年半降低为一年半。（7）减少信息源部署的物理制约，支持TBox及多传感器信息源与头单元（Head Unit，HU）的快速集成。（8）减少显示屏幕部署的物理制约，支持仪表、中控屏、副驾屏、前视镜、后视镜及后排娱乐屏快速开发。智能网联汽车电子电器系统构成如图1所示，其中红色标记部分平台中间件在整车系统集成中占有核心位置[4]。

图1 智能网联汽车电子电器系统构成概念图

基于以太网总线的智能网联系统零部件部署拓扑结构如图2所示。

图2 零部件部署拓扑图

2 设计方案

为了便于设备执行机构与外界的交互，HMI及模块间的交互语言一般采用解释性的高级语言。交互语言为解释性语言的设备被称为智能化设备（Smart Device）。从概念上讲，图3中的设备智能化模型应包括脚本语言、解释引擎和执行机构三部分。其中红色部分的解释引擎和下面黑色部分的执行机构的接口为平台中间件开发范围，蓝色箭头为数据流走向。

图 3 设备智能化模型

对原始嵌入式系统设备的智能化，至少要满足以下几方面要求：

（1）系统的安全性。对原生系统的安全性影响最小。汽车ECU等原生系统对安全性要求很高，不能因为虚拟化后的外围设备功能逻辑程序执行的崩溃而影响原生系统的工作。

（2）交互的便利性。采用解释性高级语言对被虚拟化的外围设备编程进行交互，以满足对目标设备操作的功能逻辑不断变化的要求。

（3）部署的自适性。智能HMI与原生嵌入式系统能有灵活的连接和部署。

（4）HMI操作的实时性。对操作实时性的要求，根据用户体验及应用模块之间调用的时间要求，应有适当的指标[5]。如果要求在几十ms级别，在设计上能有更多的方案可供选择。兼顾综合考虑系统的实时性和可用性，智能网联汽车应用系统架构设计采用实时性相对进程间通信（Inter Process Communication，IPC）和远程进程调用（Remote Process Call，RPC）较低的远程方法调用（Remote Method Invoke，RMI）。由图4的进程间通信抽象度模型（IPC Paradigms）的蓝色箭头指向可知，越往顶层抽象度越高，可用性越好；越往底层抽象度越低，但实时性较高[6]。

图4 进程间通信模型

2.1 Web方案

智能网联汽车应用系统的嵌入式设备智能化Web方案如图5所示。执行设备使用图5中红色部分的Web通用网关接口（Common Gateway Interface，CGI）和外部进行交互。蓝色部分的访问端使用XHTML语言及AJAX技术，利用JavaScript解释引擎来访问执行机构。执行机构内嵌蓝色部分的Web服务前端，在其中部署CGI，用C语言或PHP、Python等解释引擎来解释前端过来的指令，并调用执行机构的服务。

图 5 嵌入式设备智能化Web方案

2.2 Java方案

智能网联汽车应用系统的嵌入式设备智能化Java方案如图6所示。图中红色部分的HMI应用逻辑规范采用Java语言，在Java虚拟机空间解释执行。解释后的代码与设备的Native空间交互，进行对设备的操作。

图 6 嵌入式设备智能化Java方案

2.3 分布式方案

考虑到智能网联汽车电子电器体系架构的可扩展性及零部件的冗余性，兼顾消息通信的实时性，采用多主机分布式体系架构设计方案，如图7所示。该方案把原生系统作为智能设备的附属设备（Accessary Utilities），HMI和执行机构采用分布式架构，分别部署在两台主机的不同系统中。图7双系统的红色部分RMI使用TCP Socket或BlueTooth Socket进行远程方法调用。

图 7 多主机分布式体系架构设计方案

3 原型验证

采用Android智能手机与嵌入式设备互联，把智能手机作为HMI，嵌入式设备作为执行设备。两系统采用WIFI或BlueTooth进行无线连接。考虑到双系统间通信的实时性，和两个系统平台的不一致性，选用了公用对象请求代管者体系结构（Common Object Request Broker Architecture，CORBA）作为RMI通信协议。CORBA组件主要用于实现平台无关和透明传输，所以采用CORBA这类跨平台组件是上佳的选择。

实现的原型是在Linux和Android两个操作系统平台上部署一个媒体播放的分布式应用程序。其中，Android系统上的APP提供用户操作界面及应用功能逻辑，Linux系统上的Service是实现媒体解码和媒体播放的执行机构。

3.1 执行机构设计

执行机构侧的Linux系统和Android系统交互需要满足以下条件：

（1）Linux和Android同时部署相同版本omniORB （AT&T）支持库。为避免数据原语可能的不一致性，特地同时为Linux和Android移植了ominORB[7]相同版本。本方案采用omniORB 4.2.0版本。

（2）Linux和Android能通过TCP/IP彼此访问。Linux和Android能彼此通过TCP/IP“看”到对方，可对它们部署omniNames CORBA对象寻址服务。这样，通过对象名字能访问对象实体，而不用关心对象实体部署在哪里。

omniORB对Linux平台支持很好，Linux侧omniORB的移植相对容易，移植要点如下：

（1）交叉编译。由于编译过程对omniORB IDL编译工具的依赖，需要先编译出“omniidl”，“omkdepend”，“omnicpp”三个程序 build-host的版本。具体操作方式是先用cmake生成修改Make fi le文件，然后修改目录“src/tool”中的Make fi le文件，把其中的编译器更换为build-host版本。

（2）交叉编译器的选择。交叉编译选择GCC。ARM平台有很多Linux移植版，编译时需要参照处理器指令集类型和Linux用户层支持库进行选择。本次原型验证采用TI DRA7xx的Linux平台配型的“arm-linux-gnueabihf”工具链。

（3）omniORB运行时的环境。生成的omniORB运行库若非直接安装到系统的“LIB”路径，则需要在运行omniNames前把omniORB的lib路径加入到“LD_LIBRARY_PATH”环境变量中。

图 8 嵌入式设备智能化设计

如图8所示，执行机构的Linux 服务程序是一个媒体播放器。选用开源媒体播放框架FFmpeg（http://ffmpeg.org/）作为解码器，然后又选用了mplayer（http://www.mplayerhq.hu/） 作 为 播 放 器 的shell，ALSA作为声音通道。执行机构执行过程是从omniORB获取到IPlaylist和IMediaPlayer对象，然后IPlaylist和IMediaPlayer对象再与媒体播放器实体进行交互。

3.2 HMI设计

HMI侧omniORB的移植基本和Linux侧的相同，但需要注意的是omniORB官方不支持Android平台。而Android原生bionic库只实现了POXIC standard C library的子集（bionic相对POXIC标准缺少了大约200条函数实现），这样omniORB对Android的支持有限。在移植过程中仅遭遇到数条需要补充的C函数。Android版本的toolchain选用Android NDK的API level-19，指令集设置为“-march=armv7-a”。HMI APP是一个Android应用程序，结构如图9所示。

图 9 智能化设备HMI设计

下面是用CORBA IDL语言定义的远程调用接口。

4 性能评测

本次试验评测了高通的面向IoT的AllJoyn方案以及本次omniORB方案的RMI通信延时和资源占用情况。本次测试环境和测试方案如下。

（1）测试环境：Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30 GHz，内存为 20 GB 。

（2）测试计时已去除STDIO操作。

（3）测试两类API：一类是只单向发送，另一类是带callback。

（4）表中显示的使用nanosecond单位计时，每次测试数据是调用测试API连续1 000次试验的结果。

表1 命令发送时延 nanosecond

表2 Callback调用时延 nanosecond

表3 程序内存消耗 Byte

表4 Service启动时间 nanosecond

表5 HMI APP启动时间 nanosecond

5 结论

经测试验证，这种分布式主机双系统之间的RMI调用延时不超过0.1 ms，服务启动时间不超5 ms，完全满足车机操作实时性及服务快速启动响应的要求。系统稳定，可靠性、扩展性强，在汽车电子电器架构智能驾驶应用领域及Telematics都有广泛的应用前景。此外，本方案全部采用开源代码进行开发，开发周期短，见效快，能较好地满足商业软件对开发周期及成本的要求。针对RMI的并发操作及对有高带宽需求的视觉传感器的集成，还有待进一步研究。

参考文献（References）：

[1]WEBER J. Automotive Development Processes：Processes for Successful Customer Oriented Vehicle Development[M]. New York：Springer，2009.

[2]HANAWALT E S，ROUSE W B. Car Wars: Factors Underlying the Success or Failure of New Car Programs[J]. Systems Engineering，2010，13(4)：389-404.

[3]BROEKMAN B，NOTENBOOM E. Testing Embedded Software [M]. Boston：Addison-Wesley，2003.

[4]SANGIOVANNI-VINCENTELLI A，NATALE M D.Embedded System Design for Automotive Applications [J].Computer，2007，40(10)：42-51.

[5]ABDALLAH A，FERON E M，HELLESTRAND G，et al. Hardware/Software Codesign of Aerospace and Automotive Systems [J]. Proceedings of the IEEE，2010，98(4)：584-602.

[6]朱赛春. 嵌入式通信总线的体系结构设计与原形实现[D]. 天津：南开大学，2005：10-11.ZHU Saichun. Communication Bus Architecture Design and Implementation for Embedded System [D]. Tianjin：Nankai University，2005：10-11.(in Chinese)

[7]AT&T. omniORB：Free CORBA ORB[CP/OL]. http://www.omniorb-support.com.