K2-05 预期功能安全（SOTIF/ISO 21448）与 AI 件安全论证在热管理的落法
课程代码 K2-05 · 板块 K 控制、软件与标定 / K2 控制器硬件与安全 时长 约 3 小时（6 讲 + 1 次 mini AI safety case 论证链实操） 适合对象 功能安全与预期功能安全工程师、热管理控制与系统架构工程师，以及把学习件、预测件、代理模型推上车的算法与仿真骨干；专家级选修，做数据驱动或预测性热管理功能的岗位建议必修。⛔ 不要求会训模型，但要求看得懂训练／验证／测试集划分、过拟合与分布外这几个词 前置 K2-03 功能安全（ISO 26262）在热管理中的应用 功能安全（ISO 26262）在热管理中的应用；体系外前置（需自备）：基础机器学习概念——训练／验证／测试集划分、过拟合、分布外判据。体系内可先修 J7-05 机器学习/AI 代理模型在热管理中的应用 或 K7-03 数据驱动的能效自学习控制 作为受众背景，非硬前置 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 K2-05 大纲的完整展开版
引言：车在没人出行的清晨自己醒来加热，一个故障码都没有——件全是好的，按失效侧那条流程永远查不到根因
热管理最难判的那一类问题，往往不出现在「哪个件坏了」这一层。三个场合最能说明它长什么样。
第一个场合在售后。一条抱怨说，车辆在用户并没有出行安排的清晨自行唤醒、开始加热，用户侧没有任何故障码。按失效侧的排查流程走一遍，传感器、报文、执行器、标定表逐样查过，没有发现失效件，工单最后归档为「偶发、无法复现」，关掉。而它每周都在发生。后来复盘出来的成因是：行程级驾驶意图判定把「日历里有日程 ＋ 历史上这个时段常去某地」当成了必然出行，而「日程已经取消、只是没从日历里删掉」这一组合，训练数据里几乎没有负样本。件确实全是好的，需求也是按当时的认知被正确实现的——错的是「这位车主明天早上要出门」这个判断本身的能力边界，它在需求写下的那一刻就已经在那里了。⚠ 这类问题的特征不是难查，是用那条流程查下去永远查不到：那条流程问的是「哪个失效模式、诊断覆盖了多少」，而这里一个失效模式都没有。
第二个场合在评审桌上，同一个入口被两个相反的方向用错。一边有人指着一个带模型的功能说「这里面有 AI，所以得做 SOTIF」，追问一句「凭什么走这条线」，答不出判据；另一边有人把「换热能力裕量不够」「泵扬程选小了」「传感器精度不足」「标定表工况没覆盖到」也包装成「功能不足」送进同一个流程。前者是没有入口判据，后者是把入口撑破了。两种做法的代价一样：评审第一轮退回，而真正的能力不足被淹没在一堆本不该进来的条目里——连收敛判据算出来的曲线也跟着失真。
第三个场合在放行会上。某项目给学习件加了一个运行期监控器，把分布外判据的阈值往灵敏侧压了一档，论证材料的措施栏里写上「阈值已加严」，残余风险那一栏据此填了一个更小的数，签字放行。量产一年之后，这个监控器在现场被标定关掉了——它每周误报几次，而每一次误报都伴随一次真实的降级动作（限功率、退回保守策略、弹告警、放弃预约加热），代价直接落在用户体验与售后抱怨上。纸面上的论证仍然写着「已加严」，而这条措施的实际有效性已经归零。同一场会上还有另一种沉默：材料交了一大箱，覆盖矩阵、台架报告、仿真结果、监控器截图样样都在，评审问「这一份支持哪一条主张」，全场答不上来。⚠ 过不了评审的主因通常不是证据不够，而是证据齐全却没有人写那层映射。
三个场合是三种不同的错，却错在同一个位置：没有人先回答清楚「这件事该走哪条线、该交哪几件证据、这几件证据凭什么算够、谁签字、签的这一笔什么时候失效」。这门课要给的就是这一整套判断，以及把每一条判断落成一件当场可查的交付物的做法。⚠ 有一句话必须写在最前面：本课给的是论证方法，⛔ 不是合规依据——验收依据要回到各标准的现行原文与本项目自己的规范，本讲义一律只写标准号与去向。
本课交出七条判断力，每一条都对应一个当场可验的动作。一，对一个热管理功能逐条危害判定它走失效侧还是本课这条线，说得出「规范不足」的判据句，并当场认出把裕量与标定问题误送进来的那一类。二，用已知／未知 × 安全／不安全四象限组织一次危害推进，说清每一轮把哪一块面积从哪一格迁到了哪一格、用的是哪种手段、这一轮该拿什么当收敛度量。三，系统性识别热管理侧的触发条件与可预见误用，并把每一条写成带可观测判据的四元组；写不出判据的条目留在待办清单，⛔ 不计作已识别。四，写出一个数据驱动件的 ODD、输入域与可信域声明表，并给出「场景覆盖到什么程度算够」的三条同时成立的收敛判据。五，把一个运行期监控器规格化，并用检出延迟与危害发生时间预算的对照，论证它凭什么算安全措施而不是看板。六，把数据集充分性与覆盖论证、性能指标验收准则、运行期措施组织成一条 AI safety case 论证链，并与失效侧的追溯链互链而不是各写一套。七，定出残余风险接受准则、填出放行签署表（谁提、谁独立复核、谁批、有效期与失效条件），并说清它与共因失效那一侧的「残余风险」语义差在哪。
这七条最后落在六件交付物上，全课每一讲都在往里填：①触发条件四元组登记表；②ODD 与可信域声明表；③覆盖矩阵与空洞清单；④性能指标验收准则；⑤运行期监控器规格；⑥主张—证据—缺口对照表。
钉子①（全课主线）：判「这件事走哪条线」，看的是「件坏没坏、规格是不是已尽当时之能」，⛔ 不看「后果重不重」，也 ⛔ 不看「里面有没有 AI」。三条线各有射程：件坏了（随机硬件失效），或者规格写对了而实现错了（系统性错误），都走失效侧的方法链，去向 K2-03 功能安全（ISO 26262）在热管理中的应用 与 I7-03 功能安全导向的结构与失效模式设计；件没坏、实现也对，而危害来自感知、判断或决策的能力边界，才启动本课这条线。而对数据驱动件最对口的组织框架是 ISO/PAS 8800，ISO 21448 在本课只提供两件工具——触发条件识别、场景与充分性方法；把它用到热管理上属于方法论迁移，⛔ 不是天然适用，正文每次引用都会标明这一点。
⇒ 由这条钉子直接推出一个反直觉的结论：热失控这类后果最重的危害，只要由 E/E 失效引起，就仍然走失效侧——后果的严重程度决定的是那一侧要评多严，⛔ 不决定它走哪条线。判据落成三问，三问全为「是」才启动本课这条线：①需求写的是不是当时认知与能力所及的最好描述？②危害是否在需求被正确实现的前提下发生？③危害是否来自感知、判断或决策的能力边界，而非某个件的失效？⇒ 于是本课每一讲末尾都落回同一个动作：把一句「这个功能得做 SOTIF」，改写成「在某运行条件下、某能力不足、导致某危害行为，且规范不足三问全为是，故走本课这条线，该交的证据是这几件」。⛔ 三问答不齐就下结论，产出的会是一整套没人认的证据——评审第一轮退回，而真正的能力不足被淹没在里面（这正是第二个场合的形态）。
钉子②（收口）：本课这一侧的「做完了」不是清单清零，而是三件同时成立——其一，未知不安全那块面积的收敛趋势已经落到事先声明的门限以下；其二，每一条剩余项都有指派的处置；其三，每一条残余风险都逐条对着事先定的接受准则签署过。⇒ 六件交付物各自都要能当场答出同样的两问：它支持哪一条主张？它的缺口怎么处置？答不出的那一件不算交付。
⛔ 这里有一条不能商量的纪律：门限与接受准则必须事前写下；事后调门限，整条论证作废。它不是形式要求——「收敛」这件事没有真值可比，与一个事先写下的门限对比，是它唯一能被审的定义；门限可以事后动，那么任何一条曲线都能被宣布为已收敛，等于用结论定义判据。⚠ 与之配套的一条最容易被读反：把「未知不安全」这一格填 0 ⛔ 不是收敛证据——它按定义就是「还没被识别出来的那部分」，填 0 恰恰是「还没开始做」的标志，而报告上读起来像已经收敛了。
⚠ 本课判什么、不判什么，也在这里划死：本课判「这一组论证成不成立、证据够不够、谁签字」，⛔ 不判降级怎么实现（K5-02 热管理故障处理与降级策略）、护栏怎么写（K7-03 数据驱动的能效自学习控制）、灰度与回滚怎么发（K7-02 软件定义热管理与 OTA 迭代）。
★ 本课最容易被读反的一条，是这句听上去无懈可击的话：「运行期监控器既然是安全措施，那它当然越灵敏越安全——阈值该往灵敏侧调，宁可多报不可漏报。」
读者会做错的那个具体动作非常清楚：把分布外判据、置信度判据或残差判据的阈值往灵敏侧压（把最近邻距离阈值调小、把置信度门限调高、把残差限调紧），然后在论证材料的措施栏里写上「阈值已加严」，并据此把残余风险式子里的 P_措施失效 取一个更小的数。一处阈值调错方向，残余风险账、放行签署、验收结论三处一起偏，而三处都看不出任何异常。
它为什么是反的，有两层。
第一层：灵敏 ⇒ 误报多 ⇒ 措施在量产中被关掉，P_措施失效 不是变小，而是趋近 1。措施有效性有一条隐含前提——它在整个生命周期内保持使能。每一次误报都伴随一次真实的降级动作，代价立刻、确定地落在用户体验与售后抱怨上；而漏检的代价是概率性的、延后的。两者的反馈速度完全不同 ⇒ 量产里最常见的失效路径不是漏检把人害了，而是现场把这个措施标定关掉、或者把阈值悄悄改回去——一旦关掉，纸面上的论证还写着「已加严」，实际有效性归零（第三个场合）。⇒ 往灵敏侧调，反而把措施推向失效，方向恰好做反。
第二层：灵敏 ≠ 快，往灵敏侧调常常把检出延迟拖长。阈值决定的是「判不判」；「多久判出来」由判定时窗与迟滞决定。阈值一旦调灵敏，单次误判概率上升，为了守住误报率预算就必须加长连续判定时窗、加大迟滞回差去压它——于是检出延迟反而变长。而一个监控器算不算安全措施，硬判据是「检出延迟 < 该危害的发生时间预算」。⇒ 一个又灵敏、又因为要压误报而把时窗拉长的监控器，账面上更严、实际上顶不住时间预算，连措施都算不上，只是个看板。
⚠ 反过来同样不成立，⛔ 不许把这一条读成「阈值越松越好」：松阈值直接抬高漏检，而漏检的代价是危害真的发生。两边都不是可以单独调的方向。
★ 正解是一句判据（本课归纳，⛔ 不是任何标准或手册的既有条款，正文与图上都会标明）：一个监控器的阈值必须三者联立定——误报率预算（由降级代价与可接受的误动作频次反推）× 检出延迟（必须小于该危害的发生时间预算并留裕量）× 漏检门限（由危害率分配倒推）。任何一个阈值都要能当场报出这三个数各自的来源；报不出三个来源的，这个阈值是拍的，措施栏 ⛔ 不许填「已加严」。而当三条约束围出的可行区为空时，那是一个合法且必须被报出来的结论，正确动作是回去改设计、改功能定义或者缩 ODD，⛔ 不是回头把门限调松——那是把判据换掉，不是把问题解决掉。这一条在第 5 讲展开、在常见误区一节合账。
全课的术语与符号口径，先在这里说死，因为本课有两组词天然会撞，撞了之后表面上一个字都看不出错。
第一组是「触发条件」。本课出现的「触发条件」一律指 SOTIF 语义——使功能不足显现为危害行为的运行条件。而在控制侧，这个词长期指的是模式切换的启动条件（模式管理见 K3-01 整车热管理控制策略总览与模式管理、预约与远程唤醒见 D3-04 低温预热与出行预约热管理、蒸发器自清洁启动见 C2-12 冷凝水排放、防霉与蒸发器自清洁）。⛔ 本课把控制侧的那一类一律写作「启动条件／切换条件」并标去向。两者混用的后果不是措辞不精确，是安全评审与控制需求评审各自认下了不同的东西，最后两边的验收口径对不上。
第二组是「域」。ODD（运行设计域）、输入域、可信域三词分列，全课不混用：ODD 是功能被允许工作的运行条件；输入域是送进算法的那组量的取值范围；可信域是模型输出可被采信的子集。三者通常呈嵌套关系，因此围出四个状态区——把可信域当成输入域的同义词用，这四个区会塌成两个，而塌掉的那两个恰好是最需要写明「谁来判、判出后交给谁」的（第 3 讲展开）。
符号方面全课统一使用八个：λ_target（目标危害发生率）、C（置信水平）、T_exposure（暴露量）、f_暴露（暴露因子）、P_触发（触发概率）、P_措施失效（措施失效概率）、R_残余（残余风险）、R_accept（接受准则）。完整的定义、基准与所属讲次列在第 1 讲末的约定表里，后续每一讲首次使用某个符号时都会复述它的定义与基准，⛔ 不指望你翻回来查。这里先立两条硬规矩：其一，⛔ 全课禁止裸写「风险」二字去指代其中任何一个——λ_target 是发生率，R_残余 是发生率与暴露量的乘积，两者量纲不同，⛔ 不可比大小、⛔ 不可互算；其二，第 4 讲之后 ⛔ 禁止丢下标，把 P_触发 与 P_措施失效 都简写成 P，是这条链上最容易发生、也最难被看出来的一处错。
⚠ 还有一条基准纪律：λ_target 与 T_exposure 自带基准（每小时还是每公里）。全课两个量必须同基准，基准由本项目在论证开始时声明；两套基准之间的换算要乘平均车速，而平均车速本身是平台相关量、且随场景（行驶／驻车／充电）变化 ⇒ ⛔ 不许随手换算。更要紧的是：驻车与充电场景下「每公里」这个基准根本不成立（车不动），这类危害只能用时间基准 ⇒ 一份混用两套基准的暴露量台账，在驻车相关危害上必然算错——而热管理里高价值的那几条危害，相当一部分恰好发生在驻车与充电时。
本课对数字有三条固定处理，先声明在这里，免得读到正文时以为是漏写。
第一类，可以给准确值的，只有结构性事实与本课自己定义的枚举。外部标准里，只有 ISO 26262 在本项目已核实的标准台账里有记录，可给的也只有三条结构事实：现行为第 2 版、共 12 个部分、以及「国际标准发布即生效，不存在分档实施日期」这一性质；⛔ 版次年份与发布日期一律不写成独立断言，正文统一附「以现行目录为准，引用前须核」。至于本课各处的枚举计数（分流六格、识别六路、场景要素五类、运行期措施四类加一条正交维度、剩余六类、四元组四格、监控器规格五项、检出延迟五段、数据集充分性四件、性能验收准则三件、收敛判据三条、接受准则三种来源、safety case 三支主张、OTA 三项证据），它们是本课自己定义的结构而不是对外部世界的测量，可以给——但每一处都会标明它是本课程体系已给的还是本课归纳的。动手做那一节的登记条数下限（触发条件不少于 6 条、可预见误用不少于 3 条）与六件交付物同理，它是本课程的作业下限，⛔ 不是任何标准的规定。
第二类，行业典型区间。本课几乎用不到，因为本课要判的量全都随平台与功能而变；凡出现的区间一律标「典型」，⛔ 端点不得当成可承诺值。
第三类，平台相关量一律不给数，本课有十二组：①除上述结构事实外，各标准的版次年份与实施日期；②置信水平 C 与目标危害发生率 λ_target 的取值，以及由它们算出的暴露量与折合车队规模；③新危害发现率的收敛门限；④运行期监控器的误报率预算与可接受误动作频次；⑤检出延迟五段的各段时长与危害发生的时间预算；⑥三个可信域判据量（逐维范围、局部密度或最近邻距离、模型预测方差）的阈值；⑦性能指标的验收门限；⑧ODD 各维的区间端点；⑨覆盖矩阵里的样本数、稀有高严重度类别的最低样本量、训练／验证／测试的划分比例；⑩残余风险式子的三个因子与 R_accept；⑪四象限中各格的面积、占比与「未知不安全」那一格的估计残量；⑫各类工具的性能指标、版本与许可。⚠ 其中第②组有一条要特别记住：C 是论证口径的选择而不是任何物性，它必须在验证开始之前被显式声明并随论证一起存档，⛔ 本课不给推荐值、也不写「常用取某值」这类惯例表述。⚠ 凡本课出现的带数值算例，输入与结果一律是教学假设值，不对应任何平台与任何型号，⛔ 禁止取用。
本课凡是要「列一张表」的地方，一律先把全集画出来、写明我是沿什么轴建的集，再逐格核射程，而不是顺着自己最熟的那条线索往下数。这不是讲究：沿单一线索枚举时漏掉的从来不是「少了一条」，而是整整一类不出现，而表面上那张表还是齐的。全课有六处这样的全集：
| 全集 | 建集的轴 | 最容易整类漏掉的那一格 |
|---|---|---|
| 一 · 危害成因（该走哪条线） | 件的状态（坏了／没坏）× 规格与用法的状态 | 上游外部数据源「数值有效但语义已过期」的那一支 |
| 二 · 交付物（该交哪些件） | 生命周期阶段 × 论证三层（主张／论据／证据） | 「运行与变更」整整一列 |
| 三 · 触发条件识别路径 | 从哪个方向往回找 | 从数据侧反查、从接口与版本变更反查 |
| 四 · 热管理侧场景要素维度 | 谁在给这个功能输入 | 历史与学习类（沿时间轴积累出来的那一类） |
| 五 · 运行期措施 | 它插在推理链的哪一段 | 效果侧（闭环残差与自适应补偿量的趋势） |
| 六 · 「剩余」的分类 | 它为什么还在 | 「已知不安全但尚无处置」与「非安全剩余」两格 |
⚠ 表里第一列的编号只是本讲义的行文顺序，⛔ 不是任何标准的分类号。举三个已经踩实的例子说明它为什么值得这么麻烦。其一，触发条件的识别路径，本课程体系已给四路（沿功能链逐环反问、从自有失效画像反查、按场景要素维度组合、从现场无故障码抱怨反挖），核一遍会发现这四路方向一致——都是从运行世界往回找 ⇒ 它们会一起漏掉同一类东西；本课因此补两路：从数据侧反查（覆盖矩阵里样本密度最低的每一个空洞格，本身就是一条候选触发条件，方向与前四路相反）与从接口与版本变更反查（信号语义改版、外部服务接口变更、标定表换代、模型换结构或换特征——这一类根本不在任何一条运行场景维度上，按场景组合永远组合不出它）。其二，场景要素若沿「道路场景」枚举，拿到的是感知类功能的建集轴，照抄到热管理上几乎不相关；改按「谁在给这个功能输入」建集得五类，其中第五类（历史与学习类）是本课补的——它不是某一时刻的场景快照，而是沿时间轴积累出来的，用快照的思路建集，无论快照取得多密都取不到它，而它恰恰是学习件与固定标定件最大的差别。其三，运行期措施若按「软件的／硬件的」分，会整类漏掉效果侧那一类（闭环残差与自适应补偿量的趋势监控）——前三类都只在当下这一次推理上判，唯有它抓得到缓慢漂移；同时还会漏掉一条不属于任何一类的正交维度：检出之后把权限交给谁。⇒ 交不出去的监控器不是措施，是看板。
本课有一批判据是本课归纳的，⛔ 不是任何标准、手册或行业公认的既有分类，引用时请连同这句一起带走：入口分流的六格判定表；识别路径里补的第⑤⑥路，以及第④路（从现场无故障码抱怨反挖）只在已有量产车队时才可用这条射程限制（新平台首发时这一路是空的，⛔ 不许把它当主力路排进计划）；场景要素的第五类；运行期措施的第四类与「检出后把权限交给谁」这条正交维度；「剩余」六类里的第②格与第⑥格；检出延迟的五段拆账；ODD／输入域／可信域三分与它们围出的四个状态区；上面那条阈值三者联立的判据句；以及三支主张的证据落点表。⚠ 其中有一条判断本课要明说它可被证伪：AI 件所需的数据集充分性、覆盖论证与运行期措施这三件，在失效侧的方法链里找不到对口的工作产品与验收准则 ⇒ 需要另两者的组合论证——这是本课的射程判断，⛔ 不是标准原文事实；检验它的办法很直接：去失效侧的工作产品清单里找对口项，找得到就说明本课这条判断错了。
本课涉及的外部规范，一律只写标准号与去向，⛔ 不写条款内容、⛔ 不写工作产品编号、⛔ 不写限值、⛔ 不写实施日期。ISO 26262 是接口：危害事件清单与严重度从那一侧继承，本课的论证链要与它的追溯链互链；定级方法、等级档位、硬件量化度量与诊断覆盖去向 K2-03 功能安全（ISO 26262）在热管理中的应用 与 I7-03 功能安全导向的结构与失效模式设计。ISO 21448 是工具，本课只取触发条件识别与场景及充分性方法两件。ISO/PAS 8800 是本课主轴——AI 生命周期四段的串接顺序由本课按工程逻辑组织，⛔ 本讲义任何一处都不写成「符合该规范的要求」，那是一条合规结论，本课没有依据去下。另有两个只在接口上出现：ISO 26262 的中国对应件 GB/T 34590 系列（性质是推荐性标准，⛔ 本课不写分部编号与发布实施时点，去向 K2-03 功能安全（ISO 26262）在热管理中的应用），以及软件更新工程标准 ISO 24089 与国内的 OTA 准入、备案及召回要求（⛔ 本课不给判定档次与时限，去向 K7-02 软件定义热管理与 OTA 迭代 与 M4-08 车用软件更新的准入与合规（R155/R156·GB 44495/44496·OTA 备案与召回））。⚠ 除 ISO 26262 的那三条结构事实外，其余四个本课未取到原文，一律写「版次与状态按现行版本确认」；国内预期功能安全与车用 AI 安全的采标件状态同样按现行目录确认，本课 ⛔ 不给标准号——给一个记错的标准号比不给贵得多，它会被读者原样抄进合规材料。这三个文件各自的角色与写法，第 1 讲会摆成一张对照表。
全课六讲，顺序就是把一条抱怨走成一份可签署的论证的顺序。
第 1 讲 问题域切分：先把三条线的射程分开，把入口判据定在「件坏没坏、规格是不是已尽当时之能」上，把「规范不足」落成判定三问，把防滥用红线（换热裕量、泵扬程、传感器精度、标定覆盖这四类 ⛔ 不走本课）正面立起来；再把这三条合成一张六格分流表，一条现象进来先落格再动手；然后把四象限从「分类法」纠回推进工具——三条迁移路径怎么走、度量为什么是「未知不安全那块面积的收敛趋势」而不是「已知不安全清零」；最后把与危害分析的接口写死为继承而非重做（同一危害只能有一套安全目标），把本课不判的东西一次列全，并交出全课通用的术语与符号约定表。
第 2 讲 触发条件与可预见误用：先做命名分家，再讲六路并行的识别（缺一路就有系统性盲区），把每一条触发条件写成可判定四元组｛条件描述、可观测判据、导致的功能不足、危害行为｝——写不出可观测判据的条目只能留在待办清单，⛔ 不计作已识别，因为它既进不了场景库，也做不出运行期监控器；然后讲触发条件常常是组合而非单条件（本课案例正是组合形态）、可预见误用是独立的分析步骤而不是免责条款（判据是「可合理预见」而不是「合规使用」，处置分三档）、同一现象要按性质切开（链路失效走失效侧与 K5-02 热管理故障处理与降级策略，语义判错走本课）；最后要求登记表里每一条都被指派到至少一项处置，⛔ 无处置的条目不许悬空，直接进第 6 讲的残余风险账。
第 3 讲 域声明与场景覆盖：热管理侧的 ODD 不是道路场景清单，它要落成可机检的边界，运行期才判得出「现在是否在域内」；三个域的词分列并围出四个状态区；可信域声明是跨课统一交付物——本课给格式，各应用课给取值（J7-05 机器学习/AI 代理模型在热管理中的应用 的代理模型、K7-01 预测性热管理（导航/云端/驾驶意图协同） 的预测输入、K7-03 数据驱动的能效自学习控制 的学习件训练分布，三处指向同一张表）；场景库按要素层 × 组合层两层组织、剪枝必须留记录；「够」不是场景条数，而是三条同时成立；发现率曲线走平 ≠ 收敛（挖掘方法本身用尽也会造成假性走平）；用公式一证明纯堆暴露量这条路走不通，把充分性逼向「场景加速 ＋ 分层证据 ＋ 运行期监控」的组合论证，并讲清一条主张只挂得住与其精度等级相称的证据。
第 4 讲 离线的开发期证据：数据集充分性与覆盖论证要交四件，缺一件不成论证——版本标识为什么排第一（信号语义改版造成的口径断层，会被误读成分布漂移，而两者处置方向相反）、覆盖矩阵与空洞清单怎么建、稀有但高严重度类别的最低样本量与获取手段、以及划分独立性的判据句（同一工况的不同参数化点混入训练侧与测试侧，即论证作废）；性能指标验收准则三件——按危害方向分列、每个门限给出来源、声明ODD 分层子集上的最差值而不只是总体均值；最后把四样件按 AI 生命周期串成一条链，它同时也是学习件变更评审要交的那四样。
第 5 讲 车上的在线措施：把运行期监控器规格化到五项，缺「交给谁」或缺「延迟对照」的 ⛔ 不算措施；给出检出延迟的五段拆账与时间预算的对照判据；讲清三个判据量各抓不同的失效形态、⛔ 不可互相替代（高维输入下凸包类判据既算不动也判不出）；把误报率与降级代价绑在一起算，并把可被标定关闭的措施开关列入参数锁定分级（分级清单归 K7-02 软件定义热管理与 OTA 迭代）；落上面那条阈值三者联立的判据句；再讲运行期措施的四类全集与那条正交维度，以及监控器 ⛔ 不是越多越好——每加一个就加一条误报路径与一条降级路径，多个监控器的降级动作还可能互相冲突。
第 6 讲 收口：用公式二把「残余风险可不可接受」从口头判断变成逐条可审的账；接受准则的三种来源 ⛔ 不可混用，且必须声明「这是谁的可接受」；与冗余到位后由共因失效主导的硬件失效残余量（I7-02 失效安全（Fail-safe）与冗余设计／I7-03 功能安全导向的结构与失效模式设计）严格分家，⛔ 不可互相援引、⛔ 不可相加成一个总数；「剩余」六类里哪两类 ⛔ 不进安全残余风险账；放行签署落成一张可执行的表，重点在有效期与失效条件（ODD 变了、数据分布变了、模型结构或特征定义变了，批准即失效，必须重签）；safety case 按主张—论据—证据三层组织、顶层拆三支并与失效侧互链；OTA 下发要多交的三项证据（尤其是可信域声明必须与模型成对下发、成对回滚，只回代码会留下「新可信域配旧模型」的悬空态）；最后收在「主张—证据—缺口」对照表上，⛔ 不许留空白格。其后的典型案例把六讲的判据合成一条完整的决策链（开头那条清晨自行唤醒），动手做则用一个真实的热管理数据驱动件把六件交付物各做一遍。
最后把边界摆出来，写清楚是为了让你知道哪些东西不在这里找，本课对它们一律只给类型与去向、⛔ 不给限值、⛔ 不给等级号、⛔ 不给条款内容：危害分析与风险评估的定级方法、等级档位与硬件量化度量在 K2-03 功能安全（ISO 26262）在热管理中的应用／I7-03 功能安全导向的结构与失效模式设计；降级策略与故障处理的状态机实现、降级等级体系在 K5-02 热管理故障处理与降级策略；护栏、限幅与自学习策略的车端实现在 K7-03 数据驱动的能效自学习控制；置信度加权与降级回退在 K7-01 预测性热管理（导航/云端/驾驶意图协同）；代理模型的算法与三件套判据的算法本体在 J7-05 机器学习/AI 代理模型在热管理中的应用；虚实差距核验与上车台阶在 N6-02 整车热管理数字孪生与在线优化；环境舱与整车热平衡标定的放行口径在 K6-04 环境舱与整车热平衡标定（整车级验收清单与放行签署已由它承担，本课只补要额外加签的那几行）；灰度节奏、回滚门限、参数锁定分级与合规留痕在 K7-02 软件定义热管理与 OTA 迭代；软件更新的准入、备案与召回口径在 M4-08 车用软件更新的准入与合规（R155/R156·GB 44495/44496·OTA 备案与召回）；跨企业交付边界与联合验证签署在 K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署；车队数据的采集口径与车端实现在 K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算／K7-03 数据驱动的能效自学习控制；人员感知类功能的本体在 C6-04 智能座舱：人员感知与按需送风（露营/休息模式）。
⇒ 于是本课自己承担的只有六块，正好对应六讲与六件交付物：① 问题域切分与「规范不足」判据；② 触发条件与可预见误用的系统性识别与登记格式；③ ODD／输入域／可信域三分与覆盖收敛的三条判据；④ 数据集充分性与性能验收准则的论证方法；⑤ 运行期措施的规格化与检出延迟论证；⑥ 残余风险接受准则、放行签署与论证链的组织。本课能给你的不是一份能直接抄的模板，是那一整套「这条证据算不算数、这一签能不能签」的判据——学扎实之后，上面那些相邻课你会用同一副眼光去读。
第 1 讲 问题域切分：入口判据是「件坏没坏、规格已尽当时之能没有」，⛔ 不是后果重不重
一份预期功能安全的材料被退回，最贵的那一次通常不发生在分析做得细不细这一层，而发生在还没开始分析之前的那一步：手上有一个不期望的现象，它到底该走哪条方法链。这一步走错，代价不是「多做了一点」，而是整条方法链被用在一个它接不住的问题上——拿失效模式与诊断分析去处理「件全好着、规格也按当时能力实现对了、输出却仍不合理」这一类，那里根本不存在一个可以挂失效率、可以算诊断覆盖的失效模式；反过来，把「换热能力裕量不够」包装成「功能不足」送进本课这条线，评审第一轮就退回，而且真正的能力不足会被淹没在那一堆条目里。
本讲不识别任何一条具体的触发条件，只做九件事：立入口判据（1.1）、把它落成「规范不足」的判定三问（1.2）、把防滥用红线正面立起来（1.3）；再把这三条合成一张六格分流表，一条现象进来先落格再动手（1.4）；然后交代本课要用到的几个外部文件各扮演什么角色、本课以哪一个为纲（1.5）；把已知/未知 × 安全/不安全四象限从「分类法」纠回「推进工具」（1.6）；说清与危害分析的接口是继承而非重做（1.7）；把本课明确不判的东西与去向一次列全（1.8）；最后立一张全课通用的术语与符号约定表（1.9）。
⚠ 先说一句关于数的话，免得读者在本讲里白找：本讲只给一处结构性数字——失效侧那条标准的版本与部分数——此外一个数都没有。这不是省略，本讲交付的全部内容是射程、口径与结构；凡是带数的结论，要么在后面几讲、各自带自己的来源，要么本课明说不判、只给去向。
1.1 入口判据问的是成因，⛔ 不问后果，也 ⛔ 不问功能里有没有 AI
是什么。失效侧那条方法链（危害分析与风险评估 → 技术安全需求 → 硬件失效模式与诊断分析，整链展开见 K2-03 功能安全（ISO 26262）在热管理中的应用 与 I7-03 功能安全导向的结构与失效模式设计）只接一种输入：件的失效行为。它含两类——某个元件在使用中坏了（随机硬件失效），或者规格写对了而实现错了（软件缺陷、标定表刷错、集成错，属系统性错误）。⇒ 只要输入是这两类之一，无论后果多重，都留在那条线上。
另有一类现象看起来很像、成因正相反：件一个都没坏、规格也按当时的认知与能力被正确实现了，输出却仍然不合理并导致危害。它的成因是感知、判断或决策的能力边界。失效侧那条链接不住它——那里既没有一个可以填失效率的失效模式，也没有一个可以算诊断覆盖的通道。这一类才是本课这条线的入口。
为什么这条分界值钱。因为两侧的分析对象根本不同：失效侧问的是「哪个失效模式、诊断覆盖到多少」，本课这条线问的是「哪个运行条件让这个功能的能力不够」。输入接错，后面整条链的产出都对不上——评审时既拿不出对口的证据，也说不清另一侧为什么没做。⇒ 分流⛔ 不是形式动作，它决定了后面每一件交付物长成什么样：走失效侧要交的是失效率与诊断覆盖，走本课这条线要交的是触发条件四元组、覆盖论证、性能验收准则与运行期措施规格，两套件互相替代不了。
⚠ 还有一条同样常见的错入口：看功能里有没有 AI。「用了神经网络所以要做这一条线」与「没用神经网络所以不用做」——两句都是错的。一个纯查表的标定策略，只要它对运行状态的判断会在某些条件下失准并导致危害行为，同样落在本课这条线上；而一个学习件所在的控制器板子焊点开裂，照旧走失效侧。判据在成因，⛔ 不在实现技术。之所以要专门说这一句，是因为「里面有 AI」是目前最流行的一条伪判据，它既会把不该进来的功能拉进来，也会把该进来的传统标定件挡在外面。
工程量级。本条不涉及任何数值。⛔ 本课不给等级、不给档位、不给硬件架构度量与诊断覆盖的量化——那些是失效侧的判据，去向 K2-03 功能安全（ISO 26262）在热管理中的应用 与 I7-03 功能安全导向的结构与失效模式设计（本课不判的东西 1.8 一次列全）。
易错点。按后果严重程度选线。热失控这类后果最重的危害，只要成因是电子电气系统的失效，就仍然走失效侧；反过来，一个只造成「白预热一次、多耗一点电」的现象，若成因是能力不足，它就在本课这条线上。⇒ 后果决定的是该花多大力气去防，⛔ 不决定走哪条线去分析。这两件事在中文里都被叫作「重要性」，混起来最省事，代价是做出一整套没人认的证据。
1.2 「规范不足」判定三问：三问全为是才启动，任一为否各有各的去向
是什么。把 1.1 那条口头判断落成三问。⚠ 三问是一个合取判据——三问全为「是」，才启动本课这条线：
- 问① 需求写的是不是当时认知与能力所及的最好描述？
- 问② 危害是否在需求被正确实现的前提下发生？
- 问③ 危害是否来自感知、判断或决策的能力边界，而不是某个件的失效？
任一为「否」，各有各的去向，⛔ 没有「差一点也算」这一档：
| 哪一问为否 | 说明它其实是什么 | 去向 |
|---|---|---|
| 问① 否 | 需求当时能写对而没写对 | 回需求评审，⛔ 不是本课 |
| 问② 否 | 需求写对了、实现错了 ⇒ 系统性错误 | 失效侧方法链，K2-03 功能安全（ISO 26262）在热管理中的应用 |
| 问③ 否 | 某个件坏了 ⇒ 随机硬件失效 | 失效侧方法链，K2-03 功能安全（ISO 26262）在热管理中的应用／I7-03 功能安全导向的结构与失效模式设计 |
为什么要三问，而不是一问。因为三问分别锁住了三条最常见的滥用路径，缺任何一问都会漏进一整类不该进来的条目：缺①，「没写好的需求」会被追认成能力不足；缺②，实现缺陷会被当成能力边界；缺③，件的失效会被当成判断失准。⚠ 其中第①问是自证条款，它要求把「当时的认知与能力」的边界写出来——当时手上有哪些数据、可用的方法到什么程度、有哪些工程与时间约束。没有这一条，任何做得不好的需求都可以在事后被追认成「已尽当时之能」，三问就退化成一句谁都能通过的口号。
工程量级。判定的产出就是一张表的三列：问题、答（是／否）、依据。依据那一列填的是理由与佐证，⛔ 不是一个结论词——「因为它是 AI 件」不是依据。⛔ 本课不给命中率、通过率、各格条目占比这类统计数：它们取决于项目阶段与本项目的功能构成，属平台相关量（数的口径见 1.9 与 1.8）。
易错点。两个，方向相反。①只答第③问就下结论。「能力边界」这四个字听起来什么都能往里装，单独拿它当判据，下一节的防滥用红线整条失效。②把三问当成一次性的入场券。功能定义改了、运行设计域改了、上游接口的语义版本改了，三问都要重答一遍——这与 1.4 那张分流表必须复审是同一件事，⛔ 不是两条独立的要求。
1.3 防滥用红线：裕量、选型与标定覆盖不到位 ⛔ 不走本课这条线
是什么。四类现象明确不走本课这条线：换热能力裕量不足、泵扬程选小、传感器精度不够、标定表工况覆盖不到位。它们的共同特征只有一句：规格本可以写对、能力本可以做够，只是没做够。放进 1.2 的三问里，它们在第①问就答否。⇒ 去向是对应的设计与选型专课，以及阈值整定复验；整车级的标定与放行口径见 K6-04 环境舱与整车热平衡标定。
为什么必须挡住。因为它们与真正的能力不足在现象上很像、在成因上正相反——两者读起来都是「功能没有达到预期」，而一个是当时认知与能力所限，另一个是当时明明做得到却没做到。挡不住的代价有两层，第二层比第一层贵得多：
- 第一层：评审第一轮就退回。这些条目在本课这条线上根本找不到对口的处置——它们既写不出触发条件的可观测判据（第 2 讲），也做不出一个有意义的监控器规格（第 5 讲），因为要监视的量就是那件硬件本身的能力。
- 第二层：真正的能力不足被淹没在里面。一份混进了大量裕量条目的登记表，按它算出来的新危害发现率曲线也跟着失真——分母里塞满了本不该在这条线上的条目，曲线会比真实情况更早走平，而第 3 讲的收敛判据恰恰是读这条曲线的。⇒ 滥用不只是「多了一堆无效工作」，它会把收敛结论本身做假，而「未知不安全那块面积已收敛到事先声明的门限以下」正是本课最后要签字的三支主张之一。
工程量级。⛔ 四类全部不给限值与裕量数——它们是平台相关量，须由本项目按其目标市场与整车条件确定。本课在这里只给两件事：它归哪条线，以及去哪里找对口的判据。
易错点。矫枉过正——把所有涉及硬件能力的条目一律推给设计课。判据仍然是 1.2 的三问，⛔ 不是「有没有涉及硬件」。举一个正好落在另一侧的例子：换热器本身的能力是够的，而判断什么时候该开它的那个模型在某一组运行条件下判错——件没坏、实现也对、规格在当时的认知下就是不足，那是能力不足，在本课这条线上。⇒ 判据看的是「谁不够」：不够的是硬件能力还是判断能力。
1.4 六格分流表：一条抱怨进来先落格，再动手
是什么。把前三节合成一张表。⚠ 建集的轴不能是「部件 → 传感器 → 算法」：沿那条线索只数得出「谁坏了」，它天然漏掉「谁都没坏」的整类，而且漏掉的方式不是「少了一条」，是整类不出现，表面上看那张清点表还很完整。⇒ 本课改用二维建集：件的状态（坏了／没坏）× 规格与用法的状态，共六格。★ 这张六格分流判定表是本课归纳的，⛔ 不是任何标准既有的分类方式；它与「某个标准自己的适用范围图」也不是同一张图——那一张画的是一个文件管到哪里，本表画的是一条现象进来往哪走。
| 格 | 落格判据 | 去向 | 这一格该交哪种证据 |
|---|---|---|---|
| 格1 件坏了 | 随机硬件失效 | 失效侧方法链，K2-03 功能安全（ISO 26262）在热管理中的应用／I7-03 功能安全导向的结构与失效模式设计 | 失效模式与诊断分析一侧的证据 |
| 格2 实现错了 | 件没坏、规格写对了，而软件缺陷／标定表刷错／集成错 | 系统性错误，仍走失效侧 | 过程、评审与验证强度一侧的证据 |
| 格3 能力不足 | 件没坏、实现也对，而规格本身在当时认知与能力下就不足 | 本课这条线 | 触发条件四元组、覆盖论证、性能验收准则、运行期措施规格 |
| 格4 可预见误用 | 件没坏、规格也够，但被用在声明的使用条件之外 | 本课这条线，处置分三档 | 误用登记与处置档、约束声明与界面告知、运行期监控加降级 |
| 格5 裕量与标定不足 | 选型、裕量或标定覆盖不到位 | ⛔ 不走本课：对应设计课与阈值整定复验，整车级见 K6-04 环境舱与整车热平衡标定 | 设计复核与标定放行一侧的证据 |
| 格6 上游数据源失真 | 导航／日历／云端／桩侧数据不对 | 再分两支，见下 | 见下 |
格6 必须再切一刀，否则两条线会互相推诿：
- 链路层——报文超时、总线中断、传感器失效：数值没送到，或者电气上已经无效 ⇒ 属电子电气失效，走失效侧与 K5-02 热管理故障处理与降级策略；
- 语义层——报文正常、数值电气有效、时间戳也还在有效期内，但内容被判错、或者已经过期而未被识别 ⇒ 本课这条线。
★ 格6 的第二支是本课显式立出来的一格（⛔ 不是既有划分）。常见的切法只切到「报文超时 vs 模型判错」两支，而预测类热管理功能最常见的形态恰好是第三种：报文正常、数值在范围内、内容却已经过期——用户改了行程而日历没删、导航中途改了路线、桩侧状态还停在十分钟前。它既不是链路失效也不是模型判错；不单独立成一行，两条线都会把它推给对方，最后没有人处置它。
为什么要落成一张表，而不是口头判一次。三个理由：
- 分流是本课全部产出的入口，入口错则后面每一件交付物都白做；而它偏偏是最容易被跳过的一步——工程师看到现象，往往直接开始想措施。
- 同一批现象在不同人手里落格不一致，这是本课最先应该暴露的口径分歧。落成表（三列：现象、落在哪一格、判据句与依据）能把它当场摆出来，⛔ 不必等到放行会上才发现两个部门在按两套判据做事。
- 格5 在表上是一个正当终点，⛔ 不是遗漏。把它从表上抹掉，看起来更简洁，实际是把 1.3 的防滥用红线拆了——本课这条线立刻变成万能筐。
工程量级。⛔ 表的行数、各格的条目数与占比全是平台相关量，一个数都不给。本课给的是格的定义、判据句与去向。
易错点。两个。①省掉格5（见上）。②只做一次分流、不复审——功能定义改了、运行设计域改了、上游接口的语义版本改了，都要重新落格；这与 1.2 三问要重答是同一件事，⛔ 不是两条独立的要求。
1.5 三条线各管一段，⛔ 不是三选一——本课以 AI 安全那一条为纲
是什么。本课要用到三个外部文件，它们在本课里的角色互不相同，本课对它们的写法也各不相同：
| 文件 | 在本课的角色 | 本课怎么写它 |
|---|---|---|
| ISO 26262（道路车辆功能安全） | 接口——危害事件与严重度从这一侧继承，本课的论证链要与它的追溯链互链 | 可给的结构事实只有一条：现行为第 2 版、共 12 个部分（来源＝本项目已核实的标准台账条目）；⚠ 版次与年份以现行目录为准，引用前须核；⛔ 各部分内部的条款内容一律不写，去向 K2-03 功能安全（ISO 26262）在热管理中的应用／I7-03 功能安全导向的结构与失效模式设计 |
| ISO 21448（预期功能安全） | 工具——本课只取两件：触发条件识别、场景与充分性方法 | ⛔ 本课未取到原文 ⇒ 只写标准号与去向，版次与状态按现行版本确认；⛔ 不写条款内容 |
| ISO/PAS 8800（道路车辆 AI 安全） | 本课主轴——AI 生命周期的组织顺序：运行设计域界定 → 数据集充分性 → 性能验收准则 → 运行期措施 | ⛔ 本课未取到原文 ⇒ 只写标准号与去向；该文件为公开可用规范性质，其版本状态与是否已转为正式标准按现行版本确认；⛔ 不写它要求的工作产品编号与清册 |
另有两个只在接口上出现：ISO 26262 的中国对应件 GB/T 34590 系列（性质是推荐性标准；⛔ 本课不写分部编号、不写发布与实施时点，去向 K2-03 功能安全（ISO 26262）在热管理中的应用）；软件更新工程标准 ISO 24089 与国内的 OTA 准入、备案及召回要求（⛔ 本课不给判定档次与时限，去向 K7-02 软件定义热管理与 OTA 迭代 与 M4-08 车用软件更新的准入与合规（R155/R156·GB 44495/44496·OTA 备案与召回））。⚠ 国内预期功能安全与车用 AI 安全的采标件状态同样按现行目录确认，本课⛔ 不给标准号——给一个记错的标准号，比不给贵得多，它会被读者原样抄进合规材料。⚠ 另附一条结构性事实备对照：国际标准发布即生效，不存在分档实施日期；国内对应件的性质与时点另说（去向 K2-03 功能安全（ISO 26262）在热管理中的应用，⛔ 本课不给时点）。
为什么不是三选一。把三者当成互斥的选项，会出现「我们选了预期功能安全，所以功能安全那一套不做」这种在同一个功能上只做一半的做法。实际上同一个热管理功能的不同危害会分别落在不同的线上：同一个到桩预热功能，控制器某路输出级损坏导致的持续加热在失效侧，行程意图判错导致的无谓唤醒在本课这条线上。⇒ 判定必须逐条危害做，⛔ 不是逐个功能做。1.4 那张表的每一行是一条现象或一条危害，⛔ 不是一个功能——这是那张表最容易被填错的一处，填成「一个功能一行」，表就再也分不出这两类了。
★ 一条必须写明的诚实声明（本课判断，⛔ 不是条款）：ISO 21448 的名义范围以「安全高度依赖情境感知、而感知又来自复杂传感与算法」的功能为中心（典型是驾驶辅助与紧急干预类）——这句中文表述是本课的归纳，不是条款原文。据此，把它用到热管理的数据驱动件上属方法论迁移，⛔ 不是天然适用。⇒ 本课以 ISO/PAS 8800 为纲、只从 ISO 21448 取两件工具，正是这条判断的直接后果；而上表里 AI 生命周期四段的串接顺序，也由本课按工程逻辑组织并在此标明是本课归纳，⛔ 不得读成「符合该规范的要求」——后者是一条合规结论，本课没有依据去下。
工程量级。本节唯一的数是「第 2 版、共 12 个部分」，来源已注明，且必须带「以现行目录为准，引用前须核」。⛔ 其余四个文件本课未取到原文，一个条款字都不写。
易错点。两个。①把「用在热管理上」说成「天然覆盖热管理」——迁移要标明是迁移，⛔ 不得写成适用；这一处写松了，后面每一条方法的射程都跟着松，读者会以为方法自带权威。②拿本课的表述去当验收依据：本课给的是论证方法，⛔ 不是合规依据；验收依据要回到各文件的现行原文与本项目自己的规范。这句话 1.8 还会再说一遍，因为它是本课最容易被读者带出教室的一句。
1.6 四象限是推进工具不是分类法：度量在「未知不安全」那一格的收敛趋势
是什么。横轴分已知／未知，纵轴分安全／不安全，得四格：已知安全、已知不安全、未知安全、未知不安全。⚠ 这四格不是给危害贴标签用的，它们是一张账——每一轮活动都要说清：把哪一块面积、从哪一格、迁到了哪一格、用的是哪一种手段。三条路径：
- 路径 A（场景挖掘）：未知不安全 → 已知不安全。手段是第 2、3 讲的多路识别与场景库；
- 路径 B（措施）：已知不安全 → 已知安全。手段分三档——设计消除、约束声明加界面告知、运行期监控加降级；
- 未知安全：不必治，但它决定验证成本——为了确认某一块确实安全，该花的验证一分不少，只是它不产出措施。
为什么这个区别值钱。把四象限当分类法用，产出的是一张静态清点表，读不出「这一轮到底做了多少」；当成推进工具用，每一轮活动都能落成一条可审的迁移记录——挖出若干条新危害 ⇒ 未知不安全迁向已知不安全；配上若干条措施 ⇒ 已知不安全迁向已知安全。⇒ 本课这条线的活动度量是未知不安全那一块面积的收敛趋势，⛔ 不是「已知不安全清零」：后者只说明手上这一批场景治完了，它跟「还有多少没被识别出来」没有关系。⇒ 这一格的收敛趋势，正是第 6 讲那三支主张里第二支要证的东西，它的证据在第 3 讲的发现率曲线上，⛔ 不在任何一张已办清点表上。
工程量级。⛔ 四格的面积、占比与各格条目数一律不给数，图上也按等分示意画，⛔ 不按任何估计比例调整格的大小。未知不安全那一格的估计残量，本课只给论证方式——由发现率曲线与事先声明的门限对比，加上剩余部分的归属论证（第 3 讲与第 6 讲）——⛔ 不给单点值。
易错点。两个。①只走路径 B、不走路径 A：只给已知问题配措施、不再挖新场景。这是最常见的停滞形态，账面上「已知不安全清零」很好看，而未知不安全那一格根本没动过。②★ 本课归纳的一条常见误读：在材料里把「未知不安全 = 0」当成收敛证据。未知不安全按定义就是还没被识别出来的那一部分，把它填 0 恰恰是「还没开始做」的标志，而报告上读起来像已经收敛了。⇒ 正确的表述是发现率曲线与事先声明的门限的对比，⛔ 不是一个计数。
1.7 与危害分析的接口是继承而非重做：同一危害只能有一套安全目标
是什么。本课不重新定义危害、不重新评严重度。危害事件清单与严重度沿用失效侧危害分析的结果，本课在既有危害事件上挂一层新的成因链——触发条件 → 功能不足 → 危害行为——并由这一层因果链派生出新的措施要求与新的验证要求。
为什么必须是继承。因为两侧各定一次，会长出两个互相矛盾的验收口径。同一个危害：失效侧的安全目标可能要求某个通道的诊断覆盖，本课这一侧的目标可能要求某个监控器的检出延迟；两者若各自独立成文、互不相认，集成时必然出现「按哪一个验」的争议——而这种争议往往在放行会上才暴露，那正是它代价最高的时刻，因为此时两侧的证据都已经按各自的口径做完了。⇒ 硬口径只有一条：同一危害只能有一套安全目标；本课这条线派生出来的要求要挂在那一套之下，⛔ 不另起一套。
工程量级。⛔ 严重度的分档方式与安全目标的写法属条款内容，本课未取到原文 ⇒ 只写去向 K2-03 功能安全（ISO 26262）在热管理中的应用，⛔ 不复制定级表、⛔ 不写档位号。
易错点。把「继承」做成「照抄」。继承的是危害事件与严重度；而运行场景与暴露口径必须重评——本课新增的那些场景（驻车中的远程唤醒、充电过程中、外部数据源异常或已过期）在原来的危害分析里可能整格不存在。照抄就等于把这些场景的暴露量默认成零，而第 6 讲那张残余风险账的第一个因子正是暴露量，它一旦默认成零，整条论证会得出一个漂亮而空心的结论。⚠ 与之配对的还有一条反向要求：本课新增的成因链不改变严重度，⛔ 不许因为「这条链是新发现的」就把严重度往上调一档——严重度的判据在另一侧，两侧各调一次，1.7 这一节就白写了。
1.8 本课不判什么：一次列全，只给类型与去向
是什么。一条明写在本讲、并在后面每一张涉及等级、门限或条款的图上以去向框复述的射程声明。本课判三件事：这一组论证成不成立、证据够不够、谁签字。本课不判的东西与它们的去向：
| 本课不判什么 | 去哪里 |
|---|---|
| 危害分析的定级方法、等级档位、硬件架构度量与诊断覆盖的量化 | K2-03 功能安全（ISO 26262）在热管理中的应用／I7-03 功能安全导向的结构与失效模式设计；⛔ 本课不给档位号与判据表 |
| 降级策略与故障处理的状态机实现 | K5-02 热管理故障处理与降级策略；本课只论证「这条触发条件必须配一条降级」以及降级判据从哪来 |
| 护栏、限幅与自学习策略的车端实现 | K7-03 数据驱动的能效自学习控制 |
| 置信度加权与降级回退 | K7-01 预测性热管理（导航/云端/驾驶意图协同） |
| 代理模型的算法与可信度评估方法 | J7-05 机器学习/AI 代理模型在热管理中的应用 |
| 虚实差距核验与上车台阶 | N6-02 整车热管理数字孪生与在线优化 |
| 环境舱与整车热平衡标定的放行口径 | K6-04 环境舱与整车热平衡标定；本课只补要额外加签的那几行 |
| 灰度节奏、回滚门限、参数锁定分级与合规留痕 | K7-02 软件定义热管理与 OTA 迭代 |
| 软件更新的准入、备案与召回口径 | M4-08 车用软件更新的准入与合规（R155/R156·GB 44495/44496·OTA 备案与召回）；⛔ 本课不给判定档次与时限 |
| 跨企业交付边界与联合验证签署 | K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署 |
| 车队数据的采集口径与车端实现 | K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算／K7-03 数据驱动的能效自学习控制 |
| 感知误判本身的形态与机理 | C6-04 智能座舱：人员感知与按需送风（露营/休息模式）；本课补的是「覆盖到什么程度算够」的收敛判据这一块 |
| 冗余到位后由共因失效主导的硬件失效残余量 | I7-02 失效安全（Fail-safe）与冗余设计／I7-03 功能安全导向的结构与失效模式设计；⚠ 它与本课的残余风险语义不同，第 6 讲专门分家 |
为什么这条要正面写在这里，⛔ 而不是藏在小字里。因为本课引用的五个外部文件里，只有 ISO 26262 在本项目已核实的标准台账里有记录，而且核到的只有「版本与部分数」这一层结构事实，各部分内部的条款内容一律未核；另外四个连版次都还是待核状态。⇒ 按本项目的写作口径，未独立核对过原文的条款内容与限值一律不写，只写标准号加去向。这不是谨慎过头：本课的主轴文件恰恰是那批未核的，而读者最可能拿这门课去当合规依据用；给出一个没核过的限值或工作产品编号，读者会照着做出一整套通不过审核的证据，而错误的源头在本讲这一页。
⚠ 由此还要处理一条很容易被写成「标准原文事实」的断言。工程界常见的说法是「某版功能安全标准的正文不含机器学习的专门要求」——本课不这样写，因为本课没有核过那几部分的条款正文。本课把它改写成一条可被证伪的射程判断（★ 本课归纳）：AI 件所需的三件东西——数据集充分性论证、相对运行设计域的覆盖论证、运行期监控作为安全措施——在失效侧的方法链里找不到对口的工作产品与验收准则，⇒ 需要另两个文件的组合论证。⚠ 它怎么证伪也一并写清：去失效侧的工作产品目录里找这三件的对口项，找得到就说明本课这条判断错了。⛔ 本课不把它写成不容置疑的结论——一条讲得出如何被推翻的判断，比一条借标准之口说出的断言更经得起评审。
工程量级。本节可给的数只有 1.5 已经给过的那一条结构事实，⛔ 其余一律不给。⚠ 各类工具（需求与追溯工具、安全分析工具、场景要素与场景库管理表、数据回流与回放平台、仿真与半实物重放平台）的性能指标、版本与许可本课一概不给，也不做选型推荐——工具不在本课射程内。本课只写「哪一件交付物由哪一类工具承载」，并写明判据落在交付物本身而不在工具上：工具里放着一张空表，与没有表是同一件事。
易错点。读者拿本课的方法链去当验收依据用。本课判的是论证成不成立、证据够不够、谁签字；⛔ 它不判降级怎么实现、护栏怎么写、灰度与回滚怎么发，这三样各有专课，上表已逐条给了去向。⚠ 反过来也要防：把上表读成「这些事本课不关心」——恰恰相反，上表每一行都是本课论证链上的一个接口，本课要写清它由谁交、什么时候交、交来的东西支持哪一条主张，只是不由本课定它的内容与限值。
1.9 全课术语与符号约定：先把两组会撞的名字分开
是什么。一张写在本讲末的术语与符号约定表。后面每一讲首次用到某个符号时都会复述它的定义与基准，⛔ 不指望读者翻回本页。
第一组：两个「触发条件」，主语根本不同。
- 触发条件（本课语义）＝ 使功能不足显现为危害行为的运行条件。它的主语是「什么运行条件让这个功能的能力不够」；
- 控制侧那个同名词——模式什么时候切、预约与远程唤醒什么时候起、蒸发器自清洁什么时候启动——主语是「功能什么时候开始动作」。本课把这一侧一律改写成「启动条件／切换条件」并标去向（K3-01 整车热管理控制策略总览与模式管理／D3-04 低温预热与出行预约热管理／C2-12 冷凝水排放、防霉与蒸发器自清洁）。
⚠ ⛔ 只加一句「本文的触发条件指本课语义」是不够的。一份文件里两义并存时，控制工程师读到的是「什么时候开始动作」，安全工程师读到的是「什么时候会出事」，两个人都认为自己读懂了、都签了字，而签的不是同一件事，最后两边的验收对不上。⇒ 有效的做法是把控制语义那一侧改名；⛔ 只声明不改名，读者仍会在后面几讲把两者读混。（第 2 讲展开）
第二组：三个域，⛔ 互不为同义词。
- 运行设计域（ODD）＝ 本项目声明这个功能可以被使用的运行条件范围——它是一条承诺；
- 输入域＝ 送进算法的那组量各自的取值范围与允许的组合；
- 可信域＝ 在输入域之内、模型的输出还值得采信的那一块。
三者一旦被当成同义词用而塌成两个，第 3 讲那四个状态区就会塌成两个，其中「在输入域内、却已经出了可信域」那一格会整格消失——而运行期措施里恰好有一整类（模型侧判据）是专门盯着那一格的。
符号表（八个，全课统一）。⛔ 全课禁止裸写「风险」二字去指代其中任何一个：
| 符号 | 含义 | 基准／量纲 | 主要用在 |
|---|---|---|---|
| λ_target | 目标危害发生率，逐危害、逐场景给出 | 每单位暴露量的发生次数；基准由本项目声明 | 第 3、4、6 讲 |
| C | 论证所取的置信水平，须在验证开始前显式声明并随论证存档 | 无量纲 | 第 3 讲 |
| T_exposure | 零失效观测下所需的暴露量 | 与 λ_target 同基准 | 第 3 讲 |
| f_暴露,i | 第 i 条危害行为对应运行条件的暴露量（或其份额） | 与 λ_target 同基准，或无量纲份额 | 第 6 讲（取值来源在第 3 讲） |
| P_触发,i | 该运行条件下功能不足显现为危害行为的条件概率 | 无量纲 | 第 6 讲（证据来自第 3 讲的场景库验证） |
| P_措施失效,i | 已指派的措施在这一条上失效的概率 | 无量纲 | 第 6 讲（证据来自第 5 讲的监控器规格与检出延迟） |
| R_残余,i | 第 i 条措施用尽后仍留下的能力不足残余量（口径见第 6 讲 6.3） | 发生率 × 暴露量的乘积；基准随 f_暴露,i，与 R_accept,i 同量纲。⛔ 与 λ_target 量纲不同，⛔ 不可比大小、⛔ 不可互算 | 第 6 讲 |
| R_accept,i | 第 i 条事先声明的接受准则 | 与 R_残余,i 同量纲（⛔ 同样不与 λ_target 比大小） | 第 6 讲 |
两式的形状（逐项展开见「关键公式详解」，用法分别在第 3 讲与第 6 讲）：
- T_exposure ≥ −ln(1 − C) / λ_target
- R_残余,i = f_暴露,i × P_触发,i × P_措施失效,i，逐条与 R_accept,i 对表
⚠ 基准口径——这是全课最容易在后面几讲失守的一条。λ_target 与 T_exposure 自带基准：每小时还是每公里。两套基准在中文工程实务里都在流通，而写在纸上时表面读数一模一样。本课写死三条：
- 全课这两个量必须同基准，基准由本项目在论证开始时声明；⛔ 本课不给默认基准；
- 每小时与每公里之间的换算要乘平均车速，而平均车速本身是平台相关量，还随场景（行驶／驻车／充电）变化 ⇒ ⛔ 不许在两套基准之间随手换算；
- 驻车与充电场景下「每公里」这一基准根本不成立——车不动，分母是零。⇒ 一份混用两套基准的暴露量台账在驻车相关危害上必然算错，而驻车恰恰是热管理侧危害最集中的场景类之一（远程预约、到桩预热、驻车温控全在这里）。
⚠ 为什么禁止裸写「风险」：λ_target 是一个发生率，R_残余 是发生率与暴露量的乘积——两者量纲不同，⛔ 不可比大小、⛔ 不可互算。口语里它们都被叫作「风险」，于是一句「这个风险比那个大」写进评审记录，就成了一条无法复核的结论：读的人不知道被比较的是两个发生率、两个乘积，还是一个发生率与一个乘积。
易错点。两个。①丢下标：把 P_触发 与 P_措施失效 都写成 P，到第 6 讲那张账上立刻分不清是哪一项在变；⇒ 本课正文禁止裸写不带下标的 P，也禁止裸写不带下标的 R。②把可信域当成输入域的同义词用（见上）——这两个词只差一层，而差的那一层正是第 4、5 讲全部运行期措施的立足点。
本讲收口。本讲交出的是一张表、一组问、一条红线和一套名字：分流表（1.4）把「走哪条线」从口头判断变成可审的一行；三问（1.2）是它的判据；红线（1.3）是它的防滥用条款；术语与符号表（1.9）保证后面五讲说的是同一件事。⇒ 从这里开始，每当有人说「这个功能得做 SOTIF」，本课要求把它改写成一句完整的话：在某运行条件下、某能力不足、导致某危害行为，且规范不足三问全为是，故走本课这条线，该交的证据是这几件。说不出这句话，后面每一讲的方法都还不该开始。
后面还有 5 讲正文 · 关键公式 · 案例拆解 · 常见误区 · 动手做