热管理控制功能规格（软件需求）的编写、评审与向 Tier1 交接

课程大纲

• 能说清控制功能规格在 V 模型左支中的位置、它与功能需求链（VTS→SSTS→零部件规范）和安全需求链（安全目标→FSR→TSR）的并轨方式，并按两条交付路线（OEM 写黑盒功能规格由 Tier1 展开 vs OEM 自研直接写软件需求）判定本项目该写到哪个颗粒度、每类字段由谁写谁签
• 能用五条控制专属判据（判据只引可观测量、响应时间不超执行器动作能力与任务周期上限、阈值必须留标定接口、模式行为必须用迁移表、每条必须指定验证方法与验证层）逐条判定一份现有规格里哪些条款不可实现或不可测试，并给出改写版本
• 能核算一条响应时间条款的可实现下界，判断它是否超出执行器动作能力与任务周期上限，从而在评审现场判定该条款可否兑现
• 能组织一次功能规格评审：定评审六方组成、按逐条三问（谁实现／谁验证／在哪一层验证）走查、做条款↔用例矩阵与条款↔模型架构清单两道对账并处置无源功能与空头条款，最后按六项出口判据判定可否冻结
• 能按八字段模板写出条目化条款，把请求/回执类内容与职责归属（如重试由谁发起、退避由哪一层执行）落到正确字段，并填出跨域功能分配矩阵的 owner／输入信号权威源／失效默认值／验证层四列
• 能定出本项目控制功能规格的基线冻结时点，并按三档粒度判定一次改动是落标定、走常规 CR、还是走需双方会签的重大 CR
• 能拟出向 Tier1 交接的条款：作为技术协议/SOW 技术附件的挂接方式、接口冻结范围、回交证据包三件的验收判据，以及按四级可标性（只读／可标／需授权可标／不可标写保护）开放的标定量清单

1. 这份文档是什么、谁写谁签——SYS.2/SWE.1 与 ISO 26262-6 在热管理域的落点
   • 定位先钉死：控制功能规格是 V 模型左支在系统架构层之后多出来的一层产出物。B1-05 的四层（整车热需求→系统架构→子系统设计→零部件设计）全在硬件/系统侧，这一层才是 K4-03 的 MIL/SIL/HIL 拿来对照的那份「写下来的需求」；不承认它是独立产出物，验证阶段就没有可对照的分母，覆盖率无从谈起
   • 与上游两条链的并轨：功能需求线走 B1-02 的 VTS→SSTS→零部件规范，到零部件规范为止（M1-04 已明写它只讲通用分解与追溯机制、把控制条款让给本课）；安全需求线走 K2-03/I7-03 的安全目标→FSR→TSR，其中落到软件的那部分必须以条款形式并进本文档同一张清单并标来源。判据是「两条链的条款是否在同一张清单里、有没有统一 ID 规则」——不并轨就会出现安全需求单独躺在另一份文档里、验证时对不上号
   • 过程域落点：系统需求分析（SYS.2）与软件需求分析（SWE.1）是本文档在过程参考模型里的位置，其工作产物的双向追溯要求与 K4-03 的软件测试过程域、K4-04 的配置管理过程域构成同一条证据链。⚠ 3.1 与 4.0 两版并行流通、过程域名称与工作产物编号有差异，引用必须显式声明所依版本、不得混引（口径沿用 K4-04/M1-04）；BP 条目的逐条原文本课未采购，讲义写作前须按现行版本原文确认，大纲阶段不复述条目内容
   • 安全相关条款的额外字段：ISO 26262-6 对软件安全需求规范另有要求，落到本文档就是三个附加字段——该条的 ASIL 等级、对应的 TSR 条款号、以及该条涉及的参数是否允许在线标定。条款号与版本按现行版本确认，本课不自造编号；安全需求推导本体见 K2-03/I7-03，安全相关量的写保护属性见 K6-10，变更评审归 K6-05
   • 两条交付路线决定颗粒度，不能混着走：路线 A＝OEM 只写黑盒功能规格（做什么、什么条件下做、做到什么程度、怎么验），由 Tier1 展开成软件需求并自行架构；路线 B＝OEM 自研上层策略，直接写到软件需求粒度（含信号名、任务周期、状态机迁移表附表）。选路线的判据是架构定义权与二供导入意愿，战略判据见 A5-03、产业与议价视角见 N5-02，本课不重讲；本课只管选定路线后文档写到哪一档、字段减哪几栏
   • 谁写谁签逐条落表，不落到人就等于没签：功能条款 owner＝控制工程师，信号与通信字段＝EE/网络工程师，标定量字段＝标定工程师，安全条款＝功能安全工程师，验证方法与验证层＝试验/验证工程师，Tier1 侧另设一名对口签署人。评审签署≠责任转移——路线 A 下 Tier1 展开出的软件需求由 Tier1 签，但 OEM 仍须校验其对黑盒条款的符合性；跨企业的责任划分本体（DIA/SEooC、缺陷责任与保修归属）归 K4-09
   • 本文档在配置管理里的身份：它就是 K4-04 所说的「需求」这一配置对象的物理载体，含三样成分——条款正文、九类附表、追溯链导出件。三样必须同批次、同版本号发布；只冻条款正文而附表另行漂移，是本领域最常见的一类失配（现场表现＝条款里引的附表号在交付件里查不到或版本对不上）
2. 控制条款特有的五条不可实现/不可测试判据（本课承重讲）
   • 判据只能引用车上真实存在或可估计的观测量：写「电芯最热点温度不超过限值」而车上只有模组测点与估计值，这条永远无法判定通过与否，两侧各选一个量就会各自「通过」。改写办法两条——把判据换成可观测量并显式声明其来源与不确定度（传感器有效性、替代值与故障标志见 K1-01），或先挂一条前置条款要求「须提供该估计量及其误差带」再谈限值
   • 响应时间条款不得超过执行器物理动作能力与任务周期上限：条款给的响应时间必须 ≥ 检测延迟（滤波＋去抖）＋通信传输时延＋任务周期整数倍＋执行器机械动作时间，四项缺一核算就偏乐观。执行器动作能力与到位/堵转判定归 K1-02，任务周期与可调度性归 K4-01，通信时延与总线负载归 K2-02；本课只做条款侧的下界核算与「这条能不能兑现」的当场判定（见公式）
   • 阈值必须留标定接口而不是写成硬编码常数：判据是「该值在整车标定期是否可能被改」——凡与环境、电池型号、车型配置相关的一律做成标定量。硬编码的代价是标定期发现要改就得走软件 CR 重出版本并跑一轮回归（第 4 讲的 CR 粒度三档正为此设）；标定量的类型、轴点、插值/外插保护、min/max/default 与可标性等级归 K6-10，条款里只写「该阈值为标定量、见附表第 X 号第 Y 行」
   • 模式行为必须以迁移表表达而非自然语言散文：条款里凡出现「在某模式下如果……则切换到……」的散文，一律要求转写成状态×事件迁移表并作为附表挂进来。评审判据是能否指到表里的具体一格；这张表本身完不完备、有没有不可达/陷阱状态、可不可验证归 K4-05，本课只查「有没有这张表、字段口径全不全、与条款正文版本对不对齐」
   • 每条条款必须同时指定验证方法与验证层：验证层在 MIL/SIL/PIL/HIL/台架/整车里选，验证方法写到「用什么激励、看什么量、判据是什么」三要素。缺这一栏，K4-03 的需求覆盖率分母就不成立（该课已把上游修法明确指回本课）。判据一条——条款若在任何一层都写不出可执行的验证方法，它就是不可测试条款，评审当场打回或降级为设计说明而不是需求
   • 一条只说一件事，是最常被漏掉的隐性判据：句子里出现「并且/同时/以及」往往是两条条款挤在一起，拆开后两条的验证层常常不同（一条 HIL、一条整车），不拆就给不出单一验证方法。通用良构要素（主体/条件/判据/可验证/必要性/单一性/可追溯/不含实现方案）与「应尽量满足」这类不可判定写法归 M1-04，四要素/五要素口径归 B1-02/B1-04，本课只讲它们在控制条款上的具体形态
   • 不可实现条款的三类典型来源要会认，认出来才好改：一是把整车目标值（降温速率、快充温升一类，口径见 B1-04）直接抄成软件条款而没折算到控制回路可控的量；二是把硬件能力上限当成软件承诺（压缩机排量、加热器功率决定的上限，软件再怎么写也超不过去）；三是把仲裁结果写死成固定动作而忽略资源不足时的可让度（请求四元组与上下行双向契约见 K3-01，本课只管它进条款时摆哪个字段）
3. 评审的组织、逐条三问与两道对账
   • 评审六方缺一不可：控制（条款作者）、软件（可实现性与架构落点）、标定（阈值是否留了接口、可标性等级是否合理）、试验/验证（验证方法与验证层能不能执行）、安全（ASIL 条款与 TSR 的对应）、Tier1（路线 A 下必须到场，否则展开阶段才提异议已经晚了一个门）。缺席方名下的条款一律标「未评审」而不是默认通过
   • 逐条三问是评审的最小动作，三问任一答不出该条不得出评审：谁实现（owner，落在跨域功能分配矩阵那一行）、谁验证（验证责任人）、在哪一层验证（MIL/SIL/PIL/HIL/台架/整车）。三问的答案必须落进字段，口头答完不写进表等于没答
   • 不可实现/不可测试条款的改写要现场做，不能记进 open point 拖走：现场按第 2 讲五条判据逐条套、给出改写版本、当场重问三问。一条经验判据——单次评审若改写量超过条款总数的两成，说明写作阶段的模板与培训没到位，应回炉重写而不是逐条修补
   • 对账一：条款清单 ↔ K4-03 的测试用例矩阵，逐条双向查。孤儿两类——有条款无用例（补用例，或说明该条在哪一层免测并留书面论证）、有用例无条款（用例在测一个没人要求的行为，要么补条款要么删用例）。覆盖率定义本体、未覆盖项四条分流与结构覆盖定档归 K4-03，本课只管条款这一端摆得对不对
   • 对账二：条款清单 ↔ 模型架构清单（子系统/Runnable）。这是 K4-02「建模入口检查」的对面一侧，方向相反、必须单独走一道，只做对账一查不出模型里多做的功能。两类孤儿及处置——无源功能（模型里有实现、指不回任何条款）评审打回，要么补条款要么删实现；空头条款（有条款、无实现载体）要么补实现，要么显式降级为「非本版范围」并写进下一版计划，不许悄悄留在清单里刷分母
   • 追溯链的形态与维护机制不在本课：软件域的产物级双向链是「需求 → 模型/代码单元 → 测试用例 → 测试结果/覆盖率报告」，工具（DOORS/Polarion）与追溯矩阵的维护、上溯率/下溯率口径归 M1-04，登记进 DVP&R 的格口归 M1-03。本课只管条款这一端的字段齐不齐、有没有唯一 ID、能不能被挂上链
   • 高扇出条款是评审与变更的默认盯防对象：从追溯矩阵统计每条条款的下游引用次数（用例数＋模型单元数＋被其他条款引用数），排在前列的多是接口条款与平台公共条款，动它们必须拉全部引用方会签而不是只通知直接下游。统计做法与变更放大系数的含义归 M1-04，本课只把它作为条款分级评审的输入
   • 出口判据写成可机检的一张表，六项全绿才允许基线冻结：每条条款有唯一 owner、有验证方法与验证层、判据落在可观测量上、阈值项已标注是否为标定量、模式行为已挂迁移表附表号、安全相关条款已挂 TSR 条款号与 ASIL。冻结的时点判据见第 4 讲
4. 文档骨架、单条条款八字段与九类附表；基线冻结时点与触发 CR 的条款粒度
   • 文档骨架与功能清单的 ID 规则：功能按热管理子域分组（座舱侧／电池侧／电驱与电子侧／系统自保护侧，分组口径沿用 K3-01 的热请求源清册），条款 ID 一经分配终身不改——作废条款只标状态、不回收编号。回收编号会让历史验证报告与追溯链悄悄指向另一条内容，是查不出来的一类错
   • 单条条款八字段：触发条件／输入信号及其新鲜度要求／处理／输出／参数／异常／性能指标／验证方法。字段口径的主课指针分开挂——新鲜度 age、逐信号 timeout 取值与 SNA 编码归 K2-02＋K1-01，参数字段的规格归 K6-10，异常字段的 DTC 设计归 K5-01、降级语义归 K5-02，性能指标的目标值口径归 B1-04。本课只管「哪一格填什么、缺哪一格算不合格」
   • 请求/回执类条款的字段写法（F4-02 明确前指本课的那一项）：请求侧把「请求类型、请求热功率与紧迫度、期望持续时长」落进输入/输出字段，回执侧把「批准／降功率批准／延迟批准／拒绝＋拒绝原因码」落进输出与异常字段，并强制补两项——回执超时的时长与超时后的确定性去向、每种非满足回执各对应的退路。协议本体与三种退路的内容归 F4-02，信号新鲜度与超时字段归 K2-02，本课只管这些内容进条款时摆在哪个字段
   • 职责归属条款：功能归属在规格里的成文载体＝条款的 owner 字段 ＋ 跨域功能分配矩阵那一行。K1-02 明确前指本课的那一项——「重试由谁发起、退避由驱动层还是策略层执行」——写法是在该功能条款里增列一行归属声明并在矩阵里把 owner 唯一化。判据一条：同一动作在两层里出现两个 owner 即为不合格，否则上层与驱动层各自重试会叠加成连续堵转。重试限次/退避时长、到位与堵转判定窗归 K1-02，「重试—放弃—降级」语义归 K5-02
   • 九类附表与各自主课指针，条款正文只引附表号不复述内容：①模式表 ②状态×事件迁移表 ③仲裁优先级表（①②③→K3-01＋K4-05＋B3-04）④信号接口表（新鲜度/超时/SNA/通信矩阵指针→K2-02＋K1-01）⑤任务周期与响应时间预算表（→K4-01）⑥诊断与 DTC 表（→K5-01）⑦标定量规格表（归属→K6-01/K6-05，字段→K6-10）⑧安全需求追溯表（TSR↔条款↔ASIL→K2-03/I7-03）⑨跨域功能分配矩阵（本课新增）。附表编号以项目模板为准，本课给的是「哪一张表由哪门课定字段」的指针，不是固定编号
   • 第九张——跨域功能分配矩阵，是评审第一问「谁实现」的成文载体：每条功能逐行标 owner／输入信号的权威源（哪个域产生、经哪条报文下发）／失效默认值／验证层。它专治两类缝——同一功能两个域都以为对方做、以及权威源没写死导致两边各算一份同名量。矩阵本体的设计方法（模式与执行器目标状态映射、直辖 vs 可请求执行器、订阅 vs 自行合成的责任线）一律前指 K3-01，本课只管规格里有没有这张表、字段口径全不全、交接时怎么验收
   • 基线冻结时点（本课承重，与 K4-04 的分工在此写死）：基线机制——配置项清单、版本标识、发布件构成——归 K4-04；本课定的是时点，判据三条同时成立才允许冻结：条款清单通过第 3 讲的六项出口判据、九类附表齐版且版本号与条款正文一致、追溯链可导出。冻结前的改动叫修订，冻结后一切改动走 CR；冻结动作挂在哪一道项目门禁上按项目门禁表定，门禁节拍与机电软并线的对齐归 M1-07
   • 触发 CR 的条款粒度分三档，写死在文档首页而不是临场判：(a) 阈值类改动——该量已是标定量的，落标定、不触发软件 CR，走标定数据的版本与变更流程（归 K6-05/K6-10）；(b) 验证方法或验证层改动、条款判据量改动、新增或删除条款——触发常规 CR，影响分析须同时覆盖用例矩阵与模型架构清单两侧；(c) 跨域功能分配矩阵的 owner 列、输入信号权威源、失效默认值改动——触发重大 CR 且须双方会签（接口需求单方面改动最容易埋雷，见 M1-04）。CR 流程本体与 CCB 归 M1-02，配置管理侧的影响分析维度归 K4-04；三档分界一模糊，最常见的后果是「改了阈值没人知道验证层也跟着变」
5. 向 Tier1 交接：附件挂接、接口冻结与回交证据包
   • 挂接方式：功能规格不单独发，作为技术协议/SOW 的技术附件随件挂，且在 SOW 的交付物清单里显式列名与版本号。只发邮件、不进附件清单的规格，在争议时不具备合同效力。SOW 五块条款结构（交付物清单／各方职责边界／接口与验收方法／变更与费用触发条件／时间节点）归 M1-02，技术协议与商务条款层归 Q2-02，产业链分工的一般图景归 A5-03
   • 接口冻结与变更走 CR：本文档里的接口类条款（跨域信号、请求/回执协议、诊断接口）与 ICD 同步冻结，冻结后按第 4 讲的三档粒度走 CR。判据是「接口类条款与 ICD 是否列在同一份冻结清单里」——各冻各的必然错位。ICD/DIA 的冻结机制与「只冻 ICD 会让安全工作产物落缝」归 M1-02，DIA 条目构成与 SEooC 假设声明归 K4-09
   • 回交证据包三件必须写进交接条款并各给验收判据：需求覆盖率报告（分母＝本文档条款数，口径见 K4-03）、状态机核对报告（完备性核对与静态核对，口径见 K4-05）、HIL 报告（测试层级与出口判据见 K4-03）。统一验收判据一条——三份报告能逐条指回本文档的条款 ID；指不回的报告等于没交，不许以「我们内部做过」抵充
   • 证据互认与抽样复测不在本课：Tier1 交回的报告 OEM 认不认、抽样复测比例怎么定、台架归属与用例来源怎么分、谁签字、签字后缺陷责任与保修归属如何随之改变，全部归 K4-09。本课只负责把「要交哪三份、按什么口径、能不能对上条款号」写进交接条款
   • 标定权与算法 IP 边界要在交接谈判里逐量落地，不能停在原则表述：可执行的判据是「开放哪些标定量、以什么可标性等级开放」，等级四档——只读／可标／需授权可标／不可标（写保护）。等级定义与安全相关量的写保护属性归 K6-10，标定量归属与责任矩阵、标定基线与版本归 K6-05，标定工具与协议归 K6-01，IP 议价与产业视角归 N5-02
   • 标定量规格表随功能规格一并作为技术协议/SOW 附件交付，它是上一条落地的物理载体，字段口径引 K6-10（规格表本体的字段设计不在本课展开）。交接完整性判据一条：凡在条款里标了「该阈值为标定量」的量，必须能在这张表里找到对应行且可标性等级已填；找不到即为交接不完整，不得放行
   • 交付形态与跨企业权限分级不在本课，一律写「见 K4-09」：源码／目标码／受保护模型／FMU／SWC+ARXML／hex+A2L 等形态谱与各档的可改动空间、A2L 对外裁剪、SecurityAccess 等级分发与种子-密钥托管、AUTOSAR 分层上的自研外包切分与退出成本，全部归 K4-09。两门课的分工一句话——本课管「往外发的那份规格怎么写、怎么交」，K4-09 管「收回来的软件件怎么验、钥匙发给谁、签完谁背缺陷」

• 以为把控制策略描述写成一段通顺的自然语言就算需求，其实需求的最小单位是条目化条款——一条只说一件事、带唯一 ID、带 owner、带验证方法与验证层；散文式描述在 K4-02 建模时指不回具体条款，在 K4-03 算覆盖率时进不了分母。
• 以为需求分解到零部件规范就到底了，其实控制/软件方向在那之后还有一层控制功能规格（M1-04 已明写它只讲通用机制、把控制条款让给本课）；不承认这一层，MIL/SIL/HIL 就没有可对照的「写下来的需求」。
• 以为条款写「电芯最热点温度不超过限值」很严谨，其实车上没有该测点时这条永远无法判定通过与否——两侧各自选一个替代量都能算「通过」，而实车问题无人认账；判据必须落在真实存在或可估计的观测量上，估计量还要连误差带一起写进条款。
• 以为响应时间条款只要写得比整车目标快就安全，其实它的下界由检测延迟＋通信时延＋任务周期整数倍＋执行器机械动作时间四项之和决定，四项缺一核算就偏乐观，条款写下去 Tier1 也兑现不了。
• 以为阈值先写死、以后要改再说，其实标定期才发现要改就得走软件 CR 重出版本并跑一轮回归；判据很简单——凡与环境、电池型号、车型配置相关的阈值一律做成标定量，条款里只写「该阈值为标定量、见附表某行」。
• 以为需求覆盖率做到 100% 就说明需求闭环了，其实分母是「已条目化且带验证方法与验证层的条款数」；条款没条目化、验证层没写，分母本身就是假的，覆盖率数字随之失真（K4-03 已把上游修法明确指回本课）。
• 以为对账只要查「每条条款有没有用例」就够，其实还有方向相反的一道——从模型/Runnable 清单指回条款，指不回的是无源功能（K4-02 的建模入口检查要的正是这一道）；只做一个方向，查不出模型里多做出来的功能。
• 以为评审时把不可实现条款记进 open point 事后再改效率更高，其实改写必须现场做并当场重问三问——事后改的条款没经过六方在场复核，最容易改完又落一个新的不可测试条款。
• 以为条款作废了就把编号回收再利用，其实历史验证报告与追溯链还指着那个号，回收编号会让旧报告悄悄指向另一条内容；作废只标状态、不回收编号。
• 以为基线冻结是 K4-04 那门课的事，其实 K4-04 管的是基线机制（配置项清单、版本标识、发布件构成），「什么时候允许冻」与「改哪一级字段算 CR」是需求侧判据、归本课；两门都以为对方管，就出现冻结时点没人定、改动随手就进的真空。
• 以为改一个标定量的值也要走软件 CR 才算严谨，其实那属于标定数据的版本与变更流程（K6-05/K6-10）；把三档粒度混成一档，要么把 CR 流程堵死，要么把该双方会签的接口改动放过去。
• 以为把功能规格发邮件给 Tier1 就算交付了，其实它必须作为技术协议/SOW 的技术附件列名列版本才具备合同效力（SOW 条款结构见 M1-02）；只发邮件的规格在争议时不算数。
• 以为 Tier1 交回一摞报告就算证据齐了，其实验收判据是三份报告能逐条指回本文档的条款 ID——指不回的报告等于没交；至于这些报告 OEM 认不认、要不要抽样复测，那是 K4-09 的题、不是本课能替它答的。
• 以为标定权谈到「关键量不开放」就够了，其实必须逐量落到四级可标性（只读/可标/需授权可标/不可标写保护）并进标定量规格表随件交付，否则交接后每一次开放请求都要重谈一次。
• 以为跨域功能分配矩阵只是把 owner 抄一遍，其实它还要写死输入信号的权威源与失效默认值——同名量两个域各算一份、故障时互指，根因几乎都在这两栏空着。

需求区 · 想听众筹

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