K4-02 · 控制、软件与标定 / 嵌入式软件与开发
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 能按可维护、可复用的原则搭建控制模型的Simulink/Stateflow架构（子系统划分、接口定义）
- 能选择定点/浮点数据类型并核算量化误差对控制精度的影响
- 能用 MAB 建模规范（旧称 MAAB）和 MISRA C 约束模型，减少代码生成后的静态分析问题
- 能用代码度量报告与链接 map 文件核算生成代码的 ROM/静态 RAM 占用，并知道执行时间只能靠 PIL 或目标端实测、读不出于代码生成报告
- 能建立需求→模型→生成代码的追溯关系，支撑后续SIL验证
内容大纲
- MBD 在热管理软件开发里的位置
- V模型里MBD覆盖的阶段：从控制需求到模型，再到自动代码生成——这里的「控制需求」不是一段自然语言策略描述，而是条目化、每条带验证方法与 owner 的控制功能规格（见 K4-07）
- 与手写代码对比：一致性、可仿真验证，但生成代码可读性/效率是权衡项
- 承接K3系列控制算法（如K3-05 PID、K3-06 MPC）——模型建的就是这些算法
- 谁来建模、谁来评审：控制工程师建模型，软件工程师看生成代码与集成
- 建模入口检查：每个子系统/Runnable 都要能指回控制功能规格里的一条条款，指不回的就是无源功能，评审时打回（前指 K4-07）
- 模型架构与接口划分
- 顶层-子系统-原子子系统的层次划分，接口（Inport/Outport/总线信号）清晰定义
- Stateflow做状态机（模式切换逻辑，呼应K3-01整车热管理模式管理）
- 模型里标定量与常量的区分：哪些做成可标定的参数对象（前指 K6-10）；本课只管模型侧的标定量/常量划分，参数对象的轴点、上下限、插值/外插保护与存储区规格归 K6-10
- 建模规范与代码静态分析：MAB 与 MISRA C 两道扫描闸
- MAB Modeling Guidelines（MathWorks Advisory Board；2020 年 v5.0 起由旧称 MAAB 改此名，日本侧另有独立维护的 JMAAB 指南）：命名、图形复杂度、禁用模块——落地靠 Simulink Check 的 Model Advisor 检查集合与项目级 check 清单自动扫，人工评审只兜底
- MISRA C:2012对生成代码的约束，静态分析工具扫出的典型问题
- 定点化与数值精度
- 浮点还是定点，看三件事：目标芯片有无硬件 FPU 及其单/双精度性能、既有代码基线的数据类型约定、ROM 与执行时间预算——带 FPU 的车规平台（AURIX TC2xx/TC3xx、S32K3、RH850 一类）上单精度浮点部署已是常态；定点留给无 FPU 的低端节点控制器与智能执行器、资源极紧、或需位精确复现老基线的场合
- Q格式定点表示：字长、小数位数决定分辨率与量程的权衡
- 量化误差对控制回路的影响：过热度这类小信号对分辨率敏感，粗量化会引入极限环
- 自动定点转换工具与人工核算的取舍
- 自动代码生成与资源、执行时间核算
- Embedded Coder / TargetLink 的代码生成流程与关键配置项
- 生成代码的结构：初始化函数、周期步进函数，与RTE/AUTOSAR的接口映射（衔接K4-01）
- 代码效率报告读出的是静态代码度量与内存估算：ROM/静态 RAM 以目标编译器/链接器的 map 文件为准（受优化等级影响），最坏栈用量另做栈分析，报告数只当早期预估
- 常见的“模型能跑但代码超资源”问题排查思路
- 执行时间不在代码生成报告里：SIL 剖出的是主机 CPU 时间，只有 PIL（生成代码跑在目标处理器/评估板上）或目标端 profiling、OS 任务时序跟踪测到的单步与最坏执行时间才代表 ECU 时间；判据写成「最坏单步执行时间相对任务周期留多少裕量」，对上 K4-01 的 CPU 利用率核算（关卡序列见 K4-03）
- 模型与代码一致性验证的雏形，完整展开在K4-03
- 追溯矩阵与覆盖率：交给 SIL 验证的出口证据
- 需求-模型-代码的追溯矩阵，变更时能定位影响范围
- 模型覆盖率四类：语句 / 判定（分支）/ 条件 / MC-DC，为 SIL 阶段测试用例设计打基础；选哪一档由被测功能的 ASIL 决定而不是越高越好（MC-DC 是高 ASIL 才强制的高推荐项，定级依据见 K2-03，分档表见 K4-03），热管理软件常见档位下判定/条件覆盖即够
- Stateflow 状态机另计状态覆盖与迁移覆盖：判定/条件覆盖对状态机不充分；覆盖率只回答「测到没测到」，回答不了「这条迁移能不能发生」——不可达状态、死迁移、迁移空洞与互斥条件缺失要靠形式化性质检查（Simulink Design Verifier）自动检出，完整方法见 K4-05
- 模型覆盖率 ≠ 代码结构覆盖率：代码生成后新增的分支（饱和限幅、数据类型转换、除零保护等防御代码）不在模型覆盖率的分母里，必须在代码侧另行测量——这正是 back-to-back 与 PIL 存在的动机之一，展开见 K4-03
关键公式
y_q = round(x / LSB)·LSB，LSB = 量程 / 2^n
定点量化：n位字长下的最小分辨单位LSB，决定信号能分辨的最小变化量
e_q ∈ [−LSB/2, +LSB/2]
定点量化误差界，字长过小时这个误差量级会接近控制回路本身要分辨的信号量级
覆盖率 = 已执行判定分支数 / 总判定分支数
这是「判定（分支）覆盖」这一档的定义式，不是覆盖率的唯一定义——语句/条件/MC-DC 各有各的算法；MC-DC 的判定准则是每个条件都至少有一次独立改变判定结果的用例。属 SIL 阶段的基本出口指标之一，与需求覆盖率互不替代
ROM_used/ROM_budget < 1，RAM_used/RAM_budget < 1
代码生成后的资源占用核算，超预算就要精简模型或换更大芯片，是架构决策的硬约束
关键概念
Simulink/StateflowMAAB规范定点化Q格式量化误差Embedded CoderTargetLink模型覆盖率MISRA C追溯矩阵代码效率原子子系统PIL（处理器在环）MC-DC状态覆盖/迁移覆盖硬件 FPU
推荐工具与标准
Simulink/Stateflow Embedded Coder / dSPACE TargetLink Polyspace（静态分析） Fixed-Point Designer Git（模型版本管理，衔接K4-04） Simulink Check（MAB 规范的 Model Advisor 检查集） Simulink Design Verifier（形式化性质检查：不可达状态、死迁移） Simulink Coverage（模型层覆盖率度量）
MISRA C:2012 ISO 26262-6（软件单元设计与实现） MAB 建模规范（MathWorks Advisory Board，旧称 MAAB，2020 年 v5.0 起改此名；体系名、非编号标准，按版本号迭代；日本侧另有独立维护的 JMAAB 指南）
工程案例
某车型电池冷却回路的过热度PID控制模型，浮点仿真表现良好，定点部署后出现小幅振荡。排查发现积分项用了字长偏小的定点类型，量化误差在小信号区被放大成极限环；把积分项字长上调、调整比例系数的定点表示后振荡消除。
动手做
交付物 · 给定过热度PID控制的Simulink浮点模型：① 按 MAB 建模规范（旧称 MAAB）整理子系统结构与接口，用 Model Advisor 对应检查集跑一遍；② 设计定点方案（关键信号字长与LSB），核算量化误差是否可接受；③ 核对生成代码 ROM/静态 RAM 占用（以链接 map 文件为准）与预算对比，并注明单步执行时间须 PIL/目标端实测、不能用报告估算代替。交付架构图+定点方案表+核算表。
常见误区
- 模型子系统划分随意，一个子系统混了输入处理/控制逻辑/输出限幅，复用和测试都困难
- 定点字长凭经验拍板，没有核算量化误差相对控制信号本身量级的比例
- 只在浮点下做过仿真验证就直接生成代码部署，没做定点/生成代码的back-to-back对比
- 模型里把标定量写成硬编码常数，代码生成后标定工程师改不了，只能改模型重新生成
- 生成代码超出ROM/RAM预算才发现，模型设计阶段完全没核算资源
- 拿代码生成报告的估算、或 SIL 剖出的主机 CPU 时间当 ECU 执行时间用——任务超时要拖到 HIL 甚至整车才暴露
- 不看目标芯片有没有硬件 FPU 就默认走定点，在带 FPU 的平台上白付定标设计、量化误差核算与标定沟通的成本
- 拿模型覆盖率报告当作代码结构覆盖率证据提交——生成代码里新增的防御分支从来不在模型覆盖率的分母里
相关课题