本文由 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-25200UTC-7# gmtoff-28800UTC-8说明 tzdata 太旧。缩写 MST/PST 只作参考MST 是暂定写法zdump-v-c2026,2027America/Vancouver|grepNov 1# 没有 zdump 的设备GNU date新数据应输出 05:00UTC-7旧数据是 04:00UTC-8TZAmerica/Vancouverdate-d1796126400# 即 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-717:0022:00西雅图 / 洛杉矶冬季 UTC-818:0023:00多伦多 / 纽约冬季 UTC-515:0020: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.0from_versions:[4.1.x]rf_impact:none# none | class1 | class2 | class3见第七节非 none 先过合规闸safety_function_changed:false# 改了急停、限速、避障参数 → 先问认证机构rings:-name:R2-canaryselector:{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-smallselector:{percent:10,spread_by:site_type}min_observation:{business_days:3}-name:R4-allselector:{percent:100}batch_by:customer_window# 按每个客户自己的窗口分批precheck:# 任一不满足本台跳过不进入安装battery_soc_min:60docked:trueno_active_task:truefree_space_mb_min:1500auto_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 管不到要单独设计数据和地图格式迁移新版本把地图或数据库升级成新格式旧版本回来读不懂。要么迁移前备份、回滚时恢复要么新格式保持向后兼容至少一个版本。MCU、电机驱动、BMS、安全控制器的固件它们往往不在 A/B 范围里。原则是主控软件的 N 和 N-1 都必须能和新、旧两个 MCU 固件配合否则主控回滚了底下的 MCU 回不去机器照样起不来。云端接口云端 API 先升级时要保证对旧版本设备兼容否则「回滚成功」的机器连不上云。回滚触发条件写成表发布前和客户、现场一起确认信号阈值建议起点动作谁执行新分区连续启动失败启动次数用完自动落回旧分区设备bootloader业务健康检查未通过任一项超时 15 分钟不 mark-good自动回滚设备急停 / 碰撞类事件急停次数高于基线 2基线 该机过去 7 天同时段日均或出现任何碰撞事件本批暂停 回滚该机远程值班外部接口失败电梯、门禁、WMS营业时段内连续 2 次现场回滚现场工程师同一新故障码24 小时内 ≥2 台暂停发布等评估发布系统自动任务完成率比升级前 7 天同时段低 15% 以上暂停发布评估是否回滚远程值班客户要求回滚任何时候直接回滚事后再分析现场或远程最后一行最重要客户说回滚就回滚不在现场争论版本好坏。版本好不好事后用日志说话现场争论只会让客户下次不再同意升级窗口。把上表的远程判定部分写成函数可以挂在监控上每小时跑一次defota_decision(unit,base,policyNone):unit升级后指标base同一台机器升级前 7 天同时段的基线。 返回 rollback / pause / continue 和原因。阈值是建议起点。p{task_drop:0.15,iface_fail:2,same_code_units:2,estop_margin:2,**(policyor{})}ifunit.get(customer_requested_rollback):returnrollback,客户要求required(marked_good,estop_events,iface_fail_consecutive,task_rate)missing[kforkinrequiredifunit.get(k)isNone]ifmissingorbase.get(task_rate)isNone:returnpause,f指标缺失{missingor[base.task_rate]}先查采集不自动回滚ifnotunit[marked_good]:returnrollback,业务健康检查未通过# base[estop_events]该机过去 7 天同时段的日均急停次数ifunit.get(collision_events,0)0:returnrollback,出现碰撞事件ifunit[estop_events]base.get(estop_events,0)p[estop_margin]:returnrollback,急停次数高于基线 余量ifunit.get(iface_fail_consecutive,0)p[iface_fail]:returnrollback,外部接口电梯/门禁/WMS连续失败ifunit.get(new_code_units_24h,0)p[same_code_units]:returnpause,同一新故障码出现在多台设备bbase.get(task_rate)ifbandunit.get(task_rate)isnotNoneandunit[task_rate]b*(1-p[task_drop]):returnpause,f任务完成率{unit[task_rate]:.0%}基线{b:.0%}returncontinue,无触发项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 是英文的每一步有截图写清楚「哪一步做完要看到什么」。现场步骤确认触发条件对照上面的触发表拍下屏幕故障码记下时间UTC 和本地时间都写。先让机器停到安全位置遥控或手推回充电位不在电梯口、走廊中间做回滚。导出日志包再回滚回滚后新分区的现场就没了先导出日志包规格见我们之前写的故障分流和日志包那篇这里不展开。执行回滚切到旧分区重启。跑验收定位收敛、回桩一次、外部接口电梯 / 门禁实际走一趟三项都过才交还客户。通知给客户现场负责人一句话说明「已恢复到 4.1.3原因调查中」给国内工单回传日志包、照片、回滚前后版本号。冻结该站点停止接收新版本直到国内给出根因。第 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 一类的常规更新noneClass I不降低授权时报告的特性无需向 FCC 提交在 DA 26-789 豁免内前提是属于「减轻危害」类更新class1Class II性能有降低但仍满足规则要提交测试结果确认前不得销售同上且要走提交流程排期要预留class2Class III软件定义无线电SDR改变频率范围、调制方式或最大输出功率确认前不得加载软件做过 Class II 的设备不能再做 Class IIIDA 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 IC1PC是不改变基本射频特性的改动HVIN、PMN 不变时不需要通知 ISED会影响产品射频特性的固件改动属于 Class IIIC3PC需要通知 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 ≥ 2026bzdump 查 America/Vancouver 2026-11-01 为 gmtoff-25200JVM / ICU / pytz / Android APEX / Go 内嵌 zoneinfo 等应用自带时区库也已更新 □ 射频相关改动已确认 FCC ID / IC 归属模组厂还是自家和改动所在的固件层 □ 变更通知已发客户确认回复已存档 □ 每站点至少 1 台留在旧版本 □ 现场联系人、服务账号、英文回滚 SOP 已就位回滚可离线执行 □ 早班前确认邮件已配置自动发送 □ 不在周五至周日客户本地日期启动 R2 / R3总结三条规则观察期按客户营业日算凌晨升级、早班才是真正的考试。mark-good 绑业务健康检查回滚可离线、现场可执行客户说回滚就回滚。每个发布包标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-7862026-07-28受控清单新增境外生产的先进机器人设备https://docs.fcc.gov/public/attachments/DA-26-786A1.pdfFCC DA 26-7892026-07-28OET 豁免已授权受控机器人 / 逆变器的 Class I、II 软件固件许可变更限制至少到 2029-01-01https://docs.fcc.gov/public/attachments/DA-26-789A1.pdf47 CFR 2.1043 许可变更Class I / II / IIIhttps://www.law.cornell.edu/cfr/text/47/2.104347 CFR 2.944 软件定义无线电的软件安全要求https://www.law.cornell.edu/cfr/text/47/2.944ISED RSP-100 第 12 版第 10 节C1PC–C4PC固件改动与 FVINhttps://ised-isde.canada.ca/site/spectrum-management-telecommunications/en/devices-and-equipment/radio-standards-procedures-rsp/rsp-100-certification-radio-apparatus-and-broadcasting-equipmentBC 省永久夏令时2026-03-08 最后一次拨钟全年 UTC-7https://www2.gov.bc.ca/gov/content/governments/celebrating-british-columbia/daylight-saving-timeBC 政府新闻稿https://news.gov.bc.ca/releases/2026AG0013-000209Mender A/B 更新与提交 / 自动回滚https://docs.mender.io/overview/introductionMender 状态脚本ArtifactCommit 阶段在重启后执行脚本返回错误即中止并回滚https://docs.mender.io/artifact-creation/state-scriptstzdata 2026bAmerica/Vancouver 自 2026-11-01 起永久 UTC-7PostgreSQL 同步 tzdata 2026b 的提交说明https://www.postgresql.org/message-id/E1wGJOa-002XtW-2Igemulon.postgresql.orgFCC 有条件批准名单DA 26-1089 附录 B与受控清单https://www.fcc.gov/supplychain/coveredlistRAUC 与 U-Boot 集成BOOT_ORDER、BOOT_x_LEFT、rauc status mark-goodhttps://rauc.readthedocs.io/en/latest/integration.html