嵌入式电子飞行仪表系统的软件结构与实现Word格式文档下载.docx

嵌入式电子飞行仪表系统的软件结构与实现Word格式文档下载.docx

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

软件系统方案论证

1．操作系统

方案一核心的操作系统部分选用开放源码的ucLinux来实现，我们可以直接修改系统的源码，经过裁减后直接编译出自己的Linux内核，接着基于这个系统来设计开发应用程序部分。

这样的工作量无疑是非常大的，对于ucLinux操作系统的陌生和整个开发时间的安排以及核心的EFIS部分的工作量使我们在这个平台上的计划止步，Linux下不是十分便利的开发环境也限制了我们的能力。

因此，本设计没有采用这个方案。

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

MicrosoftWindowsCE3.0在众多的嵌入式操作系统的平台中一直比较优秀。

WindowsCE是支持多平台的可定制的嵌入式操作系统，虽然在图形界面上和WindowsX86家族系列长得很像，让人们误以为是WindowsX86平台的移植产品。

但在实际上，WindowsCE的代码全部是重新设计并编写的。

它同样支持多线程，完全抢先执行和多任务的操作系统。

系统在设计上采用完全的模块化结构，非常有利于裁减和编译。

另外，完备的驱动程序和便利的开发环境IDE也非常有利于我们在限期内设计开发出我们所制定的较为完整的EFIS系统的目标。

图一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

图2NK.bin镜像组成图

2．EFIS系统软件框架设计

系统的主干部分为数据的通讯和显示。

在飞行员的反映时间内要比较好的解决实时数据流的通讯和以一定精度的显示问题。

在人眼可察觉的范围内尽量做到快速的刷新屏幕，保持当前显示数据最新，实现实时准确的形象显示。

在系统资源非常有限的状况下，我们要解决在保证数据通讯的精度和速度的基础上，尽量提高显示刷新速度这样一个问题。

刷新速度制约了整个系统的数据的采集频率和显示效果：

刷新的速度过于缓慢，不仅在视觉上产生了明显的停滞感，而且大大的制约了数据显示的实时性。

在显示速度和整个系统的通讯速度之间找到一个比较合适的分割点，是我们在设计EFIS所追求的实际目标，也是整个系统能否使用的关键所在!

在我们的系统中，包括GPS（GlobalPositioningSystem）卫星所提供的定位信息（包含友机在内）以及本机近19路飞行参数等在内的所有资料的综合显示必须将整个系统的综合报警系统完美的结合进来。

作为飞行员，他们所关注的往往直接的视觉信息，所以使用综合的仪表显示始终要作为主导，因此在飞行员以飞行经验来判断当前飞行参数是否处在警戒范围并由此做出判断之前，我们的警报系统就必须对这些参数加以判断并将判断结果直接的在第一时间内显示出来。

鉴于飞行任务的多样性,我们不能将整个警报系统的判断参数固化进程序，必须实现给飞行员的不同设定预留出统一的动态接口，使飞行员能够随时设置而不必重新编译系统。

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

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

EFIS系统的软件功能实现框图方案如上图所示，作为中心部分的图形显示始终占据在主导地位，围绕着这点，将所有的功能划分为四大模块：

1.数据通讯接口。

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

3.实时综合显示模块。

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

作为外部数据源和驱动图形动态显示的通讯接口部分，在系统的软硬件衔接部分中起着关键的桥接作用。

虽然数据以比较快的速度2730Bps（共10帧数据）的速率实现实时的将飞行参数传递进中央处理计算机的功能，但图形的刷新往往只能显示其中的6帧到7帧，虽然飞行员能够忍受这种速度，勉强能够满足实时显示的要求，但是这给航空黑匣子的数据记录带来了一点点的麻烦，因为航空事故的整个过程关键部分只有几秒钟，所以将飞行数据以等同于接口通讯速率的速度记录下来是作为黑匣子所必须要实现的。

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

数据通讯和接口部分实现了由通讯接口读入编码数据，将数据译码为我们所规定的有效的通讯格式后，转换成可供计算机程序直接调用的变量值等功能。

作为原始的数据格式，我们将读入的数据通过程序直接控制为有效格式后，存储入文件中。

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

一旦成功的实现了软件和硬件通讯部分，飞机的飞行参数就已经成功的采集到了计算机，有了这些飞行资料，便有了实现图形显示的最根本的基础。

对于数据通讯的详细介绍请参看《嵌入式电子飞行仪表系统的通讯接口》一文。

数据被分为16种，包含在GPS定位和群体飞行的导航数据在内的所有有效数据，在实时显示的同时，还要经过警报模块来检测其是否处于危险范围来将不同的警报位置位，在综合显示中不仅实现了飞行参数的综合显示实时更新，另外还要将警报位中不同等级不同内容的警报以一种直观的图形形式显示出来，在第一时间内向飞行员报警。

发动机参数在达到最低警戒范围内的时候就已经极有可能引起一定程度的飞行故障，但其在前几分钟内的参数往往呈现某种走势，因此有必要提供在近几分钟内的发动机参数趋势图。

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

由于经过接口的转换后的数据是符合整形或者浮点的形式的结构，所以在封装单帧数据后，在图形模块直接调用数据对象的指针，便可以将当前的飞行参数实时的加以显示，警报系统加以实时的判断。

对于n分钟内的采样模块来讲，也可以通过这点实现数据的队列存储。

整个系统中的几大关键模块：

数据通讯模块，数据滤波模块，警报检测模块，图形显示模块等，彼此之间都是透明的，每种模块通过消息循环处理函数联系在一起。

这就为软件部分的分工合作，调试检错带来了方便。

因此，前期的模块划分和需求分析，对于加快系统的开发速度，减少错误查找的时间和难度等众多方面起着比较明显的作用。

整个应用程序是建立在消息映射和消息传递的基础上的。

各类不同的系统消息我们可以选择不同的处理方式：

可以忽略，或者编写处理函数进行处理。

我们所设计的EFIS系统是建立在对于数据的不断采样，不断显示的功能之上。

因此，设置定时器向系统不断的发送定时消息便可以做到每隔一段时间做一件事情。

这便是不断刷新的原理所在。

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

图4程序运行原理示意：

消息的循环与映像

对于处理不同的消息，我们使用不同的函数，各类不同的消息的传递中还会包含了WPARAM和LPARAM的参数。

另同类消息的不同处理带来了方便之处。

Timer消息贯穿在整个程序的初始到结束—在Create和Destroy之间。

只要不退出程序的运行，定时器就会一直运作。

这就首先保证了数据和图形的实时刷新。

另外，在每一时刻确定了各传感器工作正常之后，我们便得到了该时刻唯一的一组参数值，这些参数唯一的确定了飞机的飞行状态，在比较快速的采样中，即使飞机正在做幅度比较大的动作，前后几个数据样本的相关性也是非常大的，所以不断的采样--不断的刷新，我们看到的便是一个连贯的参数表达。

这便是连续显示的原理所在。

在响应Timer消息的处理函数中设计采集数据，检查数据，显示数据的代码，便是实现整个综合资料采样和显示的真正奥秘。

由于航空事故调查中的黑匣子数据所需的单位时间内之采样样本数要高于我们显示的刷新速度，故不能在同一个Timer消息的处理中应付数据流的存储工作。

故黑匣子功能必须单独在通讯前端进行处理。

关于黑匣子的详细介绍请参看《嵌入式电子飞行仪表系统的通讯接口》。