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

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

电子飞行仪表系统（ElectronicFlightInstrumentSystem）下列简称EFIS

为了实现基于嵌入式电子飞行仪表系统的数据综合显示，我们选取了基于Intel

StrongARM1110的JingWei开发平台，进行核心部分包含数据接收，解码，综合计算

与综合显示，与黑匣子部分的数据记录的软件开发。为了缩短开发时间，降低开发难度,

我们在操作系统的选取上使用了Microsoft公司优秀的嵌入式操作系统WindowsCE

3.0o开发工具选用了EmbeddedVisualC,结合JirgWei的SDK与PlatformBuilder进

行整个硬件平台上软件部分的设计与开发。飞机上各路传感器的数据通过我们所设计的

综合数据采集系统的采集后，通过串口编帧发送，JingWei通过串口1接收到数据后进

行解码与校验，将正确的数据后通过系列的计算后，调用绘图函数以图形方式综合显示

在彩色LCD上。另外，所同意到的数据还会储存在我们所设计的固定格式的二进制文件

中，储存在JingWei的SDRAM中实现黑匣子部分的数据记录，借助我们所开发的基于

X86系统的黑匣子回放软件，能够分析回放黑匣子的储存数据。

在软件上，PlatformBuilder关于专有硬件平台的操作系统的定制与裁减，Embedded

VisualC++关于系统平台上应用软件的开发均提供了极大的便利，CPU的强大的数据处

理能力，彩色LCD显示屏的综合图形显示，也为整人以显示为核心的系统提供了充分的

保证。

关于EFIS系统的扩展部分，诸如VFR（虚拟飞行法则）与ILS（仪表着陆系统）与

EFIS系统的结合等，由于时间紧迫，任务繁重，都只在理论上与实验中实现，并没有真

正加入到系统中。

软件系统方案论证

1.操作系统

方案」核心的操作系统部分选用开放源码的ucLinux来实现，我们能够直接修改

系统的源码，通过裁减后直接编译出自己的Linux内核，接着基于这个系统来设计开发

应用程序部分。这样的工作量无疑是非常大的，关于ucLinux操作系统的陌生与整个开

发时间的安排与核心的EFIS部分的工作量使我们在这个平台上的计划止步，Linux下不

是十分便利的开发环境也限制了我们的能力。因此，本设计没有使用这个方案。

方案二操作系统选用MicrosoftWindowsCE3.0。MicrosoftWindowsCE3.0在

众多的嵌入式操作系统的平台中一直比较优秀。WindowsCE是支持多平台的可定制的

嵌入式操作系统，尽管在图形界面上与WindowsX86家族系列长得很像，让人们误以为

是WindowsX86平台的移植产品。但在实际上，WindowsCE的代码全部是重新设计并

编写的。它同样支持多线程，完全抢先执行与多任务的操作系统。系统在设计上使用完

全的模块化结构，非常有利于裁减与编译。另外，完备的驱动程序与便利的开发环境IDE

也非常有利于我们在限期内设计开发出我们所制定的较为完整的EFIS系统的目标。

基于*indowsCE的应用程序

附加技术Shell模块

对象存储：

文件系统

核心系统接口通讯模块

WindowsCE数据库

注册表

模块部分

图形句柄

系统内核窗口句柄设备管理模块

事件句柄

OEM层OEM适配层本地设备马励数据流接口驱动

基于WindowsCE的目标设备

图一MicrosoftWindowsCE系统配置及基本组织图

使用PlatformBuilder3.0结合适用于JingWei的bsp包，外加模块的裁减编译后导

出适合开发应用程序的SDK,使用EmbeddedVisualC++便能够开发编译出在这个平

台上运行的软件。将我们所开发的软件与操作系统直接编译成为一个镜像文件，通过

JTAG口烧写进JingWei的flashrom便实现嵌入式系统的软件硬件化。

2.开发环境

选择好了操作系统平台之后，所要做的便是如何选择应用软件的开发环境，摆在我们

面前有两个方案：

方案一使用EmbeddedVisualBasic。使用Platformbuilder能够输出EVB使用的

SDK,EVB的开发环境相对直观简洁，开发难度相对较小，但是编译生成的目标代码过

于繁琐，编译效率相对较低，程序运行速度较慢。关于EFIS实时显示各项数据的要求完

成的并不是非常好，在熟悉过EmbeddedVisualC++之后，我们放弃了这个方案。

方案二应用程序开发使用EmbeddedVisualC++结合SDK使用API函数直接编写

WIN32程序的方式进行编码，这点不仅大大提高了编译效率，减小了目标程序的大小，C

同时也具备强大的开发底层设备驱动的能力，程序执行速度更快，更加符合嵌入式系统

实时性的高水平要求。当我们自行裁减WindowsCE模块到处SDK后，很多的MFC类

库所封装的函数将不可能被包含在SDK中，因此我们放弃了MFC直接使用API编写。

另外，使用API方式编码所编译出的代码会更加的精简。

设计与论证

1.系统镜像档的设计

EFIS系统中关于图形的要求很高，GDI函数支持这部分必不可少。关于黑匣子功

能的实现在JingWei平台上是依靠于可靠的文件系统。关于通讯部分又是整个系统数据

传输的主干。因此综合了以上的模块后，我们在PlatformBuilder中选择了MAXALL的

最小配置，包含了用户图形接口GUI与文件系统。在基于JingWei的BSP包上，选取

了Com1,Display与Touchpad的驱动模块，结合我们的应用程序部分作为用户模块，

将整个系统编译为了一个单独的镜像档。我们修改了这个系统的文件结构与程序的分布

位置，构造出了应用于这个平台固化代码的应用程序。实现了系统复位或者者重新加电

后能够迅速进入EFIS系统的目的，无需任何人工干涉。实现了简单的固化与专有。另外,

在不断的试验中，我们发现导致JingWei死机的很大一部分因素便是Explorer.exe,为

了突出图形的显示部分，我们在初始注册表中将这部分去掉没有编译进镜像。死机状况

大大的减少了。最终生成的镜像文档为NK.bin

用户模块驱动模块系统内核

JingWei

BoardSupportPackage

PLatFromBuilder

JingWei-NK.BIN

图2NK.bin镜像构成图

2.EFIS系统软件框架设计

系统的主干部分为数据的通讯与显示。在飞行员的反映时间内要比较好的解决实

时数据流的通讯与以一定精度的显示问题。在人眼可察觉的范围内尽量做到快速的刷新

屏幕，保持当前显示数据最新，实现实时准确的形象显示。

在系统资源非常有限的状况下，我们要解决在保证数据通讯的精度与速度的基础上,

尽量提高显示刷新速度这样一个问题。刷新速度制约了整个系统的数据的采集频率与显

示效果：刷新的速度过于缓慢，不仅在视觉上产生了明显的停滞感，而且大大的制约了

数据显示的实时性。在显示速度与整个系统的通讯速度之间找到一个比较合适的分割点,

是我们在设计EFIS所追求的实际目标，也是整个系统能否使用的关键所在！

在我们的系统中，包含GPS(GlobalPositioningSystem)卫星所提供的定位信息(包

含友机在内)与本机近19路飞行参数等在内的所有资料的综合显示务必将整个系统的综

合报警系统完美的结合进来。作为飞行员，他们所关注的往往直接的视觉信息，因此使

用综合的仪表显示始终要作为主导，因此在飞行员以飞行经验来推断当前飞行参数是否

处在警戒范围并由此做出推断之前，我们的警报系统就务必对这些参数加以推断并将推

断结果直接的在第一时间内显示出来。鉴于飞行任务的多样性，我们不能将整个警报系统

的推断参数固化进程序，务必实现给飞行员的不一致设定预留出统一的动态接口，使飞

行员能够随时设置而不必重新编译系统。

整个系统的软件功能模块框图如下:

FemWork

图3EFIS软件部分功能与作业框图

EFIS系统的软件功能实现框图方案如上图所示，作为中心部分的图形显示始终占据

在主导地位，围绕着这点，将所有的功能划分为四大模块：

1.数据通讯接口。

2.预警规则与图形警报。

3.实时综合显示模块。

4.黑匣子数据采集记录模块。

作为外部数据源与驱动图形动态显示的通讯接口部分，在系统的软硬件衔接部分中起

着关键的桥接作用。尽管数据以比较快的速度2730Bps（共10帧数据）的速率实现实

时的将飞行参数传递进中夬处理计算机的功能，但图形的刷新往往只能显示其中的6帧

到7帧，尽管飞行员能够忍耐这种速度，勉强能够满足实时显示的要求，但是这给航空

黑匣子的数据记录带来了一点点的烦恼，由于航空事故的整个过程关键部分只有几秒钟,

因此将飞行数据以等同于接口通讯速率的速度记录下来是作为黑匣子所务必要实现的。

也就是说我们在图形显示中忽略掉的那部分数据在黑匣子中将会完整的保留下来。

数据通讯与接口部分实现了由通讯接口读入编码数据，将数据译码为我们所规定的有

效的通讯格式后，转换成可供计算机程序直接调用的变量值等功能。作为原始的数据格

式，我们将读入的数据通过程序直接操纵为有效格式后，存储入文件中。将帧格式数据

做有效的转换，存储在全局对象中为其它的模块调用实现了飞行数据显示的通用接口。

一旦成功的实现了软件与硬件通讯部分，飞机的飞行参数就己经成功的采集到了计算机,

有了这些飞行资料，便有了实现图形显示的最根本的基础。关于数据通讯的全面介绍请

参看《嵌入式电子飞行仪表系统的通讯接口》一文。

数据被分为16种，包含在GPS定位与群体飞行的导航数据在内的所有有效数据，

在实时显示的同时，还要通过警报模块来检测其是否处于危险范围来将不一致的警报位

置位，在综合显示中不仅实现了飞行参数的综合显示实时更新，另外还要将警报位中不

一致等级不一致内容的警报以一种直观的图形形式显示出来，在第一时间内向飞行员报

警。发动机参数在达到最低警戒范围内的时候就已经极有可能引起一定程度的飞行故障,

但其在前几分钟内的参数往往呈现某种走势，因此有必要提供在近几分钟内的发动机参

数趋势图。将数据作为队列形式存储后显示出来。

由于通过接口的转换后的数据是符合整形或者者浮点的形式的结构，因此在封装单帧

数据后，在图形模块直接调用数据对象的指针，便能够将当前的飞行参数实时的加以显

示，警报系统加以实时的布断。关于n分钟内的采样模块来讲，也能够通过这点实现数

据的队列存储。

整个系统中的几大关键模块：数据通讯模块，数据滤波模块，警报检测模块，图形显

示模块等，彼此之间都是透明的，每种模块通过消息循环处理函数联系在一起。这就为

软件部分的分工合作，调试检错带来了方便。因此，前期的模块划分与需求分析，关于

加快系统的开发速度，减少错误查找的时间与难度等众多方面起着比较明显的作用。

整个应用程序是建立在消息映射与消息传递的基础上的。各类不一致的系统消息我们

能够选择不一致的处理方式：能够忽略，或者者编写处理函数进行处理。我们所设计的

EFIS系统是建立在关于数据的不断采样，不断显示的功能之上。因此，设置定时器向系

统不断的发送定时消息便能够做到每隔一段时间做一件情况。这便是不断刷新的原理所

在。下图为整个程序运作的原理示意。

图4程序运行原理示意：消息的循环与映像

关于处理不一致的消息，我们使用不一致的函数，各类不一致的消息的传递中还会包

含了WPARAM与LPARAM的参数。另同类消息的不一致处理带来了方便之处。Timer

消息贯穿在整个程序的初始到结束一在Create与Destroy之间。只要不退出程序的运行，

定时器就会一直运作。这就首先保证了数据与图形的实时刷新。另外，在每一时刻确定

了各传感器工作正常之后，我们便得到了该时刻唯一的一组参数值，这些参数唯一的确

定了飞机的飞行状态，在比较快速的采样中，即使飞机正在做幅度比较大的动作，前后

几个数据样本的有关性也是非常大的，因此不断的采样-不断的刷新，我们看到的便是一

个连贯的参数表ii。这便是连续显示的原理所在。在响应Timer消息的处理函数中设计

采集数据，检查数据，显示数据的代码，便是实现整个综合资料采样与显示的真正奥秘。

由于航空事故调查中的黑匣子数据所需的单位时间内之采样样本数要高于我们显示

的刷新速度，故不能在同一个Timer消息的处理中应付数据流的存储工作。故黑匣子功

能务必单独在通讯前端进行处理。关于黑匣子的全面介绍请参看《嵌入式电子飞行仪表

系统的通讯接口》。

3.图形显示的架构设计

在嵌入式EFIS系统的应用开发过程中，摆在我们面前的问题便是：

1.提高代码的编译效率，尽量缩小目标代码的大小

2.提高代码的执行速度，在固定的时间与画面复杂度的范围内提高画面的更新速度。

3.保障系统的稳固性。防止资源泄漏等错误的发生

在整个系统的设计过程中我们已经考虑到了以上几个问题。提高代码的编译效率，缩

小目标代码的大小意味着在一定程度上关于系统软硬件资源的充分节约，关于实现系统

实时与稳固均有一定的保证。便于错误的处理。提高代码的执行速度则意味高效快速的

完成数据采集，处理，显示，存储等一系列繁杂的任务，本身EFIS关于数据的通讯速率

与整个系统数据处理能力要求较高，大量的运算时间将花费在图形显示之上，作为图形

显示部分的程序设计一定要满足尽量有效的利用有限的资源，在保证实时的基础上完成

显示复杂图形的目标。保证系统运作的稳固性一方面要在硬件上做足功夫，另外一方面

要在软件上保证没有任何内存资源泄漏导致系统崩溃的情况发生，。

考虑到整个JingWei平台不能使用微软的图形力口速接口DirectDraw进行图形程序的

设计编码，因此只能使用JingWei所支持的基本GDI设备函数进行绘图。作为GDI设备,

直接调用其设备句柄进行繁杂的绘图操作是很慢的，同时显示效果会由于一次次的调用

中断而使画而变得闪烁刺眼，解决的方法便是使用贴图缓存，整个的贴图区务必事先在

内存中创建好，作为与系统GDI设备兼容的缓存设备的句柄，我们能够直接调用进行绘

图的操作，由于在缓存中的操作速度要远远高于在GDI设备上直接操作的速度，当完成

一次的绘图后，将整个的缓存映射到GDI设备上，便完成了一次向GDI设备的绘图操作,

能够非常有效的消除往常的闪烁现象。

整个绘图过程的瓶颈在于我们所创建的缓存区域的大小，区域过大会减慢缓冲映射的

速度。在能够正确实时的表达飞行参数的前提下，我们最终确定了基本的动态绘图区为

240*24（）。同时初步测试了我们所需的复杂图形在这人分辨率下刷新一次所需要的时间为

130ms左右。整个LCD余下的80个pix作为屏幕切换按钮与其它信息静态显示用，只

在初始化时刻进行绘图。

4.飞行画面的设计

PFD（主飞行画面）

PFD画面的设计涵盖了模拟与数字信号的大多数信息：航向角，飞行姿态，空速，

与高度等等。画面同样设计了一个虚拟的水平面所呈现的地平线，飞行员从当前画面中

央的虚拟机与水平线的显示上能够非常形象的获得当前飞机的飞行姿态等具体参数。主

飞行画面例图如下：

EAU（发动机/空气数据单元）

EAU单元的画面的设计使用了传统的图形方式-----表盘指针式。为了让飞行员在第

一时间内得到重要的发动机参数同时获知马上发生的警报，我们在显示过程中将当心/

警告的表示方法结合进了表盘设计中，下图为EAU单元的显示画面。

ND（NavigationDisplay）导航显示画面

导航显示画面的图形设计与表达方法使用了当前的通用方式。正中心的电子罗盘要紧指

示了当前飞机所飞行的磁航向角。我们在设计时候选择了惯用方式进行表达。

GPS定位及友机信息显示画面

在我们所设计的EFIS系统中包含了全球卫星定位的显示部分，正如前所说本机的

GPS信号作为一个完整数据包包含了经度，纬度，地速等信息，在通过信号调配与数据

收集后地编帧后，友机地资料也被编入了一格数据帧中，我们在设计中除了在左上角显

示出本机的信息：经度，纬度，地速，距离目的地的距离。另外还在以本机为中心的位

置同心圆上显示了友机的位置。相关于本机为参考点，上方永远指向本机当前所飞行的

方向（磁航向角），在这个参考点基础上，存在3个同心圆，同心圆的半径之比为1：2：4,

也就是说在相同的比例尺下，假如最小的半径为10公里时，最外面的大圆表示了当前以

本机为中心40公里半径内范围。当友机与本机的距离小于这个距离时，友机相关于本机

的位置便能够在这个圆内显示出来，为了方便观察，我们在大圆上设计了北向标志，便

于另外的方式进行观察。

关于友机当前的GPS信息我们设计了锁定显示，通过飞行员的操作（直接点击位于

大圆内显示的友机标志）就能够非常方便的锁定机群中的某架，如今友机的颜色会发生变

化，在右边也会显示出友机的机群编号，当前位置，对地速度等信息。锁定观察的容量

只有2架，当需要锁定第3架飞机的时候，已经锁定的第1架就会被解除锁定状态，整

个的锁定顺序为队列(FIFO)方式。

下图是一个非常典型的GPS定位及友机信息显示画面。

UAT：<40.□□□□□□DEST33.3

LONG：11□.□□□□□□GS3344

LOCK1

___L.OCKA

AFN：1

Alt：3O.43

GS：□

\s：40.130

ETD(EngineTrend-lineDisplay)发动机参数显示画面

如上所述，发动机参数的实时显示关于整个飞行过程是相当重要的，关于能够实时的

把它提供给飞行员之外，能够将过去几分钟内发动机参数的资料收集为加以存储，实现

走势图显示，关于让飞行员实时的得知过去与当前发动机的状况都是相当有好处的。便

于分析当前发动机状况以做出正确快速的推断做出了很大的作用。鉴于10分钟的数据关

于发动机走势信息已经足够，我们这里设计了共10分钟，每分钟6个样本共60个样本

的队列结构显示出来。在显示过程中，我们根据所要显示的发动机的3个参数：转速，

温度与压力的不一致等级警戒范围设计了警戒线，分别按照警告系统所规定的颜色加以

表示。在分析发动机参数的走势能够非常直观的观察到某段时间内的特殊情况与状况的

严重等级。

在图中我们显示了静态的时间刻度并标明了刻度值，左上角标明了所要显示的参数名

称。

5.警报系统的设计

正如总体框架分析所得，整个系统的警报是建立在关于单帧数据结构的自动分析上,

我们在外部已经按照规则初始化了警报逻辑所需的参数，比如最小值，最大值等等，程

序在初始化对象的时候读入外部所设定的参数到我们所设计的一个警戒参量结构中，为

下一步加载数据源后的数据规则检测做好了准备。

整个警戒参量的设计如下结构体所示，

structWarnStruct

intHeightUpLimit;〃高度上界限制（当心级）

intHeightBottomLimit;〃高度下界阳制（当心级）

intAirSpeedLimit;〃空速限制（当心级）

intVerticalSpeedLimit;〃升降速度限制（当心级）

intFYAngleLimit;〃俯仰角姿态限制（当心级）

intSAngleLimit;〃倾斜角姿态限制（当心级）

intOilNumLimitC;〃燃料数量限制（当心级）

intMotoSpeedLimitC;〃发动机转速限制（当心级）

intMotoTemperatureLimitC;〃发动机温度限制（当心级）

intMotoPressLimitC;〃发动机压力限制（当心级）

intMotoSpeedLimitW;〃发动机转速限制（警告级）

intMotoTemperatureLimitW;〃发动机温度限制（警告级）

intMotoPressLimitW;〃发动机压力限制（警告级）

intOilNumLimitW;〃燃料数量限制（警告级）

intPowerVLimit;〃电压限制（警告级）

intEntTemperatureLimit;〃环境温度限制（警告级）

intEntWaterLimit;〃环境湿度限制（警告级）

）；

在对加载后的数据源进行检测分析的过程中，将数据源所带来的单帧数据与以上的警

戒参量结合起来按照一定的逻辑进行对比，将对比的结果按照警戒等级来划分，最后将

警报系统另外的部分一标忐位结构体中的相应项目置位，这便是整个数据检测的全部过

程。最后在图形部分编