1. 前言

在很多工程项目中，温度测量并不是“把传感器贴上去，读到的值就是真实温度”这么简单。

尤其在以下场景中，温度测量往往会出现明显偏差：

• 传感器无法放在真实被测点内部
• 传感器安装位置与目标测温点存在结构距离
• 系统中存在发热器件
• 多个热源同时工作，且热影响会相互耦合

这类问题在电源系统、液冷系统、逆变器、充电机、车载电子设备、工业控制设备中都非常常见。

因此，本文不只讨论某一个项目，而是总结一套通用的温度校准设计方法，并以“水道温度测量”为例进行说明。

2. 什么是“通用温度校准问题”

从工程角度看，很多温度测量问题都可以抽象成下面这个模型：

传感器读数 = 目标真实温度 + 静态误差 + 工作热误差 + 耦合误差

其中：

• 目标真实温度
  • 真正想测的温度
• 静态误差
  • 传感器安装偏差
  • ADC/查表误差
  • 静态热阻路径偏差
• 工作热误差
  • 某个模块工作时给传感器带来的额外温升
• 耦合误差
  • 多个模块同时工作时，单机误差不能完全相加而产生的额外残差

如果把问题拆开来看，这其实不是“一个校准问题”，而是“多层误差叠加问题”。

3. 以水道测温为例，问题到底出在哪

以水道测温为例，真实目标是：

• 真实水道温度

但实际安装时，经常会遇到以下限制：

• 传感器不能直接伸入水道内部
• 只能安装在水道附近的金属结构或外壳上
• 周围存在 DCDC、OBC、功率器件、电感、散热器等热源

于是传感器看到的就不是纯粹的水道温度，而更像：

传感器温度 = 水道真实温度 + 安装偏差 + 周边模块发热影响

如果系统中只有一个热源，问题还相对简单。

如果系统中有两个甚至更多热源，例如：

• DCDC 发热
• OBC 发热

那么传感器位置就会同时受到多个热源影响，情况进一步复杂。

这时若不做校准，系统会出现：

• 水温显示偏高或偏低
• 温控策略不准确
• 热保护阈值误判
• 控制策略提前触发或延后触发

4. 很多人一开始会怎么做

很多项目初期通常会选择以下做法：

4.1 直接用原始读数

这是最简单的方式，但也是误差最大的方式。

适合功能联调早期，不适合量产或高精度控制。

4.2 只做一次静态校准

例如在设备不工作时，做一组静态标定，拟合一个公式：

真实温度 = f(原始温度)

这一步是必要的，但还不够。

因为它只能解决静态偏差，解决不了设备工作时的附加热影响。

4.3 把所有工况拟合成一个大公式

也有人会尝试直接拟合一个从原始温度到真实温度的总公式。

这个思路表面上简单，实际容易遇到三个问题：

• 物理意义不清晰
• 不利于定位误差来源
• 以后某一部分变化时，整个模型都要重做

因此，这种“大一统单公式”通常不是长期最优方案。

5. 更合理的思路：分层校准

对于通用温度校准问题，更推荐采用分层设计。

核心思想是：

• 先解决静态误差
• 再解决单个热源引入的误差
• 最后解决多个热源同时工作时的耦合误差

如果继续以水道测温为例，推荐的总体框架可以写成：

真实水道温度
  = 静态校准后的温度
  - 热源 A 单机热补偿
  - 热源 B 单机热补偿
  - 联合耦合修正

这是一套非常通用的思路，不只适用于水道，也适用于：

• 壳体温度估算
• PCB 热点温度估算
• 冷板温度估算
• 功率模块邻近传感器的真实温度补偿

6. 第一层：静态校准

6.1 目标

静态校准解决的是：

• 没有外部热源干扰时
• 传感器原始温度和真实目标温度之间的固有偏差

以水道为例：

• DCDC 不工作
• OBC 不工作
• 冷却条件稳定

此时测一组“原始温度”和“真实水道温度”之间的对应关系，就可以建立静态模型。

6.2 为什么静态层必须先做

因为后面的热补偿层，最好都建立在一个相对稳定的基准之上。

如果静态误差本身都没有被修掉，那么后面热补偿模型里会混进很多本不属于热误差的内容，结果会越来越乱。

6.3 静态模型怎么选

一般建议比较下面三类：

• 一次函数
• 二次函数
• 分段一次函数

从工程经验看：

• 一次函数最简单，但精度未必够
• 二次函数更平滑，但边界外推要小心
• 分段一次函数通常是工程上最稳妥的折中

尤其在温区跨度比较大时，分段一次往往更容易兼顾精度和可控性。

7. 第二层：单机热补偿

7.1 什么叫单机热补偿

单机热补偿指的是：

• 只让某一个热源模块工作
• 测量其对温度传感器带来的额外热偏差

以水道测温为例，可以定义：

单机热补偿 = 静态校准后温度 - 真实水道温度

这个量表示：

• 在当前热源工作时
• 传感器位置比真实水道多热了多少

7.2 为什么要按热源分别建模

因为不同热源对传感器的影响路径通常不同：

• 距离不同
• 导热路径不同
• 发热位置不同
• 发热强度随功率变化规律不同

所以多个热源最好分别建立单机模型，而不是混在一起。

7.3 为什么要按功率节点建模

热补偿几乎一定和功率有关。

因此更推荐这样做：

• 在若干典型功率点采数据
• 每个功率点单独建一个温度补偿模型
• 在线时根据实时功率做插值

例如：

• 0kW
• 1kW
• 2kW
• 3.3kW
• 5kW

不要求功率点等差，也不要求每个点样本数相同，只要有明确功率节点即可。

8. 第三层：联合耦合修正

8.1 为什么单机补偿直接相加通常还不够

在实际系统中，多个热源同时工作时，往往会出现下面的情况：

• 模块 A 和模块 B 的热量在结构中发生耦合
• 热量传递路径受到共同散热条件影响
• 某些温区内热偏差并不是单机模型简单线性叠加

这时，即使已经减掉了所有单机热补偿，仍然会剩下一部分误差。

这部分误差就是联合耦合误差。

8.2 联合修正项怎么理解

可以定义：

联合修正项 = 当前补偿结果 - 真实目标温度

这里的“当前补偿结果”指的是：

• 已经做完静态校准
• 已经减掉所有单机热补偿

剩下的残差，就是联合修正层要处理的内容。

8.3 联合修正层的价值

联合修正层并不是推翻前面的模型，而是在前面已经做得不错的基础上，把最后剩下的系统性误差单独拿出来建模。

这层通常能带来两个收益：

• 明显降低联合工况下的最终误差
• 保留单机模型的可解释性和可维护性

9. 推荐的建模方法

对于这种通用温度校准问题，推荐的建模方式是：

9.1 温度维度

每个节点内部优先尝试：

• 一次
• 二次
• 分段一次

如果分段一次明显更优，优先采用分段一次。

9.2 功率维度

功率维度不要硬切换，建议：

• 在相邻功率节点之间线性插值

这样可以保证：

• 功率变化时输出连续
• 避免补偿量跳变

9.3 多热源联合维度

如果有两个热源，可以推荐：

• 先固定热源 A 的几个功率层
• 在每个热源 A 功率层内部，对热源 B 做功率插值
• 再在热源 A 的相邻层之间插值

也就是先一维插值，再另一维插值。

这种做法比直接做一个复杂二维全局公式更适合工程实现。

10. 推荐的代码组织方式

为了让方案真正可落地，建议在嵌入式代码里采用下面的结构：

10.1 参数层

使用宏定义保存：

• 功率范围
• 静态模型参数
• 占位功率值

10.2 数据结构层

使用统一结构体保存节点参数：

• 功率值
• 分段点
• 左右两段的线性参数

10.3 算法层

将计算逻辑拆成几个通用函数：

• 原始分段一次求值函数
• 静态校准函数
• 单机节点求值函数
• 单机功率插值函数
• 联合修正插值函数

10.4 主流程层

最终在线计算链路保持清晰：

原始温度
  -> 静态校准
  -> 单机热补偿
  -> 联合修正
  -> 最终输出

11. 如果数据不完整怎么办

很多真实项目中，联合工况不可能全部测满。

这时不必因为数据不完整就放弃整体方案。

推荐做法是：

• 有测量数据的节点直接建模
• 缺失节点用相邻节点插值近似
• 在设计说明里明确标出：
  • 哪些区域是实测覆盖
  • 哪些区域是插值近似

这比“为了追求完美，什么都不落地”更符合工程实际。

12. 用水道测温再总结一次

如果把这套通用方法落到水道测温上，可以这样理解：

第一步：静态校准

先在设备不工作时，把“原始传感器温度”和“真实水道温度”的关系拟合出来。

第二步：单机热补偿

再分别测：

• 只有 DCDC 工作时，传感器多热了多少
• 只有 OBC 工作时，传感器多热了多少

并建立单机热补偿模型。

第三步：联合修正

最后再测：

• DCDC 和 OBC 同时工作时
• 在已经减去单机热补偿后，还剩多少误差

这部分就是联合耦合修正层。

第四步：在线输出

最终输出的真实水温不再是简单原始值，而是：

真实水道温度
  = 静态校准后的温度
  - DCDC 单机热补偿
  - OBC 单机热补偿
  - 联合耦合修正

13. 这种方法为什么通用

这套方法之所以通用，是因为它没有绑定某个特定产品，而是抓住了温度误差问题的本质：

• 先分离静态误差
• 再分离单机工作热误差
• 最后处理联合耦合误差

只要你的系统同时满足下面几个条件，就可以参考这套方法：

• 传感器不在真实目标点上
• 系统中存在一个或多个发热模块
• 目标是估算更接近真实物理位置的温度

14. 结论

对于通用温度校准问题，更推荐采用“分层补偿”而不是“单公式硬拟合”。

用一句话概括就是：

先做静态校准，再做单机热补偿，最后做联合耦合修正

以水道测温为例，这种方案的优势非常明显：

• 逻辑清楚
• 模型可解释
• 易于维护
• 适合固件落地
• 易于后续扩展

如果你的项目也遇到了“传感器位置受限、周边模块发热导致测温失真”的问题，这套方法通常是一个非常值得优先尝试的通用解决思路。