符合DO-178基于模型设计的软件开发最佳实践(2)_软件开发|软件定制|设计软件|APP软件-沈阳汇海软件公司

符合DO-178基于模型设计的软件开发最佳实践(2)

发布时间：2018-12-10来源：软件公司

关键字：符合DO-178基于模型设计的软件开发最佳实践(2)

1.确定模型表示高级需求还是低级需求

模型既可以表示高级需求（HLR），也可以表示低级续求（LLR）。为了确定满足哪项DO-178目标，需求的表征和流向需要认真定义。这对于在HLR、LLR、生成的源代码以及目标代码之间建立清晰且简明的可追溯性十分关键。DO-178C和附加的补充内容提供了一些指导，航空企业只需要选择需求定义和实施的策略。例如，他们选择使用文本建模语言来描沈阳做网站述需求。本节讨论了为了满足不同类型需求使用模型的不同方法。

根据文献CAST-15（认证机构软件团队），高级需求HLR通常代表设计了什么，低级需求LLR代表是怎么进行设计的。定义HLR的模型通常用于描述顶层的功能以及顶级接口。而定义LLR的模型需要定义详细设计方面的内容，包括软件架构、数据和控制流以及调度等。

有几种方法可以使用一个或者两个模型用于区分HLR和LLR，每种方法都有其优缺点。表2对利用模型定义需求的五种可行方法进行了总结。

在整个系统和软件开发过程中，应该检查是否可能出现模型的复用。可重用性的最佳案例是表2中的例5，这里一个模型被用于系统需求和设计的开发。这种方法没有减少DO-178C目标的满足数量，同时可以在开发的早期阶段开发设计模型。

模型表示HLR和LLR的情况下，HLR模型必须和LLR模型单独进行处理。尤其是开发方面的内容，比如建模标准、测试环境、和验证工作，必须针对HLR和LLR模型单独进行定义。然而，HLR模型和LLR模型同时使用同一建模环境时，通过工具复用可以提高效率，可通过在单一环境下运行两个模型的仿真来进行验证。

建高端网站设计议不要将HLR和LLR合并到单一模型。因为每个级别的需求都有不同的目标；HLR规定系统软件要做什么，而LLR规定了怎么去做以及用到了哪些部件，所以必须对HLR和LLR分开进行数据验证。

2.使用仿真和分析来满足DO-178标准的目标

仿真是DO-331中出现的测试与验证技术。随着基于模型设计流程的发展，仿真可能取代传统的检验和分析，从而为高级和低级需求提供是否满足目标子集的证明。仿真可以使工程师预测系统的动态行为，和传统的检验与分析相比，效率更高。

对于一个包含低级需求的设计模型来说，仿真可以用来证明是否满足高级软件需求。基于模型设计工具，例如Simulink报告生成器，通常利用设计模型来执行一套基于需求的测试用例，模拟系统的动态响应并且在报告中为手动检查自动捕捉结果。应该开发脚本用于比较仿真输出和预期结果，并用作验证工具。

图模型验证的仿真

根据DO-178C，处理器在环（PIL）测试平台可用于检验各个软件组件，即使该测试平台不包括最终的目标硬件。对于每个设计模型，应该开发并配置一个测试装置，用一个和目标硬件相同的处理器来和开发板相连接。每个测试装置应该包含一个顶层模型模块来引用相对应的设计模型。基于模型设计工具，比如Simulink报告生成器，通常执行一套基于需求的测试用例，模拟系统的动态响应并在报告中自动捕捉结果。该报告通过手动检验来检验可执行目标代码是否满足高级软件需求。

图利用处理器在环（PIL）进行目标测试

3.分析基于需求的测试

DO-178C标准允许使用仿真来取代人工检验对设计数据进行功能测试，或者两者并存。另外，仿真在测试中的使用有其他的好处，比如模型覆盖度，能够提供重要的反馈来进行完整的设计测试。

不使用基于模型设计，软件需求通常使用文本文档或静态图形规范来定义，如流程图。这些数据不能用来验证自身，它们首先需要转换为源代码，然后在一个仿真机或者目标计算机上运行，必须根据需求创建测试用例。使用基于模型设计，这种类型的测试可以在更高层次上进行，这意味着模型代表了设计、需求、或者两者，可以直接用于验证工作。

需求的可追溯性是DO-178的基本支柱。在高级需求、模型、源代码、目标代码、以及测试用例之间建立清晰简洁的追溯关系可能有难度。最好的方法是使用基于需求的测试用例评价模型覆盖率，并使用这个分析去发现遗漏掉的需求、派生出的需求、还有其他设计阶段的问题。这有助于避免在已知缺陷的软件上浪费精力，并且降低解决问题的成本，避免在缺少需求或有错误需求的情况下进入软件开发流程的下一步。许多建模工具都提供功能用于在仿真环境里追踪模型到外部需求以及测试用例，这样除了可以实现跟踪性，还有助于进行跟踪性分析。

就像软件架构和设计的开发一样，测试用例和程序也必须根据HLR和LLR进行开发。这些测试用例和程序可以在建模环境中开发，并用于仿真验证。DO-331中MB.6.8.1节概括了为了完成上述工作需要做的，包括需求验证是否合适，以及仿真是否完全满足具体的评估和分析目标。当使用仿真进行验证时，建议使用模型覆盖度，可以确定哪些需求模型没有覆盖到。

诸如Simulink Design verifier这样的形式化分析工具，可以识别模型中的“死”逻辑，模型覆盖度数据可以用来为未进行测试的需求创建测试用例。虽然通过在模型级使用这些工具不能获得认证信用，但是在源代码生成前识别这些设计问题可以减轻下游的工作。

4.使用具有资格的基于模型设计工具

DO-178C标准允许使用工具来清除、减少、或自动化完成DO-178C标准的过程。例如，可以使用工具来对源代码针对低级需求自动进行DO-178目标验证，从而减少或消除代码检验。这些工具必须符合RTCA DO-330“软件工具资格注意事项”[9]中所描述。最好的方法就是在软件开发生命周期中尽可能多的使用基于模型的设计验证工具。通常不使用没有资格的开发工具（比如没有商用资格的编译器），因为使用有资格的验证工具可以自动完成验证工作，投资回报率较高。

工具认证包为简化工具认证过程提供了文件和指导。这个认证包可以进行扩展来满足特定公司的标准和需求。然而，为了减轻工作量，基于模型设计工具的扩展和他们各自的认证包应该最小化。此外，应该在相同的软件开发环境下生成工具认证文件。通常，验证代码需求是一个既耗时又易出错的过程，因为需要逐行来对照项目清单手动检验代码，从而来满足DO-178C中的源代码验证目标。自动代码检查工具Simulink Coder Inspector的使用显著地减少了满足这些验证目标所需的时间。设计模型应该使用Simulink Coder Inspector所支持的模块子集来进行开发（图6）。

图 Simulink Advisor支持一个有效模块子集

通常，手工导出文件用于验证是否满足DO-178C里表A-3和表A-4中的目标[5]。开发检验清单用于完成诸如符合标准的验证和需求的可溯性验证等工作。使用基于模型设计，通过如下的总结，可以满足DO-331里表MB.A-3和MB.A-4[6]中的目标。

一个描述系统设计的详细报告;

设计模型的仿真和验证;

Model Advisor检查;

Simulink报告生成器应该用于根据设计模型来自动生成一个系统设计描述报告（SDD），该报告详细描述了系统的设计。SDD生成过程可以自定义，包含或删除特定的内容。然而，最终的报告应该包含系统设计的关键细节描述，包括：

根级和子级系统的接口;

高级需求的连接;

设计参数;

模块参数;

设计模型配置参数;

外部依赖关系;

为了满足DO-331里表MB.A-3和MB.A-4中的要求，Simulink报告生成器工具的SDD功能必须是经过认证的。应该使用认证包来简化工具通过认证过程。

应该使用基于模型设计工具来执行基于需求的测试用例，如Simulink报告生成器。虽然仿真输出的验证和PIL针对预期输出的验证都可以手动进行，但最佳方法是开发一个自定义脚本并取得资格，来完成比较。除了浮点数外，这些脚本应该能够支持更多的数据类型（single，double，integers）。

总结

DO-178B文档中提供的模型使用指导很少。新发布的DO-178C标准中的一个补充内容DO-331中提供了在使用模型时文件和验证资格的指导。这些文档注重过程和目标验证，使得航空企业去决定如何最有效的将基于模型设计应用到整个软件开发生命周期中。通过和航空工业的客户在开发高集成软件方面多年的合作积攒了许多知识，通过提炼得到了本文中的最佳实践，使用基于模型设计来开发具有DO-178认证的软件时，这些最佳实践可以用来实现一个高效的工作流程。

恒润科技，

----专注电子系统而努力！

作为本土领先的汽车电子、综合电子及轨道交通电子服务供应商，致力于为客户提供咨询、产品、工具、培训一体化解决方案。