QNX软件公司浅谈：医疗设备安全软件的10项前提

　　为医疗设备争取上市批准是一项艰辛的任务，制造商必须放眼于纯技术性质以外的挑战，集中精力培养以软件为基础的医疗设备开发所需的环境和文化。具体来说，应该考虑十项医疗设备构建和审批的重要前提，但这些前提经常被人忽略。

　　1、安全文化

　　缺乏安全文化普及的公司，不太可能生产出安全的医疗产品。安全文化不仅仅是允许工程师提出有关安全问题的文化，而且也是鼓励他们从安全的角度去考虑每一个决定的文化。一个程序员可能会有这样的问题：“我可以用A技术或B技术来编写这个信息交换，但是对如何平衡A的较好性能和B的较高可靠性没有把握”，并且知道应该和谁来讨论这个决定。而我们必须培养这种文化，来鼓励程序员思考此类问题。

　　2、专家

　　我们需要专家。定义一个安全系统必须做什么，并确认它达到了安全要求，都需要专门的培训和经验。安全系统一定要简洁，设计一个简洁的系统对于任何工程师而言都是最大的挑战。

　　归根结底，还是需要相关领域的专家（包括行业专家、系统架构师、软件设计师、流程专家、程序员和验证专家等）来确定要求，选择合适的设计模式并建立、验证系统。

　　这样的专业知识是昂贵的，因为它来自经验而非课堂：大学计算机工程本科课程很少涉及嵌入式软件开发，而教授如何创建足够可靠性嵌入式系统的课程更是凤毛麟角。

　　足够可靠性：

　　1）没有哪个系统是绝对可靠的，我们必须了解如何让系统实现足够的可靠性。

　　2）接受足够的可靠性能减少开发费用，并为我们提供可验证安全指标的方式。

　　3）如果我们不了解怎样才算足够可靠，就可能设计出一个复杂的系统，从而故障百出且容易崩溃。

　　自上世纪九十年代中期以来，软件设计模式和技术有了很大的进步，但是许多设计人员尚未接触到这些变化。图1显示的是医疗监测设备参考设计每小时故障概率的图表详情。借此找出风险所在并准确统计故障概率往往需要高深的专业知识。

　　
图1 医疗监测设备参考设计每小时故障概率的图表

　　3、流程

　　IEC 62304注重流程，没有良好的流程，我们无法证明系统达到了它的安全要求。

　　对于目前基本上难以衡量的一些内容来说，良好的流程是一个可衡量的相关因素。衡量一个流程是否被遵循比较容易；而评估设计和代码的质量是否良好就困难得多。虽然不能说一个好的流程就能保证好产品，但好产品不可能源自低劣的流程则是一个众所周知的十事实。

　　IEC 62304 列出开发医疗设备所需的流程，不是因为这些流程能够确保安全的产品，而是因为：

　　A. 它们提供了可以对开发参数进行评估的环境。例如，良好的测试流程有助于测试覆盖率的统计。没有这一流程，则不可能对测试覆盖率作出任何申明。

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

　　4、明确的要求

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

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

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

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

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

　　5、系统失效

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

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

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

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

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

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

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