河南省瑞光印務股份有限公司提供 使用動態(tài)軟件分析為醫(yī)療設備通過審批提供支持 包含軟件系統(tǒng)的醫(yī)療設備與構(gòu)建復雜系統(tǒng)一樣，制造商面臨著相同的挑戰(zhàn)：時間、質(zhì)量、規(guī)模（功能的數(shù)量和復雜性）和成本。此外，產(chǎn)品還

河南省瑞光印務股份有限公司提供 使用動態(tài)軟件分析為醫(yī)療設備通過審批提供支持 包含軟件系統(tǒng)的醫(yī)療設備與構(gòu)建復雜系統(tǒng)一樣，制造商面臨著相同的挑戰(zhàn)：時間、質(zhì)量、規(guī)模（功能的數(shù)量和復雜性）和成本。此外，產(chǎn)品還需通過當?shù)乇O(jiān)管部門的審批，如美國食品及藥品管理局（FDA ）、歐盟醫(yī)療器械指令司（MDD ）、英國藥監(jiān)局（MHRA ）以及其他同類監(jiān)管機構(gòu)。

在本文中我們將探討動態(tài)代碼分析如何幫助醫(yī)療設備展示安全合規(guī)性以及動態(tài)分析工具所應具備的關(guān)鍵功能。為了幫助設計人員選擇操作系統(tǒng)（OS ），文章還簡要介紹了OS 的哪些特性可以推動安全相關(guān)軟件加速設計、開發(fā)和審批流程等。

專業(yè)知識和流程

專業(yè)知識和良好的開發(fā)流程并不能確保系統(tǒng)符合所需滿足的可靠性，甚至不能確保它是一個好系統(tǒng)。但是這兩者的確能極大提高這種可能性。

創(chuàng)造安全關(guān)鍵系統(tǒng)所要求的簡潔設計需要卓越的專業(yè)知識。要證明被測試的軟件系統(tǒng)符合安全要求，需要對軟件驗證方法、被評估的軟件以及評估環(huán)境（包括類似系統(tǒng)的驗證）有全面透徹的了解。

毫無疑問，IEC62304標準專注于開發(fā)流程。理解這點，我們的工作將會做得更好，不僅僅是在滿足最嚴苛質(zhì)量管理標準的環(huán)境下進行軟件開發(fā)，同時還使用工具來幫助確保我們的系統(tǒng)符合這些標準，并向?qū)徲媶T和監(jiān)管機構(gòu)提供證據(jù)加以證明。

展示可靠性

為了確保通過監(jiān)管機構(gòu)的審批，制造商必須證明這些設備滿足安全規(guī)格。對于設備軟件來說，要證明他們符合可信任（可靠性和可用性）標準的要求。具體是滿足可靠性還是可用性方面的要求，則要取決于系統(tǒng)的使用情況。詳細的要求限制和精確的可信性要求提供了既定的前提和精準的方法，幫助我們驗證軟件系統(tǒng)的可信性。

定義可接受風險

河南省瑞光印務股份有限公司提供

沒有任何軟件系統(tǒng)是絕對可靠的。即使系統(tǒng)絕對可靠，我們也無法證明它?，F(xiàn)有可用的方法無法證明系統(tǒng)將永不失效，他們僅能幫助我們找到并避免錯誤的發(fā)生，并估計失效的可能性。因此，當軟件系統(tǒng)的故障率足夠低，沒有不可接受的風險，它就是“安全”的?！安豢山邮茱L險”或“可接受風險”的精確含義因行業(yè)及行政轄區(qū)而異。衡量方法包括：

? ALARP （As Low as Reasonably Practical，最低合理可行）：將潛在的危害和相關(guān)的風險定義和分類為：a ）明確不可接受，b ）如果移除成本過高，則可以容忍，以及c ）可接受。所有不可接受風險必須被移除，但是僅當移除成本和時間較為合理時，可容忍風險才會被移除。

? GAMAB （globalement au moins aussi bon ）或GAME （（globalement au moins équivalent ）：新系統(tǒng)的風險水平至少要與現(xiàn)有系統(tǒng)的風險水平大體相當。

? MEM （Minimum Endogenous Mortality）：在新系統(tǒng)部署的領(lǐng)域，它帶來的死亡率不能超過該地區(qū)常規(guī)死亡率的十分之一。舉例來說，在西方國家年齡為20多歲的人群，這個值約為0.0002。

所有這些方法都需要按實際情況調(diào)整，主要取決于設備的嚴重故障可能同步影響到的人數(shù)。當使用ALARP 方法時，為了確定哪些風險不可接受、哪些可容忍以及可接受，我們需要決定每個風險的嚴重故障所允許的最大失敗可能性。而如果使用GAMAB 和MEM 準則，我們則需要在全球范圍確定這個數(shù)值。

證明軟件可靠性的方法

目前，沒有任何一種單一的方法足以證明軟件系統(tǒng)滿足可靠性方面的要求。因此，我們的可靠性演示必須使用整合了各種方法和技巧，它們包括但不限于：

? 符合IEC 62304及其他同類標準要求的開發(fā)環(huán)境

? 要求跟蹤矩陣，確保所有安全相關(guān)的要求都已得到滿足

? 正規(guī)的設計方法和工具，可以為設計的正確性提供數(shù)學依據(jù)

? 使用貝葉斯置信網(wǎng)絡方法的故障樹分析

? 回顧性設計驗證，基于已完成的工作來評估系統(tǒng)設計

? 靜態(tài)分析，使用模型檢測或者數(shù)據(jù)流分析等方法

? 使用直接故障檢測技術(shù)進行測試，如動態(tài)分析，通過產(chǎn)生的誤差和失效來識別故障

河南省瑞光印務股份有限公司提供

圖1 IEC 62304標準涉及的不同分析方法和相關(guān)章節(jié)，表現(xiàn)為典型的“V ”字形發(fā)展模型。圖中顯示的每一種方法都不依賴于進程。任何其他開發(fā)進程模型都可用類似的表述：瀑布式、迭代的、靈敏的等

IEC 62304

IEC 62304 已成為醫(yī)療設備軟件的生命周期過程必須遵循的全球統(tǒng)一標準。FDA 推動了它的發(fā)展，而且該標準正與歐盟標準93/42 EWG（MDD ）逐步取得一致。

與圖1顯示的其它標準一樣，IEC 62304是基于IEC 61508標準，根據(jù)現(xiàn)有的行業(yè)特定實踐補充而來。舉例來說，IEC 62304與ISO 26262不同，甚至與IEC 61508本身也不同， 它未定義可接受故障率（安全完整性等級SIL 的一個評定）的常見數(shù)值。相反，它根據(jù)故障可能對病人、操作員或其他人員造成的傷害程度規(guī)定了安全等級。這些等級與FDA 的醫(yī)療設備等級類似，即：不會損害健康、可能輕微損害健康和可能嚴重損害健康甚至導致死亡。

在大多數(shù)情況下，從IEC 61508演化而來的標準與其類似，因為他們都確實規(guī)定了軟件生命周期的流程（包括風險管理過程）、活動和任務，并指出該周期不應隨著產(chǎn)品的發(fā)布而結(jié)束，只要軟件還在運行，這個流程就必須貫穿于產(chǎn)品維護和問題解決的全過程。因此，不管他們?nèi)绾味x可接受和不可接受風險，IEC 62304、IEC 61508和其它類似的標準提供了證實系統(tǒng)符合安全要求必須使用的指導和方法。

河南省瑞光印務股份有限公司提供

圖2 IEC 62304標準從IEC 61508標準演化而來，因此與其它行業(yè)標準一樣，有同樣的起源。要注意的是，IEC 62304清楚說明了它并不依賴于IEC 61508，但是可參考IEC 61508的工具和方法

動態(tài)分析

動態(tài)分析用于檢驗編譯源代碼的執(zhí)行情況，可以整體檢驗，也可以分開進行。由于動態(tài)分析執(zhí)行代碼，它不僅測試源代碼，也測試編譯器、鏈接器、開發(fā)環(huán)境，甚至有可能是目標硬件。通常來說，動態(tài)分析包括結(jié)構(gòu)（代碼）覆蓋分析和單元測試，這兩者的結(jié)合不僅可以提供非常有效的檢測軟件故障的方法，還可以為證明執(zhí)行了哪些軟件以及如何執(zhí)行提供證據(jù)。

結(jié)構(gòu)覆蓋分析是航空行業(yè)標準DO-178B/C的基礎(chǔ)。航空事故往往較為重大和悲慘，因此新聞報道往往比醫(yī)療設備事故報道頻繁，而航空業(yè)也有一個安全記錄模范。從前一里到下一里，航空是最安全的交通工具之一。

結(jié)構(gòu)覆蓋分析

動態(tài)分析工具使用介入式探針或非介入式探針。介入式探針系統(tǒng)將軟件探針（計數(shù)或程序呼叫）放置在即將被分析的代碼里（高級語言或者匯編器）。這些探針會記錄流程執(zhí)行的相關(guān)信息，并生成執(zhí)行歷史。

介入式探針和非介入式探針

使用介入式探針時，證明探針不會改變測量代碼的功能對于分析的有效性非常重要。除了證明介入式探針不會影響源代碼，這樣的演示通常還要求探針本身不會帶入可能導致編譯器出現(xiàn)漏洞的事物。這可以通過使用Compiler Validation Suite（一套源代碼，用于證明編譯器履行正確的計算功能）來展示編譯器的有效性并未受到加載進程的影響。

河南省瑞光印務股份有限公司提供

非介入式探針系統(tǒng)擁有與介入式探針系統(tǒng)一樣或類似的信息，但直接來自于處理器，并且動態(tài)分析工具會將這個低層信息連接至原始表示方法（高層語言或者匯編器）。但是，出于各種原因（比如編譯器優(yōu)化的影響），不能總是明確地建立這種聯(lián)系。

請注意，與所有測試一樣，在一個復雜的軟件系統(tǒng)，我們同樣無法證明結(jié)構(gòu)覆蓋分析所用的探針絕對不會影響代碼表現(xiàn)。舉例來說，從定義上看，Heisenbugs 為不可再現(xiàn)的錯誤，通常被認為由微妙的時間條件導致，他們可能會因代碼的任何改變而校正（甚至是帶入），包括加載檢測探針。

圖3 LDRA 代碼覆蓋工具的截圖，彩色的圖形信息清晰說明了未被執(zhí)行的代碼

可靠性判斷的證明

關(guān)鍵不是為了證明故障不存在（不可能性），而是為了收集證據(jù)，供我們用于軟件可靠性判斷。特別是如果我們的系統(tǒng)使用SOUP （第三方的軟件），結(jié)構(gòu)覆蓋分析可以幫助證明系統(tǒng)沒有未使用的或者多余的代碼。

單元測試

單元測試驗證小單元，使得觀察到不正確的表現(xiàn)更為簡易，以便檢測故障。在單元測試里，程序或程序串都獨立于完整的系統(tǒng)進行隔離測試，以確定他們滿足特定的要求。

通常情況下，這些要求比項目的要求更加全面，因此，舉例來說，可以對界面條件進行測試：對一個像素為750 x 1000的顯示的著色測試可能需要針對像素為1200 x 1600的顯示進行。

河南省瑞光印務股份有限公司提供

每一個程序的界面都進行輸入值測試，這可能被更高級程序排除在外，來探索普遍性——該程序的表現(xiàn)一直符合要求。

單元測試使得測試通常無法觸及的內(nèi)務代碼成為可能，保護性代碼元件可以同樣被測試。一些偶然糾錯的情況可以被移除；舉例說，在較大型的系統(tǒng)中，可能引入了一個不必要的程序，或者與之相反，并讓觀察者以為一切正常。因為我們處理的是較小的元件，就較為容易觀察到不正確的行為，并檢測錯誤。

如何處理被測試的單元內(nèi)的子程序取決于測試的目標。傳統(tǒng)上，單元測試會引入一個從細節(jié)到總體的測試戰(zhàn)略（有時候被稱為模塊或者集成測試）。在這樣的方法里，首先對單元進行測試，接著再將其與其他單元整合測試。在這樣的測試中子程序并不包括在測試里，它們可以被“存根”取代。

圖4 在整個系統(tǒng)或某個子系統(tǒng)進行結(jié)構(gòu)覆蓋測試提供極大的靈活性

當與結(jié)構(gòu)覆蓋分析相結(jié)合，在測試里可以隨意添加呼叫樹的數(shù)量的靈活性可以幫助系統(tǒng)符合最嚴格的質(zhì)量和認證機構(gòu)的覆蓋要求。

結(jié)構(gòu)覆蓋標準

在驗證任何系統(tǒng)時，其中一個最艱難的步驟是決定何時停止測試。該決定需要考慮系統(tǒng)可靠性要求，并最終取決于IEC 62304以及監(jiān)管機構(gòu)對于醫(yī)療設備的安全規(guī)章。

河南省瑞光印務股份有限公司提供

覆蓋標準可以幫助衡量動態(tài)測試已經(jīng)實現(xiàn)的成果，也可以用于測量剩余需要完成的測試工作。這些標準包括：

? 語句覆蓋：最基礎(chǔ)的標準，由被測試系統(tǒng)的語句部分組成。

? 分支/判定覆蓋：覆蓋的控制流分支部分。平均而言，每一個語句和程序呼叫被執(zhí)行的次數(shù)是單獨語句覆蓋的兩倍。

? LCSAJ 覆蓋：路徑相關(guān)的標準，LCSAJ （線性代碼順序和跳轉(zhuǎn)）覆蓋比分支/判定覆蓋要求更高，并且在應用的大多數(shù)關(guān)鍵領(lǐng)域都可使用。市場上較復雜的工具會包含此功能。 ? 修正條件/判定覆蓋：在一個程序中每一種輸入輸出至少要出現(xiàn)一次，在程序中的每一個條件必須產(chǎn)生所有可能的輸出結(jié)果至少一次，并且每一個判定中的每一個條件必須能夠獨立影響一個判定的輸出，則完全的MC/DC覆蓋已經(jīng)達到。

軟件分析工具的選擇

所有軟件工具提供商都非常希望售出自己的產(chǎn)品，因此極少有廠商會主動介紹他們的工具無法實現(xiàn)的功能。下面是評估軟件分析工具時的一些注意要點：

錯誤報告

? 該工具是否會產(chǎn)生很多假陽性報告？也就是說，它是否會報告其實并不存在的故障？ ? 該工具是否會產(chǎn)生假陰性報告？也就是說，它沒有及時報告其實存在的故障？ 項目兼容性

? 該工具在生成有益的信息時是否需要很長時間？工具運行所需要的時間通常并不是問題，但仍是一個考慮因素，因為如果耗時過長，則會成為項目實施的障礙。

? 該工具是否支持項目的語言？很多編譯器執(zhí)行自己的語言版本，并在該版本下分析代碼。因此，確保分析工具支持項目所用的語言就非常重要。

? 該工具是否可以立即整合至開發(fā)進程？如果需要不相稱的努力來將工具集成到項目，則其作用不大。

功能和局限性

? 該工具是否可在整個系統(tǒng)工作？這是一個非常重要的問題，因為僅當對整個系統(tǒng)進行分析時，有些故障才能被檢測到。

? 該工具是否可以適應跨程序循環(huán)？即使是在單一隊列，如果僅當另一程序被分析時，某個程序才能被完全分析，跨程序循環(huán)也極為重要。

河南省瑞光印務股份有限公司提供

? 該工具的局限性有哪些？所有的工具都有局限性，包括所能分析的代碼數(shù)量，所能處理的模塊深度，所允許的嵌套深度以及表格規(guī)格。這些局限性及其對項目的影響也需要被注意且考慮在內(nèi)。

總結(jié)

鑒于復雜的軟件系統(tǒng)是很多醫(yī)療設備的核心，這些設備的成功與否與制造商展示軟件系統(tǒng)是否符合可靠性要求的能力有越來越密切的聯(lián)系。如FDA 、MDD 和MHRA 等的監(jiān)管機構(gòu)負責審批整個設備，而不是其中的一部分，證明設備軟件（軟件安全例證）可靠對于整個設備的審批就非常重要。因此，密切關(guān)注設計和開發(fā)實踐，仔細選擇驗證方法以及實施工具，對于任何使用軟件系統(tǒng)的醫(yī)療設備項目的成功都極為重要。

操作系統(tǒng)

不管驗證工具多么優(yōu)秀，歸根結(jié)底它也是設備，它的軟件也需要通過審批。對任何使用軟件的系統(tǒng)而言，芯片以上的任何元件都需要依賴于操作系統(tǒng)（OS ）。這意味著包含軟件的醫(yī)療設備的可靠性取決于其OS ，而該OS 必須有能力支持對于設備安全性提出的要求。在為安全系統(tǒng)選擇OS 時需要注意以下幾個關(guān)鍵要求。

實時擔保

只有實時操作系統(tǒng)（RTOS ）可以確保可靠性所要求的及時反饋，而可靠性對任何安全軟件系統(tǒng)來說都是最基本的。

架構(gòu)

河南省瑞光印務股份有限公司提供

實時執(zhí)行或者宏內(nèi)核操作系統(tǒng)的失效通常要求設備進行重啟，這就使得系統(tǒng)可用性大打折扣。在微內(nèi)核實時操作系統(tǒng)中，應用程序、設備驅(qū)動程序、文件系統(tǒng)和網(wǎng)絡協(xié)議棧都運行在內(nèi)核外部的獨立地址空間，因此它們不僅與內(nèi)核隔離，而且彼此之間也互不影響。一個組件出現(xiàn)故障不會導致整個系統(tǒng)癱瘓。

內(nèi)存保護

OS 架構(gòu)需要將其內(nèi)存里的應用和關(guān)鍵進程分開，防止單個故障蔓延至整個系統(tǒng)。

優(yōu)先級繼承

為防止優(yōu)先級反轉(zhuǎn)，RTOS 需要支持將被阻止的高優(yōu)先級任務的優(yōu)先級分配給阻止任務的低優(yōu)先級線程，直至完成被阻止的任務。

分區(qū)

為了確?？捎眯?，RTOS 需要支持固定分區(qū)或者更受青睞的自適應分區(qū)。后者強制執(zhí)行資源預算，但采用一種動態(tài)調(diào)度算法將一個分區(qū)內(nèi)閑置的 CPU 周期重新分配到另一個需要更多處理時間的分區(qū)內(nèi)。

高可用性

一個自啟動的監(jiān)視程序需要監(jiān)控、停止以及在保證安全性的前提下來重啟進程，而不需要系統(tǒng)的復位。如果重啟并不安全，則監(jiān)視程序需要將系統(tǒng)設置在設計安全狀態(tài)。