上篇聊了技术文档写作，文档是工程知识的载体。今天聊一个更严肃的话题：安全。机器人和纯软件产品最大的区别在于——它能动，而且力矩不小。一个网页App崩溃了，最坏的结果是用户刷新页面；一个机器人软件出了bug，可能导致机械臂打到人、AGV撞到货架、无人机坠毁。安全不是"锦上添花"，而是机器人产品的准入门槛。面试时如果你能聊清楚安全设计思路，会让面试官觉得你有成熟工程师的思维方式。

机器人安全涉及两个维度：功能安全（Functional Safety）和信息安全（Cybersecurity）。功能安全关注的是"系统出故障时不会造成不可接受的伤害"，信息安全关注的是"系统不被恶意攻击利用"。这两个维度在机器人领域交汇在一起——黑客入侵了你的机器人控制系统，功能安全机制就是最后一道防线。

功能安全——承认系统会出故障

功能安全的核心思路很朴素：承认系统会出故障，设计机制让故障后果可控。

IEC 61508是功能安全的"母标准"，适用于所有电气电子可编程系统。它定义了安全完整性等级（SIL 1到SIL 4），等级越高要求越严格。机器人领域更常用的是ISO 13849（机械安全标准），它用性能等级（PL a到PL e）来分级。工业机器人通常要求PL d或PL e，服务机器人根据风险评估结果确定等级。

一个典型的功能安全设计是"双通道监控"：控制电机运动的指令同时由两个独立的计算通道产生，两个通道的结果做比较。如果不一致，说明某个通道可能出了故障，系统立即进入安全状态——通常是停止运动或者降低到安全速度。

// 双通道速度监控的简化示例
bool safe_speed_monitor(double cmd_vel, double actual_vel) {
    double diff = std::abs(cmd_vel - actual_vel);
    if (diff > MAX_TOLERANCE) {
        emergency_stop();
        report_fault(FAULT_SPEED_MISMATCH);
        return false;
    }
    return true;
}

机器人的"安全状态"不一定是"完全停止"。一台手术机器人如果突然断电停机，可能比受控减速更危险。安全状态的定义要结合具体场景：工业机器人通常是STO（Safe Torque Off，安全切断力矩），服务机器人可能是"减速到安全速度后停止"，飞行中的无人机则需要"安全降落"而不是直接断电。

风险评估——安全设计的起点

安全设计不是拍脑袋加几个安全机制就完事了。它始于系统性的风险评估。

机器人领域常用的风险评估方法是ISO 12100定义的三步法：识别危险→评估风险→降低风险。具体操作时，团队会用HAZOP（危险与可操作性分析）或者FMEA（失效模式与影响分析）来系统地梳理潜在风险。

FMEA的核心是一张表：列出每个组件可能的失效模式、失效后果、严重程度评分（S）、发生频率评分（O）、可检测性评分（D）。三者的乘积RPN=S×O×D就是风险优先级数。RPN高的项目必须设计安全机制来降低风险。

举个例子：激光雷达失效。失效模式是"停止输出点云数据"，后果是"机器人无法检测前方障碍物"。严重程度S=8（可能撞到人），发生频率O=3（激光雷达本身比较可靠），可检测性D=2（很容易检测到数据丢失）。RPN=48，属于中等风险，需要设计降级策略——比如激光雷达失效时自动切换到超声波传感器并降低速度。

信息安全——机器人不能被人劫持

机器人联网后面临的安全威胁和IoT设备类似，但后果更严重。一台被黑客控制的扫地机器人顶多泄露家庭地图，一台被控制的工业机械臂可能直接变成武器。

机器人信息安全的核心防御措施包括这几个层面：

通信安全方面，所有远程控制指令必须加密传输（TLS 1.2以上），并且要做双向认证。ROS2 DDS支持SROS2安全扩展，能实现节点间的加密通信和访问控制。很多团队嫌配置麻烦不用SROS2，这在产品开发阶段可以接受，上线前必须补上。

固件安全方面，OTA升级包必须有数字签名，机器人收到升级包后先验签再安装。Bootloader要做安全启动（Secure Boot），确保只运行经过授权的固件。否则有人通过USB接口刷一个恶意固件，你的机器人就变成了别人的工具。

接口安全方面，机器人的调试接口（SSH、串口、JTAG）在产品交付后必须关闭或者加强认证。我见过一个案例：某品牌的AGV默认开启了SSH且密码是出厂默认值，客户工厂里任何能连上局域网的人都能远程控制AGV运动。

# SROS2安全配置示例
ros2 security create_keystore ~/.ros/sros2_keystore
ros2 security create_key ~/.ros/sros2_keystore /navigation_node
ros2 security create_key ~/.ros/sros2_keystore /control_node
export ROS_SECURITY_STRATEGY=Enforce
export ROS_SECURITY_ENABLE=true

软件架构中的安全设计模式

在软件架构层面，有几种常用的安全设计模式：

看门狗模式：独立的安全监控线程定期检查主程序是否正常运行。如果主程序挂死或者进入死循环，看门狗触发安全停机。ROS2的生命周期管理（Lifecycle Management）就内置了这种机制。

安全包络模式：为执行器设定安全边界——最大速度、最大力矩、最大工作范围。所有控制指令在发送给执行器之前都要经过安全包络检查，超出边界的指令被截断或拒绝。这相当于在软件和硬件之间加了一道"保险"。

降级运行模式：当某个传感器或模块失效时，系统不直接停机，而是切换到降级模式——降低速度、限制运动范围、增加安全距离。这对服务机器人特别重要，因为在人机共处的环境中突然停机可能造成其他危险。比如一台送餐机器人在餐厅走廊里突然不动了，后面端着热汤的服务员可能来不及刹住。

安全机制的有效性怎么验证？靠故障注入测试。你的安全机制说"激光雷达断连0.5秒后自动停车"，那你就真的在测试时拔掉激光雷达的数据线，看系统是不是按预期响应。安全相关的测试不能只靠模拟——模拟环境里你能控制所有变量，但真实世界的故障模式往往超出你的想象。我们团队有一个"故障星期五"的传统，每周五下午花两个小时专门做故障注入测试，每周测一个场景。

面试追问

"你们怎么做功能安全认证的？"我们用ISO 13849的框架。项目初期做风险评估确定性能等级要求，设计阶段做FMEA分析每个关键模块的失效模式，实现阶段用双通道架构和自检机制满足目标等级，验证阶段用故障注入测试验证安全机制的有效性。

"安全机制会影响性能吗？"会，但可以控制影响范围。安全监控通常在独立的低优先级线程或独立MCU上运行，不和主控制逻辑抢资源。安全包络检查的计算量很小，加在控制回路里的延迟在微秒级别。关键是把安全逻辑和性能敏感的业务逻辑解耦。

"ROS2的安全性怎么样？"ROS2比ROS1好很多——DDS中间件本身支持安全扩展（SROS2），提供了认证、加密和访问控制。但默认配置是不启用安全的，需要团队主动配置。很多团队在开发阶段关闭安全方便调试，上线时忘记打开——这是个常见的安全隐患。

---

安全设计是机器人工程师和普通软件工程师的分水岭之一。写一个能跑的机器人程序不难，写一个在任何异常情况下都不会伤人的机器人程序才是真本事。安全不是一个feature，而是一种贯穿整个开发过程的思维方式。

我参加过一个机器人项目的安全评审，评审专家问了一个让我印象很深的问题："如果你们团队里最粗心的那个人来操作这台机器人，他能搞出什么事故？"这个问题逼着我们重新审视了很多之前认为"不太可能发生"的场景。安全设计的本质就是为最坏的情况做好准备。

下一篇聊系统监控与运维。机器人部署到客户现场后，怎么知道它运行状态正常？出了问题怎么远程排查？需要更新软件怎么做到不停机？这些运维能力决定了产品的长期可靠性。

---

如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。 你的支持是我持续更新的最大动力。

「机器人软件开发面试·从入门到精通」连载系列 

上一篇：第333篇 技术文档写作——设计文档/API文档/用户手册的规范

下一篇预告：第335篇 系统监控与运维——日志/告警/远程更新的方案设计

有任何问题欢迎评论区留言，我会尽量回复。