醫(yī)療設備安全軟件的10項前提

　　B. 它們可提供用以保存安全案例證據(jù)鏈的架構?；仡櫺缘厣砂踩咐强赡艿模前嘿F，而且一定會需要重新生成曾存在于項目開發(fā)過程中那些未被保留的證據(jù)。

　　4、明確的要求

　　安全指標必須闡明可靠性的程度，以及達到這些程度的限制條件。

　　FDA已經(jīng)認識到“展示設計和生產(chǎn)常規(guī)的間接流程數(shù)據(jù)的合理性 ”不足以表明軟件的安全性， “注重于展示特定產(chǎn)品設備安全性的設備保證措施”也必不可少。這種展示包含于安全案例中，也反映了上述論題，即優(yōu)質流程的目的不是保證優(yōu)質產(chǎn)品，而是提供用以評估證據(jù)的環(huán)境。

　　每一個安全案例主要都會提出類似“這一系統(tǒng)將在條件C下，以可靠性B的水平，來操作A，如果不能做A，它會轉移到概率為P的設計安全狀態(tài)下”這樣的聲明。這一聲明及其相應的注意事項都會被列在系統(tǒng)安全手冊中，以便用于系統(tǒng)更高層次的安全案例中。

　　一個系統(tǒng)的可靠性是指其持續(xù)且 及時準確回應各種情況的能力：是可用性（及時響應要求的頻率）和可靠性（這些響應的正確率）的結合。

　　安全案例聲明系統(tǒng)的可靠性指標，提供達標的證據(jù)?？煽啃灾笜说木窒扌院椭笜吮旧硪粯又匾?。例如，一個醫(yī)療成像系統(tǒng)可以滿足IEC 61508 SIL3要求，實現(xiàn)不超過8小時的持續(xù)工作，8小時后系統(tǒng)必須重置（更新）。由于成像過程通常是短暫的，所以這一限制不會造成不便，哪怕這個系統(tǒng)一天要用 24小時。

　　5、系統(tǒng)失效

　　沒有哪個系統(tǒng)對漏洞免疫，特別是Heisenbugs— 那些“曇花一現(xiàn)”，而當我們尋找它們的時候又“消失無蹤”的神秘漏洞， ；失效狀況終究會發(fā)生：我們要建立的系統(tǒng)必須能夠恢復常態(tài)或進入其設計安全狀態(tài)。

　　表1 缺陷、錯誤和故障分析表

　　既然所有的系統(tǒng)都將包含缺陷，而缺陷可能導致故障，一個安全系統(tǒng)就必須包含多道防線：

　　安全關鍵型流程的獨立——找出哪些部件有安全關鍵性，設計時務必保證其不受其它零部件的影響。

　　防止缺陷演變?yōu)殄e誤——盡管理想的解決途徑是識別并消除代碼故障，但是實際上很難做到。要小心Heisenbug，保證軟件的設計能夠發(fā)現(xiàn)和封閉缺陷，以免它們演變成錯誤。

　　防止錯誤演變?yōu)楣收稀鄬τ谲浖碚f，諸如復制和多樣化這樣的技術更適用于硬件，然而謹慎使用依然能夠奏效。

　　故障檢測和恢復——在許多系統(tǒng)中，轉移到預定義的設計安全狀態(tài)，并將恢復任務留給更高層次的系統(tǒng)（比如人）是可行的。有些系統(tǒng)則不能如此操作，所以系統(tǒng)必須恢復或重啟。一般而言，在不明確環(huán)境中企圖恢復，不如選擇帶有快速復原的crash-only模式。

6、驗證

　　測試不足以證明可靠性；需要其他方法來補充：形式化設計、統(tǒng)計分析和回顧性設計驗證等。