1. 课程导入
在传统汽车电子电气架构中，车辆功能通常由几十甚至上百个分布式 ECU 分别实现，每个 ECU 对应一个或少数几个功能，软件与硬件强绑定。随着智能座舱、智能驾驶、车联网与整车 OTA 的快速发展，这种"一功能一控制器"的模式在算力利用率、通信带宽、线束成本、软件复用和迭代效率上逐渐逼近瓶颈。中央计算平台正是在这一背景下出现的架构范式：它以少量高性能计算单元为核心，将原本分散的感知、决策、控制、交互等功能集中承载，通过统一的操作系统、中间件与通信机制对外提供服务。
从工程视角看，中央计算平台并不是"把 ECU 合并成一个大盒子"这么简单。它同时改变了硬件拓扑、软件分层、通信模型、资源调度方式与开发协作模式。因此，本课程关注的不是单一模块的编码技巧，而是软件架构工程：如何在算力、实时性、安全性、可扩展性与成本之间做出可落地的结构性决策，并让这些决策在团队协作与长期演进中保持稳定。
一、中央计算平台的定义与边界
中央计算平台可以理解为：以集中式高性能计算节点为核心，配合区域控制器或边缘节点，通过车载高速网络连接传感器、执行器与外部接口，并由统一软件栈提供计算、通信、服务管理与安全隔离能力的整车级计算基础设施。它通常包含以下关键要素：
- 集中算力单元：如 SoC、MCU、AI 加速器、GPU 等异构计算资源，承担不同安全等级与实时性要求的任务。
- 区域/边缘节点：负责 I/O 汇聚、电源管理、局部实时控制，降低中央节点的接口压力。
- 统一软件平台：包括 Hypervisor、实时操作系统、POSIX 操作系统、中间件、服务框架与 OTA 组件。
- 车载通信网络：如车载以太网、CAN/CAN FD、LIN、PCIe 等，形成确定性与非确定性并存的通信矩阵。
- 安全与隔离机制：功能安全、信息安全、资源隔离、故障域划分与降级策略。
需要明确的是，中央计算平台不等于"只有一个盒子"。在相当长的时间内，它会以"中央计算 + 区域控制"的混合形态存在，中央节点负责高算力与跨域协同，区域节点负责就近采集与执行。理解这一边界，是后续架构设计不跑偏的前提。
二、软件架构工程的目标
软件架构工程的目标，是在需求、约束与演进之间建立可验证的结构性平衡。对于中央计算平台，可以归纳为五个核心目标：
- 功能整合与算力共享：让多个业务域共享同一套计算资源，提高利用率，减少硬件数量与线束复杂度。
- 确定性与实时性保障：在混合关键性场景下，保证安全关键任务的时延与抖动可控。
- 软硬件解耦与可移植：通过抽象层与标准接口，使应用不依赖具体芯片与板卡，支持多平台复用。
- 可扩展与可演进：支持新功能以服务或组件形式接入，支持 OTA 升级与灰度发布。
- 安全、可靠与可维护：满足功能安全与信息安全要求，具备故障隔离、降级运行与可观测能力。
三、核心原理：分层、分域与通信
中央计算平台的软件架构通常遵循"分层 + 分域 + 标准化通信"的基本原理。分层解决依赖方向问题，分域解决隔离与资源分配问题，标准化通信解决跨模块协作问题。下图展示了从整车到软件栈的典型结构关系，可作为本课程后续章节的全局参照。
这张图强调三个关键关系：上层业务依赖下层抽象而非具体硬件；每一层内部通过隔离机制划分故障域与安全域；跨域协作最终落到通信与数据流上。后续章节将分别展开虚拟化、中间件、通信、安全、OTA 与工具链等主题。
四、课程整体框架与学习路径
本课程共 30 章，按照"认知—结构—机制—工程—演进"的路径组织，避免一开始就陷入某个具体框架的细节。整体框架可概括为下表：
| 阶段 | 核心问题 | 典型内容 | 产出视角 |
|---|---|---|---|
| 认知导入 | 中央计算平台是什么，为什么需要软件架构工程 | 定义、目标、整体框架、学习路径 | 建立全局地图 |
| 结构设计 | 如何分层、分域、划分组件与接口 | 架构风格、分层模型、服务划分、接口契约 | 可评审的结构方案 |
| 运行机制 | 任务如何调度、通信如何确定、资源如何隔离 | Hypervisor、RTOS、中间件、时间同步、QoS | 可验证的运行行为 |
| 工程落地 | 如何开发、集成、测试、诊断与升级 | 工具链、CI/CD、HIL、OTA、可观测性 | 可交付的工程体系 |
| 演进与复盘 | 如何应对需求变化、故障与架构腐化 | 架构评估、重构、降级策略、案例复盘 | 可持续演进的能力 |
学习路径建议遵循"先建立约束意识，再掌握结构方法，最后进入机制细节"的顺序。很多初学者容易直接跳到某个中间件 API 或某个芯片的 BSP 细节，结果在跨域协作与安全隔离上反复返工。更有效的方式是：先理解平台要满足哪些约束，再判断哪些结构能承载这些约束，最后才选择具体技术实现。
五、案例场景：从分布式到中央计算的迁移
假设某车型原本采用分布式架构：座舱域控制器负责娱乐与仪表，智驾域控制器负责感知与规划，车身控制器负责门窗与灯光，各控制器通过 CAN 与以太网交换少量信号。现在要迁移到中央计算平台，典型动作包括：
- 将座舱与智驾的高算力任务迁移到中央 SoC，通过 Hypervisor 划分多个虚拟机，分别运行不同安全等级的系统。
- 将车身控制等低实时任务下沉到区域控制器，通过 CAN FD 或以太网与中央节点通信。
- 把原本点对点的信号交互，重构为基于服务的通信，明确接口契约与 QoS 要求。
- 引入统一的 OTA 与诊断框架，使升级不再依赖各 ECU 的独立方案。
迁移过程中最常见的误区是"只做硬件合并，不做软件重构"。如果仍然沿用原来的点对点信号模型，只是把多个 ECU 塞进一个盒子，那么算力共享、隔离与可演进性都不会真正发生，反而会引入更复杂的耦合与更长的故障链。
六、常见误区与复盘要点
在课程开始阶段，先建立几个反直觉但重要的认知：
- 集中不等于简单：集中后单点复杂度上升，隔离、调度与故障恢复难度反而更大。
- 算力共享不等于性能提升：共享资源会带来争用与干扰，必须通过调度与 QoS 约束保障关键任务。
- 标准化接口不等于零成本：接口抽象会带来性能开销与调试复杂度，需要权衡粒度。
- 架构图不等于架构：真正的架构体现在约束、决策记录与验证手段上。
复盘时可以问自己：当前结构是否明确回答了"谁依赖谁、谁隔离谁、谁保障谁"？如果这三个问题无法用一张图和一组约束说清楚，说明架构还停留在概念阶段。本课程后续每一章都会围绕具体机制展开，但始终回到这三个问题。
至此，我们已经建立了中央计算平台的基本定义、软件架构工程的目标、课程整体框架与学习路径。接下来将进入结构设计阶段，从架构风格与分层模型开始，逐步把这张全局地图细化为可评审、可实现、可验证的工程结构。