IEC 62304

　　IEC 62304 已成为医疗设备软件的生命周期过程必须遵循的全球统一标准。FDA推动了它的发展，而且该标准正与欧盟标准93/42 EWG(MDD)逐步取得一致。

　　与图1显示的其它标准一样，IEC 62304是基于IEC 61508标准，根据现有的行业特定实践补充而来。举例来说，IEC 62304与ISO 26262不同，甚至与IEC 61508本身也不同， 它未定义可接受故障率(安全完整性等级SIL的一个评定)的常见数值。相反，它根据故障可能对病人、操作员或其他人员造成的伤害程度规定了安全等级。这些等级与FDA的医疗设备等级类似，即：不会损害健康、可能轻微损害健康和可能严重损害健康甚至导致死亡。

　　在大多数情况下，从IEC 61508演化而来的标准与其类似，因为他们都确实规定了软件生命周期的流程(包括风险管理过程)、活动和任务，并指出该周期不应随着产品的发布而结束，只要软件还在运行，这个流程就必须贯穿于产品维护和问题解决的全过程。因此，不管他们如何定义可接受和不可接受风险，IEC 62304、IEC 61508和其它类似的标准提供了证实系统符合安全要求必须使用的指导和方法。

　　图2 IEC 62304标准从IEC 61508标准演化而来，因此与其它行业标准一样，有同样的起源。要注意的是，IEC 62304清楚说明了它并不依赖于IEC 61508，但是可参考IEC 61508的工具和方法

　　动态分析

　　动态分析用于检验编译源代码的执行情况，可以整体检验，也可以分开进行。由于动态分析执行代码，它不仅测试源代码，也测试编译器、链接器、开发环境，甚至有可能是目标硬件。通常来说，动态分析包括结构(代码)覆盖分析和单元测试，这两者的结合不仅可以提供非常有效的检测软件故障的方法，还可以为证明执行了哪些软件以及如何执行提供证据。

　　结构覆盖分析是航空行业标准DO-178B/C的基础。航空事故往往较为重大和悲惨，因此新闻报道往往比医疗设备事故报道频繁，而航空业也有一个安全记录模范。从前一里到下一里，航空是最安全的交通工具之一。

　　结构覆盖分析

　　动态分析工具使用介入式探针或非介入式探针。介入式探针系统将软件探针(计数或程序呼叫)放置在即将被分析的代码里(高级语言或者汇编器)。这些探针会记录流程执行的相关信息，并生成执行历史。

　　介入式探针和非介入式探针

　　使用介入式探针时，证明探针不会改变测量代码的功能对于分析的有效性非常重要。除了证明介入式探针不会影响源代码，这样的演示通常还要求探针本身不会带入可能导致编译器出现漏洞的事物。这可以通过使用Compiler Validation Suite(一套源代码，用于证明编译器履行正确的计算功能)来展示编译器的有效性并未受到加载进程的影响。

　　非介入式探针系统拥有与介入式探针系统一样或类似的信息，但直接来自于处理器，并且动态分析工具会将这个低层信息连接至原始表示方法(高层语言或者汇编器)。但是，出于各种原因(比如编译器优化的影响)，不能总是明确地建立这种联系。

　　请注意，与所有测试一样，在一个复杂的软件系统，我们同样无法证明结构覆盖分析所用的探针绝对不会影响代码表现。举例来说，从定义上看，Heisenbugs为不可再现的错误，通常被认为由微妙的时间条件导致，他们可能会因代码的任何改变而校正(甚至是带入)，包括加载检测探针。

　　图3 LDRA代码覆盖工具的截图，彩色的图形信息清晰说明了未被执行的代码

　　可靠性判断的证明

　　关键不是为了证明故障不存在(不可能性)，而是为了收集证据，供我们用于软件可靠性判断。特别是如果我们的系统使用SOUP(第三方的软件)，结构覆盖分析可以帮助证明系统没有未使用的或者多余的代码。

　　单元测试

　　单元测试验证小单元，使得观察到不正确的表现更为简易，以便检测故障。在单元测试里，程序或程序串都独立于完整的系统进行隔离测试，以确定他们满足特定的要求。

　　通常情况下，这些要求比项目的要求更加全面，因此，举例来说，可以对界面条件进行测试：对一个像素为750 x 1000的显示的着色测试可能需要针对像素为1200 x 1600的显示进行。每一个程序的界面都进行输入值测试，这可能被更高级程序排除在外，来探索普遍性——该程序的表现一直符合要求。

　　单元测试使得测试通常无法触及的内务代码成为可能，保护性代码元件可以同样被测试。一些偶然纠错的情况可以被移除;举例说，在较大型的系统中，可能引入了一个不必要的程序，或者与之相反，并让观察者以为一切正常。因为我们处理的是较小的元件，就较为容易观察到不正确的行为，并检测错误。

　　如何处理被测试的单元内的子程序取决于测试的目标。传统上，单元测试会引入一个从细节到总体的测试战略(有时候被称为模块或者集成测试)。在这样的方法里，首先对单元进行测试，接着再将其与其他单元整合测试。在这样的测试中子程序并不包括在测试里，它们可以被“存根”取代。

　　图4 在整个系统或某个子系统进行结构覆盖测试提供极大的灵活性

　　当与结构覆盖分析相结合，在测试里可以随意添加呼叫树的数量的灵活性可以帮助系统符合最严格的质量和认证机构的覆盖要求。

结构覆盖标准

　　在验证任何系统时，其中一个最艰难的步骤是决定何时停止测试。该决定需要考虑系统可靠性要求，并最终取决于IEC 62304以及监管机构对于医疗设备的安全规章。

　　覆盖标准可以帮助衡量动态测试已经实现的成果，也可以用于测量剩余需要完成的测试工作。这些标准包括：

　　Ø 语句覆盖：最基础的标准，由被测试系统的语句部分组成。

　　Ø 分支/判定覆盖：覆盖的控制流分支部分。平均而言，每一个语句和程序呼叫被执行的次数是单独语句覆盖的两倍。

　　Ø LCSAJ覆盖：路径相关的标准，LCSAJ(线性代码顺序和跳转)覆盖比分支/判定覆盖要求更高，并且在应用的大多数关键领域都可使用。市场上较复杂的工具会包含此功能。

　　Ø 修正条件/判定覆盖：在一个程序中每一种输入输出至少要出现一次，在程序中的每一个条件必须产生所有可能的输出结果至少一次，并且每一个判定中的每一个条件必须能够独立影响一个判定的输出，则完全的MC/DC覆盖已经达到。

　　软件分析工具的选择

　　所有软件工具提供商都非常希望售出自己的产品，因此极少有厂商会主动介绍他们的工具无法实现的功能。下面是评估软件分析工具时的一些注意要点：

　　错误报告

　　Ø 该工具是否会产生很多假阳性报告?也就是说，它是否会报告其实并不存在的故障?

　　Ø 该工具是否会产生假阴性报告?也就是说，它没有及时报告其实存在的故障?

　　项目兼容性

　　Ø 该工具在生成有益的信息时是否需要很长时间?工具运行所需要的时间通常并不是问题，但仍是一个考虑因素，因为如果耗时过长，则会成为项目实施的障碍。

　　Ø 该工具是否支持项目的语言?很多编译器执行自己的语言版本，并在该版本下分析代码。因此，确保分析工具支持项目所用的语言就非常重要。

　　Ø 该工具是否可以立即整合至开发进程?如果需要不相称的努力来将工具集成到项目，则其作用不大。

　　功能和局限性

　　Ø 该工具是否可在整个系统工作?这是一个非常重要的问题，因为仅当对整个系统进行分析时，有些故障才能被检测到。

　　Ø 该工具是否可以适应跨程序循环?即使是在单一队列，如果仅当另一程序被分析时，某个程序才能被完全分析，跨程序循环也极为重要。

　　Ø 该工具的局限性有哪些?所有的工具都有局限性，包括所能分析的代码数量，所能处理的模块深度，所允许的嵌套深度以及表格规格。这些局限性及其对项目的影响也需要被注意且考虑在内。

　　总结

　　鉴于复杂的软件系统是很多医疗设备的核心，这些设备的成功与否与制造商展示软件系统是否符合可靠性要求的能力有越来越密切的联系。如FDA、 MDD和MHRA等的监管机构负责审批整个设备，而不是其中的一部分，证明设备软件(软件安全例证)可靠对于整个设备的审批就非常重要。因此，密切关注设计和开发实践，仔细选择验证方法以及实施工具，对于任何使用软件系统的医疗设备项目的成功都极为重要。

　　操作系统

　　不管验证工具多么优秀，归根结底它也是设备，它的软件也需要通过审批。对任何使用软件的系统而言，芯片以上的任何元件都需要依赖于操作系统(OS)。这意味着包含软件的医疗设备的可靠性取决于其OS，而该OS必须有能力支持对于设备安全性提出的要求。在为安全系统选择OS时需要注意以下几个关键要求。

　　实时担保

　　只有实时操作系统(RTOS)可以确保可靠性所要求的及时反馈，而可靠性对任何安全软件系统来说都是最基本的。

　　架构

　　实时执行或者宏内核操作系统的失效通常要求设备进行重启，这就使得系统可用性大打折扣。在微内核实时操作系统中，应用程序、设备驱动程序、文件系统和网络协议栈都运行在内核外部的独立地址空间，因此它们不仅与内核隔离，而且彼此之间也互不影响。一个组件出现故障不会导致整个系统瘫痪。

　　内存保护

　　OS架构需要将其内存里的应用和关键进程分开，防止单个故障蔓延至整个系统。

　　优先级继承

　　为防止优先级反转，RTOS需要支持将被阻止的高优先级任务的优先级分配给阻止任务的低优先级线程，直至完成被阻止的任务。

　　分区

　　为了确保可用性，RTOS需要支持固定分区或者更受青睐的自适应分区。后者强制执行资源预算，但采用一种动态调度算法将一个分区内闲置的 CPU 周期重新分配到另一个需要更多处理时间的分区内。

　　高可用性

　　一个自启动的监视程序需要监控、停止以及在保证安全性的前提下来重启进程，而不需要系统的复位。如果重启并不安全，则监视程序需要将系统设置在设计安全状态。