結構覆蓋標準

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

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

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

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

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

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

　　軟件分析工具的選擇

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

　　錯誤報告

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

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

　　項目兼容性

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

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

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

　　功能和局限性

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

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

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

　　總結

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

　　操作系統

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

　　實時擔保

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

　　架構

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

　　內存保護

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

　　優先級繼承

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

　　分區

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

　　高可用性

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