一、一辆汽车里有多少个电脑现代汽车早已不是简单的机械装置而是一个移动的计算中心。惊人的数字车型级别ECU 数量代码行数经济型轿车30-50 个1 亿行中高端轿车50-80 个1.5 亿行豪华/电动车80-150 个2 亿行对比一架波音 787 客机只有约 1400 万行代码这些 ECU 都在做什么汽车 ECU 分布示例 ┌─────────────────────────────────────────────────────────┐ │ 车身控制域 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 车门控制 │ │ 车窗控制 │ │ 座椅控制 │ │ 空调控制 │ │ │ │ (ECU) │ │ (ECU) │ │ (ECU) │ │ (ECU) │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ ├─────────────────────────────────────────────────────────┤ │ 动力系统域 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 引擎控制 │ │ 变速箱 │ │ 电池管理 │ │ 电机控制 │ │ │ │ (ECU) │ │ (ECU) │ │ (BMS) │ │ (ECU) │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ ├─────────────────────────────────────────────────────────┤ │ 底盘控制域 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 刹车控制 │ │ 转向控制 │ │ 悬挂控制 │ │ 稳定控制 │ │ │ │ (ABS) │ │ (EPS) │ │ (ECU) │ │ (ESC) │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ ├─────────────────────────────────────────────────────────┤ │ 信息娱乐域 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 中控大屏 │ │ 仪表盘 │ │ 导航系统 │ │ 音响系统 │ │ │ │ (IVI) │ │ (IC) │ │ (ECU) │ │ (ECU) │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ ├─────────────────────────────────────────────────────────┤ │ 智能驾驶域 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 摄像头 │ │ 雷达 │ │ 激光雷达 │ │ 自动驾驶 │ │ │ │ (ECU) │ │ (ECU) │ │ (ECU) │ │ (ECU) │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ └─────────────────────────────────────────────────────────┘二、为什么需要分 Primary 和 Secondary问题的复杂性如果每个 ECU 都独立去服务器下载更新❌ 方案 1每个 ECU 独立更新 ┌─────────┐ ┌─────────┐ ┌─────────┐ │ ECU 1 │◄───►│ ECU 2 │◄───►│ ECU 3 │ │ (独立) │ 网 │ (独立) │ 网 │ (独立) │ └────┬────┘ 络 └────┬────┘ 络 └────┬────┘ │ │ │ └──────────────┼──────────────┘ ▼ ┌─────────────┐ │ 4G/5G │ ← 50 个 ECU 同时下载 │ 网络 │ 带宽爆炸、费用高昂 └─────────────┘问题 流量费用50 个 ECU × 1GB 固件 50GB 流量/次更新 网络拥塞同时下载导致速度极慢 安全风险50 个攻击面每个都要保护⚡ 功耗问题同时联网耗电巨大Uptane 的解决方案主从架构✅ 方案 2Primary Secondary 架构 ┌─────────────────────────────────────────┐ │ Primary ECU (主) │ │ ┌─────────┐ ┌─────────┐ │ │ │ 网络模块 │ │ OTA客户端 │ │ │ │ (4G/5G) │ │aktualizr│ │ │ └────┬────┘ └────┬────┘ │ │ │ │ │ │ └──────────────┘ │ │ │ │ │ ┌──────┴──────┐ │ │ ▼ ▼ │ │ ┌─────────┐ ┌─────────────┐ │ │ │ 下载更新 │ │ 验证并分发 │ │ │ │ 从服务器 │ │ 给 Secondary│ │ │ └─────────┘ └─────────────┘ │ └────────┬────────────────────────────────┘ │ 车内网络 (CAN/LIN/Ethernet) │ ┌────┴────┬────────┬────────┐ ▼ ▼ ▼ ▼ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ │ ECU 1 │ │ ECU 2 │ │ ECU 3 │ │ ECU n │ │(Secondary)│(Secondary)│(Secondary)│(Secondary)│ │ 刹车 │ │ 转向 │ │ 空调 │ │ 其他 │ └───────┘ └───────┘ └───────┘ └───────┘优势✅ 只有一个设备联网节省流量✅ 集中管理安全减少攻击面✅ 车内网络更快更稳定✅ Secondary 可以更简单、更便宜三、Primary ECU更新的指挥官核心职责Primary ECU 的五大职责 ┌─────────────────────────────────────────┐ │ 1. 网络通信 │ │ • 连接 OTA 服务器 │ │ • 下载元数据和固件 │ │ • 上报设备状态和安装结果 │ ├─────────────────────────────────────────┤ │ 2. 安全验证 │ │ • 验证 Uptane 元数据签名 │ │ • 检查固件完整性哈希 │ │ • 防回滚、防重放攻击 │ ├─────────────────────────────────────────┤ │ 3. 更新决策 │ │ • 决定何时下载更新 │ │ • 决定何时安装更新 │ │ • 处理用户确认如果需要 │ ├─────────────────────────────────────────┤ │ 4. 分发管理 │ │ • 将固件分发给各个 Secondary │ │ • 管理分发进度和状态 │ │ • 处理 Secondary 的响应 │ ├─────────────────────────────────────────┤ │ 5. 安装协调 │ │ • 协调多 ECU 的安装顺序 │ │ • 处理安装失败和回滚 │ │ • 生成安装报告 │ └─────────────────────────────────────────┘硬件要求资源典型配置原因处理器ARM Cortex-A53/A72运行 Linux处理加密内存512MB - 2GB存储固件、运行 aktualizr存储4GB eMMC/SD存放数据库、缓存固件网络4G/5G WiFi连接 OTA 服务器安全HSM/TEE保护密钥和加密操作典型实例特斯拉中央计算模块CCM大众ICAS3In Car Application Server通用VIPVehicle Intelligence Platform四、Secondary ECU更新的执行者两种类型的 SecondaryUptane 根据计算能力将 Secondary 分为两类┌─────────────────────────────────────────────────────┐ │ Full Verification Secondary │ │ (完整验证型 Secondary) │ ├─────────────────────────────────────────────────────┤ │ 能力 │ │ • 完整的 Uptane 元数据验证 │ │ • 独立验证固件签名和哈希 │ │ • 支持复杂的加密操作 │ │ │ │ 硬件要求 │ │ • 较强的处理器ARM Cortex-M4/A 系列 │ │ • 较大的内存256KB RAM, 1MB Flash │ │ • 可以运行完整的 Uptane 客户端库 │ │ │ │ 示例 │ │ • 信息娱乐系统 │ │ • 自动驾驶控制器 │ │ • 高级车身控制器 │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ Partial Verification Secondary │ │ (部分验证型 Secondary) │ ├─────────────────────────────────────────────────────┤ │ 能力 │ │ • 验证固件哈希从 Primary 接收 │ │ • 简单的版本号检查 │ │ • 依赖 Primary 进行完整的 Uptane 验证 │ │ │ │ 硬件要求 │ │ • 有限的处理器ARM Cortex-M0/M3 │ │ • 较少的内存256KB RAM, 1MB Flash │ │ • 只能运行轻量级代码 │ │ │ │ 示例 │ │ • 车窗控制器 │ │ • 座椅控制器 │ │ • 简单的传感器 ECU │ └─────────────────────────────────────────────────────┘核心职责Secondary ECU 的三大职责 ┌─────────────────────────────────────────┐ │ 1. 接收固件 │ │ • 从 Primary 接收固件数据 │ │ • 本地存储通常写入临时区域 │ │ • 验证数据完整性哈希检查 │ ├─────────────────────────────────────────┤ │ 2. 安装固件 │ │ • 将固件写入目标区域Flash │ │ • 更新版本号 │ │ • 重启如果需要 │ ├─────────────────────────────────────────┤ │ 3. 报告状态 │ │ • 向 Primary 报告当前版本 │ │ • 报告安装成功/失败 │ │ • 提供诊断信息 │ └─────────────────────────────────────────┘五、Primary 与 Secondary 的通信协议通信方式车内网络类型 ┌─────────────────────────────────────────┐ │ CAN (Controller Area Network) │ │ • 速度125Kbps - 1Mbps │ │ • 用途传统汽车控制刹车、引擎 │ │ • 特点可靠、实时、低成本 │ │ • 限制带宽低、数据包小8字节 │ ├─────────────────────────────────────────┤ │ CAN FD (Flexible Data-rate) │ │ • 速度最高 8Mbps │ │ • 用途新一代汽车网络 │ │ • 特点向后兼容 CAN带宽更高 │ │ • 限制仍有一定限制 │ ├─────────────────────────────────────────┤ │ LIN (Local Interconnect Network) │ │ • 速度最高 20Kbps │ │ • 用途低成本传感器、执行器 │ │ • 特点极低成本、单线通信 │ │ • 限制速度很慢 │ ├─────────────────────────────────────────┤ │ Ethernet │ │ • 速度100Mbps - 1Gbps │ │ • 用途ADAS、信息娱乐、OTA │ │ • 特点高带宽、标准协议 │ │ • 限制成本较高、需要交换机 │ └─────────────────────────────────────────┘Uptane 的 Secondary 协议Uptane 定义了标准化的 Primary-Secondary 通信协议通信消息类型 ┌─────────────────────────────────────────┐ │ 1. Discovery发现 │ │ Primary: 有哪些 Secondary 在线 │ │ Secondary: 我在这里我的信息是... │ ├─────────────────────────────────────────┤ │ 2. Metadata Distribution元数据分发 │ │ Primary: 这是最新的 Uptane 元数据 │ │ Secondary: 收到验证通过/失败 │ ├─────────────────────────────────────────┤ │ 3. Firmware Distribution固件分发 │ │ Primary: 这是给你的固件分片发送 │ │ Secondary: 收到第 X 片校验正确 │ ├─────────────────────────────────────────┤ │ 4. Installation Request安装请求 │ │ Primary: 请安装这个固件 │ │ Secondary: 安装成功/失败原因是... │ ├─────────────────────────────────────────┤ │ 5. Status Report状态报告 │ │ Secondary: 我的当前版本是... │ │ Primary: 收到已记录 │ └─────────────────────────────────────────┘ASN.1 消息格式Uptane 使用 ASN.1Abstract Syntax Notation One定义消息格式-- 简化的 Secondary 消息定义 SecondaryMessage :: CHOICE { discoveryRequest [0] DiscoveryRequest, discoveryResponse [1] DiscoveryResponse, firmwareRequest [2] FirmwareRequest, firmwareResponse [3] FirmwareResponse, ... } DiscoveryResponse :: SEQUENCE { ecuSerial UTF8String, hardwareId UTF8String, currentVersion INTEGER, supportedTypes SEQUENCE OF UTF8String } FirmwareRequest :: SEQUENCE { ecuSerial UTF8String, targetFilename UTF8String, offset INTEGER, -- 用于断点续传 chunkSize INTEGER }六、aktualizr 中的实现代码架构aktualizr 中的 Primary/Secondary 实现 src/ ├── aktualizr_primary/ # Primary ECU 主程序 │ └── main.cc ├── aktualizr_secondary/ # Secondary ECU 主程序 │ └── main.cc ├── libaktualizr/ │ ├── primary/ # Primary 相关代码 │ │ ├── aktualizr.cc # 主类实现 │ │ ├── sotauptaneclient.cc # Uptane 客户端 │ │ └── secondary.cc # Secondary 管理 │ └── secondary/ # Secondary 相关代码 │ ├── secondary_interface.h # 接口定义 │ ├── ipc_secondary.cc # IPC 实现 │ ├── socket_secondary.cc # Socket 实现 │ └── ...关键类解析Primary 端SecondaryInterface// 简化版接口定义classSecondaryInterface{public:virtual~SecondaryInterface()default;// 发现 Secondaryvirtualstd::stringgetSerial()0;virtualstd::stringgetHwId()0;// 发送元数据virtualboolsendMetadata(constUptane::MetaCollectionmeta)0;// 发送固件virtualboolsendFirmware(conststd::stringfilename,conststd::stringdata)0;// 安装请求virtualdata::ResultCodeinstall()0;// 获取状态virtualSecondary::VersiongetVersion()0;};Secondary 端AktualizrSecondary// Secondary 主类classAktualizrSecondary{public:// 初始化voidinitialize();// 处理 Primary 的请求voidhandleDiscovery();voidhandleMetadata(constUptane::MetaCollectionmeta);voidhandleFirmware(conststd::stringdata);voidhandleInstall();// 验证根据类型boolverifyMetadata(constUptane::MetaCollectionmeta);boolverifyFirmware(conststd::stringdata);private:SecondaryConfig config_;// 配置INvStoragestorage_;// 存储KeyManagerkeys_;// 密钥管理};七、动手实验配置虚拟 Secondary实验 1查看 Secondary 配置cd~/test/aktualizr/demo# 查看虚拟 Secondary 配置文件catvirtualsec.json输出示例{virtual:[{ecu_serial:demo-vsec1,ecu_hardware_id:demo-virtual,partial_verifying:false,ecu_private_key:sec.private,ecu_public_key:sec.public,firmware_path:storage/demo-vsec1/firmware.bin,metadata_path:storage/demo-vsec1/metadata,target_name_path:storage/demo-vsec1/target_name}]}实验 2启动带 Secondary 的 aktualizrcd~/test/aktualizr/demo# 确保目录结构正确mkdir-pstorage/demo-vsec1/metadatachmod-R700storage/# 查看配置文件catsota-local.toml配置内容[provision] mode AutoProvision primary_ecu_hardware_id local-fake [logger] loglevel 1 [storage] path storage type sqlite [pacman] type none images_path storage/images [uptane] secondary_config_file virtualsec.json # 关键配置实验 3运行并观察cd~/test/aktualizr/demo# 运行 aktualizr单次模式sudo../build/src/aktualizr_primary/aktualizr--configsota-local.toml once观察输出Initializing virtual Secondaries... Adding Secondary with ECU serial: demo-vsec1 with hardware ID: demo-virtual ...实验 4配置多个 Secondarycd~/test/aktualizr/demo# 创建多 Secondary 配置catvirtualsec-multi.jsonEOF { virtual: [ { ecu_serial: demo-vsec1, ecu_hardware_id: demo-virtual, partial_verifying: false, ecu_private_key: sec1.private, ecu_public_key: sec1.public, firmware_path: storage/demo-vsec1/firmware.bin, metadata_path: storage/demo-vsec1/metadata, target_name_path: storage/demo-vsec1/target_name }, { ecu_serial: demo-vsec2, ecu_hardware_id: demo-virtual-2, partial_verifying: true, ecu_private_key: sec2.private, ecu_public_key: sec2.public, firmware_path: storage/demo-vsec2/firmware.bin, metadata_path: storage/demo-vsec2/metadata, target_name_path: storage/demo-vsec2/target_name } ] } EOF# 创建目录mkdir-pstorage/demo-vsec2/metadatachmod-R700storage/# 修改配置使用新文件sed-is/virtualsec.json/virtualsec-multi.json/sota-local.toml# 运行sudo../build/src/aktualizr_primary/aktualizr--configsota-local.toml once八、本章小结核心概念回顾概念一句话解释ECU电子控制单元汽车里的小电脑Primary ECU主 ECU负责联网、验证、分发更新Secondary ECU次 ECU从 Primary 接收并安装更新Full Verification完整验证能独立验证所有 Uptane 元数据Partial Verification部分验证依赖 Primary 进行主要验证车内网络CAN/CAN FD/LIN/Ethernet连接各个 ECU架构优势Primary Secondary 架构的优势 ✅ 安全性 • 只有一个联网点减少攻击面 • 集中管理安全策略和密钥 ✅ 经济性 • Secondary 可以更简单、更便宜 • 节省流量费用只下载一次 ✅ 可靠性 • 车内网络比公网更稳定 • 可以协调多 ECU 的更新顺序 ✅ 灵活性 • 支持不同能力的 ECU • 可以混合使用不同验证级别下一步在下一篇文章《动手搭建第一个 OTA 客户端——aktualizr 编译与运行》中我们将完整编译 aktualizr 项目配置并运行第一个可用的 demo理解配置文件的每个参数排查常见问题九、延伸阅读与资源官方文档Uptane 部署指南: https://uptane.github.io/deployment/best-practices.htmlaktualizr Secondary 文档:docs/ota-client-guide/modules/ROOT/pages/virtual-secondaries.adoc推荐阅读《汽车电子架构演进》了解域控制器架构《CAN 总线协议详解》了解车内通信思考题为什么 Full Verification Secondary 需要更强的硬件设计一个场景如果 Primary ECU 被攻破Secondary 如何保护自己在电动车中BMS电池管理系统应该作为 Primary 还是 Secondary为什么目标读者理解基础概念的开发者上一篇《Uptane 安全框架初探——比 HTTPS 更安全的更新机制》下一篇《动手搭建第一个 OTA 客户端——aktualizr 编译与运行》希望这篇文章让你理解了 Primary/Secondary 架构的设计思想。有任何问题欢迎在评论区留言讨论
Uptane OTA入门（3）：Primary 与 Secondary ECU——汽车里的更新“主从“架构
发布时间：2026/5/23 13:11:14
一、一辆汽车里有多少个电脑现代汽车早已不是简单的机械装置而是一个移动的计算中心。惊人的数字车型级别ECU 数量代码行数经济型轿车30-50 个1 亿行中高端轿车50-80 个1.5 亿行豪华/电动车80-150 个2 亿行对比一架波音 787 客机只有约 1400 万行代码这些 ECU 都在做什么汽车 ECU 分布示例 ┌─────────────────────────────────────────────────────────┐ │ 车身控制域 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 车门控制 │ │ 车窗控制 │ │ 座椅控制 │ │ 空调控制 │ │ │ │ (ECU) │ │ (ECU) │ │ (ECU) │ │ (ECU) │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ ├─────────────────────────────────────────────────────────┤ │ 动力系统域 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 引擎控制 │ │ 变速箱 │ │ 电池管理 │ │ 电机控制 │ │ │ │ (ECU) │ │ (ECU) │ │ (BMS) │ │ (ECU) │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ ├─────────────────────────────────────────────────────────┤ │ 底盘控制域 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 刹车控制 │ │ 转向控制 │ │ 悬挂控制 │ │ 稳定控制 │ │ │ │ (ABS) │ │ (EPS) │ │ (ECU) │ │ (ESC) │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ ├─────────────────────────────────────────────────────────┤ │ 信息娱乐域 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 中控大屏 │ │ 仪表盘 │ │ 导航系统 │ │ 音响系统 │ │ │ │ (IVI) │ │ (IC) │ │ (ECU) │ │ (ECU) │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ ├─────────────────────────────────────────────────────────┤ │ 智能驾驶域 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 摄像头 │ │ 雷达 │ │ 激光雷达 │ │ 自动驾驶 │ │ │ │ (ECU) │ │ (ECU) │ │ (ECU) │ │ (ECU) │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ └─────────────────────────────────────────────────────────┘二、为什么需要分 Primary 和 Secondary问题的复杂性如果每个 ECU 都独立去服务器下载更新❌ 方案 1每个 ECU 独立更新 ┌─────────┐ ┌─────────┐ ┌─────────┐ │ ECU 1 │◄───►│ ECU 2 │◄───►│ ECU 3 │ │ (独立) │ 网 │ (独立) │ 网 │ (独立) │ └────┬────┘ 络 └────┬────┘ 络 └────┬────┘ │ │ │ └──────────────┼──────────────┘ ▼ ┌─────────────┐ │ 4G/5G │ ← 50 个 ECU 同时下载 │ 网络 │ 带宽爆炸、费用高昂 └─────────────┘问题 流量费用50 个 ECU × 1GB 固件 50GB 流量/次更新 网络拥塞同时下载导致速度极慢 安全风险50 个攻击面每个都要保护⚡ 功耗问题同时联网耗电巨大Uptane 的解决方案主从架构✅ 方案 2Primary Secondary 架构 ┌─────────────────────────────────────────┐ │ Primary ECU (主) │ │ ┌─────────┐ ┌─────────┐ │ │ │ 网络模块 │ │ OTA客户端 │ │ │ │ (4G/5G) │ │aktualizr│ │ │ └────┬────┘ └────┬────┘ │ │ │ │ │ │ └──────────────┘ │ │ │ │ │ ┌──────┴──────┐ │ │ ▼ ▼ │ │ ┌─────────┐ ┌─────────────┐ │ │ │ 下载更新 │ │ 验证并分发 │ │ │ │ 从服务器 │ │ 给 Secondary│ │ │ └─────────┘ └─────────────┘ │ └────────┬────────────────────────────────┘ │ 车内网络 (CAN/LIN/Ethernet) │ ┌────┴────┬────────┬────────┐ ▼ ▼ ▼ ▼ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ │ ECU 1 │ │ ECU 2 │ │ ECU 3 │ │ ECU n │ │(Secondary)│(Secondary)│(Secondary)│(Secondary)│ │ 刹车 │ │ 转向 │ │ 空调 │ │ 其他 │ └───────┘ └───────┘ └───────┘ └───────┘优势✅ 只有一个设备联网节省流量✅ 集中管理安全减少攻击面✅ 车内网络更快更稳定✅ Secondary 可以更简单、更便宜三、Primary ECU更新的指挥官核心职责Primary ECU 的五大职责 ┌─────────────────────────────────────────┐ │ 1. 网络通信 │ │ • 连接 OTA 服务器 │ │ • 下载元数据和固件 │ │ • 上报设备状态和安装结果 │ ├─────────────────────────────────────────┤ │ 2. 安全验证 │ │ • 验证 Uptane 元数据签名 │ │ • 检查固件完整性哈希 │ │ • 防回滚、防重放攻击 │ ├─────────────────────────────────────────┤ │ 3. 更新决策 │ │ • 决定何时下载更新 │ │ • 决定何时安装更新 │ │ • 处理用户确认如果需要 │ ├─────────────────────────────────────────┤ │ 4. 分发管理 │ │ • 将固件分发给各个 Secondary │ │ • 管理分发进度和状态 │ │ • 处理 Secondary 的响应 │ ├─────────────────────────────────────────┤ │ 5. 安装协调 │ │ • 协调多 ECU 的安装顺序 │ │ • 处理安装失败和回滚 │ │ • 生成安装报告 │ └─────────────────────────────────────────┘硬件要求资源典型配置原因处理器ARM Cortex-A53/A72运行 Linux处理加密内存512MB - 2GB存储固件、运行 aktualizr存储4GB eMMC/SD存放数据库、缓存固件网络4G/5G WiFi连接 OTA 服务器安全HSM/TEE保护密钥和加密操作典型实例特斯拉中央计算模块CCM大众ICAS3In Car Application Server通用VIPVehicle Intelligence Platform四、Secondary ECU更新的执行者两种类型的 SecondaryUptane 根据计算能力将 Secondary 分为两类┌─────────────────────────────────────────────────────┐ │ Full Verification Secondary │ │ (完整验证型 Secondary) │ ├─────────────────────────────────────────────────────┤ │ 能力 │ │ • 完整的 Uptane 元数据验证 │ │ • 独立验证固件签名和哈希 │ │ • 支持复杂的加密操作 │ │ │ │ 硬件要求 │ │ • 较强的处理器ARM Cortex-M4/A 系列 │ │ • 较大的内存256KB RAM, 1MB Flash │ │ • 可以运行完整的 Uptane 客户端库 │ │ │ │ 示例 │ │ • 信息娱乐系统 │ │ • 自动驾驶控制器 │ │ • 高级车身控制器 │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ Partial Verification Secondary │ │ (部分验证型 Secondary) │ ├─────────────────────────────────────────────────────┤ │ 能力 │ │ • 验证固件哈希从 Primary 接收 │ │ • 简单的版本号检查 │ │ • 依赖 Primary 进行完整的 Uptane 验证 │ │ │ │ 硬件要求 │ │ • 有限的处理器ARM Cortex-M0/M3 │ │ • 较少的内存256KB RAM, 1MB Flash │ │ • 只能运行轻量级代码 │ │ │ │ 示例 │ │ • 车窗控制器 │ │ • 座椅控制器 │ │ • 简单的传感器 ECU │ └─────────────────────────────────────────────────────┘核心职责Secondary ECU 的三大职责 ┌─────────────────────────────────────────┐ │ 1. 接收固件 │ │ • 从 Primary 接收固件数据 │ │ • 本地存储通常写入临时区域 │ │ • 验证数据完整性哈希检查 │ ├─────────────────────────────────────────┤ │ 2. 安装固件 │ │ • 将固件写入目标区域Flash │ │ • 更新版本号 │ │ • 重启如果需要 │ ├─────────────────────────────────────────┤ │ 3. 报告状态 │ │ • 向 Primary 报告当前版本 │ │ • 报告安装成功/失败 │ │ • 提供诊断信息 │ └─────────────────────────────────────────┘五、Primary 与 Secondary 的通信协议通信方式车内网络类型 ┌─────────────────────────────────────────┐ │ CAN (Controller Area Network) │ │ • 速度125Kbps - 1Mbps │ │ • 用途传统汽车控制刹车、引擎 │ │ • 特点可靠、实时、低成本 │ │ • 限制带宽低、数据包小8字节 │ ├─────────────────────────────────────────┤ │ CAN FD (Flexible Data-rate) │ │ • 速度最高 8Mbps │ │ • 用途新一代汽车网络 │ │ • 特点向后兼容 CAN带宽更高 │ │ • 限制仍有一定限制 │ ├─────────────────────────────────────────┤ │ LIN (Local Interconnect Network) │ │ • 速度最高 20Kbps │ │ • 用途低成本传感器、执行器 │ │ • 特点极低成本、单线通信 │ │ • 限制速度很慢 │ ├─────────────────────────────────────────┤ │ Ethernet │ │ • 速度100Mbps - 1Gbps │ │ • 用途ADAS、信息娱乐、OTA │ │ • 特点高带宽、标准协议 │ │ • 限制成本较高、需要交换机 │ └─────────────────────────────────────────┘Uptane 的 Secondary 协议Uptane 定义了标准化的 Primary-Secondary 通信协议通信消息类型 ┌─────────────────────────────────────────┐ │ 1. Discovery发现 │ │ Primary: 有哪些 Secondary 在线 │ │ Secondary: 我在这里我的信息是... │ ├─────────────────────────────────────────┤ │ 2. Metadata Distribution元数据分发 │ │ Primary: 这是最新的 Uptane 元数据 │ │ Secondary: 收到验证通过/失败 │ ├─────────────────────────────────────────┤ │ 3. Firmware Distribution固件分发 │ │ Primary: 这是给你的固件分片发送 │ │ Secondary: 收到第 X 片校验正确 │ ├─────────────────────────────────────────┤ │ 4. Installation Request安装请求 │ │ Primary: 请安装这个固件 │ │ Secondary: 安装成功/失败原因是... │ ├─────────────────────────────────────────┤ │ 5. Status Report状态报告 │ │ Secondary: 我的当前版本是... │ │ Primary: 收到已记录 │ └─────────────────────────────────────────┘ASN.1 消息格式Uptane 使用 ASN.1Abstract Syntax Notation One定义消息格式-- 简化的 Secondary 消息定义 SecondaryMessage :: CHOICE { discoveryRequest [0] DiscoveryRequest, discoveryResponse [1] DiscoveryResponse, firmwareRequest [2] FirmwareRequest, firmwareResponse [3] FirmwareResponse, ... } DiscoveryResponse :: SEQUENCE { ecuSerial UTF8String, hardwareId UTF8String, currentVersion INTEGER, supportedTypes SEQUENCE OF UTF8String } FirmwareRequest :: SEQUENCE { ecuSerial UTF8String, targetFilename UTF8String, offset INTEGER, -- 用于断点续传 chunkSize INTEGER }六、aktualizr 中的实现代码架构aktualizr 中的 Primary/Secondary 实现 src/ ├── aktualizr_primary/ # Primary ECU 主程序 │ └── main.cc ├── aktualizr_secondary/ # Secondary ECU 主程序 │ └── main.cc ├── libaktualizr/ │ ├── primary/ # Primary 相关代码 │ │ ├── aktualizr.cc # 主类实现 │ │ ├── sotauptaneclient.cc # Uptane 客户端 │ │ └── secondary.cc # Secondary 管理 │ └── secondary/ # Secondary 相关代码 │ ├── secondary_interface.h # 接口定义 │ ├── ipc_secondary.cc # IPC 实现 │ ├── socket_secondary.cc # Socket 实现 │ └── ...关键类解析Primary 端SecondaryInterface// 简化版接口定义classSecondaryInterface{public:virtual~SecondaryInterface()default;// 发现 Secondaryvirtualstd::stringgetSerial()0;virtualstd::stringgetHwId()0;// 发送元数据virtualboolsendMetadata(constUptane::MetaCollectionmeta)0;// 发送固件virtualboolsendFirmware(conststd::stringfilename,conststd::stringdata)0;// 安装请求virtualdata::ResultCodeinstall()0;// 获取状态virtualSecondary::VersiongetVersion()0;};Secondary 端AktualizrSecondary// Secondary 主类classAktualizrSecondary{public:// 初始化voidinitialize();// 处理 Primary 的请求voidhandleDiscovery();voidhandleMetadata(constUptane::MetaCollectionmeta);voidhandleFirmware(conststd::stringdata);voidhandleInstall();// 验证根据类型boolverifyMetadata(constUptane::MetaCollectionmeta);boolverifyFirmware(conststd::stringdata);private:SecondaryConfig config_;// 配置INvStoragestorage_;// 存储KeyManagerkeys_;// 密钥管理};七、动手实验配置虚拟 Secondary实验 1查看 Secondary 配置cd~/test/aktualizr/demo# 查看虚拟 Secondary 配置文件catvirtualsec.json输出示例{virtual:[{ecu_serial:demo-vsec1,ecu_hardware_id:demo-virtual,partial_verifying:false,ecu_private_key:sec.private,ecu_public_key:sec.public,firmware_path:storage/demo-vsec1/firmware.bin,metadata_path:storage/demo-vsec1/metadata,target_name_path:storage/demo-vsec1/target_name}]}实验 2启动带 Secondary 的 aktualizrcd~/test/aktualizr/demo# 确保目录结构正确mkdir-pstorage/demo-vsec1/metadatachmod-R700storage/# 查看配置文件catsota-local.toml配置内容[provision] mode AutoProvision primary_ecu_hardware_id local-fake [logger] loglevel 1 [storage] path storage type sqlite [pacman] type none images_path storage/images [uptane] secondary_config_file virtualsec.json # 关键配置实验 3运行并观察cd~/test/aktualizr/demo# 运行 aktualizr单次模式sudo../build/src/aktualizr_primary/aktualizr--configsota-local.toml once观察输出Initializing virtual Secondaries... Adding Secondary with ECU serial: demo-vsec1 with hardware ID: demo-virtual ...实验 4配置多个 Secondarycd~/test/aktualizr/demo# 创建多 Secondary 配置catvirtualsec-multi.jsonEOF { virtual: [ { ecu_serial: demo-vsec1, ecu_hardware_id: demo-virtual, partial_verifying: false, ecu_private_key: sec1.private, ecu_public_key: sec1.public, firmware_path: storage/demo-vsec1/firmware.bin, metadata_path: storage/demo-vsec1/metadata, target_name_path: storage/demo-vsec1/target_name }, { ecu_serial: demo-vsec2, ecu_hardware_id: demo-virtual-2, partial_verifying: true, ecu_private_key: sec2.private, ecu_public_key: sec2.public, firmware_path: storage/demo-vsec2/firmware.bin, metadata_path: storage/demo-vsec2/metadata, target_name_path: storage/demo-vsec2/target_name } ] } EOF# 创建目录mkdir-pstorage/demo-vsec2/metadatachmod-R700storage/# 修改配置使用新文件sed-is/virtualsec.json/virtualsec-multi.json/sota-local.toml# 运行sudo../build/src/aktualizr_primary/aktualizr--configsota-local.toml once八、本章小结核心概念回顾概念一句话解释ECU电子控制单元汽车里的小电脑Primary ECU主 ECU负责联网、验证、分发更新Secondary ECU次 ECU从 Primary 接收并安装更新Full Verification完整验证能独立验证所有 Uptane 元数据Partial Verification部分验证依赖 Primary 进行主要验证车内网络CAN/CAN FD/LIN/Ethernet连接各个 ECU架构优势Primary Secondary 架构的优势 ✅ 安全性 • 只有一个联网点减少攻击面 • 集中管理安全策略和密钥 ✅ 经济性 • Secondary 可以更简单、更便宜 • 节省流量费用只下载一次 ✅ 可靠性 • 车内网络比公网更稳定 • 可以协调多 ECU 的更新顺序 ✅ 灵活性 • 支持不同能力的 ECU • 可以混合使用不同验证级别下一步在下一篇文章《动手搭建第一个 OTA 客户端——aktualizr 编译与运行》中我们将完整编译 aktualizr 项目配置并运行第一个可用的 demo理解配置文件的每个参数排查常见问题九、延伸阅读与资源官方文档Uptane 部署指南: https://uptane.github.io/deployment/best-practices.htmlaktualizr Secondary 文档:docs/ota-client-guide/modules/ROOT/pages/virtual-secondaries.adoc推荐阅读《汽车电子架构演进》了解域控制器架构《CAN 总线协议详解》了解车内通信思考题为什么 Full Verification Secondary 需要更强的硬件设计一个场景如果 Primary ECU 被攻破Secondary 如何保护自己在电动车中BMS电池管理系统应该作为 Primary 还是 Secondary为什么目标读者理解基础概念的开发者上一篇《Uptane 安全框架初探——比 HTTPS 更安全的更新机制》下一篇《动手搭建第一个 OTA 客户端——aktualizr 编译与运行》希望这篇文章让你理解了 Primary/Secondary 架构的设计思想。有任何问题欢迎在评论区留言讨论
