挑戰(zhàn)：

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

在設(shè)計歷史文件 （DHF） 中維護(hù)適當(dāng)?shù)奈臋n

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

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

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

傳統(tǒng)方法

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

設(shè)計輸入輸出

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

圖1

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

驗證設(shè)計

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

驗證系統(tǒng)

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

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

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

使用自動化工具的新方法

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

圖 2

自動驗證和驗證的示例

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

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

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

圖 4

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

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

開發(fā)工具

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

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

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

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

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

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

審核編輯：郭婷