N5-02 · 前沿与新技术 / 集成化与软件定义
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 说清热管理域控在'分布式ECU→域控制器→中央计算+区域控制器'这条演进线上的位置迁移
- 区分硬件能力天花板与软件可调整空间，判断一项能力是不是真被'软件定义'了
- 评估热管理任务并入共享算力平台后的实时性/确定性风险，识别哪些分支必须留在硬实时域
- 分析软件定义趋势对Tier1商业模式、算法IP归属与型式认证的连锁影响
- 用一套判断框架取舍Features-on-demand类能力值不值得投入
内容大纲
- 热管理在整车 E/E 架构演进线上的位置迁移
- 从分布式ECU到域控制器再到中央计算+区域控制器：热管理算力/接口在这条演进线上挪了几次窝
- 热管理域控(链K2-01)在下一代架构里的宿命：独立域控，还是并入车身域/中央计算的一个软件包
- 硬件'降智'、软件'上位'：阀/泵/压缩机从各自带控制逻辑退化为纯执行器，逻辑集中到中央计算
- 并入中央计算之后：算力池化、SOA 服务化与确定性约束
- 中央计算平台上，热管理算法与座舱/底盘/智驾共享算力资源池，不再独享一颗MCU
- 资源竞争与实时性保证：热失控抑制这类安全相关闭环在共享算力环境下如何保证确定性响应
- 服务化(SOA)软件架构让'温度控制服务'能被多个上层应用调用，而不是各功能各写一套
- 与预测性热管理(K7-01)、数据驱动控制(K7-03)的关系：这些能力都要靠这层软件架构才能落地
- 软件迭代节奏如何改写产品定义
- K7-02讲单次OTA怎么安全发布，这里讲软件迭代节奏本身如何改变产品定义
- 硬件一次冻结、软件持续迭代成为常态后，'这台车的热管理能力'不再是出厂时刻定死的
- Features-on-demand的可能形态：预处理速度、多区独立温控等作为可远程配置的能力选项(具体商业条款各家不同)
- 判断框架：物理天花板划到哪、这项能力值不值得做
- 边界：物理执行能力(压缩机排量/换热面积)锁死之后，软件能撑开的空间有多大——不是所有'升级'都只是软件的事
- 物理定律不被软件定义：压缩机做功、换热面积、电池化学特性仍是硬约束，软件只能在约束内找最优
- 区分'真被软件重新定义的能力'和'换个UI/换个OTA渠道的老功能'，避免为了讲故事而讲故事
- 判据：一项能力值不值得投入，看它是否真打开了新的产品/商业空间，还是只是把线下标定搬到线上
- 产业分工、算法 IP 与型式认证的连锁变化
- 这一步演进对Tier1商业模式的冲击：谁还卖'带软件的整套总成'，谁开始只卖裸执行器
- OEM自建软件团队 vs Tier1黑盒交付：谁掌握热管理算法IP，决定下一代议价权在谁手里——这条产业判断在工程上由三样东西兑现：交付物形态(源码/目标码/受保护模型/FMU/SWC)、标定与诊断权限的授权等级、联合验证的签署归属；具体怎么写进合同附件与验证计划见 K4-09
- 供应链契约变化：从'买总成'拆成'买执行器硬件'与'买授权软件算法'两条线——本课只作商业模式层判断，算法与标定数据在技术协议里的归属、许可范围与终止后权利落在 M5-05，两门在'算法 IP 归谁'上分层不重复
- 法规与认证的跟进压力：软件可更新的安全相关功能，型式认证怎么覆盖'发布后还会变'的软件——UN R156 要求的软件升级管理体系(SUMS)是型式批准的前提条件，不是可选的体系证书；本课只到问题提出与架构影响为止，准入与备案的完整答案在 M4-08，硬件与过程变更侧的再认证判定在 M4-06
- 组织协同：热管理工程师要懂SOA接口契约，软件平台团队要懂热管理的功能安全边界
- 面向未来的三条主线：算法资产化、跨域算力共享、法规适配，谁先跑通决定行业格局
关键公式
U = Σ(Cᵢ/Tᵢ) ≤ n(2^(1/n) − 1)
速率单调调度可调度性上界(Liu & Layland)：**充分非必要**条件，且仅在单核/单分区、固定优先级抢占、任务相互独立且周期性、相对期限=周期、不计阻塞与中断开销这一组前提下成立——超界不等于不可调度，低于界也不等于安全。中央计算这类多核共享平台不能直接照用：分区调度须按核、按分区分别核算，全局调度还有 Dhall 效应（利用率略高于 1 即可能错过截止期，与核数无关）；一旦存在共享资源、中断与通信栈开销，量产判据是计入阻塞项与优先级反转的 WCET + 响应时间分析(RTA)，而不是利用率界。定量方法的前置在 K4-01，本课只取架构层结论：'利用率没超线就安全'是错的
T_ctrl ≪ τ_thermal
热管理闭环所需控制周期远小于该环自身的热惯性时间常数即可，整体上比底盘/智驾毫秒级要求宽松——但别据此把热管理当成单一慢周期档：任务周期跨约百毫秒到十秒三个量级，制冷剂侧过热度、压缩机排温/液击保护类闭环约百毫秒~秒级，须单列为快档；冷却液回路与舱温环约秒~十秒级为慢档；热失控抑制联锁等安全分支单独划入硬实时域，不能被'让路'逻辑覆盖。毫秒级及以下的电机电流环与过流保护仍留在执行器自带逆变器本地执行，不随'硬件降智'迁入中央计算的周期任务集
P_available = min(P_hw_max, P_licensed)
软件解锁类功能的物理天花板：授权解锁的性能上限不能超过硬件本身能力上限，这是判断某功能是真软件解锁还是营销包装的判据
V_software ≈ ΔUX_value − C_dev,maint
软件定义能力的定性价值框架：新增体验价值要能覆盖开发与长期维护成本，才值得做成可迭代的软件资产而非一次性硬件功能
关键概念
软件定义汽车 SDV中央计算+区域控制器域控制器降智SOA 服务化架构Features-on-demand硬件-软件解耦算力资源池共享速率单调调度确定性响应算法资产化黑盒交付 vs 自研算法IP（落地看三处：交付物形态、标定/诊断权限授权等级、联合验证签署归属，详见 K4-09）
推荐工具与标准
AUTOSAR Adaptive Platform（服务化软件架构标准） SOME/IP（车载服务化通信协议） CI/CD 软件交付流水线（跨域软件持续迭代基础设施） 本站供应商黄页（Tier1/OEM软件能力格局查证）
UN R156（软件升级与软件升级管理体系 SUMS，型式认证层面的OTA监管） ISO 24089（道路车辆软件更新工程） AUTOSAR 标准体系（服务化/自适应平台，具体版本以最新发布为准） ISO 26262（功能安全，安全相关软件变更的边界约束） GB 44496-2024《汽车软件升级通用技术要求》（强制性，2024-08-23 发布 / 2026-01-01 实施；中国侧 OTA 的对口强制件，与 UN R156、ISO 24089 并列，配套件为 GB 44495-2024《汽车整车信息安全技术要求》）
工程案例
某集中式计算架构车型把原本独立的热管理域控制器降级为执行器接口板，控制逻辑并入中央计算平台的一个软件服务；预处理速度、多区独立温控作为可远程配置项，但物理天花板仍卡在压缩机排量与换热面积上——软件解锁的从来不是物理定律之外的能力。
动手做
交付物 · 选一个当前独立热管理域控实现的功能(如预处理触发)：①设想它并入中央计算平台后的服务化改造点，画出服务接口示意；②判断该功能在共享算力下是否需划入硬实时域并说明理由；③给出它能否做成Features-on-demand的判断依据。
常见误区
- 把'软件定义'讲成万能叙事，忽视硬件物理天花板——压缩机排量、换热面积不会因为一次OTA变大，软件解锁的上限永远卡在硬件本身
- 把K7-02讲的'发一版OTA'和这里讲的'整车软件架构演进'混为一谈，前者是工程操作层面的发布流程，后者是产品定义与商业模式层面的结构性变化
- 热管理任务塞进共享算力平台后只按平均负载评估实时性，没做最坏情况调度分析，安全相关闭环在算力抢占高峰期响应变慢却没被发现
- 组织协同没跟上架构演进：热管理工程师不懂SOA接口契约，软件平台团队不懂热失控抑制这类功能安全边界，责任真空地带出问题没人认
- 把Features-on-demand当纯商业噱头推进，没有先判断该能力是否真有软件可调整的空间，营销承诺超出物理与安全边界
相关课题