除了用于開發嵌入式軟件產品的典型工作流程，如需求收集、分析、系統設計、詳細設計、測試和項目管理，醫療設備行業還有一個額外的挑戰——合規性。

挑戰：

除了用于開發嵌入式軟件產品的典型工作流程，如需求收集、分析、系統設計、詳細設計、測試和項目管理，醫療設備行業還有一個額外的挑戰——合規性。為美國市場開發的產品由美國食品藥品監督管理局 （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 包括一個設計驗證步驟，其中根據設計輸入驗證設計輸出。

驗證系統

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

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

由于在單元測試期間發現了軟件和系統錯誤并得到糾正，它們相關的設計和要求可能需要更新以反映更改的源代碼。根據應用程序的大小，這可能會變得耗時且容易出錯，因為可能會遺漏一些更改，從而導致 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）來自動化開發過程。

審核編輯：郭婷