设备固件更新(DFU)

Bluetooth Mesh 支持在 Mesh 网络中分发固件映像。Bluetooth Mesh DFU 子系统实现了 Bluetooth Mesh Device Firmware Update Model 规范 1.0 版。

Bluetooth Mesh DFU 实现了固件映像的分发机制,不对映像的大小、格式或用途施加任何限制。该子系统的主要设计目标是提供 Bluetooth Mesh DFU 规范中可认证的部分,并将用法、固件验证和部署留给应用。

DFU 规范在 Zephyr Bluetooth Mesh DFU 子系统中通过三个独立的模型实现:

概述

DFU 角色

Bluetooth Mesh DFU 子系统定义了 Mesh 节点在固件映像分发过程中必须承担的三种不同角色:

目标节点

目标节点是所传输固件映像的接收方和使用方。其全部功能由 固件更新服务器 模型实现。一次传输可以面向任意数量的目标节点,它们将同时更新。

分发器

分发器角色在 DFU 过程中有两个用途。首先,它在 Upload Firmware 过程中充当目标节点;然后,它作为分发器将上传的映像分发给其他目标节点。分发器不选择传输参数,而是依赖发起方提供目标节点列表和传输参数。分发器功能由两个模型实现:固件分发服务器 和 固件更新客户端。固件分发服务器 负责与发起方通信,固件更新客户端 负责将映像分发给目标节点。

发起方

发起方角色通常由实现 Bluetooth Mesh 配网器 和 配置器 角色的同一设备实现。发起方需要全面了解潜在目标节点及其固件,并将控制(和发起)所有固件更新。Zephyr Bluetooth Mesh DFU 子系统未实现发起方角色。

Mesh 节点在映像分发过程中可能具有的 DFU 角色图示 分发

DFU 角色及其关联的 Bluetooth Mesh 模型

Bluetooth Mesh 应用可以以任何方式组合 DFU 角色,甚至可以将在不同元素上实例化模型来承担同一角色的多个实例。例如,可以在发起方节点上实例化 固件更新客户端 并直接调用其 API,从而组合分发器和发起方角色。

也可以将发起方和分发器设备合并为单个设备,并使用专有机制替代固件分发服务器模型,直接访问固件更新客户端模型,例如通过串行协议。

备注

所有 DFU 模型都会实例化一个或多个 BLOB 传输模型,并且对于某些角色组合,可能需要分布在多个元素上。

阶段

Bluetooth Mesh DFU 过程设计为分三个阶段执行:

上传阶段

首先,映像由外部实体(例如手机或网关,即发起方)上传到 Mesh 网络中的分发器。在上传阶段,发起方将固件映像及其所有元数据传输到 Mesh 网络内的分发器节点。分发器持久存储固件映像及其元数据,并等待发起方的进一步指令。完成上传过程所需的时间取决于映像大小。上传完成后,发起方可以在耗时长得多的分发阶段断开与网络的连接。固件上传到分发器后,发起方可以随时触发分发阶段。

固件能力检查阶段(可选)

在开始分发阶段之前,发起方可以选择检查目标节点能否接受新固件。未响应或响应无法接收新固件的节点将从固件分发过程中排除。

分发阶段

在分发固件映像之前,发起方将目标节点列表及其指定的固件映像索引传输给分发器。接着,它指示分发器启动固件分发过程,该过程在后台运行,同时发起方和 Mesh 网络执行其他任务。固件映像传输到目标节点后,分发器可以要求它们立即应用固件映像,并回报状态和新的固件 ID。

固件映像

Mesh 节点固件中所有可更新的部分都应表示为固件映像。每个目标节点持有一个固件映像列表,其中每个映像都应可独立更新和识别。

固件映像表示为一个 BLOB(固件本身),并附带以下附加信息:

固件 ID

固件 ID 用于标识固件映像。发起方节点可以向目标节点询问其当前固件 ID 列表,以确定是否有更新版本的固件可用。固件 ID 的格式由厂商定义,但通常应包含足够的信息,使了解该格式的发起方节点能够确定映像类型及其版本。固件 ID 是可选的,其最大长度由 CONFIG_BT_MESH_DFU_FWID_MAXLEN 决定。

固件元数据

目标节点使用固件元数据来确定是否应接受传入的固件更新,以及更新的效果是什么。元数据格式由厂商定义,并且应包含目标节点验证映像所需的所有信息,以及目标节点在应用映像之前必须进行的任何准备工作。典型的元数据信息可以包括映像签名、节点 Composition Data 的变更以及 BLOB 的格式。目标节点可以在接受传入传输之前执行元数据检查,以确定是否应开始传输。元数据检查后,目标节点可以丢弃固件元数据,因为其他节点永远不会向目标节点请求元数据。固件元数据是可选的,其最大长度由 CONFIG_BT_MESH_DFU_METADATA_MAXLEN 决定。

Zephyr 中的 Bluetooth Mesh DFU 子系统提供了自己的元数据格式(bt_mesh_dfu_metadata)以及一组可供最终产品使用的相关函数。其支持通过 CONFIG_BT_MESH_DFU_METADATA 选项启用。元数据的格式如下表所示。

字段

大小(字节)

描述

新固件版本

8 B

1 B:主版本 1 B:次版本 2 B:修订版 4 B:构建号

新固件大小

3 B

新固件的字节大小

新固件核心类型

1 B

位字段:位 0:应用核心 位 1:网络核心 位 2:应用特定的 BLOB。其他位:RFU

传入 Composition Data 的哈希

4 B(可选)

AES-CMAC(应用特定密钥,Composition Data)的低 4 个八位字节。如果“新固件核心类型”字段中设置了位 0,则存在此字段。

新元素数量

2 B(可选)

应用固件后节点上的元素数量。如果“新固件核心类型”字段中设置了位 0,则存在此字段。

新固件的应用特定数据

<variable>(可选)

应用特定数据,允许应用在能够响应状态消息之前,使用此数据执行某些厂商特定的行为。

备注

AES-CMAC 算法使用固定密钥作为哈希函数,在 Bluetooth Mesh DFU 元数据中不用于加密。由于密钥已知,生成的哈希并不安全。

固件 URI

固件 URI 向发起方提供有关可在何处找到该映像固件更新的信息。该 URI 指向一个在线资源,发起方可以与其交互以获取新版本的固件。这样,发起方就可以通过与 URI 指向的 Web 服务器交互,为 Mesh 网络中的任何节点执行更新。URI 必须使用 http 或 https 方案指向资源,并且目标 Web 服务器必须按照规范定义的 Firmware Check Over HTTPS 过程行事。固件 URI 是可选的,其最大长度由 CONFIG_BT_MESH_DFU_URI_MAXLEN 决定。

备注

不支持带外分发机制。

固件效果

新映像的 Composition Data Page 0 可能与目标节点上分配的版本不同。这可能影响节点的配网数据以及分发器完成 DFU 的方式。根据旧映像和新映像上 Remote Provisioning Server 模型的可用性,设备在应用新固件后可能以未配网状态启动,或者需要重新配网。可用选项的完整列表在 bt_mesh_dfu_effect 中定义:

BT_MESH_DFU_EFFECT_NONE

编程新固件后,设备保持已配网状态。如果新固件的 Composition Data 没有变化,则选择此效果。

BT_MESH_DFU_EFFECT_COMP_CHANGE_NO_RPR

当 Composition Data 发生变化且设备不支持远程配网时,选择此效果。新的 Composition Data 仅在重新配网后生效。

BT_MESH_DFU_EFFECT_COMP_CHANGE

当 Composition Data 发生变化且设备支持远程配网时,选择此效果。在这种情况下,设备保持已配网状态,新的 Composition Data 在使用 Remote Provisioning 模型重新配网后生效。

BT_MESH_DFU_EFFECT_UNPROV

如果新固件中的 Composition Data 发生变化、设备不支持远程配网,并且新的 Composition Data 在应用固件后生效,则选择此效果。如果出于应用特定原因必须将设备取消配网,也可以选择此效果。

当目标节点收到 Firmware Update Firmware Metadata Check 消息时,固件更新服务器模型会调用 bt_mesh_dfu_srv_cb.check 回调,应用随后可以处理元数据并提供效果值。如果效果为 BT_MESH_DFU_EFFECT_COMP_CHANGE,则应用必须在应用新固件映像之前调用 bt_mesh_comp_change_prepare() 和 bt_mesh_models_metadata_change_prepare() 函数,以准备 Composition Data Page 和 Models Metadata Page 的内容。更多信息请参阅 组合数据与模型元数据。

DFU 过程

DFU 协议实现为一组必须按特定顺序执行的过程。

发起方控制 DFU 协议的上传阶段,分发器侧对所有上传子过程的处理都在 固件分发服务器 中实现。

分发阶段由分发器控制,具体由 固件更新客户端 实现。目标节点在 固件更新服务器 中实现所有这些过程的处理,并通过一组回调通知应用。

DFU 阶段和过程概览

从分发器视角看到的 DFU 阶段和过程

上传固件

Upload Firmware 过程使用 BLOB 传输模型 将固件映像从发起方传输到分发器。Upload Firmware 过程分两步进行:

  1. 发起方生成 BLOB ID,并将其与固件信息以及 BLOB 传输的其他输入参数一起发送给分发器的固件分发服务器。固件分发服务器存储这些信息,并在响应发起方的状态消息之前,为其 BLOB 传输服务器做好接收传入传输的准备。

  2. 发起方的 BLOB Transfer Client 模型将固件映像传输到分发器的 BLOB Transfer Server,后者将映像存储在预定的闪存分区中。

BLOB 传输完成后,固件映像即可用于分发。发起方可以向分发器上传多个固件映像,并要求其按任意顺序或任意时间分发它们。还提供了用于查询和从分发器删除固件映像的其他过程。

以下与固件映像相关的分发器能力可以通过配置选项进行配置:

填充分发器的接收方列表

在分发器开始分发固件映像之前,它需要一份要发送映像到的目标节点列表。发起方可以通过直接查询潜在目标或通过某些外部权威机构获取完整的目标节点列表。发起方使用此信息,将每个目标节点的地址和相关固件映像索引填充到分发器的接收方列表中。发起方可以发送一条或多条 Firmware Distribution Receivers Add 消息来构建分发器的接收方列表,并发送 Firmware Distribution Receivers Delete All 消息来清除该列表。

可以添加到分发器的最大接收方数量通过 CONFIG_BT_MESH_DFD_SRV_TARGETS_MAX 配置选项进行配置。

发起分发

一旦分发器存储了固件映像并收到目标节点列表,发起方就可以发起分发过程。分发的 BLOB 传输参数与更新策略一起传递给分发器。更新策略决定分发器是否应请求在目标节点上应用固件。分发器存储传输参数,并开始将固件映像分发给其目标节点列表。

固件分发

分发器的固件更新客户端模型使用其 BLOB Transfer Client 模型的广播子系统与所有目标节点通信。固件分发按以下步骤执行:

  1. 分发器的固件更新客户端模型生成 BLOB ID,并将其与其他 BLOB 传输参数、目标节点固件映像索引和固件映像元数据一起发送到每个目标节点的固件更新服务器模型。每个目标节点执行元数据检查,并为其 BLOB Transfer Server 模型做好传输准备,然后向固件更新客户端发送状态响应,指示固件更新是否会对节点的 Bluetooth Mesh 状态产生任何影响。

  2. 分发器的 BLOB Transfer Client 模型将固件映像传输到所有目标节点。

  3. 一旦收到 BLOB 传输,目标节点的应用会通过执行签名验证或根据映像元数据校验映像校验和等检查,验证固件是否有效。

  4. 分发器的固件更新客户端模型查询所有目标节点,以确保它们都已验证固件映像。

如果分发过程完成时至少有一个目标节点报告映像已接收并验证,则认为分发过程成功。

备注

固件分发过程仅在 所有 目标节点都丢失时失败。发起方应从分发器请求失败目标节点的列表,并在当前尝试完成后发起额外尝试来更新丢失的目标节点。

暂停分发

发起方还可以请求分发器暂停固件分发。在这种情况下,分发器将停止向目标节点发送任何消息。恢复固件分发后,分发器将从最后一个成功传输的块继续发送固件。

应用固件映像

如果发起方请求,分发器可以对所有成功接收并验证固件映像的目标节点启动 Apply Firmware on Target Node 过程。Apply Firmware on Target Node 过程不带参数,为避免歧义,应在新传输开始之前执行。Apply Firmware on Target Node 过程包括以下步骤:

  1. 分发器的固件更新客户端模型指示所有已验证固件映像的目标节点应用该映像。目标节点的固件更新服务器模型在调用其应用的 apply 回调之前,会先响应一条状态消息。

  2. 目标节点的应用执行应用传输之前所需的任何准备工作,例如存储 Composition Data 快照或清除其配置。

  3. 目标节点的应用将当前固件替换为新映像,并使用新的固件 ID 更新其固件映像列表。

  4. 分发器的固件更新客户端模型向每个目标节点请求完整的固件映像列表,并扫描该列表以确保新的固件 ID 已替换旧的固件 ID。

备注

在分发过程的元数据检查期间,目标节点可能已报告在应用固件映像后将变为未配网状态。在这种情况下,分发器的固件更新客户端模型将发送请求以获取完整的固件映像列表,并预期不会有响应。

取消分发

发起方可以随时取消固件分发。在这种情况下,分发器通过向所有目标节点发送取消消息来启动取消过程。分发器等待所有目标节点的响应。一旦所有目标节点都已回复,或请求超时,分发过程即被取消。此后,可以从 Firmware distribution 部分再次启动分发过程。

API 参考

本节列出设备固件更新 Mesh 模型通用的类型。

Firmware Distribution models
Bluetooth Mesh Device Firmware Update
Bluetooth Mesh Device Firmware Update (DFU) metadata