远程升级（OTA）
Over-the-Air Update
通过无线网络远程更新设备软件、配置或模型的能力，使车队无需逐台人工操作即可完成版本迭代与问题修复。
定义
远程升级（OTA）指通过无线网络向已部署的设备下发软件、固件、配置或模型更新，无需人工到场逐台操作。对于分布在厂区各处、数量可观且经常处于作业状态的工业车辆而言，这一能力的意义不只是省人力：它决定了系统上线后还能否持续改进。缺少远程升级手段时，一次参数调整可能需要数周才能覆盖全部车辆，导致团队倾向于「不动为好」，功能迭代实质上停滞。具备该能力后，问题修复、策略调优与模型更新可以快速验证与推广，系统才能随使用而持续变好。
升级对象的分层
车辆上可远程更新的内容风险等级差异很大，应分层对待。配置参数风险最低，例如告警阈值、上报频率、区域规则，这类更新体积小、回退容易，可以较为频繁地调整。应用软件风险中等，涉及功能逻辑变化，需要经过测试流程与灰度发布。算法模型介于两者之间，体积较大但通常不改变系统骨架，重点是验证在实际数据上的表现。底层固件风险最高，一旦升级失败可能导致设备无法启动且无法远程恢复，必须具备完善的校验与回退机制。清晰区分这些层级，可以在保证安全的前提下让低风险更新保持较快节奏，而不是用最严格的流程约束所有变更。
安全与可靠性要求
远程升级本身是一条向设备写入内容的通道，因此必须防止被滥用。基本要求包括：升级包来源需可验证，通过签名机制确认确实由授权方发布且未被篡改；传输过程加密，避免内容泄露或被中间替换；设备端在安装前校验完整性，不完整或校验失败的包不予执行。可靠性方面，断电与断网随时可能发生，因此升级过程应保证原子性——要么完整生效，要么保持原状，不能停留在损坏的中间态。常见做法是采用双分区机制：新版本写入备用分区，校验通过后再切换启动，失败时自动回退到原分区，从而避免设备变砖。
灰度发布与回退
即使经过充分测试，新版本在真实车队中仍可能暴露问题，因为实际工况的多样性难以在实验室完全覆盖。因此推荐采用灰度发布：先在少量车辆上部署并观察一段时间，确认关键指标正常后再逐步扩大范围。观察指标不应只看「有没有报错」，还应包括功能表现是否符合预期、资源占用是否正常、以及是否出现异常重启。回退机制必须在发布前就准备好并验证可用，而不是出问题时才临时处理。此外，应保留版本与设备的对应记录，以便问题出现时能快速判断影响范围，并在必要时精确回退特定批次。
作业场景的特殊约束
工业车辆的升级时机需要谨慎选择，不能像手机那样随时提示用户更新。核心原则是不得在作业过程中影响车辆运行或安全功能。实践中通常设置多重条件：车辆处于静止状态、未执行任务、电量充足、且网络质量满足下载要求时才开始升级；对于涉及安全相关功能的更新，还应要求车辆处于停放状态并经过确认。升级时长也需控制，避免占用过长时间影响出车。对于多班次连续作业的车队，可行的做法是结合排班信息选择低负荷时段，或在充电时段同步进行——这也是机会充电模式带来的一个附带好处。
为什么它决定系统的长期价值
一套部署后无法便捷更新的系统，其能力在上线那一刻就基本定型了。现实中，算法策略需要根据实际数据持续调优，告警阈值需要按现场反馈修正，新的需求会不断出现，安全漏洞也需要及时修补。若每次变更都要人工逐台处理，成本会随车队规模线性增长，最终导致更新频率被迫降到极低。因此在评估车载系统时，远程升级能力应与功能本身同等重要地考察，包括是否支持分层更新、是否具备灰度与回退、升级成功率与失败恢复机制如何、以及能否远程掌握每台设备的版本状态。这些能力在项目初期不显眼，却决定了三五年后系统是否还在演进。
常见问题
远程升级会不会把设备刷坏？
设计完善的系统能避免。关键是保证原子性——要么完整生效，要么保持原状，不能停留在损坏的中间态。常见做法是双分区机制：新版本写入备用分区，校验通过后再切换启动，失败时自动回退原分区。此外升级包需签名验证来源与完整性，传输加密防篡改，并采用灰度发布先在少量车辆验证后再扩大范围。
车辆正在作业时会被强制升级吗？
不应该，也不允许。核心原则是不得在作业过程中影响车辆运行或安全功能。通常设置多重条件：车辆静止、未执行任务、电量充足、网络质量满足要求时才开始；涉及安全功能的更新还要求处于停放状态并经确认。对多班次车队，可结合排班选择低负荷时段，或在充电时段同步进行。
相关术语
本术语库收录行业通用概念，用于技术交流与知识普及，不含任何特定厂商的非公开资料。具体设备的技术参数与操作规范，请以整车厂官方文档为准。