B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件

课程代码 B1-02 · 板块 B 整车热管理系统架构 / 整车热平衡与需求定义 时长 约 4.0 小时（9 讲） 前置 B1-01 整车热平衡与热负荷谱；A2-02 泵与风机的工作点与特性曲线 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 B1-02 大纲的完整展开版

---

按任务导航

你手上的事	直接看	还要配
审一份待下发的冷板／阀／泵 CTS，判它能不能签字	第 1 讲：三层的主语与测点归属，看这条写没写在对的层｜第 8 讲：工况/测点/判据/验证方法缺哪一个、后果各不相同	第 4、5 讲（端口条目逐项）
摊一本温度或压降预算，定各段份额	第 2 讲：堆叠式怎么列、份额按灵敏度而非平均分、压降的第一刀必须先切给调节阀	第 6 讲（加性预算里裕度该怎么加）
追一件「供应商逐条合规、台架逐项达标，而闭环就是做不出来」	第 3 讲：六行时滞链与可观测性预算｜第 5 讲：可控性条款与次数型寿命条款	第 2 讲 2.4（阀的那一份压降）
回答「这个零件为什么被逼到工艺极限、成本下不来」	第 6 讲：逐级折算的放大倍数及其射程，载荷型与上限型的方向相反	第 7 讲（衰减栏与随机栏分列）
准备门禁上的需求覆盖率与一次变更的影响面	第 8 讲：双向追溯与覆盖率的分子分母口径｜第 9 讲：非性能七类自检与四份交付物	第 1 讲 1.4（owner 列为空不许冻结）

⛔ 本课不覆盖——

【不讲哪些题目】各部件耐温限值的物理依据（L3-02 整车热平衡与热害试验／J2-05 热浸（soak）与热害仿真）· 工况的定义与取值（B1-03 极端工况定义：高温、高原、低温、快充、拖挂爬坡）· 负荷谱（B1-01 整车热平衡与全工况热负荷谱分析）· 目标值怎么定（B1-04 目标设定：降温速率、冬季续航热损、快充温升）· 开发流程与门禁（B1-05 基于 V 模型的热管理正向开发流程）· 架构方案权衡（B1-06 架构方案权衡：性能/成本/重量/可靠性多目标决策）· EOL 参数重算口径（B1-07 整车热量账与能耗账的寿命末期口径：EOL 参数重算与末期设计点）· 阀本体特性与可调比（G4-04 比例阀/流量分配阀与回路调节）· 传感器选型与布置（G12-01 温度/压力/流量/湿度传感器选型与布置）· 控制器设计与前馈（K3-05 PID/前馈/增益调度控制实战）· 耐久与寿命的验证方法（L1-04 振动、热冲击与耐久台架试验／C2-03 风门驱动电机与执行器（步进/有刷/PWM）选型）· 需求管理工具与配置项（M1-04 需求管理与追溯（DOORS 等））。

【⛔ 真正不给的数】① 标准条款的限值与等级号——本课只写各标准管的是不是这件事，条文取值以现行目录的原文为准，引用前须核；② 本项目自己的验收阈值——阀权度的工程下限见 G4-04 比例阀/流量分配阀与回路调节，冷板压降上限与温差均匀性上限由第 2 讲摊出的预算份额与电芯一致性要求共同定，本课只说它占哪本账的哪一份；③ 教学假设之外的具体产品参数——被保护对象的长期许用温度来自电芯供应商 spec 与企标（两个来源不一致时两个都记、在耐温限值矩阵里写明仲裁方），接触热阻须按「名义贴合面积归一 + 绑压紧力与表面状态」的口径实测。

引言：「电芯不超 X ℃」写进冷板 CTS，为什么是一张废纸

整车层的那句话本身没错，错在它被原样搬了下去。冷板供应商的边界上只有两个进出水口和一张贴合面——他够不着电芯：电芯在他交付物的外面，温升里有一段发生在 TIM 上、一段发生在电芯壳到内部最热点之间，那两段都不归他。于是这条需求他签得了字、却验不了；问题一路捂到台架联试，才以「双方数都真、就是拼不上」的形态爆出来。

需求往下一级传递，传的不是那句话，是那句话在接收方边界内的等价形式。同一条整车目标落到冷板端口上，要被改写成他量得到的几个量：进口温度、流量、压降、温差均匀性，再加贴合面的接触热阻上限。这是一次翻译，不是一次转发——而翻译必然带损失。本课全部内容，就是把这份损失控制住、并让它在文件上留下痕迹。工程上，一条整车热目标展开到零件层（CTS）通常是十余条可测参数——这是它落到所有相关部件上的总数；摊到单个部件的端口上，则是五条上下（本课在第 4 讲给出冷板那五条的完整映射）。⛔ 两个数都随架构与部件数变化，⛔ 不是可照抄的指标（同一口径在第 1 讲 1.1 再说一次）。

一条判据，全课反复用

拿到任何一条待下发的需求，先问一句：接收方要验它，需不需要伸手去量他边界之外的东西？

需要——这一级翻译就没做完，⛔ 不许下发，动作是回去重译，不是「先发下去后面再说」。这一问对性能条款、非性能条款、控制可控性条款、寿命条款一律适用，是本课唯一一条不随对象变化的判据。

⚠ 别把它读成「需求要写得具体」——具体和可验不是一回事。「接触热阻不超过某值」够具体了，可只要没写面积基准（按名义贴合面积还是实际接触面积）和压紧力，供应商照样验不了，也照样能报出一个对他最有利的数。⇒ 用这一问过一遍手上现有的 CTS，通常能筛出一批「看起来很具体、实际验不了」的条目；筛出多少是各项目的现状，⛔ 不是一个可预期的比例。

三根钉子

钉子①：分解的本质是换语言，判据只有上面那一条。做不到「接收方在自己边界内、用自己能布的测点、在写死的工况下判过不过」的那条文字，它不是需求，是愿望。

钉子②：预算有两套代数，用错了会去松错那一项。一套是加性预算——温度、压降、功率沿环节相加，各段份额之和等于总额；另一套是层间折算下发——同一条要求在整车、系统、零件之间每传一级再乘一次裕度系数，是连乘。两者⛔ 不许互套。它们的危险也完全不同：层间连乘会把零件逼到工艺极限（四层每层各加 10%，总额就是约 1.46 倍；教学假设值，⛔ 不对应任何平台），而加性预算的危险是把误差全甩给排在最后的那个残差段。⇒ 落成一条纪律：每报一次「余量不够」，先说清它是在哪一套代数里不够的——不说清，给出的处置必然方向错误。

钉子③：预算的全集不止物理量那三本。温度、压降、功率这三本账都挂在「守恒量」这条线索上，所以它们天然会被想起来。控制侧还有三本不在这条线索上：可观测性（要哪些测点、放在哪、时间常数与刷新率上限是多少）、执行器权度与可控性余量、次数型寿命。这三本长期缺席，后果有一个极好辨认的形态——供应商逐条合规、台架逐项达标，而闭环就是做不出来。

两条会让你做出相反动作的误读

① 「压降是坏东西，分摊时让阀少吃一点、把余量留给换热器，是优化」——方向是反的。照这句话做出的具体动作是：把泵在工作点的可用扬程按各段物理阻力摊完，阀去捡剩下的零头。后果是阀权度被压得很小，阀的「指令—流量」曲线被压平：开度从三成推到七成，回路流量几乎不动。标定台上看到的是「调了没反应」，而它极容易被归因成 PID 参数不好，于是去加大增益、加积分——换来的是低开度段一动就过冲。⛔ 真相是：给调节阀的那一份压降必须在分摊之前先按目标阀权度反算着切出来，它不是可以省掉的损失，是该留的裕度；省掉它等于花钱买了一个不可调的回路。

② 「各项裕度用均方根合成比线性相加更科学」——这句话本身对，推广到衰减项上就反了，而且反得看不见。照它做出的动作是：把结垢、EOL 内阻抬升、TIM 泵出、密封应力松弛、滤芯堵塞、传感器漂移，和测量不确定度、工艺散差一起装进同一个均方根式子，算出一个「总裕度」，再按它定设计点。后果是BOL 台架逐项达标、账面全绿，而 EOL 不达标。原因是均方根合成建立在「各分量独立、有正有负、互相抵消」这个前提上，而上面那六项全部是随时间单调同向的确定性趋势：它们不抵消，它们叠加。⛔ 真相是裕度必须分成两栏、各用各的合成规则——随机型走均方根，衰减型取同一时间点各衰减曲线的取值做同向叠加。⚠ 这一条最难被发现，是因为它不产生任何异常读数：没有哪一项超差，只是全部加起来的那个总量被系统性低估了。

本课管到哪儿为止

本课只管把要求做成一份能下发、能追溯、能冻结的文档，⛔ 不管这些要求的物理值从哪儿来。凡遇到「这个数取多少」，本课一律只给类型与去向：限值的物理依据在 L3-02 整车热平衡与热害试验／J2-05 热浸（soak）与热害仿真，工况取值在 B1-03 极端工况定义：高温、高原、低温、快充、拖挂爬坡，负荷谱在 B1-01 整车热平衡与全工况热负荷谱分析，目标值怎么定在 B1-04 目标设定：降温速率、冬季续航热损、快充温升，架构怎么选在 B1-06 架构方案权衡：性能/成本/重量/可靠性多目标决策，EOL 参数重算在 B1-07 整车热量账与能耗账的寿命末期口径：EOL 参数重算与末期设计点。

⚠ 这条分工线不是偷懒，是两层的判据形态不同：方法层给的是「该写哪些格、每格绑什么」，取值层给的是数；混在一起，本课就会变成一本抄不完、且永远过期的限值手册。它在篇幅上也看得见——一份真正可下发的 CTS，通常六到八成的篇幅是工况与判据的描述，而不是数值本身（⛔ 比例随部件类型变化）。⇒ 反过来对读者的要求是：本课里凡标着「教学假设值」的数，一个都不许抄去下发。

全课九讲怎么走

先定三层的语言与接口（第 1 讲）→ 把物理量摊成加性预算（第 2 讲）→ 把时间、权度、次数这三本非守恒量的账也摊下去（第 3 讲）→ 翻译成部件端口上的性能条目（第 4 讲）与可控性、寿命条目（第 5 讲）→ 用两套不同的代数管住裕度（第 6、7 讲）→ 给每条需求配齐四要素并建双向追溯（第 8 讲）→ 用全集自检兜住漏掉的整类，落成四份交付物（第 9 讲）。

⚠ 贯穿全课有一条暗线：每一步都有一个「整类被漏掉」的东西——预算漏掉控制侧那三本账、CTS 漏掉可控性与次数型寿命、裕度漏掉衰减栏、需求全集漏掉非性能那七类。分解链上的错误分两种：一种是某一条写错了，评审能抓到；另一种是某一整类根本没出现，评审也抓不到，因为表看起来是满的。本课的结构是为第二种设计的。

第 1 讲　三层需求体系与接口：三种语言、五类接口、一个 owner

这一讲不出现任何限值，也不摊任何预算——它只解决四件事：一条要求该写在哪一层、用谁的语言写、在谁的边界上测、由谁在它不达标时给出处置方案。这四件全是"文档怎么写"的事，听起来像内务，但分解链上最贵的那几种失效恰恰都发生在这里：写错了层的需求会一路传到台架联试才炸；接口上的需求两侧都觉得是对方的；没有 owner 的需求会安静地掉在两层之间，直到有人问起才发现谁都没做。本讲最后给出一张六格自查表，你今天就能拿它去过一遍手上的 CTS。

1.1 三层的语言与颗粒度：主语、量、测点、签字人是一起换的

VTS（整车技术规范）、SSTS（系统技术规范）、CTS（零部件技术规范）说的可以是同一条要求，但它们不是同一句话的三种详细程度，而是三种语言。往下一级，四件东西同时换：

	主语是谁	量的类型	测点在谁的边界上	谁签字
VTS	车	用户可感知或法规可测的量	整车层	整车项目
SSTS	热管理系统	回路级的温度 · 流量 · 压降 · 功率	系统边界	系统负责人
CTS	这个零件	它自己端口上的可测量	零件边界	零件 owner 与供应商

为什么必须一起换：每一层的签字人不同，而签字人只能对自己边界内的事负责。验证这个动作永远发生在接收方的边界上——他布得下测点的地方、他控得住的工况。够不着的量，他签的字没有意义。

⇒ 由此得到一条可以当场执行的判据：判断一条需求是不是写在了错的层，只要看它的主语和测点在不在同一层。"电芯不超 X ℃"这句话的主语是电芯、测点在电芯内部，把它抄进冷板 CTS，签字人换成了冷板供应商，而主语和测点还停在整车层——三格对不上，这条就是写错了层，⛔ 不许下发。要下发，必须先把它改写成冷板边界上的五个量：进口温度、流量、压降、温差均匀性、贴合面的接触热阻上限。⚠ 温差均匀性这一条最常被漏，而它漏得有结构性原因（第 4 讲 4.1 说清），⛔ 不是可以省的一条。

颗粒度是逐级变长的：同一条整车目标，VTS 上通常是一句话，SSTS 上展开成三五条，CTS 上展开成十余条。⛔ 具体条数随架构与部件数变化，⛔ 不是可以照抄的指标——这里要记的只是"往下一级，条数会涨一个档"这件事本身，它决定了你排评审工作量时的量级。

最隐蔽的一种错法：同名不同界。两层上用了同一个量名，指的却是不同边界上的值。典型是"进水温度"——在 SSTS 上它常指冷源出口的温度，在 CTS 上它指冷板进口的温度，中间隔着一段 ΔT_loop（冷却液回路从冷源出口到冷板进口的温升，单位 K；它的定义与取值口径在第 2 讲 2.1 展开）。两边各自都对，各自都能测，拼起来却差了一段温升，而这段温升在任何一层的文件里都没有名字。⇒ 处置：凡在两层上重名的量，必须在下发文件里写出它的测点断面，写不出断面的量名一律当作两个不同的量对待。

今天就能用的一件事：拿你手上任何一条需求，填这三格——主语是谁 / 测点在哪一层 / 谁签字。三格同层，它写对了层；不同层，它需要再翻译一次才能下发。

1.2 派生需求与分配需求：差别落在"谁负责论证充分性"

这两个词在需求文件里天天出现，而它们真正的区别不在写法上，在论证责任归谁。

分配需求（allocated）＝上层把一个可加的量按份额摊下来。温度预算里每个环节分到的那一份温差预算 ΔT_i,budget（单位 K，式子在第 2 讲 2.2 给出）就是典型：上层决定谁分多少，下层只负责守住自己那一份。充分性由上层论证——他要证明各份额加起来确实够，核法是核加和。

派生需求（derived）＝下层为了实现上层那条要求，自己推导出来的新要求。为了让冷板出口温度不超标，推出"回路流量不得低于某值"，这条流量要求在上层的文件里原本并不存在。充分性由下层论证——他要证明这条新要求确实能支撑上层那条，核法是核模型（用的什么关系式、什么假设、在什么工况下成立）。

为什么必须分开：分配是"拆"，账是守恒的；派生是"推"，链是因果的。两种充分性论证的方法完全不同，一个查加和、一个查模型，交给同一个人用同一种方式审，必然有一种审不出来。

工程量级：一份 SSTS 里派生需求的条数通常多于分配需求——分配的只有那几本预算，派生的随设计方案展开。⛔ 具体比例随方案成熟度变化，⛔ 不是可以照搬的数。

易错点，且后果推迟发作：把派生需求当分配需求写进矩阵，再上溯到某条 VTS。于是"上层摊的"和"下层推的"在追溯图上长得一模一样。当下没有任何症状，代价在变更那一刻才出现：改了上层那条要求，分配需求只要重摊份额，而派生需求是否还成立取决于它当初依赖的那个模型——没有标出类型，你无法判断该重摊还是该重推，只能全部重来或者全部不动，两者都是错的。

⇒ 今天就能用的一件事：在需求矩阵上加一列"allocated / derived"，⛔ 不许留空；并规定 derived 的行必须在备注里写出它依赖的那条关系式或模型的出处（哪份仿真报告、哪个版本）。这一列的价值全部在变更影响面分析那一步兑现（第 8 讲）。

1.3 接口需求 IRS：五类，缺一类就有一处翻译损失无人认领

接口需求（IRS）的全集是五类：机械 · 流体 · 电气 · 信号 · 热。⛔ 这五类是并列的必查项，⛔ 没有主次之分——不能因为做的是热管理件就只写热接口。

为什么翻译损失最常发生在接口上：接口是两个边界的交集，而需求文件是按"谁的边界"组织的，交集天然没有归属。接口两侧各有一个签字人，中间那条缝没有。每一类接口的典型损失，形态都是"谁负责"型的问题：

接口类别	典型的翻译损失（都是"谁负责"型问题）
机械	安装点位置与允许公差谁定
流体	接口处的压力与流量基准在哪一侧测
电气	供电电压范围与最坏压降谁承担
信号	报文周期与最坏排队延迟算谁的
热	贴合面的接触热阻由谁保证、压紧力谁提供

工程量级：一个热管理部件与邻件之间通常同时存在 3~5 类接口；冷板几乎五类全有——安装（机械）、进出液（流体）、带加热时的供电与接地（电气）、温度信号（信号）、贴合热（热）。⛔ 具体组合随部件变化，⛔ 不要背这个组合，要背的是"五类逐条过一遍"这个动作。

易错点：只写性能不写接口，两侧各自守着自己那一套假设——结构专业假设压紧力由支架与螺栓提供，冷板供应商假设由冷板自带的弹性结构提供，两份文件各自完整、各自合规，装车前谁也不觉得有问题，而贴合面上的接触热阻在两种假设下不是一个量级。⚠ 这类损失的特征是两边都合规，因此评审抓不到——评审是按文件审的，而问题在两份文件之间。

⇒ 今天就能用的一件事：给每个部件开一张五行的接口表（机械/流体/电气/信号/热），每行只写三格——承诺的是哪一侧 · 在哪个断面上测 · 谁提供这个条件。三格填不满的那一行，就是这个部件此刻最可能出问题的接口。⛔ 接口的具体实现（连接器规格、管接头型式）不在本课，去向 G12-03 执行器硬件接口与电气规格／G7-01 前端冷却模块（FEM/Cooling Module）总体设计 一族。

1.4 需求 owner：没有唯一责任人的那条，一定会掉在两层之间

owner ⛔ 不是"这条是谁写的"，是"这条不达标时由谁负责给出处置方案"的那个人。执笔人可以是流程工程师，处置责任人必须是能调动资源改设计、改分配、或者去谈判的那个人。

为什么这条必须硬性写死：需求分解的失效多发生在层与层的缝隙里，而缝隙正是没有 owner 的地方。性能类需求天然挂在某个系统工程师名下，不会掉；接口类与非性能类需求的 owner 缺失率通常明显高于性能类（⛔ 具体比例是各项目的现状，⛔ 不是可预期的数），而它们恰恰是最容易在两层之间失踪的那些。

⇒ 落地成一条硬规则，⛔ 不留余地：矩阵里 owner 列为空的行，一律不许进入冻结版本。冻结前的检查动作就一个——按 owner 列排序，看空格。

易错点：把 owner 填成一个部门而不是一个人。部门是没有处置能力的——部门收到"这条不达标"的消息之后，第一个动作是开跨部门协调会，而协调会本身不产生处置方案。⇒ 判据：owner 这一格里必须能填进一个可以被直接找到的人；填不进去，说明这条需求的责任还没有真正分配，⛔ 不是格式问题。

1.5 六格自查：一条需求写得完不完整

把前四节压成一张随手可用的表。⚠ 这张表是本课自建的写作自查表，⛔ 不是任何标准里的条款。

格	问什么	它决定什么
① 主语在哪一层	这条的主语是车、是系统，还是这个零件？	它写在了对的层没有
② 量与单位	量的名字与单位写全了吗？重名的量标了测点断面吗？	同上
③ 工况	在什么条件下测？	它可不可验
④ 测点	测点在谁的边界上、具体哪个断面？	同上
⑤ 判据	过与不过怎么判？	同上
⑥ owner	不达标时谁给处置方案？	它会不会掉地上

三段的分工是清楚的：①② 决定层、③④⑤ 决定可验性、⑥ 决定责任。中间三格在第 8 讲会展开成完整的四要素（工况 · 测点 · 判据 · 验证方法）——这里先用三格版本，因为写需求的当下往往还不知道最终用哪种验证方法，而前三格是当场就能填的。

工程量级：拿这张表过一遍存量 CTS，"工况"与"测点"两格的空缺率通常最高（⛔ 具体比例是各项目现状）。这不是巧合：指标值是双方谈判的焦点，谁都会盯着；工况和测点不影响谈判当下的数字好看不好看，却决定了一年后台架上双方会不会吵起来。

易错点，而且是这张表最常见的死法：把它当成评审清单发给别人用，而写需求的人自己不用。⚠ 这张表的价值全部在写的那一刻——那时候填不出"工况"是因为你自己还没想清楚，这个"填不出来"就是有用的信号；等到评审时再补格子，补出来的只会是好看的空话（"常温工况下""在合适位置测"），格子满了而信息量是零，反而把问题盖住了。

1.6 本讲的边界：讲需求怎么写，⛔ 不讲用什么工具管

本课讲的是需求怎么写、怎么分层、怎么追溯，⛔ 不讲用什么工具管。DOORS / Polarion / Jama 这一类需求管理工具的配置项、基线、变更流程归 M1-04 需求管理与追溯（DOORS 等）；本课凡提到工具，只说"这件事在工具里通常叫什么"，⛔ 不给操作步骤。

理由不是篇幅：工具会换，而分层与追溯的判据不会。把方法绑在工具上，这门课会随工具版本一起过期；而同一套分解方法在不同工具上落地，差异通常集中在追溯链的命名上（satisfies / derives / verifies 一类的关系词），⛔ 具体名称各工具不同，值得记的是这几种关系分别对应本讲的哪一类需求（上溯、派生、验证），⛔ 不是某个工具的字段名。

易错点：把"在工具里建了追溯链"当成"追溯做完了"。链建了而验证条目没挂上去，需求覆盖率的分子照样是空的——工具只会告诉你链是通的，⛔ 不会告诉你链的末端有没有一条已经通过的验证。覆盖率的分子分母口径与它在门禁上怎么报，见第 8 讲 8.4。

本讲小结：三层规范是三种语言，往下一级时主语、量、测点、签字人一起换——判一条需求写没写错层，只看主语与测点在不在同一层；最隐蔽的错法是同名不同界（"进水温度"在两层上差着一段 ΔT_loop），凡重名的量必须写出测点断面。分配是拆（核加和，上层论证）、派生是推（核模型，下层论证），矩阵上必须标类型，⛔ 不许留空——它的价值在变更那一刻兑现。接口是五类：机械 · 流体 · 电气 · 信号 · 热，每一类的典型损失都是"谁负责"型问题，且这类损失的特征是两边都合规，评审抓不到，只能靠逐条过五行接口表。owner 是处置责任人⛔ 不是执笔人，⛔ 不许填部门，空 owner 的行一律不许进冻结版本。最后带走那张六格自查表——①② 判层、③④⑤ 判可验性、⑥ 判责任，而它必须在写的那一刻用，事后补格子只会补出好看的空话。