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

几乎每个使用手机的人都会有过几次通话中断的经历。虽然这些产品以及其他消费类产品的系统故障或者小毛病会带来不方便，但它们不会造成灾难性的后果。然而，医疗电子设备的一次系统故障就会带来生命威胁，这也是为什么医疗设备，以及这些系统中集成的器件和这些器件中运行的软件必须通过严格测试，并符合美国食品药品监督管理局(FDA)的严格要求。

 

为确保我们的新设计能够发挥理想可靠的性能，顺利通过FDA的审批流程，我们采用了一种称为“Scrum/Sprint开发流程”的高度结构化的设计方法。此外，通过减少在软件中实施的功能，还能够降低软件出错的几率。我们已在赛灵思的FPGA中实施了这些功能。为了能够更充分地理解这种方法，我们首先来分析一下医疗设备的设计流程。

 

三阶段生命周期

FDA针对医疗电子产品制定了严格的规定、要求和指导原则，旨在确保社会大众的人身安全。在这些规定中，FDA对医疗设备（图1）的生命周期制定了严格的要求。一般情况下，电子产品公司必须在如下方面都符合上述规定的要求，其中包括医疗设备的所有元件、零部件或者配件，医疗设备生产过程中采用的任何软件，以及设备制造商质量系统使用的所有软件，如可记录并保持设备历史记录的程序等。

 

 

图1、FDA定义的医疗设备设计整个生命周期图.

 

我们可将医疗设备整个生命周期划分为三个主要阶段。首先是产品整个生命周期的初期阶段（图2），该阶段是所有三个阶段中系统性最差的阶段，期间企业主要侧重于理论与构思方面的研究和开发。该阶段的持续时长从数星期到数年不等，这与企业准备开发的系统的复杂程度息息相关。

 

图2、在产品整个生命周期的初期阶段应用虚拟仪器和HEI设计方法，可以清晰地理解需要解决的问题。(print)

 

 

产品整个生命周期初期阶段的基本组成部分是数据采集与分析。通常情况下，研究人员与产品设计规范小组会使用多种工具来精简流程。在这个阶段，HEI通常会采用美国国家仪器(NI)公司的LabVIEW产品来调整FPGA的I/O。一旦充分理解问题，我们就能设计出解决方案。对于器件开发及原型设计，我们结合直观的图形编程，重复使用数学与信号处理功能来开发新的算法。然后，通过使用商用套装硬件，我们对现实世界的数据进行参考来对算法的性能进行验证。在许多情况下，我们都能使用NI提供的基于FPGA的原型设计平台来实现最终器件的实验原型。确切地说，我们能够将LabVIEWReal-Time模块和FPGA模块同NI CompactRIO结合使用，以便在算法设计和器件原型阶段之间迅速实现叠代。使用硬件套件进行原型设计，不仅能够显著缩短硬件开发与集成时间，而且还使我们能够将更多精力集中到交付功能强大、性能可靠的软件设计中。

 

 

图3、软件设计的审核与验证工作通常是在产品整个生命周期的中期完成。

 

 

可将医疗设备整个生命周期的第二阶段称为产品整个生命周期的中期（参见图3），能够充分满足所设计的设备在产品化、验证、审核以及制造等方面的需求。该阶段的重点是制定准确定义的、清晰载明可量化要求的规范文档。这些规范一经定义，即可在规范文档与实际的实施代码之间建立明确的映射关系。

 

 

图4、传统的“瀑布式”开发流程在进入到下一步前需完成每一阶段的开发。

 

 

在当今错综复杂的医疗设备市场上，客户必须加速上市，捷足先登。众多公司纷纷采用传统的“瀑布式”开发法来完成这项工作。“瀑布式”开发法中的设计小组在进入下一步前，需要完成设计流程的每个步骤（图4）。瀑布法高度依赖在项目展开之初就拥有完整准确的规范。但是，在医疗设备市场，更多的时候需求会随着产品的开发而不断发展变化。这就需要能够将发展演进也考虑周全的流程。HEI的Scrum/Sprint开发流程就是可充分解决这一问题的理想方案。

 

 

图5——在“Scrum/Sprint”流程中，启动项目只需要高级系统架构和规范。

 

 

 

图6——项目小组为循环周期中的每个“Sprint”确定“Sprint待办事项”工作任务，并对其进行扩展和分配。然后，项目小组在日常的”Scrum“会议上评估进程，并消除相关障碍。小组在每个“Sprint”终止时向客户交付产品功能。

在Scrum/Sprint流程中，我们仅要求高级系统架构和规范即可启动项目。我们将项目细分为4～6个星期长的“Sprint”。在每个“Sprint”中，我们可确定我们认为流程将会要求的所有任务，并将其置于“燃尽”列表(burn-down list)中。图5与图6显示了相关流程图。HEI在全公司范围内使用Scrum/Sprint开发流程，不仅将我们的开发进程加快了30%，而且还使我们提前数月完成了新产品的实施。表1对瀑布式开发与Scrum/Sprint开发方案进行了比较。

 

医疗设备开发的第三阶段，也是最后一个阶段，属于产品整个生命周期的后期（图7）。这个阶段要求的工程设计工作非常少，不过客户反馈和市场成功将有助于推动新一代产品的概念形成，这样生命周期又进入新的循环。

 

 

图7—产品生命周期后期工作是将产品推向市场，获取反馈，帮助确定新一代产品的功能。这样就完成了本周期的工作，并将其带入新的构思阶段。

 

采用Scrum/Sprint产品开发流程，再结合使用基于FPGA的套装硬件以及涵盖从研发到制造过程的高级FPGA软件设计工具，HEI就能够迅速地开发出未来产品的衍生技术。我们发现在众多情况下都可以使用我们在多种产品开发中采用的通用内核架构。例如，可调整IV与输液泵的泵控制器架构，同样也能用于可控制电机以实现输血管理的其它设计项目中。

 

为何硬件优于软件

为了有效地使用这种方法，并进一步加快设计流程，就必须改变构思设计的方式，即从以软件为中心转变为更多地以硬件为中心。正如人们所意识到的，医疗设备的召回在2008年达到新高，比2007年上升43%。FDA专家认为，发生召回问题的主要原因有两个：生产中采用的原材料存在缺陷；软件开发工作存在问题。企业对原材料质量的管理相对容易一些，不过解决软件的质量问题难度则要大得多。随着设备软件的代码量迅速增加，问题只会日益严重。在FDA的消费者健康安全部表示医疗设备设计方要承担众多安全责任后，这个问题尤为突出。

 

在HEI，我们认为该问题具有一个潜在的解决方案，不过不是进行更多的测试、代码检查和引入更多的流程，相反，我们仅是尽量少编写软件，将更多的逻辑交给诸如赛灵思FPGA这样的硬件元件来执行。让我们来看看发生软件故障的常见原因，以及我们将如何使用FPGA来解决这些问题。

 

消除死锁

大多数现代化设备都需要能够同时处理多个任务，而大多数嵌入式处理器的处理内核仍然只有一个。这意味着处理器每次只能执行一个指令。同时，并行处理也好不到那里去，因为他们仍然必须共享主系统CPU。此外，诸如通信驱动器、硬盘和用户接口元件等其他共享资源也会引发死锁——两个或两个以上的处理进程相互等待对方释放资源。

 

由于死锁状况经常有赖于多个进程，并且通常要求事件在顺序上出现同步，因而死锁非常难以复制和调试。仅仅进行单元测试很难发现大多数死锁问题。它们往往被代码检查人员、熟练的系统测试人员所发现，甚至有时靠运气发现。

 

相比之下，采用FPGA，相互独立的进程拥有其自己的物理电路系统，因而不存在共享资源。在每个时钟信号报时的时候，组合逻辑不仅在每个电路中闭锁，而且还会在独立的寄存器中存储相关值。由于进程不依赖其他资源，因而也不会发生死锁问题。这样您就能更多地相信仿真和单元测试的结果，因为诸如资源竞争这样的未知因素不再是个问题。

 

互不兼容的中间件

在开发嵌入式软件时，您基本上无需从头开始编写每一行代码。有许多工具都可帮助固件设计人员提升工作效率，如简单的驱动器、网络协议栈、操作系统、乃至代码生成工具等。虽然这些系统通常都进行过全面的独立测试，但软件还是会存在缺陷。由于工具和库的组合方式多种多样，将组件以全新的方式组合在一起使用的可能性非常大。

基于此种原因，FDA要求对在医疗设备中使用的所有套装软件，企业必须根据其具体设计的具体使用情况对软件协议栈进行审验。这是什么意思呢？例如，若我们正在使用包含定点快速傅立叶变换的信号处理库，并需要检测是否存在特定的频率组分，我们就无需验证对于所有可能的输入，FFT是否都会返回正确的值。但是，我们需要验证的是，对于符合规范的所有有效输入，FFT能否返回我们期望的值。例如，如果我们只检测人耳能听到的音调，就没有必要测试输入超过20KHz以上时返回的值是否正确。

 

不过，看上去相互独立的软件组件并不一定如此。因此，如果我们将软件协议栈与SPI驱动器结合起来使用，并配以实时操作系统(RTOS)，我们就需要对所有这些组件进行验证才能对FFT充满信心。如果FFT将有效输出传递到SPI驱动器，但SPI驱动器出现系统性故障，那么问题显然不可避免。然后，如果我们决定调整SPI驱动器，就需要再次验证整个软件协议栈。这非常麻烦，而且一个存在故障的组件会拖累整个系统的开发进程。基于此原因，在HEI，我们尽可能多地重复利用经检验具备良好特性的中间件和RTOS驱动器组合。例如，我们可使用NI单板RIO平台上的中间件驱动器。

 

除了按照每种具体使用情况审验软件以外，我们还需要审验我们在我们基于FPGA的设计中使用的所有第三方知识产权(IP)。不过，一旦我们完成我们所有使用情况的审验工作，我们就会深信不疑：IP在和其它组件集成后，工作情况会如同预期一样。让我们再来看看我们上面举的FFT示例。如果我们使用FPGA，我们就可和使用软件一样，获取或者生成FFTIP内核，根据每个使用情况验证其数字的正确性。不过，间发故障的风险可大幅降低，因为我们不需要以软件为中心的设计所需要的所有处理器中间件。这样，RTOS及SPI驱动器就不再是其自身IP内核了，因为其工作不会直接影响FFT。另外，如果我们调整SPI驱动器的实施，我们就不需要对系统未影响的部分再进行审验。

 

缓冲器溢出管理

我们如何使用FPGA来减少以软件为中心的系统通常会产生的错误的另一个示例就是缓冲器溢出管理。当程序试图存储超过为其存储分配的存储器末端的数据时，程序就会重复写入本不该写入的某些相邻数据，这样就会产生缓冲器溢出。这是个很难察觉的缺陷，因为在将来任何时候都可访问被重写的存储器，而且这种情况可能会造成明显的错误，也可能不会。嵌入设计中一种比较常见的缓冲器溢出情况是某种高速通信造成的，或许来自网络、磁盘或者A/D转换器。如果通信中断时间过长，缓冲器就会溢出，因此我们需要解决这个问题来防止各种冲突。

 

我们可以以两种方式采用FPGA来管理缓冲器溢出。在第一种示例中，我们采用FPGA管理循环传输或者双缓冲传输，这样可卸载实时处理器的负荷。在这种情况下，FPGA可用作协处理器，降低主处理器的中断负载。这是一种通用配置，特别是在高速A/D转换器中。

 

在第二种示例中，我们将FPGA用作保护功能的安全保护层，让针对病人的I/O在到达处理器之前，先通过FPGA。在这种情况下，您可以为FPGA增加额外的安全逻辑，这样在处理器上的软件崩溃时，您可将所有的输出置于已知的安全状态下。FPGA可发挥看门狗的作用，其逻辑可以在软件发生故障的时候保证对病人的风险降低到最低程度。通过在架构设计中将FPGA引入设备的主信号链，您可以使用这两种方法中的一种或者两种来应对缓冲器溢出，以便在发生状况的时候能够更好地处置。

 

事实上，越多地将软、硬件总体系统功能移至FPGA中，就能越快地完成设计流程，并最终越快地完成我们的设计在客户最终产品上的验证工作。如果我们能更快地验证我们设计方案在总体系统上运行的可靠性，那么我们的客户就能更快地验证整个最终产品，进而将其交付FDA审批。这一过程意味着我们的客户能够显著加速其产品的上市进程，改善患者的生活质量，甚至拯救生命。

 

如果我们采用ASIC工艺来实施设计，我们需要为代工厂生产出硬件等上好几个月。验证ASIC的物理设计、创建掩膜并将设计投产等额外的步骤会造成更多出错和出现缺陷的几率。如果设计在任何这些步骤中出现错误，结果都会导致产品上市时间被大大拖延。由于已生产出FPGA且经过全面的测试，因此我们只需关心我们的设计和软件，并确保设计能够符合客户的规范要求。全面结合“Scrum/Sprint”方法、以硬件为中心的构思、使用高度可靠的工具并在FPGA与ASIC中选择FPGA，我们便能使客户实现差异化，进而也能为客户的客户，即患者带来改变。