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

活性可以帮助系统符合最严格的质量和认证机构的覆盖要求。

　　结构覆盖标准

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

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

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

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

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

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

　　软件分析工具的选择

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

　　错误报告

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

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

　　项目兼容性

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

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

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

　　功能和局限性

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

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

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

　　总结

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

　　操作系统

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

　　实时担保

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

　　架构

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

　　内存保护

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

　　优先级继承

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

　　分区

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

　　高可用性

一个自启动的监视程序需要监控、停止以及在保证安全性的前提下来重启进程，而不需要系统的复位