模型驱动开发环境强化软件开发流程

   在当今的互连世界，医疗设备理所当然地容纳了更多具有智能功能的创新性能。这些新型性能通常采用软件进行设计；因此，用于实现这些新功能的软件日益复杂。同时，FDA及其它管理机构也逐步对医疗设备制造商施加压力，以确保产品安全和有关医疗设备报告信息的准确性。

   市场上面临产品复杂性增加、上市压力、产品安全和监管，对于医疗设备公司来说应对这些挑战成为良好的商业常识。本文探究一种开发医疗设备软件的模型驱动方法。

   设备制造商正处于软件开发的转折点，几种工具可能会帮助他们改良生产率和质量。一种模型驱动的开发流程集成了产品开发的多样阶段，从需求分析到系统设计、实现、文档制作和测试。此工作流程有助于使复杂的需求和架构能图形化地以图表形式表示，因此减少了复杂性，并且还能帮助股东之间就需求和设计进行交流。图表具有语义并且互连，有助于实现直接从设计要求到设计的可追踪性。更进一步的是，该软件实现可由模型直接生成，提供了从设计要求到设计到实现的追踪检查。

交付设备软件

   在医疗设备市场，交付创新技术的推动力非常现实，智能设备无处不在。在这一领域，是软件提供了使高技术世界成为可能的功能。医疗设备的软件被用于执行以往可能以硬件实现的功能：例如，诊断设备上的物理旋钮和按钮经常被触摸屏显示所替代，或者医疗图像如X光和MRI逐渐以数字格式而不是物理胶片交付。

   医疗市场竞争残酷，而且产品在竞争到来之前上市至关重要。完成上市销售前的活动（如510(k)流程）和随后的药品生产和质量管理(GMP)对设备引入市场并占领强劲市场份额必不可少。但是，在速度和病人安全之间必须取得平衡以避免耗费大的产品召回。策略之一是为上市前活动重复使用现有的大量的等效编程代码，尤其是当与软件协同工作进行生命攸关的手术时。实现成功软件的关键路径是通过理解；在一些情况下，软件可能已老化，编程人员也早已不在公司，即为什么有效复用取决于文档可理解。

文档！文档！文档！

   能发挥其知识产权(IP)效用的组织——并能复用——在工程设计新型医疗设备软件时已{lx1}一步。对于复用，没有什么比药品文档编制更为重要，它还具有其它的效用。对于维护项目信息，一个设计历史文件(DHF)被用于储存项目成果。FDA通过需要一个DHF的质量系统监控(QSR)——21 xx管理代码（CFR) Part 820.30来管理面向美国市场开发的产品。该DHF包含有关的信息，从多种源，包括诸如需求、系统规范、风险管理和其它正式文档在内的项目。也可能包括笔记、草图或其它零碎信息。具备一个DHF背后的基本原理是提供可追踪性和文档，以显示设备被用于特定目的，其设计实现了所有要求。然而，如何实现在某种程度上实属偶然：一些公司使用源代码打印清单以证明全部实现设计要求。当然，用源代码作为沟通方法仅在读者能读懂代码的条件下有效。非技术股东可能缺乏所需读懂源代码的技能，从而产生了潜在的危险的沟通真空。

可视软件开发

   模型驱动开发(MDD)为软件交付创建了一种可视化开发环境。MDD的基础是源于对象管理组织的统一建模语言(UML)。MDD环境使复杂的设计输入可视化，促进了各种各样股东之间的沟通。开发团队能用比源代码更易使股东理解的格式表述设计要求、架构、结构、设计和行为。UML定义了几种不同的图表来获得系统或应用的机构、架构和行为。与UML类似的是，系统建模语言(SysML)基于UML，但是是为系统工程设计需求而量身定做。

   UML图表内的信息被存储在一个模型储存库内，这极大地扩展了图表原仅作为插图之用的作用(见图1)。一张图表上的信息变化被模型储存库所反映，并传送给其它图表以反映同样的信息。例如，假定设计中有一级名为“Pump”，同一级出现在两个不同的图表内。在一张图中把“Pump”名改为“InfusionPump”将会在另一张图中自动变化过来。

图1：以状态图形式描述的设备操作模式。

追踪设计要求到模型元件

   对医疗设备的要求通常以文本文件而规定，或存在于用作设计输入的需求管理工具内。尽管文本能交流大量需要完成的细节，它也会易受误解。更为重要的是，没有滤波器或流程来防止有冲突的设计要求在最开始就被记录下来。通过把需求拆分为产品内每个元件更进一步的细节要求，执行需求分析能帮助解决冲突。建模能通过文本需求以图表的形式可视化来辅助这一过程，并且提供到设计和实现的可追踪性。

   追踪需求到模型元件的{dy}步是将文本需求与建模环境相关起来。模型内的一个需求元件储存需求，并保持除其它相关信息如需求ID、优先级、安全完整性级别及风险等之外的描述需求的文本。对能储存的数据类型没有限制。需求和模型之间保持同步化，从而任何一方的更改都能反映到另一方。从需求到满足这些需求的模型元件的可追踪性能在模型内表述出来。凭借这些信息，能生成需求覆盖报告或进行设计改变的影响分析。例如，能生成一个UML资料，定义了故障树分析图表。模型内还能进行安全性和风险分析。图2展示了故障如何被追踪到与故障相关的设计要求。可进行更进一步的模型信息分析来说明覆盖鸿沟。

图2：关系追踪需求到满足设计要求的模型元件。

与代码和模型协同工作

   医疗设备制造商已经校验并测试了现有设备中采用可被未来设备使用的软件。该软件可被引入到建模环境内。UML代码图能被自动创建，以显示代码现有的结构、架构和行为。结果是对现有代码的文档编制更好，有助于新开发商或其他股东获得更容易理解的针对特定目的的代码。

   一旦在模型中被描述，到设计要求的可追踪性能被添加到现有代码内，可被用于协助创建模型内已开发的新特性。例如，一个新型用户接口可能为输液泵而创建，但现有传送xx给病人的代码应该被重复使用。用户接口代码简单地引用现有代码，两者之间的关系就随之在模型内建立。

   作为设计流程，更多细节和行为被添加进改模型。UML提供了指定模型内全部应用的设备，详细的目标级代码也被纳入模型。面向设备的代码能直接由模型生成。这有助于创建模型内从代码到设计的可追踪性。模型内也包含了设计要求，因此由需求到实现代码获得可追踪性（见图3）。有可能直接在代码内包含需求信息作为对需求、设计和实现之间更进一步可追踪性的评估。

图3：从模型生成的代码可由设计追踪到实现。

   软件开发人员不需要放弃他们当前的开发环境来采用模型驱动方法。从模型产生的代码能被编入他们的选择代码编辑器内，模型内可自动更新变化（见图4）.这保持了实现与设计同步。

图4：模型驱动开发于现有的开发环境如Eclipse相集成。

校验和验证

   FDA 指南推荐在初始设计输入时启动校验，并且持续校验迭代贯穿整个开发过程。大多数缺陷在开发初始分析阶段即进入系统，但通常很晚直到集成阶段才被发现。模型驱动方法采用模型执行和一致性校验，以在最容易被确定的产品设计早期发现问题。采用该模型，有可能生成生产质量代码，包括C代码。

   对于医疗设备工程师来说，在主机平台运行的模型执行能刚好在硬件可能为软件测试准备就绪之前校验设计行为。当硬件可用时，工程师就能专注于目标特定的问题，如时序。

图5：通过突出设计行为，模型执行有助实现早期校验。

文档制作

   利用模型驱动方法，因为软件开发人员创建了模型，他们也提供面向其设计的文档制作。模型中的图表使设计可视化，能被用于项目股东或监管机构的沟通交流。因为实现代码也是从模型生成的，实现和文档制作都保持同步，以帮助确保文档能准确地表述实现。模型文档能生成多种格式，满足每间公司的特定需要。对于整体设备来说，文档内可包含图解、表格、矩阵和文本信息。

结论

   医疗设备软件的复杂性日益增加，机构监管是生活的现实。基于UML的MDD环境帮助实现文本需求可视化，加强了设计过程。它授予团队分解复杂需求并与项目湍急及政府机构更有效沟通的能力。通过维持多层的一致信息，模型的语义有助于管理设计变更。

   在设计周期的初期进行校验来识别最容易被定位的错误，以达到质量和安全性目标。对于医疗设备开发商，一个模型驱动方法集成了产品生命周期的不同阶段——有助于改进公司交付创新医疗设备软件的能力，同时获得竞争优势。

   Paul Urban是IBM公司Rational Rhapsody 及医疗器械行业市场经理