嵌入式软件和电子器件应用于汽车的各个功能领域，一方面，代替或简化了传统的机械和液压为核心的功能（如转向系统和制动系统），同时也实现了许多高级功能，如在便利性、舒适性和安全性方面对用户带来很大价值的主动安全系统和驾驶员信息系统；另一方面，嵌入式软件和电子器件的复杂程度迅速提高，加上这些系统在测试和检验上的困难，也导致了质量问题和召回数量不断上升。据IBM公司统计的数据，汽车制造商每年要支出20～30亿美元解决软件问题，在美国，32%的汽车保修服务内容是解决软件或电子相关问题。

基于模型的设计方法已经成为开发汽车嵌入式软件的首选方法。它改善了技术规格定义阶段、设计阶段和实现阶段。现在，基于模型的设计提供了许多新工具和新功能，可以帮助迎接测试和检验挑战，改善嵌入式软件质量，缩短测试和检验周期（见图1）。

图1  基于模型的设计可以帮助缩短开发周期和改善各种汽车电子器件的质量

使用基于模型的设计进行测试和检验

开发电子控制单元（ECU）往往会用到模型。在基于模型的设计中，汽车工程师可以通过多种途径得益于这些模型，如将模型用作可执行的技术规格、设计算法及用模型分析系统的动态行为和模拟系统部件与环境条件，以达到降低或免除对昂贵的实物原型的需求的目的等。此外，从这些模型中自动生成代码已经成为了公认的ECU软件开发方式。在未来几年中，预计这将成为许多汽车公司实现嵌入式控制软件的主要方法。

从质量角度看，自动代码生成能够和分析/仿真相结合来帮助优化了设计，同时自动生成的代码的质量具有可重复性。此外，汽车工程师可以从被控对象和环境模型中生成代码，以便进行硬件在环测试。

为了更广泛、更有效地利用这些模型，新的和改进的开发手段，包括基于要求的测试、覆盖分析和测试用例的生成已经出现。这些手段正在加快和改善包括软件和电子元件在内的复杂的嵌入式系统的测试和检验工作。

追踪和检查要求

大多数软件或流程标准要求在整个开发过程中实现设计与要求的双向溯源能力，用于产品实现的代码也必须能够溯源到设计，以便代码的复核和检验。基于模型的设计工具可以把EXCEL、WORD或要求管理工具中捕获的文本要求与模型联系起来，可以标出任何在设计中没有满足的要求，以及任何与要求不匹配的设计元素。如果要求或设计发生了变化，这些工具会指明可能受到影响的相应的设计元素或相应的要求。此外，自动代码生成工具可以在生成的C语言代码中插入HTML链接，使得实现代码可以被追溯到模型。这样的溯源能力对安全关键型系统尤其重要。这些功能互相结合提供了一条从代码到要求的完整的可溯源路径（见图2）。

图2  使用基于模型的设计追踪要求

除把要求和设计联系起来外，基于模型的设计工具还可以确认设计是否满足了特定的要求。工程师可以将这些要求作为属性或断言插入设计模型中，用形式化方法算法通过数学运算确定模型（即设计）在所有有效情况下是否满足这些属性。如果存在违反属性的情况，工具会生成一个反例。工程师可以在仿真中加入这个反例，并把这个反例增加到测试计划中。

检查模型风格

在设计阶段，工程师会将初期的高层模型转换成适合实现的模型，加入实现所需的特性，如定点细节，同时去掉不需要实现的部分。与软件工程师需要确定源代码风格指导准则，以使代码阅读、测试和实现起来更容易，参与基于模型的设计的工程师需要确定模型风格指导准则，保证模型能够被实现，更容易理解，并有助于测试。

根据所需的工作流程以及设计对象，工程师可以选择两种方法之一：从一开始就限制设计人员使用的选项，或者先进行设计到实现的转换，然后再对模型进行检查。

第一种方法通常用于对现有实现方案改动很小的、安全关键型系统中。一般来说，其做法是从设计一开始就通过定义一个限定子集来限制选项。这个限定子集包括模型组件（模块或状态机）、模块之间的连接方式，及其包括定点在内的其他设置。因为开发工具可以系统性地检查这些设置，所以设计人员不需要在每个设计中手动地对它们进行检查。

第二种方法是在开发阶段后期用指导准则检查模型。由于采用延迟检查，设计人员可以从不受限制的设计入手，然后逐渐限制设计，把设计转换为完善的、可以测试的实现方案。在理想情况下，这种模型检查是在建模环境中完成的，使得设计人员可以迅速发现问题，快速和有效地进行设计循环。

最近推出的一些工具可以帮助工程设计团队定义和定制一套模型检查规则，然后在模型上应用这套规则，使得设计人员能够立即处理设计中没有满足标准和指导准则的部分（见图3）。

图3   检查模型是否满足标准和客户自定义指导准则

分析和保证模型的覆盖

以往各类测试是在实现阶段之后基于源代码来实现，而模型在设计前期在实现阶段前为设计人员提供了一个执行的这些测试的机会。工程师可以全面测试控制器极限，检验其设计完整性，检测各类问题，比如找出以后会转换成为空代码的设计空段。

通常情况下，为确认一个设计能够正确运行及功能更强大，工程师会运行详尽的模型仿真，但这些仿真的效果直接取决于其模拟的工况。使用最小数值和最大数值对模型执行极限仿真测试有助于保证不会发生溢出情况，另外通过仿真要保证对设计的所有部分、所有设计中的模式和逻辑分支执行测试。

模型覆盖分析通过评估测试套件的累积结果，确定在仿真过程中哪些模块或状态执行了及哪些模块或状态没有执行。许多源代码语言如C、C++和Ada已经确立了特定的覆盖分析方法，但是这些分析方法直到最近才能应用到模型上去。

美国联邦航空局（FAA）认为，修改条件/判定覆盖（MC/DC）是满足安全关键型系统要求的最严格的覆盖级别。现在，基于模型的设计中已经包括了MC/DC在内的覆盖分析方法在仿真运行的基础上执行分析。在仿真工具中执行时，MC/DC可以自动记录和报告模型的覆盖指标（见图4）。这样，测试工程师可以从设计结构的角度去评估测试用例的完整性。有了这样的自动分析功能以后，如何定义测试用例来有效地达到完全的测试覆盖成了一个新的挑战。

图4   基于要求的测试覆盖分析

自动生成测试图形

基于模型的设计的一系列新工具可以自动生成测试图形以满足指定的覆盖目标，比如MC/DC。这些工具用数学方式分析模型结构和使用形式化方法生成测试图形。这种结构分析还能够确定模型中从未执行的部分，这表明在规格、实现和测试创建过程中可能出现了疏漏。然后，这些测试图形可以与从要求、测试台数据、Monte Carlo仿真和被控对象或环境模型中导出的其他测试用例相结合，通过仿真及以后的实际实现详尽地对模型进行测试（见图5）。

图5   仿真和测试控制中使用的测试图形

代码一致性检查

汽车行业软件可靠性协会（MISRA）已经出版了“在车载软件中使用C语言的指导准则”。这套习惯上称为MISRA-C的指导准则已经被越来越多的汽车制造商和供应商所采用。为了确定模型是否遵循MISRA-C的指导准则，大量的模型检查可以通过检查自动代码生成工具系统化的代码生成来实现，而不是像在手写程序的情况下那样检查产生的所有代码。但是检查代码生成工具并不适用于所有情况，导入的手写传统代码是例外之一。在这个情况下，可以使用开放的模型接口，自动检查这些情况。通过使用这种方法，可以在模型建立后、代码生成前进行检查，保证导入的代码或生成的代码通过检查。另一种方案是在代码生成和构建过程中汇入MISRA-C代码检查程序或者静态分析工具。

检测运行时错误

软件运行时错误在模型级上或在仿真过程中很难检测，但在开发和测试过程中可能会导致重大问题。运行时错误是指通常在特定数据值组合下才会显现的隐藏问题。使用动态测试查找运行时错误成本非常高。事实上，其功能行为结果通常会揭示这些问题，包括向制动器发送意想不到的命令、数学协处理器工作中断，或难以解释又很难重复的软件故障。在这些情况下，必须进行长时间的调试，才能找到问题的根源。

静态分析是解决运行时错误的方法之一。近几年来，业内推出了运用先进的静态分析技术的静态检验工具，减少了对手工检测需求和测试“假合格”结果的数量。这些工具对C语言代码进行静态分析及一定量的动态分析，不管这些代码是手写的还是自动生成的。这些检验工具和基于模型的设计工具集成在一起，大大改善了工作流程。通过把被分析的代码与生成代码的模型连接起来，静态检验工具可以将结果显示在源代码和模型中，从而设计人员能够从代码追溯到模型，对模型进行改动，然后再自动生成代码和重新检查代码。这种改善了的工作流程为同时在高层次和细节上作分析、调试和修改算法提供了一种有效的方式。

总结

综上所述的主要观点代表了三项使用基于模型的设计进行测试和检验的最佳实践。

第一，重复使用模型作为实现方案的测试台。从用模型进行仿真，到运行与模型相连的实现软件，到在主计算机或目标处理器上运行模型，再到在测试台上运行整个嵌入式系统，我们可以积累知识、测试数据和其他信息，然后在以后的开发和测试过程中重复使用。

第二，尽早进行测试。在实时运行之前进行仿真测试，在应用到实际环境之前在测试台上进行实时测试，在代码生成之前测试模型。测试越早，测试通常越容易，抽象程度也就越高。在开发过程尽早发现错误可带来显著的成本效益。

第三，利用所有可用的技术。仿真和形式化方法应相辅相承，测试和检验使用的基于模型的技术和基于代码的技术可以互补，许多厂商提供的工具都用到了这些技术来支持基于模型的设计。

许多汽车主机厂和供应商正使用基于模型的设计生成可执行的技术规格，仿真其性能，然后自动生成代码。许多公司开始深入一步，利用现有的模型进行测试和检验。