1、 用于医疗设备开发的透明 SOUP 和 COTS 软件 Chris Hobbs ， QNX 软件 系统有 限公司 安全 系统部 高级软 件开发 员 摘要 在许多行 业中，制造商都通过在产品中应用商业现 货 (COTS) 软件和硬 件， 从而缩 短了 开发周 期。与 所有制造 商一样，医疗设备制造商也承受着让功能 丰富的新产品迅速面市的巨大压力，但由 于 COTS 意味着软件来源不明 (SOUP) ，而这很可 能影响设备安全以及 FDA 和其他监管机构的上市 前审批 ，这种 合理担忧让业内对采用这种软件的做 法 犹豫不 决。 虽然为医疗设备选择 COTS 软件必须事先做足调 查工作，谨慎行事，
2、但 IEC 62304 “医疗设备软件” 标准和 功能安 全需求都不排斥使用这种软件。 实际 上，只 要有严 格的选择标准，并且在系统和设备完 成 后加 以同 样严 格且 对口 的验 证，COTS 软件的采 用是完 全可以 接受的。 如果我们仔细分析一下不透 明 SOUP 1 （应避免使用）和透明 SOUP （源代码、 故 障历史记 录和长期 使用记录 可查的 SOUP ） 之间 虽然细微却很关键的区别，我们就会发现 COTS 软 件可能 是许多 关乎安 全的医 疗设备 的最佳 选择。 常见的 挑战 与所有 复杂系 统的制造商一样，医疗设备制造商也 面临相 同的挑 战： 时间、质量、规模（功能
3、的数量 和复杂 性）和 成本 。 此外，还必须加上功能安全性 和上市前审批（由美国食品及药品管理局 (FDA) 、 欧 盟医疗 器械 指令司 (MDD) 、 英国药 监局 (MHRA) 、 加拿大 卫生部 ，以及医疗设备销售地的同类监管机 构负责 ）。 这种 审批 是 医疗设 备 必不可少 的 。 通不 过 审批的 设备一 文不值 。 然而， 审批不 会从根本上改变我们在设计医疗设备 的软件 系统时 面临的挑战，也不会彻底改变我们对1不透明 SOUP 有时被戏称为“豌豆汤” （SOUP 也表 示“汤 ” ） ，但还没有人把透明 SOUP 叫做“肉汤 ” 。 解决方案的选择。 基本上有 两种选择
4、：a) 从操作系 统 甚至板 级支持 包 (BSP) 开 始，自 己逐级 设计和 创 建所有组件（有时也称“自主研发”） 2 ；b) 在有 利于设计的前提下，尽可能选用现成的软件组件， 然 后与自 有组件 一起集 成到我 们设计 的系统 中。 图 1. 开发是 在功能集 、交付日 期和质量 之间寻求 最佳平 衡的一系列过程。 任何一个环节发生变化都会影响其他 环节。 例如，缩短交付期限会减少功能集或降低质量， 或者同时影响二者。 开发和交付产品的总成本是这些过 程相互作用的结果。 自主研发也许只适用于功能有限而不需要完整操作 系统的简单设计。 遇到更复杂的系统时，如果想完 全靠自己从头设计，势
5、必费时费力，而且与使用精 挑细选的组件构建系统相比，那样风险会更大 。 当 然，关键是要确定什么样的现成软件既能集成到医 疗设备中，又不会影响功能安全性和违背审批要求， 然 后证明 完成的 系统符 合这些 要求。 2板级支持包：特定操作系统的板卡专用软件，它具有 载入操作系统所需的最低设备支持功能，包括一个引 导程序和板卡上各种设备的驱动程序。 用于医疗设备开发的透明 SOUP 和 COTS 软件 QNX 软件系统公司 2 确定性 和不确定性系统 从理论 上说， 任何软件系统都是确定性的，也就是 说，我 们能掌 握、记录和测试系统内的每种状态和 状态之 间的变 换。 而 实际上，目前的软件系统
6、已经 复杂到应该被作为不确定性系统处理的程度。 3事 实上， 我们无 法了解或预知其内部所有的状态和状 态 变化。 这一事 实所 导致 的一大后果就是：软件系统的验证， 不能再 完全依 赖测试了。 当我们无法了解和记录一 个系统 内的所 有状态和状态间转换的时候，单靠测 试来验 证系统 是不够的，原因很简单：测试只能显 示缺陷 的存在 ，而无法证明没有缺陷。 医疗 设备 软 件也不 例外。 实际上 ，在医疗设 备软件 第 1 部 分 ： 医疗设备软件的 ISO 14971 标准应用指南 中，美国医疗器械促进协会 (AAMI) 就警告过，需 要避免 的一个 误区是“将测试作为一种风险 控制 手
7、段即使 不能进 行 100% 测试” 4 。 通过一 个电梯 控制器的简单实例就能很好地说明测 试的局 限性。 图 2 显示了电梯控制 器的状态图， 电 梯控制 器可向 建筑内的电梯和电梯门发送指令 。 这 个控制 器非常 简单，但它存在一个不会立即显现的 缺陷。 例如， 我们考虑到如果电梯门打开，而电梯 却不在 ，有人 可能面临跌入电梯井的危险，所以我 们在系 统设计 里防止了这种事故的发生，然而我们 可 能没有 考虑到 有人会 被困在 电梯里 面。 利 用图 2 显 示的控 制器，我 们能从 底层搭 乘电梯 ， 然后我 们会发 现电梯竟然会在楼层间不停往返 。 电 梯门再 也不打 开了 。
8、 为了自救，我们必须在电梯到 达某楼层时，并 且在控制器 发出另一个! 向上或! 向 下 指令前，设法让系统以外的人员发出! 开 指令， 或者强 迫控制 器在执行了一定次数的上下运行指令 后，发出! 开 指令，就像电信网络丢弃无法传递的 数 据包那 样。 这个简 例表明 了系统验证所面临的一个主要难题， 即使很 简单的 系统也不例外 。 由于我们疏忽了定义3随着多核处理器成本的不断降低，其支持的功能集也 迅速增加和日益复杂，这更加剧了软件的复杂程度。 4AAMI ， 医疗设备软件 第 1 部分：医疗设备软件的 ISO 14971 标准应用指南 ，2009 年，第 55 页。 所有电梯路程必须最
9、终结束这一要求，设计出来的 系统就存在非常严重的缺陷 。 当然，系统越复杂， 此 类缺陷 的数量 就会越 多。 图 2. 有缺陷 的简 单电 梯系 统 ： 无法 确保 电梯 在被 召唤到 一楼层前，电梯门会在某楼层开启。 55 选自 Gerard J. Holzmann（著） SPIN 模 型检 验器 。 波士顿： Addison-Wesley 出版社 2004 年出版。 QNX 软件系统公司 用于医疗设备开发的透明 SOUP 和 COTS 软件 3 一句话 ，只有 从理论到实际都具有确定性的简单系 统，才能用测试来证实它没有缺陷。 6我们能掌握 和测试 所有可 能的状态和状态变化；我们也能了
10、解 和提出 所有必 要的问题。 我们可以用形式模型论证 来辅助 测试， 以证明设计的正确性，然而那个简单 的电梯 用例已 经说明，如果设计前提不正确，什么 方式都 于事无 补。 当然，我们不能放弃测试，但必 须从统 计分析 的角度看待测试结果，而且要结合其 他方法 （如严 格的过程控制、设计验证和故障历史 记 录的统 计分析 ）加以 完善。 功能安 全 医疗设 备故障 通常不会像空难或火车脱轨那样引人 关注。 但对病 人而言，医疗设备一旦发生故障，其 后果同 样不堪 设想，所以无论从道德、法律还是经 济角度 ，医疗 设备行业都必须尽最大努力确保其产 品 绝对安 全。 尽管在 验证医 疗设备的功
11、能安全性方面已投入巨大 精力， 但各种 缺陷、错误和故障还是层出不穷 。 例 如 ，据 FDA 记录 ，在 1990 年和 2000 年 间，全 美 范围内有 20 万台起搏器因软件问题被召回， 1985 年和 2005 年 间 ，因 医疗 设备故 障导致 3 万例 死亡事故和 60 万例伤害事故 (1985-2005) ，其中 有 8% 的 事故都 是由软 件造成 的。 7功能安 全是指 安全相关的系统按照设计要求运行以 确保系 统安全 的能力： 它要求执行主要任务的安全 相关系 统既能 连续运行，又能保证人员、财产和环 境不会遭遇重大风险或损害。 8总之，功能安全的 系统会 按照设 计要求
12、运行，不会无意中造成人身伤 害或财 产损失 。 以放射治疗机为例，如果它不损害 操作员 或其他 人员的健康、不破坏病人体内的健康6英国铁路安全委员会代表英国铁路业出版的工程安 全管理黄皮书第 3 卷 ，应用指南 2 ：软件与 EN 50128甚至规定， “ 如 果一个设备内 部储存的状态寥 寥无几，可以通过测试完全涵盖，那么把这个设备作 为硬件处理更为妥善 ” 。第 3 页。 7Daniel Jackson 等 （编） 可信系统的软件：证据充 分？ 华盛顿：国家学术出版社 2007 年出版。 第 23 页。 8Chris Hobbs 等（著） 在复杂软件系统中构建功能安 全性，第 1 部 分
13、。 QNX 软件系统公司，2011 年。 细胞和环境安全，那么它就是功能安全的设备 。 它 对癌细胞产生的破坏力不会影响其功能安全性，因 为 那是它 的设计 用途。 什 么是功能 安全 ？举例 说明 以能产生危险电磁辐射（如 X 光）的医疗设备为 例 。 如果技术人员在辐射开启时挪开防护屏，就很 可 能对自 己造成 “不可 接受的 伤害” 。 认 识到这种危险时，我们就能采取多种办法解决问 题 。 我们可以把仪器设计成确保当开关处于“开 启”位置时，无法移动防护屏：开关处于该位置时 防护屏处于固定状态。 这种解决方案虽然安全，但 是不能算是功能安全，因为这种安全性是系统本身 固有，而且是被动的
14、， 它不依赖任何子系统的连续 运 行。 另外，我们还能创建一种主动式的子系统，当检测 到防护屏移动时，它能及时关闭辐射，以防危险的 发生。这种子系统就是功能安全的系统： 整个系统 的 持久安 全性依 赖于这 一子系 统的连 续正常 运行。 因此，我们能采取被动安全措施（如设计系统时确 保无法移动防护屏）和主动安全措施（系统检测到 防护屏移动后能自动关闭辐射）来构建安全系统。 实际上，大部分复杂系统都同时采取两种措施 。 就 我们对 COTS 的讨论而言，总的前提就是医疗设 备的安全运行需要主动式系统，也就是功能安全 性。 目前有多种标准规定了功能安全系统在特定环境下 的构成要素，在产品或系统的
15、生命周期内必须严格 完成的过程和活动，以确保产品或系统的功能安全 。 其中最常见的有 IEC 61508 （电气/ 电子/ 可编程电 子安全）、ISO 26262 （汽车安全）和 CENELEC 5012x 系列（轨道交通安全），这些标 准在各自领域中定义了系统的功能安全性和安全完 整性等级 (SIL) 目标，同时规定了在证明符合这些 标 准时必 须遵循 的流程 和措施 。 用于医疗设备开发的透明 SOUP 和 COTS 软件 QNX 软件系统公司 4 IEC 62304 IEC 62304 已成为医疗设备软件的生命周期过程必 须遵循 的全 球 统一 标准 。FDA 推动了它的 发展 ，而 且
16、 该标准 正与欧 盟标准 93/42 EWG (MDD) 逐步取 得一致。 9与 IEC 61508 和 EN 50128 不同， IEC 62304 未 定 义 可接受故障率的常见数值；遵循 IEC 62304 并 不 需要通过什么安全完整 性等级，而 IEC 61508 则以安全完整性等级为基础（如 IEC 61508 SIL3）。 IEC 62304 局限于“ 定义医疗设备软件安全设计和 维 护的生 命周期过 程框架 ” 。 10它做 了两个 关于质 量 管理和 风险管 理的假 设：a) 医 疗设备 软件“ 是按 照质量管理体系（即 ISO 13485 或 ISO 90003 ）9Cri
17、stoph Gerber （编） 医疗设备的软件生命周期简 介 ， Stryker Navigation ：幻灯片演示（2008 年 9 月 4 日） 10国际 电工 技术 委员 会，IEC 62304 ： 医疗 设备软 件 软件的生命周期过程 。初版，2005-2006 年。日内瓦： 国际电工技术委员会，2006 年出版。引言。 开发和维护的” ，b) 风险管理符 合 ISO 14971 的要求 和 IEC 62304 第 7 条 关于软 件的补 充要求。 值得注意的是，IEC 62304 并未 特别规定应如何满足其要求，也 就是说，它不制定某一种软件开 发模型，或特定文件以支持符合 标准的
18、声明。IEC 62304 中引用 到 ISO 14971 ，后者规定了医疗设备 风险管理体系的要求 。 这两种标 准既未规定风险等级，也未规定 或提出一种能根据传统统计分析 法确定软件故障机率的方法。 11我们能任意选择最符合要求的开 发模型，因为我们能自由选择最 终用来验证所构建系统的功能安 全 系数的 方法。 IEC 62304 确实制定了软件生命 周期的流程（包括风险管理过程）、活动和任务， 并指出该周期不应随着产品的发布而结束，只要软 件还在运行，这个流程就必须贯穿于产品维护和问 题解决的全过程。 它还根据故障可能对病人、操作 员或其他人员造成的伤害程度规定了安全等级 。 这 些等级与
19、 FDA 的医疗设备 等级类似：A（不会损 害 健康）、B （可能轻微损害健康）和 C （可能严重 损 害健康 甚至导 致死亡 ）。 最后，还 有一点 和本文 的论 题特别相 关，IEC 62304 明 确提及 SOUP ， 它将其 定义 为一种软 件体，特 征 是已经开发而且广泛面市的软件，而开发目的并不 是用于集成到医疗设备中（也 称 “现成软件”）， 或以前开发的不具备详细可查的开发过程记录的软 件。 1211Gerber ，幻灯片 19 。 12IEC 62304 3.29 SOUP 图 3. 与医疗设备的功能安全有关的一些标准。 QNX 软件系统公司 用于医疗设备开发的透明 SOUP
20、 和 COTS 软件 5 上 文中需 要特别 注意的 是，IEC 62304 a) 假设会 使 用现成软件（商业或其他）和 b) 提出 SOUP 的两 种定义 ，即 开发目的不是用于集成医疗设备的软件， 或开发 过程记 录不详或无法查询的软件（或同时符 合 两种条 件的软 件）。 IEC 62304 不禁止在医疗设备中使用 SOUP，事实 上， 该标准内有 一些条款已假设 会实际用到 SOUP 。 例如，5.1.1 “ 软件开发计划”就规定，“ 计 划必 须重视 软件配置和变更管理，包括 SOUP 配置 项 ” 13 ，SOUP 是部分小节中的一个明确主题，例 如 5.3.4“ 规定 SOUP
21、 项所需 的系统 硬件和 软件” 。 所以说 ，问题 的关键不在于医疗设备软件是否允许 使用 COTS 软件 和/ 或 SOUP，而是 a) 如 何确定 一 种 特定的 COTS 软 件或 SOUP 适用于相 关 医疗 设 备，b) 如 何验证 这种 COTS 或 SOUP 满足该 医疗 设备的 功能安 全要求。 要回答这个问题，我们应该 深入分析 SOUP 的定义，并正确理解 SOUP 和 COTS 软件 之间的 关系。 SOUP 和透明 SOUP 一 些软件 供应商 将 COTS 和 SOUP 之间的 区 别描 述得过于简单甚至错误百出。 他们认为 COTS 软 件背后 有供应 商的支持，
22、其商誉和金融前景有赖于 软件产品的正常运行，而 SOUP 背后则没有这样 的 保障。 这就像 人们 买药时，往往更愿意去信誉良好的药店， 而不会 选择使 用垃圾电子邮件进行推销的网站 。 其 实这样 的区别 方式并没有多大意义，因为对我们来 说，大部 分 COTS 软件很可能也是 SOUP ；供应 商遵照 执行的 过程（或者没有执行！）、源代码、 故障历 史记录 和假如我们自主研发产品时所需的一 切 ，对供 应商以 外的人 而言都 是空中 楼阁。 更有效的做法是区分（不透明）SOUP 和 透明 SOUP 。 这种区分不依据任何商业标准（商业或非 商业） ，而是 建立在支持软件安全案例的证据之上
23、 的 。 我们需要这些证据来支持采用 SOUP 构建的 系 统符合 风险和 安全等 级的声 明。 13IEC 62304 5.1.1 软件开发计划 质 量与审 批 由监管机构负责的上市前审批和产品质量是密不可 分的，但它们不能互换。 首先，我们很容易想象一 种器械或工具（如注射器），虽然具备正常的使用 功能（刺入血管抽血），但它可能永远无法通过审 批，因为它的生产过程中没有消毒过程，或者这种 注射器符合所有审批要求 ： 尖锐、无菌、使用简单 安全，但它可能在首次消毒过程中碎裂，尽管它不 会 对病人 或医生 产生危 险，但 它不符 合质量 标准。 COTS 系统（ 如 Microsoft Win
24、dows 操 作系统 ）可 能有证据充分的开发过程，其供应商可能会执行这 种定义明确、记录完善的开发过程，也拥有随时可 查的源代码和可追溯与可证明的软件故障历史记录 。 但由于公众无法获取这些信息，因此对我们来说， Windows 操 作系 统是一 种（ 不透明 ）SOUP。 14操 作系统 架构 运行 COTS 软件的操作系统必须支持供应商的功 能安全声明。 因此，我们必须对操作系统，特别是 它的架构进行评估，因为操作系统架构对系统的可 信 性至关 重要。 需要评 估的重 要特征 包括： 抢占式内核运行 为了保证系统满足实时提交的要 求，实时操作系统必须允许内核进行抢占式 运 行，而 且无法
25、 抢占的 视窗应 很短暂 。 内存保护 操作系统架构应将应用程序与关键进程 分开放入各自的内存空间，这样单一的故障 就 不会殃 及整个 系统。 优先级继承 为防止优先级反转，实时操作系统应将 被阻止的高优先级任务的优先级分配给阻止任 务的低优先级线程，直至完成阻止的任务。 分区 为确保可用性，实时操作系统应支持固定分14这样，从知名药店或通过垃圾邮件促销网站买药的类 比就站不住脚了。药店销售的药品与不透明软件不同： 它 的每种 成分（ 包括“ 非活性” 成分） 、用 于制造 或提 取这些成分的每个过程，以及成品药物都必须有据可 查以便监管机构审查。这就是制药和生化技术公司如 此依赖专利的原因；
26、他们可能守不住商业秘密，所以 专利是他们唯一的保障。 用于医疗设备开发的透明 SOUP 和 COTS 软件 QNX 软件系统公司 6 区 ，最 好是自适应分区，因为它能在执行系 统 资源 预算时，使用动态调度算法将分区内 闲置的 CPU 周期重新分配到需要额外处理 周 期的分 区。 高可用性 自启动的软件监视程序能监视、停止和重 启进程（如能确保安全），而无需系统重置。 相 反，开 源项目 （如 Apache 和 Linux ） 都 提供可 随时查 询的 源代 码和故障历史记录，以供详细审查 。 在人们 多年的 积极努力下，这种软件的特点广为人 知 。 与 自产软 件类似，这种软件虽然名义上“
27、来 路 不明” ，但可 以用代码符号执行和路径覆盖来分析 来仔细 检审， 而且此类软件悠久（并可免费查找） 的使用 历史也 能让通过数据分析得出的结论变得尤 其 可信。 因此， 我们可 将在开源项目中开发的软件视为透明 SOUP ； 也 就是能审查和验证的 SOUP ，就像是我 们 自己编 写的软 件一样 。 尽管开 源软件 有这些引人注目的特点，但它可能不 是医疗 设备的 最佳解决方案 。 在功能安全的系统内 使用开 源软件 的困难在于，开源软件的开发过程既 未 明确定 义也无 证据证 明，而 这正是 IEC 62304 明 确要求 的内容 。我们无法了解软件的设计方法、编 码方式 或验证
28、过程，没有这些依据就验证功能安全 声明 等于竹篮 打水。 此外，SOUP 或 COTS 软件 可能包 含一些 不需要的功能，这会在系统中留下失 效代码。IEC 61508 等功能安全标准对此做法都明 令 禁止。 当然，如果 COTS 软件供应商提供其产品的源代 码和故障历史记录，那么其 SOUP 便实现了透明 化 。 有些供应商力求完美，他们不仅提供透明 的 SOUP ，而且还提供一个 SOUP 的透明成分 。 也就是 说， 他们 向客户公布其开发软件的详细过程， 以及完 整的开 发历史记录。这实质上是一种非正式 的审查 跟踪， 我们可借此来验证其宣称的软件可靠 性和可 用性。 还有些供应商更
29、进一步，他们允许外 界审查 自己提 交的证明，以取得产品的安全等级认 证 （如 IEC 61508 SIL3）。 除了对医疗设备的首次审批至关重要外，透明 SOUP 的 COTS 软件成分（证据充分的开发与验 证工件、详尽的历史记录和可证明的开发过程）还 能为后续验证和产品升级后的审批提供宝贵证 明。 15这 点非常 重要， 例如 FDA 在 1992 和 1998 年间的研究 中发现，3140 起 医疗 设备召回事件 中有 242 起 (7.7%) 是由缺 陷软件 造成 的。 这其中有 192 起（近 80%）是由于软 件维 护过 程中引入的缺 陷造成的。 换句话说，缺陷是在产品面市后引入设
30、备的： 设备 开始能正常运行，但后来有人破坏了它或发现了其 内部隐藏的缺陷。 所以，在开发、维护和升级强调 功 能安全 （IEC 62304 B 级和 C 级设 备）的 医疗设 备 的软件系 统时，我 们最好使 用透明 SOUP （ 软件 成分透明，而且有长期和可证明的成功应用记录） 来 完成。 购买 COTS 软件 在为医疗设备选择 COTS 软件时，必须弄清一个 最关键的问题，那就是“软件 供应商要提供什么证 据证明其产品符合我们的要求？”除了要咨询与功 能、特征、成本和技术支持有关的常规问题外，还 要知道“ 这种 COTS 软件能帮我们顺利通过医疗 设 备的审 批吗？” 因为它不是我们自
31、己开发的，所以在假设所有 COTS 软件都是某种 SOUP 时，必须查明它是哪 种 SOUP。 如果经证 实它 是“以 前开 发的 无法 提供 开发过程 详尽记录的软件”，我们就很难证明它适 用于我们的系统。 首先，对含有这种软件的系统进 行功能安全性验证需要投入大量的精力和财力 。 其 次 ，这种 软件不 符合 IEC 62304 对证据充 分 、严 格 执 行的软 件生命 周期过 程的要 求。 15参阅 Anil Kumar （著 ） 面向开发人员的医疗设备 IEC 62304 认证攻 略 选自 电子医 疗器 械解 决方案 杂 志 ，2011 年 6 月 20 日。 QNX 软件系统公司
32、用于医疗设备开发的透明 SOUP 和 COTS 软件 7 但是，假如这种 COTS 软件是一种透明 SOUP ， 那我们 的任务 就简单多了 。也就是说，这种软件的 “开发 目的不 是集成到医疗设 备 中”，但它有随时 可查的 开发过 程的详尽记录，所以它可能适用于我 们 的医疗 设备。 COTS 检 查表 我们可使用下列高级检查表，确定一个特定的 COTS 组 件 是否适合 集成到医疗 设备的软件系 统中 首要前提是，这种 COTS 软件是透明的 SOUP 。 我们是否选择这种 COTS 软件主要取决于它能否 完全支 持我们 为整个系统规定的功能安全性和遵规 性 要求。 功 能安 全声明 我
33、们可以先验证 COTS 软件供应商对其软件所作 的 功能安 全声明 。 供 应商提 出任何 功能安 全声明 了吗？ 这 些声明 符合我 们项目 的功能 安全要 求吗？ 声明规定运行环境和限制 了吗？例如，这些 声 明 是关于 不间断 运行还 是按需 求运行 的？ COTS 软件的 功能安 全声明规 定出现 危险故 障 的机率了吗？或者换句话 ，软件供应商对软 件 可 信性作 了何种 声明？ 软件供应商定义“足够可 信性”了吗？他是 如 何量化可信性声明的？ 例 如，量化是属于“ 五 个九 (99.999%) ” 一类的吗（实质上无意 义）？ 或者它提供相关环 境下的可用性和可 靠 性 的重要
34、信息了 吗？ 软件供应商对 COTS 软件下列特征声明进行 了 量化了 吗： 可 用性： 系统能 及时响 应事件 的频率 ？ 可 靠性： 响应的 正确率 ？ 过 程 涵盖整个软件生命周期的定义明确、证据充分的过 程是一项必不可少的要求；没有它，就没必要进行 下 一步了 。 COTS 软件供应商已经执行质量管理体系 (QMS) 了吗？ 该 体系符 合下列 其中一 项要求 吗： ISO 9000 系列 QMS 标准？ ISO 15504 （“ 软件过程改进和能力测定 SPICE” ）？ 能 力成熟 度模型 集成 (CMMI) ？ 软件供应商采用了何种源 代码控制过程（包 括 修 订控制 和版本 控
35、制） ？ 软件供应商如何记录、跟 踪和解决缺陷，包 括 通 过验证 、确认 和实际 应用发 现的缺 陷？ 软件供应商为缺陷分类并 随后进行故障分析 了 吗？ 故障 树 分析 使用贝叶斯置信网络等方法的故障树分析是一种发 现、解决设计错误和评估系统可信性的重要工具。 它还提供了软件工件，负责医疗设备面市审批的机 构 会对其 进行审 查。 16已利用故障树分析对 COTS 软件进行评估了 吗？ 分析同时使用先验（由因 推果）和后验（由 果 推 因）证 据了吗 ？ 我 们能获 取故障 树分析 的结果 吗？ 16参阅 Chris Hobbs （著） ， 使用贝叶斯置信网络对安 全关键软件进行故障分析
36、，2010 年。 用于医疗设备开发的透明 SOUP 和 COTS 软件 QNX 软件系统公司 8 静 态分析 静态分 析是 确定 可疑 代码 位 置的重 要工 具，FDA 等 监管 机构 17都 建议使 用这种分 析，它 提出“ 研究各 种静态 分析技 术，如符号执行、抽象解释、逆向工 程，并 将这些 技术用于医疗设备的软件分析 ” 。 该任务的目标是，提高 FDA 的器械与辐射健康中 心 (CDRH) “在上市前和上市后审批过程中评估软 件的能 力”， 并“通过提高静态分析工具（专门用 于医疗 设备软 件）的精度和效率，使静态分析技术 更 先进” 。 18图 3. 一种非常简单的故障树。 数
37、字代表故障（1 、2 等），字母代表树叶（A 、B 等）。 17例 如， “静态 分析提 供了一 种能在 代码执 行前检 测到错 误的高效工具” ，参阅 FDA 颁布的软件验证的一 般原则：行业与 FDA 工作人员的最终指南。 2002 年 1 月 11 日。 18FDA 研究项目 ： 医疗设备软件的静态分析 ，2011 年 2 月 11 日更新。 COTS 软件供应商使用静态 分析识别产品中潜 在 的问题 了吗？ 软 件供应 商使用 了何种 静态分 析技术 ？ 根 据公布 的编码 标准进 行语法 检查了 吗？ 评 估故障 机率了 吗？ 提供正确性证明（如代码中的断言）了吗？ 符 号执行 （静
38、态 分析- 混合） ？ 为支持其静态分析的结 果，COTS 软件供应商 提 供了什 么工件 ？ “ 边用 边证明 ”数 据 在验证 COTS 软件可信性声明和构建声明时， “边用边证明”数据非 常重要 。 当人们构建一种需 要某天（即使遥遥无期）提交其可信性证明的系统 时，他应该将“使用中收集的数据”收入其业务模 型 中。 COTS 软件供应商能提供“边用边证明”数据 吗？ 数 据能回 溯到多 久以前 ？ 数 据有多 全面？ 数 据可用 的样本 大小？ 该样本代表供应商的少部分还是大部分运 行 时？ 供 应商如 何收集 此数据 ？ 软件供应商提供了具有“边用 边 证明 ”数 据的 故 障分析
39、结果， 还是只 提供了 使用数 据？ QNX 软件系统公司 用于医疗设备开发的透明 SOUP 和 COTS 软件 9 设 计软 件工件 设计和验证软件工件是 SOUP 和透明 SOUP 之间的 一个 关键 区别 。 如果 COTS 软件供应 商无 法 提供广 泛的工件集合，那选择他的产品还不如选择开源软件。 COTS 软件供应商为其软件 提供了什么设计 工 件？ 供 应商提 供了： 架 构设计 文件？ 详 细设计 文件？ COTS 软件的测试计划和方 法是什么？供应商 公 布详细 结果了 吗？ COTS 软件供应商使用了什么其他验证方法 （参见前文）？这些方法 和详细结果可以获 取 吗？ 供应
40、商保留和提供可追溯 性矩阵（从要求到 交 付 ）了吗 ？这些 都能验 证吗？ 供应商保留了什么样的软 件生命周期记录？ 其 中 包括： 变 更？ 问 题和解 决方案 ？ 安全 手册 安全手册是另一项必不可少的要求 。 如果 COTS 软 件 不包含安全 手册， 就应将产品退 回 再 找其他 供应商 。 安全手册重申 COTS 软件的功能安全声 明 了吗？ 安全手册规定 COTS 软件功能安全声明 的环境和局限了吗？ 这些 应包括功能安全声 明 的 有效环 境和用 途。例 如： “ 处理器 架构的 列表细 致详尽 。” “禁止在信号处理程序内进行浮点运算。” “ 关键预 算限于 窗口大 小。”
41、软件供应商提供有关安全使用产品的培训了吗？ 认证组 件 即使完全遵照上述建议执行，并且 COTS 软件符 合透明 SOUP 的所有要求，也无法保证最终产品 会按照计划如期通过审批 。 要确保万无一失，不妨 与具有审批申请经验的 COTS 软件供应商合作， 并 利用已 通过相 关认证 的组件 。 虽然 FDA 、MHRA、加拿大 卫生部和其他地 区的 监 管机构审批的不是单独组件，而是即将面市的完整 系 统或设 备，但 使用已 通过认 证（如 IEC 61508 或 IEC 62304 ）的组件确实能简化审批流程，加快产 品 面市。 首先，要通过认证，这些组件必须是在执行正确流 程和质量管理的环
42、境下开发的，它们必须经过适当 的测试和验证，而且 COTS 软件供应商应拥有所 有必需的工件，它们反过来能支持最终设备的审批 。 最后，具有认证经验的软件供应商能为客户提供宝 贵 建议和 专业支 持。 结论 IEC 62304 “医疗设备软件”标准和功能安全需求 都不排斥在医疗设备中使用 COTS 软件。 我们必 须非常专注和特别谨慎，但 COTS 软件完全可以 接受，因为它有非常严格的选择标准，而且完工的 系统和设备必须经过同样严格的验证。 事实 上， 如 果注意到不透明 SOUP 19 （应该避免）和 透 明 SOUP （ 源 代码、 故障历史 记录 和长期 使用记 录 可查的来源不明软件
43、）之间虽然细微却很关键的区 别，我们就会发现 COTS 软件可能是许多关乎安 全 的医疗 设备的 最佳选 择。 19不透明 SOUP 有时被戏 称为 “豌豆 汤” （SOUP 也表 示“汤 ” ） ，但还没有人把透明 SOUP 叫做“肉汤 ” 。 用于医疗设备开发的透明 SOUP 和 COTS 软件 QNX 软件系统公司 10 参考文 献 AAMI 医 疗设备 软件第 1 部分 ： 医疗设 备软件 的 ISO 14971 标准应 用指 南 。医 疗器械 促进 协会 2009 年出 版。 Berard, B. 等 。 系统与软件验证 。 柏林： Springer 出版社 2001 年出版。 Bi
44、rman, Kenneth P. 与 Thomas A. Joseph（合著 ） 在分布 式系统 中利用 虚拟同 步 。 康奈 尔大 学 。1987 年 2 月。 Birman, Kenneth P. （ 著 ） 构建安 全和可 靠的网 络 应用程 序。 格林威 治：Manning 出版社 1996 年出版 。 FDA. 软 件验 证的一 般原则 ：行业 与 FDA 工作 人 员 的最终 指南 。2002 年 1 月 11 日 。FDA 研究项 目：医 疗设备软 件的静 态分析 ， 2011 年 2 月 11 日更新 。 Gerber ，Cristoph（ 著 ）医 疗设备 软件的 生命周 期
45、 简介 。德国 弗赖堡 ：Stryker Navigation。 幻 灯片演 示（2008 年 9 月 4 日）。 Green，Blake （ 著） 从监 管角度 理解软 件开 发 。 医疗设 备管理 期刊 ，6:1（2009 年 2 月 ），自 费出版 。14-23。 Helminen，Atte（著） 利用 贝叶斯 网络对 基于安 全 关键软 件的系 统进行 可靠性 评估 。赫尔 辛 基 ： 芬兰辐射与核安全局（Steilyturvakeskus ） 2001 年出版 。 http:/www.stuk.fi/julkaisut/tr/stuk-yto-tr178.pdf Hobbs, Chr
46、is （著 ） 。 使用 贝叶斯 置信网 络对安 全 关键软 件进行 故障分 析 。QNX 软件系 统公 司 2010 年出版 。 。 Hobbs, Chris, 等 （ 合著 ） 在复杂 软件系 统中构 建 功能安 全，第 1 部 分。QNX 软 件系统 公司， 2011 年出版 。 。 _. 在 复 杂 软件系 统中构 建功 能安全 ，第 2 部 分 。QNX 软件 系统公 司，2011 年出版 。 。 Holzmann, Gerard J. （ 著） SPIN 模型检 验 器 。 波士顿：Addison-Wesley 出版社 2004 年 出版。 国 际电工 技术委 员会。IEC 62
47、304 ： 医疗设 备软 件软件 的生命 周期过 程 。 初版，2005-2006 年 。日内 瓦：国 际电工 技术委 员会 2006 年出版 。 Jackson, Daniel 等（著） 可信系 统的软 件：证 据 充分？ 华盛 顿：国 家学术 出版社 2007 年出 版。 Jackson, Daniel 等（著） 证 据 充分 ： 全美可 信 系统软 件的学 术研究 扼要 。Kumar, Anil （ 著 ）面 向开发 人员的 医疗设 备 IEC 62304 认证攻 略 。选 自电 子医疗 器械解 决 方 案杂 志。2011 年 6 月 20 日出版 Lions, J. L. 等（合著 ）
48、 Ariane 501 调查委 员会 报 告 。巴黎 ：ESA 1996 年出版 。 NASA. 机 构风 险管理 的程序 要求 (NP4 8000.4A) 。NASA 2008 年 12 月 16 日出版。 QNX Neutrino 实时操作 系统 安 全内 核 1.0 ： 安全 手册 ：QMS0054 1.0 QNX 软件 系统公 司 2010 年出版 。 。 Reason, James （ 著） 人为 错误 。剑桥 ：剑桥 大 学出版 社 1990 年出 版。 QNX 软件系统公司 用于医疗设备开发的透明 SOUP 和 COTS 软件 关于 QNX 软件系统公司 QNX 软件系统公司是全
49、球 领先 的 创新嵌入式 技术（包 括中 间件、开发工具 和操作系 统） 供应商。QNX Neutrino 实时操作 系统基 于组件的架构、QNX Momentics 工 具套件和 QNX Aviage 中 间件产品系 列能为构建高性能 嵌入式系统提供 业内最可 靠和可扩展的 框架。包括思科、戴姆勒、通 用电气、洛克希德 马丁和西门 子在内的全球技术领导者都依 靠 QNX 的技 术生产 车用远 程信 息处 理装 置和 信息 娱乐系 统、 工业 机器 人、 网络 路由器 、医 疗器 械、 安全 与国 防系统 ，并 满足 其他 任务 或 生 命 关 键型应用的需要。 公司总部位于加拿大渥太华，其产品销售覆盖全球 100 多个国家。 2011 QNX 软件系统有限责任公司（Research In Motion Lt
