使用动态软件分析为医疗设备通过审批提供支持

　　包含软件系统的医疗设备与构建复杂系统一样，制造商面临着相同的挑战：时间、质量、规模(功能的数量和复杂性)和成本。此外，产品还需通过当地监管部门的审批，如美国食品及药品管理局(FDA)、欧盟医疗器械指令司(MDD)、英国药监局(MHRA)以及其他同类监管机构。

　　在本文中我们将探讨动态代码分析如何帮助医疗设备展示安全合规性以及动态分析工具所应具备的关键功能。为了帮助设计人员选择操作系统(OS)，文章还简要介绍了OS的哪些特性可以推动安全相关软件加速设计、开发和审批流程等。

　　专业知识和流程

　　专业知识和良好的开发流程并不能确保系统符合所需满足的可靠性，甚至不能确保它是一个好系统。但是这两者的确能极大提高这种可能性。

　　创造安全关键系统所要求的简洁设计需要卓越的专业知识。要证明被测试的软件系统符合安全要求，需要对软件验证方法、被评估的软件以及评估环境(包括类似系统的验证)有全面透彻的了解。

　　毫无疑问，IEC62304标准专注于开发流程。理解这点，我们的工作将会做得更好，不仅仅是在满足最严苛质量管理标准的环境下进行软件开发，同时还使用工具来帮助确保我们的系统符合这些标准，并向审计员和监管机构提供证据加以证明。

　　展示可靠性

　　为了确保通过监管机构的审批，制造商必须证明这些设备满足安全规格。对于设备软件来说，要证明他们符合可信任(可靠性和可用性)标准的要求。具体是满足可靠性还是可用性方面的要求，则要取决于系统的使用情况。详细的要求限制和精确的可信性要求提供了既定的前提和精准的方法，帮助我们验证软件系统的可信性。

　　定义可接受风险

　　没有任何软件系统是绝对可靠的。即使系统绝对可靠，我们也无法证明它。现有可用的方法无法证明系统将永不失效，他们仅能帮助我们找到并避免错误的发生，并估计失效的可能性。因此，当软件系统的故障率足够低，没有不可接受的风险，它就是“安全”的。“不可接受风险”或“可接受风险”的精确含义因行业及行政辖区而异。衡量方法包括：

　　Ø ALARP(As Low as Reasonably Practical，最低合理可行)：将潜在的危害和相关的风险定义和分类为：a)明确不可接受，b)如果移除成本过高，则可以容忍，以及c)可接受。所有不可接受风险必须被移除，但是仅当移除成本和时间较为合理时，可容忍风险才会被移除。

　　Ø GAMAB(globalement au moins aussi bon)或GAME((globalement au moins équivalent)：新系统的风险水平至少要与现有系统的风险水平大体相当。

　　Ø MEM(Minimum Endogenous Mortality)：在新系统部署的领域，它带来的死亡率不能超过该地区常规死亡率的十分之一。举例来说，在西方国家年龄为20多岁的人群，这个值约为0.0002。

　　所有这些方法都需要按实际情况调整，主要取决于设备的严重故障可能同步影响到的人数。当使用ALARP方法时，为了确定哪些风险不可接受、哪些可容忍以及可接受，我们需要决定每个风险的严重故障所允许的最大失败可能性。而如果使用GAMAB和MEM准则，我们则需要在全球范围确定这个数值。

　　证明软件可靠性的方法

　　目前，没有任何一种单一的方法足以证明软件系统满足可靠性方面的要求。因此，我们的可靠性演示必须使用整合了各种方法和技巧，它们包括但不限于：

　　Ø 符合IEC 62304及其他同类标准要求的开发环境

　　Ø 要求跟踪矩阵，确保所有安全相关的要求都已得到满足

　　Ø 正规的设计方法和工具，可以为设计的正确性提供数学依据

　　Ø 使用贝叶斯置信网络方法的故障树分析

　　Ø 回顾性设计验证，基于已完成的工作来评估系统设计

　　Ø 静态分析，使用模型检测或者数据流分析等方法

　　Ø 使用直接故障检测技术进行测试，如动态分析，通过产生的误差和失效来识别故障

　　图1 IEC 62304标准涉及的不同分析方法和相关章节，表现为典型的“V”字形发展模型。图中显示的每一种方法都不依赖于进程。任何其他开发进程模型都可用类似的表述：瀑布式、迭代的、灵敏的等

　　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 周期重新分配到另一个需要更多处理时间的分区内。

　　高可用性

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