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

1. 行为建模

模型用来为单个子系统(如线控驾驶)的各个方面规定需求和设计。

一个典型的系统包括：

* 输入(如方向盘传感器)
* 控制器或DSP模型
* 设备模型(直流马达、齿条和小齿轮、车轮)
* 输出(方向的改变)

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

在图2和图3中，通过使用控制系统方框图来表示反馈控制、使用状态图来表示离散事件和条件逻辑，以及使用DSP模块来表示滤波器，可以创建一个系统模型来表示所需的行为特性。

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

2. 仿真与分析

然后，通过使用基于时间或基于事件的仿真以及频域分析等方法，可以执行和分析模型，以确保其满足需求。例如，一个线控驾驶系统必须对传感器故障进行响应，并“将高频响应衰减到3db以下，同时指令传输速率不能低于1.5Mbps”。

图4A和B*中对线控驾驶系统的建模与仿真,可以确定这些需求是相互冲突的还是有效的。仿真是一个核心验证行为，它确保可以实现一个系统来满足这些需求。

图4：线控驾驶系统

3. 快速原型

要在产品的芯片上实现一个可以工作的解决方案，设备模型还不够精确，处理能力也不满足要求，因此建模本身并不能提供完整的解决方案。

快速原型对于克服这些缺陷非常有用，因为它用物理设备来代替设备模型。在线控驾驶的例子中，设备有可能是一辆汽车，这时就使用一辆实际的汽车。不过，因为系统并未建立起来，一个实时或嵌入式平台将负责运行控制器软件并与设备进行交互作用。

有两种形式的快速原型：功能性快速原型和目标性快速原型。功能性原型使用一台功能强大的实时计算机，如多处理器浮点PowerPC或DSP系统，目的在于确定系统对物理汽车的控制是否如对模型汽车的控制一样好。如果真的是这样，则设备模型的不精确性就显得无关紧要，并且控制策略也得到了验证。

目标性快速原型在相同或相似的产品MCU或DSP，而不是高端PowerPC内核或其他专用高端快速原型硬件中执行软件。目的是将代码下载到实际产品目标之中，以便用物理设备进行快速测试。如果执行良好，则控制器不仅看似有效，而且可以在产品中加以实现。

软件设计行为包括定点数据规范、实时任务、数据输入、内建测试和诊断。通过基于模型的设计，用于算法规范和验证的同一模型被软件工程师加以改进和约束，作为产品代码生成过程的一部分。

4. 模型测试

与将模型部署到硬件上去编译和集成相比，在桌面计算机上测试模型具有更大的优势。基于源代码的测试已经存在许多年了，但是最近的方法允许进行模型测试和结构覆盖。使用的场景假定是开发人员对控制器施加满负荷压力，以便用仿真和覆盖来验证其设计完备性。另一种测试类型是故障模式效应分析(Failure Mode Effect Analysis)，用来确保故障情况下线控驾驶的救生操作，参见图5*。

图5：故障模式效应分析用来确保线控驾驶的救生操作

设计完备性不佳的例子是数值溢出和死码(dead code)。使用最小或最大数值的模型压力测试可以确保不发生溢出情况。使用仿真很容易进行这种测试，但死码就没有这么容易检测出来了，因为检测需要结构覆盖。死码与失效代码不同，其区别在于后者是开发人员已知，并且出于某种原因而使其失效的。实际情况中的死码意味着在确定规范期间遗漏了什么。

模型覆盖用来评估一个测试件的累积结果，以确定哪些功能模块未被执行，或者哪些状态未被到达。源代码语言(如C和C++)中建立了某些类型的覆盖，但现在模型也可以进行覆盖了。这项工作要求C语言所不需要(或不可能有)的新理论和新工具，因为这些语言没有功能模块或状态这样的构造。

修改条件/决策覆盖(MC/DC)被FAA(美国联邦航空管理局)认为是满足安全关键系统所必需的最严格的覆盖水平。现在，这种覆盖在一种基于模型的设计框架和许多需要线控设计的场合中已经得到了实现。