K2-03 · 控制、软件与标定 / 控制器硬件与安全
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 能对一个热管理功能（如电池冷却）做危害分析并给出 ASIL 定级依据
- 能识别热管理系统中需要安全机制覆盖的关键失效模式
- 能看懂/参与从安全目标到技术安全需求的分解
- 能判断某个安全机制（冗余/监控/降级）是否满足对应 ASIL 的独立性要求
内容大纲
- 功能安全基础与本课边界：ASIL 定级要素、安全目标三件套，以及与 SOTIF / SEooC 的两处划线
- ISO 26262 覆盖范围与 V 模型的对应关系
- HARA 三要素：严重度 S、暴露度 E、可控性 C
- ASIL 等级（A~D、QM）的判定逻辑
- 安全目标（Safety Goal）与安全状态（Safe State）
- 安全目标必须成套写全三件：安全目标（Safety Goal）+ 安全状态（Safe State）+ 故障容错时间间隔（FTTI）。只写前两项等于没给时间预算，下游「探测时延 + 执行时延」的分配无从展开（预算式 t_FTTI ≥ t_detect + t_react 见 K5-02）
- ISO 26262 的适用边界：它管的是随机硬件失效与系统性错误（件坏了，或规格实现错了）；件都没坏、规格也没写错，只是能力不足导致输出不合理的那类危害，归 ISO 21448（SOTIF）。两条线的入口判据、分析对象与验收方式都不同，分界与方法见 K2-05
- 本课默认 HARA→TSR→FMEDA 在一家公司内闭环，现实不是：整车安全目标与 HARA 在 OEM 手里，电子水泵/电动压缩机/PTC/多通阀等部件控制器多按 SEooC 交付并附假设条件（AoU），双方靠 DIA 划分工作产品与责任边界。AoU 怎么写、怎么回验、接口失效责任怎么归，见 K4-09，本课只交代定位
- 热管理系统的危害分析：六条危害链与 HARA 的评估前提
- 电池冷却失效 → 热失控的危害链
- 除霜/除雾失效 → 视野受阻的危害链
- 压缩机/PTC 失控 → 高压电气与过热风险
- 冷媒泄漏对乘员舱安全的影响（不同工质特性差异）
- HARA 必须在「假设本 item 没有安全机制」的前提下做：不能拿本系统自己的过温保护去降 S 或降 ASIL；BMS 限功率/停充等其他 item 的保护，只有论证独立性、按外部措施或独立 item 处理后才能计入。可控性 C 说的是驾驶员及相关人员能否及时反应，不是「系统里还有没有别的电子保护通道」
- 智能电子过热 → 算力降级/降频 → 自动驾驶功能可用性下降的危害链：与前四条在 HARA 三要素上都不同——严重度 S 随驾驶自动化等级变化，可控性 C 在 L3 的 ODD 内不能按「驾驶员随时可控」评估，暴露度 E 还要含非行驶状态。散热设计侧见 E5-01、降级侧见 K5-02；它走的是热致失效的 ISO 26262 线，不是感知不足的 SOTIF 线
- 停车充电时加热器/PTC 意外加热：车内通常无人在场、驾驶员可控性最差的一档场景，暴露度要按充电时长而不是行驶里程估，S/E/C 三参数与行驶工况完全不是一套。做危害清单时最容易被整体漏掉，因为它不出现在任何行驶场景库里
- 从安全目标到技术安全需求：TSR 分解路径、责任归属与安全机制/诊断覆盖率选型
- 从安全目标到技术安全需求（TSR）的分解路径
- 安全机制：冗余传感、看门狗、合理性检查、安全状态切换
- 诊断覆盖率（DC）与安全机制选型的对应关系
- 热失控类安全目标的归属先划清再分解：顶层安全目标通常首先落在电池侧的断电/限功率通道，热管理承担的是分解后的那一份（冷却能力可用性、过温探测通道的完整性）。不先说清哪一份归谁，TSR 会两头落空或两头重复
- 独立性、ASIL 分解与免于干扰：分解成不成立的判据
- 独立性要求与共因失效（CCF）分析
- 「独立性」在 ISO 26262 里是同形异义的两件事，别学混：本节说的是安全机制通道的物理/功能独立（防共因失效，讲的是电路与信号怎么分开）；另一套是 ISO 26262-2 中确认措施——确认评审、功能安全审核、功能安全评估——的组织独立性等级随 ASIL 提高，讲的是「谁有资格签」，见 K4-09
- ASIL 分解在热管理架构中的应用（双通道冗余降级组合）
- 免于干扰（FFI）：不同 ASIL 的元素共存于同一颗 MCU、同一个控制器时，必须论证低 ASIL 元素不会干扰高 ASIL 元素，干扰分存储、时序与执行、通信三类。这是 ASIL 分解与软件分区能否成立的前提，论证不了就等于没分解
- ASIL 结论怎么落到实现上：硬件随机失效度量、软件安全机制与验证强度
- 硬件随机失效度量：SPFM/LFM 与硬件架构度量的意义
- 软件安全机制：内存保护、锁步核、端到端（E2E）保护
- 端到端保护（E2E）单拎出来说清：它解决的是通信链路上的数据完整性失效——篡改、重复、丢失、乱序、超时、伪装，对应 ISO 26262-6 的通信失效模型；ASIL 分解时要求收发两端都实现，只在发送端加校验等于没做。配置参数与接收侧状态机的工程做法见 K2-02
- ASIL 结论落到软件侧的落点是验证强度：ISO 26262-6 对不同 ASIL 推荐的软件单元/集成测试方法与结构覆盖率档位逐级收紧（语句 → 分支 → MC-DC），高 ASIL 功能为什么必须做到 MC-DC 就写在这张推荐表里，具体做法见 K4-03。务必与第 3 节的诊断覆盖率 DC 区分：DC 衡量运行时安全机制对硬件随机失效的覆盖比例，结构覆盖率衡量开发期测试对代码结构的覆盖充分性——两者常在同一份安全案例里并列出现，但不可互相援引或互相折算
- 验证确认、安全案例证据链与量产维护
- FMEA/FTA 在热管理系统安全分析中的应用
- 故障注入与边界工况下的安全验证测试
- 安全案例（Safety Case）证据链怎么搭
- 安全案例证据链的软件侧要收哪些件：各层级的测试规程与测试结果、结构覆盖率报告、未覆盖项的合理化说明（含不可达代码与防御性代码怎么处理）。缺哪一件都会在评估时被退回，做法见 K4-03
- 量产后的安全绩效监控与现场数据反馈
- 变更管理：改一个标定参数是否触碰已定级的安全功能
关键公式
S × E × C → ASIL（查表定级，非算术乘积）
严重度/暴露度/可控性三参数按 ISO 26262 附表组合定级，不是三者相乘
SPFM = 1 − Σλ_SPF / Σλ
单点失效度量，衡量硬件架构对单点失效的覆盖能力（硬件架构指标之一）
LFM = 1 − Σλ_MPF,latent / Σλ_RF
潜伏多点失效度量，衡量对潜伏失效的诊断与覆盖能力
PMHF 目标随 ASIL 等级提高而收紧（D 级最严，QM 无定量要求）
随机硬件失效概率度量，用于验证架构是否满足对应 ASIL 的量化目标
λ_RF ≈ (1 − DC) × λ_安全机制覆盖范围内的危险失效
残余失效率的量级估算——诊断覆盖率 DC 只有经这一步才进得了 SPFM。ISO 26262-5 把 DC 分低/中/高三档（约 60% / 90% / 99%），实际取值须由 FMEDA 逐失效模式论证，不能直接套档位值
关键概念
ISO 26262HARAASIL安全目标 Safety Goal安全状态 Safe StateSPFM/LFMPMHF共因失效 CCFASIL 分解诊断覆盖率 DC安全机制安全案例 Safety Case
推荐工具与标准
Medini Analyze / APIS IQ-safe（安全分析工具） DOORS / Polarion（安全需求追溯） FMEA/FTA 分析工具 故障注入测试平台（HIL）
ISO 26262（尤其 Part 3 危害分析、Part 5 硬件、Part 6 软件） GB/T 34590（中国功能安全国标，对应 ISO 26262） ISO 21448（SOTIF，预期功能安全）——本课只交代它与 ISO 26262 的问题域边界，流程与方法由 K2-05 展开
工程案例
某纯电平台电池冷却回路：针对“电池过温未被检测/未被冷却”这一顶层危害做 HARA，结合场景给出 ASIL 定级；用双通道温度传感冗余+独立看门狗监控+阀门断电安全状态满足诊断覆盖率要求，并厘清与 D5-01 结构级抑制的责任边界。
动手做
交付物 · 给定“电池冷却系统失效”这一顶层危害：①用 S/E/C 三参数做简化 HARA 并给出 ASIL 定级依据；②写出对应安全目标与安全状态；③提出至少两条硬件或软件安全机制，说明各自覆盖的失效模式。
常见误区
- 把整个热管理系统笼统定成同一个 ASIL，没按功能/失效模式分别做 HARA，该 QM 的功能被过度设计，真正高风险的功能反而没被单独识别
- 安全机制只在软件里做合理性检查，硬件层没有独立监控通道，不满足独立性要求，共因失效未被识别
- 断电安全状态一刀切设成“断电常闭”，没结合具体危害——某些场景断电常开才是安全状态（例如防止冷却回路在电池过温时被意外切断）
- ASIL 分解后两个子通道共用同一路电源或同一颗 MCU，分解形同虚设
- 把功能安全（应对随机硬件失效/系统性错误）和 SOTIF（应对规格不足导致的功能局限）混为一谈，用同一套流程处理——分界看「件坏没坏」：件没坏、规格也实现对了却仍输出不合理的，26262 的 HARA→TSR→FMEDA 这条链接不住它，要走 ISO 21448，分界与方法见 K2-05
相关课题