嵌入式电子飞行仪表系统的软件结构与实现.docx

《嵌入式电子飞行仪表系统的软件结构与实现.docx》由会员分享，可在线阅读，更多相关《嵌入式电子飞行仪表系统的软件结构与实现.docx（12页珍藏版）》请在优知文库上搜索。

1、嵌入式电子飞行仪表系统的软件结构与实现北京航空航天大学电子信息工程学院39020818徐广毅电子飞行仪表系统（EIeCtrOniCFlightInstrumentSystem）下列简称EFIS为了实现基于嵌入式电子飞行仪表系统的数据综合显示，我们选取了基于IntelStrongARM1110的JingWei开发平台，进行核心部分包含数据接收，解码，综合计算与综合显示，与黑匣子部分的数据记录的软件开发。为了缩短开发时间，降低开发难度，我们在操作系统的选取上使用了Microsoft公司优秀的嵌入式操作系统WindowsCE3.0o开发工具选用了EmbeddedVisualC,结合JingWei的S

2、DK与PIatformBuiIder进行整个硬件平台上软件部分的设计与开发。飞机上各路传感器的数据通过我们所设计的综合数据采集系统的采集后，通过串口编帧发送，JingWei通过串口1接收到数据后进行解码与校验，将正确的数据后通过系列的计算后，调用绘图函数以图形方式综合显示在彩色LCD上。另外，所同意到的数据还会储存在我们所设计的固定格式的二进制文件中，储存在JingWei的SDRAM中实现黑匣子部分的数据记录，借助我们所开发的基于X86系统的黑匣子回放软件，能够分析回放黑匣子的储存数据。在软件上，PIatformBuiIder关于专有硬件平台的操作系统的定制与裁减，EmbeddedVisual

3、C+关于系统平台上应用软件的开发均提供了极大的便利，CPU的强大的数据处理能力，彩色LCD显示屏的综合图形显示，也为整个以显示为核心的系统提供了充分的保证。关于EFIS系统的扩展部分，诸如VFR（虚拟飞行法则）与ILS（仪表着陆系统）与EFIS系统的结合等，由于时间紧迫，任务繁重，都只在理论上与实验中实现，并没有真正加入到系统中。软件系统方案论证1 .操作系统方案一百心的操作系统部分选用开放源码的UCLinUX来实现，我们能够直接修改系统的源码，通过裁减后直接编译出自己的Linux内核，接着基于这个系统来设计开发应用程序部分。这样的工作量无疑是非常大的，关于UCLinUX操作系统的陌生与整个开

4、发时间的安排与核心的EFIS部分的工作量使我们在这个平台上的计划止步，Linux下不是十分便利的开发环境也限制了我们的能力。因此，本设计没有使用这个方案。方案二操作系统选用MicrosoftWindowsCE3.0。MicrosoftWindowsCE3.0在众多的嵌入式操作系统的平台中一直比较优秀。WindowsCE是支持多平台的可定制的嵌入式操作系统，尽管在图形界面上与WindoWSX86家族系列长得很像，让人们误以为是WindowsX86平台的移植产品。但在实际上，WindowsCE的代码全部是重新设计并编写的。它同样支持多线程，完全抢先执行与多任务的操作系统。系统在设计上使用完全的模块

5、化结构，非常有利于裁减与编译。另外，完备的驱动程序与便利的开发环境IDE也非常有利于我们在限期内设计开发出我们所制定的较为完整的EFIS系统的目标。基于WindowSCE的应用程序Shell模块附加技术对象存储:文件系统图形句柄窗口句柄事件句柄数据库注册表通讯模块设备管理模块OEM层OEM适配层本地设备驱动数据流接口驱动基于WindoWSCE的目标设备图一MicrosoftWindowsCE系统配置及基本组织图使用PIatformBuiIder3.0结合适用于JingWei的bsp包，外加模块的裁减编译后导出适合开发应用程序的SDK,使用EmbeddedVisualC+便能够开发编译出在这个平

6、台上运行的软件。将我们所开发的软件与操作系统直接编译成为一个镜像文件，通过JTAG口烧写进JingWei的Hashrom便实现嵌入式系统的软件硬件化。2 .开发环境选择好了操作系统平台之后，所要做的便是如何选择应用软件的开发环境，摆在我们面前有两个方案：方案一使用EmbeddedVisualBasic。使用Platformbuilder能够输出EVB使用的SDK,EVB的开发环境相对直观简洁，开发难度相对较小，但是编译生成的目标代码过于繁琐，编译效率相对较低，程序运行速度较慢。关于EFlS实时显示各项数据的要求完成的并不是非常好，在熟悉过EmbeddedVisualC+之后，我们放弃了这个方案

7、。方案二应用程序开发使用EmbeddedVisualC+结合SDK使用API函数直接编写WIN32程序的方式进行编码，这点不仅大大提高了编译效率，减小了目标程序的大小，C同时也具备强大的开发底层设备驱动的能力，程序执行速度更快，更加符合嵌入式系统实时性的高水平要求。当我们自行裁减WindOWSCE模块到处SDK后，很多的MFC类库所封装的函数将不可能被包含在SDK中，因此我们放弃了MFC直接使用API编写。另外，使用APl方式编码所编译出的代码会更加的精简。设计与论证1 .系统镜像档的设计EFIS系统中关于图形的要求很高，GDI函数支持这部分必不可少。关于黑匣子功能的实现在JingWei平台上

8、是依靠于可靠的文件系统。关于通讯部分又是整个系统数据传输的主干。因此综合了以上的模块后，我们在PlatformBUilder中选择了MAXALL的最小配置，包含了用户图形接口GUI与文件系统。在基于JingWei的BSP包上，选取TCom1,DiSPIay与ToUChPad的驱动模块，结合我们的应用程序部分作为用户模块，将整个系统编译为了一个单独的镜像档。我们修改了这个系统的文件结构与程序的分布位置，构造出了应用于这个平台固化代码的应用程序。实现了系统复位或者者重新加电后能够迅速进入EFIS系统的目的，无需任何人工干涉。实现了简单的固化与专有。另外,在不断的试验中，我们发现导致JingWei死

9、机的很大一部分因素便是Explorer.exe,为了突出图形的显示部分，我们在初始注册表中将这部分去掉没有编译进镜像。死机状况大大的减少了。最终生成的镜像文档为NK.bin用户模块驱动模块系统内核JingWeiBoardSupportPackagePLatFrom BuilderJingWei-NKBIN图2NK.bin镜像构成图2 .EFIS系统软件框架设计系统的主干部分为数据的通讯与显示。在飞行员的反映时间内要比较好的解决实时数据流的通讯与以一定精度的显示问题。在人眼可察觉的范围内尽量做到快速的刷新屏幕，保持当前显示数据最新，实现实时准确的形象显示。在系统资源非常有限的状况下，我们要解决在

10、保证数据通讯的精度与速度的基础上,尽量提高显示刷新速度这样一个问题。刷新速度制约了整个系统的数据的采集频率与显示效果：刷新的速度过于缓慢，不仅在视觉上产生了明显的停滞感，而且大大的制约了数据显示的实时性。在显示速度与整个系统的通讯速度之间找到一个比较合适的分割点，是我们在设计EFIS所追求的实际目标，也是整个系统能否使用的关键所在！在我们的系统中，包含GPS(GlobalPositioningSystem)卫星所提供的定位信息(包含友机在内)与本机近19路飞行参数等在内的所有资料的综合显示务必将整个系统的综合报警系统完美的结合进来。作为飞行员，他们所关注的往往直接的视觉信息，因此使用综合的仪表

11、显示始终要作为主导，因此在飞行员以飞行经验来推断当前飞行参数是否处在警戒范围并由此做出推断之前，我们的警报系统就务必对这些参数加以推断并将推断结果直接的在第一时间内显示出来。鉴于飞行任务的多样性,我们不能将整个警报系统的推断参数固化进程序，务必实现给飞行员的不一致设定预留出统一的动态接口，使飞行员能够随时设置而不必重新编译系统。整个系统的软件功能模块框图如下:SoftwareFremWQrk图3EFIS软件部分功能与作业框图EFIS系统的软件功能实现框图方案如上图所示，作为中心部分的图形显示始终占据在主导地位，围绕着这点，将所有的功能划分为四大模块：1 .数据通讯接口。2 .预警规则与图形警报

12、。3 .实时综合显示模块。4 .黑匣子数据采集记录模块。作为外部数据源与驱动图形动态显示的通讯接口部分，在系统的软硬件衔接部分中起着关键的桥接作用。尽管数据以比较快的速度2730Bps（共10帧数据）的速率实现实时的将飞行参数传递进中央处理计算机的功能，但图形的刷新往往只能显示其中的6帧到7帧，尽管飞行员能够忍耐这种速度，勉强能够满足实时显示的要求，但是这给航空黑匣子的数据记录带来了一点点的烦恼，由于航空事故的整个过程关键部分只有几秒钟,因此将飞行数据以等同于接口通讯速率的速度记录下来是作为黑匣子所务必要实现的。也就是说我们在图形显示中忽略掉的那部分数据在黑匣子中将会完整的保留下来。数据通讯与

13、接口部分实现了由通讯接口读入编码数据,将数据译码为我们所规定的有效的通讯格式后，转换成可供计算机程序直接调用的变量值等功能。作为原始的数据格式，我们将读入的数据通过程序直接操纵为有效格式后，存储入文件中。将帧格式数据做有效的转换，存储在全局对象中为其它的模块调用实现了飞行数据显示的通用接口。一旦成功的实现了软件与硬件通讯部分，飞机的飞行参数就已经成功的采集到了计算机,有了这些飞行资料，便有了实现图形显示的最根本的基础。关于数据通讯的全面介绍请参看嵌入式电子飞行仪表系统的通讯接口一文。数据被分为16种，包含在GPS定位与群体飞行的导航数据在内的所有有效数据，在实时显示的同时，还要通过警报模块来检

14、测其是否处于危险范围来将不一致的警报位置位，在综合显示中不仅实现了飞行参数的综合显示实时更新，另外还要将警报位中不一致等级不一致内容的警报以一种直观的图形形式显示出来，在第一时间内向飞行员报警。发动机参数在达到最低警戒范围内的时候就已经极有可能引起一定程度的飞行故障,但其在前几分钟内的参数往往呈现某种走势，因此有必要提供在近几分钟内的发动机参数趋势图。将数据作为队列形式存储后显示出来。由于通过接口的转换后的数据是符合整形或者者浮点的形式的结构，因此在封装单帧数据后，在图形模块直接调用数据对象的指针，便能够将当前的飞行参数实时的加以显示，警报系统加以实时的推断。关于n分钟内的采样模块来讲，也能够

15、通过这点实现数据的队列存储。整个系统中的几大关键模块：数据通讯模块，数据滤波模块，警报检测模块，图形显示模块等，彼此之间都是透明的，每种模块通过消息循环处理函数联系在一起。这就为软件部分的分工合作，调试检错带来了方便。因此，前期的模块划分与需求分析，关于加快系统的开发速度，减少错误查找的时间与难度等众多方面起着比较明显的作用。整个应用程序是建立在消息映射与消息传递的基础上的。各类不一致的系统消息我们能够选择不一致的处理方式：能够忽略，或者者编写处理函数进行处理。我们所设计的EFlS系统是建立在关于数据的不断采样，不断显示的功能之上。因此，设置定时器向系统不断的发送定时消息便能够做到每隔一段时间

16、做一件情况。这便是不断刷新的原理所在。下图为整个程序运作的原理示意。程序开始对象锄蛤化消息偏味:图4程序运行原理示意：消息的循环与映像关于处理不一致的消息，我们使用不一致的函数，各类不一致的消息的传递中还会包含了WPARAM与LPARAM的参数。另同类消息的不一致处理带来了方便之处。Timer消息贯穿在整个程序的初始到结束一在Create与DeStroy之间。只要不退出程序的运行，定时器就会一直运作。这就首先保证了数据与图形的实时刷新。另外，在每一时刻确定了各传感器工作正常之后，我们便得到了该时刻唯一的一组参数值，这些参数唯一的确定了飞机的飞行状态，在比较快速的采样中，即使飞机正在做幅度比较大的动作，前后几个数据样本的有关性也是非常大的，因此不断的采样-不断的刷新，我们看到的便是一个连贯的参