317 lines
7.2 KiB
Markdown
317 lines
7.2 KiB
Markdown
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
```markdown
|
|||
|
|
# 小鹏汽车数据流向与系统架构分析
|
|||
|
|
*面向系统分析员 · {{date}}*
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 🧭 一、总体说明（Overview）
|
|||
|
|
|
|||
|
|
> 小鹏汽车的软件体系是一套“以数据流为核心”的智能系统。
|
|||
|
|
> 系统所有功能（自动驾驶、座舱AI、云端训练、OTA）均围绕数据生命周期展开。
|
|||
|
|
|
|||
|
|
数据闭环由以下阶段组成：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
生成 → 采集 → 上传 → 存储 → 处理 → 学习 → 部署 → 执行 → 反馈
|
|||
|
|
|
|||
|
|
````
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 🚘 二、数据流向全景（End-to-End Data Flow）
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
flowchart LR
|
|||
|
|
A[车辆传感器与控制系统] --> B[车端计算与中间件]
|
|||
|
|
B --> C[Telemetry Agent]
|
|||
|
|
C --> D[云端数据接入层]
|
|||
|
|
D --> E[数据湖与特征仓库]
|
|||
|
|
E --> F[AI训练与仿真验证平台]
|
|||
|
|
F --> G[模型注册与OTA系统]
|
|||
|
|
G --> H[OTA分发至车辆]
|
|||
|
|
H --> I[车辆执行与运行反馈]
|
|||
|
|
I --> D
|
|||
|
|
````
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 🧩 三、数据生命周期分析（Data Lifecycle）
|
|||
|
|
|
|||
|
|
### 1️⃣ 数据生成（On-Vehicle Generation）
|
|||
|
|
|
|||
|
|
**来源：**
|
|||
|
|
|
|||
|
|
- 感知层：Camera、LiDAR、Radar、IMU、GPS
|
|||
|
|
|
|||
|
|
- 控制层：加速度、制动、转向、功率数据
|
|||
|
|
|
|||
|
|
- 座舱层：语音指令、界面交互、AI助手行为
|
|||
|
|
|
|||
|
|
- 系统层：XOS 日志、诊断数据、错误码
|
|||
|
|
|
|||
|
|
|
|||
|
|
**数据类型：**
|
|||
|
|
|
|||
|
|
|类别|说明|特征|
|
|||
|
|
|---|---|---|
|
|||
|
|
|感知数据|图像、点云、环境感知|高频、原始体量大|
|
|||
|
|
|车辆状态|控制信号、CAN 报文|实时性要求极高|
|
|||
|
|
|用户交互|语音、触控、行为日志|可匿名化上传|
|
|||
|
|
|系统日志|软件状态与错误码|用于稳定性评估|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 2️⃣ 数据处理与分发（Vehicle Computing）
|
|||
|
|
|
|||
|
|
- 感知栈（Perception Stack）执行 XNet 模型推理；
|
|||
|
|
|
|||
|
|
- 规划栈（Planning Stack）生成轨迹与控制策略；
|
|||
|
|
|
|||
|
|
- DDS（RTI Connext Drive）实现模块间异步消息传递；
|
|||
|
|
|
|||
|
|
- 重要事件由 **Telemetry Agent** 抽样上传。
|
|||
|
|
|
|||
|
|
|
|||
|
|
**实时路径：**
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Sensors → Perception → Fusion → Planning → Control
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**本地缓存策略：**
|
|||
|
|
|
|||
|
|
- 高频短期缓存（RAM）
|
|||
|
|
|
|||
|
|
- 关键片段写入本地Flash（用于回传）
|
|||
|
|
|
|||
|
|
- 事件触发上传机制（低频）
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 3️⃣ 数据上行（Vehicle → Cloud）
|
|||
|
|
|
|||
|
|
**通信协议：** MQTT / HTTPS / gRPC
|
|||
|
|
**网络层：** 5G / LTE / V2X
|
|||
|
|
**安全层：** TLS + PKI + 签名验证
|
|||
|
|
|
|||
|
|
**上报数据包括：**
|
|||
|
|
|
|||
|
|
- 感知片段与异常场景
|
|||
|
|
|
|||
|
|
- 驾驶日志与控制参数
|
|||
|
|
|
|||
|
|
- 车辆状态与健康信息
|
|||
|
|
|
|||
|
|
- 用户交互与座舱事件
|
|||
|
|
|
|||
|
|
- 软件运行与错误日志
|
|||
|
|
|
|||
|
|
|
|||
|
|
**云端接入流程：**
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Vehicle → API Gateway → Kafka → Flink/Spark → Data Lake
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
- Kafka：高并发数据流缓冲
|
|||
|
|
|
|||
|
|
- Flink：实时聚合与清洗
|
|||
|
|
|
|||
|
|
- Metadata Service：管理数据标签与时间戳
|
|||
|
|
|
|||
|
|
- Validation Service：完整性与签名验证
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 4️⃣ 数据存储与管理（Data Lake & Feature Store）
|
|||
|
|
|
|||
|
|
**数据分层：**
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
raw/ → 原始传感器数据
|
|||
|
|
processed/ → 清洗与对齐后的数据
|
|||
|
|
features/ → 特征化结果
|
|||
|
|
models/ → 模型输出与版本
|
|||
|
|
logs/ → 系统运行记录
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**管理策略：**
|
|||
|
|
|
|||
|
|
- Schema-on-Read 模式（灵活扩展）
|
|||
|
|
|
|||
|
|
- 按时间、车型、场景分区
|
|||
|
|
|
|||
|
|
- 数据血缘追踪与元数据索引
|
|||
|
|
|
|||
|
|
- 隐私合规（GDPR / 数据出境审计）
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 5️⃣ 数据学习与建模（AI Training & Simulation）
|
|||
|
|
|
|||
|
|
**训练流程：**
|
|||
|
|
|
|||
|
|
1. 数据清洗与增强（Data Cleaning & Augmentation）
|
|||
|
|
|
|||
|
|
2. 特征提取与标签化（Feature Engineering）
|
|||
|
|
|
|||
|
|
3. 模型训练（Distributed GPU, PyTorch / TensorFlow）
|
|||
|
|
|
|||
|
|
4. 仿真验证（Carla / Unity / OpenSCENARIO）
|
|||
|
|
|
|||
|
|
5. 模型注册与评估（MLflow / Kubeflow）
|
|||
|
|
|
|||
|
|
|
|||
|
|
**云端架构：**
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Data Lake → Feature Store → Training Cluster → Model Registry
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
- MLOps：实现模型版本控制与持续训练
|
|||
|
|
|
|||
|
|
- 分布式计算：Ray / Horovod
|
|||
|
|
|
|||
|
|
- 模型评估：自动化指标测试、精度报告生成
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 6️⃣ 模型与软件下发（Cloud → Vehicle）
|
|||
|
|
|
|||
|
|
**OTA 下发机制：**
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Model Registry → OTA Service → CDN Edge → Vehicle OTA Agent
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
- 分模块差分更新（模型、应用、固件分离）
|
|||
|
|
|
|||
|
|
- 灰度发布机制（按车型/地区批量推送）
|
|||
|
|
|
|||
|
|
- 签名校验 + HSM 保障完整性
|
|||
|
|
|
|||
|
|
- 热重载与回滚机制保证安全性
|
|||
|
|
|
|||
|
|
|
|||
|
|
**车端行为：**
|
|||
|
|
|
|||
|
|
- XOS 校验包完整性
|
|||
|
|
|
|||
|
|
- OTA Manager 调度模块重启或模型替换
|
|||
|
|
|
|||
|
|
- 上报更新结果至云端（Update Report）
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 7️⃣ 数据反馈与闭环优化（Feedback & Continuous Learning）
|
|||
|
|
|
|||
|
|
闭环目标：形成 **自演化 AI 系统**
|
|||
|
|
即车辆使用数据 → 云端优化 → OTA 更新 → 再次反馈
|
|||
|
|
|
|||
|
|
|阶段|输入|输出|作用|
|
|||
|
|
|---|---|---|---|
|
|||
|
|
|运行阶段|实际驾驶数据|异常样本|数据补充|
|
|||
|
|
|分析阶段|大规模日志|优化场景集|精准再训练|
|
|||
|
|
|训练阶段|特征数据|新模型|性能提升|
|
|||
|
|
|部署阶段|模型/软件包|OTA 更新|功能增强|
|
|||
|
|
|反馈阶段|实际指标|改进决策|自我优化|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## ☁️ 四、系统架构支撑视图（Architecture Support View）
|
|||
|
|
|
|||
|
|
### 架构逻辑
|
|||
|
|
|
|||
|
|
小鹏的架构以数据流为主线，通过以下系统支撑：
|
|||
|
|
|
|||
|
|
1. **车端：实时计算与分布式通信**
|
|||
|
|
|
|||
|
|
- 构建 SOA 化车载平台（DDS + 容器化）
|
|||
|
|
|
|||
|
|
- 以中间件实现“数据即服务”
|
|||
|
|
|
|||
|
|
2. **云端：数据与模型生命周期管理**
|
|||
|
|
|
|||
|
|
- 数据湖 → 特征仓库 → 模型训练 → OTA
|
|||
|
|
|
|||
|
|
3. **研发支撑：CI/CD + MLOps**
|
|||
|
|
|
|||
|
|
- 形成从代码、模型到数据的统一流水线
|
|||
|
|
|
|||
|
|
4. **安全与合规体系**
|
|||
|
|
|
|||
|
|
- 全链路加密、身份认证、隐私治理
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 架构分层（系统视图）
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
graph TD
|
|||
|
|
subgraph Vehicle
|
|||
|
|
V1[传感器与控制] --> V2[感知/融合/规划模块]
|
|||
|
|
V2 --> V3[DDS中间件通信层]
|
|||
|
|
V3 --> V4[XOS操作系统]
|
|||
|
|
end
|
|||
|
|
subgraph Cloud
|
|||
|
|
C1[API Gateway / Kafka]
|
|||
|
|
C1 --> C2[数据湖 & 特征仓库]
|
|||
|
|
C2 --> C3[AI训练与仿真平台]
|
|||
|
|
C3 --> C4[Model Registry / OTA Service]
|
|||
|
|
end
|
|||
|
|
subgraph DevOps
|
|||
|
|
D1[CI/CD + MLOps Pipeline]
|
|||
|
|
D1 --> C3
|
|||
|
|
end
|
|||
|
|
V3 --> C1
|
|||
|
|
C4 --> V4
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 🧮 五、系统分析要点（System Analyst Focus）
|
|||
|
|
|
|||
|
|
|分析维度|说明|
|
|||
|
|
|---|---|
|
|||
|
|
|**数据流向**|架构的主线；所有系统围绕数据生命周期设计|
|
|||
|
|
|**边界清晰**|车端与云端通过安全通道分离职责|
|
|||
|
|
|**解耦性**|车内 DDS 与云端微服务相互独立|
|
|||
|
|
|**一致性策略**|数据与模型版本同步控制|
|
|||
|
|
|**非功能性关注**|实时性、安全性、可靠性、可扩展性|
|
|||
|
|
|**演化能力**|架构支持快速OTA与模型迭代|
|
|||
|
|
|**治理与合规**|全链路审计、数据脱敏与访问控制|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 🔁 六、总结（Summary）
|
|||
|
|
|
|||
|
|
> 从数据流角度看，小鹏的软件系统是一个以 **数据驱动决策与学习** 为核心的闭环架构。
|
|||
|
|
|
|||
|
|
**核心特征：**
|
|||
|
|
|
|||
|
|
- 数据是系统的主导对象；
|
|||
|
|
|
|||
|
|
- 架构的所有层次都服务于数据流动；
|
|||
|
|
|
|||
|
|
- 软件更新是数据反馈的自然结果；
|
|||
|
|
|
|||
|
|
- 系统目标是实现“持续学习、持续优化、持续交付”。
|
|||
|
|
|
|||
|
|
|
|||
|
|
最终实现：
|
|||
|
|
|
|||
|
|
> **Software Defined Vehicle = Data Driven + Model Driven + Continuous Evolution**
|
|||
|
|
|
|||
|
|
---
|