手机弹出系统更新，很多人的习惯是：
晚上插着电，让它自己更。

第二天醒来，
最多重新适应一下图标。

AGV调度系统如果也这么干，
生产现场可能会给你上一堂很贵的课。

移动机器人系统里的软件，不只是界面。
调度规则、地图、车辆固件、接口协议、任务逻辑，
都可能和生产系统连在一起。
一个版本改了任务字段，WMS还按旧格式发。
一台车升级了，其他车还在旧版本。
地图发布了新规则，夜班正在跑的任务却没同步。

大家都没坏，
就是突然开始听不懂彼此。

所以软件升级件事，
不是看新功能有多香，是先确认影响范围。

这次改的是单车程序，还是调度平台？
会不会碰地图？接口有没有变化？
哪些车型要一起升级？生产系统要不要配合？
把边界画清楚，后面才知道该测什么。

第二件事，是先在可控环境里验证。

有测试环境更好；没有，也至少选低风险车辆、低峰时段或隔离区域先跑。
重点不是软件能打开，而是完整任务能不能走通：
接单、取货、避让、对接、回充、异常恢复，这些都要看。

第三件事，提前备份。

地图、参数、任务规则、接口配置、关键数据库信息，能备份的先备份。
更重要的是，升级失败以后能不能回滚。

理论上应该没问题不是回滚方案，
真正的方案应该写清楚：
出现什么情况停止升级，谁判断，怎么恢复旧版本，
预计恢复后先验证哪几条关键业务。

时间也要选，别挑周一早班、月底冲产量、客户马上来审核的时候，
大家一起见证版本发布。
选择生产相对平稳的窗口，让工程、IT、现场负责人都在，出问题时有人能处理。

升级完成以后，也别跑一趟就宣布胜利。
先看关键任务，再看多车协同，最后观察一段真实生产。
日志、报警、接口数据有没有异常，更好一起对。
因为有些问题不会当场爆炸，它更喜欢在第三十条任务时悄悄出现。

还有版本记录

哪天升的，从什么版本到什么版本，改了什么，谁确认的，出了问题找哪份备份。
半年后排查故障时，这张记录能让工程师少玩很多轮我记得好像改过。

自动化系统当然要升级

只是升级的目标应该是让生产更稳定，不是让生产顺便参与公测。

如果车队规模比较大，还可以分批升级。
先挑一小部分车辆跑新版本，确认关键业务稳定，再逐步扩大。
这样一旦发现兼容性问题，影响范围可控，不至于十几台车一起进入大家都更新了，但谁也不敢动的状态。

接口也要做版本兼容确认
调度系统、WMS、MES、PLC之间，只要有一方改了字段、状态码或通信方式，就要把上下游一起测。
升级清单里更好直接写出：
涉及哪个系统、谁负责验证、验证通过看什么结果。

真正专业的升级，不是追求最快装上新版本。
是新版本进来以后，生产几乎感觉不到它来过。