医疗设备安全软件的10项前提

　　B. 它们可提供用以保存安全案例证据链的架构。回顾性地生成安全案例是可能的，但是昂贵，而且一定会需要重新生成曾存在于项目开发过程中那些未被保留的证据。

　　4、明确的要求

　　安全指标必须阐明可靠性的程度，以及达到这些程度的限制条件。

　　FDA已经认识到“展示设计和生产常规的间接流程数据的合理性 ”不足以表明软件的安全性， “注重于展示特定产品设备安全性的设备保证措施”也必不可少。这种展示包含于安全案例中，也反映了上述论题，即优质流程的目的不是保证优质产品，而是提供用以评估证据的环境。

　　每一个安全案例主要都会提出类似“这一系统将在条件C下，以可靠性B的水平，来操作A，如果不能做A，它会转移到概率为P的设计安全状态下”这样的声明。这一声明及其相应的注意事项都会被列在系统安全手册中，以便用于系统更高层次的安全案例中。

　　一个系统的可靠性是指其持续且 及时准确回应各种情况的能力：是可用性（及时响应要求的频率）和可靠性（这些响应的正确率）的结合。

　　安全案例声明系统的可靠性指标，提供达标的证据。可靠性指标的局限性和指标本身一样重要。例如，一个医疗成像系统可以满足IEC 61508 SIL3要求，实现不超过8小时的持续工作，8小时后系统必须重置（更新）。由于成像过程通常是短暂的，所以这一限制不会造成不便，哪怕这个系统一天要用 24小时。

　　5、系统失效

　　没有哪个系统对漏洞免疫，特别是Heisenbugs— 那些“昙花一现”，而当我们寻找它们的时候又“消失无踪”的神秘漏洞， ；失效状况终究会发生：我们要建立的系统必须能够恢复常态或进入其设计安全状态。

　　表1 缺陷、错误和故障分析表

　　既然所有的系统都将包含缺陷，而缺陷可能导致故障，一个安全系统就必须包含多道防线：

　　安全关键型流程的独立——找出哪些部件有安全关键性，设计时务必保证其不受其它零部件的影响。

　　防止缺陷演变为错误——尽管理想的解决途径是识别并消除代码故障，但是实际上很难做到。要小心Heisenbug，保证软件的设计能够发现和封闭缺陷，以免它们演变成错误。

　　防止错误演变为故障——相对于软件来说，诸如复制和多样化这样的技术更适用于硬件，然而谨慎使用依然能够奏效。

　　故障检测和恢复——在许多系统中，转移到预定义的设计安全状态，并将恢复任务留给更高层次的系统（比如人）是可行的。有些系统则不能如此操作，所以系统必须恢复或重启。一般而言，在不明确环境中企图恢复，不如选择带有快速复原的crash-only模式。

6、验证

　　测试不足以证明可靠性；需要其他方法来补充：形式化设计、统计分析和回顾性设计验证等。