电子发烧友App
为医疗设备争取上市批准是一项艰辛的任务，制造商必须放眼于纯技术性质以外的挑战，集中精力培养以软件为基础的医疗设备开发所需的环境和文化。具体来说，应该考虑十项医疗设备构建和审批的重要前提，但这些前提经常被人忽略。
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模式。
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个召回器件中，有242个（7.7%）是由于软件故障。其中192个（几乎占80%）的故障是由软件维护中引入的缺陷引起。
换句话说，这些缺陷是在设备进入市场之后引入的。因此，我们用以确保软件达到其安全要求的流程必须包括软件的整个生命周期，包括修复和更新。
工商网监
评论