本文描述了高度完整性代码的开发和测试技术，并显示如何在模型级上应用和自动化来提高嵌入系统的质量同时缩短开发周期。

开发用于航空、汽车、轨道交通和其他行业中的安全关键系统软件的要求相当严格，开发者通常使用自我保护的编程技术来确保系统具有容错能力，并使软件能在出现未预料到的情况下继续工作。因此，首先实现可靠的验证和确认策略来减少故障进入系统的可能性同样重要。

这个额外步骤要求需要增加开发成本。行业报告显示，用在安全关键系统的验证和确认过程的成本和工作常常超过开发整个系统的一半，基于手工编程和纸上规范的传统方法的这个问题更严重。使用Ada、C或Fortran开发模型不仅代码冗长而且代码可能有错误，在不同设计阶段重新利用模型时可能产生不经意的改变而导致不正确的结果。类似地，在团队间频繁用于交流的需求、规范、测试和其它内容的文档可能引起歧义和误解。

通过使用基于模型的设计和集成开发环境，如MathWorks公司的Simulink产品系列，工程师能使开发和验证自动化，减少费用和降低错误。

在基于模型的设计中，从通过建模和仿真来获得需求到设计实现和测试，系统模型是开发过程的核心。模型是在整个开发过程中不断细化的可执行规范，与写在纸上的规范相比，可执行的规范能使系统工程师更深入了解他们策略的动态表现。在开始编码之前的很长时间就对模型进行测试，确保规范的完整性和无歧义。自动代码生成避免了手工拼写错误和对设计的误解，同时自动化的验证和确认让测试工程师开发完整的、基于需求并可在自动产生的代码上重用的测试用例(test case)。

建模和仿真

开发工作从由结构框图和状态机组成的控制算法模型开始，每一个框图和状态机都具有特别的实时执行特性。算法模型结合周边部件，如传感器、执行器(actuator)、机械设备、电子单元和其它与控制算法有相互影响的物理元件，产生一个系统模型。

例如，显示在图1中的车辆故障检测、隔离和恢复(FDIR)应用的系统模型，包括了FDIR逻辑模型、工作模式逻辑、控制规则、执行器模型、被控对象(车辆动力学和大气作用)、信号调理和插入故障的方法。一个设置故障的图形界面让开发者了解系统正常和故障下的行为。

模型风格的指导方针

模型风格指导方针使从系统规范到嵌入代码产生的转化变得简单有效。对于编码标准，生产单位通常建立他们自己的模型指导方针，准备用来产生嵌入代码模型的步骤。

在建立这些标准时，回顾一下已发布的模型和代码的指导方针和标准很有用。在一些组织，如MathWorks汽车咨询部(MAAB)和发动机工业软件可靠性联合会(MISRA)，已存在着指导方针，这些方针一般集中在安全性、一致性和简洁性。

图1：故障检测、隔离和恢复模型。

MAAB建立于1988年，开始是协调包括福特、Daimler Benz(现在DaimlerChrysler)和丰田客户间产品特征要求，现在MAAB把对象扩展到世界范围，包括大多数主要的OEM厂商和供应商。MAAB的一个重大成果就是建立了一系列公开、可用的建模风格指导方针。其中一条MAAB规则规定了控制器模型必须只能使用离散模块，因为连续模块不能更贴切地表示控制器的实现方式而不允许使用。

MISRA的《在车辆中用C语言编制软件的指导方针》(MISRA-C)，于1998年4月发布，2004年十月更新，提供了安全相关的汽车嵌入系统的C语言编程指导。使用C语言开发电控单元软件的汽车工业开发者创建了其中很大的部分。

虽然MISRA-C不是为自动代码生成而定制的，其规则关注于C语言编译器的可移植性，对于手工开发和自动产生的代码是一致的。下面就是一个规则例子：

MISRA规则11(必要的)：内部和外部标识符应该不超过31个有效字符。此外，应该检查编译器/连接器来确保31个字符串有意义，并支持外部标识符的大小写敏感特性。这个规则很重要，可以避免有长名字的标识符间的名字冲突。这个规则已可使代码更有可移植性，因为大多数编译器和连接器支持至少31个有效字符。

在自动产生的代码中，标识符在模型中标明。尽管MISRA-C给出的是编码风格指导方针，但它可以帮助在建模风格指导方针中包含相应的规则，因为模型是代码发生器的输入。MathWorks为它的嵌入代码发生器-Real-Time Workshop Embedded Coder提供一个MISRA-C分析包。另外，最近MISRA建立了一个工作组来检查自动代码生成。

模型检查器

明确的指导方针和标准使软件开发者编写可以系统地检查对这些方针的符合性的脚本，所以建模环境必须提供每一个在设计中使用的图形特征和参数相对应的API。然后它直接用来开发系统检查规则，如限制标识符名字长度的工具。

在Simulink中的Model Advisor识别模型中那些阻止嵌入系统开发和限制代码效率的部分。这个工具帮助开发者准备一个用来生成代码的模型，通过分析模型或模块级别上的配置，给出在每个领域查找结果并提出改进建议的报告。在设计周期早期它特别有用。

可追溯性

许多认证标准要求从设计到实现的双向可追溯性。因为他们通常还要求测试用例是基于需求的，因此有必要确保测试用例能跟踪到需求。许多开发环境包括了客户知道的文字需求和开发者了解的详细设计模型。客户的需求可能通过微软的Word或Excel，或者在数据库或需求管理工具如Telelogic DOORS中，用简单文字提供。

在可追溯性路径的下一步是显示代码可追溯到模型(图2)，对安全关键系统来说这特别重要。不像快速原型代码发生器，嵌入式代码发生工具包中特别强调代码简洁性。这样的一个例子是产生的HTML链接到生成的C代码。当有链接的注释被点击，产生代码的源模块在模型中会高亮显示。

验证和确认

验证和确认是高度完整性系统主要关注的问题，在设计和集成的每一阶段需对系统的应用进行检查、分析和测试工作，它贯穿在整个开发过程。

CMMI(能力成熟度集成模型)定义的验证和确认为：验证是确认产品正确反映了规范需求，即验证是确保你正确地实现产品；确认是确认提供的产品完全满足它原想要的用途，即确认是确保你实现了正确的产品。

基于模型的设计提供了许多验证选项，包括仿真、快速原型建立和硬件回路测试(hardware-in-the-loop testing)。近来出现了针对其它的验证活动的功能，如软件在回路仿真和处理器在回路仿真测试。

安全关键系统的测试必须基于需求，在测试中所有的代码结构必须得到检查。DO-178B Level A软件要求执行MC/DC(Modified Decision/Condition Coverage)等级的覆盖度。该等级确保在决策中的每一个条件能独立地影响决策的结果，没有达到要求的结构覆盖等级可能表示在需求、设计或测试用例中存在错误。

对安全关键系统模型的测试要求有正式的方法来建立和执行测试用例。特别的新模块，如信号建立和断言模块，能实现这类正式的测试。当测试已经确认所有的需求得到满足和每一要求的覆盖等级在模型上完全检查过后，模型可以用来产生代码并在代码上重新运行那些测试。

软件在回路(SIL)测试涉及到控制器的嵌入代码在一个指令级仿真器或调试器执行，并和被控对象模型(plant model)在建模环境里非实时运行。运行控制器的产品代码的处理器在回路仿真(PIL)测试和SIL相似，但在PIL测试中，工程师使用真实的I/O，通过CAN或串口器件来交换运行在处理器上的产品代码和运行在建模环境上被控对象模型间的数据。SIL和PIL是非常适合部件测试的非实时运行条件。

图2：模型需求和代码可追溯性。

通常在嵌入系统实验室最后的验证阶段，硬件在回路仿真(HIL)测试支持实时测试和系统测试。被控对象产生的代码运行在高度确定的硬实时(hard real time)计算机上。通过这个方法，在开发前期使用的被控对象在系统测试中重新使用。复杂的信号调理和功率电子元件用来激励和接收嵌入系统地输入(传感器)和输出(执行器)。

设计文档

在对安全关键系统的认证阶段，文档是一个关键的、需要核查的工作部分。对于基于模型的设计，工程师指定要求的各类文档的模板。有了正确模板，软件设计规范，包括设计框图、需求跟踪表和文字描述就能自动产生。

使用基于模型的设计所得好处超出了产品的第一次构建。采样这些工具和在这里讨论的技术，你可以迅速对模型改动，自动产生代码、自动产生文档，在模型和代码在环测试上运行一样的测试用例。这样，对安全关键系统小的改变能在几小时而不是几天或几周中成功设计出来。

供稿：MathWorks公司

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。