基于模型的开发（MBD）是汽车行业开发复杂软件（例如汽车发动机控制软件）的常用方法，这类软件部署在现代多核硬件架构上。此类发动机控制系统由从进气系统到排气系统的不同子系统组成。而每个子系统又包含必要的软件功能，这些功能用于从传感器读取数据以及向执行器写入数据。在这种情况下，基于模型的开发为建模和实现所需功能、验证功能特性、非功能特性（尤其是实时特性）是否符合需求提供了不可或缺的手段。当前工业界在基于模型开发中的实践完全依赖于生成式基于模型的开发，即通过代码生成来弥合模型与实现之间的差距。另一种方法是模型解释，即利用在硬件之上运行的解释引擎直接解释设计模型，尽管该方法尚未在汽车领域得到应用。本文通过案例研究，探究模型解释（而非代码生成）在发动机控制系统开发中的适用性。为此，我们采用基于解释模型的开发方法，对发动机冷却系统（具体为发动机冷却液温度计算功能）进行建模，并与现有的代码生成实践相比，探讨该方法的优势与不足。

01. 简介

基于模型的开发（MBD），也常被称为模型驱动工程（MDE），指将模型作为核心工件来推动系统开发的方法。尤其在软件密集型嵌入式系统的设计方面，它从根本上重塑并改进了设计流程。传统上，基于模型的开发（基于代码生成）在汽车行业得到广泛应用。代码生成用于从更高层级的模型生成代码，并创建可运行的应用程序。

大多数汽车企业在系列化开发中采用基于模型的开发方法。特别是在开发阶段（即系统设计和编码阶段），基于模型的设计应用极为广泛。汽车供应商和汽车制造商所采用的这类基于模型的开发被称为生成式基于模型的开发，因为代码及其他工件均从模型中自动生成。

通过模型获取应用程序的另一种基本方法是解释式基于模型的开发。解释式基于模型的开发可视为一组平台无关模型，这些模型由在硬件之上运行的执行引擎直接解释，该执行引擎可带操作系统运行，也可不带操作系统运行。

模型可直接执行这一特性具有重要作用，它能缩短开发周期，且模型与实际执行的内容之间不存在偏差。然而，据我们所知，模型解释技术在汽车领域尚未得到探索，但它有助于加快具有实时约束的应用程序的开发、部署和时序验证速度，这类应用程序可在潜在的复杂硬件平台上运行。由于模型与可执行程序之间完全一致，缺陷能在开发过程早期被发现，因此验证工作也更易于开展。本文通过案例研究，评估解释式基于模型的开发如何应用于汽车软件开发场景。

本文结构如下：第2节阐述汽车功能开发的工业实践现状；第3节介绍作为案例研究对象的、符合AUTOSAR标准的发动机冷却液温度计算功能；第4节探讨我们的建模方法；第5节呈现案例研究过程；第6节总结研究结果并对案例研究进行讨论；第7节总结全文。

02. 汽车功能开发--实践现状

我们以汽车发动机管理软件系统（通常采用基于模型的开发方法开发）为例，阐述汽车功能开发的最新进展。发动机由电子控制单元（ECU）控制，该单元包含用于不同子系统的发动机功能模块。

发动机功能的需求在某一应用生命周期管理（ALM）套件中进行定义，并可追踪至其在电子控制单元（ECU）中的实现过程。在应用生命周期管理（ALM）中，多种工具被整合用于软件的开发与维护。例如，IBM拥有名为IBM Rational Team Concert（RTC）的应用生命周期管理套件，其中Rational DOORS是需求管理工具，负责收集所有功能需求和非功能需求。这些需求会经过进一步分析，以指导发动机功能的设计。主流的基于模型的设计（MBD）工具包括MathWorks公司的MATLAB/Simulink（MLSL）、ETAS公司的ASCET-MD以及ANSYS公司的SCADE Suite。这些工业级基于模型的开发工具通过代码生成器进一步为发动机功能生成代码。每个发动机控制功能会经过（单元）测试，之后整合到电子控制单元中。

图1展示了汽车行业采用的软件功能开发流程。发动机的系统模型体现了设计思路与需求。该模型是可执行的规范，可通过仿真和快速原型开发来探索不同的设计方案。在现有方法中，建模环境主要用于描述领域问题（此处指需依据功能需求开发的发动机功能）。领域专家和软件设计师会参与这一阶段的工作。控制器模型在包含物理模型（即发动机）的仿真环境中进行测试，此测试被称为模型在环（MiL）测试，目的是确保模型符合需求。

图1：发动机功能开发流程——验证技术、相关参与人员及开发阶段示意图

下一步，利用代码生成器从模型中生成代码。随后，在发动机模型下对代码进行验证，该阶段被称为软件在环（SiL）测试。软件开发者会参与其中，通过单元测试对每个发动机功能进行单独测试。之后，在集成阶段，软件集成人员（通常是一级供应商）会将该功能与其他已有的发动机功能进行集成。完整的发动机软件随后会移植到电子控制单元（ECU）硬件上，可利用硬件在环（HiL）测试系统（如PT-LABCAR）对其进行验证，该系统能真实地模拟车辆的输入/输出（I/O）接口。

在当前实践中，目标平台上的执行环境与建模环境中的执行环境在输入/输出（I/O）、调度，甚至生成的代码方面均存在差异。实际上，为目标平台生成的代码会针对该平台进行优化，以实现最高效率。但不利的是，必须具备构建工具链，且从设计模型生成可执行程序需要耗费大量时间（构建时间可能需要数十分钟）。Simulink及其模块集（如Simscape、Stateflow等）是建模环境的示例，而Embedded Coder是用于在特定目标处理器上生成产品代码的代码生成器示例。生成的代码可进一步定制以满足需求（例如在安全性方面）。在汽车软件开发中，混合模式开发的可能性很高，即生成的代码会与手动开发的功能进行集成。

03. 符合AUTOSAR标准的发动机功能

发动机冷却系统是车辆的重要组成部分，负责将发动机温度维持在最佳工作范围。冷却液在电动水泵的作用下在发动机缸体中循环流动。冷却液会降低发动机缸体的温度，随后流经配备风扇的散热器，以散发废热。

图2展示了发动机冷却液温度计算功能的物理结构，该功能作为案例用于呈现我们的建模方法。发动机冷却液温度传感器在发动机冷却系统中起着不可或缺的作用。精确的温度信息至关重要，原因如下：电子控制单元（ECU）会利用该数据调整燃油喷射量和点火正时；此外，温度值还用于控制发动机冷启动、燃油量计算以及电动冷却散热器的风扇转速；该数据还可用于在仪表盘上显示冷却液温度表读数，以防止发动机过热。

图2：符合AUTOSAR标准的发动机冷却液系统功能物理结构——发动机冷却液温度传感器与电子控制单元（ECU）的连接

发动机冷却液温度传感器通过模数转换引脚连接至发动机电子控制单元（ECU）。传感器监测发动机冷却液温度，并输出电信号。根据AUTOSAR标准传感器设计模式目录，整个系统包含如图3所示的3个模块。传感器/执行器组件是特殊的AUTOSAR软件组件，它们封装了应用程序对特定传感器或执行器的依赖关系。AUTOSAR架构负责隐藏微控制器的具体细节（这一功能由运行在电子控制单元（ECU）上的AUTOSAR基础软件的微控制器抽象层（MCAL）实现）和电子控制单元（ECU）的电子设备细节（由ECU抽象层实现，该层同样属于AUTOSAR基础软件的一部分）。

图3：标准传感器的AUTOSAR设计模式

发动机冷却液温度计算功能的架构包含3个AUTOSAR软件组件，具体如下：

3.1 电气设备驱动层（DrvrSnsrElec）

通过输入引脚读取温度传感器的电气值，并将其存储在变量ElecRaw中。采用低通滤波器（LPF）对原始电信号（ElecRaw）进行抗干扰处理，得到滤波后的原始电信号（ElecBascFild）。

3.2 传感器设备驱动层（DevDrvrSnsr）

在该层，利用查找表将原始电信号转换为物理温度值（Raw），查找表中提供了对应的转换值。同时，也通过查找表获取滤波后电信号（ElecBascFild）对应的温度值，并将其传递至下一层。

3.3 虚拟设备驱动层（DevSnsrVirt）

该层用于识别可能出现的信号范围异常、电气故障、线路中断以及传感器故障。这样做是为了在传感器发生故障时，避免将错误值用于计算。此外，还能检测线路中断、电池短路或传感器电压饱和等其他故障，并设置相应的标志位：

· ElecBascFildbit：电气有效性位，用于指示传感器原始值在电气特性上是否有效。

· ElecBascFildbitCommon：通用有效性位，用于指示发动机冷却液温度整体是否有效，以及是否可传递至应用层。

基于该层计算得到的温度值，将获取的温度值（Measd）与应用层的估算值（Estimd）进行比较，通过比较判断计算值的有效性。若有效，则将最终温度值（Consld）发送至应用层。

04. 功能开发--提出的方法

据我们所知，此前尚未有人在汽车功能开发中探索和试验模型解释技术。在模型解释的情况下，需实现一个通用的模型解释引擎，用于执行发动机功能模型。如图4所示，建模环境包含执行环境。因此，可执行工件（即模型和执行引擎）均存在于该环境中。模型解释可在开发环境内启动，也可在目标平台上启动。在后一种情况下，解释可在操作系统之上运行，也可直接在硬件上运行。模型解释存在两种可能的模式：仿真模式和实时模式。

图4：集成环境（此处为CPAL编辑器），包含模型代码、过程激活的甘特图，以及在本地或目标平台上以仿真和实时模式执行模型的功能

仿真模式适用于设计阶段，该阶段要求执行速度尽可能快，这意味着过程的激活频率无需严格遵循，且过程（在概念上）可在零时间内执行。通常，仿真模式下的执行速度比实时模式快几个数量级。实时模式用于按照应用程序实际期望的时间特性执行程序。

为确保仿真能反映目标平台上的实时特性，可在仿真模式中引入时序标注（例如执行时间延迟、抖动等）。这些时序标注可通过对目标架构的测量、最坏情况执行时间（WCET）分析获取，若其他软件组件可能对所开发的功能产生干扰，还可通过可调度性分析获取。因此，时序精确仿真有助于在设计阶段早期发现故障，相比传统设计流程更具优势。

由于模型本身可执行，无需额外的工件；且与传统的生成式基于模型的开发不同，无需生成特定于目标平台的代码。相反，平台的具体细节由解释引擎处理。应用程序开发的后续步骤（如将源代码编译为目标代码、通过链接生成可执行程序）均不再需要。

05. 案例研究--发动机冷却液温度计算

发动机冷却系统模型采用CPAL（信息物理行动语言）开发，CPAL是一种用于建模、仿真、验证和编程信息物理系统的新型语言。CPAL是由卢森堡大学我们的研究团队与RTaW公司联合开发的语言。此前已有多项研究通过CPAL展示了多个工业用例。

CPAL的基于模型的环境包含一个集成开发环境，即CPAL编辑器（CPAL-Editor）。该编辑器将设计、仿真、执行（本地执行和在目标平台上执行）、功能架构可视化以及执行时序图整合在一个集成环境中。模型解释引擎是特定于目标平台的。该解释引擎可在操作系统之上运行，也可在无操作系统的环境下运行（后者被称为裸机模型解释（BMMI））。恩智浦半导体（NXP Semiconductors）的Freedom-K64F开发板支持CPAL裸机模型解释（BMMI），该开发板成本较低，其引脚布局与Arduino R3兼容。本研究的实验在树莓派（Raspberry Pi）上进行，该设备配备多核ARM Cortex-A7处理器（工作频率为900 MHz），运行Raspbian操作系统。

典型的发动机冷却液温度传感器的测量范围为-40°C至+150°C。在本案例研究中，我们采用负温度系数（NTC）型传感器，其工作电压为3.3V。图5展示了模拟发动机冷却系统的实验装置。MCP3008是一个外部模数转换（ADC）接口，与传感器相连。由于该传感器基于热敏电阻原理工作，因此添加了一个带有3.3V基准电压的分压电路。MCP3008的模数转换（ADC）数据通过串行外设接口（SPI）传输至处理器。传感器软件组件根据第三节所述的AUTOSAR设计目录进行建模。电动风扇的转速根据测得的温度进行控制。

图5：实验装置——传感器与硬件的接口连接

CPAL有两种可能的执行环境（即裸机环境或由操作系统托管的环境），本研究采用在操作系统（树莓派上的Raspbian系统）之上运行的解释引擎，该引擎也可在实时模式下执行，但相比裸机实现，其实时可预测性较低。发动机冷却液温度由采用CPAL建模的传感器软件组件计算得出。图6展示了同时进行仿真和实时执行的示例运行环境。该环境支持交互式执行和非交互式执行两种模式。交互式执行模式对程序分析和调试非常有用。在交互式模式下，用户可选择不同的执行选项，例如单步执行或在预定义的时间段内不间断执行。

图6：实时模式下的CPAL模型与执行环境

由于采用了解释式执行环境，用户可在运行时列出并修改全局变量的值，还可执行额外的代码语句。在非交互式模式下，程序会无限期执行或在指定时间段内执行，无需用户提供额外输入。

06. 结果与讨论

基于案例研究经验，我们提出了功能开发的开发流程。图7展示了采用模型解释方法开发发动机功能的流程。

图7：模型解释式发动机功能开发流程——涉及的步骤与相关人员

6.1 模型解释式开发步骤

第一步，收集发动机功能的所有功能需求、非功能需求（包括时序需求）。领域专家会对这些需求进行进一步分析。第二步（如图7中的系统设计阶段），采用CPAL实现需求规范。在开发过程中，每当功能模型更新时，功能架构以及由模型生成的其他视图（如执行甘特图）会随修改自动更新（第三步），这一过程在后台与模型修改同步进行。这使得设计师能立即可视化并理解修改所产生的影响，无需构建可执行程序并在调试模式下运行。无论是在仿真模式还是实时模式下，无论是在本地还是在目标平台上，模型的最新版本始终可用于执行。通常，在仿真结果满足要求后（第四步），会进行实时模式执行（第五步），这有助于设计师评估目标平台上的性能，实现快速原型开发。若仿真或实时模式执行过程中发现故障，则会通过迭代过程对模型进行改进。

基于发动机冷却液温度计算功能的开发过程，我们总结出模型解释方法相比现有生成式基于模型的开发方法的优势与差异，具体如下：

6.2 更快地适应需求变化

模型解释最显著的优势在于，模型修改无需执行显式的重新生成、重新构建、重新测试和重新部署步骤。这大大缩短了周转时间，在某些情况下还缩短了整体变更管理流程（即需求变更的实现流程）。尽管CPAL目前尚未支持，但未来模型有望在运行时更新，且无需停止正在运行的应用程序，从而提高开发效率。此外，由于无需生成工件，构建时间也得以缩短。根据具体用例，解释器与模型相结合所需的内存甚至可能少于生成的代码。

6.3 更易发现模型中的失效

在所有模块集成后的测试阶段出现的失效，能清晰地定位到模型中的问题，因为实际执行的就是模型本身。与代码生成不同，无需从生成的工件反向追溯失效在模型中的位置（这一过程通常难度较大）。另一方面，可在运行时对模型进行调试。由于模型在运行时是可用的，因此可通过在运行时单步执行功能模型来进行调试（例如，可在模型层级设置断点）。当支持模型层级调试时，领域专家可调试自己设计的模型（如单步调试），并基于调试结果调整应用程序的功能行为。例如，当涉及复杂的控制流或数据流时，这一功能会非常有帮助。

6.4 可移植性与硬件无关性

可移植性是模型解释的另一项优势。理论上，解释器可创建一个平台无关的目标环境来执行模型。通过仅重写硬件特定组件，可开发出能在多个平台上运行的解释器，CPAL便是如此的实例。在代码生成的情况下，我们需要确保生成的代码是特定于目标平台的；而在模型解释的情况下，解释器会处理平台特定的适配工作。

模型解释的一个显著优势在于，它向程序员隐藏了硬件平台的复杂性，使得运行时环境的配置和应用程序的部署更加简便。显然，更简便的部署是两者之间的一个重要差异。在使用代码生成时，我们常常需要在集成开发环境（IDE）中打开生成的源代码，对程序进行分析，然后从该环境中构建代码以生成最终的应用程序。而在裸机模型解释（BMMI）的情况下，我们只需上传模型并重置目标平台；若解释器由操作系统托管，则可在开发环境中或通过命令行（可能通过脚本在目标平台上）执行模型。因此，领域专家部署和测试应用程序会更加便捷，而不仅仅是进行建模工作。

6.5 单一集成环境的优势

解释式方法与生成式方法之间的一个重要差异在于，领域专家和软件开发者可以围绕单一集成环境和单一模型开展协作。如图8所示，集成建模环境提供了所设计功能模型架构的图形化视图。该模型从项目初期开始，既可供领域专家用于功能分析与验证，也可供软件工程师用于功能开发与测试。

图8：冷却液温度计算功能的软件架构

07. 结论

代码生成是工业界在嵌入式系统基于模型开发（MBD）中的标准实践，在发动机功能开发中尤其如此。本文探讨了一种模型解释开发流程，并以符合AUTOSAR标准软件架构的发动机冷却液温度计算功能开发为例进行了说明。通过与依赖代码生成的常规开发流程进行对比，并基于案例研究，我们讨论了模型解释的优势，包括简化开发流程、提高开发效率以及支持早期验证（尤其在时间维度上）。例如，本案例研究中选用的基于模型的开发环境CPAL，已具备在设计流程早期提供时序逼真仿真的基本机制。我们目前正在研究一种方法，该方法可自动推导软件模块所需的时间服务质量，并借助模型解释在运行时对其进行强制保障。

尽管模型解释具有诸多优势，但它无法覆盖所有使用场景。主要原因在于，模型解释在本质上比编译代码的执行速度更慢。不过，有多种方法可在产品代码中缓解这一缺陷，例如从解释代码中调用二进制代码（如遗留代码或专用功能代码），或者可能为模型中计算密集型部分选择性地生成代码。解释和代码生成通常被视为两种对立的方法，而非连续的技术体系。但我们也可以设想这样一种模式：先借助模型解释及其带来的开发效率提升，直至功能模块/电子控制单元（ECU）满足所有功能需求后，再切换到代码生成以获取产品代码。这一模式有待在未来的研究中进一步探索。