J7-04 整车热管理数字孪生与实时模型

项	内容
课程代码	J7-04
所属板块	J 仿真分析 CAE ／ J7 数字化仿真方法
难度	L3 专家
建议学时	3.5 小时
适合对象	高级仿真工程师、智能热管理架构工程师；数字孪生方向必修，其余选修
前置课程	J7-02《模型降阶（ROM）与控制导向建模》；K3-10《热管理在线状态与负荷估计：观测器整定、软测量置信度与退出条件》
本讲义定位	讲孪生模型侧的分层架构、实时模型底座、融合架构与漂移在线修正。⛔ 不讲估计器方法本体（归 K3-10）、⛔ 不讲降阶方法本体（归 J7-02）、⛔ 不讲在线寻优的应用策略、⛔ 不讲电池那一路的专例实现（归 D1-06）。

---

按任务导航

你手上的事	直接看	还要配
评审一份「数字孪生」方案书，判它到底是哪一级	第 1 讲 1.1：数一数自动数据流的条数与方向	1.2（三件被混当定义的事）· 1.6
定一个新项目的孪生目标该做到哪一级	第 1 讲 1.6：影子级是合格的目标；要做孪生级，写回边是重心	第 2 讲 2.4（写回边的四件）
决定某个状态量该放车端还是云端	第 2 讲 2.3：三条判据逐条打钩 + 冲突处置	2.1 · 2.2
核一个车端孪生模型跑不跑得动	第 3 讲 3.3：t_solve,max ≤ β·Δt_cycle，口径覆盖五段	3.1（ROM 底座）· J7-02 模型降阶（ROM）与控制导向建模
定几个子系统孪生之间的接口	第 3 讲 3.2：要定死的四件 + 代数环怎么断开	3.4（可扩展性）
给一个测不到的量设计融合估计方案	第 4 讲 4.1~4.3：三种「测不到」→ 可观测性闸 → 融合放在哪	4.4（该信谁）· K3-10 热管理在线状态与负荷估计：观测器整定、软测量置信度与退出条件
设计漂移监测与在线修正	第 5 讲 5.2、5.3：三步测法 + 触发—退出表	5.1（e_drift 定义）· 5.4
判孪生输出能不能接进安全相关动作	第 6 讲 6.3：先答三个问题	6.4（四种失效）
排查「同一辆车两边诊断结论对不上」	第 6 讲 6.4 失效三：版本配对校验 + 唯一权威来源	1.4 · 2.4

⛔ 本课不覆盖——两栏，每样带去向：

栏一 · 不讲哪些题目：降阶方法本体、精度验证与两本静态误差账 → J7-02 模型降阶（ROM）与控制导向建模；可观测性判据、估计器结构选型、Q/R 整定、协方差维护与发散防护、置信度状态机的整定 → K3-10 热管理在线状态与负荷估计：观测器整定、软测量置信度与退出条件；参照模型有没有验过（相关性验证） → J7-01 仿真—试验相关性验证（Correlation）；退化趋势判定、剩余寿命外推与服务决策 → K5-05 在役健康度与渐变衰减辨识：从车端信号到服务决策；电池那一路从稀疏测点到包内极值的完整做法 → D1-06 电池热状态在线估计：从稀疏 NTC 到 T_max 与 ΔT_pack；结温那一路的在线观测器全流程 → E2-05 结温估计、热保护与主动降额策略；流量软测量 → G12-01 温度/压力/流量/湿度传感器选型与布置；传感器冗余表决与共模盲区 → K1-03 传感器布置、冗余与信号可靠性；误差带折算成控制约束裕度 → B4-04 整车能量管理与热管理的协同优化；模型预测控制方法本体 → K3-06 模型预测控制（MPC）在热管理中的应用；车联网通信协议与网络安全设计、域控软件架构与任务调度 → 不在本课射程内。

栏二 · ⛔ 真正不给的数：① 漂移触发门限——量纲随被比的量而变，合理值完全取决于误判代价，⛔ 给一个典型值等于给一个会被照抄的错误锚点 → 本课给的是定它的方法（5.3 三步），由本项目自定；② 标准条款的内容与限值——本课引用的 ISO 26262、ISO 23247、FMI/FMU 只写去向、⛔ 不复述条款文字，版次以现行目录为准 → 查现行版原文；③ 任何安全等级判定结论——须基于本项目的相关项定义做危害分析与风险评估 → 贵司功能安全流程；④ 你自己平台的 t_solve、模型阶数、τ_link、算力与内存预算——引言那张表给了典型参考值，⛔ 非验收依据 → 在目标域控与真实链路上实测。

引言

学完这门课，你要能当场答出四件事

第一件，判一个方案处在三级谱系的哪一级，并说得出判据是什么。交付物是一句话加一张数据流向图：这个方案的物理侧与数字侧之间，有几条自动数据流、方向分别是什么。答案只有三选一——数字模型、数字影子、数字孪生。⛔ 不是「像不像孪生」的程度判断，也⛔ 不看它刷新多快、不看它自称什么。

第二件，设计一个整车热管理孪生的车端／云端分层架构。交付物是一张分层图外加一张划分依据表——每一个被放到车端的状态量，都要在表里写清它为什么不能放云端；每一个被放到云端的，写清它为什么不必放车端。⛔ 一张只有方框和箭头、没有划分依据的架构图不算交付物，因为它没有约束过任何一个决策。

第三件，把传感器数据和模型状态融合起来修正模型偏差。交付物是一套融合架构：先过可观测性这道闸，再定模型置信与量测置信怎么加权，最后必须带一条退出判据——残差持续超限或偏离量越界时退回纯量测并标记模型失效。⛔ 少了退出判据的融合方案不是方案，是一个永远不会承认自己错了的东西。

第四件，判一个应用场景该用车端轻量孪生还是云端精细孪生。交付物是按三条判据（时间尺度、安全相关性、算力—带宽预算）逐条过一遍的判定表，而不是「重要的放车端」这种直觉。

两根钉子

第一根：孪生的定义门槛是双向自动数据流，⛔ 不是实时。这句话看起来只是术语较真，实际它改变三处工程决策：① 立项时的目标定位——如果你的目标只是「把车队数据回流上来做健康监测」，那是一个数字影子，它有完整的工程价值，⛔ 不需要为了配得上「孪生」这个名字硬做车端部署；② 验收判据的落点——孪生级方案必须验的是「云端算出的修正量真的自动写回了车端、且写回是可追溯可回退的」，而不是验刷新率；③ 责任边界——一旦存在自动写回，车端软件的配置就会被一个车外的东西改变，这条链路从此落进功能安全与网络安全的射程内，⛔ 不能当成一次普通的数据服务上线。这一根钉子在第 1 讲（谱系）、第 2 讲（数据链路的写回方向）、第 6 讲（安全边界）各落一次。

第二根：孪生交出去的是「值 ＋ 置信度档 ＋ 有效窗口标志」三件套，⛔ 不是一个裸值。这一条不是本课新造的，它是 K3-10 已经写死的估计器交付口径，本课原样沿用并把它抬到孪生这一层——因为孪生比单个估计器多了一样东西：它的输出会同时进入控制、诊断、服务三条下游，而这三条对「不可信」的处置完全不同。⛔ 交一个裸值出去，等于让三条下游各自去猜什么时候不该信它，而它们会猜出三个不一样的答案。这一根钉子在第 4 讲（融合架构的输出格式）、第 5 讲（漂移触发与退出）、第 6 讲（安全相关动作的准入）各落一次。

一句本课最容易被读反的话

「我们的模型在车端跑到了 10 毫秒一拍，所以这是一个真正的数字孪生。」

这句话的现象部分完全没有错——车端 10 毫秒一拍确实是一件很难做到的工程成就，第 3 讲整讲都在讲怎么做到它。危险在「判据选错了对象」这个组合里：刷新率度量的是这个模型跟不跟得上车，而谱系度量的是物理侧与数字侧之间有没有闭合的自动数据流。这是两根完全独立的轴。一个跑在 10 毫秒的车端模型，如果它的参数只在标定阶段被人工写死过一次、运行期没有任何来自实车的自动修正，它在谱系上仍然是数字模型那一级——它甚至连影子都不是，因为影子至少要求实车数据自动流进模型。

说不出「读者会做错的那个具体动作」就不算读反，所以把三个动作写清楚。方向 A（拿刷新率当验收证据）：项目验收时只测了车端单步耗时与丢帧率，全部合格，于是判定孪生功能交付完成；而实车跑了半年之后模型与真车已经差得很远，没有任何一条判据报过警——因为漂移监测这一整层根本没有被要求过。方向 B（拿刷新率当分级门槛，把影子判成不合格）：一个已经稳定回流车队数据、做出了有效健康监测的云端方案，被评审判为「不是真孪生、要重做」，于是团队去补一个没有场景需求的车端实时部署，代价真金白银而收益为零。方向 C（反过来：为凑「实时」标签把离线模型硬塞进车端）：把设计阶段的详细模型直接交叉编译到域控上，实测降频丢步，输出滞后于真实工况，下游拿到的是过时的状态量——这比没有孪生更糟，因为它看起来在工作。

⇒ 由此定下本课的硬口径（本课归纳，⛔ 不是任何标准的原文条款）：判级只看数据流向与自动化程度；实时性是车端闭环这一类场景的附加约束，⛔ 不是任何一级的定义要件；闭环反馈优化是应用层的能力，⛔ 不在本课射程内。全课不许拿刷新率单独当作分级依据；上面那句错话只允许以被点破的错句的身份出现在这里、「典型案例详解」与「常见误区」三处，⛔ 不得以正面表述出现在任何别处。

符号与口径表

⛔ 全课符号一律以本表为准。本表已按前置课程既有记号对齐过，凡与兄弟课同名的量，「口径来源」一栏写明它是沿用还是本课首定。

符号	含义	单位	口径来源与撞名提醒
Δt_cycle	孪生模型自己的执行拍周期——孪生每隔多久推进一步	s	本课口径。⚠ 撞名高危，见下一节跨课对照表：它与 J7-02 的 Δt_target、D1-06 的 Δt_ctrl 不是同义词
t_solve	孪生模型推进一步的求解耗时，一律取最坏值；强调处写 t_solve,max，两者同义	s	沿用 J7-02，口径一字不改
RTF_max	t_solve,max ÷ Δt_cycle	—（无量纲）	沿用 J7-02。⛔ 全课不裸写「实时因子 RTF」，一律带下标
β	扣除同核其余任务与调度裕度之后，还留给孪生模型的那一份	—（无量纲，β < 1）	沿用 J7-02。⚠ 方向别读反：它是留给模型的那一份，⛔ 不是留给其它任务的那一份
y_sensor	传感器实测的那一路信号	随所比量	本课首定
y_twin	孪生模型算出的同一个量的那一路输出	同 y_sensor	本课首定。⚠ 与 y_sensor 必须是同一物理位置、同一口径的量，否则下面的偏离量无意义
e_drift(t)	模型—实车偏离量 ＝ y_twin(t) − y_sensor(t)。它度量模型失准，属模型侧	同 y_sensor	本课首定，K5-05 已声明沿用本课记号。⛔ 它不是硬件的物理退化量（那一路归 K5-05）
ē_drift,W	窗口 W 内 e_drift 的中位数，即偏离量的慢分量	同 e_drift	本课首定。判漂移用它，⛔ 不用瞬时 e_drift（理由见 5.2）
W	漂移判定的观测窗口长度	s（或行程数／里程）	本课首定
r	估计器创新残差 ＝ z − H·x̂⁻	随量测量	沿用 K3-10，口径一字不改。⛔ 与 e_drift 不互算、不比大小（见 5.1）
σ_r	残差标准差	同 r	沿用 K3-10。⛔ 不裸写 σ
x̂ / x̂⁻	状态估计的后验值／时间更新后的先验值	随状态	沿用 K3-10 与 D1-06：估计值戴帽、真值不戴帽
z	量测向量	随量测量	沿用 K3-10
K_k	第 k 拍的融合增益（卡尔曼增益）	随状态与量测	沿用 K3-10。⚠ 撞名高危：K5-05 的 k 是无量纲判定倍数、D1-06 的 k 是离散下标或包含因子 ⇒ 本课增益一律写 K_k、⛔ 不裸写 K，也⛔ 不用 k 表示任何增益
ε_源	参照模型相对物理真值的偏差	随所比量	沿用 J7-02（归 J7-01 的射程）
ε_ROM	降阶模型相对参照模型的偏差	同上	沿用 J7-02
τ_link	车—云一次往返的端到端时延（含采集、上行、云端处理、下行、车端生效）	s	本课首定。⛔ 不等于网络 RTT——网络只是其中一段
L_conf	置信度档，取值 {可信／降级可用／不可用} 三档	—（离散档）	沿用 K3-10，三档名称与绑定动作的形式一字不改

⛔ 跨课口径对照：三处必须先分清的撞名

本课在这三处与兄弟课用了形式相同而口径不同的量。⚠ 直接互代会得到系统性错误的结论，所以先摆在这里。

其一，三个「周期」。三门课各自的语境不同，代进对方的判据里会得到偏松或偏紧的预算：

写法	属主课	它指的是什么	与本课的关系
Δt_target	J7-02	降阶模型要接进去的那个目标环境的步长（HIL 的定步长、MPC 的控制周期）	本课的 Δt_cycle 在孪生进控制闭环时必须 ≤ 该回路的 Δt_target
Δt_ctrl	D1-06	电池热状态估计器自己的执行拍	同上，是 Δt_cycle 的一个具体实例
Δt_cycle	本课	孪生模型自己的执行拍，⚠ 它可以慢于控制周期	孪生的输出若只进诊断与服务，Δt_cycle 可以比任何控制周期都长

⇒ 用法写死：孪生输出进控制闭环时，Δt_cycle ≤ Δt_target 是硬约束；孪生输出只进诊断与服务时，Δt_cycle 由信息时效性定，⛔ 不受控制周期约束。把后一种也按控制周期去核算，会得出一个高得离谱的算力需求，然后据此判定「车端做不了」——而那个结论是判据用错了对象造成的。

其二，三个同名的「残差」。这一处 K5-05 已经写死过一次，本课作为 e_drift 的属主再写一遍，两边一致：

量	属主课	参考物是什么	它变大说明什么
r（创新残差）	K3-10	估计器自己的一步预测	估计器内部的预测与量测不一致
e_drift（模型—实车偏离量）	本课	实车传感器	模型与真车渐行渐远（模型侧）
r_norm（归一化偏差）	K5-05	本车同工况格的出厂基线	硬件相对它自己出厂时退化了（物理侧）

⇒ 三者⛔ 不互算、⛔ 不比大小、⛔ 不互相替代。最常见的错法是拿 e_drift 变大去报「换热器脏堵了」——那需要 r_norm 那一路的物理侧证据；e_drift 变大的第一嫌疑永远是模型自己失准。K5-05 已经把 e_drift 的地位写死为第二路弱证据：它只有与至少一路物理侧证据同向时才计入表决。本课这一侧同样承认这条口径。

其三，两本静态误差账与一本动态账。J7-02 已定 ε_总 ≤ ε_源 ＋ ε_ROM，那是标定期的上界，是两个静态的数。e_drift 是运行期的实测量，随时间变。⇒ 写死：e_drift 与 ε_源、ε_ROM ⛔ 不相加、⛔ 不比较——前者是一条随时间走的曲线，后两者是标定完成那一刻定下来的两个上界。它们唯一的关系是：如果 e_drift 在交付第一天就已经接近 ε_源 ＋ ε_ROM 的量级，说明标定期那两本账里至少有一本记漏了，这是一个很有用的开箱自检，⛔ 但它不是一个可以持续用的判据。

本课对数字的三类处理

第一类，标准与规范性内容。本课引用三份文件：ISO 26262（道路车辆功能安全）、ISO 23247（制造业数字孪生参考框架，⚠ 非车用专有标准，本课只借它的分层思路）、FMI/FMU（Modelica Association 的模型交换标准）。⛔ 本课只写它们管什么、去哪儿查，⛔ 不复述任何条款文字，也⛔ 不钉死版次年份——版次以现行目录为准。⚠ 需要引条款做设计依据时，请取现行版原文自行核对，⛔ 不要以本课的转述为准。

第二类，行业典型区间。只给区间或量级档位并标「典型」，⛔ 端点不得当成可承诺值。

第三类，平台相关量。本课涉及的六组平台相关量，按本课程体系的口径都给典型参考值，每一组四件齐全：区间两端、常见值锚点、免责句、拿到它的路。⚠ 统一免责句一次写在这里，下文出现时不再重复全文：以下均为典型参考值，⛔ 非验收依据，必须在本项目的目标硬件与真实数据上实测确认。

平台相关量	典型区间（两端都给）	常见值锚点	拿到它的路
车端孪生执行拍 Δt_cycle	10 ms ~ 1 s	100 ms（与多数热管理控制回路同拍）	由该孪生输出的下游消费者定：进控制闭环取该回路周期，只进诊断取信息时效性需求
车端孪生单步耗时 t_solve,max	亚毫秒 ~ 十毫秒量级	1 ms 量级（一个十阶上下的定步长状态空间模型）	在目标域控上按最坏路径实测，⛔ 不用 PC 结果外推
车端孪生模型阶数	3 ~ 30 阶	10 阶上下（单回路热网络）	由 J7-02 的「两头夹」定：下界看目标带宽与主导时间常数，上界看实时预算
车—云端到端时延 τ_link	秒级 ~ 小时级	分钟量级（常规车联网数据服务的一次往返）	端到端实测，⛔ 不用网络 RTT 代替；必须包含云端排队与批处理等待
车—云数据回传频率	秒级一帧 ~ 一天一包	触发式上报 ＋ 低频周期包并存	由带宽与流量成本预算反推，⛔ 不由「多多益善」定
漂移触发门限（e_drift 侧）	⛔ 无通用区间可给	⛔ 无锚点	本项目自定：由该量的下游用途与误判代价定，方法在 5.3；⚠ 这一行刻意不给数，理由见下

⚠ 最后一行为什么不给数，要说清楚，⛔ 免得读成漏写。前五行的量都有一个共同点——它们的量纲与物理含义与平台无关（时间就是时间、阶数就是阶数），所以给一个典型量级是有意义的。而漂移门限的量纲随被比的那个量而变（温度、流量、功率各不相同），且它的合理值完全取决于误判的代价：同一个 2 K 的偏离，在座舱舒适性诊断里无所谓，在快充功率限制的输入链上是安全相关的。⇒ 给一个典型值在这里不是帮助，是一个会被照抄的错误锚点。本课给的是定这个门限的方法（5.3 的三步），⛔ 不是数。

---

第 1 讲 数字孪生 ≠ 仿真模型：判据是数据流向

这一讲不讲任何一种建模技术。它要先把一个几乎每份方案书都答错的问题掰开：「这算不算数字孪生」到底是一个程度问题还是一个是非问题。绝大多数人是按程度理解的——于是评审会变成「够不够孪生」的争论，谁的刷新率高谁更像，谁接了更多传感器谁更像。这条路径从第一步就走岔了：谱系分级是一个是非题，它问的是数据流向与自动化程度，⛔ 不问程度。本讲先把三级谱系摆开并把判据落到数据流上（1.1）；再把三件常被混当定义的事各归其位（1.2）；然后分开离线仿真与在线孪生这两个不同阶段的东西（1.3）；接着摊开保真度—实时性光谱，说清为什么孪生不是一个模型而是一族模型（1.4）；最后给出行业现状定位与它对立项的直接含义（1.5）。

1.1 三级谱系：判据是数据流向，⛔ 不是刷新率

行业里通行的分类把「物理对象 ↔ 数字对象」这条关系切成三级，切法只看两侧之间有几条自动数据流、方向是什么：

• 数字模型（Digital Model）：物理侧与数字侧之间没有任何自动数据流。模型的参数是人工设定的，实车的数据要靠人导出来、人再喂进去。⚠ 注意「没有自动数据流」⛔ 不等于「没有数据交换」——一个每季度由工程师人工重标一次的模型，仍然是数字模型级。绝大多数设计阶段的仿真模型都在这一级，而这没有任何问题，那正是它该在的地方。
• 数字影子（Digital Shadow）：实车 → 模型方向存在自动数据流，反向没有。实车的状态自动流进数字侧，数字侧据此更新它对实车的表征；但数字侧算出来的任何东西不会自动回到实车——它变成报表、变成告警、变成给人看的看板，人再决定做什么。
• 数字孪生（Digital Twin）：两个方向都存在自动数据流。实车状态自动上行，数字侧算出的修正量、参数、决策自动下行并生效于实车，不需要人在中间点一次确认。

⇒ 判据写死：数一数自动数据流有几条、朝哪个方向。零条＝数字模型；一条上行＝数字影子；上下行都有＝数字孪生。⛔ 这三级之间没有中间态可谈——「半自动写回」（云端算完、推给工程师、工程师批准后下发）在这条判据上归数字影子，因为那条回路上有人。⚠ 这么判⛔ 不是贬低它：带人工审批的写回在功能安全上往往是正确的设计选择，第 6 讲会说清为什么。

1.2 三件被混当定义的事，各归其位

术语混乱的根源是三件不同层级的事被塞进了同一个定义里。把它们拆开，每一件的归属都很清楚：

① 双向自动数据流——这是定义门槛。它是影子升级为孪生的真门槛，也是本课判级的唯一判据。⛔ 它是结构性的：有就是有，没有就是没有，不存在「做了 70%」。

② 实时运行——这是场景约束，⛔ 不是定义要件。一个孪生要不要实时，取决于它服务的那个场景。车端闭环场景要求实时，那是本课第 2、3 讲的主战场；而云端做长周期趋势分析的孪生，同步速率按用途确定即可。⚠ ISO 23247 那份参考框架在同步这一层的表述方向是「按用途确定适当的同步速率」，⛔ 它没有把某个具体刷新率写成定义门槛——⚠ 本课在此只给去向，条款原文请取现行版自核，⛔ 不以本课转述为准。

③ 闭环反馈优化——这是应用层能力。拿孪生算出的状态去做在线寻优、去改控制策略，那是建在孪生之上的一层应用。⛔ 它不是孪生的定义要件，也不在本课射程内——本课交的是模型底座，应用策略是另一层（第 6 讲会把这条分界线画清楚）。

⇒ 把这三件混成一件的代价是可预见的，而且两个方向都错：把 ② 当定义，就会把一大批有效的影子级方案判为不合格；把 ③ 当定义，就会认为「只要没做在线寻优就不算孪生」，于是把一个数据流已经闭合、只是暂时没上寻优应用的方案也判成不合格。两种误判都会让团队去补一件不需要的东西。

1.3 离线仿真与在线孪生：不是精度之分，是阶段之分

这两者常被拿来比精度，那是比错了轴。它们的差别在处在产品生命周期的哪个阶段、回答谁的问题：

	离线仿真（设计阶段）	在线孪生（运行阶段）
回答谁的问题	设计者：这个方案行不行、参数取多少	车与后台：这一辆车此刻是什么状态、接下来会怎样
对象	一个设计，它还不存在实物	一辆具体的车，有车架号
输入从哪来	工况库、边界条件假设	这辆车此刻的传感器
一次算多久	秒到几十秒的量级（典型），算完就好	必须跟得上它服务的那条链的时效要求
出错的表现	设计决策做错，返工	在役车辆上给出错误状态，可能进安全相关链路
谁来验它	相关性验证（去向 J7-01）	运行期的漂移监测（本课第 5 讲）

⇒ 两条最容易踩的推论，先点破：

• ⛔ 离线模型精度高，推不出它适合做孪生底座。离线模型的精度是在受控的边界条件下达成的，而孪生吃的是真车传感器——传感器有噪声、有失效、有安装位置带来的系统性偏差，一个对边界条件敏感的高精度模型在这种输入下会比一个粗糙但迟钝的模型表现更差。
• ⛔ 「一辆车一个孪生」推不出「要为每辆车单独建模」。实际做法是一套共用的模型结构 ＋ 每辆车自己的一组参数与状态。这一点决定了第 3 讲的可扩展性设计：结构是资产，参数是车的。

1.4 保真度—实时性光谱：孪生不是一个模型，是一族

把「一个热管理孪生」画成一个方框是这份方案书里最常见的简化，而它会隐藏掉一个关键决策。真实的形态是一族保真度不同的模型同时存在，沿着「保真度 ↔ 实时性」这条轴分布：

• 整车级、极低阶：几个集总热容加几条热阻，跑在车端，回答「现在还有多少冷却余量」这类粗问题。它的实时性最好，保真度最低。
• 子系统级、中阶：一条回路的热网络或状态空间模型，可以跑在车端也可以跑在云端，回答「这条回路的某个测不到的点是多少度」。
• 部件级、高阶：某个换热器或某个电池模组的详细模型，只跑在云端，回答「这个部件的内部分布是什么样」。
• 三维详细模型：⛔ 它不在孪生这一族里——它是云端偶尔被调用来做校核的参照，不参与在线运行。

⇒ 关键决策不是「用哪一个」，是「哪几个同时存在、它们之间怎么对账」。同一辆车上两个保真度不同的模型给出的同一个量必然不完全一致，如果没有事先规定谁是权威，两条下游会各信一个，然后在某次故障复盘时发现同一辆车两边的诊断结论对不上（这正是第 6 讲要点名的一种失效模式）。

写死一条口径：任何一个会被两个以上模型算出的量，都必须在架构文档里指定唯一的权威来源，以及非权威那一路的用途（通常是交叉校核）。⛔ 不许留「两边都算、谁准用谁」。

1.5 没有 ROM 就没有实时孪生的数字底座

这一节只讲一件事，也是本课与 J7-02 的接口所在：车端实时孪生的模型必然是降阶模型，这不是取舍，是结构决定的。J7-02 已经把那道沟说清楚了——离线详细模型的单工况机时落在秒到几十秒的量级（典型），而控制器与 HIL 的执行周期落在毫秒的量级（典型），两者之间隔着的不是倍数而是判据本身换了一个量。⇒ 本课直接站在那个结论上，⛔ 不重讲。

本课要补的是孪生这一侧对 ROM 提出的两条额外要求，它们在 J7-02 的四类使用场景里对应「嵌入式在线估计器」那一类，但比它更严：

要求一：模型必须有状态且状态要有物理含义。孪生的核心动作是「拿实车数据修正模型状态」，所以那些状态必须是可以被修正的、可以对应到物理量的东西。⛔ 一个纯输入—输出拟合出来的黑箱传递函数不能直接当孪生底座——它的内部变量没有物理对应，你无法说「把这个电芯的温度状态往上修 1 K」。

要求二：模型必须支持参数在线可写。孪生要修正的往往不只是状态，还有参数（热阻随污垢变大、风扇效率随磨损下降）。⇒ 这要求模型实现时把参数从代码常量里拿出来，做成可读可写的标定量并带版本号。⚠ 这一条影响的是嵌入式实现方式，⛔ 不是建模方法，很容易被漏在架构评审之外，然后在集成阶段发现「模型改不了」。

1.6 行业现状定位：这直接影响你的立项目标

按上面那条数据流判据去看车用领域已经规模化落地的车云方案，会得到一个与宣传口径不太一样的结论：绝大多数还停在数字影子这一级——整车数据单向回流云端，做分析、做健康监测、做车队统计，缺的是自动写回车端那一条边。全闭环的在线寻优多数仍在示范与试点阶段。

⚠ 这个判断本身是按公开可见的信息做的定位，⛔ 不是普查结论，各家的实际情况不对外披露，请按你自己能拿到的证据复核。

⇒ 它对立项的三条直接含义：

1. 影子级是一个合格的、常见的、有价值的目标。把目标定在影子级，把数据链路、模型对齐、漂移监测做扎实，工程价值是实的。⛔ 不必因为名字不够响而硬做闭环。
2. 要做孪生级，那条写回边是整个项目的重心，⛔ 不是最后一个迭代的收尾工作。它带来的功能安全、网络安全、版本管理与可回退设计，工作量往往超过模型本身。
3. 判一个供应商的方案在哪一级，看它的架构图上有没有那条向下的自动边，以及那条边上有没有人。⛔ 不要问它「是不是数字孪生」——所有人都会回答是。

---