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

课程代码 K4-07 · 板块 K 控制、软件与标定 / K4 嵌入式软件与开发 时长 约 3.5 小时（5 讲 ＋ 1 次条款改写与评审实操） 适合对象 控制／系统工程师，尤其是要在功能规格上签字的那一位；负责组织功能规格评审的技术主管；与 Tier1 谈技术协议与标定权的技术负责人。控制方向必修，系统方向选修。前提是你手上已经有、或即将开始写一份控制功能规格，问题不是「需求是什么」而是「这一条这样写，Tier1 到底做不做得出来、试验到底测不测得了」。 前置 M1-04 需求管理与追溯（DOORS 等） 需求管理与追溯（DOORS 等）——通用良构要素、双向追溯与变更影响分析是本课的上游；B1-05 基于 V 模型的热管理正向开发流程 基于 V 模型的热管理正向开发流程；K3-01 整车热管理控制策略总览与模式管理 整车热管理控制策略总览与模式管理；K4-01 热管理嵌入式软件架构与 AUTOSAR 基础 热管理嵌入式软件架构与 AUTOSAR 基础；体系外前置（需自备）：读得懂一份条目化需求文档——条款 ID、字段表、追溯链三样的基本含义 本讲义定位 讲师授课蓝本 / 学员自学讲义，是本课题的完整展开版

---

按任务导航

你手上的事	直接看	还要配
项目刚立项，要定「这份规格我们写到多细」	第 1 讲：两条交付路线决定颗粒度，字段减哪几栏	第 4 讲（八字段与九类附表）· A5-03 产业链地图：主机厂—Tier1—Tier2 分工（要不要自研的战略判据）
手上一条条款，判它「能不能实现、能不能测」	第 2 讲：五条控制专属判据，逐条套	关键判据与口径详解（响应时间下界式可当场算）
条款写了响应时间，不知道 Tier1 兑不兑得了	第 2 讲 2.3 与判据详解：四段时间相加得下界	K4-01 热管理嵌入式软件架构与 AUTOSAR 基础（任务周期与可调度性）· K1-02 执行器驱动：电子阀/泵/风扇/压缩机 PWM（执行器动作时间）
下周要主持一次功能规格评审	第 3 讲：六方组成、逐条三问、两道对账、六项出口判据	第 4 讲（出口判据里的字段从哪来）· K4-03 MIL/SIL/HIL 验证流程（用例矩阵那一端）
覆盖率报告数字很好看，但总觉得不对	第 3 讲 3.5 两道对账 ＋ 第 2 讲 2.6	K4-03 MIL/SIL/HIL 验证流程（需求覆盖率 C_req 的分子分母口径本体）
要判「这次改动走不走 CR、要不要双方会签」	第 4 讲 4.7：三档粒度写死在文档首页	K4-04 软件版本、配置与变量管理（配置管理侧影响分析）· M1-02 热管理项目管理与主机厂—供应商协同（CR 流程与 CCB 本体）
规格要发给 Tier1 了，不知道怎么挂、要回收什么	第 5 讲：附件挂接、接口冻结、回交证据包三件	K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署（收回来的软件件怎么验、钥匙发给谁）
谈标定权，对方只肯说「关键量不开放」	第 5 讲 5.5：逐量落到四级可标性并进附表	K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量（可标性等级字段口径）· K6-05 标定数据管理与版本控制（标定量归属）

⛔ 本课不覆盖，一律只写去向：模式表／状态×事件迁移表／仲裁优先级表的本体设计方法 → K3-01 整车热管理控制策略总览与模式管理 ＋ B3-04 热泵型整车热管理架构（多通阀一体化方案）；这张迁移表本身完不完备、可不可验证（不可达与陷阱状态、死锁活锁、状态覆盖／迁移覆盖、模型检验工具边界）→ K4-05 模式状态机的完备性核对与可验证性设计，本课全程不展开；信号新鲜度 age、逐信号 timeout 取值、SNA 编码、通信矩阵与报文设计 → K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成 ＋ K1-01 热管理传感器信号处理与故障诊断；任务周期、可调度性分析与响应时间分析本体 → K4-01 热管理嵌入式软件架构与 AUTOSAR 基础；执行器重试限次、退避时长、到位与堵转判定窗 → K1-02 执行器驱动：电子阀/泵/风扇/压缩机 PWM；DTC 设计 → K5-01 OBD/UDS 诊断与故障码（DTC）设计，降级等级与「重试—放弃—降级」语义 → K5-02 热管理故障处理与降级策略；标定量的类型、轴点、插值／外插保护、min/max/default、写保护与可标性等级定义 → K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量，标定量归属与责任矩阵、标定基线 → K6-05 标定数据管理与版本控制，标定工具与协议 → K6-01 热管理标定流程与工具（INCA/CANape）；安全目标→FSR→TSR 的推导与 ASIL 定级 → K2-03 功能安全（ISO 26262）在热管理中的应用 ＋ I7-03 功能安全导向的结构与失效模式设计；通用良构需求要素与「应尽量满足」这类不可判定写法、追溯工具与追溯矩阵维护、上溯率／下溯率、变更放大系数的统计做法 → M1-04 需求管理与追溯（DOORS 等）；需求覆盖率的定义与分子分母、未覆盖项分流、结构覆盖阶梯、用例设计取点、MIL/SIL/PIL/HIL 各级本体与台架架构 → K4-03 MIL/SIL/HIL 验证流程；模型架构划分、建模规范、定点化、代码生成 → K4-02 基于模型开发（MBD）：Simulink 建模与代码生成；配置项清单、版本号与分支策略、基线机制、发布件构成、变型管理 → K4-04 软件版本、配置与变量管理；SOW 五块条款结构、ICD／DIA 接口冻结机制、CR 流程本体与 CCB → M1-02 热管理项目管理与主机厂—供应商协同；技术协议与商务条款层、谈判战术 → Q2-02 主机厂—供应商技术对接与商务谈判；软件件的交付形态谱、DIA/SEooC、跨企业权限分级与钥匙分发、证据互认与抽样复测、放行签署与缺陷责任 → K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署；门禁节拍与机电软并线的阶段对齐 → M1-01 汽车研发流程（APQP/IATF16949）与热管理里程碑；算法 IP 议价与产业视角 → N5-02 软件定义热管理与整车 OTA 演进 ＋ A5-03 产业链地图：主机厂—Tier1—Tier2 分工；登记进 DVP&R 的格口 → M1-03 DVP&R 与验证计划管理。⛔ 本课也不讲通用需求工程理论、不讲需求管理工具的操作、不讲控制算法与策略本体（归 K3 模块）——被写对象钉死为「热管理控制功能规格这一份文档」。

---

引言：这一条读起来很像需求，但它谁也约束不了

拿一份真实项目的热管理控制功能规格出来，翻到快充冷却那一节，大概率会读到这样一句：

快充过程中，电芯最高温度不超过限值，且模组温差不超过限值。

这句话在评审会上通常一次就过。它有主体、有条件、有判据，读起来像一条合格的需求。三个月后，事情是这样发生的：

Tier1 按 BMS 上报的最高单体温度实现了这条，在自家台架上判「通过」；OEM 的整车用例按模组测点判，也判「通过」。实车快充复现温差超标时，两边把各自的通过报告摆在桌上，谁也不认账。不是有人撒谎，是这条条款从来没有说清楚判据落在哪个量上——车上根本没有「电芯最热点」这个测点，两侧于是各选了一个自己有的量，各自都合规。

同一句话还埋着第二件事：那两个「限值」被写成了策略里的常量。标定期发现限值定低了、冷却功率长期打满，改这个数要 Tier1 重出一版软件、跑一轮完整回归，周期以周计。而如果当初条款里写的是「该阈值为标定量、见附表某行」，这件事是标定工程师一个下午的活。

第三件事更隐蔽：这条功能在跨域功能分配矩阵里根本没有行——「电芯温度这个量由 BMS 产生还是由热管理域控估计」没有权威源声明，失效时的默认值也空着。故障复现时两个域互相指对方。

⇒ 这三件事都不是控制策略没想清楚，是这份文档没写对。而它们都发生在文档离开你的手之后，那时候改一次的代价已经不是改一句话了。

钉子①：需求的最小单位是条款，不是段落

很多团队交出去的「功能规格」是一篇通顺的控制策略描述：先讲背景，再讲思路，再讲几种工况下大概怎么动。这份文档读起来比条款表舒服得多，而它在下游一个字都用不上——建模时指不回具体条款，算覆盖率时进不了分母，出了问题时找不到 owner。

⇒ 条目化不是形式主义，它是这份文档能不能被下游使用的唯一门槛。一条条款＝一个唯一 ID ＋ 八个字段 ＋ 一个 owner ＋ 一个验证层。第 4 讲把这张表摆出来。

钉子②：控制条款有自己的「不可实现」，通用需求工程答不了

M1-04 需求管理与追溯（DOORS 等） 讲的良构要素（主体、条件、判据、可验证、单一性、可追溯、不含实现方案）全部成立，条款依然可能是不可实现的——因为控制条款还多了四个物理约束：车上有没有那个量、控制链来不来得及、这个数以后要不要改、这个行为能不能用表说清楚。这四件加上「验证方法与验证层」，就是第 2 讲的五条判据，它们是本课的承重部分。

钉子③：评审的产出不是「同意」，是三个填进字段的答案

评审席上最常见的失败不是没发现问题，而是发现了、口头答了、没写进表。逐条三问——谁实现、谁验证、在哪一层验证——的答案必须落进字段；口头答完不写，等于没答。第 3 讲把评审做成一个有出口判据的动作。

本课的数字口径

本课是一门讲文档结构、判据与责任切分的课，能给的确定数字很少。⇒ 全课数字按三类处理，每一处当场标明：

• 标准里定死的（如汽车功能安全里 ASIL 分四个等级 A/B/C/D）——给准确值并写出它出自哪一族标准；版次一律按现行版本目录确认，⛔ 本课不钉死年份；⛔ 本课未采购这些标准的原文，因此只写它管什么、条款落在哪个位置，⛔ 不复述任何条款正文、⛔ 不自造条款号与过程域编号；
• 行业典型区间——只给区间并标「典型」，如热管理控制任务周期常见落在 10 ms 与 100 ms 两个量级（口径与本体归 K4-01 热管理嵌入式软件架构与 AUTOSAR 基础）；
• 与平台强相关的量（一份规格的条款总数、单次评审的合理改写比例、接口冻结提前量、回交报告的抽样比例……）——给典型参考区间＋常见值锚点，同时给出你自己怎么拿到本项目那个真数的路径，并附免责说明。

⚠ 本课出现的一切具体数字都是典型参考值或教学假设值，⛔ 不是验收依据，必须以你本项目的实测、体系文件与标准现行版本为准。

⚠ 符号口径先钉住，因为本课的时间量与邻课撞名：本课第 2 讲用到的 T_task（承载该功能的控制任务周期，ECU 侧，工程上常用 ms）与 K4-01 热管理嵌入式软件架构与 AUTOSAR 基础／K4-03 MIL/SIL/HIL 验证流程 的用法完全一致，直接复用、⛔ 不另起符号。本课新定义的 t_spec / t_detect / t_comm / t_act 全部是控制链上的时延，与 T_task 同族、可相加。⚠ 但它们与 K4-08 控制软件回归验证：基线与激励库、回归范围裁剪、自动执行与失败分诊 的 t_win / t_run / t_settle 不是一族——那三个是台架排期侧的挂钟时间，⛔ 不得与本课的时延量相加或直接比大小。另外，本课多处提到需求覆盖率 C_req，它的定义、分子分母口径与报告要求一律沿用 K4-03 MIL/SIL/HIL 验证流程，本课只管分母那一端的条款摆得对不对，⛔ 不重新定义这个符号。

---

第 1 讲　这份文档是什么、谁写谁签

1.1 先钉死定位：它是 V 模型左支多出来的一层

B1-05 基于 V 模型的热管理正向开发流程 把热管理的正向开发拆成四层：整车热需求 → 系统架构 → 子系统设计 → 零部件设计。这四层全部在硬件与系统侧——它们的产出物是架构图、回路拓扑、部件规范书。

控制/软件方向在「子系统设计」之后还有一层，它的产出物不是硬件，而是一份写下来的、条目化的需求文档。这一层就是控制功能规格。

它为什么必须是一层独立的产出物，只有一个理由，而这个理由足够硬：

K4-03 MIL/SIL/HIL 验证流程 的 MIL/SIL/HIL 拿来对照的，正是这份文档。不承认它是独立产出物，验证阶段就没有可对照的分母，需求覆盖率 C_req 无从谈起——⛔ 不是数字难看，是这个数字不存在。

⚠ 这里有一个非常常见的误判：「我们的零部件规范里已经写了控制要求了」。零部件规范约束的是那个部件（压缩机要能在多少转速下工作、阀要在多长时间内切换到位），而控制功能规格约束的是那段软件（在什么条件下、依据什么输入、发出什么指令、多久之内、怎么验）。两者的被约束对象不同、owner 不同、验证层也不同。混在一起写，最后的现象是：部件供应商说这是软件的事，软件方说这是部件规范里的指标。

1.2 两条上游链必须并进同一张清单

条款不是凭空来的，它有两条上游：

功能需求线：整车规范 → 系统规范 → 零部件规范（B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件 讲这条链的分解与追溯机制）。控制条款接在这条链的末端，把「这台车要在多长时间内把座舱降到多少度」这类目标，转成「软件在什么条件下让哪个执行器动到哪一档」。

安全需求线：安全目标 → 功能安全需求 → 技术安全需求（推导与定级归 K2-03 功能安全（ISO 26262）在热管理中的应用 ＋ I7-03 功能安全导向的结构与失效模式设计）。技术安全需求里落到软件的那一部分，必须以条款形式并进本文档的同一张清单，并在字段里标明它来自安全需求线。

⇒ 判据一条，可当场查：

两条链的条款，是不是在同一张清单里？用的是不是同一套 ID 规则？

不并轨的典型症状：安全需求单独躺在一份「功能安全需求规格」里，功能条款在另一份里；验证时安全条款的用例挂在安全团队的矩阵上，功能条款的用例挂在软件测试的矩阵上，两张矩阵的分母互相不含。发布评审时问「一共多少条需求、覆盖了多少」，得到两个数，而没有人能把它们加起来——⛔ 它们不能加，口径不同。

⚠ 并轨不等于合并管理责任。安全条款的 owner 仍然是功能安全工程师、推导依据仍然在安全线的文档里，本文档只是它在软件侧的落地载体。并的是清单与编号，⛔ 不是把安全分析搬进来。

1.3 过程域落点：只写位置，不复述条目

这份文档在业界通行的过程参考模型里有明确位置：它同时承担系统需求分析与软件需求分析两个过程域的工作产物职责——具体是落在其中一个还是两个都占，取决于第 1.4 节要讲的交付路线。它的工作产物与 K4-03 MIL/SIL/HIL 验证流程 的软件测试过程域、K4-04 软件版本、配置与变量管理 的配置管理过程域，串成同一条证据链：需求 → 测试 → 配置基线，三段任何一段的双向追溯断掉，整条链就不成立。

⚠⚠ 两条硬纪律，本课全程遵守，也请你在自己的文档里遵守：

1. 该过程参考模型目前有两个大版本并行流通，过程域名称与工作产物编号有差异。⇒ 引用时必须显式声明所依版本，⛔ 不得混引。混引的现象很好认：评审记录里一半写着旧版的过程域名、一半写着新版的工作产物号，评估时对不上。这条口径与 K4-04 软件版本、配置与变量管理／M1-04 需求管理与追溯（DOORS 等） 一致。
2. ⛔ 本课未采购这些标准的原文，因此本讲义不复述任何基本实践条目的文字、不给条款号。你在自己的文档里做过程域对位时，须按现行版本原文逐条确认。⇒ 这不是谨慎过度：拿一份转述去做评估准备，评估时被逐条追问原文，是这类项目上真实会发生的事。

1.4 安全相关条款的三个附加字段

汽车功能安全标准的软件产品开发部分，对软件安全需求规范另有要求。落到本文档，就是安全相关条款在八字段之外额外多三格：

附加字段	填什么	为什么必须在这份文档里
ASIL 等级	该条继承自哪一级（分四级，等级划分出自功能安全标准族，⛔ 具体分级依据与推导归 K2-03 功能安全（ISO 26262）在热管理中的应用）	决定这条要走哪一档验证与评审严格度
对应的技术安全需求条款号	该条是从安全线的哪一条落下来的	缺它，安全论证链在软件这一端断掉
该条涉及的参数是否允许在线标定	是／否，以及若允许，等级是哪一级	安全相关量随手可标，是最容易被忽略的一类开口；等级定义与写保护属性归 K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量

⛔ 条款号与版本一律按现行版本确认，本课不引任何条款号、不自造编号。安全相关标定量的变更评审归 K6-05 标定数据管理与版本控制。

1.5 两条交付路线决定颗粒度，⛔ 不能混着走

路线 A ＝ OEM 只写黑盒功能规格。写四件事：做什么、什么条件下做、做到什么程度、怎么验。⛔ 不写信号名、不写任务周期、不写内部状态机结构——那些是 Tier1 的架构自由度，写进去等于替对方做架构，出了问题责任还回到你这边。

路线 B ＝ OEM 自研上层策略，直接写到软件需求粒度。字段全开：信号名、新鲜度要求、任务周期、状态×事件迁移表作为附表挂进来、参数表逐个列。

选路线的判据是架构定义权在谁手上与要不要保留二供导入的可能——战略层的判断归 A5-03 产业链地图：主机厂—Tier1—Tier2 分工，产业与议价视角归 N5-02 软件定义热管理与整车 OTA 演进，⛔ 本课不重讲。

⇒ 本课只管一件事：选定路线之后，这份文档写到哪一档、哪几栏字段该减掉。

字段	路线 A（黑盒）	路线 B（软件需求）
触发条件	写，用整车／系统级可观测的量表述	写，可用内部信号名
输入信号及其新鲜度要求	只写接口上的信号与其新鲜度要求	写全，含内部信号
处理	写行为，⛔ 不写算法结构	可写到算法结构与模块划分
输出	写接口输出	写全
参数	写「该阈值为标定量」＋可标性等级要求	写全，并挂标定量规格表行号
异常	写对外可见的降级行为	写全，含内部故障处理
性能指标	写，且必须是接口上可测的	写全
验证方法与验证层	写，且必须是OEM 侧能执行的那一层	写全
任务周期附表	⛔ 不发	发
状态×事件迁移表附表	⛔ 不发内部状态机；只发对外可见的模式集	发

⚠⚠ 最常见的错法是混着走：整体写成黑盒，但某几个「我们比较懂」的功能突然写到了信号名与内部状态。后果有两个，都会在集成期爆发——一是 Tier1 的架构在那几处被你切开，它自己的模块划分被迫迁就；二是那几条的责任变得说不清（按黑盒判？还是按你给的实现判？）。⇒ 一份文档一条路线，写在文档首页。确实有个别功能要下沉，就把它单列成一节并写明该节走路线 B，⛔ 不许在同一张清单里悄悄混。

1.6 谁写谁签：不落到人就等于没签

分派表照抄即可用：

内容	谁写谁签
功能条款正文（触发／处理／输出）	控制工程师，同时是该条的 owner
输入信号与新鲜度字段	EE／网络工程师（口径归 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成 ＋ K1-01 热管理传感器信号处理与故障诊断）
参数字段（是否标定量、可标性等级）	标定工程师（口径归 K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量）
异常字段（DTC、降级）	诊断工程师（归 K5-01 OBD/UDS 诊断与故障码（DTC）设计／K5-02 热管理故障处理与降级策略）
安全条款的三个附加字段	功能安全工程师（归 K2-03 功能安全（ISO 26262）在热管理中的应用）
验证方法与验证层	试验／验证工程师（归 K4-03 MIL/SIL/HIL 验证流程）
Tier1 侧对口	路线 A 下必须设一名具名签署人

⚠ 评审签署 ≠ 责任转移。路线 A 下 Tier1 展开出的软件需求由 Tier1 签，但 OEM 仍须校验其对黑盒条款的符合性——这一步经常被跳过，理由是「他们签了」。跨企业的责任划分本体（安全工作的分派协议、缺陷责任与保修归属）归 K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署，⛔ 本课不展开。

1.7 它在配置管理里的身份：三样成分必须同批次发布

本文档就是 K4-04 软件版本、配置与变量管理 所说的「需求」这一类配置对象的物理载体。它含三样成分：

1. 条款正文；
2. 九类附表（第 4 讲逐一说明）；
3. 追溯链导出件（条款 ↔ 上游需求 ↔ 用例 ↔ 模型单元）。

⇒ 三样必须同批次、同版本号发布。

⚠ 本领域最常见的一类失配就在这里：只冻条款正文，附表另行漂移。现场表现非常好认——条款里引的附表号，在交付件里查不到，或者版本对不上。而这件事发生时没有任何工具会报警，因为附表通常是另一个 Excel 文件、由另一个人维护。基线机制本身（配置项清单、版本标识、发布件构成与校验）归 K4-04 软件版本、配置与变量管理；本课承重的是第 4 讲的冻结时点。

本讲小结：① 控制功能规格是 V 模型左支上一层独立产出物，不承认它则验证阶段没有分母；② 功能需求线与安全需求线必须并进同一张清单、同一套 ID 规则；③ 过程域落点只写位置，版本必须显式声明、⛔ 不得混引，条款原文一律按现行版本自行确认；④ 安全条款额外三格：ASIL、对应技术安全需求条款号、是否允许在线标定；⑤ 两条交付路线决定颗粒度，⛔ 一份文档一条路线；⑥ 签署粒度是字段不是文档；⑦ 条款正文＋九类附表＋追溯链导出件三样同批次发布。