1. 课程导入
欢迎进入《SDV中央计算软件平台工程》课程。软件定义汽车（Software-Defined Vehicle, SDV）并不是一句营销口号，而是汽车电子电气架构从“分布式ECU”向“中央计算+区域控制”演进后，软件在整车价值中占比持续上升的工程结果。本课程关注的不是单一功能如何编码，而是一个可量产、可迭代、可诊断、可升级的中央计算软件平台如何被设计、集成、验证与运营。
本课程的核心命题：把“中央计算硬件 + 车载操作系统 + 中间件 + 应用框架 + 云端协同”组织成一套可复用的软件平台，使整车功能能够像移动互联网应用一样快速迭代，同时满足车规级功能安全、信息安全与实时性约束。
一、学习目标：从“会写代码”到“会造平台”
完成本课程后，你应当具备以下能力：
- 架构能力：能够描述中央计算平台的软硬件分层，解释SOA、AUTOSAR Adaptive、Hypervisor、区域控制器之间的协作关系。
- 工程能力：能够设计服务接口、配置通信中间件、定义诊断与OTA升级流程，并理解实时性与资源隔离的权衡。
- 验证能力：能够搭建HIL/SIL测试环境，使用日志、Trace、总线报文定位跨域问题。
- 协作能力：能够在OEM、Tier1、芯片厂商、OS供应商之间用统一的术语和接口契约推进项目。
二、核心概念：先建立一张“术语地图”
SDV中央计算软件平台涉及大量跨领域术语。初学者最容易混淆的是“平台”与“应用”、“中间件”与“操作系统”、“SOA”与“微服务”。下面用一张关系图先建立整体认知。
图中自上而下是“云端—应用—中间件—OS—硬件”的分层。越往上，软件迭代越快、与用户价值越近；越往下，越接近车规约束、实时性与安全要求越高。中央计算平台工程的关键，就是在这些层之间建立稳定的接口契约。
三、整体框架：五个必须打通的工程域
本课程将平台工程拆解为五个相互依赖的域，它们共同决定平台能否量产落地：
| 工程域 | 核心问题 | 关键产出 | 典型工具/标准 |
|---|---|---|---|
| 架构与SOA | 服务如何划分、接口如何定义 | 服务清单、接口契约、部署视图 | ARXML、IDL、UML/SysML |
| 通信与中间件 | 跨进程/跨核/跨域如何可靠通信 | 通信配置、QoS策略、时延预算 | SOME/IP、DDS、IPC |
| 执行与资源管理 | 进程如何启动、隔离、调度与恢复 | 执行清单、资源配额、看门狗策略 | AUTOSAR Adaptive、Hypervisor |
| 诊断与OTA | 故障如何发现、上报、修复与升级 | DTC策略、刷写流程、回滚机制 | UDS、DoIP、OTA Master |
| 安全与验证 | 功能安全与信息安全如何落地 | 安全案例、测试报告、Trace证据 | ISO 26262、ISO 21434、HIL/SIL |
四、方法流程：一个功能从需求到上车的典型路径
以“雨天自动关窗”为例，它看似简单，却会贯穿平台各层。典型流程如下：
- 场景定义：雨量传感器触发，车速低于阈值，车窗未关，则自动关闭。
- 服务拆分：雨量服务、车速服务、车窗控制服务、场景编排服务。
- 接口定义：定义事件、方法、字段及QoS，例如雨量事件周期10ms、可靠性为Best Effort。
- 部署配置：将服务映射到中央计算SoC的不同虚拟机或进程，配置CPU/内存配额。
- 集成验证：在SIL中跑通逻辑，在HIL中接入真实雨量信号与车窗执行器。
- 诊断与OTA：定义失败DTC，支持场景服务独立升级而不影响整车其他功能。
# 服务接口契约示例（伪IDL）
service RainWindowService {
event RainIntensity { period: 10ms; qos: best_effort; }
event VehicleSpeed { period: 20ms; qos: reliable; }
method CloseWindow { request: WindowId; response: Result; timeout: 200ms; }
method GetWindowState { request: WindowId; response: WindowState; }
}五、案例与场景：为什么“平台”比“功能”更难
假设某车型要在已量产平台上新增“宠物模式”：锁车后保持空调、屏幕提示、电量监控。若平台没有统一的服务发现、状态管理和OTA能力，这个功能可能需要改动多个ECU、重新刷写、重新做整车验证，周期以月计。而在成熟中央计算平台上，它通常只是新增一个应用服务，复用空调服务、座舱服务、能量服务，通过场景引擎编排，再以OTA方式灰度发布。
平台价值：把“每次改功能都要动底层”变成“底层稳定、上层快速编排”。平台工程的目标不是让某个功能跑起来，而是让一百个功能都能以可控成本跑起来。
六、常见误区与复盘
- 误区一：把中央计算等同于“把ECU合并”。物理合并只是第一步，真正的难点是软件解耦、服务治理与资源隔离。
- 误区二：先做应用，后补平台。应用越多，技术债越重，后期迁移成本呈指数上升。
- 误区三：忽视实时性与安全等级差异。座舱与智驾、车身控制对时延和功能安全的要求完全不同，必须用Hypervisor或安全岛隔离。
- 误区四：只关注功能，不关注可观测性。没有统一日志、Trace和诊断，跨域问题几乎无法定位。
复盘要点：中央计算软件平台的成功标准不是“功能最多”，而是“新增功能的边际成本最低、故障定位最快、升级风险可控”。
七、课程路线图
本课程共30章，整体按“认知—架构—平台—集成—验证—运营”推进：
- 第1—4章：课程导入、SDV演进、中央计算架构、SOA与接口设计基础。
- 第5—10章：车载操作系统、Hypervisor、中间件、通信机制、执行管理与资源隔离。
- 第11—16章：服务框架、状态管理、诊断、日志、OTA与车云协同。
- 第17—22章：功能安全、信息安全、时间同步、网络管理、电源与热管理协同。
- 第23—27章：SIL/HIL测试、持续集成、灰度发布、数据闭环与工具链。
- 第28—30章：量产案例复盘、组织与流程、平台演进趋势。
学习本课程时，建议你始终带着三个问题阅读：这个模块解决什么问题？它的接口边界在哪里？如果它失效，整车会怎样？把这三个问题贯穿30章，你就能从“写代码的人”逐步成长为“造平台的人”。