《嵌入式电子飞行仪表系统的软件结构与实现.docx》由会员分享，可在线阅读，更多相关《嵌入式电子飞行仪表系统的软件结构与实现.docx（11页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、编号：时间：2021年x月x日书山有路勤为径，学海无涯苦作舟页码：第11页 共11页嵌入式电子飞行仪表系统的软件结构与实现北京航空航天大学电子信息工程学院39020818 徐广毅电子飞行仪表系统(Electronic Flight Instrument System) 以下简称EFIS为了实现基于嵌入式电子飞行仪表系统的数据综合显示，我们选取了基于Intel StrongARM 1110的JingWei开发平台，进行核心部分包括数据接收，解码，综合计算和综合显示，以及黑匣子部分的数据记录的软件开发。为了缩短开发时间，降低开发难度，我们在操作系统的选取上采用了Microsoft公司优秀的嵌入式操
2、作系统Windows CE 3.0。开发工具选用了Embedded Visual C，结合JingWei的SDK与PlatformBuilder进行整个硬件平台上软件部分的设计和开发。飞机上各路传感器的数据经过我们所设计的综合数据采集系统的采集后，通过串口编帧发送，JingWei通过串口1接收到数据后进行解码和校验，将正确的数据后通过系列的计算后，调用绘图函数以图形方式综合显示在彩色LCD上。另外，所接受到的数据还会保存在我们所设计的固定格式的二进制文件中，保存在JingWei的SDRAM中实现黑匣子部分的数据记录，借助我们所开发的基于X86系统的黑匣子回放软件，可以分析回放黑匣子的保存数据。
3、 在软件上，PlatformBuilder对于专有硬件平台的操作系统的定制和裁减，Embedded Visual C+对于系统平台上应用软件的开发均提供了极大的便利，CPU的强大的数据处理能力，彩色LCD显示屏的综合图形显示，也为整个以显示为核心的系统提供了充分的保证。 对于EFIS系统的扩展部分，诸如VFR（虚拟飞行法则）与ILS（仪表着陆系统）和EFIS系统的结合等，由于时间紧迫，任务繁重，都只在理论上和实验中实现，并没有真正加入到系统中。软件系统方案论证1 操作系统方案一 核心的操作系统部分选用开放源码的uc Linux来实现，我们可以直接修改系统的源码，经过裁减后直接编译出自己的Lin
4、ux内核，接着基于这个系统来设计开发应用程序部分。这样的工作量无疑是非常大的，对于uc Linux操作系统的陌生和整个开发时间的安排以及核心的EFIS部分的工作量使我们在这个平台上的计划止步，Linux下不是十分便利的开发环境也限制了我们的能力。因此，本设计没有采用这个方案。方案二 操作系统选用Microsoft Windows CE 3.0。Microsoft Windows CE 3.0 在众多的嵌入式操作系统的平台中一直比较优秀。Windows CE是支持多平台的可定制的嵌入式操作系统，虽然在图形界面上和Windows X86家族系列长得很像，让人们误以为是Windows X86平台的移
5、植产品。但在实际上，Windows CE的代码全部是重新设计并编写的。它同样支持多线程，完全抢先执行和多任务的操作系统。系统在设计上采用完全的模块化结构，非常有利于裁减和编译。另外，完备的驱动程序和便利的开发环境IDE也非常有利于我们在限期内设计开发出我们所制定的较为完整的EFIS系统的目标。图一 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实时显示各项数据的要求完成的并不是非常好，在熟悉过Embedded Visual C之后，我们放弃了这个方案。方案二 应用程序开发使用Embedde
7、d Visual C结合SDK使用API函数直接编写WIN32程序的方式进行编码，这点不仅大大提高了编译效率，减小了目标程序的大小， C同时也具备强大的开发底层设备驱动的能力，程序执行速度更快，更加符合嵌入式系统实时性的高水平要求。当我们自行裁减Windows CE模块到处SDK后，很多的MFC类库所封装的函数将不会被包含在SDK中，因此我们放弃了MFC直接使用API编写。另外，使用API方式编码所编译出的代码会更加的精简。设计与论证1系统镜像档的设计EFIS系统中对于图形的要求很高，GDI函数支持这部分必不可少。对于黑匣子功能的实现在JingWei平台上是依赖于可靠的文件系统。对于通讯部分又
8、是整个系统数据传输的主干。所以综合了以上的模块后，我们在Platform Builder中选择了MAXALL的最小配置，包含了用户图形接口GUI和文件系统。在基于JingWei的BSP包上，选取了Com1，Display和Touchpad的驱动模块，结合我们的应用程序部分作为用户模块，将整个系统编译为了一个单独的镜像档。我们修改了这个系统的文件结构和程序的分布位置，构造出了应用于这个平台固化代码的应用程序。实现了系统复位或者重新加电后能够迅速进入EFIS系统的目的，无需任何人工干涉。实现了简单的固化和专有。另外，在不断的试验中，我们发现导致JingWei死机的很大一部分因素便是Explorer
9、.exe，为了突出图形的显示部分，我们在初始注册表中将这部分去掉没有编译进镜像。死机状况大大的减少了。最终生成的镜像文档为NK.bin图2 NK.bin镜像组成图 2EFIS系统软件框架设计 系统的主干部分为数据的通讯和显示。在飞行员的反映时间内要比较好的解决实时数据流的通讯和以一定精度的显示问题。在人眼可察觉的范围内尽量做到快速的刷新屏幕，保持当前显示数据最新，实现实时准确的形象显示。 在系统资源非常有限的状况下，我们要解决在保证数据通讯的精度和速度的基础上，尽量提高显示刷新速度这样一个问题。刷新速度制约了整个系统的数据的采集频率和显示效果：刷新的速度过于缓慢，不仅在视觉上产生了明显的停滞感
10、，而且大大的制约了数据显示的实时性。在显示速度和整个系统的通讯速度之间找到一个比较合适的分割点，是我们在设计EFIS所追求的实际目标，也是整个系统能否使用的关键所在!在我们的系统中，包括GPS（Global Positioning System）卫星所提供的定位信息(包含友机在内)以及本机近19路飞行参数等在内的所有资料的综合显示必须将整个系统的综合报警系统完美的结合进来。作为飞行员，他们所关注的往往直接的视觉信息，所以使用综合的仪表显示始终要作为主导，因此在飞行员以飞行经验来判断当前飞行参数是否处在警戒范围并由此做出判断之前，我们的警报系统就必须对这些参数加以判断并将判断结果直接的在第一时间
11、内显示出来。鉴于飞行任务的多样性,我们不能将整个警报系统的判断参数固化进程序，必须实现给飞行员的不同设定预留出统一的动态接口，使飞行员能够随时设置而不必重新编译系统。整个系统的软件功能模块框图如下：图3 EFIS软件部分功能和作业框图EFIS系统的软件功能实现框图方案如上图所示，作为中心部分的图形显示始终占据在主导地位，围绕着这点，将所有的功能划分为四大模块： 1.数据通讯接口。 2.预警规则和图形警报。 3.实时综合显示模块。4.黑匣子数据采集记录模块。 作为外部数据源和驱动图形动态显示的通讯接口部分，在系统的软硬件衔接部分中起着关键的桥接作用。虽然数据以比较快的速度2730 Bps（共10
12、帧数据）的速率实现实时的将飞行参数传递进中央处理计算机的功能，但图形的刷新往往只能显示其中的6帧到7帧，虽然飞行员能够忍受这种速度，勉强能够满足实时显示的要求，但是这给航空黑匣子的数据记录带来了一点点的麻烦，因为航空事故的整个过程关键部分只有几秒钟，所以将飞行数据以等同于接口通讯速率的速度记录下来是作为黑匣子所必须要实现的。也就是说我们在图形显示中忽略掉的那部分数据在黑匣子中将会完整的保留下来。 数据通讯和接口部分实现了由通讯接口读入编码数据，将数据译码为我们所规定的有效的通讯格式后，转换成可供计算机程序直接调用的变量值等功能。作为原始的数据格式，我们将读入的数据通过程序直接控制为有效格式后，
13、存储入文件中。将帧格式数据做有效的转换，存储在全局对象中为其它的模块调用实现了飞行数据显示的通用接口。一旦成功的实现了软件和硬件通讯部分，飞机的飞行参数就已经成功的采集到了计算机，有了这些飞行资料，便有了实现图形显示的最根本的基础。对于数据通讯的详细介绍请参看嵌入式电子飞行仪表系统的通讯接口一文。 数据被分为16种，包含在GPS定位和群体飞行的导航数据在内的所有有效数据，在实时显示的同时，还要经过警报模块来检测其是否处于危险范围来将不同的警报位置位，在综合显示中不仅实现了飞行参数的综合显示实时更新，另外还要将警报位中不同等级不同内容的警报以一种直观的图形形式显示出来，在第一时间内向飞行员报警。
14、发动机参数在达到最低警戒范围内的时候就已经极有可能引起一定程度的飞行故障，但其在前几分钟内的参数往往呈现某种走势，因此有必要提供在近几分钟内的发动机参数趋势图。将数据作为队列形式存储后显示出来。 由于经过接口的转换后的数据是符合整形或者浮点的形式的结构，所以在封装单帧数据后， 在图形模块直接调用数据对象的指针，便可以将当前的飞行参数实时的加以显示，警报系统加以实时的判断。对于n分钟内的采样模块来讲，也可以通过这点实现数据的队列存储。 整个系统中的几大关键模块：数据通讯模块，数据滤波模块，警报检测模块，图形显示模块等，彼此之间都是透明的，每种模块通过消息循环处理函数联系在一起。这就为软件部分的分
15、工合作，调试检错带来了方便。因此，前期的模块划分和需求分析，对于加快系统的开发速度，减少错误查找的时间和难度等众多方面起着比较明显的作用。整个应用程序是建立在消息映射和消息传递的基础上的。各类不同的系统消息我们可以选择不同的处理方式：可以忽略，或者编写处理函数进行处理。我们所设计的EFIS系统是建立在对于数据的不断采样，不断显示的功能之上。因此，设置定时器向系统不断的发送定时消息便可以做到每隔一段时间做一件事情。这便是不断刷新的原理所在。下图为整个程序运作的原理示意。图4 程序运行原理示意： 消息的循环与映像对于处理不同的消息，我们使用不同的函数，各类不同的消息的传递中还会包含了WPARAM和
16、LPARAM的参数。另同类消息的不同处理带来了方便之处。Timer消息贯穿在整个程序的初始到结束在Create和Destroy之间。只要不退出程序的运行，定时器就会一直运作。这就首先保证了数据和图形的实时刷新。另外，在每一时刻确定了各传感器工作正常之后，我们便得到了该时刻唯一的一组参数值，这些参数唯一的确定了飞机的飞行状态，在比较快速的采样中， 即使飞机正在做幅度比较大的动作，前后几个数据样本的相关性也是非常大的，所以不断的采样-不断的刷新，我们看到的便是一个连贯的参数表达。这便是连续显示的原理所在。在响应Timer消息的处理函数中设计采集数据，检查数据，显示数据的代码，便是实现整个综合资料采
17、样和显示的真正奥秘。由于航空事故调查中的黑匣子数据所需的单位时间内之采样样本数要高于我们显示的刷新速度，故不能在同一个Timer消息的处理中应付数据流的存储工作。故黑匣子功能必须单独在通讯前端进行处理。关于黑匣子的详细介绍请参看嵌入式电子飞行仪表系统的通讯接口。3 图形显示的架构设计在嵌入式EFIS系统的应用开发过程中，摆在我们面前的问题便是：1. 提高代码的编译效率，尽量缩小目标代码的大小2. 提高代码的执行速度，在固定的时间和画面复杂度的范围内提高画面的更新速度。3. 保障系统的稳定性。防止资源泄漏等错误的发生 在整个系统的设计过程中我们已经考虑到了以上几个问题。提高代码的编译效率，缩小目
18、标代码的大小意味着在一定程度上对于系统软硬件资源的充分节省，对于实现系统实时和稳定均有一定的保证。便于错误的处理。提高代码的执行速度则意味高效快速的完成数据采集，处理，显示，存储等一系列繁杂的任务，本身EFIS对于数据的通讯速率和整个系统数据处理能力要求较高，大量的运算时间将花费在图形显示之上，作为图形显示部分的程序设计一定要满足尽量有效的利用有限的资源，在保证实时的基础上完成显示复杂图形的目标。保证系统运作的稳定性一方面要在硬件上做足功夫，另外一方面要在软件上保证没有任何内存资源泄漏导致系统崩溃的情况发生，。考虑到整个JingWei平台不能使用微软的图形加速接口DirectDraw进行图形程
19、序的设计编码，因此只能采用JingWei所支持的基本GDI设备函数进行绘图。作为GDI设备，直接调用其设备句柄进行繁杂的绘图操作是很慢的，并且显示效果会由于一次次的调用中断而使画面变得闪烁刺眼，解决的方法便是使用贴图缓存，整个的贴图区必须事先在内存中创建好，作为和系统GDI设备兼容的缓存设备的句柄，我们可以直接调用进行绘图的操作，因为在缓存中的操作速度要远远高于在GDI设备上直接操作的速度，当完成一次的绘图后，将整个的缓存映射到GDI设备上，便完成了一次向GDI设备的绘图操作，可以非常有效的消除以前的闪烁现象。整个绘图过程的瓶颈在于我们所创建的缓存区域的大小，区域过大会减慢缓冲映射的速度。在能
20、够正确实时的表达飞行参数的前提下，我们最终确定了基本的动态绘图区为240*240。并且初步测试了我们所需的复杂图形在这个分辨率下刷新一次所需要的时间为130ms 左右。整个 LCD余下的80个pix作为屏幕切换按钮和其它信息静态显示用，只在初始化时刻进行绘图。4飞行画面的设计PFD(主飞行画面) PFD画面的设计涵盖了模拟和数字信号的大多数信息：航向角，飞行姿态，空速，以及高度等等。画面同样设计了一个虚拟的水平面所呈现的地平线，飞行员从当前画面中央的虚拟机和水平线的显示上可以非常形象的获得当前飞机的飞行姿态等具体参数。主飞行画面例图如下：EAU(发动机/空气数据单元) EAU单元的画面的设计使
21、用了传统的图形方式-表盘指针式。为了让飞行员在第一时间内得到重要的发动机参数并且获知即将发生的警报，我们在显示过程中将 当心/警告 的表示方法结合进了表盘设计中，下图为 EAU单元的显示画面。ND (Navigation Display) 导航显示画面导航显示画面的图形设计和表达方法采用了当前的通用方式。正中心的电子罗盘主要指示了当前飞机所飞行的磁航向角。我们在设计时候选择了惯用方式进行表达。GPS定位及友机信息显示画面 在我们所设计的EFIS系统中包含了全球卫星定位的显示部分，正如前所说本机的GPS信号作为一个完整数据包包括了经度，纬度，地速等信息，在经过信号调配和数据收集后地编帧后，友机地
22、资料也被编入了一格数据帧中，我们在设计中除了在左上角显示出本机的信息：经度，纬度，地速，距离目的地的距离。另外还在以本机为中心的位置同心圆上显示了友机的位置。相对于本机为参考点，上方永远指向本机当前所飞行的方向(磁航向角)，在这个参考点基础上，存在3个同心圆，同心圆的半径之比为1：2：4，也就是说在相同的比例尺下，如果最小的半径为10公里时，最外面的大圆表示了当前以本机为中心40公里半径内范围。当友机和本机的距离小于这个距离时，友机相对于本机的位置便可以在这个圆内显示出来，为了方便观察，我们在大圆上设计了北向标志，便于另外的方式进行观察。 对于友机当前的GPS信息我们设计了锁定显示，通过飞行员
23、的操作(直接点击位于大圆内显示的友机标志)就可以非常方便的锁定机群中的某架，此时友机的颜色会发生变化，在右边也会显示出友机的机群编号，当前位置，对地速度等信息。锁定观察的容量只有2架，当需要锁定第3架飞机的时候，已经锁定的第1架就会被解除锁定状态，整个的锁定顺序为队列(FIFO)方式。 下图是一个非常典型的GPS定位及友机信息显示画面。ETD (Engine Trend-line Display)发动机参数显示画面如上所述，发动机参数的实时显示对于整个飞行过程是相当重要的，对于能够实时的把它提供给飞行员之外，能够将过去几分钟内发动机参数的资料收集为加以存储，实现走势图显示，对于让飞行员实时的得
24、知过去和当前发动机的状况都是相当有好处的。便于分析当前发动机状况以做出正确快速的判断做出了很大的作用。鉴于10分钟的数据对于发动机走势信息已经足够，我们这里设计了共10分钟，每分钟6个样本共60个样本的队列结构显示出来。在显示过程中，我们根据所要显示的发动机的3个参数：转速，温度和压力的不同等级警戒范围设计了警戒线，分别按照警告系统所规定的颜色加以表示。在分析发动机参数的走势可以非常直观的观察到某段时间内的异常情况和状况的严重等级。在图中我们显示了静态的时间刻度并标明了刻度值，左上角标明了所要显示的参数名称。5警报系统的设计正如总体框架分析所得，整个系统的警报是建立在对于单帧数据结构的自动分析
25、上，我们在外部已经按照规则初始化了警报逻辑所需的参数，例如最小值，最大值等等，程序在初始化对象的时候读入外部所设定的参数到我们所设计的一个警戒参量结构中，为下一步加载数据源后的数据规则检测做好了准备。整个警戒参量的设计如下结构体所示，struct WarnStruct int HeightUpLimit; /高度上界限制(当心级) int HeightBottomLimit; /高度下界限制(当心级) int AirSpeedLimit; /空速限制(当心级) int VerticalSpeedLimit; /升降速度限制(当心级) int FYAngleLimit; /俯仰角姿态限制(当心级
26、) int SAngleLimit; /倾斜角姿态限制(当心级) int OilNumLimitC;/燃料数量限制(当心级) int MotoSpeedLimitC;/发动机转速限制(当心级) int MotoTemperatureLimitC;/发动机温度限制(当心级) int MotoPressLimitC;/发动机压力限制(当心级) int MotoSpeedLimitW; /发动机转速限制(警告级) int MotoTemperatureLimitW; /发动机温度限制(警告级) int MotoPressLimitW; /发动机压力限制(警告级) int OilNumLimitW;
27、/燃料数量限制(警告级) int PowerVLimit;/电压限制(警告级) int EntTemperatureLimit;/环境温度限制(警告级) int EntWaterLimit;/环境湿度限制(警告级);在对加载后的数据源进行检测分析的过程中，将数据源所带来的单帧数据和以上的警戒参量结合起来按照一定的逻辑进行对比，将对比的结果按照警戒等级来划分，最后将警报系统另外的部分-标志位结构体中的相应项目置位，这便是整个数据检测的全部过程。最后在图形部分编入根据警戒标志位的图形显示部分，就完成了图形报警的工作。警戒标志位结构设计如下：struct WarnFlag/严重等级 ：2 普通等级
28、：1 正常状态 ：0 int f_Height;/高度警戒标志位int f_AirSpeed;/空速警戒标志位int f_VerticalSpeed;/升降速度警戒标志位int f_FYAngle;/俯仰角警戒标志位int f_SAngle;/水平角警戒标志位int f_MotoSpeed;/发动机转速警戒标志位int f_MotoTemperature;/发动机温度警戒标志位int f_MotoPress;/发动机压力警戒标志位int f_OilNum;/燃料数量警戒标志位int f_PowerV;/电源电压警戒标志位int f_EntTemperature;/环境温度警戒标志位int f_
29、EntWater;/环境湿度警戒标志位;正常状态的标志位为0，表示数据检测通过，普通警告为1，严重警告为2 警报的逻辑检测与置位部分是由很多的条件判断组成，例如：/p_SDB为帧数据结构指针 p_SWS为警报参量结构指针 p_SWF为警戒标志结构指针if( p_SDB-Height = p_SWS-HeightUpLimit )/当前参量和警报参量对比 p_SWF-f_Height = 1;表示当前高度大于设定的最大高度的时候，将相应警戒位置位，其余逻辑类似。对于警戒参量的设计是灵活的。我们在设计中考虑到了不同的飞行任务中会有不同的要求，举例来讲，同样的飞机执行一次飞行任务，当这个任务是在城市
30、上空盘旋拍照的时候就和另外的一次飞跃喜马拉雅山脉的任务所应设定的最低可接受飞行高度肯定是不一样的。这部分的参量值是不能够固化在系统内不可改变的。我们必须给飞行员提供一个可以随时改变的接口。我们最终为这部分的接口设计了INI初始化配置文件的方法进行处理。INI文件的读取和写入算法很多，大都是和字符搜索相关的。我们在这里单独设计了一套比较简单的处理方法，按照我们所事先规定的行数写入当前参量值。例如：1HeightUpLimit=20000;表示第一行的参量高度限制为20000米，每行以分号和回车字符作为结束符号。在读取时候按照此规则便可读入相应的参量值，经过字符到浮点数据转换便实现了数据的读入。第 11 页 共 11 页