虚拟仪表盘

2024-10-24

虚拟仪表盘(精选6篇)

虚拟仪表盘 篇1

1 引言

车联网是汽车技术与互联网技术的高度融合,车载终端作为车联网的核心部件之一,是用户应用车联网服务的直接接口。随着移动手机的普及和软硬件技术发展,基于手机的车联网终端应用成为一个学术界和产业界关注的焦点,手机符合了为车联网应用提供友好的用户界面和图形展示方面的要求,并且还具有便捷、易扩展等优势。通过OBD、蓝牙等通信技术,系统设计和开发人员可以把车载数据实时读取到移动终端上,为用户提供实时显示、故障诊断、增值服务等业务。

当前,Android的市场占比继续保持增长态势,根据Statista发布的数据,截止2016年第二季度,Android手机的全球市场占比已经达到了86.2%,为Android手机用户提供车联网服务具有广阔的用户基础和应用前景。

随着研发人员的增多,各式各样的Android车联网应用不断被推出,但是,作为仪表显示等通用的模块,缺少系统级别的封装,使得开发效率降低,缺少复用性和移植性,反复造“轮子”现象比较突出。

2 仪表盘设计

2.1 总体架构

虚拟仪表盘由外边框、刻度与指针3部分组成。为了更好放置与定位组件的位置,3个部分均为设计为独立组件,然后插入插槽构成整体。组件化的设计使得各部分耦合度降低,调用方便、可定制、可扩展。

2.2 详细设计

(1)仪表盘外边框绘制。封装Ts Border类实现外边框绘制功能,允许传入中心点坐标、半径大小、画笔颜色及宽度等参数来进行定制。绘图时首先获取当前画布中心坐标,然后根据传入的参数列表绘制空心圆,以保证在不同屏幕上按比例绘制,实现不同屏幕上的大小自适应。

(2)仪表盘刻度绘制。封装Ts Scale类实现刻度与数值的绘制功能,允许传入起始角度、偏移角度、大刻度个数、小刻度个数、大刻度步长、小刻度步长、数值递增量等参数实现定制。首先通过起始角度和偏转角度计算刻度表的总弧度。刻度部分隐含4个逻辑上的同心圆作为边界,这4个边界半径逐渐减小,从外至内依次称之为外边界、中间边界、内边界和数值边界。仪表盘刻度由两个边界圆的半径差决定,且指向圆心,其长度可以由传入的4个边界圆半径进行定制,同时允许调整粗细、颜色等属性、弧度计算过程、刻度数值偏转角度。x轴坐标计算:|r|*cos(2*π/360*|θ|)(θ为圆心角),y轴坐标计算将外边界圆心角与半径、中间边界圆心角与半径、内边界圆心角与半径带入得出分别的坐标点,即可根据点绘制刻度直线。

(3)指针绘制。封装Ts Pointer类实现指针绘制,允许传入指针长度、空心圆半径、实心圆半径与画笔风格等参数实现定制。圆心至虚拟圆的半径线为指针,圆心至实心圆边界绘制为实心圆作为仪表盘中心显示部分,其绘制原理与刻度相同。指针可以根据步长值重绘,在应用基于多线程技术可以实现指针实时更新显示,考虑到车辆速度等实时性要求较高的图形绘制要求,使用双缓冲技术实现绘图操作,以解决高频率重绘时各个模块会出现画面撕裂现象的问题。

(4)自定义绘图类。组件都是基于绘图实现,把基于Surface View的画板、画笔设置、对称点设置相关的方法封装在父类Ts Draw中,利用继承的优势保证绘图风格一致、减少代码量、增强扩展性。

(5)封装为View类Dashboard View。将Ts Border、Ts S-cale、Ts Pointer组合成一个独立的View类Dashboard View。开发者可以直接构造Dashboard View对象,然后绘制到屏幕上,完成虚拟图标的绘制功能。经过这种组合,本应用可以以API的形式发布使用。

3 仪表盘实现

3.1 类图

如图1所示。

3.2 Dashboard Activity实现

Dashboard Activity继承至Ts Draw,重写Ts Draw类中的ts On Draw方法,实现图形的绘制。核心代码如下:

本组件可以在XML文件中直接调用,配置文件代码如下:

4 应用演示

自定义时速仪表盘Speed Dashboard Activity类、油量仪表盘Oil Dashboard Activity类,运行效果如图2所示。

5 结语

在车联网及其他涉及到仪表盘绘制的应用中,定义一个可复用的虚拟仪表盘,既有利于提高功能代码的内聚程度,同时也降低了与其他功能代码的耦合度,具有良好的复用性和扩展性,其面向对象的设计和实现、绘制方法设计,也具有一定的借鉴价值。

参考文献

[1]HU Ling-ling,LI Hai-feng,XV Xv,et al.An Intelligent Vehicle Monitoring System based on Internet of Things[C]//Procee ding of 2011 Seventh Internation al Conference on Computa tional Intelligence and Security.Sanye:[s.n],2011:231-233.

[2]吉永卿,龚元明.基于蓝牙的汽车OBD-Ⅱ电控故障诊断系统[J].单片机与嵌入式系统应用,2014(11):56-59.

[3]崔胜民.智能网联汽车新技术[M].北京:化学工业出版社出版,2016:1-50.

[4]杨丰盛.Android应用开发揭秘[M].北京:机械工业出版社,2010.1:2-15.

[5]Bill Phillips,Chris Stewart,Brian Hardy,et al.Android Programming:the Big Nerd Ranch Guide,second Edition[M].人民邮电出版社,2016.

虚拟仪表盘 篇2

系统仿真是电子计算机的重要应用领域, 而飞机飞行仿真是系统仿真的重要分支, 可用于飞机动力学特性评定, 飞机操纵系统可操纵性和稳定性、控制系统控制规律研究, 飞机座舱布局及航空电子系统软、硬件结构组成与功能研究, 机载武器及其发动机控制系统仿真, 飞机应急或故障情况下可操纵性仿真, 以及相关系统操作使用人员的培训[1]。飞行模拟器就是典型的人在回路的飞行仿真系统。

传统的飞行模拟器中使用的飞行仪表通常有三种形式, 即模拟仪表、改装仪表和真实仪表。由于计算机虚拟仪表显示记数的发展极其优越性, 其在飞行模拟器上的应用, 尤其是在工程模拟器上的应用将日趋广泛, 取代传统模拟器飞行仪表势在必行。

2 软件创新点

OpenGL是处理专用图形硬件的软件接口, 是支持可视化实现、支持视景生成的程序设计语言。它非常适合可视化仿真系统[2]。它能够从多种可选模式画图元, 而且一种模式的设置一般不会影响其他模式的设置。图元由一组顶点定义, 该组顶点既可以只包含一个顶点, 也可以包含多个顶点。顶点的说明由位置坐标、颜色值、法向量和纹理坐标组成[3]。

本文中的虚拟仪表软件就是利用OpenGL的这些特点开发制作的。该软件基于VC++的MFC编程, 通过嵌入OpenGL语句实现绘图。其特点是通过总结飞机仪表的共性, 根据这些仪表的形状特征设计开发了圆形刻度表盘、垂直刻度带、水平刻度带、俯仰梯度表和垂直刻度表等五种类型虚拟仪表, 并且这几类虚拟仪表可基本覆盖航空常规仪表的需求。

本软件具有可视化界面, 增强了直观性, 使用者可通过任意设置修改软件中的参数得到需求的仪表画面, 同时通过软件的导出功能将需求的仪表画面的相关参数导出。该软件可灵活地被移植到飞行仿真系统中, 用于飞机仪表应用程序的开发, 大大提高相关软件的开发效率。

3 软件功能介绍

圆形刻度表盘可应用于空速表、航空时钟表、无线电磁指示仪表、座舱压力表、发动机转速表、高度表、马赫数表等仪表的开发。该软件可通过修改起始角度、扫射角度、圆盘半径、表盘线宽、相关颜色信息、刻度线信息、文字信息等参数实现应用。显示界面见图1。

垂直刻度带可用于开发平视显示器显示画面中的高度刻度带和速度刻度带。该软件可通过修改刻度带对齐方式、刻度线信息、文字信息等参数实现应用。显示界面见图2。

平显俯仰梯度表可用于开发平视显示器显示画面;仪表俯仰梯度表可用于开发地平仪仪表和多功能显示器显示画面中的垂直显示画面。该软件可通过类型选择实现平显俯仰梯度表和仪表俯仰梯度表的切换, 可通过修改刻度线信息、标志信息、文字信息等参数实现应用。显示界面见图3和图4。

垂直刻度表可用于开发多功能显示器显示画面的高度刻度带和速度刻度带。该软件可通过修改刻度尺信息、仪表信息、刻度线信息、文字信息等参数实现应用。显示界面见图5。

水平刻度带可用于开发平视显示器显示画面中的航向刻度带。该软件可通过修改刻度带颜色、文字大小、刻度线信息、物理参数值等参数实现应用。显示界面见图6。

每一种虚拟表盘的界面中均有一个“导出”按钮, 点击该按钮, 可弹出“导出”功能对话框, 提示用户保存该界面下当前设置的各参数的数值, 文件保存名称可由用户根据需要进行修改, 文件将被保存在与该软件exe相同的路径下。

4 软件界面

4.1 圆形刻度表盘

4.2 垂直刻度带

4.3 俯仰梯度表

4.4 垂直刻度表

4.5 水平刻度带

5 结论

以上是本文中制作的虚拟仪表软件的各项功能描述, 该软件可快速灵活地被移植到飞行仿真系统中, 可减少相关工作量, 提高软件开发效率。软件不足之处是软件界面有待美化改进。

摘要:本文在总结了诸多机型显示仪表共同点的基础上, 使用基于VC++的MFC编程, 通过嵌入OpenGL语句设计开发了具有可视化界面的虚拟仪表软件。该软件包括圆形刻度表盘、垂直刻度带、水平刻度带、垂直刻度表和俯仰梯度表等显示画面, 并可快速灵活地被移植到飞行仿真系统中, 可用于具有平显画面、多功能显示画面、常规虚拟仪表等应用程序的开发, 能很大程度提高相关软件的开发效率。

关键词:仿真,OpenGL,虚拟仪表

参考文献

[1]卢惠民著.飞行仿真数学建模与实践.航空工业出版社, 2007.3

[2]和平鸽工作室编著.Open GL高级编程与可视化系统开发.高级编程篇》.北京:中国水利水电出版社, 2005

虚拟仪表盘 篇3

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

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

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

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

1 系统总体结构

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

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

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

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

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

具体的硬件连接:主控器Exynos4412的接收引脚Xspi MISO接CAN控制器MCP2515的发送引脚SO,发送引脚Xspi MOSI接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系统,内核版本为Linux3.0.31。该系统内部集成了诸多常用的驱动及接口程序,并且与所选用的处理器Exynos4412完美结合,经测试,性能和稳定性均良好。在此基础上我们需要做的就是系统及内核的裁剪、驱动的移植(C/C++语言)以及上层应用软件的编写(Java语言)。

2 系统裁剪及驱动移植

2.1 系统裁剪

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

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

Android上层的剪裁则相对比较简单,包括改写系统初始化配置文件init.rc,删除System Server.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所示。

第一步

向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机及其上位机软件(调试终端Secure CRT和串口助手)、带有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所示。

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

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

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

ID:701(111 0000 0000 0000 0001)

ID:702(111 0000 0000 0000 00010)

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

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

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

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

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

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

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

4 故障诊断的设计与实现

Android系统提供了基于SQLite的嵌入式数据库管理系统,因此,可以借助SQLite来建立故障诊断系统的后台数据库,并完成数据的查询、存储、删除、修改等操作。因此,首先依据天津一汽提供的威志原厂维修手册[10]建立本地数据库故障码表fcode,并导入到Android系统下,作为故障诊断的后台数据库,然后结合各ECU的自诊断系统完成故障诊断功能。软件设计流程如图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系统调用List View组件以列表的形式显示故障码、故障原因、故障部位等信息。点击“获取帮助”按钮,便可获取维修建议及维修步骤,从而第一时间为车主提供维修帮助,如图10所示。

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

ID:700(111 0000 0000 0000 0000)

5 功能测试

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

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

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

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

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

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

6 结语

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

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

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

关键词:车载,虚拟仪表,SurfaceView,CAN通信,故障诊断

参考文献

[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.

直升机虚拟仪表DLL设计与实现 篇4

直升机CBT系统主要采用计算机仿真、计算机控制和图像处理显示等高新技术,实现一个融图形、图像、文字、曲线、图表、声音为一体的多媒体仿真平台。它可以为飞行员提供多方位的信息流,充分发挥飞行员多感官接收信息、应用信息的能力。

直升机CBT系统的组成包括主控计算机系统、网络通讯系统、环境音响系统、座舱、航电及操纵系统、视景系统等。座舱、航电及操纵系统采用软硬结合的方法进行设计,座舱中仪表板和中央操纵台上的分立仪表均为触摸响应的虚拟仪表,用GL Studio进行虚拟仪表开发。座舱结构、座椅、飞行操作联动机构、驾驶杆、总距杆等均做成硬件结构,通过网络将硬件机构的控制信号传给主控计算机进行处理。

直升机CBT系统中的分立仪表有气压高度表、空速表、陀螺地平仪、综合显示器、多功能键盘、油量控制板等,下面将详细介绍虚拟仪表DLL的设计开发过程,以及在GL Studio中进行调用的方法。

1 GL Studio开发平台简介

直升机本文基于仿真平台GL Studio,其是Disti公司为仪表仿真软件开发提供的一套系统解决方案。用户可以利用其图形交互界面以所见即所得的方式完成仪表面板的制作,通过其代码编辑器完成仪表内部的逻辑仿真。其代码生成器能够将用户的制作结果自动生成C++和OpenGL源代码,用户既可以将代码进行单独编译,也可以嵌入到其他程序中进行编译,从而避免了大量繁琐的底层OpenGL开发过程[2,3,4,5]。

GL Studio工程可以生产两种类型的文件:一种可执行文件.exe;另一种是可独立使用的文件即DLL[6]。在用GL Studio进行直升机CBT系统中虚拟仪表开发的时候,各分立仪表都做成单独的DLL,将虚拟仪表的输入和输出接口定义为属性。在最后的主程序开发时,只需在GL Studio的图形界面上插入各虚拟仪表DLL,根据飞行模型的需要传递参数即可。GL Studio开发虚拟仪表DLL的流程如图1所示。

2 创建虚拟仪表DLL

2.1 制作纹理

制作纹理有多种方法,一般采用数码相机拍摄实物照片,然后运用图形编辑软件处理。获取高质量的实物照片是制作纹理的关键,所以在拍摄直升机座舱仪表照片时需要设置好背景,调节好光线,选取合适的角度。制作纹理时,将仪表照片经过图形编辑软件处理后保存为*.png格式[7]。

在进行纹理制作的过程中,采用3D MAX和Photoshop制作仪表纹理非常方便。以直升机仪表中最常见的气压高度表为例,介绍仪表纹理的制作过程。

首先,在3D MAX中,创建一个圆柱体作为盘底,再创建一个白色的小长方体作为长刻度。调整好长方体大小,将旋转轴心设为表盘中心。选择工具中的阵列选项,设置好旋转角度为36°,阵列维数为1D,数量10,按确定。同理阵列出短刻度。对立体图进行渲染,保存为*.png格式。用Photoshop打开进行编辑,添加相应的刻度数字。这种方法制作出来的表盘非常美观,而且比处理仪表照片的效率高。

2.2 设计图形界面

设计图形界面即创建仪表模型,创建的模型分为静态模型和动态模型。以气压高度表为例,高度表盘为静态模型,仪表上的指针、旋钮、气压表盘为动态模型。

GL Studio设计器支持的所见即所得绘制方式,使开发仪表工作变得简单、直观。在GL Studio中进行绘制图形和添加纹理。纹理添加完毕后,注意调整各元件之间的层次关系,确定图形的正确显示[7,8,9,10,11]。仪表界面的最终效果如下,给气压高度表每个独立的部件进行合理命名,以方便行为代码的编写。

场压选择旋钮的制作方法:在设计面板“Geometry”栏中,高亮“PBS”点功能键“Converts Selected to GlsKnob”创建旋钮。右击生成的旋钮,在“Knob”选项卡中设置旋钮转动的角度及连续性。

2.3 定义接口

气压高度表只有一个输入接口:气压值。最少只需要添加一个属性,Baro_hPa(),通过飞行动力学模型给该属性接口传值,单位统一为hPa。

2.4 编写行为代码

气压表左下角的旋钮为场压选择旋钮。仪表右边的气压表盘会随着场压选择旋钮转动指示设定的场压值。添加变量PBS_hPa,该变量记录设定的场压值。

(1)场压选择旋钮代码编写。

旋钮的位置范围为0~100,用来设定场压PBS_hPa,气压修正范围为950~1 050 hPa。在设计气压高度表的时候,假设初始场压在1 013 hPa。

> 场压选择旋钮的初始化代码

self->PositionVal(63.0f);//旋钮初始位置设为63PBS_hPa=950.0+(self->PositionVal());//63.0对应场压1 013 hPa

PBSDisc->DynamicRotate(2.4*self->PositionVal(),Z_AXIS);

//气压刻度盘初始旋转角151.2°,即1 013 hPa气压值所在角度

> 场压选择旋钮回调函数代码

if (ObjectEventIs(ev,"PositionVal"))

{

PBS_hPa=950.0+(self->PositionVal());

//旋钮位置范围0~100,对应的气压修正范围为950~1 050 hPa。

PBSDisc->DynamicRotate(2.4*self->PositionVal(),Z_AXIS);

//气压刻度盘通过换算在0~240°逆时针旋转,与气压表盘950~1 050 hPa场压对应

}

(2)Baro_hPa()属性函数编写。

Baro_hPa()为输入接口,用来接收主程序传来的外界气压大小(静压)。3 000 m以下,每升高12 m气压下降133.3 Pa。通过静压和旋钮设定的场压,即可算出直升机所在的高度。

> Baro_hPa()属性函数的行为代码

_baro_hPa=value;

float altitude=(PBS_hPa*100-_baro_hPa*100)*12.0/133.3;//通过静压和场压差算出高度

float alt_long=(float)fmod(altitude,1 000.0f);

longNeedle->DynamicRotate(-(alt_long*(360.0/1 000)),Z_AXIS);//长指针根据高度值大小旋转,1 000 m转动360°

float alt_short=(float)fmod(altitude,10 000.0f);

shortNeedle->DynamicRotate(-(alt_short*(36.0/1 000)),Z_AXIS);

//短指针根据高度值大小旋转,1 000 m转动36°

2.5 生成代码、发布DLL

选择菜单栏中code->Generate All生成代码,在Microsoft Visual Studio.NET 2003中选择编译选项为Live Component Release,编译、连接,即可生成气压高度表DLL,在Licensed LiveComponent Release文件夹下可以找到生成的Barometric Altimeter.dll。

3 DLL的加载

3.1 插入虚拟仪表DLL

在程序中,有以下两种加载动态链接库的方式:隐式链接和显式加载[12]。而GL Studio中对DLL的加载方式更加简便,程序员不需要了解底层的加载方式即可对DLL进行操作。

在工具栏中点击“(Inserts a Component)”,选中需要加载的仪表DLL,即可将该虚拟仪表插入到GL Studio编辑器中。调整该虚拟仪表的大小,放到仪表板底板合适的位置。插入进来的虚拟仪表DLL实际上是一个类对象指针。

3.2 给虚拟仪表DLL传递参数

插入虚拟仪表DLL并进行合适的命名后,剩下的工作就是在Calculate()对该虚拟仪表的接口进行读写操作,即传递控制参数。

在GL Studio中,Resource()函数可以读写DLL的属性,这也是在创建虚拟仪表DLL的时候将所有输入输出接口定义为属性的原因。调用方式如下:

someObject->Resource("someAttribute")>>someValue;//将虚拟仪表的某个属性读取出来

someObject->Resource("someAttribute")<<someValue;//给虚拟仪表的某个属性传值

在总仪表板程序的calculate()中给各虚拟仪表DLL传递参数,以model_作为前缀的变量是根据直升机飞行动力学模型解算出来的值:

Bool model bPower=true;//电源信号

//-------气压高度表-----------------------------

_BarometricAltimeter->Resource("Baro_hPa")<<model_Baro;

//-------起落架状态指示灯--------------------------

_LGearStatus->Resource("bPower")<<model_bPower;

_LGearStatus->Resource("bJianCha")<<_AlarmPanel->Resource("bJianCha");//将信号灯盒DLL的“bJianCha”属性的值传递给起落架状态指示器DLL的“bJianCha”属性。即将信号灯盒上的检查按钮的状态传递给起落架状态指示灯,控制其亮。

……

3.3 调试并完善

在项目后期联合调试和完善的过程中,如果需要对某个仪表的功能进行修改和扩充,只需要修改该虚拟仪表的程序代码,编译连接生成新的DLL。用新的DLL替换原有的DLL文件即可。

4 结束语

虚拟仪表盘 篇5

本文介绍一种能够应用在WinCE设备平台的OBD汽车虚拟仪表设计方案。

1 需求分析与总体设计

OBD系统能够输出汽车ECU (Electronic Control Unit) 电子控制单元通过车载传感器获得的燃油系统、温度系统、点火系统、动力系统以及废气控制辅助装置系统运行状态数据, 在发生故障的情况下则输出故障码。

硬件设计方面, 设计了以ELM327为主控芯片的硬件连接电路和以PL2303芯片为主控芯片的电平转换电路, 扩展OBD接口的功能, 与O B D接口通信, 解析报文数据流, 将OBD接口输出信号转换为WinCE平台设备能够识别的信号并输入。

软件设计方面, 本文具体阐述了在WinCE SDK环境下开发的设计方案。采用模块化的设计方法, 将虚拟仪表软件分为通信初始化模块、OBD数据解析模块、计算与显示模块进行设计和研究, 实现了将发动机状态、发动机转速、当前时速、剩余油量、发动机温度等行车信息在WinCE平台上以汽车虚拟仪表图形显示。

2 硬件连接器设计

2.1 连接器设计

连接器的作用时信号转换, 因为系统终端与ECU的通信码均为串口信号, 只是与RS-232标准串口信号的电压不同, 标准串口信号的“1”用-12V表示, “0”用+12V表示, 而K线的“0”用0~1.3V表示, “1”用12V表示, 所以需要设计一块转换卡, 把K线的串口信号转换为标准的串口信号, 即可实现利用计算机串口来读取嵌入式系统终端与E C U的通信码。转换卡除了能完成电平转换功能外, 工作频率要大于10kHz, 且输入电阻要大, 不至于影响嵌入式系统终端与E C U的通信。采用转换卡截码的效率很高, 每次截码得到的文件也较小, 约1Kbytes。基于ELM327的连接器组成框图如图1所示。

2.2 电平转换

USB作为一种新的PC机互连协议, 使外设到计算机的连接更加高效、便利.这种接口适合于多种设备, 不仅具有快速、即插即用、支持热插拔的特点, 还能同时连接多达127个设备, 解决了如资源冲突、中断请求 (IRQs) 和直接数据通道 (DMAs) 等问题。因此, 越来越多的开发者欲在自己的产品中使用这种标准接口。而RS-232是单个设备接入计算机时, 常采用的一种接入方式, 其硬件实现简单, 因此在设计的时候考虑将RS232信号转换成USB信号, 电路实物图如图2所示。

如图2:ELM327内驻一个多路低导通电阻模拟开关组成的供电-测量电路网络、12bit逐次逼近A/D转换器和异步串行数据输入输出, ELM327根据微控制器发来的不同测量命令导通相应的模拟开关, 以便向OBD电极对提供电压, 并把相应电极上的触点坐标位置所对应的电压模拟量引入A/D转换器, X+、Y+、X-、Y-为O B D电压输入;CS为ADS7843的片选输入信号, 低电平有效;DCLK接外部时钟输入, 为芯片进行A/D转换和异步串行数据输入/输出提供时钟;DIN串行数据输入端, 当CS低电平时, 输入数据在时钟的上升沿将串行数据锁存;DOUT串行数据输出端, 在时钟下降沿数据由此移位输出, 当CS为高电平时, DOUT呈高阻态。BUSY为系统忙标志端, 当C S为低电平, 且B U S Y为高电平时, 表示ELM327正在进行数据转换;VREF参考电压输入端, 电压值在+1 V到+V C C之间变化;PENIRQ为笔触中断, 低电平有效;IN3、IN4为辅助ADC转换输入通道;+VCC为电源输入。

按照图2示电路, ELM327完成一次数据转换需要与O B D进行3次通信, 第一次微处理器通过异步数据传送向E L M 3 2 7发送控制字, 其中包括起始位、通道选择、8/1 2位模式、差分/单端选择和掉电模式选择, 其后的两次数据传送则是微控制器从E L M 3 2 7取出1 6 b i t A/D转换结果数据 (最后四位自动补零) , 每次通信需要8个时钟周期, 完成一次数据转换共需24个时钟周期。

3 虚拟仪表软件设计

软件设计平台选用Visual Studio20085构建的开发平台[4]。采用模块化的设计方法, 主要核心模块是通信模块和OBD报文解析模块。

3.1 通信模块

通信初始化模块功能是通过连接器实现OBD插座与WinCE平台设备的互联, 打开USB通用串行端口, 代码如下:

3.2 OBD报文解析模块

报文解析模块是虚拟仪表的核心, 以OBD报文组成为基础定义其主要工作流程图如图3所示。

4 工程实测

选用相应设备, 虚拟仪表成功读取汽车动力系统的发动机状态、转速、温度、行驶速度、存油量等参数信息并显示, 显示结果和汽车仪表盘完全一致, 达到设计的预期目的。 (如图4)

5 结语

本论文设计的汽车虚拟仪表设计方案能够读取汽车动力系统的发动机状态、转速、温度、行驶速度、存油量等参数信息并显示。在今后的工作中, 还可以开发车载多功能信息系统, 为驾驶员提供更多的行车服务。

参考文献

[1]Salvatore Cavalier.Meeting Real-TimeConstraints in CAN[C].IEEE Trans-actions On Industrial Informatics, 2005, 1 (2) .

虚拟仪表盘 篇6

仪表作为汽车整个系统中十分重要的部分, 是提高汽车综合性能的重要方面之一。随着计算机软硬件技术、总线技术、电子技术等的快速发展, 控制系统臃肿、接线布线复杂、占用空间大的传统电磁机械仪表渐渐被淘汰, 虚拟仪表正以传统机械仪表无法比拟的速度迅猛发展[1]。目前虚拟仪表通常包括纯数字仪表和虚拟仪表盘仪表2种:纯数字仪表成本较低, 但功能和界面比较简单, 满足不了一般驾驶员的需求;而现有的虚拟仪表盘仪表虽然功能和界面比较丰富, 但又存在着开发成本高、可移植性和可重绘性差、可扩展性不足等缺点, 不利于大范围的推广与应用[2,3]。

针对传统仪表和现有仪表存在的不足, 本文提出了一种新型的车载虚拟仪表设计方案, 采用ARM处理器S3C6410为核心的硬件平台和以嵌入式Linux系统为核心的软件平台, 并在此基础上采用开放源代码的图形界面库QT开发仪表终端应用程序。该虚拟仪表可读性好, 读数精度高, 在可移植性、可维护性和成本方面都得到了良好的改善, 具有较大的科研价值和商业使用价值。

1 系统总体设计

本文所介绍的车载虚拟仪表的基本设计思想是将汽车上安装的各种传感器采集到的数据进行智能化的处理, 然后在运行于嵌入式Linux系统的使用QT设计的虚拟仪表盘上进行显示, 以便于监测汽车各系统的工作状况, 如剩余油量、当前车速、行驶里程等, 并在某状态出现异常或存在危险时向驾驶员提示报警。

如图1所示, 本车载虚拟仪表系统的设计总体由3个部分组成:

(1) 信号采集:对汽车上安装的的各种传感器采集的速度、剩余油量等汽车状态信息, 经过处理转换后, 将其转换为计算机可以识别的数字量;

(2) 数据处理:将“信号采集”过程传输来的数据进行必要的处理, 将有用的数据保存, 以便于显示和报警, 本过程主要由嵌入式处理器完成;

(3) 人机交互:将“数据处理”过程处理完成的数据, 在使用QT设计的虚拟仪表盘上动态显示, 主要显示内容有:当前速度、燃油箱的存油量、时间日期、行驶里程、报警灯等;在某项状态出现异常时, 通过报警模块向驾驶员提示报警。

2 虚拟仪表硬件设计

虚拟仪表的硬件结构图如图2所示。虚拟仪表的核心处理器采用ARM1176JZF-S核的S3C6410芯片, 其主频最高可达到667 MHz, 内部继承了强大的多媒体处理单元, 带有3D图形硬件加速器, 并支持2D图形图像的平滑缩放等操作, 有利于为用户提供高灵敏度的汽车状态动态显示;外接256 MB SDRAM和2 GB NANDFLASH;串口连接信号转换处理模块, 转换处理模块内部集成CAN-RS232转换器及24位的A/D转换器LTC2414, 接收相关传感器采集的各种汽车状态信号, 并经过处理后, 将处理完成的数据上传至处理器;外接LCD模块采用8寸TFT液晶显示屏, 处理器内部集成的LCD控制器信号线经过驱动电路后即可连接LCD模块, 为虚拟仪表显示提供了硬件平台;外接由语音芯片组成的报警模块, 在必要的时候可以由处理器驱动报警模块以语音的形式向驾驶员提示报警。

3 虚拟仪表软件设计

本系统采用嵌入式Linux作为操作系统, 在Linux平台下编写虚拟仪表的驱动程序和应用程序, 采用QT/embedded设计虚拟仪表软面板。应用程序的主要功能有, 当接收到各个经转换处理的传感器采集到的信号后, 将其有用的数据提取并加以存储, 然后调用仪表显示程序, 将需要显示的内容显示到不同的虚拟仪表盘中, 同时并行判断各项参数是否正常, 若出现异常则调用语音报警程序和显示程序提示报警。虚拟仪表软件结构图如图3所示。虚拟仪表软件开发主要有2个内容:开发环境的搭建、虚拟仪表应用程序的设计[4]。

3.1 开发环境的搭建

为了开发满足功能的应用程序, 本文采用的软件开发环境是Vmware WorkStation 7虚拟机和Fedora 13操作系统, 在此环境中安装交叉编译器ARM-linux-gcc 4.5.1, 用来完成包含相关驱动程序的虚拟仪表系统内核、QT库和应用程序的编译;编译安装QT/Embedded库, 用来支持虚拟仪表人机交互界面程序的开发并生成虚拟仪表系统中需要的QT库文件;编译Tslib触摸屏库, 为虚拟仪表系统添加触摸屏支持;在Fedora13系统中安装QT Creator软件, 用于完成虚拟仪表系统应用程序的开发;移植嵌入式设备的系统引导程序U-boot;编写硬件平台相关驱动[5], 然后裁剪编译Linux2.6.10内核并在其中加载已编译的相关驱动[6];制作硬件平台需要的根文件系统, 在其中移植已配置、编译过的tslib库和QT/Embedded库[7]。

3.2 应用程序开发

本虚拟仪表系统的的应用程序基于QT/Embedded平台, 使用QT的轻量级集成开发环境QT Creator完成开发, 最后在已搭建的开发环境中编译生成可执行二进制文件, 并将其移植到硬件平台中的文件系统中进行测试。

虚拟仪表系统应用程序的主要工作流程如图4所示, 在系统上电后, 应用程序开始运行, 要实现汽车虚拟仪表系统的功能, 应用程序需要完成虚拟仪表面板和后台处理程序的开发:

3.2.1 虚拟仪表面板的绘制

虚拟仪表面板主要将汽车的一些基本状态在LCD上通过表盘和数字直观、动态的显示出来, 本设计中采用速度、油量、电池电量、时间日期、安全带、安全气囊、行驶里程等状态。

为了提高本虚拟仪表的可扩展性和可维护性, 在本设计中, 为每种具体的虚拟仪表对象定义一个抽象类。下面即以仪表盘类 (QMeter) 为例介绍本系统中虚拟仪器面板的绘制。

在需要显示的各种状态中, 速度和油量通常以仪表盘形式显示, 虚拟仪表模块中的虚拟仪表盘采用QT的二维图形引擎的基础类QPainter开发。QPainter具有丰富的图形图像绘制函数, 并支持反走样、渐变填充、像素混合、线性变换等特性, 利用这些函数完成仪表盘的绘制[8,9]。

3.2.2 后台处理程序

后台处理程序主要将系统下层采集的数据进行分析处理, 将有用的数据传送至虚拟仪表面板显示, 实现虚拟仪表的动态显示, 同时以多线程的方式不断检测汽车各项状态, 当某项状态出现异常或存在危险时驱动LCD和语音芯片向驾驶员报警[10], 其中异常状态有超速、存油量过低、电池电量过低等。下面以报警子程序为例讲解后台处理子程序。

报警子程序在后台处理程序中新建一个线程, 通过多线程的方式以轮询的方式查询各个传感器的状态, 当发现某个状态存在危险时, 驱动语音芯片发出相应的报警信息。其定义如下:

QT特有的信号与槽 (signal/slots) 机制实现方式如下:

connect (m_thread, SIGNAL (sendData () ) , this, SLOT (Deal () ) ) ;

通过调用QObject对象的connect函数, 将报警线程的sendData信号与主线程的槽函数Deal () 关联, 当报警侦听线程发射信号时, 主线程槽函数及时被调用, 驱动报警。

4 应用程序示例

将裁剪、编译过的内核与制作的带QT库的文件系统烧写到开发板。在开发环境内交叉编译编写的应用程序, 得到可执行二进制文件, 将此文件移植到开发板, 即可实现应用程序的发布。重新开机, 运行应用程序即显示虚拟仪表界面, 如图5所示。

通过汽车上的各种传感器采集数据, 通过控制器和高速CAN总线传送到S3C6410硬件平台解析, 应用程序得到解析后的数据后, 即可动态的显示当前车辆的各种状态及报警情况。

5 结语

本文设计的汽车虚拟仪表, 具有优良的跨平台性能;该设计方案使得仪表信息量增大, 操作简单, 易于维护, 界面友好;采用开放源码设计, 使得本系统开发成本降低;使用双缓冲技术消除了仪表显示页面的闪烁;采用多线程技术, 使处理、显示与报警同时进行, 提高了系统的实时性与灵敏度;将具体的虚拟仪表对象定义为抽象类, 增强了虚拟仪表的扩展性。经实验测试, 本虚拟仪表系统的所有功能模块均能正常运行, 该系统的应用将对降低汽车的成本, 缩短汽车仪表系统的研发周期提供高友好度的人机界面具有重要的意义

摘要:为了简化汽车内部控制系统, 降低汽车制造成本, 提高人车交互界面的友好度, 设计并实现了一种新型的汽车虚拟仪表。采用以ARM处理器S3C6410为核心的硬件平台和以嵌入式Linux系统为核心的软件平台, 并在此基础上采用开放源代码的图形界面库QT开发仪表终端应用程序。经试验验证, 虚拟仪表系统具有成本较低、界面友好、反应灵敏等特点, 并在跨平台性、可扩展性等方面得到了显著改善。

关键词:汽车,虚拟仪表,嵌入式Linux,QT,ARM

参考文献

[1]陈丽, 陈焱焱.基于VC++6.0的虚拟汽车数字仪表盘的设计[J].电脑开发与应用, 2009, 22 (8) :29-31.

[2]涂天佳, 王见, 秦树人.跨平台的虚拟仪器开发研究与实现[J].中国测试, 2010, 36 (5) :55-58.

[3]程兴亚.基于嵌入式系统的虚拟仪器设计[J].微计算机信息, 2004, 12 (20) :63-65.

[4]胡志文, 张崎.基于嵌入式Linux的自助点菜终端设计[J].现代电子技术, 2011, 34 (4) :14-16.

[5]CORBET J, RUBINI A, KROAH-HARTMAN G.Linux设备驱动程序[M].北京:中国电力出版社, 2005.

[6]BOVET P D, CESATI M.深入理解Linux内核[M].北京:中国电力出版社, 2007.

[7]韦东山.嵌入式Linux应用开发完全手册[M].北京:人民邮电出版社, 2008.

[8]BLANCHETTE Jasmin, SUMMERFIELD Mark.C++GUIQT4编程[M].北京:电子工业出版社, 2008.

[9]蔡志明, 卢传富, 李立夏.精通QT4编程[M].北京:电子工业出版社, 2008.

[10]李青松, 周晓光, 周慧玲.基于QT的工程机械监控和诊断系统的设计与实现[J].计算机与信息技术, 2011, 13 (12) :3-5.

[11]石春虎, 曲红星, 陈雷.直升机虚拟仪表DLL设计与实现[J].电子科技, 2011 (5) :104-107.

【虚拟仪表盘】推荐阅读:

虚拟仪表08-31

市场仪表盘09-07

仪表设计07-19

电力仪表05-29

仪表选择06-08

仪表总线08-06

仪表发展08-10

仪表开发08-24

自动仪表08-25

校验仪表09-05

上一篇:文物与文化的关系下一篇:数字加密