2. 固件需求工程与风险分析

在医疗设备研发中，固件需求工程不是把临床愿望抄成条目，而是把“临床需要什么”逐层翻译成“固件必须做什么、做到什么程度、失效时如何被控制”。这条链路一旦断裂，常见后果是：临床功能实现了，但报警优先级错误、剂量计算边界未定义、升级失败后设备进入不可用状态，而这些恰恰是危害分析中最需要被控制的环节。本节围绕四个相互衔接的产物展开：临床需求、固件需求规格、ISO 14971 危害分析与安全需求、可追溯性矩阵。

一、从临床需求到固件需求规格的翻译

临床需求通常以“用户需要”表述，例如“护士希望在输液即将结束时提前获知”。它不能直接作为固件需求，因为缺少可验证的量化条件。翻译时至少补齐四类信息：触发条件、判定阈值、输出行为、异常处理。以输液泵为例，临床需求“提前获知输液将结束”可翻译为：当剩余量按当前流速计算小于等于 5 mL 时，固件在 200 ms 内点亮预警指示并发出低优先级提示音；当剩余量小于等于 1 mL 时，升级为中优先级报警；若流速为 0 或管路阻塞，则不按剩余量推算，直接进入阻塞报警逻辑。这里 5 mL、1 mL、200 ms 都是示例参数，实际值应由临床与风险团队确认。

固件需求规格应具备可测试性。每条需求建议包含唯一标识、需求描述、来源、验收准则和优先级。例如 FW-ALM-012：当剩余量 ≤ 5 mL 且流速 > 0 时，固件应在 200 ms 内启动预警；验收准则为在流速 10 mL/h、20 mL/h、60 mL/h 三档下各测试 10 次，预警触发时间均不超过 200 ms。这样的写法让测试工程师可以直接设计用例，而不是凭理解复现。

二、ISO 14971 危害分析与安全需求推导

ISO 14971 的核心不是“列风险”，而是建立“危害—可预见序列—伤害—风险控制”的因果链。对固件而言，危害往往来自软件行为：计算错误、状态机死锁、报警被屏蔽、升级中断、看门狗未复位、通信超时未处理。分析时先识别危害，再推演可预见的事件序列，最后判断伤害严重度与发生概率，决定风险是否可接受。

以“输液泵流速计算错误”为例：危害是实际流速高于设定流速；可预见序列为“传感器采样值被错误解析 → 流速计算使用错误系数 → 电机驱动输出偏高 → 患者单位时间入液量超预期”；伤害可能是药物过量。风险控制优先采用固有安全设计，例如双通道独立计算并比对，若两路结果偏差超过 5% 则停止输液并报警；其次才是提示性措施，例如界面提示“流速校验失败”。由此推导出的安全需求应写成固件可执行条款：FW-SAF-007：固件应每 100 ms 对两路流速计算结果进行比对，偏差 > 5% 时在 300 ms 内停止电机并触发高优先级报警；该需求必须可测试、可追溯。

三、可追溯性矩阵的建立与使用

可追溯性矩阵把临床需求、固件需求、危害、风险控制、安全需求和测试用例串起来。它的价值在于回答三个问题：每条临床需求是否都有固件实现？每个危害是否都有控制措施？每条安全需求是否都被验证？矩阵不必一开始就完美，但必须在设计输入评审前建立基线，并在变更时同步更新。

下面给出一个可参考的矩阵片段，字段包括临床需求、固件需求、关联危害、安全需求、验证方法。示例中的编号和参数均为教学示例，实际项目应按自身编号规则填写。

建立矩阵时，建议从危害分析反向检查：每个不可接受风险是否都有安全需求覆盖；再从临床需求正向检查：每条临床需求是否都有固件需求承接。两个方向都走通，才说明需求链路闭合。

四、把风险控制落到固件状态与信号链

固件安全需求最终要落到状态机和信号链上。以“双路流速比对失败”为例，信号链为：流量传感器 → 采样滤波 → 两路独立计算 → 偏差判定 → 电机驱动禁止 → 报警输出。状态机则从“运行”迁移到“安全停止”，并锁定直到人工复位。若只写“检测到异常就报警”，没有定义停止电机、锁定状态和复位条件，风险控制仍不完整。

从工程实践看，需求工程与风险分析不是两个独立阶段，而是同一链条上的双向校验。临床需求提供输入，固件需求提供实现边界，危害分析提供失效视角，安全需求提供控制措施，可追溯性矩阵提供闭合证据。只有这条链路完整，后续的架构设计、代码实现、验证测试和升级维护才有稳定的依据。