本文由 KeepRobots 团队撰写。KeepRobots 是温哥华的机器人现场服务公司，给别家生产的机器人做北美现场部署和售后。本文是工程笔记，不是法律或认证意见；涉及 FCC / ISED 许可变更的判断，请以你们的认证机构（TCB / CB）和律师意见为准。

假设一个场景：温哥华一家酒店和厂商约好，配送机器人的固件升级放在客户本地凌晨 2 点到 4 点。这时是北京下午 5 点到 7 点，研发在工位上看着 20 台机器的进度条全部变绿，下班回家。

早上 7 点酒店早班开始，第一单送餐，机器人在电梯口呼梯失败。新版本改了电梯对接模块的重试逻辑，台架上没有那台电梯网关，测不出来。这时北京是晚上 10 点，能拍板回滚的人已经下线；前台经理只看到 20 台机器同时罢工。

北美的维护窗口其实落在北京的工作时间里，真正出问题的时候却是北京深夜。 这篇讲的就是由此推出来的一条主线：回滚的判断不能等国内醒来，要提前写成规则，交给设备和现场的人去执行。 下面依次是：时间怎么算、发布环怎么分、客户网络对 OTA 的限制、A/B 回滚条件、现场回滚 SOP、给客户的变更通知模板，最后是北美特有的一层：FCC 2026 新规和 ISED 规则下，哪些固件还能推、要先报备什么。

---

一、先把时间算对：窗口在北京下午，出事在北京深夜

北美很多机构客户的 IT 变更都要走审批，维护窗口一般约在客户本地夜间或周末。先把几个常见时区换算清楚：

• 温哥华（BC 省）：2026 年 3 月 8 日是最后一次拨钟，从 11 月 1 日起不再拨回，全年固定 UTC-7。北京和温哥华全年差 15 小时。
• 西雅图、旧金山、洛杉矶：华盛顿州、俄勒冈州、加州没有跟进，仍然冬夏拨钟。夏令时差 15 小时，冬天（11 月初到 3 月中旬，下一次拨钟是 2027-03-14）差 16 小时。也就是说，今年冬天开始，温哥华和西雅图之间会有 1 小时时差，同一个客户如果在两地都有站点，窗口要分开排。另外，BC 东南部 East Kootenay、Golden 等用山地时间的地区不受这次变化影响，仍跟阿尔伯塔一起拨钟。
• 多伦多、纽约：夏令时差 12 小时，冬天差 13 小时。

今年还有一个时效坑：tzdata。 设备、发布系统、监控里的时区换算，靠的是系统自带的 IANA 时区数据库（tzdata）。tzdata 到 2026b 才把 America/Vancouver 改成 11 月 1 日起永久 UTC-7（缩写暂记为 MST，判断时以 UTC 偏移为准）。还在用旧 tzdata 的系统，11 月 1 日会照旧把温哥华时间拨回 UTC-8：发布系统按「America/Vancouver 02:00」排的窗口实际晚开 1 小时，监控里的「早班 07:00」也全部错位 1 小时，而且不会有任何报错。机器人主控、云端发布服务、监控告警，三处都要查：

# 看 2026-11-01 那次切换：判据是 gmtoff=-25200（UTC-7）；
# gmtoff=-28800（UTC-8）说明 tzdata 太旧。缩写 MST/PST 只作参考，MST 是暂定写法
zdump -v -c 2026,2027 America/Vancouver | grep "Nov  1"
# 没有 zdump 的设备（GNU date）：新数据应输出 05:00（UTC-7），旧数据是 04:00（UTC-8）
TZ=America/Vancouver date -d @1796126400    # 即 2026-12-01 12:00 UTC

系统 tzdata 更新了还不够，应用自带的时区库要分别查：JVM 的 tzdata、Node.js / Chrome 内置的 ICU、Python 的 pytz / tzdata 包、Android 的 tzdata APEX、Go 程序内嵌的 zoneinfo，都可能比系统旧。

把「客户本地凌晨 2 点开窗口」和「早班 7 点开工」换成北京时间：

客户所在地	窗口 02:00 对应北京	早班 07:00 对应北京
温哥华（全年 UTC-7）	17:00	22:00
西雅图 / 洛杉矶（冬季 UTC-8）	18:00	23:00
多伦多 / 纽约（冬季 UTC-5）	15:00	20:00

对研发是好消息：推送本身可以在北京下午盯着做。坏消息在第三列：版本在真实业务里第一次「受压」，是客户早班开工那一刻，这时国内要么已经下班，要么快睡了。所以接下来每一节都在回答一个问题：北京晚上 10 点出问题，谁能在不叫醒总部的情况下把机器恢复？

二、发布环：观察期按「营业日」算，不按小时

灰度的核心不是比例，而是每一环要过一次完整的真实业务高峰。凌晨升级完，机器在空荡荡的走廊里跑 3 个小时什么都不说明；呼梯、闸机、早高峰排队这些场景，要到营业时间才会出现。

下面是一张可以直接拿去改的发布环表（比例和时长是建议起点，按你们的设备规模调）：

环	范围	进入条件	最短观察期	谁签字放行
R0 台架	国内台架 + 同硬件版本整机	CI 全绿；A/B 切换、回滚、断电恢复各演练一次	24 小时连续跑	研发负责人
R1 北美样机	北美的 demo 机、备用机（不在客户现场）	R0 通过；离线安装包验证过	24 小时，含一次对接真实电梯/门禁（如有条件）	研发 + 海外售后
R2 金丝雀	1 个站点、1–2 台，客户书面同意	R1 通过；变更通知已发、窗口已确认	1 个完整营业日（含早高峰）	海外售后负责人
R3 小批	≤10% 设备，覆盖不同场景类型（酒店 / 仓库 / 商场）	R2 无触发项	3 个营业日	海外售后负责人
R4 全量	其余设备，按各客户窗口分批	R3 无触发项	持续监控 7 天	自动，触发即暂停

几条容易漏的规则：

• 同一站点不要一次升满。 留 1 台在旧版本，出问题时客户至少还有一台能用，现场也有对照组。
• 按「场景类型」挑金丝雀，不按「谁最好说话」。 电梯对接、闸机、WMS 接口各选一个代表站点。
• R2 之后的每一批都要给客户发变更通知（模板见第六节），不能因为「之前推过」就省掉。
• 周五到周日（客户本地日期）不启动 R2/R3。 周五凌晨升级，观察期就跨进周末：国内周末值班最薄，很多写字楼、学校站点周末根本没有「完整营业日」，问题要拖到周一早班才暴露，那时离升级已经三天，日志和现场都凉了。

把这张表写成配置，交给发布系统执行，比写在 Wiki 里靠人记要可靠：

# rollout-policy.yaml —— 字段名为示例，按你们的发布平台改
release: "4.2.0"
from_versions: ["4.1.x"]
rf_impact: none            # none | class1 | class2 | class3，见第七节；非 none 先过合规闸
safety_function_changed: false   # 改了急停、限速、避障参数 → 先问认证机构
rings:
  - name: R2-canary
    selector: {site: "site-yvr-hotel-01", max_units: 2}
    keep_on_old_version: 1          # 每站点至少留 1 台旧版本
    window: {tz: "America/Vancouver", start: "02:00", end: "04:00"}
    min_observation: {business_days: 1, must_include: "07:00-10:00"}
    no_start_on: [FRI, SAT, SUN]    # 按窗口开始那天的客户本地日期算，不按北京日期
  - name: R3-small
    selector: {percent: 10, spread_by: site_type}
    min_observation: {business_days: 3}
  - name: R4-all
    selector: {percent: 100}
    batch_by: customer_window       # 按每个客户自己的窗口分批
precheck:                           # 任一不满足，本台跳过，不进入安装
  battery_soc_min: 60
  docked: true
  no_active_task: true
  free_space_mb_min: 1500
auto_pause_on: [rollback_rate_over_5pct, new_fault_code_on_2_units_24h]

三、客户网络：OTA 先要能下载，再谈灰度

北美企业网的认证方式、出站白名单、TLS 解密审批，我们在另一篇工程笔记（客户安全团队会问的 7 个问题）里单独写过，这里不重复，只说和 OTA 直接相关的四件事：

1. 下载和安装分开。 白天在客户网络空闲时下载、校验签名、写进非活动分区；夜里窗口只做「切换 + 重启 + 健康检查」。这样窗口里不会因为下载慢、代理超时把 2 小时耗完。

2. 下载器要能走代理、能断点续传。 强制代理的网络里，OTA 客户端如果只会直连就永远下不到包。支持 HTTP 代理配置、HTTP Range 续传，单个包尽量做差分，别指望客户 IT 为一次升级调整带宽策略。

3. OTA 域名单独、稳定。 白名单是按域名批的。OTA 下载如果用的是会变的 CDN 域名，或者和遥测共用一个域名，每次换 CDN 都要客户 IT 重新审批。

4. 无外网站点：准备离线包。 有的工厂、医院、政府站点机器人根本不出外网。离线包要做到：

• 和在线包同一套签名，设备端用同一个校验逻辑，不留「U 盘包不验签」的后门；
• 现场笔记本或 U 盘导入，导入前后都能打印当前版本、目标版本、签名校验结果；
• 带一份版本清单（哪台机器、从哪个版本、升到哪个版本），装完由现场工程师回填，因为这类站点没有云端记录。

四、A/B 分区和回滚条件：「能启动」不等于「升级成功」

A/B（双分区）方案大家都熟：新版本写进非活动分区，切换启动顺序，重启；起不来就回到旧分区。开源方案里，Mender 的做法是新版本首次启动后由客户端「提交」（commit），提交前如果重启，引导程序就认为升级失败并回滚；RAUC 配合 U-Boot 用 BOOT_<slot>_LEFT 计剩余启动次数，系统起来后跑 rauc status mark-good 才算成功，次数用完就落回另一个分区。

问题在于**「什么时候 mark-good / commit」**。很多实现是 systemd 起来就标记，这对机器人远远不够。两种方案都留了挂业务检查的位置：RAUC 是把 mark-good 放在你自己的健康检查服务最后一步；Mender 可以在 ArtifactCommit_Enter 挂一个状态脚本（state script），这个阶段在重启进新分区之后执行，脚本返回 1，更新就会中止并回滚（返回 21 是保留给「稍后重试」的，别混用）。建议把它绑定在一组业务健康检查上，全部通过才标记：

• 底盘通信、电机驱动、编码器正常；
• 急停回路自检通过；
• 定位在已知地图上收敛（置信度过阈值）；
• 能完成一次回桩对接；
• 本站点用到的外部接口（电梯、门禁、WMS）至少握手成功一次。

有三类东西 A/B 管不到，要单独设计：

1. 数据和地图格式迁移：新版本把地图或数据库升级成新格式，旧版本回来读不懂。要么迁移前备份、回滚时恢复，要么新格式保持向后兼容至少一个版本。
2. MCU、电机驱动、BMS、安全控制器的固件：它们往往不在 A/B 范围里。原则是主控软件的 N 和 N-1 都必须能和新、旧两个 MCU 固件配合，否则主控回滚了，底下的 MCU 回不去，机器照样起不来。
3. 云端接口：云端 API 先升级时，要保证对旧版本设备兼容，否则「回滚成功」的机器连不上云。

回滚触发条件写成表，发布前和客户、现场一起确认：

信号	阈值（建议起点）	动作	谁执行
新分区连续启动失败	启动次数用完	自动落回旧分区	设备（bootloader）
业务健康检查未通过	任一项，超时 15 分钟	不 mark-good，自动回滚	设备
急停 / 碰撞类事件	急停次数高于基线 + 2（基线 = 该机过去 7 天同时段日均），或出现任何碰撞事件	本批暂停 + 回滚该机	远程值班
外部接口失败（电梯、门禁、WMS）	营业时段内连续 2 次	现场回滚	现场工程师
同一新故障码	24 小时内 ≥2 台	暂停发布，等评估	发布系统自动
任务完成率	比升级前 7 天同时段低 15% 以上	暂停发布，评估是否回滚	远程值班
客户要求回滚	任何时候	直接回滚，事后再分析	现场或远程

最后一行最重要：客户说回滚就回滚，不在现场争论版本好坏。 版本好不好，事后用日志说话；现场争论只会让客户下次不再同意升级窗口。

把上表的远程判定部分写成函数，可以挂在监控上每小时跑一次：

def ota_decision(unit, base, policy=None):
    """unit：升级后指标；base：同一台机器升级前 7 天同时段的基线。
    返回 'rollback' / 'pause' / 'continue' 和原因。阈值是建议起点。"""
    p = {"task_drop": 0.15, "iface_fail": 2, "same_code_units": 2,
         "estop_margin": 2, **(policy or {})}
    if unit.get("customer_requested_rollback"):
        return "rollback", "客户要求"
    required = ("marked_good", "estop_events", "iface_fail_consecutive", "task_rate")
    missing = [k for k in required if unit.get(k) is None]
    if missing or base.get("task_rate") is None:
        return "pause", f"指标缺失 {missing or ['base.task_rate']}，先查采集，不自动回滚"
    if not unit["marked_good"]:
        return "rollback", "业务健康检查未通过"
    # base["estop_events"]：该机过去 7 天同时段的日均急停次数
    if unit.get("collision_events", 0) > 0:
        return "rollback", "出现碰撞事件"
    if unit["estop_events"] > base.get("estop_events", 0) + p["estop_margin"]:
        return "rollback", "急停次数高于基线 + 余量"
    if unit.get("iface_fail_consecutive", 0) >= p["iface_fail"]:
        return "rollback", "外部接口（电梯/门禁/WMS）连续失败"
    if unit.get("new_code_units_24h", 0) >= p["same_code_units"]:
        return "pause", "同一新故障码出现在多台设备"
    b = base.get("task_rate")
    if b and unit.get("task_rate") is not None and unit["task_rate"] < b * (1 - p["task_drop"]):
        return "pause", f"任务完成率 {unit['task_rate']:.0%}，基线 {b:.0%}"
    return "continue", "无触发项"

base = {"estop_events": 0.4, "task_rate": 0.96}   # 急停为过去 7 天同时段日均
print(ota_decision({"marked_good": True, "estop_events": 1,
                    "iface_fail_consecutive": 2, "task_rate": 0.40}, base))
# ('rollback', '外部接口（电梯/门禁/WMS）连续失败') —— 开头那家酒店的情况
print(ota_decision({"marked_good": True, "iface_fail_consecutive": 0}, base))
# ('pause', "指标缺失 ['estop_events', 'task_rate']，先查采集，不自动回滚")

五、现场回滚 SOP：北京晚上 10 点，现场的人要能自己做完

开头那个场景里，前台经理打电话时，最需要的是一个在当地、拿着 SOP、有权限的人。这个人可以是你们自己的海外工程师，也可以是 KeepRobots 这样的第三方现场服务商。不管是谁，下面这几条要在发布前就准备好：

前提（发布前做完）：

• 回滚操作能离线执行：服务菜单、按键组合或本地命令，不依赖云端，也不依赖国内实时授权；
• 现场人员有独立的服务账号，权限只到「切换分区 / 导出日志」，不到改参数；
• SOP 是英文的，每一步有截图，写清楚「哪一步做完要看到什么」。

现场步骤：

1. 确认触发条件：对照上面的触发表，拍下屏幕故障码，记下时间（UTC 和本地时间都写）。
2. 先让机器停到安全位置：遥控或手推回充电位，不在电梯口、走廊中间做回滚。
3. 导出日志包再回滚：回滚后新分区的现场就没了，先导出（日志包规格见我们之前写的故障分流和日志包那篇，这里不展开）。
4. 执行回滚：切到旧分区，重启。
5. 跑验收：定位收敛、回桩一次、外部接口（电梯 / 门禁）实际走一趟，三项都过才交还客户。
6. 通知：给客户现场负责人一句话说明「已恢复到 4.1.3，原因调查中」；给国内工单回传日志包、照片、回滚前后版本号。
7. 冻结：该站点停止接收新版本，直到国内给出根因。

第 3 步最常被跳过，代价是第二天国内醒来只看到「已回滚」，根因永远查不到。

六、给客户的变更通知模板

北美机构客户的合同或 IT 流程里，经常要求变更前书面通知，写清楚影响和回退方案。没有这个要求的客户，发一封也只有好处。下面这份可以直接改着用：

Subject: [Scheduled maintenance] Robot software update – <Site name> – <Date>

Hello <Name>,

We plan to update the software on <N> robot(s) at <Site> during the agreed
maintenance window.

  Window:              <Mon Nov 16, 02:00–04:00 Vancouver time (UTC-7)>
  Units:               <Serial numbers>; <1> unit stays on the current version
  Version:             <4.1.3> → <4.2.0>
  What changes:        <Elevator retry logic; navigation bug fixes; security patches>
  Expected impact:     Robots unavailable for about <20> minutes each, docked
  Network:             No firewall or proxy changes needed / <list if any>

Rollback plan: if any check fails, the robot returns to <4.1.3> automatically.
If you notice a problem after the update, call <on-site contact, local number>
and we will roll back without further discussion.

Before your <07:00> shift starts we will send a short confirmation.
Reply to this email if you need to move or cancel the window.

<Name>, <Company> – <email>

要点：窗口写客户本地时间，并写成「城市 + UTC 偏移」。11 月起温哥华不再是 PST，写「PT」「PST」在温哥华和西雅图之间会差出 1 小时；美西客户冬天写「Seattle time (UTC-8)」。其余：写明「留 1 台旧版本」和回滚承诺；早班前发一封确认，这一封可以由发布系统在健康检查通过后自动发。

七、北美特有的一层：射频相关的固件，先过合规闸

先说结论：在美国，07-28 前已授权的受控机器人，固件只剩「减轻危害」类的 Class I/II 许可变更能做，Class III 不行；在加拿大，影响射频特性的固件要通知 ISED、换新的 FVIN。 这就是 YAML 里那个 rf_impact 字段的由来。

FCC 2026 新规。 2026 年 7 月 28 日，FCC 发布 DA 26-786，把境外生产的先进机器人设备（地面移动的 AMR、人形、四足等，按生产地算，不按公司国籍）列入受控清单，拿到美国战争部（DoW）有条件批准的除外（截至 2026-10-14 共批了 3 项）。效果是新型号拿不到设备授权；已授权型号的进口、销售、使用不受影响。

同一天的 DA 26-789 处理固件问题。FCC 2025 年修订的 47 CFR 2.1043(b)（以及 2.932(b)，DA 26-789 一并豁免） 把受控设备排除在许可变更程序之外，不豁免的话，已授权的机器人连安全补丁都推不了。DA 26-789 的要点：

• 范围：07-28 前已授权的这类设备，「减轻对美国消费者危害」的软件 / 固件更新，可以继续走 Class I、Class II 许可变更，至少到 2029 年 1 月 1 日；原文举例包括修补漏洞、兼容不同操作系统、保证设备持续正常运行。
• 照旧的要求：Class II 仍要提交完整信息和测试结果，FCC 确认前不得销售改动后的设备，并要按 2.1043(b)(2) 附上相关声明，其中包括申请人是否作为受控通信设备的生产方被列入受控清单。
• 推论：豁免只覆盖软件 / 固件更新，硬件改动不在其中。

三类许可变更，对应到 OTA：

变更类型	47 CFR 2.1043 怎么说	对受控机器人意味着什么	rf_impact
不影响射频发射的软件改动	2.1043(a)：不需要新的申请	导航、业务逻辑、UI 一类的常规更新	none
Class I	不降低授权时报告的特性，无需向 FCC 提交	在 DA 26-789 豁免内，前提是属于「减轻危害」类更新	class1
Class II	性能有降低但仍满足规则，要提交测试结果，确认前不得销售	同上，且要走提交流程，排期要预留	class2
Class III	软件定义无线电（SDR）改变频率范围、调制方式或最大输出功率；确认前不得加载软件；做过 Class II 的设备不能再做 Class III	DA 26-789 只豁免 Class I/II，这一类不在豁免范围内	class3

另外，如果设备或其中的模组是按软件定义无线电认证的，按 47 CFR 2.944，厂商要采取措施，保证只有经过批准的软件能加载、用户不能把频率和功率改出授权范围，常见做法是软件签名、认证用户才能接入的私有网络。这和 OTA 的签名校验是同一件事：离线包验签，不只是安全问题，也是合规要求的一部分。

工程上的落点很简单：每个发布包标 rf_impact，不是 none 的，发布系统自动拦下，等合规负责人和 TCB 确认后再放行；class3 默认不进发布队列。 改 Wi-Fi 国家码、信道列表、发射功率表、LTE 频段配置，都要在这里过一次。

先确认改的是谁的证。 多数机器人的 Wi-Fi、蓝牙、LTE 用的是自带 FCC ID / IC 编号的预认证模组，许可变更的主体是证书持有人。所以改国家码、功率表之前，先确认三件事：这个 FCC ID / IC 归谁（模组厂还是你们）；要改的是模组固件、驱动里的配置文件，还是你们自己主控上的参数；模组厂对这类改动有没有书面说法。答案不同，该找的 TCB、该走的流程也不同，这一步不要由发版的人自己判断。

加拿大 ISED。 ISED 的规则独立于 FCC。按 RSP-100（第 12 版）第 10 节：Class I（C1PC）是不改变基本射频特性的改动，HVIN、PMN 不变时不需要通知 ISED；会影响产品射频特性的固件改动属于 Class III（C3PC），需要通知 ISED，并提供新的、唯一的 FVIN（固件版本识别号）。也就是说，同一个改功率表的固件，在美国、加拿大是两条流程，都要提前排。截至 2026-10-14，我们没检索到 ISED 有类似 FCC 受控清单的机器人限制。

安全认证。 如果改动涉及急停、限速、避障距离这类安全功能，而整机走过 UL 3300、CSA 等安全认证，固件变更是否需要重新评估，要看具体标准和认证机构的规则，我们没能找到可以公开引用的统一说法。做法是在 YAML 里单独标 safety_function_changed，发布前先问认证机构，拿到书面答复再进 R2。

八、发布前清单（复制即用）

【北美 OTA 发布前清单】
□ 版本号、来源版本范围、发布说明（英文）已定稿
□ rf_impact 已标注；非 none 的已有合规负责人 / TCB 书面确认（美国、加拿大分别）
□ safety_function_changed 已标注；为 true 的已有认证机构答复
□ R0 台架：A/B 切换、回滚、断电恢复各演练一次，有记录
□ mark-good 绑定业务健康检查（底盘、急停回路、定位、回桩、外部接口）
□ 数据/地图格式迁移有备份或向后兼容；MCU 固件 N/N-1 双向兼容已测
□ 离线包与在线包同一签名，离线导入流程现场走过一遍
□ 每个客户的窗口、时区（注意温哥华全年 UTC-7、美西冬季 UTC-8）已确认，通知里写「城市 + UTC 偏移」
□ 设备 / 发布系统 / 监控的 tzdata ≥ 2026b（zdump 查 America/Vancouver 2026-11-01 为 gmtoff=-25200）；JVM / ICU / pytz / Android APEX / Go 内嵌 zoneinfo 等应用自带时区库也已更新
□ 射频相关改动：已确认 FCC ID / IC 归属（模组厂还是自家）和改动所在的固件层
□ 变更通知已发，客户确认回复已存档
□ 每站点至少 1 台留在旧版本
□ 现场联系人、服务账号、英文回滚 SOP 已就位，回滚可离线执行
□ 早班前确认邮件已配置自动发送
□ 不在周五至周日（客户本地日期）启动 R2 / R3

---

总结：三条规则

1. 观察期按客户营业日算，凌晨升级、早班才是真正的考试。
2. mark-good 绑业务健康检查，回滚可离线、现场可执行，客户说回滚就回滚。
3. 每个发布包标 rf_impact：在美国，受控机器人只剩「减轻危害」的 Class I/II 变更能做，Class III 不在豁免里；在加拿大，影响射频特性的固件走 C3PC，要通知 ISED、换 FVIN。

跨 15、16 小时时差的值班和交接怎么排，可以接着看《机器人出海的技术支持时差怎么排》：https://keeprobots.com/zh/notes/robot-overseas-tech-support-timezone/ 。如果你们需要在加拿大有人能按这份 SOP 在现场回滚、验收，KeepRobots 的服务范围和按小时计费方式写在这里：https://keeprobots.com/zh/service/canada/

---

参考来源

• FCC DA 26-786（2026-07-28，受控清单新增境外生产的先进机器人设备）：https://docs.fcc.gov/public/attachments/DA-26-786A1.pdf
• FCC DA 26-789（2026-07-28，OET 豁免已授权受控机器人 / 逆变器的 Class I、II 软件固件许可变更限制，至少到 2029-01-01）：https://docs.fcc.gov/public/attachments/DA-26-789A1.pdf
• 47 CFR 2.1043 许可变更（Class I / II / III）：https://www.law.cornell.edu/cfr/text/47/2.1043
• 47 CFR 2.944 软件定义无线电的软件安全要求：https://www.law.cornell.edu/cfr/text/47/2.944
• ISED RSP-100 第 12 版第 10 节（C1PC–C4PC，固件改动与 FVIN）：https://ised-isde.canada.ca/site/spectrum-management-telecommunications/en/devices-and-equipment/radio-standards-procedures-rsp/rsp-100-certification-radio-apparatus-and-broadcasting-equipment
• BC 省永久夏令时（2026-03-08 最后一次拨钟，全年 UTC-7）：https://www2.gov.bc.ca/gov/content/governments/celebrating-british-columbia/daylight-saving-time
• BC 政府新闻稿：https://news.gov.bc.ca/releases/2026AG0013-000209
• Mender A/B 更新与提交 / 自动回滚：https://docs.mender.io/overview/introduction
• Mender 状态脚本（ArtifactCommit 阶段在重启后执行，脚本返回错误即中止并回滚）：https://docs.mender.io/artifact-creation/state-scripts
• tzdata 2026b：America/Vancouver 自 2026-11-01 起永久 UTC-7（PostgreSQL 同步 tzdata 2026b 的提交说明）：https://www.postgresql.org/message-id/E1wGJOa-002XtW-2I@gemulon.postgresql.org
• FCC 有条件批准名单（DA 26-1089 附录 B）与受控清单：https://www.fcc.gov/supplychain/coveredlist
• RAUC 与 U-Boot 集成（BOOT_ORDER、BOOT_x_LEFT、rauc status mark-good）：https://rauc.readthedocs.io/en/latest/integration.html