4. 医疗设备软件可靠性指标体系
可靠性指标不是一组可以随意挑选的数字，而是把“临床可用”这一模糊目标翻译成可测量、可分配、可验证的工程语言。医疗设备软件的特殊性在于：它往往与硬件、传感器、执行机构、网络和操作者共同构成一个诊疗环路，软件失效的后果可能是报警延迟、剂量计算偏差或治疗中断。因此，指标体系必须同时回答三个问题：整机层面“可靠到什么程度”、模块与接口层面“各自承担多少”、验证阶段“用什么数据证明达标”。
一、核心指标的定义与适用边界
平均失效间隔时间（MTBF）指可修复系统在两次相邻失效之间的平均运行时间，通常以小时计。它适用于连续运行、失效后可恢复的设备软件，例如监护中央站、输液泵管理软件。但MTBF对“一次失效即造成不可接受伤害”的安全相关功能并不充分，此时更应关注危险失效的间隔或单位时间危险失效率。
可用度（A）是系统在任意时刻处于可工作状态的概率，稳态下可近似为 A = MTBF / (MTBF + MTTR)，其中MTTR为平均修复时间。可用度适合描述设备“随时能用”的能力，例如除颤器自检通过率、远程会诊终端在线率。需要注意的是，可用度不区分失效后果，一个频繁重启但每次都能恢复的软件，可用度可能不低，却可能因治疗中断而不可接受。
失效率（λ）是单位时间内发生失效的概率，常以“次/小时”或FIT（10⁻⁹次/小时）表示。软件失效率通常不服从恒定失效率假设，更接近随缺陷暴露而递减、随版本变更而阶跃的曲线。因此，λ更适合作为版本发布后早期现场数据的统计量，而不宜直接外推到长周期。
缺陷密度指每千行代码或每个功能点中发现的缺陷数，典型单位为 defects/KLOC。它反映开发与测试过程的成熟度，适合在模块级做横向比较和准入判断，但不能直接等同于现场失效率，因为缺陷密度统计的是“已发现”缺陷，且严重度分布差异很大。
任务成功概率（Ps）指在给定任务剖面下，软件在规定时间内完成规定功能的概率。它最适合有明确起止的任务型场景，例如一次CT扫描重建、一次化疗输注方案执行。任务成功概率要求先定义任务剖面：运行时长、输入范围、环境条件、操作序列，否则数值没有意义。
二、指标分解到模块与接口的方法
整机指标不能停留在系统层，必须向下分配，否则模块开发没有目标，验证也无法定位。常用方法是“自上而下分配、自下而上汇总”。以一台联网输液泵软件为例，整机要求“每1000小时非计划中断不超过1次”，即系统失效率目标 λsys ≤ 1×10⁻³/h。按功能重要度和复杂度加权，可将预算分配到主控流程、输注控制、报警管理、通信接口、日志与恢复五个部分。
分配时建议采用“串联可靠性框图”思路：若任一模块失效都导致整机中断，则 λsys ≈ Σλi。假设按复杂度权重分配为：输注控制40%、报警管理20%、通信接口20%、主控流程10%、日志与恢复10%，则各模块失效率预算分别为4×10⁻⁴/h、2×10⁻⁴/h、2×10⁻⁴/h、1×10⁻⁴/h、1×10⁻⁴/h。这些是设计预算，不是实测值，后续必须用测试和现场数据修正。
接口分解比模块分解更容易被忽视。接口失效往往不是“某个模块坏了”，而是数据契约不一致、时序竞争、单位换算错误或异常传播。对每个接口应定义：传输的数据项、更新周期、允许的延迟、错误检测方式、超时后的降级行为。例如“输注速率设定值”接口，要求从UI到控制模块的端到端延迟≤100ms，超时则保持当前速率并触发中级报警。接口指标应写成可测的约束，而不是“通信可靠”这类描述。
三、验证数据来源设计
指标能否被验证，取决于数据来源是否在设计阶段就规划好。常见的数据来源有四类，各自回答不同问题。
单元与集成测试数据用于支撑缺陷密度和接口时序指标。例如对输注控制模块执行边界值、等价类、异常注入测试，记录每千行代码缺陷数、接口延迟分布、超时处理是否正确。这类数据的特点是可控、可重复，但样本量小，不能直接换算成现场MTBF。
可靠性增长试验数据用于估计MTBF和失效率趋势。典型做法是让软件在接近真实的硬件平台上连续运行，按预定剖面施加输入，记录每次失效的时间、现象、根因和修复版本。若在示例试验中累计运行2000小时、发生4次可恢复失效，则观测MTBF约为500小时；但这只是该试验剖面下的估计值，需说明置信区间和试验条件，不能直接宣称现场MTBF为500小时。
任务剖面试验数据用于计算任务成功概率。需要先定义任务脚本，例如“开机自检→选择方案→设置速率→启动输注→模拟阻塞→报警确认→正常结束”，每个脚本重复执行若干次，统计完整通过次数。若某脚本执行200次、成功198次，则示例Ps≈0.99，并需记录2次失败的失效模式和是否可恢复。
现场与售后数据用于验证可用度和现场失效率。数据来自维修工单、远程遥测日志、客户投诉分类。关键是建立统一的失效判定准则和编码，否则“软件卡死”“报警不响”“通信断开”会被重复或漏计。建议在设备端记录带时间戳的状态迁移日志，使现场失效可与代码版本、配置参数关联。
四、从指标到可执行检查表
为了让指标体系真正落地，可在项目评审中使用一份简化的指标分解检查表。以下字段直接对应本节内容，可作为设计评审的输入。
| 检查项 | 示例填写 | 判断依据 |
|---|---|---|
| 系统级指标 | λ_sys ≤ 1×10⁻³/h，A ≥ 0.999，P_s ≥ 0.995 | 与临床风险和产品定位一致 |
| 模块分配 | 输注控制4×10⁻⁴/h，报警2×10⁻⁴/h | 权重有复杂度或安全分析支撑 |
| 接口约束 | 速率设定延迟≤100ms，心跳丢失2s降级 | 可测量、有超时和降级行为 |
| 验证数据源 | 集成测试缺陷库、2000h增长试验、200次任务脚本、现场工单 | 数据可追溯、失效判定准则统一 |
| 反馈机制 | 现场数据每季度回灌，修正模块预算 | 指标随版本和现场证据迭代 |
指标体系的成熟标志，不是数字好看，而是每个数字都能追溯到分配依据、测试记录和现场证据。MTBF、可用度、失效率、缺陷密度和任务成功概率各有适用边界，混用会导致结论失真。把系统目标分解到模块与接口，再为每类指标设计对应的数据来源，才能让可靠性工作从“事后统计”变成“设计可控、验证可查、迭代有据”。