(工具CE)基于DO178B最佳实践-审核稿(一)

符合DO-178基于模型的软件开发最佳实践RaymondG.Estrada,Jr.1TheMathWorks,Torrance,CAEricDillaber.2TheMathWorks,Natick,MAGenSasaki3TheMathWorks,Torrance,CA利用代码自动生成的基于模型设计已经是开发嵌入式系统的一种成熟方法，而且这种方法现在已经广泛的应用在一些必须满足商用航空软件DO-178B的应用软件上面。基于模型设计能够使工程师利用一个可执行模型来创建先进的嵌入式软件系统，来作为设计、仿真、软件检验及确认的基础。现代航空航天系统复杂度增加使得基于模型设计广泛应用，从早期的检验到实现以及系统整合整个软件开发生命周期中都有应用。在满足DO-178B标准（FAA采用改进的DO-178C标准）的情况下，是基于模型设计的优势最大化就需要一定程度的专业知识，这往往要花上数年的实践经验才能获得。1.介绍本文介绍了一系列的最佳实践，这些方法对于基于模型设计来实现能够通过DO-178B和DO-178C标准认证的完整项目构建十分关键。这些最佳实践描述了重要的注意事项、模型和基于模型设计的基础功能，基于模型设计是跨越整个软件开发过程的，从建模仿真到代码生成，到验证和确认，再到执行。这些最佳实践是从多年来和航空航天工业的客户在开发高集成软件方面的合作经验中总结提取而来的。我们的目的是帮助组织在开发满足DO-178标准的高集成软件过程中，能够避免常见的误区并减少时间、精力以及成本的需求。DO-178B标准和最近发布的DO-178C标准明确定义了软件生命周期过程中步骤的具体目标，步骤例如软件需求定义、软件设计、编码、集成、认证和管理。标准附件A中的表A-1到A-10列出了各个步骤的输出要求。这些输出是根据软件的集成水平来生成的，并且使用前需要验证认证。而这些表格和DO-178B[7]文档提供了很少的模型使用指导，使航空公司去决定如何最好的在开发符合DO-178软件中应用基于模型设计。新发布的DO-178C标准增加了一项补充，RTCADO-331“DO-178C和DO-278A的基于模型开发和认证的补充”[6]，包括，当使用基于模型设计时，需要对目标、活动和软件生命周期数据进行修改和增加。DO-331对使用模型和相应的验证证明生成的工件提供了额外的指导。虽然该指导很有价值，但工程团队需要有一个高效的工作去提早识别错误、快速生成目标工件，使用可靠的工具消除手工过程，减少在系统集成中的软件错误。可以采用下面的最佳实践来实现一个工作流程，该工作流程是使用基于模型设计来开发满足DO-178标准的软件：建立一个标准化的基于模型设计的开发和认证环境定义一个配置管理策略，包括基于模型设计工件定义一个关于DO-178标准的优化的基于模型设计过程确定模型表示高级还是低级需求使用仿真和分析来满足DO-178标准的目标在一个抽象的更高层次上分析基于需求的测试使用具有资质的基于模型设计工具2.最佳实践A.建立一个标准化的基于模型设计的开发和认证环境DO-178标准要求开发人员具有一个标准化的环境，这样他们能够再生产软件的任何特定版本[5]。不一致的软件开发环境可能产生出不能完全符合需求的源代码和目标代码。建立标准化的基于模型设计环境有助于确保设计模型可以产生出满足需求的源代码和目标代码，同时可以生成满足需求的一致的、可重用的仿真和测试结果。虽然大多数有经验的组织已经使用传统方法建立了标准化的加工环境，但建立一个初始化的基于模型设计环境可能是一个挑战，因为大量的加工和定制能够需要基于模型设计所提供附加功能。加工不再局限在软件开发过程中，而是连续的使用。因此，应该妥善完成基于模型设计环境的内容，最大效率的支持项目并减少维护成本。就像一个编译器的输出受到一个单独的链接器文件的影响，仿真和代码生成的输出受到诸多因素的影响，例如配置设置、自定义文件、还有其他依赖关系（图1）。这些依赖关系通常以多种格式进行存储，并且一般位于开发环境的多个层级。图1基于模型设计的软件开发环境一个最佳实践为所有开发人员自动安装和设置开发环境。对于一个新用户或者一个新的开发环境安装，可以使用一个批处理脚本来自动安装：开发工具的合适版本合适的编译器版本模型开发库数据文件和脚本另外，通过自动执行任务，在初始化脚本启动时自动执行可以帮助确保一个一致的开发环境。例如：当SDP（软件开发）指定时，验证工具版本、库、补丁等等是否合适。所有设计模型依赖的路径添加执行附加设置并支持脚本定义和加载数据这方面的一个例子是Windows桌面快捷方式的配置，通过执行一个桌面上的启动脚本来初始化开发环境。自动安装、设置、和配置，有助于建立正确的设计模型需要用到的依赖关系。一个标准的软件开发环境包括一个通用的共享库，其中拥有已经开发的设计模型。原始模块（例如，增益模块、求和模块）通常为开发人员提供多种可配置选项，可以在设计模型中采用不同的模型选项。例如，Simulink中的增益模块有很多的配置选项，比如采样时间、信号、参数属性。应该创建一个包含有效基础模块子集的库来公用。自定义模型顾问的检查可以用来验证设计模型过程中使用一致的模块参数。B.定义一个配置管理策略，包括基于模型设计工件一个标准的基于模型设计环境自身是不足以再生产一致的软件生命周期数据的。典型的原模型依赖关系包括支持库、数据文件、脚本等等。仿真、测试、验证代码生成等都需要这些依赖关系。DO-178中声明了软件生命周期数据必须放置在配置管理（CM）[5]，在软件方面的认证计划（PSAC）具体描述。建立一个支持基于模型设计且与PSAC相一致的配置管理策略，并结合一个标准化的设计环境，这样可以允许一致的、可复用的仿真测试结果、源代码、目标代码。基于模型设计工件中配置管理的“黄金法则”是模型，它是设计信息的来源。由此来说，参数数据应用到模型也可能被认为是模型的一部分，但要用单独的数据文件或脚本来管理。导出的工件例如C代码和可执行文件应该总是从原模型生成而来。基于模型设计工件的代表类型如图2所示。图2典型的基于模型设计文件关于DO-178，下面的注意事项在配置管理过程中特别重要：存档在CM仓库中的设计文件必须保持同步设计文件在放入CM仓库之前应该进行标准检查下面的段落强调了工程师在定义一个配置管理过程中所遇到的一些共同问题，还有一些解决这些问题的最佳实践。同步文件关于基于模型设计，许多的文件可以自动从模型生成并关联参数数据，例如C代码和可执行文件，再这样一个过程中必须按照DO-178标准进行，这些文件应该归档，这样便于将来回访。这是十分有用的，当代码由于设计过程的连续迭代而更新时，就可以用来鉴定导出的工件的变化。为了确保这是在一个一致的且可重用的方式下进行，在源代码被存储到配置管理仓库之前，应该要确认所有的文件和它们的代码已经建立了同步关系。例如，这个过程要防止修改后的基于模型设计源文件（诸如模型和数据文件）在没有相对应的自动生成的代码情况下就被存入仓库。此外，这个过程应该防止修改后的自动生成工件的存入，例如C源文件和头文件，这样设计的模型和它的依赖关系都来自于自动生成的文件。如果不同步的工件被存入时，它会阻碍或者阻止调试过程，使工程师不能够重复之前的设计。此外，每一个自动生成的工件存储在CM仓库里的的目的应该是可以被理解和记录。例如，这应该记录一个系统设计描述（SDD）报告，该报告从设计模型和它的依赖关系自动生成，这可以用于模型验证和回溯活动。文件存入前进行标准检查虽然DO-178标准没有强制规定，但这是一个最佳实践，即在存入CM仓库之前检查开发的文件是否满足建立的建模和编码标准。建立Simulink建模标准的例子是有NASA(OrionGN&C)和MathWorks自动化顾问委员会（使用MATLAB、Simulink和Stateflow进行控制算法建模的指导）发布的。对于C代码，MISRAC标准是一个可选项。此外如果可以的话，在存入之前，团队应该确认模型是否可以仿真并且设计的模型能否生成代码。在配置模型和它的导出文件时，必须要进行正式的验证活动。这个最佳实践可以帮助确保正确文件的检查，且有助于简化验证活动。例如，一个没有按照标准操作的存入模型，可能无法仿真或者生成代码。这样就延长了正式的验证活动，因为在重新开始正式的验证活动之前，模型必须更新，并且工件必须重新生成。使用基于模型设计工具，比如模型顾问，可以在工件存入之前通过对其是否符合标准进行自动检查，来帮助减少或消除这些延误。C.定义一个关于DO-178标准的优化的基于模型设计过程在整个开发生命周期中，模型使用应该考虑多个目标，最大幅度的提高流程效率、增强管理复杂事务的能力、提高投资回报率。一个优化的基于模型设计方法结合了仿真分析、代码生成、链接和可追溯性分析要求、自动代码检查、自动文档生成、模型覆盖以及正式的验证方法。在使用基于模型设计的具体项目的软件设计过程实施之前，模型所代表的软件需求水平应该被提前确定。更多内容和最佳实践可以看[确定模型表示高级/低级需求]章节。使用在航空工业中的一种方法是按照文本最高水平需求（HLR）来开发模型。如DO-331[6]中表MB.1-1（模型用例）里的“MB例1”，这些模型代表最低水平需求。理想情况下，使用基于模型设计的软件设计过程是根据建立软件HLR的初始化设置来实现的。程序部分描述了几个关键领域，这些领域需要基于模型设计所提供的高投入水平，这也是基于模型设计与传统方式相比的优势所在。早期设计验证利用基于模型设计进行软件开发促进了早期设计验证。在模型级进行验证有助于减少软硬件测试及其以后的需求数量和设计错误。设计模型的桌面仿真通常使用基本需求测试用例，来完成非实时仿真。模型覆盖常用于结合仿真来确定不可执行的设计模型所需要的任何需求，需要的软件级别为DO-178的A，B和C。LLR的验证遵循和HLR一致的验证标准，通常是通过人工设计评审来完成。当使用基于模型设计时，在传统的设计评审执行的一些活动可以减少或者自动执行。例如，模型顾问工具自动完成模型评审来评估是否和建模标准一致。手动检查项应该不在模型顾问的检查范围之内。遵循高水平需求的模型可以通过仿真来进行评估，在发现设计中的实际问题方面，这种方法比传统的设计评审更加高效。减少或消除手工代码审查Simulink代码审查员通常用于实现DO-331中表MB.A-5中的目标，通常通过手工代码审查能够满足要求。这个工具使用正式的模型来系统地检查一个模型中的模块、参数和设置，来确定它们在结构上是否和生成的代码的操作、操作符和数据相比配。模型和代码之间详细的双向可追溯性分析可以检查出在人工代码审查中错过了的问题。生成的结构等价性和可追溯性报告要存档，并用于认证机构的审计，作为满足DO-331中表MB.A-5目标的证明。为了使得Simulink代码审查员的效率最大化，设计的模型应该使用支持原始模块的子集来开发。可执行目标代码的验证处理器在环测试是通过基于需求测试用例来对高级、低级和派生需求进行验证（图3）。现在已经存在的一系列基于需求测试用例在这些活动中可以重复利用。这样可以消除开发和审查中所需要的额外测试用例和代码，而在使用传统的方法进行目标代码验证时这些经常需要用到。一个代码覆盖工具经常和PIL结合使用来评估覆盖，并且产生一个代码覆盖度报告。Polyspace是一款静态代码分析工具，它是用来证明源代码中没有某些运行时错误，并且产生一个所需文档。测试结果、代码覆盖、和运行错误报告要存档，并且提供给认证机构，作为满足DO-331中表MB.A-6和表MB.A-7目标的证明。图3可执行目标代码（EOC）验证DO-178C目标验证的证明生成必须生成合规证明，并且提供给认证机构为了DO-178C中附件A里表A1-A10的目标。在传统的方法下，所需的文件通常手动开发，一个活动可能既耗时又容易出错。在使用基于模型设计的一个最优化软件开发过程下，大量的所需文件通过自动报表生成来创建。表1列出了各种工作流程活动自动生成的文档。表1：生成的工件工作流程活动文档模型可追溯性系统设计描述报告模型一致性模型标准报告模型验证仿真测试报告系统设计描述报告源代码可追溯性代码审查可追溯性报告代码一致性代码标准报告代码验证代码审查报告低级验证可执行目标代码测试结果报告高级验证可执行目标代码测试结果报告目标代码可追溯性代码生成报告目标代码表（第三方IDE或编码器）所需的工件自动生成巩固了从开发到审查的努力。有资质的工具应该被应用，例如Simulink代码审查员，这样对生成的工件的审查可以显著减少。