N5-02 软件定义热管理与整车 OTA 演进

项	内容
课程代码	N5-02
板块 / 模块	N 前沿与新技术 / N5 集成化与软件定义
难度	L3 专家
建议学时	3.0 小时（5 讲 ＋ 1 次服务化改造与实时性判断实操）
适合对象	系统架构、控制／软件工程师；做整车 E/E 架构规划、热管理域控软件的岗位（选修）
前置	K2-01 热管理控制器（域控/ECU）硬件架构 热管理控制器（域控／ECU）硬件架构 · K7-02 软件定义热管理与 OTA 迭代 软件定义热管理与 OTA 迭代
本讲义定位	讲清一件事：热管理软件被电子电气架构的演进重新定义之后，工程上到底有哪些东西真的变了、哪些一动没动。⛔ 本课不是一门 OTA 发布流程课（那是 K7-02 软件定义热管理与 OTA 迭代），也不是一门实时系统课（那是 K4-01 热管理嵌入式软件架构与 AUTOSAR 基础）——本课只取这两门的结论，讲它们在架构层与产品定义层的后果

---

按任务导航

你手上的事	直接看	还要配
参加下一代整车电子电气架构评审，要替热管理提要求	第 1 讲 1.5：架构评审上热管理必须提的三条要求（★ 本课归纳），每条附「不提的后果」	第 2 讲 2.7：硬实时域划分清单——那是三条要求里最容易被砍掉的一条
判「热管理域控这块板子下一代还保不保得住」	第 1 讲 1.2：三种宿命与它们各自的判据（安全等级 · 时序 · 接口与线束拓扑）	第 1 讲 1.4：区域控制器改变的首先是线束与供电，⛔ 不是算力
有人要求把热管理任务整体塞进中央计算平台	第 2 讲 2.3：两笔账（资源账与时间账）在架构层只取一条结论；2.4：为什么单核那条判据在这里出了射程	第 2 讲 2.2：热管理任务的三档时间尺度表——⛔ 别把热管理整体当「慢任务」
要写一份「温度控制服务」的对外接口	第 2 讲 2.5：接口五问（谁提供 · 谁能调 · 语义是请求还是命令 · 仲裁落在哪一层 · 降级时谁说了算）	第 2 讲 2.6：服务化最常见的事故形态——仲裁责任被稀释掉
市场或产品提了一个 Features-on-demand 的想法，要判值不值得做	第 4 讲 4.3：四问判据（★ 本课归纳），四个出口	第 4 讲 4.1：物理天花板 P_available；4.4：为什么维护成本是长尾
有人说「这个能力以后 OTA 再给」，要判这句话成不成立	第 4 讲 4.2：软件能撑开的空间只来自三处，每一处各有自己的天花板	第 3 讲 3.1：软件冻结点消失了，而硬件冻结点一动没动
谈下一代供应商合同，要定交付物形态与权限等级	第 5 讲 5.1：交付物形态谱（整套总成 → 裸执行器 ＋ 授权软件）；5.2：三样兑现物	合同附件与验证计划怎么写 ⇒ K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署；权属、许可范围与终止后权利 ⇒ M5-05 合作开发与供应关系中的 IP 权属：技术协议 IP 条款、职务发明与商业秘密保护
被问「软件发布后还会变，型式认证怎么覆盖」	第 5 讲 5.4：本课只到问题提出与架构影响为止	准入与备案的完整答案 ⇒ M4-08 车用软件更新的准入与合规（R155/R156·GB 44495/44496·OTA 备案与召回）；硬件与过程变更侧的再认证判定 ⇒ M4-06 热管理强检项的认证与送检执行实务：准入链时序、送检状态冻结、检测机构与失败返工

⛔ 本课不覆盖——【栏一 · 不讲哪些题目】一次 OTA 怎么安全发布（权限档、灰度序列、回滚门限、证据方案、刷写期间的热安全前置条件）⇒ K7-02 软件定义热管理与 OTA 迭代，本课设它为前置，一句不重讲；嵌入式软件架构与实时分析本体（任务与中断怎么建模、响应时间分析怎么迭代、优先级反转与资源机制）⇒ K4-01 热管理嵌入式软件架构与 AUTOSAR 基础，本课只取它的结论；控制器硬件本体（芯片选型、供电、看门狗、驱动级与功能安全硬件度量）⇒ K2-01 热管理控制器（域控/ECU）硬件架构；控制算法本体（PID／前馈／增益调度、模式仲裁）⇒ K3-05 PID/前馈/增益调度控制实战 与 K3-01 整车热管理控制策略总览与模式管理；预测性热管理的算法与数据链 ⇒ K7-01 预测性热管理（导航/云端/驾驶意图协同）；数据驱动的自学习控制 ⇒ K7-03 数据驱动的能效自学习控制；车队数据回流的车端实现（信号表、事件抓帧、带宽与存储预算）⇒ K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算；标定量规格与下线／售后标定工位 ⇒ K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量 与 K6-09 产线下线与售后标定：工位项清单、配置写入与学习值管理；合同层 IP 权属条款 ⇒ M5-05 合作开发与供应关系中的 IP 权属：技术协议 IP 条款、职务发明与商业秘密保护；准入、备案与再认证判定 ⇒ M4-08 车用软件更新的准入与合规（R155/R156·GB 44495/44496·OTA 备案与召回） 与 M4-06 热管理强检项的认证与送检执行实务：准入链时序、送检状态冻结、检测机构与失败返工。

【栏二 · ⛔ 真正不给的数】① 标准条款的内容与限值：软件升级监管与软件更新工程这几份标准（对口件见第 5 讲 5.4）的条款文本、审查项、证书形态与时限——本课只写它管什么与去向，版次一律写「以现行目录为准，引用前须核」，⛔ 不复述条款；② 本项目自己的平台参数：中央计算平台上分给热管理服务的算力份额与内存带宽预算、各分区的时间预算、本平台各任务的执行时间与最坏响应时间、看门狗与降级门限——这些由本项目的软件平台团队与整车架构给出，本课给的是该问哪几个问题、答案填在哪一栏；③ 商业与法务口径：Features-on-demand 的定价、订阅／买断条款、区域差异、算法授权的许可费与终止后权利——各家不同且随法域变，⇒ M5-05 合作开发与供应关系中的 IP 权属：技术协议 IP 条款、职务发明与商业秘密保护 与本站供应商黄页。

⚠ 平台相关量⛔ 不在栏二：热管理各类闭环的控制周期、冷却液回路与座舱环的热惯性时间常数、电机电流环的执行周期这几项，本课在正文里给典型区间 ＋ 常见值锚点 ＋ 免责句 ＋ 拿到它的路，⛔ 不拿「取决于平台」六个字混过去。

---

引言：被重新定义的不是热管理，是热管理软件的住址、邻居和房东

先看两个现场。

第一个在架构评审室。某平台做下一代电子电气架构规划，会上的结论是「热管理域控制器取消，逻辑并入中央计算平台，原来那块板子退化为区域控制器上的一组执行器接口」。热管理这边当场没有反对——理由听起来也充分：热管理的闭环本来就慢，几百毫秒到几秒一拍，比底盘和智驾宽松得多，共享算力不会有问题。一年后集成测试出问题：某些工况下，压缩机排气温度保护的响应比台架上慢了一截，现象是偶发、复现不了、每次都在整车其他功能忙的时候出现。回头查，那条闭环被排在一个和座舱应用共享的分区里，而分区预算是按平均负载算的。

第二个在产品定义会上。一份规划书写着：「预处理速度、多区独立温控作为可远程配置的能力选项，后续通过 OTA 交付」。工程侧签了字。到了要交付那一版的时候，事情卡在一个谁都没算过的地方——把预处理时间从常规档缩短到宣传的那个档，需要的制冷／制热功率超过了这台车压缩机排量与换热面积能给的上限。软件已经写好了，物理给不出来。

第一反应通常是「实时性没评估到位」和「市场承诺太激进」，处置是补一轮压力测试、把宣传口径改回来。两个都不是根因。第一件是把「热管理闭环慢」这个整体印象套到了一条本来就不慢、而且安全相关的分支上——热管理任务不是一档，是三档；第二件是把「软件可迭代」误读成「能力可增长」，而能力的上限从来卡在硬件那一侧。

这两件事都不是执行层面的疏忽，它们是同一场架构迁移的两个副产品。本课五讲，围着下面两根钉子转。

钉子①：热管理软件搬了家，它交易的不是一块板子，是三样确定性。当热管理逻辑从一颗自己独占的微控制器搬进一个共享算力平台，下面三件同时改变，⛔ 且没有一件能靠「多写点代码」补回来——

• 时间的确定性从「独占」变成「被分配」：以前这颗芯片上只有热管理任务，最坏情况是自己算给自己听；现在你的最坏情况取决于邻居和分配方案，而两者都不归你管；
• 失效边界从「一块板子」变成「一个分区」：以前域控死了就是热管理失效，边界清清楚楚；现在你要回答的是「宿主平台重启时，谁在管热」——这个问题在旧架构里根本不存在；
• 责任边界从「一份技术协议」变成「一组接口契约」：以前一份总成技术协议就把功能、性能与验证包住了；现在功能是软件、执行器是硬件、平台是第三方，责任被拆成三份，而拆开的地方就是事故长出来的地方。

钉子②：软件定义的是「怎么用」，⛔ 不是「有多少」。一次 OTA 能改的是控制律、门限、协同策略、人机界面与商业配置，它改不了压缩机的排量、换热器的面积、电池的化学体系与线束的载流能力。所以任何一句「这个能力以后软件给」都必须先过一道判据：它要的那份能力，硬件此刻在不在手上？在，才是软件问题；不在，那是一次硬件改款，⛔ 不是一次发布。

本课的讲法是：第 1 讲把热管理在架构演进线上的位置迁移讲清，并给出「域控还保不保得住」的判据；第 2 讲是本课最工程的一讲——搬进共享算力平台之后，确定性怎么保、服务接口怎么写；第 3 讲讲迭代节奏本身如何改写产品定义；第 4 讲给出取舍框架，把「值不值得做」变成可以在会上走完的四问；第 5 讲讲这一步演进对产业分工、算法资产与型式认证的连锁影响。

⚠ 一条贯穿全课的口径声明，请先读完再往下走。本课是一门架构与决策课，不是一门数值课。全课出现的可复算数字只有一类——速率单调可调度性上界那条数学结果曲线（第 2 讲 2.3），它由 n(2^(1/n) − 1) 直接算出，可自行复核。除此之外，凡涉及具体取值的地方一律走两条路：属于平台相关量的（控制周期、热惯性时间常数、电流环执行周期），给区间、锚点、免责句与拿到它的路；属于本项目自己的预算与门限的（分区时间预算、算力份额、最坏响应时间、降级门限），本课一个数都不给，只给该问的问题与该填的栏。⛔ 请不要从本课取任何可以直接填进设计文件的数。

---

第 1 讲　位置迁移：热管理的算力和逻辑，挪了几次窝

1.1 演进线上有四个落脚点，热管理每次挪窝挪的是不同的东西

整车电子电气架构的演进线，行业里通常按这四个阶段讲。要紧的不是阶段本身，而是热管理在每个阶段里被挪走的是什么——四次挪窝挪的东西完全不同，把它们混成一句「越来越集中」，后面所有判断都会跟着糊掉。

阶段	形态	热管理落在哪	这一步真正挪走的是什么
① 分布式	每个功能一颗电子控制单元，靠总线交换信号	空调控制器、发动机冷却由动力控制单元兼管、电池热管理在电池管理系统里，互不相识	⛔ 什么都没挪。这一阶段的问题不是算力，是没有一个地方能看见整车的热
② 功能域控制器	按功能域合并：动力域、底盘域、车身域、座舱域	出现独立的热管理域控制器，或并入动力域／车身域	挪走的是仲裁权：整车热请求第一次有了单一的收口点（清册与仲裁结构 ⇒ K3-01 整车热管理控制策略总览与模式管理）
③ 中央计算 ＋ 区域控制器	一到三颗高算力中央计算单元，配若干按物理位置划分的区域控制器	逻辑并入中央计算成为一个软件服务；就近的阀、泵、风扇挂在区域控制器上	挪走的是算力的所有权和线束的拓扑。★ 这两件是不同的事，1.4 单独讲
④ 车云协同的延伸	车端服务与云端能力配合，部分推理与标定在云侧	预测与自学习类能力的一部分在云侧（⇒ K7-01 预测性热管理（导航/云端/驾驶意图协同）／K7-03 数据驱动的能效自学习控制）	挪走的是数据与模型的更新节奏；⚠ 实时闭环仍然只能在车上，这一条本课第 2 讲会钉死

⇒ 这张表要读出的是：①→② 挪的是仲裁权，②→③ 挪的是算力所有权与线束拓扑，③→④ 挪的是更新节奏。三次挪的是三样东西，各有各的代价。工程上最容易出事的是第二次，因为它同时动了两样，而讨论时人们通常只看见其中一样。

1.2 热管理域控的三种宿命，判据只有三条

「下一代还有没有热管理域控制器」这个问题，在评审桌上常被当成一个立场问题（集中派 vs 保守派）。它不是立场问题，它有判据。三种可能的落点是：

• 甲 · 保留独立域控：仍是一块自己的板子，跑自己的操作系统，对外只暴露接口；
• 乙 · 并入区域控制器：逻辑跟着执行器就近落到某个区域控制器上，一块板子上同时跑热管理与别的就近功能；
• 丙 · 并入中央计算成为软件服务：逻辑上移到中央计算平台，区域控制器只做输入输出与驱动。

判据三条，⛔ 缺一条都会把结论判反（★ 本课归纳，⛔ 不是任何标准的条文）：

判据一 · 这条功能链上最高的安全完整性等级是多少，且它能不能被隔离出来。热管理里最高的那一档通常不是舒适性功能，而是热失控相关的联锁与抑制（机理与处置 ⇒ D5-01 热失控热扩散抑制（热管理与结构协同）／D5-04 碰撞后电池热管理应急响应）。要问的不是「整个热管理是什么等级」——那个问题没有意义；要问的是「最高等级的那一小段能不能被切出来单独放」。切得出来，甲乙丙三条路都开着；切不出来，整块逻辑就被最高等级绑住，丙的代价陡增。

判据二 · 最快的那条闭环有多快，以及它容不容忍通信抖动。热管理不是一档慢任务（2.2 有完整的三档表）。判据的形式是一句可以当场问出口的话：把这条闭环的传感器读数和执行器指令放到网络上跑一趟，它还成立吗？——网络往返的时间与抖动，相对这条环的控制周期是几个百分点还是几成？是几成，这条环就不能跨网络拆开，它必须和它的执行器待在一起。

判据三 · 接口数量与线束拓扑的账算不算得过来。热管理是整车里低速离散接口最多的域之一：十几到几十路的阀、泵、风扇、加热器、温度与压力传感器，且它们在车上分散在前中后三处。这一条判的不是算力，是铜。⇒ 1.4 单独讲。

三条判据交叉之后的落点，通常是这样的形态：

落点	什么时候成立	它的代价
甲 保留独立域控	安全相关段切不出来 ＋ 快档闭环多 ＋ 接口高度集中在一处（典型是集成热管理模块把阀泵集中在一块 ⇒ G8-01 集成热管理模块（TMM/阀岛/超级水壶）架构）	与整车「减少控制器数量」的目标冲突，通常要在成本评审上单独辩护
乙 并入区域控制器	接口分散、安全相关段可切、快档闭环与执行器同处一区	逻辑被物理位置切开：一条环的传感器在前区、执行器在后区时，这条环被迫跨网络
丙 并入中央计算	安全相关段可切出并单独承载 ＋ 快档闭环少或可下沉到执行器本地 ＋ 接口本来就要走区域控制器	时间确定性变成别人分配给你的东西；⇒ 第 2 讲整讲在处理这个代价

⚠ 现实里最常见的是混合形态：安全联锁与最快的那几条环留在本地（甲或乙），其余上移（丙）。⇒ 所以 1.2 这个问题的正确答案形态不是三选一，而是一张划线图——哪一段留下、哪一段上移、线画在哪。这张线怎么画，就是 1.3。

1.3 「硬件降智」到底降到哪一层：可迁与不可迁的分界线

「阀、泵、压缩机从各自带控制逻辑退化为纯执行器」——这句话在演进叙事里出现得很频繁，而它作为整句是错的。真实发生的事情是：执行器里的逻辑分成两层，上面那层迁走，下面那层一寸也不能动。

把一个电子水泵拆开看，它里面原本装着的东西，按周期由慢到快排：

层	里面是什么	典型执行周期	能不能迁到中央计算
④ 策略层	什么时候开、开多大、跟谁配合、怎么省电	与所属闭环同级（见 2.2）	能，而且这一层正是「软件定义」真正搬走的那一层
③ 闭环层	转速环／流量环，把策略层给的目标做出来	约 1~10 ms	看情况：判据就是 1.2 的判据二，取决于网络抖动占它周期的比例
② 电流环与换向	让电机按指令出力矩	与开关频率同级，典型 5~20 kHz（对应约 50~200 μs 一拍），常见锚点约 10 kHz（100 μs）	不能。这个周期比任何车载网络的往返都短一到两个数量级
① 本地保护	过流、堵转、过温、退磁保护	与②同级或更快，部分由硬件电路直接完成	不能，且这一层还必须在通信断掉时独立成立

⚠ 上表中的开关频率区间与锚点是行业典型值，⛔ 不是验收依据；具体值随电机形式、母线电压、功率器件与噪声要求变化很大，须以本项目的电驱／泵驱规格与实测确认。→ 拿到它的路：向执行器供应商索取该型号的开关频率与本地保护清单，或在实件上用示波器测相电流波形的载频。

⇒ 于是分界线可以写成一句可以在评审上当场用的判据（★ 本课归纳）：

一层逻辑可以迁走，当且仅当它同时满足两条：① 它的周期比通信往返与抖动之和大出足够的余量；② 通信断掉时，它不动作也不会造成不可接受的后果。两条只满足一条的，⛔ 不能迁。

第②条常被漏掉，而它正是「降智」这个词最危险的地方。过流保护不是一段逻辑，它是这个执行器活下去的条件。把它迁到中央计算，等于把一个执行器的生存条件挂到了一条会丢包、会重启、会被优先级抢占的链路上。⇒ 所以工程上真实的图景是：执行器交出了策略，保住了保护。

⇒ 这条分界线还有一个反方向的用处：它同时说明了「纯执行器」这个词在采购上是个陷阱。一个真正的「纯执行器」（连本地保护都没有）会把保护责任整体推给上游，而上游此刻并不具备那个响应速度。⇒ 谈交付形态时（第 5 讲 5.1），「裸执行器」必须写清它裸到哪一层——是交出了策略层，还是连本地保护也交出来了。这两者在报价单上可能只差一行字，在责任上差一个数量级。

1.4 区域控制器改变的首先是线束与供电，⛔ 不是算力

第 1 讲最容易被跳过、而在热管理上代价最大的一节。

区域控制器的划分依据是物理位置，不是功能。它带来的直接好处是线束：原来从车头拉到车尾的一根根信号线，变成「就近进区域控制器、区域之间走一条高速干线」。对整车来说这是减重、减成本、减装配工时；⚠ 对热管理来说，它同时是一次拓扑重排。

热管理受到的三处具体影响：

1. 一条闭环可能被物理位置切开。典型例子：电池包的温度传感器在中后部、而这条回路的比例阀和水泵挂在前舱的集成模块上。在旧架构里它们同接一块热管理域控；在区域架构里它们分属两个区域控制器，这条环从此每一拍都要过一次网络。⇒ 这件事必须在区域划分阶段就提出来，⛔ 不能等到软件集成时再说——那时候线束已经定版了。
2. 供电分区与热管理的「值守」需求不一致。热管理有一批功能要在整车下电后继续工作（充电中的电池温控、下电后的余热处理、停车状态的座舱预处理）。区域控制器的供电分区若按「行车用电」划分，这批功能会撞上一个尴尬：要么整个区域控制器陪着醒着（能耗），要么这条功能没有执行通路（失能）。⇒ 下电、值守与休眠期能耗预算这条线的属主是 K3-11 热管理域的上下电时序、run-on 编排与休眠期能耗预算，本课只负责把这个问题在区域划分阶段提出来。
3. 诊断与故障定位的路径变长了。一个执行器不动作，原因可能在中央计算的服务、在干线通信、在区域控制器的驱动级、也可能在执行器本身。⇒ 故障树因此多了两层，而这两层的属主分属三个团队。诊断与故障管理的方法本体 ⇒ K5-01 OBD/UDS 诊断与故障码（DTC）设计。

⇒ 本节的可执行动作只有一个：在区域划分方案定稿之前，把热管理每一条闭环的传感器与执行器落在哪个区列成一张表，并把跨区的那几条单独标出来。这张表要在线束定版之前交出去。它不需要任何算力数据，只需要一张位置清单——而它是本讲里唯一一件过了时间点就补不回来的事。

1.5 本讲收口：架构评审上，热管理必须提的三条要求

第 1 讲的产出物是三条要求，⛔ 不是一个结论。三条各自附一句「不提的后果」（★ 本课归纳）：

#	要求	不提的后果
①	把热管理的安全相关段单独划出来，并要求它有独立于宿主平台的承载与失效表现	这一段跟着舒适性功能一起被排进共享分区，事故形态就是引言里那个「偶发、复现不了」
②	提交热管理的三档任务时间尺度表（2.2 给形状），并要求快档与安全分支单独核算	「热管理慢」这个整体印象被写进平台假设，之后所有分区预算都建在它上面
③	在区域划分定稿前交出闭环的位置清单，标出跨区的那几条（1.4）	线束定版后闭环被物理切开，只能靠加通信速率或改控制律去补，两者都比改划分贵

⚠ 三条里只有 ③ 有硬时间点（线束定版）。①② 晚提还有救，③ 晚提就没救了——这是本讲唯一一条不可逆的。