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

课程代码 B1-02 · 板块 B 整车热管理系统架构 / B1 整车热平衡与需求定义 时长 约 4 小时（5 讲 + 1 次需求分解实操） 适合对象 整车 / 系统热管理工程师与项目负责人；对接供应商、下发技术规范的岗位必修 前置 B1-01 整车热平衡与热负荷谱；A2-02 泵与风机的工作点与特性曲线 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 B1-02 大纲的完整展开版

引言：一句「电芯不超温」，供应商没法验

整车这边写下一条目标：「快充时电芯不超温」。这句话对整车工程师是清楚的，对冷板供应商却是无法验证的——他手里只有一块冷板，没有电芯、没有整车、没有那台快充桩。你让他保证「电芯不超温」，他既测不了电芯温度，也不知道该给多少流量、进口水温设多少，只能拍胸脯或者拒签。

需求分解要解决的，就是这条翻译链：把「电芯不超温」这个整车级结果，一级一级翻译成系统能承诺的参数（chiller 出水温度、回路流量），再翻译成冷板供应商能在自己边界内测出来的参数（进口温度、流量、压降、接触热阻）。翻译对了，供应商拿着 CTS 就能上台架测、能签字承诺；翻译错了，要么整车目标丢在半路，要么零件被逼到工艺极限白花成本。

这条链上有两个最凶的敌人。一是翻译损失——在接口上、在颗粒度切换处，需求会悄悄失真或掉地上。二是裕度加码——每一层工程师都想给自己留点保险，逐层乘起来，最后把零件逼死。这门课就讲怎么把链搭对、把余量摊对、把每条需求都配上一条能验的路。核心判断只有一句：一条需求，如果承接它的那个人在自己的边界内验证不了，它就还没被分解完。

第 1 讲　三层需求体系与接口

需求不是一张扁平的清单，而是一个有层级、有颗粒度、有责任边界的体系。搞不清层级，就会把整车目标原样抄给零件，或者让接口需求无人认领。

1.1 VTS / SSTS / CTS：语言与颗粒度逐级收窄

三层规范说的是同一件事，但用的是三种语言、三种颗粒度：

• VTS（整车技术规范）说的是结果，用的是用户和法规的语言：快充多少分钟、冬季续航打折不超多少、电芯不超温、噪声不超标。它的边界是整车，不关心内部怎么实现。
• SSTS（系统技术规范）说的是子系统的承诺参数，用的是系统工程师的语言：热管理系统要把 chiller 出水温度控制到多少、电池回路要给多少流量、泵要提供多少扬程。它把整车目标翻译成某个子系统能负责的东西。
• CTS（零部件技术规范）说的是零件端口上的可测量，用的是供应商能签字的语言：冷板进口温度多少、流量多少、压降不超多少、接触热阻不超多少。它的边界缩到零件的进出口。

三层之间，颗粒度递减、边界收窄、语言从「结果」变成「可测参数」。这个方向是有道理的：越往下，越具体、越可测、越接近某个人能在自己的台架上验证并签字承诺的东西。分解做得好不好，第一眼就看语言变没变——如果 CTS 里还写着整车级的结果语言（「电芯不超温」），说明这一级根本没翻译，只是把上一级抄下来了。

1.2 派生需求与分配需求：谁负责论证充分性

往下传的需求有两种，责任人完全不同，混淆是评审时的常见病：

• 分配需求（allocated）：把一个整车指标切成几份，分给下层的若干环节，各份加起来要覆盖整体。温度预算的分配就是典型——总的可用温差切成前端、回路、冷板、TIM、电芯几份。论证责任在分配者：你得证明「各份加起来确实覆盖了整体、没有漏账」。
• 派生需求（derived）：下层为了实现上层要求，自己冒出来的新需求，上层没写、但物理上绕不过去。比如冷板必须有排气口（否则积气恶化换热）、TIM 必须有一个装配压力窗口（否则接触热阻不可控）。论证责任在派生者：你得证明「这条需求是必要的，而且这么定是充分的」。

为什么要分清？因为两类需求的「充分性由谁论证」不一样。分配需求的坑是加起来不够（分配者没算总账），派生需求的坑是凭空多出或论证不足（派生者没说清为什么必须、为什么这个值够）。评审时对着每条需求先问一句「这是分配来的还是派生出来的」，才能找对该质询的人。

1.3 接口需求 IRS：翻译损失最常发生在接口上

两个零件各自满足自己的 CTS，装到一起却不工作——问题几乎总是出在接口。接口需求（IRS）要管五类接口：

• 机械接口：安装点、法兰、螺栓孔位、包络空间；
• 流体接口：管径、接头形式、密封面、流量与压力口径；
• 电气接口：供电电压、电流、连接器；
• 信号接口：通信协议、信号定义、时序；
• 热接口：接触面、平面度、装配压力、TIM 规格。

翻译损失最常发生在这里，机理是：接口是两个零件共同决定的，而每个零件的 CTS 只写自己那一半，中间那道缝很容易两边都以为对方负责。热接口尤其隐蔽——TIM 的接触热阻，取决于冷板的平面度、电芯壳体的平面度、以及两者之间的装配压力，三者分属不同零件甚至不同供应商。这条接触热阻该写进谁的 CTS？如果谁都不认领，它就会在装配后以「实测温度比仿真高一截」的形式冒出来，而那时谁都甩锅。接口需求必须单独成条、明确两侧各自的责任，不能指望它藏在两个零件的 CTS 里自动对齐。

1.4 需求 owner：没有唯一责任人，需求就掉地上

前面三节其实都指向同一件事：每条需求都要有唯一的 owner。一条需求如果没有明确的责任人——负责论证它、负责下沉它、负责验证它——它就会掉进两层之间的真空地带。

最容易无主的正是接口需求，因为它天然骑在两个团队的边界上。系统团队觉得那是零件团队的事，零件团队觉得那是系统团队的接口定义。可操作的做法很直接：需求评审时，逐条问两个问题——「这条谁负责论证它充分」「这条谁负责验证它满足」。任何一条答不上唯一名字的，就是一条迟早要出事的需求。owner 制度不是管理形式主义，它是防止需求掉地上的唯一机制。

本讲小结：三层规范语言与颗粒度逐级收窄（结果 → 承诺参数 → 端口可测量）；分配需求看总账、派生需求看必要充分；翻译损失集中在五类接口尤其热接口；每条需求必须有唯一 owner，否则接口需求必然掉地上。