MIL/SIL/HIL 验证流程

课程大纲

• 能说清 RCP/MIL/SIL/PIL/HIL 各级的被测对象、测试目的与不能相互替代的原因，并区分「在环形态」与「测试层级」这两条正交维度
• 能设计一台热管理HIL台架的基本架构（真实ECU+被控对象实时模型+激励/负载模拟）
• 能核算被控对象实时模型的步长与保真度是否满足HIL实时仿真要求
• 能设计覆盖正常/边界/故障工况的测试用例，并用覆盖率指标评估测试完整性
• 能通过故障注入验证控制器的降级与安全响应逻辑

1. 在环阶梯 RCP→MIL→SIL→PIL→HIL，与正交的测试层级维度
   • MIL（Model-in-the-Loop）：控制模型与被控对象模型都在PC里仿真，验证算法逻辑本身
   • SIL（Software-in-the-Loop）：把生成的目标代码接入仿真环境，验证代码与模型行为一致（back-to-back）
   • HIL（Hardware-in-the-Loop）：真实ECU接实时仿真的被控对象模型，验证软硬件在真实电气环境下的表现
   • 为什么不能跳关：MIL 测算法对不对，SIL 测代码有没有引入偏差，PIL 测目标芯片上的实现与执行时间，HIL 测真实硬件与电气环境；每一级都能抓住上一级抓不到的问题，跳级等于把那一类问题留到整车上第一次暴露
   • RCP（旁路标定/快速原型）：策略还没进量产 ECU 时，用外挂原型硬件（dSPACE MicroAutoBox、ETAS ES910 类）旁路量产 ECU 的目标功能，在实车上边跑边在线改参数，是软件开发与实车验证并行的唯一手段；边界必须写死——bypass 只接管被旁路的那部分功能，其参数不进 A2L 主线，RCP 上标出的值只能当量产软件的标定初值，不得直接作为放行结果（下游承接见 K6-01）
   • PIL（Processor-in-the-Loop）：生成代码在目标处理器/评估板上运行、被控对象模型仍在 PC 侧闭环，专测 SIL 测不出的三类问题——目标编译器优化引入的行为差异、目标芯片上的位精确性（定点/浮点实现差异，衔接 K4-02 定点化）、单步任务的实测执行时间（对上 K4-02 的 ROM/RAM/执行时间预算）；它补的正是 SIL 与 HIL 之间常被跳过的那一格
   • 在环形态之外还有一条正交的维度——测试层级：软件单元验证（被测对象＝单个模块，出口＝单元用例通过 + 结构覆盖达档）、软件集成验证（被测对象＝模块间接口与数据流，出口＝接口用例通过 + 集成缺陷收敛）、软件合格性验证（被测对象＝整包软件对需求规格的符合性，出口＝需求覆盖率达标 + 合格性测试报告）；同一层级可以在不同在环形态上跑，别把「跑在 HIL 上」直接当成「做的是合格性测试」
   • 三个测试层级与软件测试过程域的对位：单元/集成/合格性分别对应 Automotive SPICE 的 SWE.4/SWE.5/SWE.6，每层要留的工作产物是同一套四件——测试规格、测试用例集、测试结果记录、与需求条目的双向追溯链；本课已有的「需求覆盖率」公式正是合格性层评估时的核心证据指标。能力等级与评估视角本身见 K4-04
2. MIL 与 SIL：算法逻辑验证与 back-to-back 代码一致性
   • MIL阶段的被控对象模型精度要求：够反映系统动态特征即可，不追求最高保真
   • SIL阶段的目标：验证代码生成/定点化没有引入行为偏差（衔接K4-02的量化误差话题）
   • back-to-back测试：同一组激励下比较模型输出与代码输出的差异，设阈值判定通过
   • SIL可以跑在非实时的PC上，比HIL便宜快，适合跑大批量回归测试
3. HIL 台架架构：实时机与 I/O、被控对象实时模型步长、故障与场景注入能力
   • 核心组成：实时仿真机（跑被控对象实时模型）+ I/O 接口机箱 + 总线仿真板卡 + 被测 ECU；三层时基各管各的——主模型按 ms 级步长跑热/流动态，PWM、转速脉冲、H 桥电流采样这类快信号由 FPGA I/O 板卡按硬件时基处理，CAN/LIN 报文由总线板卡加协议栈承担
   • 被控对象实时模型的来源：从一维系统仿真降阶而来，需兼顾精度与实时计算能力（衔接J1-04）
   • 步长与实时因子：仿真步长的计算耗时必须小于对应的物理时间步长，否则“跟不上”真实时间
   • 电气故障模拟：开路/短路/信号漂移等注入能力，衔接K1-01信号诊断的验证需求
   • 真实部件在环（半实物）形态：把真实压缩机/空调箱/冷媒回路接进台架，车厢与电池负载仍走虚拟模型、NTC 用阻值注入、执行器接电气负载模拟——这种形态主要服务标定而不是纯验证。经济性边界要先算清：热惯性时间常数远大于控制步长，一轮降温工况在环就要真占几十分钟台架时间，而带真实 ECU 的在环台架做不了时间缩放（ECU 跑自己的晶振时钟，缩时会把任务周期与滤波器时基一起缩掉），想提速只能退回 MIL/SIL 纯虚拟层、代价是丢掉真实部件的非线性。哪些量能虚拟筛选、哪些必须半实物、哪些必须回实车验收，见 K6-04 与 K6-13
   • 故障注入之外还要有场景层注入能力：在台架上直接注入场景触发信号的组合（档位、车速、充电握手、门锁、座椅占位、坡度、日照），用来验证场景判定与「场景→模式请求」的映射是否如预期，而不是只注入部件故障；场景定义表与「场景→模式请求」映射表见 K3-13；逐场景判据见 C6-05/K7-01/C6-04/D4-03
4. 测试用例设计：四类工况与从需求到用例的取点方法
   • 正常工况：典型驾驶循环下的控制响应（如压缩机启停、多通阀切换）
   • 边界工况：极限温度、极限负荷、传感器量程边缘
   • 故障工况：传感器/执行器故障注入，验证降级策略（衔接K5-02）
   • 在正常/边界/故障之外并列第四类注入——无故障的纯资源竞争注入：多路热需求同时到场、同时把功率与冷量预算收紧，验证仲裁结果的可预期性。它与 K5-02 的「失效叠加极端环境」不同，这里所有部件都是好的，出问题的是仲裁本身
   • 从需求到用例的取点方法：① 阈值型参数（模式切换温度门限、迟滞带上下沿、最小驻留时间、去抖时间）按边界值取点——门限 ± 一个分辨率、恰好落在迟滞带内、驻留时间恰好差一个周期，这三点是模式抖动类缺陷的高发区；② 仲裁/降级这类多条件规则用判定表（条件组合 × 动作）展开，先补全规则再压缩；③ 本课只做用例设计方法，连续物理因子的试验点压缩仍归 K6-01/J7-03 的 DOE，两侧互相挂链、不重讲
   • 离散组合场景的用例设计：把「需求源 × 工况 × 预算档」的组合空间先做等价类划分，再取边界组合与成对（两两）覆盖，按优先级剪枝——这是把 K6-01 的 DoE 思路从连续物理因子迁到离散场景空间，DoE 本身不在这里重讲
   • 仲裁/降级逻辑的病理场景必须单独进用例集：两方互相等待的循环依赖用例、低优先级需求长期饥饿的长时序用例。这两类靠随机工况和分支覆盖率测不出来——覆盖率数字可以很好看而问题仍在，必须由 K4-05 的静态性质核对配上本课的定向长时序用例，双管齐下
5. 覆盖率与出口判据：需求／结构／状态迁移／场景，以及未覆盖项的处置
   • 需求覆盖率与测试用例矩阵，避免「测了很多但没测到关键需求」；该指标的分母「总需求数」只有在需求已条目化、每条带明确的验证方法与验证层时才成立，否则覆盖率数字本身就是失真的——上游修法在需求侧，见 K4-07
   • 结构覆盖阶梯与定档依据：语句覆盖 < 判定（分支）覆盖 < MC/DC，逐级更严——复合布尔式「T_bat>T1 && SOC>S1 && !故障」在判定覆盖下两条用例就满分，但「每个条件能否独立改变输出」根本没被验到；档位由 ASIL 决定而不是越高越好，ISO 26262-6 的结构覆盖推荐表里语句覆盖对低 ASIL、分支覆盖对中高 ASIL 为高推荐，MC/DC 只对 ASIL D 为高推荐，热管理软件多落在 QM~ASIL C（定级见 K2-03）。需求覆盖率与结构覆盖率是两类互不替代的出口判据：前者答「该测的测了没」，后者答「代码里还有没有从没跑到的地方」，缺任何一类都不算过出口
   • 被测对象是状态机时，出口判据须再加上状态覆盖与迁移覆盖：每个模式、每条迁移至少一条用例，迁移条件里的阈值与迟滞带按边界值取点。但要认清动态测试的原理性上限——它测不出「这个组合从来没被写进规则表」，遗漏的规则不会在任何一条用例里失败，只能靠 K4-05 的静态核对前置拦截
   • 场景判定的覆盖度验收：把量产车的真实信号流灌回 HIL/SIL 做日志回放，判据＝场景全集清单里每个场景至少一条回放用例，并统计场景误判率；覆盖率指标相应在「需求覆盖率」「结构覆盖率」之外再加一栏「场景覆盖率」
   • 未覆盖项的处置流程：覆盖率跑不满时按四条分流——(a) 需求在、用例缺 → 补用例；(b) 防御性/容错代码在正常激励下不可达 → 用故障注入去激活，仍不可达则书面论证并留档豁免；(c) 代码生成器产生的不可达分支（如定点饱和保护）→ 归为工具产物，随代码生成器版本一并说明；(d) 真死代码/死迁移 → 删除，并回溯是哪条需求作废后没同步。任何一条都不许直接把它从分母里抹掉；死迁移「能不能发生」的判断交给 K4-05 的静态核对，动态覆盖率只负责发现「没跑到」
6. 从 HIL 到整车：保真度上限、回归与标定复用、跨企业分工的边界
   • HIL台架的被控对象是模型，无法完全复现真实流体/热惯性的所有非线性
   • 整车/环境舱试验仍是最终确认，HIL是把问题尽量提前拦截
   • HIL 回归测试在软件迭代中的持续集成价值：把典型/边界/故障场景固化成可版本管理的激励库，提交时在 SIL 上跑冒烟子集、夜间在 HIL 上跑全量回归并出覆盖率与差异报告——「每次代码变更自动跑一遍」要真成立，靠的是基线、回归范围裁剪与失败分诊这一整套机制，展开见 K4-08
   • 常见的“HIL过了、整车不过”的原因：模型保真度不足、线束/EMC等台架未覆盖的因素
   • 定位说明：HIL/SIL 台架除了做验证，还能反过来当标定台架用——在上面跑标定循环、批量注参数集、夜间跑回归标定，这条线归 K6-13；本课只管「验证」这一侧，两者的出口判据别混在一张表里
   • 联合 HIL 的分工（本课只给定位，本体见 K4-09）：台架归属（OEM 台架 / Tier1 台架 / 第三方）、用例来源（谁出正常、边界、故障注入用例）、通过判据由谁编写、报告由谁签署，以及「对方台架出的结论我认不认、要不要抽样复测」——热管理域控大量走 Tier1 交台架结论，这套分工不谈清楚，验证证据链在跨企业交界处就断了

• 把MIL阶段验证过的算法直接当成“已验证”跳过SIL，代码生成/定点化引入的偏差没人测到
• HIL被控对象模型为了图省事过度简化，关键动态（如换热器热惯性）被降阶掉，HIL测试形同虚设
• 只测正常工况，故障注入和边界工况覆盖不足，故障降级逻辑在整车上才第一次被真正触发
• 仿真步长设得比实际需要粗，实时因子看着达标，但关键快动态（如压力脉动）被步长滤掉
• SIL/HIL测试用例长期不随需求变更更新，需求改了测试矩阵没跟着改，覆盖率数字失真
• 只按单因子逐一扫用例，组合场景靠碰运气——快充 + 严寒 + 除霜三者叠加这类组合从来没被枚举过，直到实车上才第一次出现（对接 K3-07 规则表未覆盖组合的问题）
• 为把覆盖率刷满而编造与需求没有对应关系的用例，或者干脆删掉不好覆盖的防御性代码——覆盖率数字达标了，鲁棒性反而被削掉
• 把「SIL 回归全过」直接等同于软件验证充分，忽略 PIL 与 HIL 才能暴露的目标芯片行为、执行时间与真实电气问题
• 拿模型覆盖率报告冒充代码结构覆盖率证据——代码生成后新增的分支（饱和限幅、数据类型转换、除零保护）根本不在模型覆盖率的分母里
• 结构覆盖率刷满就宣布可以出口，需求覆盖率却还缺一截（或者反过来）——两类覆盖率互不替代，缺一都不算过出口

完整讲义已发布 · 阅读全文

需求区 · 想听众筹

登录后想听 / 点名

想听/点名均为需求登记，不涉及任何付款（意向金仅登记不收款）。满 5 人点名 → 自动向平台专家发邀约。