预期功能安全（SOTIF/ISO 21448）与 AI 件安全论证在热管理的落法

课程大纲

• 能对一个热管理功能逐条判定其危害走 ISO 26262 还是 ISO 21448，说出「规范不足」的判据句，并识别把换热裕量/选型/标定问题误送进 SOTIF 的滥用
• 能用已知/未知 × 安全/不安全四象限组织一次危害推进，说清每一步把哪一块面积迁到了哪里、活动该拿什么当收敛度量
• 能系统性识别热管理侧的 SOTIF 触发条件与可预见误用，并把每一条写成带可观测判据的四元组，写不出判据的条目留在待办清单而不计作已识别
• 能写出一个数据驱动件的 ODD/输入域与可信域声明表，并给出「场景覆盖到什么程度算够」的三条同时成立的收敛判据
• 能把一个运行期监控器规格化，并用检出延迟与危害发生时间预算的对照论证它为什么算安全措施而不是看板
• 能按 ISO/PAS 8800 的 AI 生命周期把数据集充分性与覆盖论证、性能指标验收准则、运行期措施组织成一条 AI safety case 论证链，并与 26262 侧追溯链互链
• 能定出残余风险接受准则、填出放行签署表（谁提、谁独立复核、谁批、有效期与失效条件），并说清它与共因失效残余风险的语义差别

1. 问题域切分：ISO 26262 收不住什么，SOTIF 什么时候该启动
   • 开篇先把射程说清：ISO 21448:2022 的名义范围以「安全高度依赖情境感知、而感知又来自复杂传感与算法」的功能为中心（典型是 ADAS 与紧急干预类），把它用在热管理的数据驱动件上属方法论迁移而不是天然适用；对 AI 件更对口的是 ISO/PAS 8800，故本课主轴以 8800 为纲，21448 只提供触发条件识别与场景/充分性方法这两件工具
   • 入口判据看「件坏没坏」而不是「后果重不重」：ISO 26262 管安全相关 E/E 系统的失效行为（随机硬件失效与系统性错误），件没坏、规格也按当时能力正确实现，输出却仍不合理导致危害的，26262 的 HARA→TSR→FMEDA 这条链接不住它，归 ISO 21448；两侧的定级方法与量化度量不在本课重讲（K2-03、I7-03 已整节）
   • 「规范不足（specification insufficiency）」的判定三问，三问全为「是」才启动 SOTIF 流程：①需求写的是不是当时认知与能力所及的最好描述；②危害是否在需求被正确实现的前提下发生；③危害是否来自感知、判断或决策的能力边界而非某个件的失效
   • 防滥用的反向红线（本条不讲学员会拿 SOTIF 当万能筐）：换热能力裕量不足、泵扬程选小、传感器精度不够、标定表工况覆盖不到位——这些是选型、验证与标定不到位，走对应设计课与阈值整定复验，不走 SOTIF；把裕量问题包装成「功能不足」的后果是评审第一轮退回，且真正的能力不足被淹没在里面
   • 已知/未知 × 安全/不安全四象限的用法是推进而非分类：已知不安全必须靠措施迁到已知安全；未知不安全是 SOTIF 主战场，只能先靠场景挖掘把它变成已知不安全、再治；未知安全不必治但决定验证成本。活动的度量是「未知不安全这块面积的收敛趋势」，不是「已知不安全清零」
   • 与 HARA 的接口是继承而非重做：危害事件清单与严重度沿用 26262 侧 HARA 结果，SOTIF 增加的是「触发条件—功能不足—危害行为」这一层因果链；同一危害只能有一套安全目标，两侧各定一次会出现两个互相矛盾的验收口径
2. 触发条件与可预见误用：热管理侧的系统性识别
   • 命名先分家再讲方法：SOTIF 的 triggering condition 指使功能不足显现为危害行为的运行条件，与控制策略里的启动/切换条件是两回事——体系内「触发条件」17 处命中全是控制语义（K3-01 模式切换、D3-04 预约与远程唤醒、C2-12 蒸发器自清洁启动），混用会让安全评审与控制需求评审各自认下不同的东西
   • 识别四路并行，缺一路就有系统性盲区：①沿功能链逐环反问「什么运行条件下这一环的能力会不够」；②从本体系自有失效画像反查（导航中途改路线致白预热、驾驶意图误判、学习策略在训练分布外给出不合理动作、代理模型错得自信的失效沉默、远程预约在用户并不出行时启动）；③按场景要素维度组合（环境、停放/行驶/充电状态、用户行为、连接性与数据时延、车辆状态）；④从现场「无 DTC 抱怨」里反挖——这一路命中率最高，正因为功能不足恰好不置故障码
   • 每条触发条件写成可判定四元组｛条件描述、可观测判据（信号与阈值）、导致的功能不足、危害行为｝；写不出可观测判据的条目只能留在待办清单，不计作已识别——它既进不了场景库，也做不出运行期监控器
   • 可预见误用是独立分析步骤，不是「用户操作错了」的免责条款：热管理侧典型清单＝把露营/驻车空调当整夜可靠制冷用、用远程预约代替车库通风、拖挂与赛道等超出声明使用条件的连续大负荷、封堵格栅或加装座椅套改变风路、低 SOC 下反复远程唤醒；判据是「可合理预见」而不是「合规使用」，处置分三档——设计消除、约束声明加界面告知、运行期监控加降级
   • 同一个现象也要能按性质切开：报文超时、传感器失效、通信中断属 E/E 失效，走 26262 与 K5-02 的降级实现；信号数值电气有效但语义判错（场景标志位判错、驾驶意图误判）走本课。K5-02 已整节讲降级怎么做，本课只负责论证「这条触发条件必须配一条降级」以及降级判据从哪来
   • 登记表要与后两讲联立：每条触发条件必须能被指派到至少一项处置（设计消除／场景库验证／运行期监控＋降级／约束声明），无处置的条目直接进第 5 讲的残余风险账，不允许悬空
3. ODD/输入域声明与场景库：覆盖到什么程度算够
   • 运行设计域（ODD）与输入域必须先声明后验证，且热管理侧的 ODD 不是道路场景清单，而是｛环境温湿度与海拔区间、SOC 与电池温度区间、驻车/行驶/充电状态、可用外部数据源及其时延与缺失容忍、乘员与载荷条件、允许的驾驶模式｝；声明要落成可机检的边界，运行期才判得出「现在是否在域内」
   • 可信域声明是跨课统一交付物，本课给格式、各课给取值：J7-05 的代理模型可信域（输入范围、样本密度/最近邻距离与预测方差阈值、失效沉默的运行期监控方案）、K7-01 的预测输入可信域与置信度失效判据、K7-03 学习件的训练分布，三处都指向同一张表；格式不统一，模型卡、验收报告与 OTA 包声明就对不上
   • 场景库分两层组织：要素层（每一维的取值与分布，含 ODD 边界与边界外一档）× 组合层（要素叉乘后按危害相关性剪枝）。体系内既有素材只有 C6-04 的感知误判清单一条要点、且没给收敛判据，本课补的正是判据这一块
   • 「够」不是场景条数，而是三条同时成立：①要素维度已穷举、每维取值覆盖到 ODD 边界与边界外一档；②新一轮场景挖掘的新危害发现率已落到事先声明的门限以下（发现率曲线走平，门限必须事前定，事后调门限即论证作废）；③剩余未覆盖部分有归属论证——或属未知安全区，或已由运行期措施兜住
   • 验证目标量化要先算清纯暴露路走不通：按零失效观测反推所需暴露量（式见 formulas）通常给出不可实施的量级，所以充分性只能靠「场景加速 ＋ 仿真/台架/整车分层证据 ＋ 运行期监控」的组合论证；虚实差距核验与上车台阶不在本课重讲（N6-02 已整节）
   • 分层证据的接口写死，本课只做证据到主张的映射与缺口清单：仿真类证据须带模型可信度与可信域声明（见 J7-05）、台架与环境舱证据的放行口径见 K6-04、灰度车队证据的统计显著性与样本量见 K7-02；一条主张只挂得住与其精度等级相称的证据，越级挂靠是评审退回的常见形态
4. 以 ISO/PAS 8800 为纲的 AI 件论证链：数据集、性能验收、运行期措施
   • 数据集充分性与覆盖论证要交四件，缺一件不成论证：数据来源与采集口径的版本标识（信号语义改版会造成历史数据口径断层，把口径变化误读成分布漂移）、相对 ODD 各维的覆盖矩阵与空洞清单、稀有但高严重度类别的最低样本量与获取手段（含合成与增强的可信性说明）、训练/验证/测试划分的独立性证明——同一工况的不同参数化点混入两侧即论证作废
   • 性能指标验收准则不能只写「精度够高」：按危害方向分列（漏检与误检代价不对称时门限就不该同值）、每个门限给出来源（由危害率分配倒推，不是抄行业惯例）、并声明指标在 ODD 分层子集上的最差值而不只是总体均值——总体达标、某个子域塌陷是最常见的过不了评审的形态
   • 运行期措施要论证成安全措施而不是监控看板：一个监控器要规格化到｛被监视量、判据形式（分布外/置信度/残差/自适应补偿量趋势）、判定时窗与迟滞、检出后把权限交给谁、检出延迟与危害发生时间预算的对照｝；检出延迟顶不住时间预算的监控器不算措施。护栏与限幅实现见 K7-03、监控器-执行器架构与降级等级见 K5-02、置信度加权与降级回退见 K7-01，本课不重讲
   • 判据量的选取要把取舍摆出来：高维输入下几乎所有新点都落在训练集凸包之外，凸包类判据既算不动也判不出，实务上取「逐维范围 ＋ 局部密度/最近邻距离 ＋ 模型自身预测方差」的组合，阈值按误报率预算定；三件套本身的算法见 J7-05，本课只讲选哪几个量、阈值与误报率预算怎么挂
   • 误报率必须与降级代价一起算，否则措施会被现场关掉——这是安全措施在量产中失效的最常见现实路径，也是论证里必须写进假设的一条：措施有效性的前提是它在整个生命周期内保持使能，凡有「可被标定关闭」的措施，都要把该开关列入参数锁定分级（分级清单归 K7-02）
   • 把四样证据组织成 8800 的生命周期视图：ODD 界定 → 数据集充分性 → 性能验收准则 → 运行期监控与降级作为安全措施；这正是 K7-03 学习件变更评审要交的四样件，本课负责给出它们的论证方法与相互接口，各应用课负责按自己的功能填值
5. 残余风险接受准则、放行签署与 AI safety case 的组织
   • 残余风险接受准则必须事先定、逐危害定：口径＝该危害行为的可接受发生率与其暴露量之积（分解式见 formulas），并声明「谁的可接受」——法规/评级门槛、企业内部准则、同类既有功能的现状水平（as-good-as-current 论证）三种来源不可混用，混用会出现一个谁都不认的数
   • 与体系内另一处「残余风险」严格分家：I7-02/I7-03 的残余风险是冗余到位后由共因失效主导的硬件失效残余量（β 因子量化），本课的是措施用尽后仍留在未知不安全区的能力不足残余量；两者不可互相援引、不可相加成一个总数
   • 放行签署落成一张可执行的签署表：谁提出（功能负责人）、谁独立复核（安全/验证侧，独立性等级随危害严重度提高）、谁最终批准（安全经理或指定角色）、批准所依据的证据包清单、以及批准的有效期与失效条件——ODD 变了、数据分布变了、模型结构或特征定义变了，批准即失效，必须重签。标定口径的整车级验收清单与放行签署已由 K6-04 承担，本课只补 SOTIF/AI 侧要额外加签的那几行
   • AI safety case 按主张—论据—证据三层组织，顶层主张拆成三支：已知不安全已被措施迁移、未知不安全已收敛到接受准则以内、运行期措施在生命周期内有效；与 26262 侧的 safety case 必须互链而不是各写一套（追溯接口见 K2-03、I7-03），跨企业开发时证据分散两侧的拼装规则见 K4-09
   • 学到的模型经 OTA 下发要多交三项验收证据：①随包声明训练分布与可信域（可信域变了属接口变更，不是参数微调）；②回滚必须把模型与其可信域声明一起回滚，只回代码会留下「新可信域配旧模型」的悬空态；③安全相关变更补交触发条件覆盖与失效降级路径证据。灰度节奏、回滚门限、参数锁定分级与合规留痕不在本课重讲（K7-02 已整节，准入备案与召回口径见 M4-08）
   • 本课收口交付物是一份「主张—证据—缺口」对照表：每条证据必须写清它支持哪条主张，缺口项要么排期补证、要么转成运行期措施加约束声明，不允许留空白格——评审最常见的失败形态不是证据不够，而是证据齐全但没人写映射

• 以为后果越严重就越该走 SOTIF，其实入口判据是「件坏没坏、规格是否已尽当时之能」——热失控这类后果最重的危害，只要由 E/E 失效引起就仍走 ISO 26262（K2-03），走错入口会做出一整套没人认的证据
• 以为把换热裕量不足、泵扬程选小、传感器精度不够包装成「功能不足」就能进 SOTIF 流程，其实那是选型与标定问题，评审第一轮就退回，且真正的能力不足被淹没在这些条目里
• 以为「触发条件」就是控制策略里的启动条件，其实两者语义不同（K3-01/D3-04/C2-12 是控制语义），混用会让安全评审与控制需求评审各自认下不同的东西，最后两边的验收对不上
• 以为已知不安全清零就算 SOTIF 做完了，其实度量在未知不安全那一块面积的收敛趋势——已知不安全清零只说明手上这批场景治完了
• 以为场景库越大越安全，其实没有收敛判据的场景库只是成本；判「够」看新危害发现率是否落到事先声明的门限以下，事后调门限即论证作废
• 以为堆里程就能证明安全，其实按零失效观测反推的暴露量量级通常不可实施（见 formulas 第 1 条），充分性只能靠场景加速＋分层证据＋运行期监控的组合论证
• 以为上了护栏、限幅和漂移监控就等于安全措施到位，其实措施要有规格与检出延迟论证——检出延迟顶不住危害发生的时间预算，那就只是个看板
• 以为总体精度达标就能过性能验收，其实要看 ODD 分层子集上的最差值；总体均值达标、某个子域塌陷是最常见的过不了评审的形态
• 以为残余风险就是「剩下没做的事」，其实它是要事先定准则、逐条签署接受的量；且与 I7-02/I7-03 的共因失效残余量语义不同，不能混算或相加
• 以为 AI 件挂上 ISO 26262 就有了验收依据，其实 26262:2018 正文不含机器学习的专门要求，AI 件要靠 ISO/PAS 8800 与 ISO 21448 的组合论证
• 以为 safety case 是文档汇编，其实过不了评审的主因通常不是证据不够，而是没人写「哪条证据支持哪条主张」这层映射
• 以为模型 OTA 回滚就是把代码回退回去，其实可信域声明必须与模型一起回滚，否则会留下「新可信域配旧模型」的悬空态（下发工程本身见 K7-02）

需求区 · 想听众筹

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