包含軟件系統的醫療設備與構建復雜系統一樣，制造商面臨著相同的挑戰：時間、質量、規模(功能的數量和復雜性)和成本。此外，產品還需通過當地監管部門的審批，如美國食品及藥品管理局(FDA)、歐盟醫療器械指令司(MDD)、英國藥監局(MHRA)以及其他同類監管機構。

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

　　專業知識和流程

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

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

　　毫無疑問，IEC62304標準專注于開發流程。理解這點，我們的工作將會做得更好，不僅僅是在滿足最嚴苛質量管理標準的環境下進行軟件開發，同時還使用工具來幫助確保我們的系統符合這些標準，并向審計員和監管機構提供證據加以證明。

　　展示可靠性

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

　　定義可接受風險

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

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

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

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

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

　　證明軟件可靠性的方法

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

　　? 符合IEC 62304及其他同類標準要求的開發環境

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

　　? 正規的設計方法和工具，可以為設計的正確性提供數學依據

　　? 使用貝葉斯置信網絡方法的故障樹分析

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

　　? 靜態分析，使用模型檢測或者數據流分析等方法

　　? 使用直接故障檢測技術進行測試，如動態分析，通過產生的誤差和失效來識別故障

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

　　IEC 62304

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

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

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

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

　　動態分析

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

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

　　結構覆蓋分析

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

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

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

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

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

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

　　可靠性判斷的證明

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

　　單元測試

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

　　通常情況下，這些要求比項目的要求更加全面，因此，舉例來說，可以對界面條件進行測試：對一個像素為750 x 1000的顯示的著色測試可能需要針對像素為1200 x 1600的顯示進行。每一個程序的界面都進行輸入值測試，這可能被更高級程序排除在外，來探索普遍性——該程序的表現一直符合要求。

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

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

　　圖4 在整個系統或某個子系統進行結構覆蓋測試提供極大的靈活性

　　當與結構覆蓋分析相結合，在測試里可以隨意添加呼叫樹的數量的靈活性可以幫助系統符合最嚴格的質量和認證機構的覆蓋要求。

　　結構覆蓋標準

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

　　覆蓋標準可以幫助衡量動態測試已經實現的成果，也可以用于測量剩余需要完成的測試工作。這些標準包括：

　　? 語句覆蓋：最基礎的標準，由被測試系統的語句部分組成。

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

　　? LCSAJ覆蓋：路徑相關的標準，LCSAJ(線性代碼順序和跳轉)覆蓋比分支/判定覆蓋要求更高，并且在應用的大多數關鍵領域都可使用。市場上較復雜的工具會包含此功能。

　　? 修正條件/判定覆蓋：在一個程序中每一種輸入輸出至少要出現一次，在程序中的每一個條件必須產生所有可能的輸出結果至少一次，并且每一個判定中的每一個條件必須能夠獨立影響一個判定的輸出，則完全的MC/DC覆蓋已經達到。

　　軟件分析工具的選擇

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

　　錯誤報告

　　? 該工具是否會產生很多假陽性報告?也就是說，它是否會報告其實并不存在的故障?

　　? 該工具是否會產生假陰性報告?也就是說，它沒有及時報告其實存在的故障?

　　項目兼容性

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

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

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

　　功能和局限性

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

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

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

　　總結

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

　　操作系統

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

　　實時擔保

　　只有實時操作系統(RTOS)可以確?？煽啃运蟮募皶r反饋，而可靠性對任何安全軟件系統來說都是最基本的。

　　架構

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

　　內存保護

　　OS架構需要將其內存里的應用和關鍵進程分開，防止單個故障蔓延至整個系統。

　　優先級繼承

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

　　分區

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

　　高可用性

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