工作赋能

15 年汽车行业一线经验的主业能力:电子电气架构设计、SOA 服务架构与 SOME/IP 全流程开发、功能架构与汽车标准解读/翻译。

01电子电气架构 02SOA 服务架构开发 03功能架构 · 标准
01. // 汽车电子电气架构(EEA)

从分布式到中央计算,我一路做过来

电子电气架构是汽车的「神经系统 + 大脑」——它决定了智能化功能发挥的上限。15 年来我完整经历了从分布式 ECU、域控制器到中央计算+区域架构的演进,既做过主流车企的架构对标研究,也踩过中央计算架构从立项到暂停的坑:架构不只是拓扑图,更是组织、供应链、软件能力的系统工程

演进脉络 · 行业坐标

分布式阶段
2015 前
  • 1 ECU = 1 功能
  • ECU 100+、线束 6km/70kg
  • CAN/LIN 低速总线
  • 软硬件深度耦合
功能域集中
2018-2022
  • 动力/底盘/车身/座舱/智驾五域
  • 域控制器 + 以太网/CANFD 骨干
  • 软件开始上收
跨域融合
2022-2023
  • 五域 → 车控/座舱/智驾三域
  • 中央计算群组形态
  • SOA 架构落地
中央计算+区域
2024-2026
  • 少量 HPC + ZCU 就近接入
  • 软硬件解耦、无感 OTA
  • 线束大幅缩短
车云计算
未来
  • 功能上云、车端再简化
  • 车辆成为可编程终端
  • one brain + 生态

判断:分布式 → 域控 → 中央计算的本质,是主机厂把控制权从供应商「黑盒」中收回自研的过程;中央计算 + 区域控制已是行业共识的终局形态。

EEA 工程师的核心能力

01

架构演进认知

从分布式 ECU → 域控 → 中央计算+区域 → 车云的完整演进模型,理解每一代的动因、瓶颈与取舍。

02

硬件架构设计

中央计算单元 / 域控制器 / 区域控制器的硬件构成与选型:异构 SoC(A核/M核)、车规 MCU、成本与算力模型。

03

软件架构设计

CP/AP AUTOSAR、SOA 分层(基础/组合/应用)、QNX/Linux/Android/RTOS、Hypervisor 与 AMP 多核。

04

通信架构设计

CAN/CANFD/LIN → 车载以太网骨干(100/1000BASE-T1)、TSN、SOME/IP、DDS、MQTT 车云链路与网关转换。

05

电源架构设计

区域配电、智能电源管理、场景式精准配电、冗余供电与低功耗策略。

06

安全与信息安全落地

ISO 26262 功能安全(ASIL 与部署约束)、ISO/SAE 21434 信息安全、冗余/降级设计。

07

开发流程与工具链

V 模型 + 敏捷/SPASE、架构建模、代码生成、测试与仿真工具链、车云协同开发。

08

行业对标能力

主流车企 EEA 形态持续调研,域控制器形态/芯片/供应商格局分析,演进节奏判断。

主流车企架构对标(一手调研口径)

特斯拉Model 3 开创中央计算+区域(CCM+BCM×3)

ECU 26 个 ≈ ID4 一半;无线束保险丝继电器;领先传统车企约 6 年

小鹏X-EEA 3.0:中央超算 C-DCU + 左右 Z-DCU

千兆以太主干;30 分钟无感整车 OTA;场景式精准配电

蔚来中央计算单元(>1000 TOPS)+ 4 区域控制器

环形拓扑双冗余;区域控制器=汽车小脑;AMP 多核

理想L9 三域(S32G 中央控制全自研)→ CCU+区域

CCU 算力/存储/通讯资源利用率硬指标管控

长城GEEP3.0 四域量产 → 4.0 中央+区域(复盘)→ DE/4-Light

左域集成网关+Switch;S32G274 高配支持 SOA

广汽星灵:中央运算(S32G399)+座舱+智驾(昇腾610)+四区域

算力提升 50 倍、线束回路减少 40%

覆盖 11+ 家车企(含大众、奥迪、长安、红旗、小米、上汽零束、比亚迪等)的完整对标矩阵,来自长期车厂调研与公开信息梳理。

02. // SOA 服务架构开发

服务设计准则 + SOME/IP 全流程

SOME/IP 是车载行业实现服务的一种方式;而服务设计的理念与准则是独立的方法论——它们让「软件定义汽车」从口号变成可落地的工程。
这一部分:先讲我怎么设计服务,再讲我怎么把设计变成可运行的代码。

① 服务怎么分层

🧱
基础服务Basic Service
L1

按整车系统划分,把系统能力以服务接口暴露(外灯、门锁、雨刮…),可独立运行、无外部依赖。

外灯控制服务 · 雨刮控制服务
🧩
组合服务Composite Service
L2

域内基础服务/能力组合 + 逻辑判断与算法,形成有业务含义的服务。

摄像头+雷达 → 环境感知模型服务
🚘
应用服务Application Service
L3

直接面向用户场景,调用组合/基础服务实现体验类功能。

智能冷暖 · 远程车窗控制

② 服务设计九条准则(实践沉淀)

P1

先判断要不要服务化

单控制器、逻辑稳定少更新 → 信号;需快速修复/更新、信息源频繁变更 → 服务化。ASIL C/D、高实时(动力/底盘控制)不服务化。

P2

分层定义服务

基础/组合/应用三层,软件模块化标准化,与硬件、操作系统解耦,可灵活部署、最大化复用。

P3

两条设计路径

已有系统用 Bottom-Up(信号/能力抽象为服务);新功能/复杂功能用 Top-Down(需求 → 逻辑拆解 → 服务拆解 → SOA 图)。

P4

按信息类型选接口

控制类 → RR/FF-Method、Field-Setter/Getter;状态类 → Event(周期推送)/ Field-Notifier(变化触发)。

P5

接口与业务解耦

三步业务流程应拆三个接口;业务调整改时序编排,不改接口定义。

P6

命名与颗粒度规范

名称唯一无空格、缩写对照 AUTOSAR 词表;服务名首字母大写;同一功能参数不可拆散到不同服务。

P7

部署看属性

低实时控制类基础服务 → CCU/HUT/IDC(便于 S2S);高实时状态类 → 就近部署在 VIU/直接驱动 ECU。

P8

客户端分级仲裁

Client 优先级(数值越小优先级越高);多客户端同请求响应高优先级;无特殊要求默认低优先级 Client。

P9

严格版本管理

Major.Minor:不向后兼容 → Major+1 且 Minor 归零;向后兼容变更 → Minor+1。发行后禁止改内容,新版本发行。

③ SOME/IP 全流程开发(工程实现)

1 服务矩阵

单源真相:merged.json 维护全部服务/接口/事件

JSON
2 接口定义

生成 FIDL/FDEPL 接口定义文件

FIDL
3 中间件配置

vsomeip/CommonAPI 配置(服务发现、端口、通信)

CFG
4 代码生成

CommonAPI codegen → Stub/Proxy 骨架代码

CODEGEN
5 服务实现

Stub 侧实现服务逻辑 + 事件触发

C++
6 纯 C 封装

C API 层:服务端回调注册 / 客户端调用订阅

C API
7 多平台构建

CMake 三平台:local / 5522 / 7720 工具链

CMake
7 个服务83 个接口48 R&R + 32 Getter140 条事件C 自测 72/72 通过
想看完整开发过程?

公众号长文记录了从 Excel 服务矩阵到车载代码的全链路踩坑与设计思路。

公众号:SOME/IP 从 Excel 到车载代码 ↗
03. // 功能架构 · 标准解读与翻译

把需求变成功能,把标准落进产品

功能架构在 EEA 中承上启下:把用户/法规/产品需求转化为整车功能清单与功能分配,回答「车有哪些功能、功能放哪、功能之间如何交互」。标准与功能强相关——强制性国标定义功能的底线,技术规范定义功能的实现细节。

功能设计注意点(域内 / 跨域)

🏠 域内功能

  • 功能归属清晰:按域划分功能边界,避免重复实现
  • 基础能力沉淀:稳定能力服务化(外灯/门锁/雨刮),控制类与状态类拆分看部署
  • 接口标准化:统一模板、统一命名、统一版本管理
  • 与硬件对齐:功能定义跟随域控能力更新,矩阵同步更新
  • 实时与安全约束:高实时/高 ASIL 功能不盲目服务化,留在 MCU 侧

🛣️ 跨域功能

  • 场景驱动:从用户场景出发(吸烟模式/智能冷暖/洗车模式),识别多域所需服务
  • 服务编排:跨域 = 组合/应用服务编排域内基础服务,业务逻辑不入基础接口
  • 通信保障:跨域依赖以太主干与 SOME/IP、DDS,做延时与带宽预算
  • 功能上移:中央集中后逻辑功能上移、I/O 驱动下沉区域,切分「逻辑/执行」边界
  • 仲裁与兼容:多客户端场景统一优先级仲裁;跨域接口变更严格版本管理 + 会签

※ 功能架构目前尚无行业统一设计准则,以上为我在项目中的实践总结(域内/跨域两条线),欢迎探讨校正。

强制性国标解读(功能安全的底线)

G1

GB 44495-2024 整车信息安全

整车信息安全强制性国标解读:安全框架、纵深防御、技术要求拆解与开发行动清单。

信息安全 · 整车 · 强制性
G2

GB 44497-2024 自动驾驶数据记录系统

DSSAD 国标解读:记录范围、触发条件、存储要求与认证要点。

DSSAD · 数据记录
G3

GB 44721-2026 自动驾驶系统安全要求

自动驾驶系统安全国标解读:系统架构、功能安全与预期功能安全要求。

自动驾驶 · 系统安全
G4

GB 45672-2025 车载事故紧急呼叫系统

AECS 国标解读:M1/N1 类车辆紧急呼叫系统技术要求与试验方法。

AECS · 紧急呼叫
G5

GB 47955-2026 组合驾驶辅助系统安全要求

L2+ 组合驾驶辅助国标解读:功能要求、人机交互、失效检测与响应。

驾驶辅助 · L2+

技术标准翻译(功能实现的细节)

T1

FiRa MAC v4.0.0(单文件全卷版)

UWB MAC 层完整中文翻译:架构、协议流程、技术细节与附录全收录。

在线阅读 →
T2

FiRa UCI 技术规范

UWB 命令接口(UCI)规范翻译:命令集、参数定义与流程(第 1 卷 Ch1-6)。

在线阅读 →
T3

FiRa PACS 技术规范

测距与位置感知服务(PACS)规范翻译:架构、数据模型与业务流程。

在线阅读 →
T4

FiRa CSML 技术规范

通用服务与消息层(CSML)规范翻译:帧结构、消息类型与交互流程。

在线阅读 →
T5

FiRa BLE-OOB 中文翻译

基于 BLE 的带外(OOB)配对与配置流程翻译,UWB 设备配网参考。

在线阅读 →
T6

FiRa PHY v4.0.1 errata 翻译

FiRa 物理层规范勘误表翻译,与 MAC 规范配套研读。

在线阅读 →

沉淀的方法论

auto-standard-analysis

汽车标准深度解读技能:英文规范 → 可执行中文工程文档

trans-regs

寄存器/规范转换技能:术语统一的中英对照转换

someip-full-chain

SOME/IP 全链路开发 SOP:矩阵 → 代码 → 多平台

📍 定位中…
--° --
体感 --°💧 --%💨 --
加载中…
🔊