本文由 KeepRobots 團隊撰寫。KeepRobots 是溫哥華的機器人現(xiàn)場服務(wù)公司給別家生產(chǎn)的機器人做北美現(xiàn)場部署和售后。本文是工程筆記不是法律或認證意見涉及 FCC / ISED 許可變更的判斷請以你們的認證機構(gòu)TCB / CB和律師意見為準(zhǔn)。假設(shè)一個場景溫哥華一家酒店和廠商約好配送機器人的固件升級放在客戶本地凌晨 2 點到 4 點。這時是北京下午 5 點到 7 點研發(fā)在工位上看著 20 臺機器的進度條全部變綠下班回家。早上 7 點酒店早班開始第一單送餐機器人在電梯口呼梯失敗。新版本改了電梯對接模塊的重試邏輯臺架上沒有那臺電梯網(wǎng)關(guān)測不出來。這時北京是晚上 10 點能拍板回滾的人已經(jīng)下線前臺經(jīng)理只看到 20 臺機器同時罷工。北美的維護窗口其實落在北京的工作時間里真正出問題的時候卻是北京深夜。這篇講的就是由此推出來的一條主線回滾的判斷不能等國內(nèi)醒來要提前寫成規(guī)則交給設(shè)備和現(xiàn)場的人去執(zhí)行。下面依次是時間怎么算、發(fā)布環(huán)怎么分、客戶網(wǎng)絡(luò)對 OTA 的限制、A/B 回滾條件、現(xiàn)場回滾 SOP、給客戶的變更通知模板最后是北美特有的一層FCC 2026 新規(guī)和 ISED 規(guī)則下哪些固件還能推、要先報備什么。一、先把時間算對窗口在北京下午出事在北京深夜北美很多機構(gòu)客戶的 IT 變更都要走審批維護窗口一般約在客戶本地夜間或周末。先把幾個常見時區(qū)換算清楚溫哥華BC 省2026 年 3 月 8 日是最后一次撥鐘從 11 月 1 日起不再撥回全年固定 UTC-7。北京和溫哥華全年差 15 小時。西雅圖、舊金山、洛杉磯華盛頓州、俄勒岡州、加州沒有跟進仍然冬夏撥鐘。夏令時差 15 小時冬天11 月初到 3 月中旬下一次撥鐘是 2027-03-14差 16 小時。也就是說今年冬天開始溫哥華和西雅圖之間會有 1 小時時差同一個客戶如果在兩地都有站點窗口要分開排。另外BC 東南部 East Kootenay、Golden 等用山地時間的地區(qū)不受這次變化影響仍跟阿爾伯塔一起撥鐘。多倫多、紐約夏令時差 12 小時冬天差 13 小時。今年還有一個時效坑tzdata。設(shè)備、發(fā)布系統(tǒng)、監(jiān)控里的時區(qū)換算靠的是系統(tǒng)自帶的 IANA 時區(qū)數(shù)據(jù)庫tzdata。tzdata 到2026b才把 America/Vancouver 改成 11 月 1 日起永久 UTC-7縮寫暫記為 MST判斷時以 UTC 偏移為準(zhǔn)。還在用舊 tzdata 的系統(tǒng)11 月 1 日會照舊把溫哥華時間撥回 UTC-8發(fā)布系統(tǒng)按「America/Vancouver 02:00」排的窗口實際晚開 1 小時監(jiān)控里的「早班 07:00」也全部錯位 1 小時而且不會有任何報錯。機器人主控、云端發(fā)布服務(wù)、監(jiān)控告警三處都要查# 看 2026-11-01 那次切換判據(jù)是 gmtoff-25200UTC-7# gmtoff-28800UTC-8說明 tzdata 太舊。縮寫 MST/PST 只作參考MST 是暫定寫法zdump-v-c2026,2027America/Vancouver|grepNov 1# 沒有 zdump 的設(shè)備GNU date新數(shù)據(jù)應(yīng)輸出 05:00UTC-7舊數(shù)據(jù)是 04:00UTC-8TZAmerica/Vancouverdate-d1796126400# 即 2026-12-01 12:00 UTC系統(tǒng) tzdata 更新了還不夠應(yīng)用自帶的時區(qū)庫要分別查JVM 的 tzdata、Node.js / Chrome 內(nèi)置的 ICU、Python 的 pytz / tzdata 包、Android 的 tzdata APEX、Go 程序內(nèi)嵌的 zoneinfo都可能比系統(tǒng)舊。把「客戶本地凌晨 2 點開窗口」和「早班 7 點開工」換成北京時間客戶所在地窗口 02:00 對應(yīng)北京早班 07:00 對應(yīng)北京溫哥華全年 UTC-717:0022:00西雅圖 / 洛杉磯冬季 UTC-818:0023:00多倫多 / 紐約冬季 UTC-515:0020:00對研發(fā)是好消息推送本身可以在北京下午盯著做。壞消息在第三列版本在真實業(yè)務(wù)里第一次「受壓」是客戶早班開工那一刻這時國內(nèi)要么已經(jīng)下班要么快睡了。所以接下來每一節(jié)都在回答一個問題北京晚上 10 點出問題誰能在不叫醒總部的情況下把機器恢復(fù)二、發(fā)布環(huán)觀察期按「營業(yè)日」算不按小時灰度的核心不是比例而是每一環(huán)要過一次完整的真實業(yè)務(wù)高峰。凌晨升級完機器在空蕩蕩的走廊里跑 3 個小時什么都不說明呼梯、閘機、早高峰排隊這些場景要到營業(yè)時間才會出現(xiàn)。下面是一張可以直接拿去改的發(fā)布環(huán)表比例和時長是建議起點按你們的設(shè)備規(guī)模調(diào)環(huán)范圍進入條件最短觀察期誰簽字放行R0 臺架國內(nèi)臺架 同硬件版本整機CI 全綠A/B 切換、回滾、斷電恢復(fù)各演練一次24 小時連續(xù)跑研發(fā)負責(zé)人R1 北美樣機北美的 demo 機、備用機不在客戶現(xiàn)場R0 通過離線安裝包驗證過24 小時含一次對接真實電梯/門禁如有條件研發(fā) 海外售后R2 金絲雀1 個站點、1–2 臺客戶書面同意R1 通過變更通知已發(fā)、窗口已確認1 個完整營業(yè)日含早高峰海外售后負責(zé)人R3 小批≤10% 設(shè)備覆蓋不同場景類型酒店 / 倉庫 / 商場R2 無觸發(fā)項3 個營業(yè)日海外售后負責(zé)人R4 全量其余設(shè)備按各客戶窗口分批R3 無觸發(fā)項持續(xù)監(jiān)控 7 天自動觸發(fā)即暫停幾條容易漏的規(guī)則同一站點不要一次升滿。留 1 臺在舊版本出問題時客戶至少還有一臺能用現(xiàn)場也有對照組。按「場景類型」挑金絲雀不按「誰最好說話」。電梯對接、閘機、WMS 接口各選一個代表站點。R2 之后的每一批都要給客戶發(fā)變更通知模板見第六節(jié)不能因為「之前推過」就省掉。周五到周日客戶本地日期不啟動 R2/R3。周五凌晨升級觀察期就跨進周末國內(nèi)周末值班最薄很多寫字樓、學(xué)校站點周末根本沒有「完整營業(yè)日」問題要拖到周一早班才暴露那時離升級已經(jīng)三天日志和現(xiàn)場都涼了。把這張表寫成配置交給發(fā)布系統(tǒng)執(zhí)行比寫在 Wiki 里靠人記要可靠# rollout-policy.yaml —— 字段名為示例按你們的發(fā)布平臺改release:4.2.0from_versions:[4.1.x]rf_impact:none# none | class1 | class2 | class3見第七節(jié)非 none 先過合規(guī)閘safety_function_changed:false# 改了急停、限速、避障參數(shù) → 先問認證機構(gòu)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]三、客戶網(wǎng)絡(luò)OTA 先要能下載再談灰度北美企業(yè)網(wǎng)的認證方式、出站白名單、TLS 解密審批我們在另一篇工程筆記客戶安全團隊會問的 7 個問題里單獨寫過這里不重復(fù)只說和 OTA 直接相關(guān)的四件事1. 下載和安裝分開。白天在客戶網(wǎng)絡(luò)空閑時下載、校驗簽名、寫進非活動分區(qū)夜里窗口只做「切換 重啟 健康檢查」。這樣窗口里不會因為下載慢、代理超時把 2 小時耗完。2. 下載器要能走代理、能斷點續(xù)傳。強制代理的網(wǎng)絡(luò)里OTA 客戶端如果只會直連就永遠下不到包。支持 HTTP 代理配置、HTTP Range 續(xù)傳單個包盡量做差分別指望客戶 IT 為一次升級調(diào)整帶寬策略。3. OTA 域名單獨、穩(wěn)定。白名單是按域名批的。OTA 下載如果用的是會變的 CDN 域名或者和遙測共用一個域名每次換 CDN 都要客戶 IT 重新審批。4. 無外網(wǎng)站點準(zhǔn)備離線包。有的工廠、醫(yī)院、政府站點機器人根本不出外網(wǎng)。離線包要做到和在線包同一套簽名設(shè)備端用同一個校驗邏輯不留「U 盤包不驗簽」的后門現(xiàn)場筆記本或 U 盤導(dǎo)入導(dǎo)入前后都能打印當(dāng)前版本、目標(biāo)版本、簽名校驗結(jié)果帶一份版本清單哪臺機器、從哪個版本、升到哪個版本裝完由現(xiàn)場工程師回填因為這類站點沒有云端記錄。四、A/B 分區(qū)和回滾條件「能啟動」不等于「升級成功」A/B雙分區(qū)方案大家都熟新版本寫進非活動分區(qū)切換啟動順序重啟起不來就回到舊分區(qū)。開源方案里Mender 的做法是新版本首次啟動后由客戶端「提交」commit提交前如果重啟引導(dǎo)程序就認為升級失敗并回滾RAUC 配合 U-Boot 用BOOT_slot_LEFT計剩余啟動次數(shù)系統(tǒng)起來后跑rauc status mark-good才算成功次數(shù)用完就落回另一個分區(qū)。問題在于**「什么時候 mark-good / commit」**。很多實現(xiàn)是 systemd 起來就標(biāo)記這對機器人遠遠不夠。兩種方案都留了掛業(yè)務(wù)檢查的位置RAUC 是把mark-good放在你自己的健康檢查服務(wù)最后一步Mender 可以在ArtifactCommit_Enter掛一個狀態(tài)腳本state script這個階段在重啟進新分區(qū)之后執(zhí)行腳本返回 1更新就會中止并回滾返回 21 是保留給「稍后重試」的別混用。建議把它綁定在一組業(yè)務(wù)健康檢查上全部通過才標(biāo)記底盤通信、電機驅(qū)動、編碼器正常急?；芈纷詸z通過定位在已知地圖上收斂置信度過閾值能完成一次回樁對接本站點用到的外部接口電梯、門禁、WMS至少握手成功一次。有三類東西 A/B 管不到要單獨設(shè)計數(shù)據(jù)和地圖格式遷移新版本把地圖或數(shù)據(jù)庫升級成新格式舊版本回來讀不懂。要么遷移前備份、回滾時恢復(fù)要么新格式保持向后兼容至少一個版本。MCU、電機驅(qū)動、BMS、安全控制器的固件它們往往不在 A/B 范圍里。原則是主控軟件的 N 和 N-1 都必須能和新、舊兩個 MCU 固件配合否則主控回滾了底下的 MCU 回不去機器照樣起不來。云端接口云端 API 先升級時要保證對舊版本設(shè)備兼容否則「回滾成功」的機器連不上云?；貪L觸發(fā)條件寫成表發(fā)布前和客戶、現(xiàn)場一起確認信號閾值建議起點動作誰執(zhí)行新分區(qū)連續(xù)啟動失敗啟動次數(shù)用完自動落回舊分區(qū)設(shè)備bootloader業(yè)務(wù)健康檢查未通過任一項超時 15 分鐘不 mark-good自動回滾設(shè)備急停 / 碰撞類事件急停次數(shù)高于基線 2基線 該機過去 7 天同時段日均或出現(xiàn)任何碰撞事件本批暫停 回滾該機遠程值班外部接口失敗電梯、門禁、WMS營業(yè)時段內(nèi)連續(xù) 2 次現(xiàn)場回滾現(xiàn)場工程師同一新故障碼24 小時內(nèi) ≥2 臺暫停發(fā)布等評估發(fā)布系統(tǒng)自動任務(wù)完成率比升級前 7 天同時段低 15% 以上暫停發(fā)布評估是否回滾遠程值班客戶要求回滾任何時候直接回滾事后再分析現(xiàn)場或遠程最后一行最重要客戶說回滾就回滾不在現(xiàn)場爭論版本好壞。版本好不好事后用日志說話現(xiàn)場爭論只會讓客戶下次不再同意升級窗口。把上表的遠程判定部分寫成函數(shù)可以掛在監(jiān)控上每小時跑一次defota_decision(unit,base,policyNone):unit升級后指標(biāo)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指標(biāo)缺失{missingor[base.task_rate]}先查采集不自動回滾ifnotunit[marked_good]:returnrollback,業(yè)務(wù)健康檢查未通過# base[estop_events]該機過去 7 天同時段的日均急停次數(shù)ifunit.get(collision_events,0)0:returnrollback,出現(xiàn)碰撞事件ifunit[estop_events]base.get(estop_events,0)p[estop_margin]:returnrollback,急停次數(shù)高于基線 余量ifunit.get(iface_fail_consecutive,0)p[iface_fail]:returnrollback,外部接口電梯/門禁/WMS連續(xù)失敗ifunit.get(new_code_units_24h,0)p[same_code_units]:returnpause,同一新故障碼出現(xiàn)在多臺設(shè)備bbase.get(task_rate)ifbandunit.get(task_rate)isnotNoneandunit[task_rate]b*(1-p[task_drop]):returnpause,f任務(wù)完成率{unit[task_rate]:.0%}基線{b:.0%}returncontinue,無觸發(fā)項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連續(xù)失敗) —— 開頭那家酒店的情況print(ota_decision({marked_good:True,iface_fail_consecutive:0},base))# (pause, 指標(biāo)缺失 [estop_events, task_rate]先查采集不自動回滾)五、現(xiàn)場回滾 SOP北京晚上 10 點現(xiàn)場的人要能自己做完開頭那個場景里前臺經(jīng)理打電話時最需要的是一個在當(dāng)?shù)?、拿?SOP、有權(quán)限的人。這個人可以是你們自己的海外工程師也可以是 KeepRobots 這樣的第三方現(xiàn)場服務(wù)商。不管是誰下面這幾條要在發(fā)布前就準(zhǔn)備好前提發(fā)布前做完回滾操作能離線執(zhí)行服務(wù)菜單、按鍵組合或本地命令不依賴云端也不依賴國內(nèi)實時授權(quán)現(xiàn)場人員有獨立的服務(wù)賬號權(quán)限只到「切換分區(qū) / 導(dǎo)出日志」不到改參數(shù)SOP 是英文的每一步有截圖寫清楚「哪一步做完要看到什么」。現(xiàn)場步驟確認觸發(fā)條件對照上面的觸發(fā)表拍下屏幕故障碼記下時間UTC 和本地時間都寫。先讓機器停到安全位置遙控或手推回充電位不在電梯口、走廊中間做回滾。導(dǎo)出日志包再回滾回滾后新分區(qū)的現(xiàn)場就沒了先導(dǎo)出日志包規(guī)格見我們之前寫的故障分流和日志包那篇這里不展開。執(zhí)行回滾切到舊分區(qū)重啟。跑驗收定位收斂、回樁一次、外部接口電梯 / 門禁實際走一趟三項都過才交還客戶。通知給客戶現(xiàn)場負責(zé)人一句話說明「已恢復(fù)到 4.1.3原因調(diào)查中」給國內(nèi)工單回傳日志包、照片、回滾前后版本號。凍結(jié)該站點停止接收新版本直到國內(nèi)給出根因。第 3 步最常被跳過代價是第二天國內(nèi)醒來只看到「已回滾」根因永遠查不到。六、給客戶的變更通知模板北美機構(gòu)客戶的合同或 IT 流程里經(jīng)常要求變更前書面通知寫清楚影響和回退方案。沒有這個要求的客戶發(fā)一封也只有好處。下面這份可以直接改著用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 臺舊版本」和回滾承諾早班前發(fā)一封確認這一封可以由發(fā)布系統(tǒng)在健康檢查通過后自動發(fā)。七、北美特有的一層射頻相關(guān)的固件先過合規(guī)閘先說結(jié)論在美國07-28 前已授權(quán)的受控機器人固件只?！笢p輕危害」類的 Class I/II 許可變更能做Class III 不行在加拿大影響射頻特性的固件要通知 ISED、換新的 FVIN。這就是 YAML 里那個rf_impact字段的由來。FCC 2026 新規(guī)。2026 年 7 月 28 日FCC 發(fā)布 DA 26-786把境外生產(chǎn)的先進機器人設(shè)備地面移動的 AMR、人形、四足等按生產(chǎn)地算不按公司國籍列入受控清單拿到美國戰(zhàn)爭部DoW有條件批準(zhǔn)的除外截至 2026-10-14 共批了 3 項。效果是新型號拿不到設(shè)備授權(quán)已授權(quán)型號的進口、銷售、使用不受影響。同一天的 DA 26-789 處理固件問題。FCC 2025 年修訂的 47 CFR 2.1043(b)以及 2.932(b)DA 26-789 一并豁免 把受控設(shè)備排除在許可變更程序之外不豁免的話已授權(quán)的機器人連安全補丁都推不了。DA 26-789 的要點范圍07-28 前已授權(quán)的這類設(shè)備「減輕對美國消費者危害」的軟件 / 固件更新可以繼續(xù)走 Class I、Class II 許可變更至少到 2029 年 1 月 1 日原文舉例包括修補漏洞、兼容不同操作系統(tǒng)、保證設(shè)備持續(xù)正常運行。照舊的要求Class II 仍要提交完整信息和測試結(jié)果FCC 確認前不得銷售改動后的設(shè)備并要按 2.1043(b)(2) 附上相關(guān)聲明其中包括申請人是否作為受控通信設(shè)備的生產(chǎn)方被列入受控清單。推論豁免只覆蓋軟件 / 固件更新硬件改動不在其中。三類許可變更對應(yīng)到 OTA變更類型47 CFR 2.1043 怎么說對受控機器人意味著什么rf_impact不影響射頻發(fā)射的軟件改動2.1043(a)不需要新的申請導(dǎo)航、業(yè)務(wù)邏輯、UI 一類的常規(guī)更新noneClass I不降低授權(quán)時報告的特性無需向 FCC 提交在 DA 26-789 豁免內(nèi)前提是屬于「減輕危害」類更新class1Class II性能有降低但仍滿足規(guī)則要提交測試結(jié)果確認前不得銷售同上且要走提交流程排期要預(yù)留class2Class III軟件定義無線電SDR改變頻率范圍、調(diào)制方式或最大輸出功率確認前不得加載軟件做過 Class II 的設(shè)備不能再做 Class IIIDA 26-789 只豁免 Class I/II這一類不在豁免范圍內(nèi)class3另外如果設(shè)備或其中的模組是按軟件定義無線電認證的按 47 CFR 2.944廠商要采取措施保證只有經(jīng)過批準(zhǔn)的軟件能加載、用戶不能把頻率和功率改出授權(quán)范圍常見做法是軟件簽名、認證用戶才能接入的私有網(wǎng)絡(luò)。這和 OTA 的簽名校驗是同一件事離線包驗簽不只是安全問題也是合規(guī)要求的一部分。工程上的落點很簡單每個發(fā)布包標(biāo)rf_impact不是none的發(fā)布系統(tǒng)自動攔下等合規(guī)負責(zé)人和 TCB 確認后再放行class3默認不進發(fā)布隊列。改 Wi-Fi 國家碼、信道列表、發(fā)射功率表、LTE 頻段配置都要在這里過一次。先確認改的是誰的證。多數(shù)機器人的 Wi-Fi、藍牙、LTE 用的是自帶 FCC ID / IC 編號的預(yù)認證模組許可變更的主體是證書持有人。所以改國家碼、功率表之前先確認三件事這個 FCC ID / IC 歸誰模組廠還是你們要改的是模組固件、驅(qū)動里的配置文件還是你們自己主控上的參數(shù)模組廠對這類改動有沒有書面說法。答案不同該找的 TCB、該走的流程也不同這一步不要由發(fā)版的人自己判斷。加拿大 ISED。ISED 的規(guī)則獨立于 FCC。按 RSP-100第 12 版第 10 節(jié)Class IC1PC是不改變基本射頻特性的改動HVIN、PMN 不變時不需要通知 ISED會影響產(chǎn)品射頻特性的固件改動屬于 Class IIIC3PC需要通知 ISED并提供新的、唯一的 FVIN固件版本識別號。也就是說同一個改功率表的固件在美國、加拿大是兩條流程都要提前排。截至 2026-10-14我們沒檢索到 ISED 有類似 FCC 受控清單的機器人限制。安全認證。如果改動涉及急停、限速、避障距離這類安全功能而整機走過 UL 3300、CSA 等安全認證固件變更是否需要重新評估要看具體標(biāo)準(zhǔn)和認證機構(gòu)的規(guī)則我們沒能找到可以公開引用的統(tǒng)一說法。做法是在 YAML 里單獨標(biāo)safety_function_changed發(fā)布前先問認證機構(gòu)拿到書面答復(fù)再進 R2。八、發(fā)布前清單復(fù)制即用【北美 OTA 發(fā)布前清單】 □ 版本號、來源版本范圍、發(fā)布說明英文已定稿 □ rf_impact 已標(biāo)注非 none 的已有合規(guī)負責(zé)人 / TCB 書面確認美國、加拿大分別 □ safety_function_changed 已標(biāo)注為 true 的已有認證機構(gòu)答復(fù) □ R0 臺架A/B 切換、回滾、斷電恢復(fù)各演練一次有記錄 □ mark-good 綁定業(yè)務(wù)健康檢查底盤、急?；芈?、定位、回樁、外部接口 □ 數(shù)據(jù)/地圖格式遷移有備份或向后兼容MCU 固件 N/N-1 雙向兼容已測 □ 離線包與在線包同一簽名離線導(dǎo)入流程現(xiàn)場走過一遍 □ 每個客戶的窗口、時區(qū)注意溫哥華全年 UTC-7、美西冬季 UTC-8已確認通知里寫「城市 UTC 偏移」 □ 設(shè)備 / 發(fā)布系統(tǒng) / 監(jiān)控的 tzdata ≥ 2026bzdump 查 America/Vancouver 2026-11-01 為 gmtoff-25200JVM / ICU / pytz / Android APEX / Go 內(nèi)嵌 zoneinfo 等應(yīng)用自帶時區(qū)庫也已更新 □ 射頻相關(guān)改動已確認 FCC ID / IC 歸屬模組廠還是自家和改動所在的固件層 □ 變更通知已發(fā)客戶確認回復(fù)已存檔 □ 每站點至少 1 臺留在舊版本 □ 現(xiàn)場聯(lián)系人、服務(wù)賬號、英文回滾 SOP 已就位回滾可離線執(zhí)行 □ 早班前確認郵件已配置自動發(fā)送 □ 不在周五至周日客戶本地日期啟動 R2 / R3總結(jié)三條規(guī)則觀察期按客戶營業(yè)日算凌晨升級、早班才是真正的考試。mark-good 綁業(yè)務(wù)健康檢查回滾可離線、現(xiàn)場可執(zhí)行客戶說回滾就回滾。每個發(fā)布包標(biāo)rf_impact在美國受控機器人只剩「減輕危害」的 Class I/II 變更能做Class III 不在豁免里在加拿大影響射頻特性的固件走 C3PC要通知 ISED、換 FVIN?？?15、16 小時時差的值班和交接怎么排可以接著看《機器人出海的技術(shù)支持時差怎么排》https://keeprobots.com/zh/notes/robot-overseas-tech-support-timezone/ 。如果你們需要在加拿大有人能按這份 SOP 在現(xiàn)場回滾、驗收KeepRobots 的服務(wù)范圍和按小時計費方式寫在這里https://keeprobots.com/zh/service/canada/參考來源FCC DA 26-7862026-07-28受控清單新增境外生產(chǎn)的先進機器人設(shè)備https://docs.fcc.gov/public/attachments/DA-26-786A1.pdfFCC DA 26-7892026-07-28OET 豁免已授權(quán)受控機器人 / 逆變器的 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 節(jié)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 狀態(tài)腳本ArtifactCommit 階段在重啟后執(zhí)行腳本返回錯誤即中止并回滾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 有條件批準(zhǔn)名單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