3. 安全需求工程与可追溯性

医疗机器人功能安全验证的起点不是测试，而是需求。若安全需求本身含糊、不可验证或与用户需求脱节，后续的验证活动只能证明“系统符合了一份错误的规格”。安全需求工程的核心任务，是把临床用户需求逐层分解为可验证的安全需求，并通过追溯矩阵和变更管理，保证需求在整个生命周期中始终一致、完整、可追踪。

从用户需求到安全需求：分解逻辑

用户需求描述的是临床期望，例如“手术机器人应在主从控制下避免器械末端超出预设安全边界”。这类表述包含临床意图，但无法直接测试。安全需求分解要做的是：识别该用户需求对应的危害，确定安全目标，再导出可验证的安全需求。

以腹腔镜手术机器人为例。用户需求“医生希望机械臂在组织牵引时不会突然失控”对应危害“机械臂非预期运动导致组织撕裂”。安全目标可定义为“在任何单点故障下，机械臂末端速度不得超过 50 mm/s 且不得超出虚拟边界”。由此导出的安全需求包括：控制器需在 10 ms 内检测到位置偏差超过 2 mm 并触发限速；驱动模块需具备独立于主控制器的使能切断路径；编码器信号需进行双通道交叉校验。每条安全需求都带有安全完整性等级（如 ASIL C 或 SIL 2）、验证方法和验收准则。

分解过程中要避免两类错误：一是把设计实现当作需求，例如“使用双编码器”是方案而非需求，需求应写“位置反馈应具备独立双通道且偏差超过阈值时进入安全状态”；二是遗漏派生需求，例如限速功能本身需要电源监控、时钟监控和通信超时检测，这些必须显式写入规格书。

安全需求规格书编写

安全需求规格书不是需求列表的堆砌，而是一份可验证、可追溯、可变更控制的工程文档。每条安全需求应包含以下字段：唯一标识、需求描述、来源（用户需求/危害/法规）、安全完整性等级、验证方法、验收准则、状态和版本。描述必须使用“应”字句，避免“尽量”“适当”等模糊词。

以 SR-01 为例，规格书条目可写为：

ID: SR-01
描述: 当主从位置偏差超过 2 mm 时，控制器应在 10 ms 内将机械臂末端速度限制至 50 mm/s 以下。
来源: SG-01 / HAZ-03（非预期运动）
安全等级: ASIL C
验证方法: 故障注入 + 边界测试
验收准则: 偏差 2.1 mm 时，响应时间 ≤ 10 ms，速度 ≤ 50 mm/s，连续 100 次无漏检。
状态: 已评审 / 版本 1.2

规格书编写中常见的缺陷包括：验收准则不可测量（如“响应迅速”）、验证方法与需求不匹配（用单元测试验证系统级安全状态）、遗漏安全状态定义（进入安全状态后是否保持、如何复位）。这些缺陷会直接导致后续验证无法闭环。

需求追溯矩阵

追溯矩阵是安全需求工程的骨架。它建立用户需求、安全目标、安全需求、派生需求、设计实现、测试用例之间的双向链接。正向追溯确保每条用户需求都有安全需求覆盖，反向追溯确保每条安全需求都有来源和验证。矩阵中应标记覆盖状态：完全覆盖、部分覆盖、未覆盖、冗余覆盖。

实际操作中，可用表格维护追溯关系。例如 SR-01 对应测试用例 TC-01（偏差 2.1 mm 边界测试）、TC-02（偏差 5 mm 阶跃测试）、TC-03（传感器断线故障注入）。若某条安全需求没有对应测试用例，矩阵中显示“未验证”，必须在设计冻结前补齐。追溯矩阵还应记录变更影响：当 SR-01 的阈值从 2 mm 改为 1.5 mm 时，矩阵应自动关联到受影响的测试用例和设计模块。

变更管理在医疗机器人中的实践

医疗机器人需求变更频繁，可能来自临床反馈、法规更新、供应链替换或测试缺陷。变更管理的关键不是禁止变更，而是保证每次变更都经过影响分析、评审、验证和追溯更新。

一个可操作的变更流程如下：变更请求提交后，先做影响分析，识别受影响的安全需求、设计模块、测试用例和风险分析文档；再由安全经理和系统工程师评审，判断是否引入新的危害或降低原有安全完整性；评审通过后更新规格书和追溯矩阵，分配变更版本号；最后执行回归验证，确认变更未破坏原有安全需求。变更记录应包含变更前后对比、影响范围、验证结果和批准人。

安全需求工程与可追溯性不是一次性文档工作，而是贯穿医疗机器人设计、验证、注册和上市后监测的持续活动。只有把用户需求、安全目标、安全需求、派生需求、测试用例和变更记录串成一条可审计的链条，功能安全验证才具备工程可信度。