《嵌入式电子飞行仪表系统的软件结构与实现》由会员分享，可在线阅读，更多相关《嵌入式电子飞行仪表系统的软件结构与实现（11页珍藏版）》请在金锄头文库上搜索。
1、 - 1 -嵌入式电子飞行仪表系统的软件结构与实现北京航空航天大学电子信息工程学院39020818 徐广毅电子飞行仪表系统(Electronic Flight Instrument System) 以下简称 EFIS为了实现基于嵌入式电子飞行仪表系统的数据综合显示，我们选取了基于 Intel StrongARM 1110 的 JingWei 开发平台，进行核心部分包括数据接收，解码，综合计算和综合显示，以及黑匣子部分的数据记录的软件开发。为了缩短开发时间，降低开发难度，我们在操作系统的选取上采用了 Microsoft 公司优秀的嵌入式操作系统 Windows CE 3.0。开发工具选用了 Em
2、bedded Visual C，结合 JingWei 的 SDK 与PlatformBuilder 进行整个硬件平台上软件部分的设计和开发。飞机上各路传感器的数据经过我们所设计的综合数据采集系统的采集后，通过串口编帧发送，JingWei 通过串口1 接收到数据后进行解码和校验，将正确的数据后通过系列的计算后，调用绘图函数以图形方式综合显示在彩色 LCD 上。另外，所接受到的数据还会保存在我们所设计的固定格式的二进制文件中，保存在 JingWei 的 SDRAM 中实现黑匣子部分的数据记录，借助我们所开发的基于 X86 系统的黑匣子回放软件，可以分析回放黑匣子的保存数据。在软件上，Platfor
3、mBuilder 对于专有硬件平台的操作系统的定制和裁减，Embedded Visual C+对于系统平台上应用软件的开发均提供了极大的便利，CPU 的强大的数据处理能力，彩色 LCD 显示屏的综合图形显示，也为整个以显示为核心的系统提供了充分的保证。对于 EFIS 系统的扩展部分，诸如 VFR（虚拟飞行法则）与 ILS（仪表着陆系统）和EFIS 系统的结合等，由于时间紧迫，任务繁重，都只在理论上和实验中实现，并没有真正加入到系统中。软件系统方案论证1 操作系统方案一 核心的操作系统部分选用开放源码的 uc Linux 来实现，我们可以直接修改系统的源码，经过裁减后直接编译出自己的 Linux
4、 内核，接着基于这个系统来设计开发应用程序部分。这样的工作量无疑是非常大的，对于 uc Linux 操作系统的陌生和整个开发时间的安排以及核心的 EFIS 部分的工作量使我们在这个平台上的计划止步，Linux下不是十分便利的开发环境也限制了我们的能力。因此，本设计没有采用这个方案。方案二 操作系统选用 Microsoft Windows CE 3.0。Microsoft Windows CE 3.0 在众多的嵌入式操作系统的平台中一直比较优秀。Windows CE 是支持多平台的可定制的嵌入式操作系统，虽然在图形界面上和 Windows X86 家族系列长得很像，让人们误以为是 Windows
5、 X86 平台的移植产品。但在实际上，Windows CE 的代码全部是重新设计并编写的。它同样支持多线程，完全抢先执行和多任务的操作系统。系统在设计上采用完全的模块化结构，非常有利于裁减和编译。另外，完备的驱动程序和便利的开发环境 IDE 也非常有利于我们在限期内设计开发出我们所制定的较为完整的 EFIS 系统的目 - 2 -标。图一 Microsoft Windows CE 系统配置及基本组织图使用 PlatformBuilder 3.0 结合适用于 JingWei 的 bsp 包，外加模块的裁减编译后导出适合开发应用程序的 SDK，使用 Embedded Visual C便可以开发编译出
6、在这个平台上运行的软件。将我们所开发的软件和操作系统直接编译成为一个镜像文件，通过JTAG 口烧写进 JingWei 的 flashrom 便实现嵌入式系统的软件硬件化。2 开发环境选择好了操作系统平台之后，所要做的便是如何选择应用软件的开发环境，摆在我们面前有两个方案：方案一 采用 Embedded Visual Basic。使用 Platformbuilder 可以输出 EVB 使用的 SDK，EVB 的开发环境相对直观简洁，开发难度相对较小，但是编译生成的目标代码过于繁琐，编译效率相对较低，程序运行速度较慢。对于 EFIS 实时显示各项数据的要求完成的并不是非常好，在熟悉过 Embedd
7、ed Visual C之后，我们放弃了这个方案。方案二 应用程序开发使用 Embedded Visual C结合 SDK 使用 API 函数直接编写 WIN32 程序的方式进行编码，这点不仅大大提高了编译效率，减小了目标程序的大小， C 同时也具备强大的开发底层设备驱动的能力，程序执行速度更快，更加符合嵌入式系统实时性的高水平要求。当我们自行裁减 Windows CE 模块到处 SDK 后，很多的 MFC 类库所封装的函数将不会被包含在 SDK 中，因此我们放弃了 MFC 直接使用API 编写。另外，使用 API 方式编码所编译出的代码会更加的精简。设计与论证1系统镜像档的设计 - 3 -EF
8、IS 系统中对于图形的要求很高，GDI 函数支持这部分必不可少。对于黑匣子功能的实现在 JingWei 平台上是依赖于可靠的文件系统。对于通讯部分又是整个系统数据传输的主干。所以综合了以上的模块后，我们在 Platform Builder 中选择了 MAXALL 的最小配置，包含了用户图形接口 GUI 和文件系统。在基于 JingWei 的 BSP 包上，选取了 Com1，Display 和 Touchpad 的驱动模块，结合我们的应用程序部分作为用户模块，将整个系统编译为了一个单独的镜像档。我们修改了这个系统的文件结构和程序的分布位置，构造出了应用于这个平台固化代码的应用程序。实现了系统复位
9、或者重新加电后能够迅速进入 EFIS 系统的目的，无需任何人工干涉。实现了简单的固化和专有。另外，在不断的试验中，我们发现导致 JingWei 死机的很大一部分因素便是 Explorer.exe，为了突出图形的显示部分，我们在初始注册表中将这部分去掉没有编译进镜像。死机状况大大的减少了。最终生成的镜像文档为 NK.bin图 2 NK.bin 镜像组成图2EFIS 系统软件框架设计系统的主干部分为数据的通讯和显示。在飞行员的反映时间内要比较好的解决实时数据流的通讯和以一定精度的显示问题。在人眼可察觉的范围内尽量做到快速的刷新屏幕，保持当前显示数据最新，实现实时准确的形象显示。在系统资源非常有限的
10、状况下，我们要解决在保证数据通讯的精度和速度的基础上，尽量提高显示刷新速度这样一个问题。刷新速度制约了整个系统的数据的采集频率和显示效果：刷新的速度过于缓慢，不仅在视觉上产生了明显的停滞感，而且大大的制约了数据显示的实时性。在显示速度和整个系统的通讯速度之间找到一个比较合适的分割点， - 4 -是我们在设计 EFIS 所追求的实际目标，也是整个系统能否使用的关键所在!在我们的系统中，包括 GPS（Global Positioning System）卫星所提供的定位信息(包含友机在内) 以及本机近 19 路飞行参数等在内的所有资料的综合显示必须将整个系统的综合报警系统完美的结合进来。作为飞行员，
11、他们所关注的往往直接的视觉信息，所以使用综合的仪表显示始终要作为主导，因此在飞行员以飞行经验来判断当前飞行参数是否处在警戒范围并由此做出判断之前，我们的警报系统就必须对这些参数加以判断并将判断结果直接的在第一时间内显示出来。鉴于飞行任务的多样性,我们不能将整个警报系统的判断参数固化进程序，必须实现给飞行员的不同设定预留出统一的动态接口，使飞行员能够随时设置而不必重新编译系统。整个系统的软件功能模块框图如下：图 3 EFIS 软件部分功能和作业框图EFIS 系统的软件功能实现框图方案如上图所示，作为中心部分的图形显示始终占据在主导地位，围绕着这点，将所有的功能划分为四大模块：1.数据通讯接口。2
12、.预警规则和图形警报。3.实时综合显示模块。4.黑匣子数据采集记录模块。 - 5 -作为外部数据源和驱动图形动态显示的通讯接口部分，在系统的软硬件衔接部分中起着关键的桥接作用。虽然数据以比较快的速度 2730 Bps（共 10 帧数据）的速率实现实时的将飞行参数传递进中央处理计算机的功能，但图形的刷新往往只能显示其中的 6帧到 7 帧，虽然飞行员能够忍受这种速度，勉强能够满足实时显示的要求，但是这给航空黑匣子的数据记录带来了一点点的麻烦，因为航空事故的整个过程关键部分只有几秒钟，所以将飞行数据以等同于接口通讯速率的速度记录下来是作为黑匣子所必须要实现的。也就是说我们在图形显示中忽略掉的那部分数
13、据在黑匣子中将会完整的保留下来。数据通讯和接口部分实现了由通讯接口读入编码数据，将数据译码为我们所规定的有效的通讯格式后，转换成可供计算机程序直接调用的变量值等功能。作为原始的数据格式，我们将读入的数据通过程序直接控制为有效格式后，存储入文件中。将帧格式数据做有效的转换，存储在全局对象中为其它的模块调用实现了飞行数据显示的通用接口。一旦成功的实现了软件和硬件通讯部分，飞机的飞行参数就已经成功的采集到了计算机，有了这些飞行资料，便有了实现图形显示的最根本的基础。对于数据通讯的详细介绍请参看嵌入式电子飞行仪表系统的通讯接口一文。数据被分为 16 种，包含在 GPS 定位和群体飞行的导航数据在内的所
14、有有效数据，在实时显示的同时，还要经过警报模块来检测其是否处于危险范围来将不同的警报位置位，在综合显示中不仅实现了飞行参数的综合显示实时更新，另外还要将警报位中不同等级不同内容的警报以一种直观的图形形式显示出来，在第一时间内向飞行员报警。发动机参数在达到最低警戒范围内的时候就已经极有可能引起一定程度的飞行故障，但其在前几分钟内的参数往往呈现某种走势，因此有必要提供在近几分钟内的发动机参数趋势图。将数据作为队列形式存储后显示出来。由于经过接口的转换后的数据是符合整形或者浮点的形式的结构，所以在封装单帧数据后， 在图形模块直接调用数据对象的指针，便可以将当前的飞行参数实时的加以显示，警报系统加以实
15、时的判断。对于 n 分钟内的采样模块来讲，也可以通过这点实现数据的队列存储。整个系统中的几大关键模块：数据通讯模块，数据滤波模块，警报检测模块，图形显示模块等，彼此之间都是透明的，每种模块通过消息循环处理函数联系在一起。这就为软件部分的分工合作，调试检错带来了方便。因此，前期的模块划分和需求分析，对于加快系统的开发速度，减少错误查找的时间和难度等众多方面起着比较明显的作用。整个应用程序是建立在消息映射和消息传递的基础上的。各类不同的系统消息我们可以选择不同的处理方式：可以忽略，或者编写处理函数进行处理。我们所设计的EFIS 系统是建立在对于数据的不断采样，不断显示的功能之上。因此，设置定时器向
16、系统不断的发送定时消息便可以做到每隔一段时间做一件事情。这便是不断刷新的原理所在。下图为整个程序运作的原理示意。 - 6 -图 4 程序运行原理示意： 消息的循环与映像对于处理不同的消息，我们使用不同的函数，各类不同的消息的传递中还会包含了WPARAM 和 LPARAM 的参数。另同类消息的不同处理带来了方便之处。Timer 消息贯穿在整个程序的初始到结束在 Create 和 Destroy 之间。只要不退出程序的运行，定时器就会一直运作。这就首先保证了数据和图形的实时刷新。另外，在每一时刻确定了各传感器工作正常之后，我们便得到了该时刻唯一的一组参数值，这些参数唯一的确定了飞机的飞行状态，在比较快速的采样中， 即使飞机正在做幅度比较大的动作，前后几个数据样本的相关性也是非常大的，所以不断的采样-不断的刷新，我们看到的便是一个连贯的参数表达。这便是连续显示的原理所在。在响应 Timer 消息的处理函数中设计采集数据，检查数据，显
