利用Scrum/Sprint开发流程构建高可靠性医疗电子设备
时间：01-13
来源：互联网
点击：
为何硬件优于软件
为了有效地使用这种方法，并进一步加快设计流程，就必须改变构思设计的方式，即从以软件为中心转变为更多地以硬件为中心。正如人们所意识到的，医疗设备的召回在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，我们便能使客户实现差异化，进而也能为客户的客户，即患者带来改变。
为了有效地使用这种方法，并进一步加快设计流程，就必须改变构思设计的方式，即从以软件为中心转变为更多地以硬件为中心。正如人们所意识到的，医疗设备的召回在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，我们便能使客户实现差异化，进而也能为客户的客户，即患者带来改变。
电子 赛灵思 FPGA 虚拟仪器 LabVIEW 嵌入式 电路 仿真 看门狗 相关文章：
- 基于中颖SH79F164单片机的电子血压计应用(07-01)
- 医疗电子发展方向(04-17)
- 世界首个固态量子处理器问世(07-13)
- 医疗电子技术大会折射行业发展方向(04-18)
- 医疗电子：梦想与现实的巨大鸿沟(07-16)
- “聪明的药丸”(07-20)
射频专业培训教程推荐
栏目分类