关于使用合格工具的do_178b标准基于模型设计（一）
基于模型的设计和自动代码生成在开发航空嵌入式控制系统中是一种重要且成熟的技术。早期模型的认证、验证、模型测试以及用软件工具和相应的一些工作流的应用逐渐被重视。在2009年，mathworks公司发布了基于民用航空软件标准do-178b的开发工具包，本文详述了基于模型设计在民用航空软件标准do-178b下的应用，并且应用有效的认证工具对其认证。
引言
基于模型设计能让工程师开发整个嵌入式系统，而且可以在桌面环境对系统进行仿真来分析和设计。基于模型设计提供了一系列代码生成功能，团队能利用它来进行仿真、快速原型设计和硬件在环测试。基于模型设计理念在航空代码设计和嵌入式开发上面也得到了发展。[1-4]
航空软件需要进行严格的航空认证标准认证而且每一项验证必须证据充分，如民航机载软件认证标准do-178b[5]。有了do-178b，执行开发或验证任务需要符合标准甚至系统输出也需要验证。基于do-178b标准验证一个工具的过程是基于这个工具的作用。如果是作为开发工具，那么就会有一个非常严格的认证过程；而对于作为测试工具，认证过程相对宽松但是需要非常具体。
本文将介绍一种用商业成品组件基于模型设计技术来开发嵌入式航空软件的框架。框架以工作流的方式呈现，工作流包括文本需求、详细模型设计、代码自动生成和一些自动验证的步骤。对比与传统的开发过程（文档设计和手工编代码）。本文还将研究工具合格套件以及通过一个基于模型的设计流程可以得到的好处，包括合格的工具。下面以一个基于模型设计工具的应用实例来阐述。
基于模型设计概述
a.建模和仿真
一个系统模型包括算法和算法运行的环境。一个算法实例可以是一条控制率或者一个信号处理过滤器的设计。对于控制系统，系统环境包括执行器、传感器和控制对象。而对于信号处理系统，系统环境需要表现为一个具有不同的延迟和噪音的通信传输层。算法模型最终将变成嵌入式处理器（如微控制器mcu或者数字信号处理器dsp）上的代码。针对嵌入式航空系统的硬件在环测试，可以在一个实时测试平台上部署工厂模型。这就需要花费大量的时间和精力用来开发模型。然而，对于实施和测试，可以通过生成代码来复用模型，这是利用基于模型设计的一个好方法。
典型的系统模型是使用simulink方框图、stateflow状态机、真值表和嵌入式matlab代码来开发的。嵌入式matlab代码是matlab语言的一个分支，支持仿真和c语言源代码生成。最初在2004年，作为一个小分支发布。如今嵌入式matlab已发展到包括大部分计算符和函数，通常用于嵌入式开发和实时仿真。直接从matlab命令行，从simulink中生成的嵌入式matlab模块，从stateflow中的嵌入式matlab函数都可以嵌入式matlab文件（.m files）。一个相关的功能是simulink模型图可以直接嵌入stateflow图。总之，这些特性为工程师进行系统、软件和硬件设计提供一个高度灵活的、多领域建模环境。
为了清楚的理解模型，需要执行或模拟。仿真首先需要模型编译成功、每个模型参数设置正确。在模型的编译阶段执行语法和语义检查、检查模型的确定性和完整性，例如模块之间有没有漏连的线，以纸质或者文档的说明书形式给出模型的立即优势。随后在正常仿真过程中进行实时分析，检查诸如数组越界和溢出等问题，增加到可执行规范，使其更加完善。
仿真结果的表现形式有图表、仪表、动画。仿真模型和相应的仿真结果如图1和图2所示。
图 1飞机航空控制模型和仿真输出图
图 2雷达应用系统模型（上），嵌入式matlab函数（右），和输出（下）
仿真有两种实现方法，一种是常规模式，即使用模型的内存表示和以解释性的方式来执行仿真。常规模式仿真为用户提供了更多的可控环境和更多的用户交互，但是对于复杂的模型仿真速度较慢。另一种仿真方法是基于模型生成代码并在仿真的时候运行代码。这种模式被称为加速模式，在仿真时用户交互很少，但是这种执行速度快，尽管在开始仿真运行时需要为代码生成花费一些资源。一种新的超速仿真模式正在兴起。它利用多个处理核心提供比加速模式更快的执行，同样只需要较少的用户交互。
仿真模型可以作为一个可执行的规范。不管是系统模型、软件模型、或验证模型，模型条目内容必须要严格定义。模型的逼真度决定了模型的好坏。很多公司和开发团体尤其是很多跨部门或者不同公司之间都开始考虑用基于模型设计。例如，飞机制造商需要面向系统级的、提供模型验证的建模工具。子系统供应商可能需要更多的在认证标准下(如do-178b)的面向软件、提供帮助验证的工具。成功使用基于模型设计需要考虑快速、简单以及软件工程和系统之间无缝过渡这些方面。文献[7]是采用基于模型的设计的工业应用。
b.架构和设计
一个完整的模型是分层管理的，直观显示的是顶层模型。常规组件包括子系统、模块库里面的子系统模块以及引用模型。组件分为虚拟或非虚拟。其中虚拟仿真组件能够方便的以图形显示并且不影响模型的结构和功能。非虚拟仿真组件被视为原子单元，它们影响仿真模型的动作，从而影响组织形式和执行顺序。生成的c代码由于是以原子单元为基本单位，所以在代码生成时也会有影响，而虚拟子系统总是产生一列轴向的代码（不会影响仿真）。
子系统在整个模型中是独立的、不可以被修改的。从版本控制的角度来看，这意味着子系统的微小的改变都会影响到整个模型的改变从而在相应的模型文件中生成一个新的模型。
模块库中的子系统模块分类存放在不同的模块库中，但是它们不完全是原子单元或者在整个模型中独立于其它模块。例如，母模型中的子模型继承了母模型的一些属性包括采样间隔、数据类型、信号带宽。在软件工程著作中，这个特点是通常被称为多态性，它为开发人员在组件创建和延伸上提供了很大的灵活性。然而，对于航空软件集成，多态性有助于把那些当结合其他组件时行为不改变的原子单元组件化。这就是模型参考组件的作用。
模型参考组件可以在常规和加速两种模式下仿真。图3是一个应用模块化构造模型的实例和一个simulink中独立的观测器构造的结构图。模型中在四周标记有小三角形的模块表示这些模块来自于其他模块或者其他子系统。标记的小三角形分为白色和黑色，白色表示常规模式的模块（如图中的算法模型模块）。黑色表示加速模式的模块（如图中其他模块）。菜单选项中选择模型模块参数表选项，在其中选择仿真模式。最近添加第三种仿真模式——处理器在环仿真（pil）。pil模式能够方便的基于模型的行为来验证生成的代码。
图 3示例架构模型（左）和相应的依赖关系图（右）
c.嵌入式代码生成和验证
对于代码生成的公司来说，重点是理解模块使用时代码的影响、模块的参数的意义和代码生成的设置。不管用什么语言和工具，工程师团队应该根据目标环境、软件完整性以及其他标准就如何使用代码生成器达成一致。因为目标环境参数没有以ansi/iso-c标准定义（如，整形的长度），所以目标环境参数的设置非常重要。通过选择合适的目标字的长度，开发人员可能意识到重要的代码效率改善和帮助确保他们的源代码符合处理器体系结构。相反，一个不合适的选择将会导致错误。
real-time workshop embedded coder 适合用来开发航空软件，因为它提供了对生成代码的很多控制性内容，如效率、可追溯性和可验证性。通常也用独立系统仿真环境来集成自动生成的代码，因为它提供高程度的代码集成选项，包括封装c++。real-time workshop embedded coder 中代码生成顾问帮助开发人员基于标准如效率、可追溯性、安全预防措施的条件下快速完成设置，如图4所示。
图 4代码生成顾问用来建立和检查目标代码
c语言是航空代码生成使用的传统语言。但是最近提出支持c++、verilog和vhdl等语言的生成。这就可以基于项目需要把很多处理器作为代码生成的目标。如图5。
图 5不同硬件设备代码生成和验证
图5指出对于模型，还需要在目标系统上执行目标代码来进行验证。自动代码验证用软件在环（sil）和处理器在环（pil）测试方法。sil测试通过在主机上编译和执行生成的源代码，运行结构和模型结果相比较。pil测试和sil测试类似，只不过pil在目标硬件和设备上设置编译器编译和执行代码。sil相对于pil通常作为一个快速的、额外的验证步骤，而pil则是我们的最终目标。结构代码覆盖度分析也应该检查在测试过程中是否满足do-178b涵盖标准，如修改条件/决定覆盖(mc / dc)。
凭借代码自动生成工程师能够开发一个自动sil和pil测试环境，项目工程团队可以在临界容忍度下比较数值结果。一种选择是在前面架构和设计中提到的用新的模型模块硬件在环仿真模式。这种模式需要一个主机和目标之间的通信机制(例如串口或tcp / ip)并且需要硬件在环接口程序。连接建立后，工程师只要将模型仿真模式设置为pil和快速启动pil测试。
代码生成、验证接口函数使得sil和pil使用脚本批量测试（数值查分、数值化测图）自动化。系统试验（systemtest）提供了一个类似的功能，即使用图形界面和报告自动生成。
d.模型验证和确认
使用基于模型设计，在开发过程中需要经过验证和确认。引进大量新技术辅以早期模型验证如需求追踪性、模型检查、模型覆盖，形式化和测试用例生成。
模型验证和确认中的模型顾问检查模型中可能不适合航空软件环境的地方。其中一些检查是基于仿真方面，其他是基于代码效率方面，有一系列新的检查是基于认证标准包括do-178b。例如，一种检查是检查模型的输入输出端口，确认它们定义准确而且没有继承像数据类型、采样间隔的属性。另一种是检查用户用户建立的环境参数设置。同样也要检查添加自定义中应用接口程序和图形编辑器。
另一个重要的验证步骤设计和运行模型试验。对于涉及安全的系统，试验应该基于文本形式呈现的需求。模型和高水平需求（文档中、基于数据的、或者在需求管理工具中）的双向连接支持需求管理界面的仿真软件验证和确认。需求也可以出现在生成的代码中，作为从模型自动链接注释。
有了simulink设计验证，能从涵盖相应标准（如，mc/dc）的理想模型中自动生成测试用例。图6就是一个从模型中生成的测试用例，测试显示了一个完整的特定路径覆盖。由于设计逻辑不佳而不能执行的情况需要在生成代码是重新生成凯发娱乐登录的解决方案。最后,仿真软件设计验证器提供了特殊的模块，帮助工程师执行形式化校验条目来评估设计逻辑，提高其鲁棒性。
图 6设计验证工具生成的模型试验目标报告
一旦模型如前所述能够满足其基础测试和模型覆盖的需求，航空软件代码即可自动生成。用软件在环（sil）和处理器在环（pil）执行代码验证。在软件/硬件集成完成后硬件在环测试（hil）作为最终系统的验证工作。对于硬件在环测试，生成的代码作为对象模型，在高精度、实时的计算机上运行。复杂的信号调节和电力电子需要合适的激励给硬件输入(传感器)和接收输出(执行器命令)，也包括硬件故障注入。
最后，除了这些基于仿真的测试方法，更重要的是要使用正式的分析方法分析和验证软件，例如显示缺乏某些运行时错误或执行misra-c®和jsf c++代码检查。polyspace®代码验证产品启用这种方式而且支持c、c++、ada源代码。