嵌入式线控驾驶系统开发过程中设计和测试考虑

图1：查看一个软件过程的普通方法是借助于V形图。

由于有了基于模型的设计，使得开发大量的汽车嵌入式系统时，可以由模型自动生成最终编译的软件。不过，这项工作需要一个软件工程框架的支持。本文使用线控驾驶系统(steer-by-wire system)作为实例，给出了设计汽车嵌入式系统的过程、方法和测试工具的一个框架。

近来，有报道称包括Denso、Motorola和Toyota在内的不同行业的多家公司都在产品代码方面取得了成功。这项技术正日益成为软件下一波演进发展中的一个重要组成部分。虽然总体而言，它对软件工程化过程的影响已为业界所了解，但却并没有十分清楚地确立起来。对于早前类似演进发展(包括从机器代码发展到汇编代码，再发展到源代码)的参与者而言，这一点尤为明显。

随着抽象与自动化程度的日益提高，新的过程、方法和工具接踵而来。瀑布式过程已让位于螺旋式方法和迭代方法。实时方法已经出现并正在取代静态流程设计。新的工具也出现了，如包含有调试器、优化编译器和自动测试工具的IDE(集成开发环境)。

不过，由于难以使用、缺乏了解或是工具支持不足的原因，并非每一种好的思想都能开花结果。有迹象表明，这些方法和工具对于主流产品应用并非总是实用。例如，用验证来确保软件正确性的正规方法是使用一种全世界只有极少数专家才真正懂得的语言编写的。此外，1980年代的实时用例工具可以辅助设计，但并未提供一条产生最终代码的简便途径。

图2：用控制系统方框图来表示反馈控制。

在早期应用阶段，产品代码生成的效果相当不错，这主要是由于其实用性。不过，其进一步的发展还需要依靠集成过程、方法和工具的支持。一种新的过程只有在具备了所需支持方法和工具的条件下才会成功。如果这些条件有所欠缺，那么对一个公司成熟的嵌入式系统进行重新设计的努力就不会是可行和实用的。

本文给出了主要面向产品代码生成的这样一个框架：

* 基于模型的设计
* 建模、仿真、快速原型、产品代码生成、模型测试和覆盖、在环测试
* 开发工具、验证与生效(V&V)工具、集成工具

模型的设计过程

图3：创建一个系统模型来表示所需的行为特性。

通过提供一个共同的图形规范和分析环境，基于模型的设计可以支持控制/DSP系统工程师和软件开发人员的需要。在这个过程中，模型被创建并用来规定系统数据、接口、反馈控制逻辑、离散/状态逻辑和实时行为。

基于模型的设计被应用在几乎每个需要嵌入式控制系统的行业之中。而在大型汽车电子控制单元(ECU)等嵌入式应用的开发过程中，其应用更为广泛。DSP和通信应用也采用这种方法，但它们更强调建模和原型，而不是产品代码生成。

为了满足这些不同的应用，基于模型的设计过程必须解决线控驾驶系统等安全关键系统的需求。它还必须产生最终的、可执行的代码，而且必须特别紧凑、快速和能够追踪。这是由于在大批量生产的ECU中，必须使用低成本的定点微控制器部件和DSP。

基于模型的设计适合任何过程框架环境，包括那些在IEEE软件工程化标准中描述过的过程框架。

IEEE Std. 730适用于任何通用软件项目。为了很好地理解它的过程框架，有必要回顾一下它对"关键性"项目文档所列出的需求。

IEEE Std. 730需求包括：

图4：线控驾驶系统。

* 软件需求规范(SRS)
* 软件设计描述(SDD)
* 软件验证与生效计划(SVVP)
* 软件验证与生效报告(SVVR)
* 用户文档
* 软件配置管理计划(SCMP)
* 包括软件项目管理计划(SPMP)在内的其他文档

查看一个软件过程的普通方法是借助于图1所示的V形图。这个图对应着大部分工程化过程，不过在开发生命周期中，这个过程是迭代性的，有许多反复的步骤。图中的软件过程包括以下几个组成部分：

图4B：对线控驾驶系统的建模与仿真。

* 开发 (需求、设计、编码和集成)
* 验证和生效(V&V)
* 集成 (软件配置管理、需求可追踪性和文档)

基于模型的设计非常注重过程迭代、早期测试和开发过程中的重用，这使得它既独特而又功能强大。这一过程的内在实用性体现在V形图的底部，产品代码生成是来自设计的一种自动过渡。

在基于模型的设计中，方框图或状态图模型可以用作系统和软件需求、软件设计，或者在稍作假设变换之后，用作源代码。这个过程的另外一个独特之处是，它在最终编译之前要进行广泛的验证和生效操作。早期验证和生效的好处很明显：它将大大减少在最终系统集成和测试期间发现的bug数目，返工次数也会更少。