第4章：软件架构与SOA
🟢 入门理解
TCU的软件就像一个多层蛋糕。 最底层是硬件（芯片和电路板），中间层是操作系统（负责管理CPU、内存等资源），再往上是中间件（负责把各层连接起来），最顶层是应用程序（真正干活的：远程控制、OTA升级、诊断等）。
操作系统管理硬件资源，中间件提供通信桥梁，应用程序实现具体业务功能——三层各司其职，共同构成TCU的软件世界。
4A 软件栈全景
4A.1 分层架构概览
TCU软件栈从底到顶可分为五层：
|
层次 |
典型技术 |
职责 |
|---|---|---|
|
BSP/HAL |
芯片厂商SDK、MCAL |
屏蔽硬件差异，提供统一硬件访问接口 |
|
操作系统 |
FreeRTOS、Linux、QNX |
任务调度、内存管理、进程/线程隔离 |
|
AUTOSAR CP/AP |
Classic BSW、Adaptive Platform |
标准化基础软件框架，提供COM/Diag/NvM等服务 |
|
中间件 |
SOME/IP、DDS、MQTT Client |
面向服务通信、云端连接、消息路由 |
|
应用层 |
SWC（CommM、OTAM等） |
实现具体业务逻辑 |
4A.2 完整软件栈架构图
4A.3 多核与多OS部署策略
现代TCU SoC通常采用异构多核架构：
-
安全核（Lock-step MCU）：运行FreeRTOS + AUTOSAR CP，处理CAN通信、UDS诊断等安全关键任务
-
性能核（Application Core）：运行Linux/QNX + AUTOSAR AP，处理OTA、V2X、AI推理等复杂应用
-
通信核（Modem Core）：运行专用RTOS，管理4G/5G蜂窝链路
4B AUTOSAR Classic Platform
4B.1 BSW模块全景
AUTOSAR Classic Platform的BSW（Basic Software）是标准化的基础软件框架，按层次组织：
服务层（Services Layer）：
|
模块 |
全称 |
功能 |
|---|---|---|
|
COM |
Communication |
信号级通信抽象，I-PDU打包/解包 |
|
PduR |
PDU Router |
PDU路由，连接COM与底层通信栈 |
|
DCM |
Diagnostic Communication Manager |
UDS诊断服务处理（0x10/0x22/0x27/0x2E/0x31/0x34-0x37等） |
|
DEM |
Diagnostic Event Manager |
DTC存储、冻结帧管理、事件去抖 |
|
NvM |
Non-volatile Memory Manager |
非易失存储管理，支持ROM/EEPROM/Flash抽象 |
|
EcuM |
ECU State Manager |
ECU启动/关机/睡眠状态管理 |
|
BswM |
BSW Mode Manager |
模式仲裁，根据条件切换系统模式 |
|
ComM |
Communication Manager |
通信通道状态管理（Full/No/Silent Com） |
|
FiM |
Function Inhibition Manager |
基于DTC的功能抑制 |
ECU抽象层 & MCAL：
|
模块 |
接口 |
功能 |
|---|---|---|
|
CanIf |
CAN Interface |
CAN驱动抽象 |
|
EthIf |
Ethernet Interface |
以太网驱动抽象 |
|
CanSM |
CAN State Manager |
CAN通道状态机（Bus-Off恢复等） |
|
TcpIp |
TCP/IP Stack |
TCP/UDP/IP协议栈 |
|
SoAd |
Socket Adaptor |
Socket抽象层，连接PDU Router与TCP/IP |
|
DoIP |
Diagnostics over IP |
ISO 13400协议实现 |
|
CanMCAL |
CAN Driver |
CAN控制器寄存器级驱动 |
|
EthMCAL |
Ethernet Driver |
以太网MAC/PHY驱动 |
|
SpiMCAL |
SPI Handler |
SPI通信驱动 |
|
UartMCAL |
UART Driver |
串口驱动 |
4B.2 RTE与SWC
RTE（Runtime Environment） 是AUTOSAR的核心，它为SWC提供虚拟总线接口，使SWC与底层BSW解耦：
SWC接口类型：
|
接口类型 |
通信模式 |
典型场景 |
|---|---|---|
|
Sender-Receiver (S/R) |
数据驱动，单向/周期 |
车速信号、温度数据 |
|
Client-Server (C/S) |
请求-响应，同步/异步 |
诊断请求、NvM读写 |
|
Mode-Switch |
模式通知 |
系统模式切换 |
|
Trigger |
事件触发 |
周期任务启动 |
4B.3 TCU典型SWC分解
一个典型TCU的SWC（Software Component）分解如下：
|
SWC |
职责 |
关键接口 |
|---|---|---|
|
CommM（通信管理） |
管理与TSP云端的通信链路，维护心跳，处理上下行消息路由 |
S/R：网络状态；C/S：发送/接收请求 |
|
DiagM（诊断管理） |
管理UDS诊断会话，处理远程诊断请求，管理DTC上报 |
C/S：UDS服务调用；S/R：DTC事件 |
|
OTAM（OTA管理） |
接收云端升级指令，管理差分包下载、校验、刷写流程 |
C/S：升级控制；S/R：进度/状态上报 |
|
RemoteCtrlM（远程控制） |
解析远程指令（锁车/解锁/启动空调等），映射为CAN信号 |
C/S：指令执行；S/R：执行结果 |
|
GNSSM（定位管理） |
读取GNSS模块数据，解析NMEA，计算位置/速度/时间 |
S/R：经纬度、速度、UTC时间 |
|
PowerM（电源管理） |
管理TCU休眠/唤醒策略，KL15/KL30状态监控 |
S/R：电源状态；Mode-Switch：模式切换 |
|
LogM（日志管理） |
管理运行日志的采集、存储、上传 |
C/S：日志写入/查询；S/R：日志状态 |
4C AUTOSAR Adaptive Platform
4C.1 平台架构
AUTOSAR Adaptive Platform（AP）面向高性能SoC，基于POSIX操作系统（Linux或QNX），支持C++14/17开发：
4C.2 关键功能集群详解
ara::com — 面向服务通信框架
ara::com是AP的核心通信中间件，实现SOME/IP协议栈：
-
Service Discovery：自动发现网络上可用的服务实例
-
Proxy/Skeleton模式：客户端通过Proxy发起请求，服务端通过Skeleton接收请求
-
通信模式：Method（同步/异步请求-响应）、Event（发布-订阅）、Field（可读写属性）
ara::ucm — 更新与配置管理
ara::ucm负责软件包的生命周期管理：
|
功能 |
说明 |
|---|---|
|
Software Package Transfer |
从外部源接收软件包 |
|
Software Package Installation |
安装/卸载软件组件 |
|
Activation/Deactivation |
激活或停用已安装的软件 |
|
Rollback |
安装失败时回退到上一版本 |
ara::exec — 执行管理
管理应用的完整生命周期：
Off → Starting → Running → Terminating → Off
↕
Updating (via ara::ucm)4C.3 AP vs CP 对比
|
维度 |
Classic Platform |
Adaptive Platform |
|---|---|---|
|
操作系统 |
AUTOSAR OS / FreeRTOS |
Linux / QNX（POSIX） |
|
编程语言 |
C |
C++14/17 |
|
通信模型 |
信号（Signal） |
服务（Service） |
|
动态性 |
静态配置 |
动态部署、运行时更新 |
|
适用场景 |
安全关键、低延迟 |
复杂计算、高带宽 |
|
典型用例 |
CAN/UDS/NM |
OTA/V2X/AI/HMI |
4D Hybrid AUTOSAR（CP+AP共存）
4D.1 为什么需要混合架构
单一平台无法满足TCU的全部需求：
-
CP的优势：确定性调度、低延迟（<1ms）、ASIL-B/D安全认证成熟
-
AP的优势：动态部署、高算力利用、丰富的生态（Linux库、AI框架）
-
TCU的现实需求：CAN诊断（CP） + OTA升级（AP） + 远程控制（CP映射CAN） + V2X（AP）
4D.2 双系统架构方案
4D.3 IPC跨域通信
CP与AP之间需要可靠的进程间通信（IPC）机制：
|
IPC方案 |
特点 |
适用场景 |
|---|---|---|
|
共享内存 + 信号量 |
最低延迟，需手动同步 |
高频数据交换（传感器数据） |
|
虚拟串口（VirtIO） |
标准化，Hypervisor支持好 |
中等频率命令/响应 |
|
RPC over VirtIO Ethernet |
类网络通信，可复用TCP/IP栈 |
ara::com跨域调用 |
|
OpenAMP（RPMsg） |
轻量级AMP框架，适合MCU-SoC |
MCU核与AP核通信 |
典型数据流示例：远程锁车命令
Cloud → MQTT → [AP域] ara::com → IPC(VirtIO) → [CP域] RemoteCtrlM → COM → CAN → BCM ECU → 锁车4E SOA与面向服务通信
4E.1 SOME/IP协议
SOME/IP（Scalable service-Oriented MiddlewarE over IP） 是车载以太网的主流SOA协议：
|
特性 |
说明 |
|---|---|
|
Service Discovery (SD) |
服务提供方广播Offer Service，消费方Find Service |
|
Method Call |
支持Request/Response和Fire&Forget |
|
Event |
发布-订阅模型，支持Notification |
|
Field |
Getter/Setter/Notifier组合 |
SOME/IP报文结构：
┌──────────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│ Message ID │ Length │ Request ID │ Protocol │ Interface │ Message │
│ (16b) │ (32b) │ (16b) │ Ver(8b) │ Ver(8b) │ Type(8b) │
├──────────┴──────────┴──────────┴──────────┴──────────┼──────────┤
│ Return Code (8b) │ Payload │
└───────────────────────────────────────────────────────┴──────────┘SOME/IP-SD 服务发现流程：
4E.2 DDS（Data Distribution Service）
DDS是另一种面向实时系统的发布-订阅通信中间件：
|
特性 |
DDS |
SOME/IP |
|---|---|---|
|
发现机制 |
自动发现（SPDP/SEDP） |
SD协议 |
|
通信模型 |
以数据为中心的发布-订阅 |
以服务为中心 |
|
QoS策略 |
丰富的QoS（可靠性、持久化、Deadline等） |
基本QoS |
|
实时性 |
强实时保障 |
中等 |
|
典型应用 |
V2X、传感器融合 |
域控通信 |
4E.3 SOA vs 传统CAN信号通信
|
维度 |
CAN信号通信 |
SOA（SOME/IP/DDS） |
|---|---|---|
|
寻址方式 |
信号ID（静态DBC/LDF配置） |
Service ID + Method/Event ID |
|
通信模式 |
周期广播 |
按需请求/事件驱动 |
|
带宽 |
CAN: 500kbps / CAN-FD: 8Mbps |
100Mbps~1Gbps以太网 |
|
扩展性 |
新增信号需改DBC + 重刷所有ECU |
动态服务发现，热插拔 |
|
适合场景 |
实时控制、传感器数据 |
信息娱乐、OTA、V2X |
4F 云端连接（V2C）
4F.1 通信协议对比
|
协议 |
传输层 |
模式 |
带宽 |
适用场景 |
|---|---|---|---|---|
|
MQTT |
TCP |
发布-订阅 |
低（<1KB报文） |
心跳、事件上报、远程指令下发 |
|
HTTPS |
TCP (TLS) |
请求-响应 |
中 |
文件下载（OTA包）、批量数据上传 |
|
DDS |
UDP/TCP |
发布-订阅 |
高 |
实时遥测、V2X |
MQTT QoS等级选择：
|
QoS |
可靠性 |
延迟 |
TCU典型用途 |
|---|---|---|---|
|
0 |
最多一次 |
最低 |
遥测数据上报 |
|
1 |
至少一次 |
中 |
远程控制指令 |
|
2 |
恰好一次 |
最高 |
OTA升级确认 |
4F.2 消息序列化格式
|
格式 |
可读性 |
体积 |
编解码速度 |
典型用途 |
|---|---|---|---|---|
|
JSON |
高 |
大 |
中 |
API交互、配置下发 |
|
Protobuf |
低（二进制） |
小 |
快 |
高频遥测、大批量数据 |
|
CBOR |
低（二进制） |
小 |
快 |
嵌入式受限场景 |
4F.3 设备影子与数字孪生
设备影子（Device Shadow） 是云端维护的设备状态副本：
{
"state": {
"reported": {
"firmware_version": "3.2.1",
"battery_voltage": 12.4,
"gnss_latitude": 39.9042,
"gnss_longitude": 116.4074,
"door_lock_status": "locked",
"last_ota_time": "2026-06-15T08:30:00Z"
},
"desired": {
"target_firmware_version": "3.3.0",
"climate_on": true
}
}
}-
reported：TCU上报的实际状态
-
desired：云端期望的目标状态，TCU读取后执行
-
delta：reported与desired的差异，驱动OTA/控制动作
4F.4 主流IoT平台集成
|
平台 |
协议 |
特点 |
|---|---|---|
|
阿里云IoT |
MQTT (TLS) |
设备影子、OTA服务、规则引擎、国内合规 |
|
AWS IoT Core |
MQTT (TLS) |
Device Shadow、Greengrass边缘计算 |
|
华为IoTDA |
MQTT/CoAP |
设备接入、全球SIM联接、OTA |
4G 远程服务实现（RVC）
4G.1 远程控制命令列表
|
命令 |
CAN目标ECU |
CAN信号示例 |
前置条件 |
|---|---|---|---|
|
远程锁车 |
BCM（车身控制模块） |
DoorLockCmd = LOCK |
车速 = 0, 挡位 = P |
|
远程解锁 |
BCM |
DoorLockCmd = UNLOCK |
车辆处于驻车状态 |
|
远程启动空调 |
HVAC / EMS |
ClimateStartReq = ON |
电池电压 > 11.5V |
|
远程鸣笛 |
BCM |
HornReq = ON（限时5s） |
车速 = 0 |
|
远程闪灯 |
BCM |
HazardLightReq = ON（限时10s） |
无 |
4G.2 命令执行全链路
4G.3 安全机制
|
安全层 |
机制 |
说明 |
|---|---|---|
|
传输层 |
TLS 1.3 |
MQTT/HTTPS加密传输 |
|
应用层认证 |
Token + 签名 |
每条命令携带HMAC-SHA256签名 |
|
防重放 |
Timestamp + Nonce |
命令带时间戳（±30s窗口）+ 一次性随机数 |
|
TCU内部 |
Secure Element |
密钥存储在HSM/SE中，不暴露于软件层 |
|
ECU层 |
SecOC |
CAN报文级认证（可选） |
4H 诊断子系统
4H.1 UDS over IP（DoIP, ISO 13400）
DoIP将以诊断协议（UDS）封装在以太网/IP之上，实现高带宽诊断：
DoIP会话建立流程：
1. Vehicle Identification Request (UDP广播)
2. Vehicle Identification Response (TCU应答VIN/EID)
3. TCP连接建立
4. Routing Activation Request (认证)
5. Routing Activation Response (确认)
6. Diagnostic Message (UDS over TCP)4H.2 DTC管理
|
功能 |
说明 |
|---|---|
|
DTC存储 |
DEM模块将故障码存入NvM，断电不丢失 |
|
冻结帧 |
DTC触发时记录当时的环境数据（车速、温度等） |
|
去抖机制 |
防止偶发故障触发DTC（去抖计数器+时间窗口） |
|
DTC上报 |
通过MQTT/DoIP上报云端或诊断仪 |
|
OTA诊断 |
升级前后自动扫描DTC，确保升级未引入新故障 |
4H.3 诊断服务典型用例
|
UDS服务 |
SID |
TCU典型用途 |
|---|---|---|
|
DiagnosticSessionControl |
0x10 |
切换诊断会话（默认/编程/扩展） |
|
ReadDataByIdentifier |
0x22 |
读取软件版本、硬件序列号 |
|
SecurityAccess |
0x27 |
获取刷写/标定权限（Seed-Key） |
|
WriteDataByIdentifier |
0x2E |
写入配置参数 |
|
RoutineControl |
0x31 |
执行校验/擦除/完整性检查 |
|
RequestDownload |
0x34 |
OTA刷写：请求下载 |
|
TransferData |
0x36 |
OTA刷写：传输数据块 |
|
RequestTransferExit |
0x37 |
OTA刷写：传输完成 |
|
ClearDTC |
0x14 |
清除故障码 |
|
ReadDTCInformation |
0x19 |
读取故障码列表及快照数据 |
4I 启动链（Boot Chain）
4I.1 三阶段启动架构
4I.2 Secure Boot验证流程
每个阶段启动时执行以下验证：
1. 读取待执行镜像的数字签名（RSA-2048 / ECDSA-P256）
2. 从HSM/Secure Element获取对应公钥
3. 计算镜像SHA-256哈希值
4. 用公钥验证签名与哈希匹配
5. 验证通过 → 跳转执行
6. 验证失败 → 进入恢复模式 / 回退到上一版本|
启动阶段 |
存储位置 |
可更新性 |
签名验证 |
失败策略 |
|---|---|---|---|---|
|
Primary BL |
ROM |
不可更新 |
N/A（ROM可信） |
— |
|
Secondary BL |
Flash Bank A/B |
OTA可更新 |
PBL验证 |
回退到备用Bank |
|
Application |
Flash Bank A/B |
OTA可更新 |
SBL验证 |
回退到上一版本 |
4I.3 A/B分区与回退机制
回退策略：
-
启动计数器：Application启动后N秒内需上报Watchdog，否则SBL判定启动失败
-
连续失败阈值：连续3次启动失败则回退到上一版本
-
云端通知：回退事件通过MQTT上报云端
本章小结
|
主题 |
核心要点 |
|---|---|
|
软件栈全景 |
BSP → OS → AUTOSAR → Middleware → App 五层架构 |
|
AUTOSAR CP |
BSW模块（COM/DCM/DEM/NvM等）+ RTE + SWC，面向CAN/UDS安全关键域 |
|
AUTOSAR AP |
POSIX OS + ara::com/diag/ucm，面向高性能计算域 |
|
混合架构 |
CP处理安全关键，AP处理复杂应用，通过Hypervisor+IPC共存 |
|
SOA通信 |
SOME/IP服务发现+方法/事件，DDS实时发布-订阅 |
|
云端连接 |
MQTT为主协议，设备影子管理状态，支持阿里/AWS/华为IoT平台 |
|
远程服务 |
全链路安全：TLS+Token+防重放+HSM，命令经CP域映射CAN信号执行 |
|
诊断子系统 |
DoIP(UDS over IP) + DTC管理 + OTA诊断 |
|
启动链 |
三级安全启动 + A/B分区回退保障升级安全 |
下一章预告： 第五章将深入讲解通信协议栈，包括CAN/CAN-FD/LIN/以太网的协议细节与测试方法。
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)