嵌入式汽车控制软件发展的特征可以概括为使用V模型的几个开发步骤^[1]。从逻辑系统架构的分析和设计开始，也就是说，这个系统架构定义了控制功能，然后定义一组网络ECU的技术架构，接着在ECU上继续用软件完成设计。软件模块将被集成和测试，然后ECU将集成到车载网络中，最后，但并非最不重要的是，该系统运行执行功能必须通过校准来微调。然而这不是一个自上而下的流程，而是需要根据通过仿真和快速成型的早期反馈。

9.3.1.1 控制算法的研发

首先，控制算法是在发展的，主要是控制工程任务。它从被控制的系统，也就是从设备的动态分析开始。一个系统模型由三部分组成：车辆（包括传感器和执行器）、环境（道路条件等）和驾驶人。一般来说，在特殊情况下只考虑汽车的子系统，如动力总成的发动机和驾驶人，或一定路况条件下的底盘。这些模型可以是分析模型，如解析求解的微分方程；或是一个仿真模型，如一个数值求解的微分方程。实际上，一个模型通常是上述两种情况的混合。

然后根据一些质量标准，应用控制律。控制律用来对系统进行动态补偿。可以用很多规则寻找合适的控制律。汽车控制算法往往结合闭环控制律和开环控制策略。后者往往被使用于自动机构或开关构造上。这意味着从系统论的观点来看，控制算法是混合系统。通常情况下，控制律由设定点产生控制功能和监视功能的函数组成，且这些都由软件实现。第一步是给车辆的子系统（它由一个仿真模型来表示）设计控制算法。控制算法和系统模型都是在计算机上运行的。系统通常是准连续时间模型，而控制算法是离散时间模型。这两种模型的取值范围是连续的，也就是说，控制算法和系统模型的状态变量和参数在模拟代码中是浮点变量。图9.1的上部描绘了该模型。逻辑系统架构代表了控制算法和系统模型（包括车辆、驾驶人和环境）。箭头1代表控制算法的设计步骤。

9.3.1.2 快速成型

不幸的是，在整个设计过程中，使用的系统模型通常不够详细，不能当做唯一的参考模型。因此，控制算法必须要在一个真实的车辆上进行检查。这是控制算法第一次实时运行。因此，要仔细选择时间离散的仿真模型可执行部分。可执行部分必须被映射到操作系统任务中，而为硬件访问专设的软件模块必须附加到控制算法中。

此步骤如图9.1所示，把逻辑系统架构连接到真正的车辆上，此车辆在实际环境中由驾驶人驾驶，由箭头2表示。有许多方法来实现这一步骤。首先，可以使用带专用输入/输出（I/O）接口来连接车辆的专用快速成型系统。快速研发系统（RP系统）由一个强大的处理器和I/O板组成，如图9.1所示。这些板通过内部总线系统连接。与一个系列产品ECU相比，这些处理器板一般较有效，因为它们有浮点运算单元，并提供容量更大的只读存储器（ROM）和随机存取存储器（RAM）。在不同的使用情况下，通过总线连接的板卡，与传感器和执行器形成的接口提供了更多灵活性。简短地说，优先考虑的是控制算法的快速成型，而不是ECU的生产成本。

对快速研发系统的接口需求往往会导致板卡上专用电器的出现。这限制了灵活性，因此，另一种连接传感器和执行器的方法是使用带微控制器外围设备和ECU电子的常规ECU。一个积极的作用是，在以后的系列生产中，I/O硬件抽象层的软件组件可重复使用。

图9.1—基于模型开发的软件功能

l—对软件功能以及对车辆、驾驶人、环境的建模与仿真

2—真实午辆中软件功能的快速成型

3—软件功能的设计和实现(www.daowen.com)

4—在实验室的车辆和测试台架上，对软件功能进行集成和测试

5—在午辆中进行软件功能的测试和校准

图9.2所示为在旁路系统运行的控制和监视功能，该旁路系统通过传感器和执行器连接到车辆上。

对于图9.2所示的旁路配置中的ECU的快速成型，μC外围设备被用于驱动传感器和执行器。这意味着控制算法仍然在快速发展的硬件上运行，而I/O驱动程序在系列产品ECU上运行。信号W、R和U是数字值，它们分别代表着设定点、系统的采样反应和数字化的执行器信号。执行器的信号转化为电信号或机械信号Y，从而根据驾驶人愿望W^*规定的状态驾驶车辆。W是采集的数字信号。代表车辆实际状态的机械或电信号X被采样，并成为数字信号R再传递到控制算法。此外，还有存在类似道路状况的噪声信号Z，尽管它没有被控制算法作为测量的输入信号直接加以考虑，但它会影响车辆的行为，如果没有其他车辆信号，可直接使用。除了处理器板外，RP系统只使用专用的通信板。传感器值R、设定点值W和执行器值U通过高速通信链路来传输。绝大多数情况下，需要用专门的设施修改ECU硬件，以适应高速通信链路。

图9.2 典型的快速成型系统

9.3.1.3 控制算法的实施和ECU的集成

在快速成型这一步骤完成后，控制算法被证明在汽车上使用是有效的。针对快速成型系统生成的代码依赖于处理板的特殊功能，如RAM资源和浮点单元。为了使控制算法在有限的内存和计算资源下可以执行，该模型的控制算法必须重新设计。例如，控制算法的计算公式从浮点转换到固定点，且效率的可扩展性、模块化和其他关心的问题要一并解决。在代码生成步骤中，改写的设计可以自动转化为产品代码。

9.3.1.4 在实验室中测试技术体系架构

实施和整合阶段的结果就是技术体系架构，即网络化的ECU。这些ECU会对实际的系统模型进行测试。通过传感器和执行器的模型，及通过能够模拟ECU电子产品所期待的电信号的专门板卡，系统模型本身可以得到加强。这一类系统称为硬件在环系统，且包括处理板和I/O板。系统模型在初始化时，会有很多组不同的数值，以模拟各种典型的驾驶方式。然后，当ECU提供传感器的数据作为输出数据、ECU接收执行器的数据作为输入数据时，在硬件在环系统中模拟驾驶方式。通过这种方式，可以检查ECU的集成是否成功。在图9.1中，箭头4表示硬件在环系统测试。

9.3.1.5 在车辆中测试和磨炼技术体系架构

正如上面所说的，还存在很多使用情况的系统模型不够详细，因而不足以代表车辆动力学。虽然，如今很多的校准事宜都可以通过硬件在环系统进行，然而车辆控制算法的最终磨炼依然需要在实际车辆中依靠产品ECU中的产品软件来完成。这就要求，技术体系架构必须内置到车辆中，并到试验场进行测试。这种微调只涉及控制算法的参数设置，而不是其结构。