嵌入式软件和当今的医疗设备

　　嵌入式开发人员在开发医疗嵌入式设备时面临多个决策，从选择最佳系统软件以获得最佳应用性能，到了解软件操作系统和目标硬件之间的交互和限制。软件工程师应该使用小型微内核、实时操作系统 （RTOS） 还是通用操作系统 （GPOS），例如 Android 或 Linux？其他考虑因素包括系统的可移植性和功能要求的物理尺寸，包括更快的性能、功耗、数据保护和显示（用户界面）技术。影响嵌入式软件选择的 FDA 认证和行业标准也加入其中。

　　现代医疗设备正在以创纪录的速度发展。从供患者在家中使用的便携式无线设备到医疗保健专业人员在设施中使用的更大更复杂的设备，毫无疑问，我们处于开发新方法以增强患者和医疗专业人员的能力的最前沿。我们如何确保控制这些设备的系统软件完全按计划运行，几乎没有伤害患者的风险？

　　问题的核心：操作系统

　　通常，操作系统 （OS） 管理医疗嵌入式设备。操作系统可以从一些有进取心的软件编码人员内部构建的简单“自己动手”到成熟供应商提供的更复杂的操作系统。Linux 或 Android 等 GPOS 为应用程序开发建立了功能丰富的平台，但有时会消耗过多的内存。对于现代医疗设备来说，RTOS 也是一个不错的选择，特别是当特定系统要求需要确定性的抢占式内核和较小的内存占用时。在混合的某个地方，您的应用程序和硬件是理想的候选者。有一件事是肯定的：在选择您的操作系统之前，请准确了解您的应用程序的意图以及您计划使用的硬件。

　　该设备将如何使用？

　　开发嵌入式系统时将风险降至最低的一种方法是首先考虑其用例——不仅是最终用户将如何与之交互，而且还要考虑它的设计、开发和测试方式。该设备将主要由医疗保健提供者、患者在家中使用，还是两者兼而有之？

　　该设备是否具有通信模式或纯粹是独立的？根据其通信需求，您可能会发现您首选的操作系统包括您需要的许多模式，或者您可能更喜欢其他操作系统，在这种情况下，您必须移植通信堆栈和/或驱动程序才能获得正确的通讯软件的组合。

　　是否确定了任何实时需求？对于某些设备，不需要实时行为。如果中断服务延迟 100 毫秒，结果可能会延迟 100 毫秒，但这不会导致失败。但是，如果它是用于眼科手术的激光，如果激光没有在准确的时间打开和关闭，这可能会产生灾难性的影响。如果激光器具有眼动追踪引导，则即使存在眼动，激光器也必须以预定义的模式同步移动。

　　也许该设备是关键设备，因此对成本的敏感性最低。相反，手持设备并以数百万售出，对成本具有很高的敏感性。这些类型的考虑因素将直接影响最小化 BOM 的需求，进而可能会最小化您有效构建完整应用程序所需的内存，并留有一定的余量。

　　一切都与硬件有关

　　一旦定义了用例，就该找到合适的硬件了。医疗系统可以非常小，配备一个时钟频率低于 25 MHz 的 8 位微控制器，并且仅使用 8K 内存。更复杂的设计可以包括功能丰富的 SoC，时钟频率为数百 MHz 和兆字节的内存。系统范围包括具有专用处理器或 DSP 的混合系统到包含大量多核芯片的系统。

　　最适合您的设计的是用例和您希望系统如何运行的期望。

　　需要多核吗？

　　考虑到选择多核的两个主要原因——纯处理性能和低功耗管理——可以添加第三个，即两者的结合。

　　如果您关心低功耗，您可能只想使用多核 SoC，因为它可以以较低的时钟频率利用所有可用的内核，而不是以更高的频率为主处理器提供时钟。不需要时，它可以关闭额外的内核以节省电力。

　　虽然功率和性能都是使用多核的充分理由，但问题更多在于找到分配 CPU 的最佳方式。使用对称硬件，您可以在所有可用内核上使用单一操作系统，作为一种对称多核处理 （SMP）。大多数 GPOS 和一些 RTOS 都具有此功能。但是，使用 SMP 可能会使跨内核的调度复杂化，因为一个内核中的缓存未命中导致的实时命中可能会导致另一个内核中的缓存刷新，这总是会导致系统延迟。自旋锁等功能对于所有支持 SMP 的操作系统都是通用的。如果使用不当，自旋锁可能会损害系统性能，因为一个核心会在不确定的时间内停止等待另一个核心上的资源被释放。

　　构建系统的另一种方法（即使使用对称硬件）是应用非对称多核处理 （AMP） 技术。这种方法涉及两个或多个独立的操作系统，通过某种类型的通信通道使用硬件（如一系列 FIFO）或通过共享内存进行交互。多核协会有一个标准可以使应用程序开发可移植，称为多核通信 API （MCAPI）。

　　当硬件和软件世界发生冲突时

　　考虑这样一种情况：通过 USB 连接到 Windows 主机的医疗设备通常遵循 USB 规范，但是当 SoC 的所有部分都被激活时，硬件会间歇性地开始发出超出规范的信号，导致主机关闭在会话中间关闭端口，导致在最不合时宜的时间失败 - 在患者数据收集期间。在结果丢失的情况下，提前24小时对原程序进行特殊准备的患者必须准备重新测试。

　　导致端口关闭的两个根本原因。首先，软件假设 USB 控制器不会出现故障。其次，系统架构没有针对在会话中间拔掉设备的情况进行规划。如果系统考虑了这些用例中的任何一个，系统将在本地存储数据，允许在会话重新建立后进行传输，从而最大限度地降低患者可能重新测试的风险。

　　该应用程序依靠 USB 控制器的完美操作来防止数据丢失。如果将应用程序分解为几个部分，则可能可以避免数据丢失。采用数据采集和数据传输互不关联的架构，即使链路发生故障，数据仍然存储在设备中，因此当设备恢复时，可以从中断处继续，不会丢失任何数据。在传输到主机之前写入缓冲区（这将在后台发生）是避免在这种情况下丢失数据的一种方法。

　　如果使用软件变通方法来检测 USB 总线暂停，则该变通方法可以使 SoC 引脚脱离 USB 模式并使它们成为 GPIO 引脚，以便主机可以检测到复位条件并强制重新枚举设备。然后 USB 软件将重新提交缓冲区，传输将继续。最终结果是数据不会丢失，只是在解决方法发生时延迟。

　　便携性考虑

　　操作系统管理系统的硬件和软件资源。最基本的管理是内存和时间的管理。但是操作系统的责任在哪里停止而应用程序的责任从哪里开始呢？虽然应用程序可以在其中内置设备驱动程序并直接与硬件通信，但随着设备的发展和采用更新的硬件，移植到新硬件成为一项挑战。因此，建议系统中的大多数（如果不是全部）设备由操作系统管理，以确保未来的可移植性。

　　法规和患者隐私

　　对便携性的需求包括无线设备，如 GSM 无线电或用于连接的 802.11 无线接口。其他包括蓝牙和 ZigBee，这些链接也必须是安全的并提供患者隐私。即使在设备本身中，也必须只有有权查看患者的医生才能真正看到该患者的数据。禁止未经授权的访问也是任何设备的关键要求。记录是否安全，即使对于在设备上工作的技术人员也是如此？是否存在这些数据不安全的模式？真正的健康保险流通与责任法案 （HIPPA） 合规性确保信息的安全性至关重要。患者记录数据库内部的安全性也是如此。

　　结论

　　医疗设备是一种特殊的品种，将以某种方式触及我们所有人。在设计这些系统时，我们需要格外小心，以确保设备能够完成预期的工作。使用 RTOS 或 GPOS 来满足确定性、大小、启动时间、功耗优化和可用中间件广度的要求是否有意义？最后，为了最大限度地降低风险，我们需要确保遵守 HIPPA 和 FDA 的所有规定。

　　审核编辑：郭婷