254 lines
7.4 KiB
Markdown
254 lines
7.4 KiB
Markdown
|
||
|
||
> **「小鹏汽车系统架构（System Architecture）」**
|
||
|
||
结构清晰、语义标准，格式完全适配 **Obsidian Markdown**。
|
||
内容聚焦在系统架构本身：分层结构、逻辑与物理视图、关键子系统、非功能性约束，以及架构演化路线。
|
||
|
||
---
|
||
|
||
```markdown
|
||
# 小鹏汽车系统架构（System Architecture of XPENG Motors）
|
||
*面向系统分析员 · {{date}}*
|
||
|
||
---
|
||
|
||
## 🧭 一、系统定位与架构目标（System Context & Goals）
|
||
|
||
### 系统定位
|
||
小鹏汽车是一个 **“云-车一体化” 的软件定义汽车系统（Software Defined Vehicle, SDV）**。
|
||
整体由两大系统域组成：
|
||
- **车端系统（On-Vehicle System）**：负责实时感知、决策、控制与人机交互；
|
||
- **云端系统（In-Cloud System）**：负责数据采集、分析、模型训练、OTA分发与远程运维。
|
||
|
||
两者通过安全通信通道（5G / V2X / TLS）形成 **闭环数据架构**，
|
||
实现从感知到学习、从更新到再优化的持续演进。
|
||
|
||
---
|
||
|
||
### 架构目标
|
||
| 架构属性 | 目标描述 | 指标或机制 |
|
||
|-----------|-----------|-------------|
|
||
| **可演化性** | 支持软件持续迭代与OTA更新 | 模块化 / 接口稳定 / 热更新 |
|
||
| **实时性** | 满足自动驾驶与控制环路响应 | <10ms 延迟（DDS QoS） |
|
||
| **安全性** | 满足功能安全 + 网络安全 | ISO 26262 + TLS + HSM |
|
||
| **可扩展性** | 支撑多车型、多功能复用 | 微服务 + 容器化 |
|
||
| **可用性** | 高可用冗余与自愈 | 双通道通信 + 监控回退 |
|
||
| **一致性** | 云车状态与数据同步 | 双向版本控制机制 |
|
||
|
||
---
|
||
|
||
## 🧩 二、系统总体结构（System Decomposition）
|
||
|
||
小鹏系统采用“**双域四层**”结构：
|
||
|
||
```
|
||
|
||
Cloud System (云端)
|
||
├─ 数据采集与管道层
|
||
├─ 数据湖与特征仓库层
|
||
├─ AI训练与仿真层
|
||
└─ OTA与运维服务层
|
||
|
||
Vehicle System (车端)
|
||
├─ 感知与决策层
|
||
├─ 通信中间件层
|
||
├─ 操作系统与座舱层
|
||
└─ 硬件抽象与控制层
|
||
|
||
````
|
||
|
||
---
|
||
|
||
## 🚗 三、车端系统架构（On-Vehicle Architecture）
|
||
|
||
### 分层结构
|
||
```mermaid
|
||
graph TD
|
||
A[应用层: 自动驾驶 / 座舱AI / 车控逻辑]
|
||
B[服务层: SOA 服务管理 / 语音 / 导航]
|
||
C[通信层: DDS / RTI Connext / IPC]
|
||
D[系统层: XOS / Linux / QNX]
|
||
E[硬件抽象层: ECU / Sensors / Actuators]
|
||
A --> B --> C --> D --> E
|
||
````
|
||
|
||
### 主要组成模块
|
||
|
||
|模块|功能说明|技术要点|
|
||
|---|---|---|
|
||
|**自动驾驶栈 (XPILOT / XNGP)**|感知、预测、规划、控制|XNet 感知模型 + Turing 芯片|
|
||
|**车载操作系统 (XOS)**|座舱交互、语音助手、小P|Linux + QNX + 应用容器|
|
||
|**通信中间件 (DDS)**|模块间消息分发与服务发现|RTI Connext Drive|
|
||
|**E/E 电子架构**|中央计算 + Zonal Controller|与大众 CEA 架构协同|
|
||
|**车控与诊断系统**|电机/制动/能量管理|CAN / LIN / Ethernet|
|
||
|**安全机制**|功能安全 + 网络加密|HSM / PKI / TLS|
|
||
|
||
### 架构特征
|
||
|
||
- SOA化设计（Service-Oriented Architecture）
|
||
|
||
- 模块以服务形式存在，通过 DDS 异步通信
|
||
|
||
- 容器化运行环境，支持模块级 OTA
|
||
|
||
- 实时调度与安全隔离（QNX + Linux 双核架构）
|
||
|
||
|
||
---
|
||
|
||
## ☁️ 四、云端系统架构（In-Cloud Architecture）
|
||
|
||
### 云端逻辑结构
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[Telemetry Ingestion 层]
|
||
B[数据湖 / 特征仓库]
|
||
C[AI 训练与仿真平台]
|
||
D[模型注册 / MLOps 管理]
|
||
E[OTA 分发与运维平台]
|
||
A --> B --> C --> D --> E
|
||
```
|
||
|
||
### 云端核心子系统
|
||
|
||
|模块|功能说明|技术栈 / 架构模式|
|
||
|---|---|---|
|
||
|**数据采集与接入层**|接收车端上报数据|MQTT / Kafka / Flink|
|
||
|**数据湖与仓库层**|存储与管理全量数据|S3 / Hive / DeltaLake|
|
||
|**AI 训练平台**|模型训练与优化|PyTorch / TensorFlow / Ray|
|
||
|**仿真测试系统**|模拟驾驶场景验证算法|Carla / Unity / OpenSCENARIO|
|
||
|**MLOps 管理平台**|模型版本与部署管理|MLflow / Kubeflow|
|
||
|**OTA 系统**|OTA 打包与分发|微服务 + CDN + 签名验证|
|
||
|**监控与运维**|实时监测与异常分析|Prometheus / Grafana / ELK|
|
||
|
||
### 架构特征
|
||
|
||
- 微服务化 + 事件驱动架构（EDA）
|
||
|
||
- 支持实时流处理与批量分析（Lambda Architecture）
|
||
|
||
- 模型与软件分层管理（解耦版本）
|
||
|
||
- 数据闭环支持持续学习（DataOps + MLOps）
|
||
|
||
|
||
---
|
||
|
||
## 🔗 五、云车交互与数据闭环（Cloud-Vehicle Interaction）
|
||
|
||
### 数据闭环流程
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[车辆传感器] --> B[车端计算与决策]
|
||
B --> C[Telemetry Agent 上报]
|
||
C --> D[云端数据管道 Kafka/Flink]
|
||
D --> E[数据湖 / 特征仓库]
|
||
E --> F[AI 训练 / 仿真平台]
|
||
F --> G[模型注册 / OTA系统]
|
||
G --> H[OTA 分发]
|
||
H --> I[车辆端接收更新]
|
||
I --> B
|
||
```
|
||
|
||
**说明：**
|
||
|
||
- 上行：车辆 → 云端 → 数据湖
|
||
|
||
- 下行：云端 → OTA → 车辆
|
||
|
||
- 闭环：通过反馈数据持续优化模型与策略
|
||
|
||
|
||
---
|
||
|
||
## 🧠 六、系统架构视图（Architectural Views）
|
||
|
||
### 1️⃣ 逻辑视图（Logical View）
|
||
|
||
展示功能模块与交互关系：
|
||
|
||
```
|
||
[自动驾驶] ─ [座舱系统] ─ [通信中间件]
|
||
│ │
|
||
└─────→ 云端数据平台 ←─────┘
|
||
```
|
||
|
||
### 2️⃣ 物理视图（Physical View）
|
||
|
||
```
|
||
车辆端：中央计算单元 + 区域控制器
|
||
云 端：Kubernetes 集群 + GPU 训练集群
|
||
通信通道：5G / MQTT / HTTPS / OTA
|
||
```
|
||
|
||
### 3️⃣ 过程视图（Process View）
|
||
|
||
- 实时管线：传感器 → 感知 → 规划 → 控制
|
||
|
||
- 异步事件：消息总线 DDS
|
||
|
||
- 后台任务：日志上传、诊断上报、OTA更新
|
||
|
||
- 云端任务：数据清洗 → 模型训练 → 部署 → 下发
|
||
|
||
|
||
---
|
||
|
||
## ⚙️ 七、非功能性需求（NFR Support）
|
||
|
||
|类别|架构应对方式|
|
||
|---|---|
|
||
|**性能**|中央计算 + DDS 实时通信|
|
||
|**安全**|端到端加密 + OTA 签名验证|
|
||
|**可靠性**|模块冗余 + 服务回退机制|
|
||
|**可维护性**|模块化服务与标准化接口|
|
||
|**可测试性**|仿真测试 + 数字孪生验证|
|
||
|**可扩展性**|微服务 + K8s 弹性伸缩|
|
||
|**合规性**|数据脱敏 + 日志审计|
|
||
|
||
---
|
||
|
||
## 🧭 八、架构演化路线（Architecture Evolution Roadmap）
|
||
|
||
|阶段|架构形态|关键演进|
|
||
|---|---|---|
|
||
|**V1 分域架构**|多ECU、功能分散|向域控制器集中|
|
||
|**V2 域融合架构**|多域整合、服务化|引入DDS与SOA|
|
||
|**V3 中央计算架构（当前）**|单一计算平台 + 容器化服务|实现统一调度与OTA|
|
||
|**V4 智能体架构（目标）**|大模型驱动、自演化系统|云车协同AI原生架构|
|
||
|
||
---
|
||
|
||
## 🔍 九、系统分析要点（Analyst Summary）
|
||
|
||
|分析维度|关键结论|
|
||
|---|---|
|
||
|**系统类型**|分布式智能系统（Cyber-Physical + Cloud）|
|
||
|**通信模型**|异步事件驱动 + 服务编排|
|
||
|**核心驱动**|数据闭环与模型持续学习|
|
||
|**解耦策略**|SOA / 微服务 / DDS 消息总线|
|
||
|**安全架构**|PKI + OTA签名 + 可信执行环境|
|
||
|**研发体系**|DevOps + MLOps + Digital Twin|
|
||
|**关键特征**|数据驱动、AI原生、自演化|
|
||
|
||
---
|
||
|
||
## 🧩 十、总结（Summary）
|
||
|
||
> 小鹏汽车的系统架构是一种 **数据驱动 + 服务化 + AI原生** 的分布式智能体系。
|
||
> 它的本质是通过云车数据闭环实现智能进化：
|
||
|
||
**软件定义汽车 = 数据流动 + 模型迭代 + OTA持续交付**
|
||
|
||
架构目标：
|
||
|
||
- 解耦与复用；
|
||
|
||
- 实时与可靠；
|
||
|
||
- 安全与演化。
|
||
|