车载虚拟仪表及诊断系统的设计与实现

刘善坤　窦立谦　宗　群　苟鹏程

(天津大学电气与自动化工程学院　天津 300072)



车载虚拟仪表及诊断系统的设计与实现

刘善坤窦立谦宗群苟鹏程

(天津大学电气与自动化工程学院天津 300072)

论述基于Android平台的车载虚拟仪表及诊断系统的软硬件设计过程。在具体实现上，利用ARM+Android体系构建终端仪表装置，在此基础上完成Android下CAN驱动的移植、车辆数据采集、图形化虚拟仪表显示以及故障诊断等功能。该装置借助Android特有的SurfaceView类实现了将车辆状态数据以图形化的方式展现在LCD触摸屏上，从而取代了传统的仪表盘。此外，还可以实时监测汽车运行和各ECU工作状态。当出现故障时，进行诊断，并第一时间为车主提供故障详情及维修建议。最后，采用dSPACE实时仿真系统与本装置构成闭环的测试系统来进行硬件在环(HIL)仿真测试，结果证明该装置性能稳定、显示效果良好，故障诊断功能全面、准确。

车载虚拟仪表SurfaceViewCAN通信故障诊断

0　引　言

汽车电子化使汽车进入高科技产品的范畴，并被看作是衡量一个国家汽车工业水平的重要标志。随着汽车保有量及销售量的逐年攀升，我国的汽车电子市场规模也随之水涨船高，从2007年的1200多亿元增长到了2012年的2600多亿元，预计到2015年，将突破4000亿。其中的汽车电子成本占比也在不断增长，预计2015年会达到40%，相比2000年翻一番。与此同时，汽车科技领域正在发生新的技术革命，这也无形之中驱动着汽车产业“改朝换代”的步伐。

作为与驾驶员进行信息交流的窗口，汽车仪表盘的作用不言而喻。经过一个多世纪的演变，它由机械式的、借助物理原理实现的传统仪表逐渐发展成为数字加模拟式的、借助多种传感器实现的全数字仪表系统，并广泛用于大小型汽车上[1]。

如今，随着车主群体的不断壮大，人们对于仪表的功能及外观的要求也趋于多样化。正所谓众口难调，传统仪表的“一成不变”性显然无法给所有用户带来智能化的功能体验及完美的视觉冲击。

本文以天津一汽威志汽车作为实验对象，设计出基于Android平台的车载虚拟仪表及诊断装置。该装置可将车辆行驶状态信息以图形化的方式展现在LCD触摸屏上。并且结合汽车自诊断系统实时监测汽车运行和各电控单元(ECU)工作状态，并主要针对出现故障频率最高的发送机进行检测与诊断。所涉及的部位包括燃油与排气系统、点火控制系统、废气控制系统、怠速控制系统、电脑控制系统、怠速马速控制系统、油门控制系统等七大最常见故障部位。当出现异常时，进行分析与诊断，并第一时间显示故障原因、故障部位并提供维修建议，摆脱了传统的、笨重的故障检测仪的束缚，改变了车主面对故障问题束手无策的处境。因此，该装置具有良好的市场前景和广阔的应用空间。

1　系统总体结构

该系统的整体硬件结构如图1所示。总体的硬件设计主要包括四大部分：ARM主控器、LCD触摸屏及其驱动电路、CAN通信装置和信息采集装置(ST10)。

图1　系统总体硬件结构图

其中，ARM主控器采用三星的Exynos4412四核处理器，该主控器基于Quad Cortex-A9，运行主频为1.5 GHz，2 GB DDR3 RAM，可配置16 GB eMMC闪存。此外，该处理器内部还集成了高性能的图像引擎技术，支持2D及3D的图形图像处理及显示，从而为虚拟仪表的设计与实现提供了强有力的支撑。

LCD触摸屏采用的是群创AT070TN92，支持电容式多点触摸，分辨率高，反应速度快。其驱动电路板与主控器直接采用45 pin接口相连，该接口提供了行场扫描、时钟、使能和背光开关等控制信号以及完整的RGB数据信号(RGB输出为 8：8：8，最高可支持1600万色的LCD)。此外为支持电容触摸屏，还增设了I2C和中断脚。

作为主控器的通信节点，CAN模块与核心处理器Exynos4412一起组成了整个CAN通信系统，如图2所示。

图2　CAN通信系统

该CAN通信系统的控制器采用的是带有SPI接口的MCP2515，完全支持CAN V2.0B技术规范[2,3]。收发器采用的是一款带隔离的高速CAN收发器芯片CTM1050T，该芯片与传统的CAN收发器CJA1050相比，最大亮点是内部集成了CAN隔离及CAN收、发器件。在保留了原有功能的基础上还具有DC 2500 V的隔离功能及ESD保护作用，与控制器MCP2515有良好的兼容性。与常规的CAN总线通信设计相比，省去了光电耦合器(6N137)和电源隔离器(ZY0505BS)，避免了电路设计的复杂性，并且增加了抗干扰能力，保证了系统运行的稳定性和安全性。

具体的硬件连接：主控器Exynos4412的接收引脚XspiMISO接CAN控制器MCP2515的发送引脚SO，发送引脚XspiMOSI接CAN控制器MCP2515的接收引脚SI；同步时钟SPICLK由主控器提供；MCP2515的片选信号CS由主控器的SPI模块的XspiCLK控制，CAN总线控制器MCP2515的中断引脚与主控器的外部中断XEINT0连接，采用中断的方式接收数据[4,5]。

汽车信息采集装置采用意法(ST)公司的ST10系列的单片机。作为16位的汽车专用微处理器，它内部集成了CAN总线接口、K线接口和串口。其中的K线接口与K网络相连，采用K线网络机制采集各个电控单元(ECU)的信息，CAN接口与主控器CAN接口相连，负责传输车辆状态数据及故障信息，串口可以与PC端相连，进行现场调试或模拟数据的传输。

软件平台选用的是Android 4.1.2 系统，内核版本为Linux 3.0.31。该系统内部集成了诸多常用的驱动及接口程序，并且与所选用的处理器Exynos4412完美结合，经测试，性能和稳定性均良好。在此基础上我们需要做的就是系统及内核的裁剪、驱动的移植(C/C++语言)以及上层应用软件的编写(Java语言)。

2　系统裁剪及驱动移植

2.1系统裁剪

整体的硬件与软件平台搭建好之后，就要对Android系统平台进行一些简单的裁剪，使其更加精简，不仅可以增加系统运行的流畅程度，而且使其与硬件平台完美匹配。此操作均在虚拟机(Vmware 10)下的Fedora 18环境下进行。

内核方面的裁剪可借助基于文本模式的菜单型配置，如图3所示。根据具体情况选择所需要的系统部件，并改写相应的Makefile文件，然后进行编译，最终生成适合我们系统的内核镜像文件。

图3　内核的菜单型配置

Android上层的剪裁则相对比较简单，包括改写系统初始化配置文件init.rc，删除SystemServer.java中不必要的系统服务，以及对不需要的预加载资源和类进行屏蔽等，具体实现不再赘述。

2.2驱动移植

作为硬件与系统之间的桥梁，驱动的作用不言而喻。Android内核可以看作是Linux内核的增强版，它在保留后者基本架构的基础上又增添了一下新的驱动程序和必要的功能。但对于一些非标准设备的驱动程序，还须我们自己开发和移植[6]。下面就详细介绍一下Android平台下的CAN总线驱动程序的开发与实现。

由于CAN通信系统的主控器选用的是MCP2515，且主控器与其直接进行通信，所以这里所说的CAN总线驱动就是指Android下CAN控制器MCP2515的驱动。传统的CAN驱动是基于字符设备的。这种方式只能针对某一具体硬件的设备驱动，提供的功能比较少，且同一时刻只支持单进程访问。而基于网络设备的Socket CAN驱动则可以克服以上不足。该设备驱动将CAN控制器以网络设备的形式注册进Linux的网络层，实现了用户空间的socket接口，这样一来，CAN控制器就可以与上层的网络协议以及CAN协议族进行通信。

图4所示为Android下的CAN总线通信开发流程图。Android下的CAN总线通信开发流程如图5所示。

图4　Android下的CAN总线通信开发流程

图5　CAN通信系统测试环境

第一步向Android内核注册MCP2515驱动，根据前面所述的具体的硬件连接方式编写相应的注册代码，包括SPI总线的加载和声明，CAN控制器的设备信息的填写、初始化、读写等操作，将其封装成socket接口。

第二步根据所选芯片类型配置内核选项，然后编译并加载到Android内核中。此处是以模块化的方式进行编译，生成以下所需文件：can.ko、can-raw.ko、can-bcm.ko、can-dev.ko、mcp251x.ko。然后按顺序通过insmod命令依次进行加载，这样做的目的是不用重新编译内核，缩短开发周期，减少工作量。

第三步CAN测试工具的编译：在Vmware的Fedora环境下编译测试工具——canutils，主要用到的命令有ifconfig命令：负责CAN节点的开启与关闭；candump命令：负责CAN节点的数据接收；cansend命令：负责CAN节点的数据发送；canecho命令：负责对波特率等的设置。

此处要特别注意的是，由于该测试软件的使用环境默认是在Linux，而我们最终的测试环境是Android，为避免出现命令不识别的情况，必须借助NDK(Native Development Kit)的相关工具进行编译。因此要首先进行NDK环境的搭建以及Android.mk的编写，然后进行测试工具的编译。

第四步CAN通信的测试：此步骤主要是为验证CAN驱动的正确性，主要进行CAN总线的收发实验。

首先是CAN通信系统测试环境的搭建(见图5)，该测试环境由三部分构成，主要包括PC机及其上位机软件(调试终端SecureCRT和串口助手)、带有CAN通信装置的主控器、汽车数据采集的模拟装置。然后通过第三步编译的脚本命令来控制主控器的CAN节点动作(设置、发送、接收)。采用带有CAN模块和串口的处理器来模拟汽车的信息采集装置，并通过电脑端的调试助手控制其数据的发送与接收，从而测试通信是否准确及稳定性是否良好。若一切正常，则表明Android下的CAN驱动已移植成功。

第五步Android HAL层的调用：由于Android上层的Application和Application Framework都是使用Java编写，底层包括系统和Libraries都是C/C++编写的。所以上层Java要调用底层的C/C++函数库必须通过Java的JNI来实现，所以此操作是至关重要的。

首先通过struct hw_module_t、struct hw_module_methods_t和struct hw_device_t3个结构体来设置硬件操作方法[7,8]，并在JNI层对其进行注册，然后在Servixe层对JNI所提供的方法进行声明，采用静态或者动态方式加载包含上述方法的库文件(*.so)。

以上步骤完成以后，就要运用Java语言在eclipse环境下编译App应用软件。

3　虚拟仪表的软件设计

上层应用软件的编写采用Java语言，开发环境为eclipse，适用版本为Android 4.1.2。考虑到操作的流畅度以及事件响应时间，该设计采用了Android系统下的多线程操作，具体流程如图6所示。

图6　软件设计流程图

首先是主控器以及外围模块的初始化操作，该过程主要完成了核心处理器的内核和Android操作系统的初始化任务、LCD触摸屏的识别与配置以及CAN通信系统的初始化(包括SPI的使能、中断的使能、ID的设置、波特率的设置等)。

然后启动UI主线程、绘图子线程、数据采集子线程。由于绘图操作与数据采集操作都比较耗时，为保证主线程的流畅性，增强用户体验，将两个耗时操作放到了两个线程。先看数据采集子线程，基于CAN总线的数据采集主要任务是接收来自汽车信息采集装置的一些车辆行驶参数或故障信息，并判断数据帧ID。如果为故障码ID，则进入故障诊断程序，否则为车辆行驶数据帧，然后将这些参数进行解析与处理，作为绘图操作的数据来源。下面对CAN通信机制及数据处理做一下简要说明。

数据类型为标准帧，标识位(ID)11位，数据字段为8个字节，ID越小，优先级越高。每帧的高位节优先传送。具体数据内容定义如表1、表2所示。

表1　车辆状态数据帧一

ID：701(111 0000 0000 0000 0001)

表2　车辆状态数据帧二

ID：702(111 0000 0000 0000 00010)

本数据格式及内容为实验所用，更多的数据内容可在以后版本中进行添加与完善。

对于绘图子线程，它的主要任务是接收来自数据采集子线程的车辆行驶状态数据，从而根据有效的数据进行绘图操作。

主要借助Android下具有高速执行效率的绘图容器—SurfaceView。它拥有独立的绘图表面，能够在主线程之外的独立线程中向屏幕绘图，可以避免因画图任务繁重而造成的主线程阻塞；还可以直接从内存或者DMA等硬件接口取得图像数据, 实现复杂而高效的UI绘制[9]。

该方法主要涉及到SurfaceHolder.Callback接口和Runnable接口的实现。其中，SurfaceHolder用来存取程序的Canvas，从而控制Surface。Callback函数包括surfaceChange()、srufaceCreated()和surfaceDestroyed()三个回调函数。Runnable接口的实现则是为了绘图子线程的建立，其中具有耗时操作的绘图程序在run()方法中完成，避免了主线程的拥堵，保证了程序运行的流畅。

最后，UI主线程接收来自绘图子线程的绘图，从而完成UI界面的更新，继而将整个仪表以图形化的方式展现在LCD触摸屏上。所涵盖的信息包括车辆行驶速度、发动机转速、总里程、燃油液位、机油压力、冷却液温度、车内温度、车门以及后备箱的打开与关闭、车灯状态(包括远光灯、近光灯、前雾灯、后雾灯等)、状态指示灯、警示灯等。最终实物效果如图7所示。

图7　实物效果图

该装置与传统的仪表相比，具有诸多优点。首先，省去了硬件驱动电路(包括步进电机及其他机械设备的驱动等)的设计，避免了硬件电路及线束的繁琐，节省了开支。其次，该装置将分散的、相互独立的仪表模块整合在了一起，便于集中管理与配置。并且避免了外界的物理性干扰，比如颠簸的路面、设备的磨损等，提高了灵敏度和精确度。

此外，还可基于此装置进行内容的丰富，并根据需要制定多种类型的仪表模式，用户可根据喜好任意切换，具有良好的可扩展性和灵活性，真正体现了人性化与智能化的特点。

4　故障诊断的设计与实现

Android系统提供了基于SQLite的嵌入式数据库管理系统，因此，可以借助SQLite来建立故障诊断系统的后台数据库，并完成数据的查询、存储、删除、修改等操作。因此，首先依据天津一汽提供的威志原厂维修手册[10]建立本地数据库故障码表fcode，并导入到Android系统下，作为故障诊断的后台数据库，然后结合各ECU的自诊断系统完成故障诊断功能。软件设计流程如图8所示。

图8　故障诊断流程图

该诊断功能采用目前国内广泛使用的一种车载诊断协议标准——KWP2000(Keyword Pro-tocol 2000)。该协议实现了一套完整的车载诊断服务，并且满足E-OBD(European On Board Diagnose)标准，即基于CAN的ISO 15765协议。首先汽车信息采集装置通过K线采集汽车的ECM、ABS、SRS、TCU、TPMS等电控单元的数据[11]，并重点对发动机性能进行评估及故障检测。当发生故障时，通过CAN通信读取电控单元自诊断系统产生的故障码，存储在数据表newcode中，并实时提示故障的出现，如图9所示。点击“故障原因”按钮，系统会读取保存在newcode中的故障码，并对其进行解析处理，然后在数据库故障码表(fcode)中查询与匹配，Android系统调用ListView组件以列表的形式显示故障码、故障原因、故障部位等信息。点击“获取帮助”按钮，便可获取维修建议及维修步骤，从而第一时间为车主提供维修帮助，如图10所示。

图9　故障诊断提示界面

图10　故障诊断界面

其中的故障码数据帧定义如表3所示。

表3　故障码数据帧

ID：700(111 0000 0000 0000 0000)

5　功能测试

为验证该装置的稳定性和可靠性，采用dSPACE实时仿真系统与本装置构成闭环的测试系统，来进行硬件在环(HIL)仿真测试。dSPACE专门为汽车用户提供了快速开发及测试系统——MicroAutoBox，它集成了包括CAN在内的大量接口，可与车载装置连接进行实时仿真测试。

首先看仪表功能的测试，先建立车辆仿真模型，用来采集不同类型的车辆状态参数(包括模拟量、数字量、脉冲量、开关量等)，并从Simulink模块库中选择dSPACE CAN模块(RTICAN Transmit和RTICAN Receive)加入到仿真程序中，并设置其参数(波特率125 000 bps，标准帧ID 701、702)。最后启动dSPACE及ControlDesk，编译并下载Simulink仿真程序，在ControlDesk中设置监控界面，对仪表功能进行测试，仿真测试框图如图11所示。

图11　dSPACE虚拟仪表在环仿真框图

通过硬件在环(HIL)仿真测试表明，该装置的虚拟仪表功能能够将仪表信息完整、全面、准确地展现在LCD屏幕上，并且CAN通信功能稳定、精度高，没有出现丢失帧、错误帧等错误信息。

在仪表分辨率方面，发送机转速(2个字节)的分辨率达到0.122 rpm/位，测量范围从0～8000 rpm；车量行驶速度(2个字节)高位字节为0.936 km/h/位,数据范围0～240 km/h;总里程、燃油液位、冷却液温度等仪表信息均达到了标准要求。

在故障诊断方面，主要围绕汽车最重要的总成——发动机进行，所涉及的部位包括燃油与排气系统、点火控制系统、废气控制系统、怠速控制系统、电脑控制系统、怠速马速控制系统、油门控制系统等七大最常见故障部位。dSPACE故障诊断在环测试框图如图12所示。

图12　dSPACE故障诊断在环测试框图

该诊断功能遵循基于CAN的ISO 15765协议，通过dSPACE仿真平台模拟车辆故障来进行硬件在环(HIL)仿真测试，测试结果验证了该装置性能的稳定性及可靠性。当出现故障时能够迅速、准确地获取故障码，并根据故障码锁定故障部位、故障原因，提供维修步骤等帮助信息，从而实现故障诊断的功能，与仪表显示功能具有良好的兼容性。

6　结　语

本文从硬件的设计、Android系统的搭建、驱动的移植以及上层应用软件的编写等方面论述了系统的开发过程，并实现了一套完整的、全图形化的车载虚拟仪表及诊断装置。该装置将仪表信息直观、全面地呈现在屏幕上，内容丰富、可读性强，并且具有较高的精度和良好的稳定性，有望取代笨重的、单一的步进电机驱动式仪表盘。其中的故障诊断功能可在故障出现时帮助车主第一时间了解故障详情，并提供故障的检测与维修建议。

此外还可在此硬件、软件平台上进行功能的扩展，比如北斗导航、车载电话、语音控制、3G上网等功能，使其成为集显示、服务、控制于一体的多功能仪表系统。随着智能车载系统的普及，以及Android开源系统的盛行，该系统所适用的车辆及车型将会大幅度提高，具有良好的发展前景和广阔的市场空间。

[1] Tom Denton.Automobile Electrical and Electronic Systems[M].北京:机械工业出版社,2008.

[2] 徐争颖.CAN总线及其网络系统的实现[J].自动化与仪表,2005(5):39-41.

[3] 赵宝华.CAN总线技术在汽车数字仪表中的应用研究[J].科技通报,2013,29(3):197-200.

[4] 申建伟.基于ARM的智能车控制系统研究[D].西安:西安工业大学,2014.

[5] 姚蔚利.车辆总线与网络通信技术标准(上)[J].信息技术与标准化,2007(11):11-16.

[6] 孟小华,黄宗轩.Android系统非标准设备驱动程序设计[J].微型机与应用,2011,30(14):7-12.

[7] 王振丽.Android底层开发技术实战详解[M].北京:电子工业出版社,2012.

[8] 李玉洁,朱维杰.Android系统下CAN总线驱动程序的设计与实现[J].电子科技,2013,26(2):83-86.

[9] 罗雷,韩建文,汪杰.Android应用开发实战详解[M].北京:人民邮电出版社,2014.

[10] 李想.车载故障诊断系统的设计与实现[D].天津:天津大学,2010.

DESIGN AND IMPLEMENTATION OF VEHICULAR VIRTUAL DASHBOARD AND FAULT DIAGNOSIS SYSTEM

Liu ShankunDou LiqianZong QunGou Pengcheng

(SchoolofAutomationandElectricalEngineering,TianjinUniversity,Tianjin300072,China)

In this paper, we discuss the design process of hardware and software of Android platform-based vehicular virtual dashboard and fault diagnosis system. In regard to specific realisation, we made use of ARM+Android system to establish terminal instrumentation devices. On this basis, we completed the functions of driver transplantation of CAN, vehicle data acquisition, graphical virtual dashboard display and fault diagnosis under Android. The instrument realises the display of cars’ state data on LCD touch-screen in the form of graphic pictures through unique SurfaceView of Android system, so that it replaces the traditional instrumentation accordingly. In addition, the instrument can also timely monitor the working status of cars and ECUs. When a fault occurs, the system makes the diagnosis, then immediately provides owners with the failure details and repair suggestions. Finally, we carried out the HIL simulation testing by composing a closed-loop testing system with dSPACE real-time simulation system and this instrument, and the results proved that the instrument had stable performance, and got a better visual effect as well. The fault diagnosis function was also accurate and complete.

VehicularVirtual dashboardSurfaceViewCommunication by CANFault diagnosis

2015-01-20。国家自然科学基金项目(91016018)；天津市基础研究重点项目(11JCZDJC25100)。刘善坤，硕士生，主研领域：嵌入式开发。窦立谦，副教授。宗群，教授。苟鹏程，硕士生。

TP368.1

A

10.3969/j.issn.1000-386x.2016.08.051