《嵌入式电子飞行仪表系统的软件结构与实现.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之间。只要不退出程序的运行，定时器就会一直运作。这就首先保证了数据与图形的实时刷新。另外，在每一时刻确定了各传感器工作正常之后，我们便得到了该时刻唯一的一组参数值，这些参数唯一的确定了飞机的飞行状态，在比较快速的采样中，即使飞机正在做幅度比较大
17、的动作，前后几个数据样本的有关性也是非常大的，因此不断的采样-不断的刷新，我们看到的便是一个连贯的参数表达。这便是连续显示的原理所在。在响应Timer消息的处理函数中设计采集数据，检查数据，显示数据的代码，便是实现整个综合资料采样与显示的真正奥秘。由于航空事故调查中的黑匣子数据所需的单位时间内之采样样本数要高于我们显示的刷新速度，故不能在同一个Timer消息的处理中应付数据流的存储工作。故黑匣子功能务必单独在通讯前端进行处理。关于黑匣子的全面介绍请参看嵌入式电子飞行仪表系统的通讯接口。3.图形显示的架构设计在嵌入式EFIS系统的应用开发过程中，摆在我们面前的问题便是：1 .提高代码的编译效率，
18、尽量缩小目标代码的大小2 .提高代码的执行速度，在固定的时间与画面复杂度的范围内提高画面的更新速度。3 .保障系统的稳固性。防止资源泄漏等错误的发生在整个系统的设计过程中我们已经考虑到了以上几个问题。提高代码的编译效率，缩小目标代码的大小意味着在一定程度上关于系统软硬件资源的充分节约，关于实现系统实时与稳固均有一定的保证。便于错误的处理。提高代码的执行速度则意味高效快速的完成数据采集，处理，显示，存储等一系列繁杂的任务，本身EFIS关于数据的通讯速率与整个系统数据处理能力要求较高，大量的运算时间将花费在图形显示之上，作为图形显示部分的程序设计一定要满足尽量有效的利用有限的资源，在保证实时的基础
19、上完成显示复杂图形的目标。保证系统运作的稳固性一方面要在硬件上做足功夫，另外一方面要在软件上保证没有任何内存资源泄漏导致系统崩溃的情况发生，。考虑到整个JingWei平台不能使用微软的图形加速接口DirectDraw进行图形程序的设计编码，因此只能使用JingWei所支持的基本GDI设备函数进行绘图。作为GDI设备,直接调用其设备句柄进行繁杂的绘图操作是很慢的，同时显示效果会由于一次次的调用中断而使画面变得闪烁刺眼，解决的方法便是使用贴图缓存，整个的贴图区务必事先在内存中创建好，作为与系统GDl设备兼容的缓存设备的句柄，我们能够直接调用进行绘图的操作，由于在缓存中的操作速度要远远高于在GDl设
20、备上直接操作的速度，当完成一次的绘图后，将整个的缓存映射到GDI设备上，便完成了一次向GDI设备的绘图操作，能够非常有效的消除往常的闪烁现象。整个绘图过程的瓶颈在于我们所创建的缓存区域的大小，区域过大会减慢缓冲映射的速度。在能够正确实时的表达飞行参数的前提下，我们最终确定了基本的动态绘图区为240*240。同时初步测试了我们所需的复杂图形在这个分辨率下刷新一次所需要的时间为130ms左右。整个LCD余下的80个PiX作为屏幕切换按钮与其它信息静态显示用，只在初始化时刻进行绘图。4 .飞行画面的国计PFD（主飞行画面）PFD画面的设计涵盖了模拟与数字信号的大多数信息：航向角，飞行姿态，空速，与高
21、度等等。画面同样设计了一个虚拟的水平面所呈现的地平线，飞行员从当前画面中央的虚拟机与水平线的显示上能够非常形象的获得当前飞机的飞行姿态等具体参数。主飞行画面例图如下：EAU（发动机/空气数据单元）EAU单元的画面的设计使用了传统的图形方式-一表盘指针式。为了让飞行员在第一时间内得到重要的发动机参数同时获知马上发生的警报，我们在显示过程中将当心/警告的表示方法结合进了表盘设计中，下图为EAU单元的显示画面。ND（NavigationDisplay）导航显示画面导航显示画面的图形设计与表达方法使用了当前的通用方式。正中心的电子罗盘要紧指示了当前飞机所飞行的磁航向角。我们在设计时候选择了惯用方式进行
22、表达。GPS定位及友机信息显示画面在我们所设计的EFIS系统中包含了全球卫星定位的显示部分，正如前所说本机的GPS信号作为一个完整数据包包含了经度，纬度，地速等信息，在通过信号调配与数据收集后地编帧后，友机地资料也被编入了一格数据帧中，我们在设计中除了在左上角显示出本机的信息：经度，纬度，地速，距离目的地的距离。另外还在以本机为中心的位置同心圆上显示了友机的位置。相关于本机为参考点，上方永远指向本机当前所飞行的方向（磁航向角），在这个参考点基础上，存在3个同心圆，同心圆的半径之比为1：2：4,也就是说在相同的比例尺下，假如最小的半径为10公里时，最外面的大圆表示了当前以本机为中心40公里半径内
23、范围。当友机与本机的距离小于这个距离时，友机相关于本机的位置便能够在这个圆内显示出来，为了方便观察，我们在大圆上设计了北向标志，便于另外的方式进行观察。关于友机当前的GPS信息我们设计了锁定显示，通过飞行员的操作（直接点击位于大圆内显示的友机标志）就能够非常方便的锁定机群中的某架，如今友机的颜色会发生变化，在右边也会显示出友机的机群编号，当前位置，对地速度等信息。锁定观察的容量只有2架，当需要锁定第3架飞机的时候，已经锁定的第1架就会被解除锁定状态，整个的锁定顺序为队列(FlFO)方式。下图是一个非常典型的GPS定位及友机信息显示画面。OEST 33.3GS33.44LOCK 1pKT：Hei
24、ght=p_SWS-HeightUpLimit)当前参量与警报参量对比p_SWF-f_Height=1;表示当前高度大于设定的最大高度的时候，将相应警戒位置位，其余逻辑类似。关于警戒参量的设计是灵活的。我们在设计中考虑到了不一致的飞行任务中会有不一致的要求，举例来讲，同样的飞机执行一次飞行任务，当这个任务是在城市上空盘旋拍照的时候就与另外的一次飞跃喜马拉雅山脉的任务所应设定的最低可同意飞行高度确信是不一样的。这部分的参量值是不能够固化在系统内不可改变的。我们务必给飞行员提供一个能够随时改变的接口。我们最终为这部分的接口设计了INl初始化配置文件的方法进行处理。INl文件的读取与写入算法很多，大都是与字符搜索有关的。我们在这里单独设计了一套比较简单的处理方法，按照我们所事先规定的行数写入当前参量值。比如：1HeightUpLimit=20000;表示第一行的参量高度限制为20000米，每行以分号与回车字符作为结束符号。在读取时候按照此规则便可读入相应的参量值，通过字符到浮点数据转换便实现了数据的读入。
