机器人全书

PART 09 · CHAPTER 48

可靠性、运维与网络安全

一句话理解

机器人能长期创造价值，需要把故障、维护、更新、网络和人工接管设计成日常系统，而不能只追求第一次成功。

约 1,998 字约 5 分钟5 个来源1 幅教学图

可靠性从任务连续运行开始定义。平均故障间隔（MTBF）描述可修复系统相邻故障之间的运行时间，平均修复时间（MTTR）描述恢复所需时间。在简单稳态近似下，可用性为：

\[A\approx\frac{MTBF}{MTBF+MTTR}\]

这提醒团队同时减少故障频率和修复时间。一个很少坏、每次维修需数天的机器人，与经常有小故障、几分钟可自动恢复的机器人，会对业务产生不同影响。指标还要明确哪些事件算故障：保护停机、人工复位、任务重试、换电和计划维护应分别统计。

故障来源横跨机械、电气、软件、模型与环境。齿轮和轴承磨损、线束疲劳、连接器松动、相机污染、电池衰减、散热堵塞、存储损坏、时钟漂移、地图过期和模型分布偏移都可能造成退化。很多问题不会立即停机，它们会表现为定位变差、温度升高、耗电增加或抓取重试增多。趋势监测比单次阈值更早发现风险。

可维护性要在设计阶段进入整机。模块是否容易拆换，连接器是否防错，校准是否可自动完成，维修后能否运行自检，备件是否有版本兼容规则，这些都会影响 MTTR。对人形机器人，跌倒后检查、关节零位、手指与足底耗材、线束弯折寿命尤其重要。模块化也有代价：接插件和壳体增加重量与失效点，模块边界要围绕高故障或高维护部件设计。

运维系统应保存机器人健康、任务、告警和环境四类日志。健康日志包括电压、电流、温度、振动、通信错误和存储；任务日志记录输入、状态迁移、动作与结果；告警记录触发条件、持续时间和恢复；环境日志保存地图、传感器遮挡和关键现场变化。日志时间必须同步，并带软件、固件、模型、标定和硬件序列版本。视频和原始传感器的保留要服从隐私与存储策略。

故障恢复分层处理。瞬时感知失败可以重新观察，抓取失败可以放回并换姿态，导航阻塞可以等待或改道，低电量可以回充，关键传感器异常则进入安全状态。恢复次数需要上限，持续重试可能损坏物品、阻塞流程或耗尽电池。超过阈值后，系统应请求远程协助或现场人员，并把上下文一并交给人。

FIGURE 01机器人从告警到恢复的运维闭环安全停机回归测试后上线版式 ：横向状态机：正常运行退化趋势安全监督本图用于解释“可靠性、运维与网络安全”的关键关系
图 1　机器人从告警到恢复的运维闭环

远程运维扩大了一名操作员能管理的设备数量，也增加网络与责任风险。界面需要显示机器人当前任务、身体状态、周围环境、已尝试恢复和安全条件。遥操作模式要明确速度限制、视野、通信质量、控制权转移和失联行为。操作者的响应时间、认知负担和培训也属于系统容量，不能只计算服务器并发。

软件与模型更新采用分阶段发布。先在回归集和仿真中验证，再在目标硬件做实验室测试，随后影子运行、少量设备启用，最后扩展到机群。更新包需要签名、依赖清单和兼容检查；设备保留已验证版本与回滚路径。数据库或地图格式变化要与程序版本一起迁移，避免只回滚模型后接口失配。

机器人网络安全会直接变成物理安全。攻击者可能窃取相机、篡改任务、控制运动、污染地图、替换模型或阻断通信。防护从资产与数据流清单开始：分隔机器人网络与办公网络，使用设备身份、加密通信、最小权限、密钥轮换、安全启动、签名更新、端口关闭与异常监测。ROS 2 基于 DDS 的安全能力可支持认证、加密和访问控制，仍需正确配置与密钥管理。

安全与网络安全有交叉，也要分别负责。网络断开时机器人应进入预定义安全状态；安全急停应避免依赖云服务；远程命令应经过本地约束检查。NIST CSF 2.0 的“治理、识别、保护、检测、响应、恢复”可以作为组织风险框架，工业现场还需结合 IEC 62443 等控制系统安全要求以及适用行业法规。

退役同样属于生命周期。机器人离场前要撤销证书、清除现场地图与个人数据、导出必要审计、处理电池与电子废弃物，并明确二手设备的安全更新责任。停产部件、云服务关闭和供应商退出都可能使仍在现场的设备失去维护，采购合同应提前规定数据可携、离线能力、备件期限和安全补丁。

深入阅读