K2-03 功能安全（ISO 26262）在热管理中的应用

课程代码 K2-03 · 板块 K 控制、软件与标定 / 控制器硬件与安全 时长 约 4.5 小时（6 讲） 前置 K2-01/K2-02 或等效控制系统基础；体系外前置（需自备）：建议先学 D1-03 热失控触发机理 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 K2-03 大纲的完整展开版

---

引言：「我们有过温保护，所以这条可以评低一级」——一句论证写错，五处要求一起松

热管理这一侧的功能安全，卡住人的从来不是「ISO 26262 是什么」，而是三个具体场合答不上来。第一个场合在评审桌上：有人指着一条功能问「这个定几级」——问的是汽车安全完整性等级（ASIL），A、B、C、D 四档，另有 QM——回答给出了一个字母，而追问「凭什么是这个字母」时，能说出的只有「我们一直是这么定的」或者「上一代平台就是这一级」。第二个场合在危害分析工作表里：整张表的可控性一栏都评得很低，理由栏写着「本控制器有过温保护，会主动切安全状态」；这句话读起来很有工程感，可它让整张表朝同一个方向一起偏，于是异常在表内部看不出来——每一行都错了，行与行之间反而很一致。第三个场合在定级之后：等级定完了，却不知道该改哪一根线、报文里该加哪几个字节、软件测试该做到哪一档——结论悬在纸面上，落不到实现里。这门课要处理的正是这三件事。

本课交出四项判断力，每一项都对应一个当场可验的动作：给一个热管理功能做危害分析并给出定级依据——交付物是一张十二列的表，其中三个「依据」列填的是理由，不是等级号；识别出哪些失效模式必须被安全机制覆盖——做法是对分析对象（item）边界上的每一个输入、输出与能量通路逐个扫，各问四种失效表现；看懂并参与从安全目标到技术安全需求的分解——三跳，每一跳都要带着等级与时间预算一起往下传；判断一个安全机制是否满足对应等级的独立性要求——三问：共因清单逐项核过了吗、剩余的共享项有处置记录吗、分解结论写回安全需求与追溯矩阵了吗。这四项之外的东西，本课要么只给去向，要么明说不给，下面会逐类交代清楚。

全课六讲。第 1 讲把射程线与基础判据摆平——这条标准管什么、明文不管什么，严重度 / 暴露度 / 可控性三个参数各自评的是什么，安全目标为什么必须成套写全三件，以及现实里这条链跨了几家公司；第 2 讲做危害建集，先画全集再逐格核，并把「裸态前提」这条规矩正面立起来；第 3 讲讲分解——责任先划清再往下分、安全机制按覆盖链上的哪一段选、诊断覆盖率怎么才进得了度量；第 4 讲判独立性——共因失效、等级分解、免于干扰，三件事合起来回答「这个分解到底成不成立」；第 5 讲把等级结论落到实现上——硬件随机失效的三个度量、软件侧的内存保护与锁步核与端到端保护、以及验证强度那一档；第 6 讲收口到验证确认、安全案例证据链、量产后的绩效监控与变更管理。前置是 K2-01 热管理控制器（域控/ECU）硬件架构（控制器这块板自己的边界）与 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成（报文这一层的约定）；热失控本身的机理建议先读 D1-03 热失控触发机理与特征参数。

钉子①：等级是「危害事件」的属性，不是系统、零件或功能的属性。一条定级结论要能当场答出三问——哪个 item（分析对象与边界画在哪）？哪一种失效行为（不是「坏了」，而是以什么方式表现出来：该动没动 / 不该动却动了 / 动了但不到位 / 动了但停不下来）？哪一个运行场景（车在什么状态、谁在场、他能做什么）？三问缺任何一个，三个参数就没有可评的对象，写出来的等级是拍的。本课每一讲最后都落回同一个动作：把「这个功能要做 ASIL X」这句话，改写成「在某场景下、某失效表现、导致某危害事件，故定为 ASIL X，依据是……」。⛔ 由这条钉子可以直接推出一个判断：把整个热管理系统笼统定成同一个等级是错的——热管理里不同功能、不同失效模式的等级本来就应当差得很远，一个常数意味着该 QM 的功能被过度设计，而真正高风险的那条链反而没被单独识别出来。过度设计的代价还不只是成本，它会挤占那几条真正需要独立性的链的资源（引脚、通道、算力、验证工时），结果是高风险那条做得更粗。⚠ 这个错在评审时看起来「很保守很安全」，所以它能活很久。

钉子②：这条标准的射程线画在「E/E 失效行为」上——热危害本身不归它，热管理承担的是分解之后的那一份。射程写在标准自己的范围条款里（本课所据的原文出处是 ISO 26262-11 的第 1 章范围；版次与年份以现行目录为准，引用前须核），明文有两条不管：与电击、火、烟、热、辐射、毒性、可燃性、反应性、腐蚀、能量释放等相关的危害，除非由安全相关 E/E 系统的失效行为直接引起；以及 E/E 系统的标称性能——后者归 ISO 21448，去向 K2-05 预期功能安全（SOTIF/ISO 21448）与 AI 件安全论证在热管理的落法。⇒ 所以「电池热失控」这件事本身的判据源不在本课：机理与特征参数见 D1-03 热失控触发机理与特征参数，结构级抑制见 D5-01 热失控热扩散抑制（热管理与结构协同），对应强制性国标的适用由那两门给出。本课覆盖的是那一段 E/E 链路：过温未被探测到、冷却能力因 E/E 失效而失去、执行器被误驱动。⇒ 由此还推出一条工作顺序：责任先划清，再往下分解。热失控类的顶层安全目标通常首先落在电池侧的断电与限功率通道上，热管理承担的是分解之后的那一份——冷却能力的可用性、过温探测通道的完整性。不先说清哪一份归谁，技术安全需求会两头落空（都以为对方做）或两头重复（都做了，但没人验证组合起来是否覆盖）。

★ 本课最容易被读反的一句，是这一句：「我们这个功能已经有过温保护了，所以危害分析里可以按风险较低评，ASIL 能降一级」。读者会做错的那个动作非常具体：在危害分析工作表的可控性（或严重度）论证栏里填上「本控制器有独立过温保护 / 看门狗，会主动切安全状态」，据此把等级往下调一到两级。一处论证写错，五处要求一起降——硬件架构度量的目标、独立性与免于干扰的要求、软件验证强度的档位、确认措施的组织独立性等级，全都挂在那个等级上，跟着一起松掉。⚠ 而这一路松下来，不会有任何一道测试因此报错：每一项都按新等级的要求做到了，只是那个等级本身是错的。

它为什么是反的：危害分析的输出就是「需要多强的安全机制」，把安全机制放进输入，是循环论证——用被告当法官。危害分析必须在「假设本 item 不含任何安全机制」的裸态前提下做；那个过温保护本身正是要被覆盖的对象，它失效的那个场景，恰恰就是危害分析要问的那个场景。一旦把它计入，该保护失效时没有任何东西托底，而纸面上的等级还写着低一级。⚠ 但这句话不是「永远错」，它对一半：其他 item 的保护——例如电池管理侧的限功率与停充、整车级的高压断电——在论证了独立性之后，可以按外部措施或独立 item 处理并计入。⇒ 正解是先判归属，再决定能不能计入，两问：① 这个保护在本 item 的边界之内还是之外？② 它与本 item 有没有共因（同一颗 MCU、同一路电源、同一路信号、同一份标定表、同一个安装位置）？两问答不出，就不许计入。⛔ 不许把「先判归属」压缩成「有没有别的保护」——那是把判据整个换掉了。⚠ 第二层同样会被读反：可控性说的是驾驶员及相关人员能否及时反应，不是「系统里还有没有别的电子保护通道」；把它读成「系统可控性」，整张表会一起偏。⚠ 第三层是收口：即便外部措施论证成立，能降的也只是该危害事件的等级，⛔ 不是把安全目标取消掉；而且外部措施的有效性要在安全案例里有证据（谁做的、怎么验的、失效率假设是什么、假设被推翻时回哪一步），⛔ 不能只在表里写一句「电池管理会管」。这一条在第 2 讲会以正面规矩的形态立一遍，在常见误区一节合账。

本课凡是要「列一张表」的地方——有哪些危害链、标准的生命周期分几段、安全机制有哪几类、独立性会被什么破坏、通信会出哪些失效、安全案例要收哪些件——一律先把全集画出来、再逐项核射程，而不是顺着自己最熟的那条线索往下数。这不是讲究：沿单一线索枚举时漏掉的从来不是「少了一条」，而是整类不出现，而表面上那张表还是齐的、还是有头有尾。三个已经踩实的例子。其一，沿「电池 → 座舱 → 高压件」数危害链，会整类漏掉不在这条线上的格；本课改用「热管理的作用对象 × 车辆运行状态」二维建集，据此补出三格——这三格是本课归纳的：驻车与远程唤醒（远程预热或预约空调时车内可能有人，含儿童与宠物，而驾驶员不在车上）、维修与售后（服务模式下回路被人为断开、人的手就在回路上，受害人是维修人员，而「相关人员」正是可控性定义里最容易被丢掉的那一半）、以及横跨全部状态的「不该动却动了」这一整类（意外开阀导致电池被过冷、意外关阀切断冷却、压缩机或加热器意外启动）——它与「该动没动」方向相反，靠只监控输出量够不够的单侧合理性检查天然抓不到。其二，沿「危害分析 → 技术安全需求 → 失效模式与影响诊断分析」这条主干数生命周期，会整类漏掉支持过程与生产运行两段，而本课第 6 讲的变更管理与量产后监控恰恰落在那里。其三，按「硬件的 / 软件的」给安全机制分类，会整类漏掉论证类（独立性论证、共因失效分析、免于干扰论证、确认措施）——它在代码与电路图上都不出现，而没有它，探测、隔离、反应三类做得再全，分解也不成立。

射程也先划清，免得在正文里白找。本课判三件事：这个功能要不要做、做到哪一级、机制成不成立。本课不判的，只写去向、不给限值：热失控的触发阈值与特征参数去向 D1-03 热失控触发机理与特征参数，结构级热扩散抑制去向 D5-01 热失控热扩散抑制（热管理与结构协同）；进入安全状态之后怎么降级、状态机怎么写去向 K5-02 热管理故障处理与降级策略；件没坏、规格也实现对了却仍输出不合理的那一类去向 K2-05 预期功能安全（SOTIF/ISO 21448）与 AI 件安全论证在热管理的落法；跨企业时假设条件怎么写、怎么回验、接口失效责任怎么归去向 K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署；验证流程与覆盖率报告的具体做法去向 K4-03 MIL/SIL/HIL 验证流程；端到端保护的参数配置与接收侧状态机去向 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成；监控通道与电源域的电路实现去向 K2-01 热管理控制器（域控/ECU）硬件架构，传感器的冗余布置去向 K1-03 传感器布置、冗余与信号可靠性；大算力件的散热设计去向 E5-01 自动驾驶域控/大算力芯片散热设计，结构侧的失效模式设计去向 I7-03 功能安全导向的结构与失效模式设计；标定改动本身的工程实践去向 K6-03 电池热管理标定。冷媒工质的安全分类与作业规程、除霜除雾的性能判据，本课都不判，只写「按现行标准与整车法规原文核」。标准这一层同样只写去向：本课引用时一律按用法落到部分号，⛔ 不裸写「ISO 26262」四个字——定级、系统层、硬件、软件、生产与运行、支持过程、分解与相关失效分析各归不同部分，裸写会让读者无从查证；而各部分内部的条款正文，本课一份都没有取到，因此只写「哪一部分管什么、去哪查」，不复述条款内容与限值。中国对应件是 GB/T 34590 系列，修改采用 ISO 26262，且是推荐性不是强制性；具体部分号、版次与实施日期以现行目录为准，引用前须核。⚠ 「推荐性」不等于「可以不做」——主机厂的技术协议通常把它变成合同义务；反过来把它说成强制性也错，会让项目做出不必要的合规动作。

最后交代一类数，同样免得在正文里白找。三个参数各分几档、组合怎么查表、硬件度量的目标值、诊断覆盖率低 / 中 / 高三档的档位值、合法的等级分解组合、结构覆盖率与等级的对应表——这几样都是标准的条款内容，本课未取到原文，一个都不写，只写「按现行版本原文核」。故障容错时间间隔 t_FTTI 与从它切下来的两段（t_detect、t_react）、热失控的触发温度与可用时间窗、电池被过冷的危害阈值、大算力件的结温与降频门限、停车充电场景暴露度的分母、高压部件的过热阈值与关断时间、端到端保护的容错次数与超时门限、安全相关软件的执行时间预算、现场安全绩效监控的门限，以及任何一个失效率 λ 的具体取值——这些全是平台相关量，取决于电芯体系、包结构、回路热惯量、芯片与散热设计、整车高压架构与本项目的运行画像，只能由本项目的试验、实测与系统仿真给出。⛔ 本课一个都不给，⛔ 也禁止抄上一代平台，图上同样不会偷偷画一条门槛线代替它——凡属这一类的量，图上都画成可沿轴自由平移的带，并在行尾写明它由谁给出。本课能给的可手算示例只有两个，而且刻意都不依赖任何平台数：时间预算的符号推演 t_FTTI ≥ t_detect + t_react（逐项展开成去抖次数、诊断周期、通信周期、执行器机械动作完成时间等分项），以及残余失效率随诊断覆盖率变化的代数关系 λ_RF ≈ (1 − DC) × λ（式中 λ 指该安全机制覆盖范围内的危险失效率，DC 指诊断覆盖率）。这门课的交付物不是一组推荐值，是一串每一步都写得出理由、也经得起当场反问的判据。

第 1 讲　先把射程线与三件套钉死：本课判的是「失效行为」，不是「热」这个词

一份热管理的功能安全材料被打回，最常见的两处不在分析做得细不细，而在还没开始分析之前：一处是射程——把「电池热失控」整件事都拿进 ISO 26262 的方法链里做，或者反过来，因为热失控归电池就把 E/E 那一段也一起推走；另一处是口径——安全目标只写了「不许发生什么」，没写「停在哪个状态算安全」，更没写「留给系统的时间有多长」，于是下游每个人各自假设了一个响应时间。这两处都发生在「划线」这一层，而它们造成的返工会落在后面五讲的每一讲上。所以本讲不做任何一条具体的危害分析，只做九件事：先画出本课的射程线与那条例外通道（1.1），给出判断一件事该走哪条线的入口两问（1.2）；再把标准的组织方式说清楚，并指出只沿主干枚举必漏的那两整类（1.3），以及引用时怎么落到部分号、中国对应件怎么并列写（1.4）；然后逐个说清 S/E/C 三个参数各自评的是什么（1.5）、等级是怎么组合出来的（1.6）、安全目标要成套写全哪三件（1.7）；接着交代现实中这条链跨几家公司、责任怎么划（1.8）；最后把全课的术语与符号一次立表钉死（1.9）。⚠ 本讲只给三个数——标准共几个部分、等级共几档、中国对应件是什么性质，除此之外一个数都没有。这不是省略：本讲交付的全部是射程、口径与结构，凡是带数的结论要么在后面几讲、要么本课明说不判，各自带自己的来源。

1.1 射程线画在「失效行为」上，不画在「热」这个词上——热危害本身的判据源不在本课

是什么。ISO 26262 的适用对象是装在量产道路车辆上、含电子电气（E/E）系统的安全相关系统，并明文排除若干车型（轻便摩托车、为残疾驾驶人设计的特种车辆专用 E/E 系统）。它的范围条款里另有两条「不管」，对热管理工程师尤其要紧：

• 与电击、火、烟、热、辐射、毒性、可燃性、反应性、腐蚀、能量释放等相关的危害，不管——⚠ 但有一条例外通道：除非由安全相关 E/E 系统的失效行为直接引起；
• E/E 系统的标称性能，不管——那是另一条线的对象，去向 K2-05 预期功能安全（SOTIF/ISO 21448）与 AI 件安全论证在热管理的落法。

⇒ 于是本课的射程可以画成三个域：域一是 26262 管的「E/E 失效行为引发的危害」；域二是标称性能，件没坏、规格也实现对了，只是能力不足导致输出不合理；域三是被明文排除的那一族危害，其中「热」赫然在列——而热危害走那条例外通道就能回到域一。这就是本课与 D1-03 热失控触发机理与特征参数、D5-01 热失控热扩散抑制（热管理与结构协同） 之间那条线的由来：「电池热失控」这件事本身的判据源不是 ISO 26262（机理与特征参数在 D1-03 热失控触发机理与特征参数、结构级热扩散抑制在 D5-01 热失控热扩散抑制（热管理与结构协同），对应强制性国标的适用由那两门给出）；26262 在本课覆盖的是其中那一段 E/E 链路——过温未被探测到、冷却能力因 E/E 失效而失去、执行器被误驱动。

为什么这条线必须先画。因为「热管理的功能安全」这个说法里，「热」是对象而不是判据的入口。判据的入口是失效行为：一件事之所以进本课，不是因为它跟温度有关，而是因为有一个安全相关的 E/E 系统以某种方式表现出了失效。这条线画错，两个方向的错都很贵：往里多收，会把热失控演化本身（属材料与结构层的问题）拿进来做危害分析与技术安全需求，做出来的需求没有承接对象；往外少收，会因为「热失控归电池」把过温探测通道的完整性也推给别人，而那一段恰恰是本课能管、也只有本课在管的。⇒ 责任先划清再分解：顶层安全目标通常首先落在电池侧的断电与限功率通道上，热管理承担的是分解之后的那一份——冷却能力可用性与过温探测通道的完整性。不先说清哪一份归谁，技术安全需求会两头落空（都以为对方做）或两头重复（都做了但没人验证组合起来是否覆盖）。

工程量级。本条不涉及任何数值：三个域是范围划分不是参数。⚠ 三域划分与那条例外通道，逐字取自项目已核实标准台账的 ISO 26262 条目所引的范围条款；⚠ 具体部分号、版次与年份以现行目录为准，引用前须核（1.4 给引用写法）。⛔ 本课不给热失控的触发温度、温升速率与可用时间窗——那些取决于电芯体系与包结构，须由本项目试验确定，且本课不判这一层。

易错点。两个，方向相反。①把域三读成「不重要」——它不是不重要，是判据源在别处；本课在那里给的是去向而不是限值，读者拿不到限值时正确动作是去那门课或去本项目规范，⛔ 不是继续在本课里找。②把例外通道读成「只要跟热沾边就走 26262」——那条通道的措辞是「由安全相关 E/E 系统的失效行为直接引起」，「直接引起」四个字是判据，缺了它就是把整条热链的严重度扣到某个传感器头上做过度设计。

1.2 入口只有两问，且必须先问「件坏没坏」——顺序反了会把系统性错误推给另一条线

是什么。手上有一个不期望的输出或后果，判它该走哪条方法链，本课给两问，有顺序：

• 问① 件坏了吗？——这里的「坏」含两类：随机硬件失效（件在使用中坏了）与系统性错误（规格写错了、实现错了、标定表填错了、需求本身有缺陷）。任一为是 ⇒ 进问②。
• 问② 它是安全相关 E/E 系统的失效行为吗？——是 ⇒ 走 ISO 26262：危害分析与风险评估 → 安全目标 → 技术安全需求 → 失效模式与影响诊断分析；否 ⇒ 判据源在别处（热危害去向 D1-03 热失控触发机理与特征参数 与 D5-01 热失控热扩散抑制（热管理与结构协同），性能类去向整车法规与企业规范）。
• 问① 若为「件都没坏」，还要追一问：规格实现对了吗？——实现对了、件也没坏，输出仍不合理 ⇒ 那是能力不足，走 ISO 21448，去向 K2-05 预期功能安全（SOTIF/ISO 21448）与 AI 件安全论证在热管理的落法；实现没对 ⇒ 那是系统性错误，仍回 ISO 26262。

★ 这棵树上的第四个终点（「判据源在别处」）是本课归纳的，⛔ 不要把它当成既有条款；两问本身的判据来自本课射程线的推论（1.1）。

为什么顺序不能反。先问「是不是能力不足」的人，会把系统性错误整类推给另一条线——因为「规格写错了」在现象上看起来也像「系统表现得不够聪明」。而系统性错误在 26262 的射程之内，它有一整套针对性的过程要求（规格评审、验证强度、变更管理）；推走之后，那些要求一条都不会落到项目上。反过来，先问件坏没坏，就把「实现错了」这一支牢牢留在 26262 这一侧——这一支是最常被读错的一支。⇒ 入口判错的代价不是「多做一点」，是整条方法链用在接不住它的问题上：拿失效模式与影响诊断分析去处理「传感器没坏、但装的位置让读数不代表真实温度」这类问题，它接不住，因为那里根本没有一个可以填失效率的失效模式。

工程量级。本条不涉及数值。⚠ ISO 21448 的条款内容本课未核原文，⇒ 只写去向（K2-05 预期功能安全（SOTIF/ISO 21448）与 AI 件安全论证在热管理的落法），⛔ 不写它的流程步骤、不把它的判定条件当作标准原文引用。

易错点。两个。①把两者当成「新老标准」的替代关系——它们是并列的两条线，入口判据不同，是分流不是先后；写成「先做 26262 再做 21448」会让人把两条线的产物混在一份材料里，评审时两边都对不上。②在热管理里把「除霜性能不足」直接当成 26262 的危害去做危害分析——标称性能不在 26262 射程内，这一点范围条款有明文（1.1）；同一个「玻璃没除干净」的现象，成因是风道能力不够还是鼓风机驱动失效，走的是完全不同的两套方法（第 2 讲展开）。

1.3 V 的左右是层次对应不是时间先后——只沿主干枚举，必漏支持过程与生产运行两整类

是什么。ISO 26262 按生命周期分部分，共 12 个部分（来源＝项目已核实标准台账的 ISO 26262 条目，核自标准发布方的官方条目页；⚠ 版次与年份以现行目录为准，引用前须核）。这些部分在 V 模型上是有位置的：左侧自上而下是概念阶段（item 定义 → 危害分析与风险评估 → 安全目标 → 功能安全需求）、系统层设计、硬件设计、软件设计；右侧自下而上是软件验证、硬件验证与度量、系统集成与验证、安全确认；V 的外围还横跨两条带——上带是支持过程（变更管理、配置管理、文档、工具鉴定、接口协议与责任划分），下带是生产、运行、服务与报废。

★ 把它铺成可核对的七段，是本课归纳的全集（⛔ 不是标准既有的分段方式；⚠ 「七」是本课当前铺到的条数，⛔ 不是封闭全称——本课凡是标着「本课归纳」的清单一律按可增不可减读，判据见 5.5）：① 概念阶段 ② 产品开发系统层 ③ 硬件层 ④ 软件层 ⑤ 生产、运行、服务与报废 ⑥ 支持过程 ⑦ 相关失效分析与 ASIL 分解。本课六讲在这七段上的落点是：

本课	落在 V 的哪一段
第 1 讲	概念阶段的入口（item 与边界、三要素、安全目标三件套）＋ 支持过程里的接口协议
第 2 讲	概念阶段的「危害分析与风险评估」这一格
第 3 讲	概念阶段末端到系统层左侧（功能安全需求 → 技术安全需求 → 安全机制选型）
第 4 讲	第 ⑦ 段（相关失效分析与 ASIL 分解），横跨系统架构与软件架构
第 5 讲	硬件层的度量与软件层的验证强度（V 的左下与右下）
第 6 讲	V 的右上（验证、确认与安全案例）＋ 第 ⑤ 段与第 ⑥ 段

为什么必须这样铺。两个理由。一是 V 的左右成对意味着每一条需求都必须有一条与之配对的验证——追溯矩阵不是「文档要求」，它就是 V 的结构本身；这也是为什么第 6 讲的证据链能按 V 逐层收件（缺哪一层的配对，收件表上就是一个空格）。二是枚举方式：多数人沿「危害分析 → 技术安全需求 → 测试」这条主干数生命周期，凡不在这条主干上的东西不会以「少了一条」的形式暴露，而是整类不出现——而本课第 6 讲的变更管理与量产后安全绩效监控恰恰各在被漏掉的那两类（⑥ 与 ⑤）里。⇒ 读者若按主干理解整个生命周期，会得出一个非常自然、也非常错的结论：项目投产就结束了。

工程量级。本条只有一个数：共 12 个部分（来源同上）。⛔ 各部分内部的条款内容一律不写——本课只核过范围与部分划分，没核过条款正文（1.4 给引用写法与去向）。

易错点。两个。①把 V 模型讲成「先设计后测试」的时间顺序——它是层次对应：右侧某一层验的是左侧同一层写下的东西，两侧在项目上完全可以并行推进，而且必须并行（验证方案要在需求写下时就一起定，否则会出现「写得下来但验不了」的需求）。②把「先画全集」做成「把标准目录抄一遍」——全集要按读者会从哪条线索数来建，并明确写出哪一类是补出来的；抄目录得到的是一张不会漏、但也不会提醒任何人的清册。

1.4 引用一律落到部分号，中国对应件并列写——⛔ 不裸写「ISO 26262」四个字

是什么。「按 ISO 26262 做」这句话在工程材料里等于没说：危害分析与定级、系统层、硬件、软件、生产运行、支持过程、分解与相关失效分析各归不同的部分，读者拿不到部分号就查不到原文。本课全课统一按用法写部分号：

你在做的是这一步	引用落到
危害分析与风险评估、定级、安全目标	ISO 26262-3
系统层技术安全需求、架构、集成与验证、安全确认	ISO 26262-4
硬件设计、失效模式与影响诊断分析、硬件架构度量	ISO 26262-5
软件架构、单元设计与验证强度	ISO 26262-6
生产、运行、服务与报废	ISO 26262-7
支持过程（含变更管理、配置管理、工具鉴定、接口协议）	ISO 26262-8
ASIL 分解与相关失效分析	ISO 26262-9
半导体	ISO 26262-11

面向中国工程师，还应并列写：中国对应件是 GB/T 34590 系列，修改采用 ISO 26262，且是推荐性标准（GB/T 的「/T」即推荐性）。写法示例：「按 GB/T 34590.3 / ISO 26262-3 现行版本」。

为什么这件事值得单独立一节。三个理由。一是可查证：部分号是读者回到原文的唯一入口。二是部分号本身携带射程信息——把软件那一部分的条款拿去管硬件度量，是跨射程引用；反过来把硬件那一部分的度量目标拿去要求软件，也一样。三是合规判断：把推荐性说成强制，项目会做出不必要的合规动作；反过来说成「推荐性所以可以不做」也错——主机厂的技术协议通常把它写成合同义务，性质是推荐性、约束力来自合同，这两件事要分开说。

工程量级。上表的对应关系来源＝项目已核实标准台账的 ISO 26262 条目（该条目同时给出建议写法）。⛔ 版次年份与发布日期不写成独立断言——正文一律写「以现行目录为准，引用前须核」。⚠ GB/T 34590 未单独过射程核，⇒ 本课对它只写去向与性质，⛔ 不写它的条款内容、不写具体部分号的实施日期与代替关系。

易错点。三个。①给了部分号，却把条款内容也「顺手」写出来——本课只核过范围与部分划分，没核过条款正文，凡涉及条款内容的地方本课一律只写去向。②把「修改采用」当成「等同采用」——两者对差异条款的处理不同，项目上真正要看的恰恰是差异那几处。③把某一年的版次写死当事实：一份三年前写的材料里那个年份至今还在被引用，而目录早已更新——这正是「版次不单值化」这条要防的形态。

1.5 S、E、C 三个参数的评估对象各不相同，且都不是零件的属性

是什么。危害分析与风险评估的三个参数评在危害事件上，而危害事件是三样东西组合出来的：

1. item 与边界——分析对象是什么，边界画在哪，哪些接口穿过边界；
2. 失效行为——⛔ 不是「坏了」，是「以什么方式表现出来」。本课全课用同一组四分类：该动没动 / 不该动却动了 / 动了但不到位 / 动了但停不下来；
3. 运行场景——车在什么状态、谁在场、他能做什么。

三者组合成一条危害事件，再对它评三个参数：

参数	它评的是什么	它的对象（分母）是
严重度 S	该危害事件对人造成的伤害后果	人受到的伤害
暴露度 E	那个运行场景出现得有多频繁	场景出现的机会
可控性 C	驾驶员及相关人员能否及时反应、避开伤害	人的反应能力

为什么必须逐个说清对象。因为三个参数的分母各不相同：S 的对象是人受到的伤害，E 的对象是场景出现的机会，C 的对象是人的反应能力。三者混在一起评，会出现一种非常一致、因而很难被发现的偏差——把系统的能力算进人的反应能力里。⇒ 而钉子①在这里落地：ASIL 是「危害事件」的属性，不是系统、零件或功能的属性。一条定级结论必须能当场答出三问——哪个 item？哪一种失效行为？哪一个运行场景？三问缺一个，S/E/C 就没有可评的对象，写出来的等级是拍的。

工程量级。S/E/C 各分几档、组合怎么查表属 ISO 26262-3 的条款内容，本课未取到原文 ⇒ 只写去向：按 GB/T 34590.3 / ISO 26262-3 现行版本原文核。⛔ 本课正文与图上不复制定级表、不写档位号。

易错点。两个，都会让整张表一起偏，因而看不出异常。①把可控性 C 读成「系统可控性」——即在 C 的论证栏里回答「系统里还有没有别的电子保护通道」。⛔ 这是错的：C 的定义说的是人能否及时反应，不是系统里还剩几条保护。这样读的人会把每一条危害的 C 都评低，而且错得很一致，评审时看不出哪一行反常。②忘了 C 的定义里含「相关人员」而不只是驾驶员——于是「维修与售后」这一整格从危害清单里消失：服务模式下回路被人为断开、人员的手就在回路上，此时执行器意外动作的受害人是维修人员。⇒ 「相关人员」这半句正是 C 的定义里最容易被丢掉的一半（第 2 讲会把危害清单按二维全集重建一遍）。

1.6 ASIL 是查表组合出来的，不是三个数相乘——「S×E×C」只是助记

是什么。三个参数各自分档后，按标准附表查得一个等级：A、B、C、D 四档，另有 QM（质量管理级，即不需要按本标准的安全要求处理，但仍走常规质量流程）。写成「S × E × C → ASIL」是助记，⛔ 不是算术乘积——三个参数是分档的定性标度，相乘会得到一个标准里根本不存在的中间数。

为什么这个写法要专门破。因为一旦把它当算术，就会顺手做三件在查表里不成立的事：①排序——拿中间数给几十条危害排优先级，而查表是离散且非线性的，两条中间数相同的危害可能落在不同等级上；②等价替换——误以为「E 降一档等于 S 降一档」，于是在论证时专挑最容易降的那个参数下手，而实际上某些组合降一档不跨级、某些组合会一次跨两级；③求平均——拿一个「平均 ASIL」去描述整个系统。⛔ 第三件是钉子①的直接反面：ASIL 是危害事件的属性，系统没有平均等级这回事；把整个热管理系统笼统定成同一个等级，结果是该 QM 的功能被过度设计，而真正高风险的那条链反而没被单独识别出来（第 2 讲与常见误区节会把这条正面拆开）。

工程量级。本条只给一个枚举事实：四档加 QM。⛔ 组合表的具体格子不写——未核原文，只写去向（同 1.5）。

易错点。两个。①在材料里真的算出了一个乘积并据此写结论——这类错在评审时很容易过，因为它「有算式、有数」，看起来比一句定性判断更硬。②把 QM 读成「不用管」——QM 的含义是不按本标准的安全要求处理，常规的质量流程、验证与变更管理照样要走；而且一条危害被定成 QM 本身是一个需要依据的结论，不是「没评出等级」的默认值。

1.7 安全目标要成套写全三件：目标、状态、时间——只写前两件，等于没给下游任何预算

是什么。三件套缺一不可：

• 安全目标：由危害事件反写出来的顶层陈述（避免/防止该危害事件发生），并继承该危害事件的 ASIL。它说的是「不许发生什么」，⛔ 不写机制、不写技术方案。

• 安全状态：达成该安全目标时，系统要停在的那个具体状态。它必须可达（有执行通道、有能量、有时间走过去）且可维持（进去了不会自己出来，也不会因为别的失效被推出来）。

• 故障容错时间间隔 t_FTTI：从故障发生到危害发生之间，系统还来得及做点什么的那个时间窗。判据是一条不等式：

  t_FTTI ≥ t_detect + t_react

把两段时延各自展开（分项清单为本课归纳）：

t_detect ＝ t_sense ＋ t_bus,in ＋ n_deb · T_diag t_react ＝ t_decide ＋ t_bus,out ＋ t_act ＋ t_settle

其中 t_sense 是传感与信号调理时延，t_bus,in 是信号送到做判据那个节点的通信时延，n_deb 是去抖所需的连续判定次数（无量纲），T_diag 是诊断任务周期，t_decide 是决策与仲裁时延，t_bus,out 是指令送到执行器的通信时延，t_act 是执行器从收到指令到机械动作真正完成的时间，t_settle 是效果建立那一段——阀开到位不等于电池温升停住，泵转起来不等于流量建立、热量被带走，回路热惯量的那一段时间同样在预算里。⚠ t_settle 是最常被整项忘掉的一项，它不因为「指令已经发出去了」而消失（第 3 讲 3.3 会把这两段再拆一遍，用的是同一套符号）。

分配顺序也是本课归纳的，且只有一种正确顺序：先扣 t_act 与 t_settle 这两段硬的，再分探测与决策。因为这两段是几样里唯一不由软件决定的——一段由执行器的机械特性与工作点决定，一段由回路的热惯量决定，谈判空间最小。⇒ 符号形式的分配式写成（⚠ t_bus,in 已经含在 t_detect 里，⛔ 不得在同一式里再单列一次，那会把上行通信时延算两遍）：

t_detect ＋ t_decide ＋ t_bus,out ≤ t_FTTI − t_act − t_settle

为什么三件套缺一件就断。只写安全目标不写安全状态，下游无从设计反应动作——「不许过温」到底是要关掉压缩机、还是要把阀打开继续冷却？两个动作方向相反。只写前两件不写 t_FTTI，「加个监控」这句话就没有验收判据：诊断周期取多快、去抖取几次，全凭感觉，也没人能反驳。而有了 t_FTTI，上面那串分项全部变成可核算的预算项：诊断周期、去抖次数、通信周期、执行器响应时间各占多少、余量留在哪一段，都能写下来并被验证。

工程量级。⛔ t_FTTI 与两段时延一律不给数——它们取决于危害演化速度、电芯体系、包结构、回路热惯量与整车级抑制措施，须由本项目的演化试验与系统仿真确定；⛔ 禁止抄上一代平台。安全状态的进入时间与维持时长同样不给数，取决于整车布置与执行器能力。本课在这里交付的是预算式的结构与上面那个用符号写的分配式；预算怎么随三跳分解往下传，第 3 讲展开；分配到具体降级动作上的时序，去向 K5-02 热管理故障处理与降级策略。

易错点。三个。①安全状态一刀切写成「断电」——安全状态的方向由危害决定，不由零件的失电默认位决定；同一个阀在「电池过温需继续冷却」与「冷媒泄漏需切断」两个场景下，安全状态方向恰好相反（第 3 讲与常见误区节正面拆）。②把分项漏出预算——最常漏的是去抖次数与执行器机械动作真正完成的那一段，只算了软件探测那一小段，于是纸面上余量充足、台架上超时。③把 t_FTTI 当成「诊断周期」的同义词——⛔ 前者是危害侧给出的时间窗（外部约束），后者是方案侧的一个分项（内部选择），把两者等同起来等于用自己的选择去定义自己的约束。

1.8 现实里这条链跨几家公司：你拿到的等级是分解后的一份，假设条件是要回验的输入

是什么。本课在讲法上默认「危害分析 → 技术安全需求 → 失效模式与影响诊断分析」在一家公司里闭环，现实不是：整车安全目标与危害分析在整车厂手里；电子水泵、电动压缩机、PTC、多通阀等部件控制器多按 SEooC（脱离具体整车语境开发的安全元素）交付，并自带一份使用假设条件；双方靠一份接口协议逐项写明：哪一方交哪个工作产品、谁签、谁回验。三条线穿过这条边界：

• 安全需求分配（整车厂 → 部件方）：往下传的不只是 ASIL，还有从 t_FTTI 切下来的那一段时间预算；
• 假设条件下发与回验（部件方 → 整车厂 → 折返）：部件方声明「我假设整车会怎样」，整车厂必须逐条回答「这个假设在本车上成立吗」；
• 工作产品与责任划分（双向）：谁做、谁审、谁签。

为什么这一节放在第 1 讲。因为它决定了读者手里那张纸的意义。假设条件不回验，等于两边各自假设了一个不同的整车：部件方假设「整车会在某个时间内断高压」，整车厂假设「部件自己会关断」——两个假设各自都很合理，合起来就是没人管。而这类缺口在集成阶段不会以「功能不通」的形式暴露，它只在故障注入时才现形，那时候硬件已经冻结。

工程量级。本条不涉及数值。⚠ 接口协议怎么写、假设条件怎么回验、接口失效的责任怎么归，去向 K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署，本课只交代定位；外部措施的失效率假设与响应时间取决于对方 item 的设计，⛔ 本课不给数，须由接口协议约定并回验（第 2 讲会用到这条）。

易错点。两个。①把假设条件当成免责声明——写完锁进抽屉，评估时才发现没人回验过。⛔ 它是输入不是声明：一条假设被推翻，对应的是回到分解那一步重做，不是在会议纪要里记一笔。②拿到一个 ASIL 等级就直接开工，没问这个等级是从哪条危害事件分解下来的——不知道来源，就无法判断自己这一份的边界在哪：哪些失效行为算在我头上、哪些是对方托底、时间预算里属于我的那一段有多长，三问全都答不了，只能按「等级越高做得越多」蛮干。

1.9 全课的术语与符号在这里一次立表，之后不许换用——三组词在中文工程实务里都两义流通

是什么。下面这张表是本课归纳的口径表（⛔ 不是标准的术语条款，条款内容一律去原文核）。每一行给三样：它是什么、它作用在哪一层、以及一个「它不是什么」的对照项——最后一栏才是这张表的价值所在。

词	它是什么	作用在哪一层	⛔ 它不是什么
item	被分析的那个系统或功能组合，连同它的边界与穿过边界的接口	概念阶段	⛔ 不是「一个零件」，也不是「一个软件模块」——边界没画就不存在 item
危害 / 危害事件	危害是失效行为带来的潜在伤害来源；危害事件是它与一个具体运行场景的组合	概念阶段	⛔ 危害事件 ≠ 失效模式：失效模式长在件上，危害事件落在人身上
fault / error / failure	一条链上的三个位置：故障 → 错误 → 失效表现	贯穿全课	⛔ 三者不是同义词；时间预算从 fault 起算（1.7）
安全目标	由危害事件反写的顶层「不许发生什么」，继承该事件的等级	概念阶段	⛔ 不是技术方案，⛔ 不写机制
安全状态	达成安全目标时系统要停在的、可达且可维持的具体状态	概念 → 系统层	⛔ 不是一句「关掉」，⛔ 不等于降级模式
降级模式	功能受限但仍在提供服务的运行模式	系统层，做法去向 K5-02 热管理故障处理与降级策略	⛔ 不是安全状态——它还在提供服务，因而还在产生新的失效可能
失效安全	一种设计取向：失效后落到危害较小的一侧	设计取向	⛔ 不是一个可验收的状态定义，⛔ 不能替代「安全状态」那一栏
ASIL 继承	安全目标的等级往下传给由它导出的需求	分解路径的每一跳（第 3 讲）	⛔ 不降低等级——往下传时等级不变
ASIL 分解	把一条高等级需求拆成两条各自较低等级、且相互独立的需求	系统与架构层（第 4 讲）	⛔ 不是降级手段；⛔ 与「继承」不是一回事，两支的组合仍须满足原安全目标
独立性（通道侧）	安全机制通道与被监控对象在物理与功能上分开，防共因失效	电路与信号层（第 4 讲）	⛔ 不能拿组织独立性去论证它
独立性（组织侧）	确认措施（确认评审、功能安全审核、功能安全评估）由谁来做、谁有资格签	组织与流程层，去向 K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署	⛔ 不能拿它去论证通道独立，反过来也不行
安全机制	覆盖 fault → error → failure 链上某一段的手段（探测/隔离/反应/论证四类）	第 3 讲	⛔ 不等于「加了看门狗和合理性检查」这一件事
诊断覆盖率 DC	运行时某安全机制对某类硬件随机失效的覆盖比例	硬件层（第 3、5 讲）	⛔ 不是结构覆盖率
结构覆盖率	开发期测试对代码结构的覆盖充分性（语句 → 分支 → 修正条件判定覆盖，逐级收紧）	软件层（第 5 讲）	⛔ 不是 DC；两者对象、时点、量纲全不同，⛔ 不可互相援引或互相折算
安全案例	一个论证：主张—证据—推理	第 6 讲	⛔ 不是文件袋，⛔ 不是交付末期的编纂工作

符号侧的统一口径（全课一致，⛔ 之后不许换用）：

符号	含义	硬规矩
λ	失效率（1/h）——⚠ 这是一个通名，不是某一个具体的量	必须带下标区分类别（如 λ_SPF、λ_RF）；⛔ 正文中禁止裸写 λ 去指代残余失效率。★ 裸写的 λ 在本课有三个不同的所指，各由所在式子当场声明，⛔ 不可互相代入：① 第 3 讲 3.9 与公式③ 的 λ ＝ 该安全机制覆盖范围内的危险失效率；② 第 5 讲 5.1 拆账树的根 λ ＝ 该 item 的总失效率（含非安全相关那一支）；③ 公式④ 分母里的 Σλ ＝ 全部安全相关失效率（⛔ 不含非安全相关那一支）
DC	诊断覆盖率	全课写全称或写 DC，⛔ 不简称「覆盖率」——那三个字在本课有两个对象
t_FTTI	故障容错时间间隔	⛔ 正文中禁止裸写不带下标的 t
t_detect / t_react	探测时延 / 反应时延	同上；两者的分项清单见 1.7，全课只此一套（t_sense · t_bus,in · n_deb · T_diag · t_decide · t_bus,out · t_act · t_settle），⛔ 之后不许另立第二套写法

为什么必须在第 1 讲就立。因为这几组词在中文工程实务里两义都在流通，而读者见到熟词不会回问，会直接按自己那一义收下——错在收下的那一刻，暴露在很久以后。三处最贵的：①「安全状态 / 降级模式 / 失效安全」被当同义词用，写出来的技术安全需求要么验不了（失效安全不是状态），要么把一个仍在提供服务的模式当成了终点；②「ASIL 分解」被当成「ASIL 继承」的反义词理解成降级手段，于是分解被拿来省工作量，而它实际上是增加工作量（多一条通道、多一份独立性论证、多一份共因分析、多一轮组合验证）；③「独立性」的同形异义——一套在电路层，一套在组织层。读混的典型句式是「我们请了独立第三方评审，所以两条通道是独立的」，或反过来「通道已经独立了，评审可以自己人做」，两个方向都错。

工程量级。本节不涉及数值。⚠ 表中「作用在哪一层」列出的讲次是本课的落点，具体条款内容仍以现行版本原文为准。

易错点。一个，且它到第 4、5 讲才发作：把 DC 与结构覆盖率都简称「覆盖率」。两者一个在运行时对硬件随机失效、一个在开发期对代码结构，对象与量纲都不同；混称之后必然出现一句听上去很顺的荒谬推论——「诊断覆盖率已经很高了，所以单元测试可以少做一点」。⇒ 本课在第 5 讲用一张口径对照图把这两者钉死，⛔ 图上不出现任何百分比数值。

⇒ 本讲收口，落到那个反复要做的动作上：从今天起，凡看到一句「这个功能要做 ASIL X」，都把它改写成——「在某场景下、发生某种失效表现、导致某危害事件，故定为 ASIL X，依据是……」。改写不出来，说明 item、失效行为、运行场景三样里至少缺一样；缺的那一样，就是这条结论真正的漏洞所在。第 2 讲开始，我们就拿这个句式去核六条危害链。