第4章：软件架构与SOA

卵男（章鱼）2026-07-13 10:20

🟢 入门理解

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/以太网的协议细节与测试方法。

相关推荐
是摆烂第一名呀2 小时前
【RK3506】RGB屏幕与背光调试记录
linux·arm开发·驱动开发·嵌入式硬件
qetfw2 小时前
CentOS 7 搭建 DNS 主从服务
linux·运维·centos·dns·bind
卵男（章鱼）2 小时前
第3章：硬件架构与芯片方案
车载系统·汽车·硬件架构
JustNow_Man2 小时前
【Claude Code】 中给 Python + XML 项目建立可靠验证体系
xml·linux·python
CodeStats2 小时前
【Linux IO】从文件描述符到硬件中断:Linux IO 系统底层完全拆解
java·linux·开发语言·io·socket
日取其半万世不竭3 小时前
Palworld 服务器内存越跑越高？重启计划和存档保护怎么做
linux·运维·服务器·vps·幻兽帕鲁·palworld
kyle~3 小时前
Linux---Snap（隔离式Linux 软件分发范式）
linux·运维·网络
老约家的可汗3 小时前
Linux中基础IO
linux·服务器·算法
热门推荐
01GitHub 镜像站点02AI科技热点日报 | 2026年07月01日03幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南042026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片052026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf062026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？07AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路082026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？09GPT-5.5 对比 GPT-5.6 Sol、Terra、Luna：官方性能数据与选型分析102026 年 AI 大模型 & AI 编程工具实战全总结