第二章：系统架构设计——云端-管道-终端三层架构、OTA主控节点设计、升级域划分策略

好，咱们进入正题。这一章讲的是OTA升级的骨架——系统架构。说白了，就是搞清楚升级指令从哪发、怎么传、谁来执行。我见过不少项目，一开始就埋头写代码，结果架构没想清楚，后面改得想哭。所以，咱们先把这层皮剥开，看明白。

2.1 云端-管道-终端三层架构

OTA升级，本质上是一个“远程控制”问题。你想想看，车在用户手里，工程师在办公室，怎么把新软件塞进去？答案就是分层。

我个人习惯把整个系统拆成三层：云端、管道、终端。每一层各司其职，互不干扰。

2.1.1 云端（Cloud）

云端是大脑。它负责管理升级包、制定升级策略、下发指令。具体来说，云端要干这几件事：

  • 升级包管理：存储不同版本、不同车型的固件包。我记得有一次，一个项目同时支持5个车型，每个车型又有3个配置，光版本号就搞晕了。所以，云端必须有一套清晰的版本管理机制。
  • 策略下发：不是所有车都能同时升级。云端要决定“先升哪批车”、“什么时候升”、“失败了怎么办”。
  • 状态监控：每辆车的升级进度、成功失败，云端都要实时掌握。
我的经验：云端设计时，一定要考虑“灰度发布”。别一上来就全量推送，万一有bug，那画面太美我不敢看。先找1%的车试试水，没问题再放开。

2.1.2 管道（Pipe）

管道是桥梁。它负责把云端的指令和数据，安全、可靠地送到车端。这里说的管道，通常指TSP（Telematics Service Provider）平台和移动网络。

管道设计有几个关键点：

  • 协议选择：HTTP/HTTPS还是MQTT？我个人更倾向MQTT，因为它轻量、支持长连接、有QoS保证。但HTTP也有它的场景，比如大文件下载。
  • 断点续传：车在移动中，网络不稳定。升级包下载到一半断了怎么办？必须支持断点续传。我曾经在一个项目中，因为没做断点续传，导致用户在地下车库升级失败，投诉电话打爆了。
  • 安全加密：管道传输的数据必须加密。别让黑客在中间截获了你的升级包，那后果不堪设想。

2.1.3 终端（Terminal）

终端是执行者。就是车上的ECU们。终端负责接收指令、下载包、校验、刷写、重启。

终端设计最头疼的是资源限制。很多ECU的Flash只有几兆，RAM更是少得可怜。你想想看，一个几十兆的升级包，怎么塞进去？这就引出了后面的“升级域划分”和“主控节点设计”。

2.2 OTA主控节点设计

主控节点，是整个车端升级的“总指挥”。它不直接刷写所有ECU，而是协调各个域控制器完成升级。

为什么需要主控节点？因为车上有几十个ECU，如果每个ECU都直接跟云端通信，那网络负担太重，而且管理混乱。所以，需要一个“带头大哥”。

2.2.1 主控节点的选型

主控节点通常选谁？我个人建议选网关（Gateway）或T-Box。原因很简单：

  • 网关：它连接了车内所有网络（CAN、LIN、以太网），天然适合做协调者。
  • T-Box：它负责跟云端通信，有网络连接能力。

有些项目会把主控节点放在域控制器里，比如智能座舱域控。但我不太推荐，因为座舱域控一旦升级失败，连仪表都黑了，用户直接抓狂。

避坑指南：我曾经在一个项目中，把主控节点放在了一个不带独立电源的ECU上。结果升级过程中，车辆下电，主控节点直接挂了，升级失败。所以，主控节点一定要有独立的供电管理，确保升级过程中不掉电。

2.2.2 主控节点的核心功能

主控节点要干的事，我列了个清单：

  1. 接收云端指令：解析升级任务，判断升级哪个ECU。
  2. 下载升级包：从云端拉取固件包，并做完整性校验（比如MD5、SHA256）。
  3. 分发升级包：把包分发给对应的域控制器或ECU。
  4. 协调升级顺序：有些ECU有依赖关系，比如先升网关，再升域控。主控节点要控制好顺序。
  5. 监控升级状态：实时上报每个ECU的升级进度给云端。
  6. 处理异常：升级失败时，要能回滚到旧版本。

这里我贴一段伪代码，展示主控节点处理升级任务的核心逻辑：

// 主控节点升级任务处理
void handle_ota_task(ota_task_t *task) {
    // 1. 校验任务合法性
    if (!validate_task(task)) {
        report_error("Invalid task");
        return;
    }

    // 2. 下载升级包
    download_result_t result = download_package(task->package_url);
    if (result != SUCCESS) {
        report_error("Download failed");
        return;
    }

    // 3. 校验包完整性
    if (!verify_package(task->expected_hash)) {
        report_error("Hash mismatch");
        return;
    }

    // 4. 按顺序分发到各ECU
    for (int i = 0; i < task->ecu_count; i++) {
        ecu_info_t *ecu = &task->ecu_list[i];
        if (!flash_ecu(ecu)) {
            // 5. 失败则回滚
            rollback_all();
            report_error("Flash failed on ECU %d", ecu->id);
            return;
        }
    }

    // 6. 上报成功
    report_success();
}

2.3 升级域划分策略

升级域划分，说白了就是把车上的ECU分成几个组，每组由一个域控制器负责升级。为什么要分域？因为直接让主控节点去刷写每一个ECU，效率太低，而且风险集中。

2.3.1 划分原则

我总结了几条原则，供你参考：

  • 按功能域划分：动力域、底盘域、车身域、信息娱乐域、自动驾驶域。这是最自然的划分方式。
  • 按网络拓扑划分：同一个网络总线上的ECU，尽量划在一个域里。比如CAN总线上的ECU，由同一个域控管理。
  • 按升级频率划分：经常升级的ECU（比如座舱域控）和很少升级的ECU（比如ABS控制器）分开。这样不会互相影响。
  • 按安全等级划分：涉及安全的ECU（比如制动、转向）要单独划域，升级流程要更严格。

2.3.2 一个典型的划分示例

假设一辆车有20个ECU，我可能会这样划分：

升级域 域控制器 包含ECU 升级策略
动力域 VCU 发动机ECU、变速箱ECU、BMS 必须停车升级，失败可回滚
底盘域 ESP控制器 ABS、EPS、EPB 必须停车升级，安全校验严格
车身域 BCM 门窗控制器、灯光控制器、座椅控制器 可静默升级，用户无感
信息娱乐域 座舱域控 仪表、中控、T-Box 可后台升级，升级完重启
自动驾驶域 ADAS域控 摄像头、雷达、域控主芯片 必须停车，升级后需标定
注意：这个划分不是死的。比如，有些车把T-Box划在信息娱乐域，有些划在车身域。关键是要看你的网络拓扑和功能安全需求。

2.3.3 域内升级流程

每个域内部，升级流程是这样的：

  1. 主控节点通知域控制器：告诉它“你要升级了，包已经准备好了”。
  2. 域控制器拉取包：从主控节点或本地存储拉取升级包。
  3. 域控制器刷写子ECU：按顺序刷写域内的各个ECU。
  4. 域控制器上报结果：告诉主控节点“我这边搞定了”或“失败了”。

嗯，这里要注意，域控制器本身也可能需要升级。这时候，主控节点要先升级域控制器，再让它去升级子ECU。顺序不能乱。

好了，这一章的内容就到这。说白了，架构设计就是“分而治之”。云端管策略，管道管传输，终端管执行。主控节点当总指挥，域控制器当分指挥。这样，几十个ECU的升级才能有条不紊地进行。

← 上一章 📖 返回目录 下一章 →