车企工程师的视角是如何看待智能网联汽车的？

为了满足智能网联汽车多源信息早期集成的要求，提出了智能化设备的概念与模型，识别出智能化设备的重要特征：具备解释性语言的开放接口。针对这一特征并根据实时性及安全性的要求，对车载嵌入式设备的早期集成给出了三种解决方案：Web CGI 方案、Java 方案和分布式方案。针对分布式解决方案，从软件工程的角度，提出了利用高抽象级别的 RMI 来解决嵌入式设备互联的方法，采用 CORBA 构件互联协议，以智能手机控制媒体播放设备的原型实现来进行平台中间件的验证。

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

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

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

1 系统设计目标与要求

平台中间件的设计与开发须达成以下目标。

1） 支持零部件灵活部署

2） 支持零部件快速集成

3） 支持产品早期验证

4） 支持快速迭代的生产模型

根据 HMI 架构平台设计目标，平台中间件的设计要达到以下目标。

1） 支持HMI 架构上显示与功能逻辑的分离；

2） 形成企业标准的车载应用逻辑开放接口规范（Profile）；

3） 灵活配置 HMI 功能；

4） 快速切换 HMI 风格；

5） 支持迭代开发，缩短 HMI 新功能开发周期；

6） 缩短 HMI 与 Tier1&2 集成开发时间，整车开发周期由通常两年半降低为一年半；

7） 减少信息源部署的物理制约，支持 TBox及多传感器信息源与 HU 的快速集成；

8） 减少显示屏幕部署的物理制约，支持仪表、中控屏、副驾屏、前视镜、后视镜及后排娱乐屏快速开发。

智能网联汽车电子电器系统构成如图1 所示，其中的平台中间件部分在整车系统集成中占有中心位置。

图 1 系统构成概念图

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

图 2 零部件部署拓扑图

2 设计方案

为了便于设备执行机构与外界的交互，HMI 界面及模块间交互语言一般采用解释性的高级语言。交互语言为解释性语言的设备我们称之为智能化设备（Smart Device）。从概念上图 3 中的设备智能化模型应包括脚本语言、解释引擎和执行机构三部分。

图 3 设备智能化模型

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

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

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

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

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

图 4 进程间通信模型

2.1 Web方案

智能网联汽车应用系统的嵌入式设备智能化的 Web 方案如图 5 所示。执行设备使用 Web 的 CGI（Common Gateway  Interface）和外部进行交互。访问端使用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  和执行机构采用分布式架构，分别部署在两台主机的不同系统中。双系统在 TCP Socket 或 BlueTooth Socket 上进行远程方法调用（RMI）。

图 7 嵌入式设备分布式方案

3 原型验证

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

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

3.1 执行机构设计

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

1） Linux 和 Android 同时部署相同版本omniORB (AT&T)支持库。为避免数据原语可能的不一致性，特地同时为 Linux 和 Android 移植了 ominORB 相同版本。本方案采用 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 生成修改 Makefile 文件，然后修改目录“src/tool”中的 Makefile 文件，把其中的编译器更换为 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 语言定义的远程调用接口。

module MediaPlayer

{

interface  IMediaPlayerListener  { void onSeekComplete(in long msec);

};

interface IMediaPlayer { void pause();

void seekTo(in long msec); void start();

void   stop(); void forward();

void backward();

void settOnSeekCompleteListener(in IMediaPlayerListener listener);

};

};

4 性能评测

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

1）测试环境：Intel(R) Xeon(R) CPU E3-1226

2)  测试计时已去除 STDIO 操作；

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

表中显示的使用 nanosecond 单位计时， 每次测试数据是调用测试 API 1000 次的结果。

5 结 论

经测试验证，这种双主机双系统之间的 RMI调用时延不超过 1ms，服务启动时间不超 5ms，完全满足车机操作实时性及服务快速加载的要求。系统稳定，可靠性、扩展性强，在汽车电子电器架构智能驾驶应用领域及 Telematics 都有广泛应用前景。另外，本方案全部采用开源代码进行开发，开发周期短，见效快，能较好地满足商业软件对软件开发周期及成本的要求。

参考文献

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

[2] 朱赛春. 嵌入式通信总线的体系结构设计与原形实现[D]. 南开大学，2005：10-11

[3] J. Weber. Automotive Development Processes: Processes for Successful Customer Oriented Vehicle Development[M]. New York: Springer, 2009.

[4] E. Hanawalt and W. Rouse. Car wars: Factors underlying the success or failure of new car programs[J]. Systems Engineering, 2010, 13(4).

[5] B. Broekman and E. Notenboom. Testing Embedded Software[M]. Boston: Addison-Wesley, 2003.

[6] A. Sangiovanni-Vincentelli and M. Di Natale. Embedded system design for automotive applications[J]. Computer, 2007, 40(10): 42–51.

[7] A. Abdallah, E. M. Feron, G. Hellestrand, and M. Wolf. Hardware/software codesign of aerospace and automotive systems[J]. Proceedings of the IEEE, 2010, 98(4): 584–602.

[8] M. S. Fisher. Software verification & validation: An engineering & scientific approach[M]. New York: Springer, 2007