K7-02 · 控制、软件与标定 / 智能与软件定义
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 能区分标定参数 OTA 与控制逻辑/代码 OTA 的风险等级差异
- 能画出一次 OTA 从云端下发到车端生效的技术链路
- 能识别哪些热管理相关参数/逻辑受功能安全约束、不能随意 OTA
- 能设计一个包含灰度放量与回滚门限的最小发布流程
- 能判断一次 OTA 迭代的收益是否有统计显著性，而不是凭感觉
内容大纲
- 软件定义热管理的架构含义
- 硬件能力与控制逻辑解耦：同一套硬件靠软件差异化不同车型/工况策略
- 控制策略从'固化标定表'变成'可迭代软件资产'
- 与传统方式对比：过去改策略要等下一次改款，现在理论上随时能改
- 解耦带来的代价：软件复杂度、测试覆盖面、责任边界都要重新定义
- OTA 技术链路与升级包形态
- 域控/网关 OTA 架构：云端下发、车端接收、刷写、生效四个环节
- 全量包与差分（增量）升级包：包大小、刷写时间、失败概率的权衡
- 标定参数 OTA vs 可执行代码 OTA：改的是'数值'还是'逻辑'，风险等级完全不同
- 刷写失败与回滚：A/B 双分区、数据不回退与热安全准入
- 升级中断/失败的回滚机制：断电、信号丢失场景下车辆不能变砖——实现该意图的主流机制是 **A/B 双分区（双备份）刷写**：写备区、校验通过再切换启动分区，失败则留在原分区，全站此前未点名这个词
- ⚠ 固件可回，数据未必可回：A/B 双分区保的只是可执行代码这一侧，车端持久化数据（标定 NVM、自适应/学习值、诊断历史与累计量）不随分区切换回退。回滚后的典型现场表现是「版本号已显示回到旧版，行为却仍是新版的」——因为数据结构已按新版做过迁移，且自适应/学习值需要单独定义清除策略。升级引入 NVM 数据块布局变更时的版本迁移（旧学习值结构不兼容导致执行器行为异常且极难定位）见 K4-06，本课只留这条接口句
- 刷写窗口的热安全前置条件与执行器状态约束要写成准入条件，不能只在流程图上写「进入刷写」：刷写期间压缩机/水泵/风扇是按最后一帧目标继续运行还是切固定安全档、是否禁止模式切换与高压上电、进入刷写的电池温度窗口与 SOC 下限、刷写期间热监控由谁接管（域控自身在刷写就必须有接管方，否则降级到硬件保护如温控开关/熔断器）、刷写失败回滚时各执行器停在什么位（阀的默认位、风扇的默认占空比）。工况与场景标志位的定义见 K3-15；签名与防回滚判据不在此重讲（K2-04），本条只补热侧准入与执行器约束
- 参数锁定分级、功能安全与监管准入
- 功能安全约束：涉及热失控保护等安全相关的逻辑不能像普通标定一样快速走灰度
- 网络安全基础：签名校验、加密传输、防篡改（链 K2-04）
- 哪些参数允许远程改、哪些必须锁定在产线/授权工具才能改，要有分级清单——每行至少三列：权限等级（可远程改／需授权工具／产线锁定）、变更审批级别、**回滚可逆性**（可反向迁移／只能清除重学／不可回退）。这张清单还有个对外授权版（授权给哪家供应商、授权怎么撤销），见 K4-09
- OTA 变更的合规留痕：改了什么、谁批准的、影响范围，要可追溯
- 留痕的外部收口是监管准入，不只是内部可追溯：软件变更要按三档判定——哪些只需内部留档、哪些须向主管部门备案后方可下发、哪些涉安全变更须审批通过才能放量，以及哪一类 OTA 会被直接认定为召回的实施方式。标定表与控制逻辑的推送同样可能越过型式批准边界（R155/R156 与 SUMS 层面、国内 OTA 备案/审批）。发布流程必须与这三档挂钩，否则灰度放量本身就是违规下发；判定规则与备案流程见 M4-08，本课只讲发布工程（灰度、回滚门限、参数锁定分级），合规准入不在此重讲
- 当下发对象是「学到的模型」（自学习/数据驱动策略）而不是标定数值时，验收要多三项：①随版本一起声明训练分布与可信域——模型在哪些工况上被证明过，可信域变了就是接口变更，不是参数微调；②回滚必须把模型与它的可信域声明**一起**回滚，只回代码会留下「新可信域配旧模型」的悬空状态；③安全相关逻辑的评审要补的证据是触发条件覆盖与失效降级路径（可信域外靠什么检出、降级到哪一档兜底），而不只是「不能像普通标定一样快速走灰度」这句禁令。论证方法见 K2-05
- 灰度发布：回归门禁、分批放量与回滚门限
- 灰度放量的门禁前提：**发布前回归已通过**才允许进入灰度——回归基线与激励库、回归范围裁剪、自动执行与失败分诊见 K4-08；CI/CD 流水线在此的职责是把构建、签名、回归套件执行与灰度批次下发串成一条可审计的门禁链，回归未过的包根本进不了下发队列，而不是靠人记得别点发布。门禁过了才谈节奏：小比例试点 → 观察窗 → 逐步扩大，而不是一步到位
- 每一批放量要设观察指标和回滚门限，出问题能及时止损
- 车队数据回流与统计显著性判断
- 车队数据回流评估新版本效果：不能只看台架/实验室数据
- 统计显著性判断：样本量不够时'看起来更好'可能只是噪声
- 车队数据是聚类/重复测量结构，不能当独立样本喂进样本量公式：同一台车多次行程之间强相关，车间差异与驾驶员/路线差异通常远大于车内差异——把「行程数」直接当 n 会把有效样本量虚高一个量级。优先用同车升级前后配对（每台车出一个差值）或混合效应模型，σ 取车内残差标准差而不是总标准差；样本量的计数单位是**车**，不是行程
- 评估用的回流数据不是天然就有的：本次评估需要哪些信号、多大采样率、用什么触发条件采样，必须在版本下发**之前**声明并随灰度包一起下发采集配置——样本量公式决定的是要多少台车，采集口径决定的是每台车上到底算不算得出这个指标。采集侧设计见 K7-03
- 于是灰度车的信号覆盖度成了统计判断的前置条件：要证明的结论所需信号是否已在灰度车上采到、采样频率与工况覆盖是否够，不满足时样本量再大也证不出结论。信号表反推、事件抓帧与带宽/存储预算见 K7-04；本课仍只管灰度节奏、回滚门限与统计显著性本身
- 回流数据的第二个用途是现场误报统计：某条保护/诊断阈值在真实车队上的误报率与漏报率，是整定的唯一现场证据；「该收紧还是放宽、移多少」的判据见 K5-07。但再整定的结果要回到车上，仍走本课这两道闸——限幅 K_new = clip(K_old + ΔK_ota, K_min, K_max)，且安全相关参数不得走快速灰度
- 工程实践的组织协同
- 软件迭代节奏与硬件冻结点的错配：软件想快迭代，硬件/供应链跟不上
- OTA 与诊断（DTC）、标定版本管理的联动（链 K4-04、K5-01）
- 跨部门协同：整车厂、Tier1、云平台谁负责哪一段的验证与签署——这不是靠会议纪要定的，DIA 分派表、证据包互认与签字之后的缺陷责任划分见 K4-09，本课只给接口不展开
- 版本兼容矩阵：软件版本 × 硬件变型 × 标定版本三维校验，缺一格不能下发
关键公式
K_new = clip(K_old + ΔK_ota, K_min, K_max)
OTA 下发的标定参数增量必须限幅在预先定义的安全包络内，不能无限外推到未验证过的区间
灰度比例序列：p₁ < p₂ < … < 100%（如小比例起步、逐步倍增）
分批放量的基本规则：每批设观察窗与回滚门限，出问题时影响面随批次可控，而不是一次性全量
n_每组 ≈ 2σ²·(z_(α/2)+z_β)²/δ²（灰度组 vs 对照组，两独立组）｜n_配对 ≈ (z_(α/2)+z_β)²·σ_d²/δ²（同车升级前后配对，σ_d 为配对差标准差，不乘 2）
判断新旧版本某项指标（如能耗、噪声）差异是否统计显著所需的车队样本量估算：δ 为要检出的最小差异（MDE），z_(α/2) 对应双侧显著性水平 α，**z_β 对应检验功效 1−β**，σ 取组内标准差（配对设计取车内残差标准差）。⚠ 流传很广的写法 n ≈ (z_(α/2)·σ/δ)² 是**单组区间估计**式（等价于真差恰为 δ 时约 50% 功效），拿它做版本比较会系统性低估样本量——α=0.05 时，功效 50% 低估约 2.0 倍、80% 约 4.1 倍、90% 约 5.5 倍，正好把学员推进本课自己列的「样本量不够时看起来更好只是噪声」那个坑。记两条边界：漏 z_β 在任何设计下都是错的；2 倍系数只对两独立组成立，同车前后配对不乘 2。A/B 分组评估的完整做法见 K7-03
ΔSize_diff ≈ Size_full − Size_common
差分升级包大小近似等于全量包减去与车端已有版本重合的部分，直接影响刷写时间与失败概率。⚠ **差分率由新旧镜像的字节级相似度决定，不是源码改动量**——链接布局位移、函数地址整体平移、编译器内联与常量池重排，都会让「只改一行」产出接近全量的差分包。所以刷写窗口与失败率预算要按**实测差分率**排，对布局敏感的模块保留全量兜底
关键概念
软件定义汽车 SDVOTA差分升级灰度发布回滚机制功能安全 ASIL签名与防篡改版本兼容矩阵A/B 验证参数锁定分级检验功效 1−β 与样本量估算（配对/两独立组）
推荐工具与标准
OTA 云端管理平台（域控 OTA 下发/监控） AUTOSAR（Classic/Adaptive，软件架构基础） CI/CD 流水线（软件构建与灰度发布联动） 代码签名/HSM 工具链 车队数据回流分析平台
ISO 24089（道路车辆软件更新工程） ISO/SAE 21434（道路车辆网络安全工程） ISO 26262（功能安全，OTA 变更管理的接口约束） UN R156（车辆软件更新与 SUMS；准入判定、备案与召回口径见 M4-08） GB 44496-2024（汽车软件升级通用技术要求，强制性国标，2024-08-23 发布；新申请型式批准车型与已获型式批准的在产车型分档执行，具体实施时点按现行版本与主管部门公告确认。与 GB 44495-2024《汽车整车信息安全技术要求》配套，是境内 OTA 落地的强制判据；与 UN R156 的适用口径对照见 M4-08）
工程案例
某车型 SOP 半年后，某工况下压缩机启停过频、噪音投诉集中；不改硬件，通过 OTA 下发新标定，先在小比例灰度车队验证噪音与能耗指标，确认无退化再逐步扩大放量；期间某批次因边界参数设置不当触发过热保护误报，靠回滚机制及时止损，未扩大到全量车队。
动手做
交付物 · 针对某个热管理控制参数（如目标蒸发温度）设计一次 OTA 迭代方案：①判断该参数改动是否触碰功能安全红线，给出判断依据；②画出灰度放量的分批比例与每批的观察指标/回滚门限；③写出该版本上线后如何用车队回传数据判断'这版真的更好'。
常见误区
- 把热失控保护阈值这类安全相关逻辑当普通标定参数一样走快速灰度，跳过功能安全变更评审
- OTA 只测过'升级成功'，没测'升级失败/中断后能否安全回滚'，断电、信号中断场景没有兜底
- 灰度放量比例定得太粗（比如直接推给较大比例车队），出问题时影响面过大、止损代价高
- 只用实验室/台架数据判断 OTA 收益，没用车队回传数据做统计显著性验证，凭感觉判断'这版更好'
- 版本管理混乱：标定版本、软件版本、硬件变型没做三维匹配校验，OTA 后出现参数与硬件不匹配的问题
- 把单组区间估计式 n ≈ (z_(α/2)·σ/δ)² 当成版本 A/B 比较的样本量判据——漏掉功效项 z_β，所需样本量被低估 2～5 倍（功效越高低估越多），于是「小比例灰度看着没退化」被当成已验证，提前全量放量
相关课题