经验总结-实车VCU算法开发/集成/测试

原创于 2025-09-26 15:23:14 发布 · 2.1k 阅读

45 ·

CC 4.0 BY-SA版权

文章标签：

#算法

1 文档范围

文档主要介绍Simulink模型的开发、模型测试、模型集成、模型实车部署、实车测试与实车采集的数据分析全流程。具体而言，文档主要涵盖以下核心环节：

模型开发阶段：详细说明基于Simulink进行控制算法建模的规范与实践，包括模型接口设计、观测信号与标定信号的定义与管理、模块化架构设计原则以及建模风格指南。
模型验证阶段：介绍模型级的验证与测试方法，包括静态测试（如模型规范检查）和动态测试（如模型在环仿真），确保算法逻辑的正确性和代码生成的就绪度。
代码生成与集成阶段：阐述如何将经过验证的模型自动生成高质量、可读的嵌入式C代码，并概述生成的代码如何与底层软件集成，最终编译生成可刷写到电子控制单元（ECU）的目标文件。
实车部署与测试阶段：描述将集成后的软件部署到实车环境中的流程，包括ECU刷写、使用标定工具（如INCA）进行参数在线标定、信号实时观测以及多格式数据（如BLF/DAT/MF4）的采集方法。
数据分析与闭环优化阶段：重点介绍如何利用实车采集的数据进行回放分析，通过与仿真结果的对比，精确评估算法性能、诊断问题根源，并指导模型的迭代优化，形成"开发-测试-优化"的完整闭环。

2 模型开发

2.1 输入输出信号接口表

2.1.1 创建模型信号接口表

表中明确模型整体的输入输出，包括：信号的类型、信号释义、信号需求周期等；

2.1.2 维护模型内部信号接口表

若模型涉及多个子功能部分，由多人开发完成，需要将每个功能部分封装为（例图一）所示的模块，并维护每个子模块的输入输出信号表。

2.2 观测信号（Simulink.Signal）

2.2.1 观测信号是什么？

可以指定模型的输入/输出/中间计算过程的信号为观测信号，在Simulink仿真运行时可以查看观测信号的取值从而定位问题；在模型集成到实车上后，可以通过CAN设备采集（例如582/CANoe/同星等）这些观测量的值，从而分析与定位实车测试的问题。

2.2.2 如何制定观测信号？

右键单击信号线 → 选择属性 → 记录与设置观测量的名称 → 配置SLDD字典（按需）

注释：

只有选择了"信号名称必须解析为Simulink信号对象"并信号添加到SLDD数据字典（或者MAT文件中）中，模型集成和刷包到实车上后，才能通过CAN设备采集（例如582/CANoe/同星等）这些观测量的值，否则无法采集到这些信号。
如果只有离线仿真的需求，可以不用操作上述步骤（1），只需要设置观测变量名称和"勾选记录数据"即可在离线仿真环境观测这些变量的值。

在Simulink仿真运行时候，点击"网络"符号，可以查看模型所有观测量的计算结果（功能类似于Scope），如下所示：

2.2.3 为观测量配置SLDD字典

Simulink模型界面点击"模型资源管理器" → 选择"文件/新建/数据字典" → 新增观测量

2.3 标定信号（Simulink.Parameter）

2.3.1 什么是标定量？

标定量是一组在Simulink模型中定义的、数值可调整的变量或参数。核心特征是：在模型集成到实车后，这些参数的数值可以在不重新编译模型的情况下，通过外部标定工具（INCA/同星等）进行在线修改。

2.3.2 如何制定标定信号？

① 在MATLAB基础工作空间中设置标定量

% 创建Simulink.Parameter对象
OVP_Threshold = Simulink.Parameter;

% 设置参数值
OVP_Threshold.Value = 4.2;

% 设置存储类为'ExportedGlobal'，这样在生成代码时该变量将成为全局变量，可以被标定工具访问
OVP_Threshold.StorageClass = 'ExportedGlobal';

% 设置数据类型
OVP_Threshold.DataType = 'single';

% 可选-设置最小值和最大值(用于验证和标定工具中的限制)
OVP_Threshold.Min = 4.0;
OVP_Threshold.Max = 4.5;

% 可选-设置单位
OVP_Threshold.DocUnits = 'V';

% 可选-设置描述(说明该标定量的用途)
OVP_Threshold.Description = 'Battery cell over-voltage protection threshold';

注释：
（1）执行上述m脚本后，变量 OVP_Threshold 就会出现在MATLAB基础工作空间中。在Simulink模型里，就可以直接使用 OVP_Threshold 这个变量名，其值就是上述脚本定义的取值。
（2）如需要定义多个标定量，可按照上述脚本追加定义，最终将所有基础工作空间的标定量存储为mat文件；
（3）mat文件可以在sldd中导入，加载到sldd中；

2.4 模型的信号规范建议

当模型部署到车载ECU后进行实车测试时，已经不能再像Simulink环境那样可视化调试。因此，必须通过外部工具（如CANape/INCA/同星等）来监控（查看观测量）和调整（调整标定量）模型行为。因此这就要求开发人员在模型开发阶段就做好充分准备。

2.4.1 输入/输出信号的注意事项

● 对于模型的关键输入（如油门踏板、电池电压），必须添加信号观测、做合理性检查
● 对于模型的关键输出，必须添加信号观测、做合理性检查（例如取值范围）
● 建议：模型的输入可以设置为可标定形式
● 建议：模型的输出可以设置为可标定形式

2.4.2 观测信号的注意事项

观测信号命名规范：推荐命名格式：[模型缩写][子系统前缀][功能描述]_[信号类型]
- 子系统前缀：表明信号所属的功能模块
- 功能描述：清晰描述信号的意义，使用驼峰命名法或下划线
- 信号类型（可选）：有时可以加入类型后缀，使含义更清晰
  - _Cmd （命令）
  - _Act （实际值）
  - _Fdbk （反馈）
  - _Stat （状态）
  - _Err （错误）
- 示例
  - BMS_SOC_Display （BMS显示的SOC值）
  - VCU_Torque_Req_Cmd （VCU请求的扭矩命令）
观测信号选择原则
- 关键中间变量：不要只观测最终输入输出。要观测算法中的关键决策点和中间计算结果。例如，在扭矩计算中，观测驾驶员需求扭矩、系统限制后的扭矩、最终仲裁扭矩
- 计数器与计时器：软件看门狗、故障确认计数器等，对于诊断间歇性故障非常重要
  性能指标：如CPU占用率、栈使用情况等（如果ECU支持）

2.4.3 标定信号的注意事项

标定信号命名规范

推荐命名格式：Calib_[子系统前缀]_[功能描述]
- 强制前缀 Calib_：便于在代码和A2L文件中快速识别所有标定量
  - 示例：Calib_VCU_Torque_Max（VCU最大扭矩限制）

标定信号的设计原则

赋予合理的物理意义和范围：每个标定量必须有精确的单位、最小值（Min）和最大值（Max）。这既是为了安全，也是为了方便工程师理解
标定参数的耦合性：注意相关联的标定量。例如，修改一个阈值上限时，可能也需要相应修改下限。最好在文档中注明这些关联关系

2.5 模型开发规范

2.5.1 建模风格与规范

避免复杂逻辑

尽量使用Lookup Table替代复杂的数学运算，提高运行效率
- （1）对于复杂的非线性函数（如指数、对数、三角函数）或多次多项式，在嵌入式处理器（特别是低端MCU）上实时计算会消耗大量CPU资源。预计算的查找表通过"空间换时间"的方式，极大提升执行效率。
- （2）查表能确保输出结果的确定性和一致性，避免因浮点运算精度或不同编译器带来的细微差异。

禁止使用"魔块"

如Fcn模块、MATLAB Function模块中复杂的脚本，应使用基本的Simulink库模块（如Gain, Sum, Switch）实现，以保证生成代码的清晰度

循环与迭代

谨慎使用While Iterator等模块，必须有明确的迭代上限，防止死循环
- （1）嵌入式实时系统要求任务的执行时间必须是可预测的。while iterator模块的迭代次数在运行前未知，可能导致任务超时，进而引发系统级故障。
- （2）防止死循环：若循环退出条件永远无法满足，将导致软件死循环，看门狗复位，严重降低系统可用性。

除零保护机制

后果：除零操作会导致运行时错误，在嵌入式系统中可能引发处理器异常/系统复位或不可控
保护：在所有除法运算(Divide模块)前，必须对分母进行有效性判断

数组越界防护

后果：数组越界访问会破坏相邻内存数据，导致难以调试的随机错误，严重时可被恶意利用形成安全漏洞
保护：
- 使用Simulink标准查表模块（如lookup-table）时，必须配置外推/插值选项
- 当使用Selector模块或MATLAB Function进行数组操作时，必须手动添加边界检查

2.5.2 模块化与层次化设计

核心思想：高内聚，低耦合

将大模型分解为功能独立、接口清晰的子系统
- 高内聚：一个子系统（或模型引用）应仅专注于实现一个明确定义的功能（如"SOC估算"、“扭矩仲裁”）。其内部模块应紧密相关，共同完成该单一功能
- 低耦合：子系统之间的依赖关系应降到最低。它们通过定义良好的接口进行通信，而非直接访问或修改对方的内部数据。一个子系统的修改不应轻易导致另一个子系统出错

定义清晰的接口

每个子系统/模型引用都应通过输入/输出端口或配置型总线与外部交互
避免过度使用Data Store Memory等全局变量，以免造成隐蔽的数据耦合

子系统规范

规定每个子系统的功能描述、输入/输出信号清单、调用时序、复位逻辑等
- 在子系统的Description属性或内部的注释框中，详细说明其功能、算法原理和适用场景
- 明确每个端口的名称、数据类型、单位、物理含义和有效范围

2.6 模型验证与测试

2.6.1 静态测试

静态测试是指在不执行模型代码的情况下，通过分析模型结构、配置、代码和文档来发现缺陷的方法。其核心目标是预防错误，而非等待运行时才发现错误。静态测试是成本最低、效率最高的质量保障手段。通过建立严格的静态测试流程，可以将大部分设计缺陷消灭在萌芽状态，为后续的动态测试和集成测试奠定坚实的基础。

Model Advisor是Simulink内置的静态模型检查工具，主要用于检查模型是否符合建模规范，并提供自动或手动修改建议。主要操作步骤可以参考下述文档。

2.6.2 动态测试

动态测试是指在仿真或实际硬件上运行模型或生成的代码，通过输入测试用例，观察其输出行为，并与预期结果进行比较，从而发现缺陷的测试方法。其核心是"执行"和"比较"。

模型在环测试 Model-in-the-Loop (MIL)

定义

在PC上纯仿真环境下执行Simulink/Stateflow模型本身

目标

验证算法逻辑的正确性、早期发现设计缺陷

测试环境搭建

测试 harness 模型：创建一个顶层测试模型，将被测模型作为模型引用接入
输入激励：使用以下模块生成测试用例：
- Signal Editor：强大的信号组管理，可定义复杂的时序场景
- From Spreadsheet：从Excel导入测试向量
- From Workspace：从MATLAB基础工作空间加载数据
- Repeating Sequence / Sine Wave：生成标准波形
输出与验证评估：
- Check Static Range / Assertion：在仿真过程中实时检查信号是否超出预期范围或满足特定条件
- To Workspace / To File：记录仿真结果，用于事后分析
- Scope / Dashboard：用于实时观察波形，进行交互式调试

测试类型与用例设计

测试覆盖度分析：（Simulink Coverage）用于分析测试用例对模型结构的覆盖程度
需求覆盖测试：为每一条功能需求设计正向测试用例，验证需求被正确实现
正常工况测试：模拟系统在正常工作范围内的各种输入组合
边界值测试：针对输入、输出和参数的边界值（如最小值、最大值、刚超过边界的值）进行测试
异常与故障注入测试：模拟传感器故障、执行器失效、通信超时等，验证模型的诊断和处理机制（如默认值输出、安全状态切换）

软件在环测试 Software-in-the-Loop (SIL)

定义

将模型生成的C/C++代码编译成宿主机的可执行文件（如Windows的.dll或.exe），并在PC上运行，与MIL的仿真结果进行对比

目标

确保从模型到代码的转换没有引入错误、确认生成的代码与原始模型在数学上是等价的

测试流程

生成代码：从模型生成C代码
创建SIL测试环境：在Test Manager中创建SIL测试，自动生成SIL模型（用生成的代码替换原模型）
运行测试：执行相同的测试用例，比较SIL测试结果与MIL测试结果
背对背比较：确保SIL测试结果与MIL测试结果一致（在一定容差范围内）

3 代码生成与集成

代码生成与集成是将Simulink模型自动转换为高质量、可读、高效的C/C++代码，并将其与底层软件（操作系统、驱动、通信栈等）整合，最终部署到目标ECU的过程。（一般由专门负责集成的同事执行）

3.1 代码生成配置

系统目标文件选择

决定了代码的整体结构和风格
- ert.tlc：生成高度优化、紧凑、适用于资源受限嵌入式系统的ANSI/ISO C代码。这是最常用、最推荐的选择
- autosar.tlc：用于符合AUTOSAR标准的项目，生成AUTOSAR软件组件（SWC）的代码和描述文件（ARXML）
- grt.tlc：生成更适合快速原型的代码，代码可读性更强但优化较少，会包含更多用于PC环境执行的逻辑。不推荐用于最终的车规级ECU产品

语言标准

C89/C90 (ANSI)：兼容性最广的标准，几乎被所有嵌入式编译器支持。是最安全/常用的选择
C99：提供了一些现代特性（如//注释、内联函数、变量声明位置灵活）。如果编译器明确支持C99，可以选择此项以获得更简洁的代码
3.2 代码生成输出

生成代码

步骤：Simulink Coder/Embedded Coder将执行以下步骤：模型编译 → 代码生成 → 编译 → 生成报告。（展示生成代码的结构、文件列表、接口信息、堆栈使用量估计等）

生成的文件

model.c 和 model.h：模型的入口函数（step函数）和主要算法
rtwtypes.h：定义与目标硬件相关的标准数据类型
model_data.c：包含模型参数（标定量）的初始化值

3.3 代码集成

将生成的应用层代码与底层基础软件相结合的过程。主要的输出物为集成好的软件包，包括：

ECU可执行程序文件

这是一个已编译链接好的、可直接刷写到ECU微控制器中的十六进制可执行文件
常用的文件格式：s19格式和hex格式
主要用途：
- HIL测试：将该文件刷写到HIL台架的ECU中，进行系统测试
- 实车标定：通过标定工具（如CANape）将其下载到实车ECU中
- 生产线终端刷写：在车辆生产结束时，通过刷写设备将软件写入ECU

A2L文件

连接Simulink模型与外部标定世界的"地图"
生成方式：由Embedded Coder在代码生成过程中自动生成，其内容直接来源于Simulink模型中Simulink.Parameter和观测量等设置
功能：描述了观测/标定等信号在ECU的内存地址
使用场景：
- 打开CANape或INCA，加载这个A2L文件
- 软件根据A2L文件提供的信息，自动识别出ECU中所有可标定和可观测的变量
- 提供友好的图形化界面进行修改和观测