使用Eclipse Process Framework构建嵌入式软件

除了用于开发嵌入式软件产品的典型工作流程，如需求收集、分析、系统设计、详细设计、测试和项目管理，医疗设备行业还有一个额外的挑战——合规性。

挑战：

除了用于开发嵌入式软件产品的典型工作流程，如需求收集、分析、系统设计、详细设计、测试和项目管理，医疗设备行业还有一个额外的挑战——合规性。为美国市场开发的产品由美国食品药品监督管理局 （FDA） 通过质量体系法规 （QSR） 21 CFR Part §820.30 进行监管，这基本上要求：

在设计历史文件 （DHF） 中维护适当的文档

21 CFR 第 11 部分还管理 DHF 中电子签名的使用，以促进电子文档代替纸质版本

国际市场符合 ISO 13485:2003 并符合欧盟 MDD 93/42 法规

符合 FDA 规定的当前良好生产规范 （CGMP） 和良好设计规范 （GDP）

传统方法

为了达到合规目标，医疗器械开发团队在项目开始时就启动了 DHF。该文件的内容可能包括非正式的手写需求和设计说明，以及以打印输出和源代码摘录形式的正式架构和设计文档。对于许多以源代码为中心的开发团队，DHF 可能包括需求文档、临时正式设计文档和大量源代码清单，反映了表达的需求如何作为源代码忠实地实现。QSR 需要此工作流程，要求必须在需求及其确切实施之间建立可追溯性，以证明设备正用于其预期目的; 但是，没有详细说明建立可追溯性的方法。源代码通常是提交的，因为它很容易获得，并且大多数团队也使用源代码作为表示系统架构和设计的媒介。在开发过程中没有集成正式建模方法的情况下，这是非常典型的 。

设计输入输出

图 1 显示了 FDA 设计控制指南  中推荐的开发过程。请注意，通过遵循所示的迭代开发步骤，可以与 GDP 一起实现 QSR 合规性。通过根据设计输入测量设计输出，可以根据要求执行大部分系统验证。设计输入是一组最初源自用户要求的规范，其目标是设备的预期用途应作为一组要求进行说明。反过来，设计输出是设备制造商定义的一组程序，以确保完成的工作与相应的设计输入相符。这实质上要求这两个里程碑之间的可追溯性。

图1

传统上，开发过程包括作为设计输入的一组正式或半正式的文字处理器文档和一些模型，这些模型反映了构建系统所依据的一组规范。该输入被转换为设计输出中提到的一组预先披露的可交付成果。因此，在系统软件的情况下，设计输出可能包括属于应用程序的源代码列表。目标是披露设备的预期用途并确保已实施规范并满足设计目标。

验证设计

设计输入和输出里程碑是医疗器械开发过程的组成部分，适用于大量器械；因此，他们没有具体说明应该使用哪些方法进行图 1 中概述的流程中所示的验证。设备制造商为此使用了一系列工具和流程，但大多数依赖于文本需求文档和源代码列表，如设计输入和输出。图 1 包括一个设计验证步骤，其中根据设计输入验证设计输出。

验证系统

由于大多数团队将源代码视为系统实现的最终衡量标准，因此在实际设备上运行完整的源代码经常表明设备的预期用途。这是一种以源为中心的方法，因为通过执行为真实设备编译的应用程序代码来进行验证。

验证系统的传统方法虽然有效，但成本高且容易出错。在目标设备上对不断发展的系统进行单元测试的任务可能既繁琐又缓慢。可能无法在不产生大量费用或后勤障碍（例如硬件不完整或不存在）的情况下使机器通过所有预期的使用场景，这可能会妨碍设备的最终测试。不完整的平台可能会为测试的应用程序呈现错误的结果。

由于在单元测试期间发现了软件和系统错误并得到纠正，它们相关的设计和要求可能需要更新以反映更改的源代码。根据应用程序的大小，这可能会变得耗时且容易出错，因为可能会遗漏一些更改，从而导致 DHF 与实际实施的系统不匹配。

使用自动化工具的新方法

设计控制和 QSR 不需要实际运行的医疗设备作为系统验证和确认的基础。就 FDA 而言，只需证明收集的数据作为设备预期用途的证明就足够了。该数据可以从实际设备以及模拟执行中收集该设备的自动化应用程序开发工具提供了无与伦比的效率增益。图 2 展示了一个以确认和验证为中心的过程。与前面描述的 FDA 流程一样，该流程取决于基于设计输入的设计输出的迭代开发。图 2 还将需求追溯至系统验证，而架构和设计活动则追溯至系统验证。显示的所有步骤都是通过建模工具提供的需求可追溯性和可执行模型功能自动执行的。

图 2

自动验证和验证的示例

在模型驱动的过程中，应用程序的架构和设计都是在建模工具中进行的。此外，设计工具可以从设计模型中自动生成单元测试用例，如图 3 所示。在这里，设计和测试用例的模型都是可执行的。第一个目标是验证底层设计，然后测试设计，描绘设备的实际使用场景。大多数缺陷和设计疏忽都在此模型验证阶段被发现。单元测试可以使设计通过任何可能的场景，其中许多可能难以在实际设备上创建。在接下来的示例中，测试可以显示系统在患者在监测他或她的血氧水平的过程中没有表现出可检测到的脉搏这种不太可能发生的情况下的行为。

图 3

检测到的缺陷和疏忽会在设计中立即得到纠正，从而无需手动更改代码和设计文档。这与传统开发形成鲜明对比，传统开发是在真实设备上执行源代码后修复源代码内部的缺陷。这发生在开发过程的后期，因此系统调试比模型驱动方法慢得多。

图 4 中的示例说明了用于通过指夹传感器测量血氧水平和脉率的血氧监测仪的设计。该设计显示了一个状态机，负责对包含血氧水平 （SpO2） 和脉率的传感器数据进行解包。通过注入真实或模拟的传感器数据，图中所示的状态机可以快速验证正确的操作。此外，图 4 中的测试案例验证了脉搏率和氧气水平都在安全范围内。该测试用例与设计验证一起运行，以确保在难以创建的不可预见或复杂事件期间患者的安全。

图 4

此外，可以使用自动化需求管理工具，以便在设计组件（例如图 4 中所示的状态机）和需求之间建立可追溯性。

最后，对于系统验证，测试用例被追踪到系统的操作要求。这是通过正式需求管理工具和建模环境之间的需求可追溯性功能实现的自动化。换句话说，可以建立一个完全自动化的验证和验证过程。

开发工具

Telelogic 提供生命周期开发工具（如图 3 所示），涵盖 QSR 要求的整个系统验证和验证领域。DOORS 需求管理工具用作创建设计输入的基础，系统需求和验证测试都在 DOORS 内部作为结构化和可跟踪的对象集进行管理。

根据正在开发的医疗设备的性质，两种不同的工具可提供建模解决方案。对于通常使用单板嵌入式计算机和实时操作系统 （RTOS） 的传统独立医疗设备，Telelogic 的 Rhapsody 提供系统架构和设计支持以及自动源代码生成。Rhapsody 能够支持开箱即用的主要 RTOS 平台。它还提供了目标托管协同仿真的附加功能，当需要目标级验证时，这在验证和验证过程中被证明是有价值的。

Telelogic TAU 可用于使用多个平台或嵌入式和桌面系统的任意组合的复杂医疗设备。这可能包括计算机断层扫描 （CT） 扫描仪等设备或携带一系列相关平台的其他系统，包括无头运行传统操作系统（如 Linux、UNIX 或 Windows）的台式计算机和监控工作站。TAU 支持独立于语言和操作系统的建模，并且可以使用多种编程语言在任意平台上部署相同的模型。这被描述为平台无关建模 （PIM），其中一组模型可以在许多不同或未定义的平台上使用。因此，PIM 的概念为提高生产力增加了另一个维度，允许在未来几代未知平台中使用设计的组件。

自动化开发过程生成的文档提供了源自需求管理和建模活动的集成书面记录。这篇论文是由 Telelogic 的 DocExpress 自动创建的，它可以查看本示例中使用的所有 Telelogic 工具。DocExpress 自动创建包含来自所用工具的文本和图表的文字处理器页面，并且完全由用户配置。

更好、更便宜的开发过程

在设计医疗设备时，FDA QSR 规定的设计指南和法规可以与系统和软件开发中的最佳实践同时解决。这不仅降低了开发成本，还促进了 QSR 规定的验证和验证过程，从而使医疗设备更可靠，现场故障的可能性更小。此外，这还为 DHF 提供了实时内容，这些内容是自动管理和制作的。Telelogic 的生命周期管理解决方案集旨在通过使用需求管理、系统和软件建模以及自动化的、基于模型的测试工具（包括 DOORS、Rhapsody、TAU 和 DocExpress）来自动化开发过程。

审核编辑：郭婷