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

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

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

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

6、验证

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

　　测试的设计是通过引发错误和故障来间接地找出设计或实施中的缺陷。测试的首要作用是对发现和孤立Bohrbug，即一种即便在调试程序应用时仍保持不变的连续重现的漏洞。但是测试在面对Heisenbug时作用较小，因为同一缺陷在每次发生时表现为不同的错误。

　　
图2 一台医疗监测设备系统级故障树细节

　　在图2所示的医疗监测设备系统级故障树中，使用的贝叶斯网络，可以天衣无缝地地融入采用贝叶斯技术的安全案例之中。

　　要证明我们的系统满足其安全要求，我们必须采用包括测试在内的多种手段：

　　静态分析­——受到包括FDA在内的多家机构的推荐，静态分析对于定位可疑代码十分有价值。它包含针对编码标准的语法检查、故障概率估计、针对代码指令的正确验证，以及符号执行（静态/动态混合）。

　　实地使用和曾用数据——对建立可靠性指标至关重要，使用时间和该段时间内的故障情况的搜集应该贯穿整个产品生命周期：样本越多，我们对提出的指标也就越有信心。

　　故障输入——故意输入故障既可以检验用来处理错误检测的代码，还可以帮助预估剩余故障的数目。和随机测试分析一样，故障输入的结果需要细致的统计分析。

　　形式化和半形式化的设计验证——传统上是在执行前完成，设计验证也可回顾性执行。

　　7、COTS和SOUP

　　无论是COTS，甚或是SOUP，只要这个部件有足够证据来支持系统的整体安全案例，就可以采用。

　　建立一个安全软件系统的最佳途径通常不是完全自力更生，因为这样所承担的风险要比建立一个采用选定COTS（commercial off-the-shelf，商业成品）零部件的系统要大。建立操作系统、通信栈和数据库需要专门的知识，而相应的COTS也许会有上千万小时的使用历史优势。

　　虽然如此，对医疗设备开发者来说，COTS软件通常是SOUP（software of uncertain provenance，不确定出处软件），因而应该谨慎对待。IEC 61508和IEC 62304都假定SOUP会被用到。关键在于要有充足的可靠证据来量化SOUP对系统安全指标的影响。

　　这些证据将包括在实地使用数据、故障历史记录和其他历史数据。我们应该要求获得源代码和测试计划，这样可以利用静态代码分析工具来检验软件。供应商还应该提供用来构建软件的详细流程，或者是外部审核员的声明，肯定这些流程适用于IEC 62304设备。

　　8、经认证的零部件及其供应商

　　具备安全认证的零部件，比如通过IEC 61508认证的操作系统，可以加速开发和验证，有助于加快审准步伐。

　　如果使用COTS，采用获得相关批准的零部件很有帮助。诸如FDA、MHAR、加拿大卫生部以及其他国家的同等部门的组织所审批的不是这些零部件，而且面向市场的整个系统或设备；即便如此，获得类似IEC 61508或IEC 62304认证的零部件可以简化审批流程，缩短上市时间。

　　要获得认证，a）这些零部件必须在一个流程和质量管理都到位的环境中进行开发，b）它们必须经过合理的测试和验证，c） COTS软件供应商必须提供所有必要的文档，来支持最终设备获得批准。

　　9、审员

　　审核员是我们的朋友，要尽早与他们合作。

　　在安全软件开发的世界中，认证审核员是我们的朋友。他们知道我们要如何建立获得认证的流程，也能帮助我们构建安全案例。越早让审核员参与项目帮助我们，日后需要修改的地方就越少，开发周期的效率也越高。

　　在把证据加入安全案例之前，同审核员探索所提出的安全案例论点架构尤为有用。如果用类似GSN或BBN这样的形式化构架来表达论点，清晰地将论点架构从证据中分离出来，那么我们就可以问审核员：“若我们给出该论点的证据，你能满意吗？”这可以减少审核过程中的意外。

　　10、产品发布不是终点

　　我们对安全系统所肩负的责任不会因产品发布而终结；它将一直持续到最后一个设备和最后一个系统的功成身退。

以下数字虽然有点陈旧，但是有说服力：软件的更新会影响其完整性：FDA在1992-1998年间的一项研究表明，在3140个