1. 课程导入

智能网联汽车正在从“分布式电子控制单元（ECU）堆叠”走向“中央计算+区域控制”的新架构。过去，车窗、座椅、空调、动力、制动等功能由各自独立的 ECU 通过 CAN/LIN 总线交换少量信号；今天，座舱域、智驾域、车身域、动力域需要在同一台车内协同工作，还要与云端、手机、路侧设备持续交互。功能越来越多、软件规模越来越大、迭代节奏越来越快，传统的“信号级”通信方式已经难以支撑。车载服务中间件，正是在这样的背景下成为智能汽车软件架构中的关键一层。

一、什么是车载服务中间件

车载服务中间件（Automotive Service Middleware）是位于操作系统与上层应用之间的一层基础软件。它把车内各控制器、传感器、执行器以及云端能力抽象为“服务”，并统一提供服务发现、服务调用、数据分发、序列化、安全认证、生命周期管理等能力。上层应用不再直接关心“这个信号在哪个 CAN 报文里、走哪条总线、用什么字节序”，而是以调用服务的方式完成功能组合。

可以用一个简单的类比理解：中间件像车内的“通信与治理中枢”。应用是乘客，服务是车站，中间件是调度系统——它知道谁在哪里、怎么找到、如何安全送达、失败了怎么重试。没有中间件，每个应用都要自己修路、自己认路，软件复用和跨域协作几乎无法实现。

二、发展背景：从信号到服务

车载通信经历了三个阶段。第一阶段是信号通信，以 CAN/LIN 为主，报文 ID 固定、信号位置固定，适合低带宽、强实时的控制场景。第二阶段是面向信号的以太网扩展，SOME/IP 等协议开始把服务化思想引入车内，支持事件订阅和方法调用。第三阶段是面向服务的架构（SOA），服务可动态发现、可组合、可跨域部署，配合 OTA 实现软件持续演进。

推动这一演进的力量主要有三方面：一是功能复杂度，一辆智能汽车代码量可达上亿行，必须解耦；二是跨域协同，智驾、座舱、车身需要共享感知、决策和执行能力；三是持续交付，用户希望像手机一样通过 OTA 获得新功能，而服务化是 OTA 可灰度、可回滚的前提。

三、在智能网联汽车中的定位

从整车软件栈看，车载服务中间件位于操作系统/驱动层之上、应用层之下，横向连接车内各域控制器，纵向对接云端服务。它向下屏蔽异构硬件与总线差异，向上提供统一的服务接口与治理策略。典型能力包括：

• 通信抽象：统一封装 CAN、LIN、以太网、PCIe 等链路，支持发布/订阅与请求/响应。
• 服务治理：服务注册、发现、路由、限流、熔断、重试、超时。
• 数据与序列化：IDL 定义、序列化/反序列化、版本兼容。
• 安全与诊断：身份认证、访问控制、日志、追踪、故障定位。
• 资源与生命周期：进程/容器管理、资源配额、启动依赖、OTA 升级。

下面的 SVG 展示了车载服务中间件在整车软件栈中的位置，以及它与各域、云端之间的连接关系。

四、整体课程框架

本课程围绕“通信”与“治理”两条主线展开，共 30 章，可划分为五个模块。下表给出模块划分与核心内容，帮助建立全局地图。

五、典型场景与常见误区

以一个真实场景为例：用户靠近车辆，手机蓝牙钥匙向车身域发起“解锁”请求，车身域服务调用座舱域“迎宾灯效”服务，同时智驾域读取“座椅位置”服务并调整后视镜。整个链路涉及三个域、四类服务、多种总线。若没有中间件，每个应用都要硬编码对方地址和报文格式，任何一方升级都会导致联调失败。有了中间件，服务通过注册中心发现彼此，接口由 IDL 约束，升级只需保证版本兼容。