模式表/场景表与仲裁规则的静态体检：可达性、死锁与切换质量

课程大纲

• 能把 K3-01/K3-08/K3-09/K3-16/K6-08/O3-07 交付的策略层表格翻译成「状态—事件—迁移」三元组，做出可达模式集与不可达/陷阱清单，并对每一项给出「删格／改门限／退回架构」三选一的处置与理由
• 能判别不可达模式的三类策略侧成因（进入门限严于退出门限、优先级恒被压过、工况谱里无对应 bin），并说明为什么可达模式集必须作为 K6-07 覆盖率与 K4-05 迁移覆盖率的分母
• 能按「节点＝请求源/资源持有者、边＝A 的推进条件里含 B 的释放动作」从需求合成表与权限矩阵建出请求-资源图，识别策略层死锁的四类成因，并在优先级表上落实单向全序（破除手段本体引 K4-05）
• 能填出一张场景层互斥/并存对偶表（三值填法 + 条件写全）与一张「场景→模式请求」映射表，并说清映射表为什么不许自带第二套仲裁
• 能写出场景标志位接口表的九个必填字段与命名/编号规则，并按「新增／拆分／语义变更」三种改动给出版本演进兼容的处置，说明为什么废弃号位不得复用
• 能定出切换质量四个验收量的取数窗口、分布算法与合格判据构造法，把单位时间与单位里程两个口径并给，并把动作次数配额分摊到执行器与请求源、填出一页可签署的验收页

1. 策略层规则表的迁移可达性核对：从表到可达集
   • 体检对象先点名，一共六张策略层交付表：K3-01 的模式表（含互斥/并存表与非法组合排除表）与迁移矩阵、K3-08 的需求合成表与执行器稳态出力优先级表、K3-09 的切换序列表、K3-16 的请求源权限矩阵、K6-08 的整车级门限表、O3-07 的状态—仲裁表。六张表的属主与内容一律引用不重讲，本课只做「体检」这一道工序。
   • 本课的入口是一道翻译而不是分析：K4-05 的输入已经是一台成型的 Stateflow 状态机，策略层的输入却是一叠二维表——必须先把「行＝模式、列＝请求/工况」的表逐格翻成「状态—事件—迁移」三元组，翻译规则与翻不出来的格（表里写了条件却没有对应状态）本身就是第一批缺陷。
   • 不可达模式的三类策略侧成因判别不同、处置也不同：① 进入门限严于退出门限（写反了 T_on/T_off）→ 改门限；② 优先级恒被压过，该模式的请求在任何工况组合下都拿不到执行器 → 要么改优先级、要么承认它是死格并从表里删掉；③ 工况谱里根本没有落进该模式的 bin → 退回需求与架构，不是继续加仲裁分支（O3-07 的工况谱点名法已写死这条：有解不上的 bin 是需求不合理或自由度不足）。
   • 陷阱（不可逃逸）态在策略层有两种典型形态，与软件层的成因不同：其一，进入条件写成「或」而退出条件写成「与」，进得去出不来；其二，退出条件依赖一个进入该模式后就不再更新或不再有效的量（例：进入除霜后蒸发器温度不再反映结霜程度，仍用它当退出判据）。判据是逐模式检查「退出条件所依赖的每个量，在该模式内是否仍然有效且会变化」。
   • 可达模式集是下游三处的分母，算错了三处一起虚高：K6-07 的标定覆盖率 η_cov 已写死「分母必须取静态体检后的可达模式集」；K4-05 的迁移覆盖率分母须先剔不可达迁移；K4-03 的场景覆盖率同理。本讲的交付物之一就是这份带版本号的可达模式集清单。
   • 方法本体一律引用不重讲：guard 可满足性的前向遍历、等待图查环算法、模型检验工具（Simulink Design Verifier 一类）能证什么/不能证什么、「未证明 ≠ 通过」这条工具边界，全部归 K4-05 第 3 讲与第 5 讲。本课只讲这套方法用到具体规则表上时，输入怎么准备、结论怎么判读、报告怎么签。
   • 出口有两处闸口，别拖到下游才发现：一份静态体检报告接进 K4-03 的出口判据（与需求覆盖率、结构覆盖率并列）；同一份报告是 K6-07 进环境舱前的拦截项——K6-07 已写死「不可达模式、死锁与无出口迁移应在这一层拦掉，别带进环境舱花舱时才发现」，一次花舱台时的代价远高于一次逐格核对。
2. 请求-资源图死锁的策略侧成因与破除
   • 策略层的建图规则与软件层不同，必须先说清节点取什么：节点＝请求源或资源持有者（座舱制冷、电池冷却、电驱散热、快充预约、系统自保护、外部不可支配热源…），而不是软件状态；边＝「A 的推进条件里含 B 先释放或先动作」。这些边不需要另外收集——K3-08 需求合成表每一行的「谁赢、要不要回执」和 K3-16 权限矩阵每一格的「压过之后怎么办」就是边的来源。
   • 策略层死锁的四类成因，逐类给识别特征：① 两个子系统互相等待对方先降级（K5-02 只给了病名）；② 共享资源环形持有——压缩机冷量、冷却液流量、12V 功率、电池可用功率这四类是热管理里最常成环的资源（预算与仲裁本体归 K3-07/K3-12）；③ 回执型握手互等（Q_avail 四段握手的上下行契约，本体归 K3-01）；④ 跨域授权互等，只在含不可支配热源（发动机/增程器）的架构里出现，模式表里那一格只能填「请求/不请求」并配授权判据与超时分支。
   • 破除手段的本体（单向全序／超时兜底／全局仲裁者，以及只有单向全序能在设计期证明无环）归 K4-05，本讲只讲它们在策略表上长什么样：单向全序的表面形式就是**优先级表必须是全序而不是偏序**——同优先级并列的两行是环的温床，因为此时结果依赖请求到达次序，而到达次序不受设计控制。
   • 超时兜底的时长在策略层有双侧边界，取错两边都出事：下界必须长于该模式的 t_dwell_min（否则超时先于驻留到期触发，等于把最小驻留架空），上界必须短于该通道的 FTTI 预算（否则等到超时已经来不及）。t_dwell_min 的取法归 K3-01、FTTI 拆分归 K5-02，本讲只立这条「夹在两者之间」的约束。
   • 死锁体检的输入必须包含降级路径，只体检正常路径会系统性漏检：K5-02 的降级等级体系与 I7-02 的 fail-safe 去激励默认位都会新增迁移边，而互相等待对方先降级这类环恰恰只在降级路径上闭合。判据是「把降级迁移画进同一张图再查一次环」。
   • 饥饿与死锁不是一回事，用同一套药会误诊（K4-05 已把两者划开）：饥饿在图上表现为**无环**而某节点长期拿不到资源，超时兜底对它无效。老化、保底配额与优先级倒置三件套归 K3-01，长时序定向用例归 K4-03；本讲只在体检表上留一列「连续未满足时长」的饥饿观察位，不重推机制。
3. 场景层互斥/并存对偶表与「场景→模式请求」映射（承 K3-15 并课）
   • 对偶表的形状先定死：行、列都是场景全集，只填上三角，每格取「互斥／可并存／条件并存」三值之一，「条件并存」必须把条件表达式写全——只写三个字不算填。空格在实车上就是一处未定义行为，与 K3-01 那条易错点（把没写进表的组合默认当禁止态）是同一个病。
   • 表头不由本课定义：场景全集与两栏责任线（订阅类＝行驶/充电/驻车/上下电/驾驶模式/服务态/运输态/刷写态/下线检测态，由 VCU、BMS、诊断仪、产线设备、OTA 主控产生；自合成类＝快充预约、暴晒、露营、拖挂爬坡、长下坡回收、热浸 after-run）已由 K3-01 §5.2 交付，本讲直接接过来做表头，不重新划责任线。
   • 逐场景的判定判据一概不在本课，五处前指必须原样保留：暴晒→C6-05，拖挂爬坡与长下坡回收→K7-01 §2，快充预约→D4-03 与 D3-04，露营→C6-04，热浸 after-run→K3-11 §3 与 K3-08 §4。本讲只回答「这两个场景能不能同时成立」，不回答「这个场景现在成不成立」。
   • 「场景→模式请求」映射表的字段：场景编号、映出的模式请求（可多条）、每条的 urgency 档、是否需要回执、以及**退出后回到哪个值**——最后一项最常漏，漏掉的表现是场景退出了而设定点留在场景值上（例：暴晒退出后 pull-down 目标不回落）。
   • 映射冲突的三类典型，逐类给处置：① 两个判为「可并存」的场景映到互斥的模式请求（露营 × 快充预约）；② 场景有进入映射而无退出映射；③ 同一模式被两个场景以不同 urgency 请求。三类都不在本表里自行裁决——**映射表不许自带第二套仲裁**，冲突一律交回 K3-01 的优先级/按权分摊与 K3-16 的人机权限，本表只负责把冲突暴露出来。
   • 只做场景层，两侧都不越界：模式层的互斥/并存表归 K3-01，执行器层的阀位组合穷举归 B3-04（§1.3/§4.2/§5.1）与 G8-06（真值表与 N_states ≤ N_valve_positions 上限）——这是 K3-13 登记时就写死要删去的两项，并课后仍然守住。
   • 这张表连同映射表是 K4-03 场景层注入的直接输入（K4-03 现文已写死「场景定义表与场景→模式请求映射表见本课」）：验收要求是对偶表里每一格「可并存/条件并存」至少派生一条注入用例，映射表每一行至少一条正向 + 一条退出用例。
4. 场景标志位的接口约定：命名/编号规则与版本演进兼容（承 K3-15 并课）
   • 场景定义表是唯一事实来源，一处定义、多处引用——C6-04 已就露营前置条件立过同一条规矩（「与 D3-04 是同一张表」）。它的消费方要在表里列名：K5-02 取回退方向、K4-03 取注入用例、K6-07 取可达模式集、C6-05/K7-01 取判定判据的落点、G8-05 取服务态/检测态的接口位。同一场景在两处各定义一次，必然在某个边界时刻打架且两边都「自洽」。
   • 每个场景条目的必填字段共九项，缺一项即打回：编号、名称、产生方（订阅／自合成）、判定判据的属主课、进入条件、退出条件、更新周期、上电默认值、失效回退方向与理由。最后一项是 K5-02 承接本课并课后的修正结论——**回退方向必须逐场景声明、不用全局默认**，因为不同场景的安全方向不同向（暴晒判错向「不制冷」回退会烧内饰与电子件；快充判错向「不冷却」回退直接撞电池热失控边界；长下坡回收判错向「不散热」回退会顶到制动/电机温限）。
   • 命名与编号规则三条，都是为了跨版本可比：① 编号与名字分离，编号稳定、不随排序变；② 编号一经发布只增不改；③ **废弃场景的号位作废、不得复用**——复用号位在新旧软件混装时不会报任何错，接收方按老语义解释一个新场景，是最典型的静默错配。
   • 版本演进的三种改动各有处置，不能混：新增场景＝追加号位、老号一律不动；拆分场景＝老号保留为粗粒度兼容位并标注废弃版本，新号并行一段；**语义变更＝必须换新号，禁止原号改义**。跨版本混装的准入（哪一版热管理软件配哪一版场景表可以放行）属 OTA 刷写的热侧准入，归 K7-02；刷写态本身属订阅类、由 OTA 主控产生，责任线在 K3-01 §5.2。
   • 订阅类使用态同样占接口位，但字段的填法不同：服务态、运输态、刷写态、下线检测态的产生方是诊断仪/产线设备/OTA 主控，域控**只订阅、不推断**，故「判定判据属主课」一栏填「订阅，无本域判据」。G8-05 消费的正是这一条（它要的是接口约定，不是判定法）；它进入后禁止风扇/水泵/压缩机自主启动的那套互锁需求由 G8-05 自己持有。
   • 信号层的取值一律不重讲，本讲只要求字段有值、有属主：新鲜度 age 的定义与阈值、SNA/无效值编码、逐信号 timeout 取值归 K2-02；替代值三选一与信号级故障标志分级归 K1-01；上电默认值的产生次序与初始化编排归 K3-11。凡这些格里填「待定」的，就是一处没有属主的接口。
   • 这张表的机检项是本讲可自动化的部分：编号唯一且连续无复用、九个字段无空、消费方清单里点名的每门课都能反查到对应引用、回退方向非空、条件表达式可解析。这五条做成脚本挂进提交门禁，比评审会逐行念表可靠得多（K3-01 已就三表核对立过同一条：人眼逐格看必漏，且两次走查漏的格子还不一样）。
5. 切换质量 KPI 的取数、分布判读与验收口径
   • 验收量一共四个，前三个由 K3-01 点名（切换频次、执行器动作次数、驻留时长分布），第四个由 K3-05 点名（切换瞬间输出跳变幅度，且必须与随后的回稳过程成对看）。K3-01 现文已明写「本课不定义 KPI 的判读口径——怎么采、采多久、怎么算分布、怎么判合格」，这四问正是本讲的交付；f_chatter 的定义式、两口径并给的要求与五条有效性条件归 K4-05 第 5 讲，本讲不重列。
   • 「采多久」＝观测窗的选取规则，这是 K6-02、K6-07、I6-01、I6-05 四门课都在等的那条口径：窗必须覆盖该模式门限的穿越工况，否则窗内切换次数恒为 0，是假合格；窗长下界取「最长的 t_dwell_min × 一个可统计的段数」与「该回路最慢热时间常数」二者之大；驻车、充电、休眠与下电 run-on 期间的动作不产生里程却实打实消耗寿命配额，不得从窗里剔除（K3-01 的 n_budget 条已写死这条漏计）。
   • 「怎么算分布」＝驻留时长直方图对 t_dwell_min 下限取占比，贴下限的短驻留占比是抖动的**前兆量**：它超限而切换频次尚未超限时，结论是「再加一点扰动就会超」，不是「已经不合格」；反过来频次已超而短驻留占比不高，说明病根不在驻留边界而在迟滞带宽，须回 K3-01 的 ΔT_hys 三项下界重算。被 t_dwell_min 强制压住的「想切没切成」那些驻留必须单列，混进来会把占比顶高、误报前兆。
   • 两个口径必须并给，且要说清为什么：单位时间口径（次/h）在城市与高速工况下不可比，单位里程口径（次/百公里）在驻车与充电段无意义——所以是并列两栏而不是二选一。这条要求由 K3-01 持有，本讲把它落成验收页上固定的两栏。
   • 配额分摊是本讲对 K3-08 那条前指的兑付：把整车级动作次数配额按模式、按执行器、再按请求源三级分摊到每一条迁移，超配额只有两条显式回退分支——放宽迟滞带或延长最小驻留（代价＝控制精度与舒适性），或回改硬件规格（代价＝成本与周期，回到 B1-02 的 CTS）。N_life 本体与 n_budget 反推归 K3-01，耐久侧的循环次数目标归 B1-02/G7-06/L1-04，磨损定寿与动作耐久台架归 I6-05，本讲只做分摊规则。
   • 验收页的形状固定七列：验收量、口径（时间/里程两行）、观测窗定义、实测值、目标值、目标值来源（课号 + 条目号）、标定版本号。**标定改版即触发复评**——L1-04 已写死这条反向约束、I6-05 已承接：实车动作次数超过已验证当量时，该项耐久结论对新版即失效。
   • 各门课的量按同一张验收页取数，不许各写一套：AGS 开合次数（G7-04，与 G7-06 的耐久循环次数对齐）、内外循环切换次数与压缩机启停次数（K6-02、K6-07）、多通阀阀芯往复与执行器减速机构动作（I6-01 第四类交变载荷、I6-05）、切换瞬间输出跳变幅度与回稳（K3-05，其「随后 5~10 个采样周期内的超调」这一具体窗口由 K3-05 持有）。口径不统一的后果是同一台车三份报告三个数，谁也不敢签。

• 以为「静态体检」和「完备性核对」是两件事、要分给两门课各写一遍，其实是同一套方法的两个作用面：方法本体（可达性遍历、等待图查环、工具边界）归 K4-05，作用到具体规则表上的应用归本课——两门互链、各写一半，不是各写一遍。
• 以为可达性分析要等状态机建好才能做，其实策略层在表阶段就该做一遍：表里已经有「行＝模式、列＝请求/工况」的全部信息，等进了 Stateflow 再查，改一次表要连带改模型、用例与标定三处。
• 以为不可达模式就是删掉，其实三类成因处置完全不同——门限写反了要改门限、优先级恒被压过要改优先级或承认死格、工况谱里没有对应 bin 的要退回需求与架构（O3-07 已写死：有解不上的 bin 是需求不合理，不是继续加仲裁分支）。
• 以为标定覆盖率的分母就是模式表的行数，其实必须取静态体检后的**可达**模式集——把不可达模式算进分母会让覆盖率虚高，K6-07 已就此写死一条硬约束。
• 以为死锁是「逻辑写复杂了」的偶发问题，其实策略层有四类可静态查出的成因（互相等待降级、共享资源环形持有、回执握手互等、跨域授权互等），而且只体检正常路径必漏——互相等待对方先降级这类环恰恰只在降级迁移上闭合。
• 以为优先级表写好了就不会有环，其实同优先级并列就是环的温床：并列意味着结果取决于请求到达次序，而到达次序不受设计控制；单向全序在策略表上的表面形式就是「优先级必须是全序而不是偏序」。
• 以为超时兜底越短越安全，其实它有双侧边界——短于最小驻留就把 t_dwell_min 架空，长于该通道的 FTTI 就来不及；两侧的量值分别归 K3-01 与 K5-02。
• 以为把饥饿和死锁一起用超时兜底就都解决了，其实饥饿在等待图上**无环**、超时对它无效，治法是老化与保底配额（归 K3-01）；本课只在体检表上留一列观察位。
• 以为场景没写进对偶表就默认互斥、所以不必逐格填，其实默认值不会被测试覆盖（用例从表里派生，表里没有的组合派生不出用例），实车上一旦被触发就是未定义行为——与 K3-01 那条「把没写进表的组合默认当禁止态」是同一个病。
• 以为「场景→模式请求」映射表可以顺手把冲突裁决了，其实映射表自带第二套仲裁就等于全车有两套优先级，两套一旦不一致没有任何一方会报错；冲突必须交回 K3-01 的优先级与 K3-16 的人机权限。
• 以为场景标志位的失效回退可以用一条全局默认（「回退到能耗最低且不伤安全的那一档」），其实不同场景的安全方向不同向——暴晒判错向「不制冷」回退会烧内饰与电子件、快充判错向「不冷却」回退直接撞热失控边界、长下坡回收判错向「不散热」回退会顶到制动/电机温限；必须逐场景声明（K5-02 已按此修正第十一类）。
• 以为场景语义改了保留原编号更省事，其实原号改义在新旧软件混装时不会报任何错——接收方按老语义解释一个新场景，是最典型的静默错配；语义变更必须换新号，废弃号位作废不得复用。
• 以为服务态、下线检测态这类使用态该由热管理域控自己判定，其实它们属**订阅类**（产生方＝诊断仪/产线设备/OTA 主控），域控只订阅不推断（K3-01 §5.2 责任线）；本课给的是它们的接口位与互斥声明，不是判定法。
• 以为切换质量只看温度达标，其实抖动次数、执行器动作次数、驻留时长分布、切换扰动幅度是四个独立验收量；温度全合格而寿命配额被吃光是本领域最常见的假通过。
• 以为切换次数统计随便取一段日志就行，其实观测窗没覆盖门限穿越工况时次数恒为 0，那是假合格；而只按单位里程统计会漏掉驻车、充电、休眠 run-on 期间那些不产生里程却实打实消耗配额的动作。
• 以为驻留时长分布超标就等于抖动不合格，其实它是**前兆量**：贴下限短驻留占比高而频次未超，说明「再加一点扰动就会超」；反过来频次已超而占比不高，病根在迟滞带宽而不在驻留边界，改错地方越改越差。
• 以为体检报告是评审用的文档，其实它是两道闸的输入：接进 K4-03 的出口判据（与需求覆盖率、结构覆盖率并列），以及 K6-07 进环境舱前的拦截项——不可达模式带进花舱才发现，代价是台时。

需求区 · 想听众筹

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