挑戰(zhàn)：

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

在設(shè)計(jì)歷史文件 （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è)計(jì)規(guī)范 （GDP）

傳統(tǒng)方法

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

設(shè)計(jì)輸入輸出

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

圖1

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

驗(yàn)證設(shè)計(jì)

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

驗(yàn)證系統(tǒng)

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

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

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

使用自動(dòng)化工具的新方法

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

圖 2

自動(dòng)驗(yàn)證和驗(yàn)證的示例

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

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

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

圖 4

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

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

開發(fā)工具

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

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

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

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

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

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

審核編輯：郭婷