除了用于開發(fā)嵌入式軟件產(chǎn)品的典型工作流程，如需求收集、分析、系統(tǒng)設計、詳細設計、測試和項目管理，醫(yī)療設備行業(yè)還有一個額外的挑戰(zhàn)——合規(guī)性。

挑戰(zhàn)：

除了用于開發(fā)嵌入式軟件產(chǎn)品的典型工作流程，如需求收集、分析、系統(tǒng)設計、詳細設計、測試和項目管理，醫(yī)療設備行業(yè)還有一個額外的挑戰(zhàn)——合規(guī)性。為美國市場開發(fā)的產(chǎn)品由美國食品藥品監(jiān)督管理局 （FDA） 通過質(zhì)量體系法規(guī) （QSR） 21 CFR Part §820.30 進行監(jiān)管，這基本上要求：

在設計歷史文件 （DHF） 中維護適當?shù)奈臋n

21 CFR 第 11 部分還管理 DHF 中電子簽名的使用，以促進電子文檔代替紙質(zhì)版本

國際市場符合 ISO 13485:2003 并符合歐盟 MDD 93/42 法規(guī)

符合 FDA 規(guī)定的當前良好生產(chǎn)規(guī)范 （CGMP） 和良好設計規(guī)范 （GDP）

傳統(tǒng)方法

為了達到合規(guī)目標，醫(yī)療器械開發(fā)團隊在項目開始時就啟動了 DHF。該文件的內(nèi)容可能包括非正式的手寫需求和設計說明，以及以打印輸出和源代碼摘錄形式的正式架構和設計文檔。對于許多以源代碼為中心的開發(fā)團隊，DHF 可能包括需求文檔、臨時正式設計文檔和大量源代碼清單，反映了表達的需求如何作為源代碼忠實地實現(xiàn)。QSR 需要此工作流程，要求必須在需求及其確切實施之間建立可追溯性，以證明設備正用于其預期目的; 但是，沒有詳細說明建立可追溯性的方法。源代碼通常是提交的，因為它很容易獲得，并且大多數(shù)團隊也使用源代碼作為表示系統(tǒng)架構和設計的媒介。在開發(fā)過程中沒有集成正式建模方法的情況下，這是非常典型的 。

設計輸入輸出

圖 1 顯示了 FDA 設計控制指南? 中推薦的開發(fā)過程。請注意，通過遵循所示的迭代開發(fā)步驟，可以與 GDP 一起實現(xiàn) QSR 合規(guī)性。通過根據(jù)設計輸入測量設計輸出，可以根據(jù)要求執(zhí)行大部分系統(tǒng)驗證。設計輸入是一組最初源自用戶要求的規(guī)范，其目標是設備的預期用途應作為一組要求進行說明。反過來，設計輸出是設備制造商定義的一組程序，以確保完成的工作與相應的設計輸入相符。這實質(zhì)上要求這兩個里程碑之間的可追溯性。

圖1

傳統(tǒng)上，開發(fā)過程包括作為設計輸入的一組正式或半正式的文字處理器文檔和一些模型，這些模型反映了構建系統(tǒng)所依據(jù)的一組規(guī)范。該輸入被轉(zhuǎn)換為設計輸出中提到的一組預先披露的可交付成果。因此，在系統(tǒng)軟件的情況下，設計輸出可能包括屬于應用程序的源代碼列表。目標是披露設備的預期用途并確保已實施規(guī)范并滿足設計目標。

驗證設計

設計輸入和輸出里程碑是醫(yī)療器械開發(fā)過程的組成部分，適用于大量器械；因此，他們沒有具體說明應該使用哪些方法進行圖 1 中概述的流程中所示的驗證。設備制造商為此使用了一系列工具和流程，但大多數(shù)依賴于文本需求文檔和源代碼列表，如設計輸入和輸出。圖 1 包括一個設計驗證步驟，其中根據(jù)設計輸入驗證設計輸出。

驗證系統(tǒng)

由于大多數(shù)團隊將源代碼視為系統(tǒng)實現(xiàn)的最終衡量標準，因此在實際設備上運行完整的源代碼經(jīng)常表明設備的預期用途。這是一種以源為中心的方法，因為通過執(zhí)行為真實設備編譯的應用程序代碼來進行驗證。

驗證系統(tǒng)的傳統(tǒng)方法雖然有效，但成本高且容易出錯。在目標設備上對不斷發(fā)展的系統(tǒng)進行單元測試的任務可能既繁瑣又緩慢。可能無法在不產(chǎn)生大量費用或后勤障礙（例如硬件不完整或不存在）的情況下使機器通過所有預期的使用場景，這可能會妨礙設備的最終測試。不完整的平臺可能會為測試的應用程序呈現(xiàn)錯誤的結果。

由于在單元測試期間發(fā)現(xiàn)了軟件和系統(tǒng)錯誤并得到糾正，它們相關的設計和要求可能需要更新以反映更改的源代碼。根據(jù)應用程序的大小，這可能會變得耗時且容易出錯，因為可能會遺漏一些更改，從而導致 DHF 與實際實施的系統(tǒng)不匹配。

使用自動化工具的新方法

設計控制和 QSR 不需要實際運行的醫(yī)療設備作為系統(tǒng)驗證和確認的基礎。就 FDA 而言，只需證明收集的數(shù)據(jù)作為設備預期用途的證明就足夠了。該數(shù)據(jù)可以從實際設備以及模擬執(zhí)行中收集該設備的自動化應用程序開發(fā)工具提供了無與倫比的效率增益。圖 2 展示了一個以確認和驗證為中心的過程。與前面描述的 FDA 流程一樣，該流程取決于基于設計輸入的設計輸出的迭代開發(fā)。圖 2 還將需求追溯至系統(tǒng)驗證，而架構和設計活動則追溯至系統(tǒng)驗證。顯示的所有步驟都是通過建模工具提供的需求可追溯性和可執(zhí)行模型功能自動執(zhí)行的。

圖 2

自動驗證和驗證的示例

在模型驅(qū)動的過程中，應用程序的架構和設計都是在建模工具中進行的。此外，設計工具可以從設計模型中自動生成單元測試用例，如圖 3 所示。在這里，設計和測試用例的模型都是可執(zhí)行的。第一個目標是驗證底層設計，然后測試設計，描繪設備的實際使用場景。大多數(shù)缺陷和設計疏忽都在此模型驗證階段被發(fā)現(xiàn)。單元測試可以使設計通過任何可能的場景，其中許多可能難以在實際設備上創(chuàng)建。在接下來的示例中，測試可以顯示系統(tǒng)在患者在監(jiān)測他或她的血氧水平的過程中沒有表現(xiàn)出可檢測到的脈搏這種不太可能發(fā)生的情況下的行為。

圖 3

檢測到的缺陷和疏忽會在設計中立即得到糾正，從而無需手動更改代碼和設計文檔。這與傳統(tǒng)開發(fā)形成鮮明對比，傳統(tǒng)開發(fā)是在真實設備上執(zhí)行源代碼后修復源代碼內(nèi)部的缺陷。這發(fā)生在開發(fā)過程的后期，因此系統(tǒng)調(diào)試比模型驅(qū)動方法慢得多。

圖 4 中的示例說明了用于通過指夾傳感器測量血氧水平和脈率的血氧監(jiān)測儀的設計。該設計顯示了一個狀態(tài)機，負責對包含血氧水平 （SpO2） 和脈率的傳感器數(shù)據(jù)進行解包。通過注入真實或模擬的傳感器數(shù)據(jù)，圖中所示的狀態(tài)機可以快速驗證正確的操作。此外，圖 4 中的測試案例驗證了脈搏率和氧氣水平都在安全范圍內(nèi)。該測試用例與設計驗證一起運行，以確保在難以創(chuàng)建的不可預見或復雜事件期間患者的安全。

圖 4

此外，可以使用自動化需求管理工具，以便在設計組件（例如圖 4 中所示的狀態(tài)機）和需求之間建立可追溯性。

最后，對于系統(tǒng)驗證，測試用例被追蹤到系統(tǒng)的操作要求。這是通過正式需求管理工具和建模環(huán)境之間的需求可追溯性功能實現(xiàn)的自動化。換句話說，可以建立一個完全自動化的驗證和驗證過程。

開發(fā)工具

Telelogic 提供生命周期開發(fā)工具（如圖 3 所示），涵蓋 QSR 要求的整個系統(tǒng)驗證和驗證領域。DOORS 需求管理工具用作創(chuàng)建設計輸入的基礎，系統(tǒng)需求和驗證測試都在 DOORS 內(nèi)部作為結構化和可跟蹤的對象集進行管理。

根據(jù)正在開發(fā)的醫(yī)療設備的性質(zhì)，兩種不同的工具可提供建模解決方案。對于通常使用單板嵌入式計算機和實時操作系統(tǒng) （RTOS） 的傳統(tǒng)獨立醫(yī)療設備，Telelogic 的 Rhapsody 提供系統(tǒng)架構和設計支持以及自動源代碼生成。Rhapsody 能夠支持開箱即用的主要 RTOS 平臺。它還提供了目標托管協(xié)同仿真的附加功能，當需要目標級驗證時，這在驗證和驗證過程中被證明是有價值的。

Telelogic TAU 可用于使用多個平臺或嵌入式和桌面系統(tǒng)的任意組合的復雜醫(yī)療設備。這可能包括計算機斷層掃描 （CT） 掃描儀等設備或攜帶一系列相關平臺的其他系統(tǒng)，包括無頭運行傳統(tǒng)操作系統(tǒng)（如 Linux、UNIX 或 Windows）的臺式計算機和監(jiān)控工作站。TAU 支持獨立于語言和操作系統(tǒng)的建模，并且可以使用多種編程語言在任意平臺上部署相同的模型。這被描述為平臺無關建模 （PIM），其中一組模型可以在許多不同或未定義的平臺上使用。因此，PIM 的概念為提高生產(chǎn)力增加了另一個維度，允許在未來幾代未知平臺中使用設計的組件。

自動化開發(fā)過程生成的文檔提供了源自需求管理和建模活動的集成書面記錄。這篇論文是由 Telelogic 的 DocExpress 自動創(chuàng)建的，它可以查看本示例中使用的所有 Telelogic 工具。DocExpress 自動創(chuàng)建包含來自所用工具的文本和圖表的文字處理器頁面，并且完全由用戶配置。

更好、更便宜的開發(fā)過程

在設計醫(yī)療設備時，F(xiàn)DA QSR 規(guī)定的設計指南和法規(guī)可以與系統(tǒng)和軟件開發(fā)中的最佳實踐同時解決。這不僅降低了開發(fā)成本，還促進了 QSR 規(guī)定的驗證和驗證過程，從而使醫(yī)療設備更可靠，現(xiàn)場故障的可能性更小。此外，這還為 DHF 提供了實時內(nèi)容，這些內(nèi)容是自動管理和制作的。Telelogic 的生命周期管理解決方案集旨在通過使用需求管理、系統(tǒng)和軟件建模以及自動化的、基于模型的測試工具（包括 DOORS、Rhapsody、TAU 和 DocExpress）來自動化開發(fā)過程。

審核編輯：郭婷