2. 汽车电子电气架构基础

车身属性服务（CarPropertyService）并不是孤立存在的中间件模块，它能否稳定工作、能否被上层应用高效调用，取决于整车电子电气架构（EEA）的形态。理解 EEA 从分布式到中央集中式的演进路径，以及域控制器、SOA 在其中的角色，才能准确判断车身属性服务在整车软件栈中的位置与边界。

一、核心原理：EEA 演进的三级跳

EEA 的本质是“计算资源、通信网络与供电网络的拓扑组织方式”。它决定了信号从哪里采集、在哪里计算、以什么形式被消费。行业普遍将其演进划分为三个阶段：

• 分布式架构：每个功能对应一个 ECU，如车窗 ECU、座椅 ECU、灯光 ECU。ECU 之间通过 CAN/LIN 总线交换少量信号，功能逻辑固化在各自 ECU 内部。优点是失效隔离好，缺点是线束长、算力碎片化、跨功能协同困难。
• 域集中式架构：按功能域划分控制器，典型为动力域、底盘域、智能座舱域、车身域、自动驾驶域。域控制器（DCU）汇聚本域内多个 ECU 的信号与逻辑，域内可继续保留 CAN/LIN 子网，域间通过以太网骨干互联。车身域控制器通常管理车门、车窗、灯光、雨刮、座椅、空调风门等车身属性。
• 中央计算+区域控制架构：中央计算平台（CCP）承担跨域融合计算，区域控制器（ZCU）按物理位置就近接入传感器与执行器，形成“中央大脑+区域神经末梢”的结构。软件从“面向信号”转向“面向服务”，SOA 成为必然选择。

二、域控制器与中央计算平台的分工

域控制器解决的是“同一功能域内逻辑集中”的问题，中央计算平台解决的是“跨域融合与算力共享”的问题。两者不是替代关系，而是不同阶段的组织形态。在域集中式阶段，车身属性服务通常运行在车身域控制器上；在中央计算+区域控制阶段，车身属性服务可能运行在中央计算平台的某个容器或分区中，通过 SOA 总线与区域控制器交互。

下表对比三种架构下车身属性服务的典型部署方式：

三、SOA 架构与车身属性服务的定位

SOA（面向服务的架构）把整车能力抽象为可发现、可调用、可组合的服务。车身属性服务是 SOA 在车身领域的具体落地：它把“车门开闭状态”“车窗位置”“座椅记忆”“灯光模式”等物理属性，封装为带方法、事件与属性的服务接口。

在 SOA 分层中，车身属性服务位于“原子服务/基础服务”层，向上被场景服务、座舱应用、车控 App 调用，向下通过 HAL 或信号抽象层访问具体硬件。其典型接口形态如下：

// 车身属性服务接口示意（IDL 风格）
interface CarPropertyService {
  // 属性读取
  getProperty(propId: CarPropertyId): PropertyValue;
  // 属性设置
  setProperty(propId: CarPropertyId, value: PropertyValue): ResultCode;
  // 属性变化事件订阅
  subscribe(propId: CarPropertyId, callback: PropertyCallback): SubscriptionId;
  // 批量区域属性
  getAreaProperties(area: ZoneId, propIds: CarPropertyId[]): PropertyValue[];
}

// 典型属性 ID
CarPropertyId.WINDOW_POSITION   // 车窗位置
CarPropertyId.DOOR_LOCK_STATE   // 门锁状态
CarPropertyId.SEAT_MEMORY_POS   // 座椅记忆位置
CarPropertyId.AMBIENT_LIGHT     // 氛围灯模式

可以看到，车身属性服务并不直接操作电机或继电器，而是通过属性 ID 与区域 ID 的组合，把“哪个位置、哪个属性、什么值”表达清楚。这正是 SOA 解耦硬件与应用的体现。

四、案例场景：从“按按钮”到“调服务”

以“用户靠近车辆，车门自动解锁并调整座椅到记忆位置”为例：

1. 蓝牙钥匙或 UWB 模块检测到用户接近，产生“用户接近”事件。
2. 场景服务订阅该事件，调用车身属性服务的 setProperty(DOOR_LOCK_STATE, UNLOCK)。
3. 车身属性服务校验权限与车辆状态，向区域控制器下发门锁执行指令。
4. 同时读取 SEAT_MEMORY_POS，调用座椅区域属性设置，完成座椅调整。
5. 属性变化通过事件回调通知座舱应用，更新迎宾灯语与屏幕欢迎界面。

整个过程中，应用层不关心门锁是 LIN 还是 CAN 驱动，也不关心座椅电机来自哪家供应商，只依赖车身属性服务的统一接口。这就是 EEA 演进到 SOA 阶段后，车身属性服务的核心价值。

五、常见误区与复盘

• 误区一：把车身属性服务等同于车身域控制器。域控制器是硬件载体，车身属性服务是软件服务，二者可以分离部署。
• 误区二：认为 SOA 就是“加一层 RPC”。SOA 还包含服务发现、生命周期、权限、版本兼容与事件模型，缺少这些会退化为点对点调用。
• 误区三：忽略区域属性与全局属性的差异。车窗、座椅、灯光都是区域相关属性，接口设计必须带区域标识，否则会出现“左前窗控制右后窗”的错位。
• 误区四：在分布式架构上强行套用 SOA。若底层仍是低速 CAN 信号，服务化收益有限，应先完成域集中或区域控制改造。

复盘来看，EEA 演进决定了车身属性服务的部署位置与通信方式，域控制器与中央计算平台决定了它的算力与隔离边界，SOA 决定了它的接口形态。三者共同定义了 CarPropertyService 在整车软件架构中的坐标。