以硬件为中心的设计方案构建高可靠性医疗电子设备概要

1、以硬件为中心的设计方案构建高可靠性医疗电子设备作者：Chuck Russo 来源：电子工程专辑§ ©过几次通话中断的经历。虽然这些产品以及其他消费类产品的系统 故障或者小毛病会带来不方便，但它们不会造成灾难性的后果。然 而，医疗电子设备的一次系统故障就会带来生命威胁，这也是为什 么医疗设备，以及这些系统中集成的器件和这些器件中运行的软件 必须通过严格测试，并符合美国食品药品监督管理局（FDA）的严格要 求。为确保我们的新设计能够发挥理想可靠的性能，顺利通过FDA的审 批流程，我们采用了一种称为“Scrum/Sprint开发流程”的高度结构化 的设计方法。此外，通过减少在软件

2、中实施的功能，还能够降低软 件出错的几率。我们已在赛灵思的 FPGA中实施了这些功能。为了 能够更充分地理解这种方法，我们首先来分析一下医疗设备的设计 流程。三阶段生命周期FDA针对医疗电子产品制定了严格的规定、要求和指导原则，旨在 确保社会大众的人身安全。在这些规定中，FDA对医疗设备（图1） 的生命周期制定了严格的要求。一般情况下，电子产品公司必须在 如下方面都符合上述规定的要求，其中包括医疗设备的所有元件、 零部件或者配件，医疗设备生产过程中采用的任何软件，以及设备 制造商质量系统使用的所有软件，如可记录并保持设备历史记录的 程序等。图1、FDA定义的医疗设备设计整个生命周期图我们可将医

3、疗设备整个生命周期划分为三个主要阶段。首先是产品整个生命周期的初期阶段（图2），该阶段是所有三个阶段中系统性最差的阶段，期间企业主要侧重于理论与构思方面的研究和开发。该阶段的持续时长从数星期到数年不等，这与企业准备开发的系统的复杂程度息息相关图2、在产品整个生命周期的初期阶段应用虚拟仪器和HEI设计方法，可以清晰地理解需要解决的问题产品整个生命周期初期阶段的基本组成部分是数据采集与分析。通 常情况下，研究人员与产品设计规范小组会使用多种工具来精简流 程。在这个阶段，HEI通常会采用美国国家仪器（NI）公司的LabVIEW 产品来调整FPGA的I/O。一旦充分理解问题，我们就能设计出解决 方案。

4、对于器件开发及原型设计，我们结合直观的图形编程，重复 使用数学与信号处理功能来开发新的算法。然后，通过使用商用套 装硬件，我们对现实世界的数据进行参考来对算法的性能进行验证。 在许多情况下，我们都能使用NI提供的基于FPGA的原型设计平台 来实现最终器件的实验原型。确切地说，我们能够将LabVIEWReal-Time 模块和 FPGA 模块同 NI CompactRIO 结合使 用，以便在算法设计和器件原型阶段之间迅速实现叠代。使用硬件 套件进行原型设计，不仅能够显著缩短硬件开发与集成时间，而且 还使我们能够将更多精力集中到交付功能强大、性能可靠的软件设 计中。可将医疗设备整个生命周期的第二阶

5、段称为产品整个生命周期的中 期（参见图 3），能够充分满足所设计的设备在产品化、验证、审核以及制造等方面的需求。该阶段的重点是制定准确定义的、清晰载 明可量化要求的规范文档。这些规范一经定义，即可在规范文档与 实际的实施代码之间建立明确的映射关系。图 3 、软件设计的审核与验证工作通常是在产品整个生命周期的中期 完成在当今错综复杂的医疗设备市场上，客户必须加速上市，捷足先登。 众多公司纷纷采用传统的 “瀑布式 ”开发法来完成这项工作。 “瀑布式 开发法中的设计小组在进入下一步前，需要完成设计流程的每个步 骤（图 4）。瀑布法高度依赖在项目展开之初就拥有完整准确的规范。 但是，在医疗设备市场，更

6、多的时候需求会随着产品的开发而不断 发展变化。这就需要能够将发展演进也考虑周全的流程。 HEI 的 Scrum/Sprint 开发流程就是可充分解决这一问题的理想方案。图4、传统的瀑布式”开发流程在进入到下一步前需完成每一阶段的开发验证Scrum/Sprint开崔流程构建和集成定义需采和"Burn'down" 列表凤险分祈设计图5在“Scrum/Sprint流程中，启动项目只需要高级系统架构和规范在Scrum/Sprint流程中，我们仅要求高级系统架构和规范即可启动 项目。我们将项目细分为46个星期长的“ Spri nt。'在每个“ Spri nt 中，我们

7、可确定我们认为流程将会要求的所有任务，并将其置于燃尽'列表(burn-down list)中。图5与图6显示了相关流程图。HEI在全公司范围内使用Scrum/Sprint开发流程，不仅将我们的开发进程 加快了 30%，而且还使我们提前数月完成了新产品的实施。表1对瀑布式开发与Scrum/Sprint开发方案进行了比较。24 HoursDaHy Scrum MeetingProduct Backtogas Priortied by Product OwnerBacklog Tasks Expanded by TeamDemonstrableNew FunctionalitySprint

8、BacklogSprint Backlog图6项目小组为循环周期中的每个“Sprin确定“Sprin待办事项”工作任务，并对其进行扩展和分配。然后，项目小组在日常的” Scrum会议上评估进程，并消除相关障碍。小组在每个“Sprint终止时向客户交付产品功能&rua/9priaiWtitrFdQSE cintimi伽甑Htm of SKjidrom 聖ihY«s岂to印一 imfh med dimgeMeANeu proNftd iiheirconid( requme«i愉Sliori ipeTitilrydEs¥»sHeOrril fh

9、7;-r*-tvirkglHi Ji r«lvt*dTyped血山J T/h弓eju即ffw m 血曲b” 吟阳日曰Jkh" iwlf点山 耶卿曲 M dr?皿典医疗设备开发的第三阶段，也是最后一个阶段，属于产品整个生命 周期的后期（图7）。这个阶段要求的工程设计工作非常少，不过客 户反馈和市场成功将有助于推动新一代产品的概念形成，这样生命 周期又进入新的循环。图7产品生命周期后期工作是将产品推向市场， 获取反馈，帮助确定新一代产品的功能。这样就完成了本周期的工作，并将其带入新 的构思阶段。采用 Scrum/Sprint 产品开发流程， 再结合使用基于 FPGA 的套装硬

10、件以及涵盖从研发到制造过程的高级 FPGA 软件设计工具， HEI 就 能够迅速地开发出未来产品的衍生技术。我们发现在众多情况下都 可以使用我们在多种产品开发中采用的通用内核架构。例如，可调 整 IV 与输液泵的泵控制器架构，同样也能用于可控制电机以实现输 血管理的其它设计项目中。为何硬件优于软件为了有效地使用这种方法，并进一步加快设计流程，就必须改变构 思设计的方式，即从以软件为中心转变为更多地以硬件为中心。正 如人们所意识到的，医疗设备的召回在 2008 年达到新高，比 2007 年上升43%。FDA专家认为，发生召回问题的主要原因有两个：生 产中采用的原材料存在缺陷；软件开发工作存在问题

11、。企业对原材 料质量的管理相对容易一些，不过解决软件的质量问题难度则要大 得多。随着设备软件的代码量迅速增加， 问题只会日益严重。 在 FDA 的消费者健康安全部表示医疗设备设计方要承担众多安全责任后， 这个问题尤为突出。在 HEI ，我们认为该问题具有一个潜在的解决方案，不过不是进行 更多的测试、代码检查和引入更多的流程，相反，我们仅是尽量少 编写软件，将更多的逻辑交给诸如赛灵思 FPGA 这样的硬件元件来 执行。让我们来看看发生软件故障的常见原因，以及我们将如何使 用 FPGA 来解决这些问题。消除死锁大多数现代化设备都需要能够同时处理多个任务，而大多数嵌入式 处理器的处理内核仍然只有一个

12、。这意味着处理器每次只能执行一 个指令。同时，并行处理也好不到那里去，因为他们仍然必须共享 主系统 CPU 。此外，诸如通信驱动器、硬盘和用户接口元件等其他 共享资源也会引发死锁 两个或两个以上的处理进程相互等待对 方释放资源。由于死锁状况经常有赖于多个进程，并且通常要求事件在顺序上出 现同步，因而死锁非常难以复制和调试。仅仅进行单元测试很难发 现大多数死锁问题。它们往往被代码检查人员、熟练的系统测试人 员所发现，甚至有时靠运气发现。相比之下，采用 FPGA ，相互独立的进程拥有其自己的物理电路系 统，因而不存在共享资源。在每个时钟信号报时的时候，组合逻辑 不仅在每个电路中闭锁，而且还会在独立

13、的寄存器中存储相关值。 由于进程不依赖其他资源，因而也不会发生死锁问题。这样您就能 更多地相信仿真和单元测试的结果，因为诸如资源竞争这样的未知 因素不再是个问题。互不兼容的中间件在开发嵌入式软件时，您基本上无需从头开始编写每一行代码。有 许多工具都可帮助固件设计人员提升工作效率，如简单的驱动器、 网络协议栈、操作系统、乃至代码生成工具等。虽然这些系统通常 都进行过全面的独立测试，但软件还是会存在缺陷。由于工具和库 的组合方式多种多样，将组件以全新的方式组合在一起使用的可能 性非常大。基于此种原因， FDA 要求对在医疗设备中使用的所有套装软件，企 业必须根据其具体设计的具体使用情况对软件协议栈

14、进行审验。这 是什么意思呢？例如，若我们正在使用包含定点快速傅立叶变换的 信号处理库，并需要检测是否存在特定的频率组分，我们就无需验 证对于所有可能的输入， FFT 是否都会返回正确的值。但是，我们 需要验证的是，对于符合规范的所有有效输入， FFT 能否返回我们 期望的值。例如，如果我们只检测人耳能听到的音调，就没有必要 测试输入超过 20KHz 以上时返回的值是否正确。不过，看上去相互独立的软件组件并不一定如此。因此，如果我们 将软件协议栈与 SPI 驱动器结合起来使用，并配以实时操作系统 (RTOS) ，我们就需要对所有这些组件进行验证才能对 FFT 充满信 心。如果 FFT 将有效输出

15、传递到 SPI 驱动器，但 SPI 驱动器出现系 统性故障，那么问题显然不可避免。然后，如果我们决定调整 SPI 驱动器，就需要再次验证整个软件协议栈。这非常麻烦，而且一个 存在故障的组件会拖累整个系统的开发进程。基于此原因，在HEI，我们尽可能多地重复利用经检验具备良好特性的中间件和 RTOS 驱 动器组合。例如，我们可使用 NI单板RIO平台上的中间件驱动器。除了按照每种具体使用情况审验软件以外，我们还需要审验我们在我们基于FPGA的设计中使用的所有第三方知识产权(IP)。不过，一 旦我们完成我们所有使用情况的审验工作，我们就会深信不疑： IP 在和其它组件集成后，工作情况会如同预期一样。

16、让我们再来看看 我们上面举的FFT示例。如果我们使用FPGA，我们就可和使用软 件一样，获取或者生成 FFTIP 内核，根据每个使用情况验证其数字 的正确性。不过，间发故障的风险可大幅降低，因为我们不需要以 软件为中心的设计所需要的所有处理器中间件。 这样， RTOS 及 SPI 驱动器就不再是其自身 IP 内核了，因为其工作不会直接影响 FFT。 另外，如果我们调整 SPI 驱动器的实施，我们就不需要对系统未影 响的部分再进行审验。缓冲器溢出管理我们如何使用 FPGA 来减少以软件为中心的系统通常会产生的错误 的另一个示例就是缓冲器溢出管理。当程序试图存储超过为其存储 分配的存储器末端的数据

17、时，程序就会重复写入本不该写入的某些 相邻数据，这样就会产生缓冲器溢出。这是个很难察觉的缺陷，因 为在将来任何时候都可访问被重写的存储器，而且这种情况可能会 造成明显的错误，也可能不会。嵌入设计中一种比较常见的缓冲器 溢出情况是某种高速通信造成的，或许来自网络、磁盘或者 A/D 转 换器。如果通信中断时间过长，缓冲器就会溢出，因此我们需要解 决这个问题来防止各种冲突。我们可以以两种方式采用 FPGA 来管理缓冲器溢出。在第一种示例 中，我们采用 FPGA 管理循环传输或者双缓冲传输，这样可卸载实 时处理器的负荷。在这种情况下， FPGA 可用作协处理器，降低主 处理器的中断负载。这是一种通用配

18、置，特别是在高速 A/D 转换器 中。在第二种示例中，我们将 FPGA 用作保护功能的安全保护层，让针 对病人的I/O在到达处理器之前，先通过FPGA。在这种情况下，您 可以为 FPGA 增加额外的安全逻辑， 这样在处理器上的软件崩溃时， 您可将所有的输出置于已知的安全状态下。 FPGA 可发挥看门狗的 作用，其逻辑可以在软件发生故障的时候保证对病人的风险降低到 最低程度。通过在架构设计中将 FPGA 引入设备的主信号链，您可 以使用这两种方法中的一种或者两种来应对缓冲器溢出，以便在发 生状况的时候能够更好地处置。事实上，越多地将软、硬件总体系统功能移至 FPGA 中，就能越快 地完成设计流程，并最终越快地完成我们的设计在客户最终产品上 的验证工作。如果我们能更快地验证我们设计方案在总体系统上运 行的可靠性，那么我们的客户就能更快地验证整个最终产品，进而 将其交付 FDA 审批。这一过程意味着我们的客户能够显著加速其产 品的上市进程，改善患者的生活质量，甚