醫療設備安全軟件的10項前提

　　B. 它們可提供用以保存安全案例證據鏈的架構。回顧性地生成安全案例是可能的，但是昂貴，而且一定會需要重新生成曾存在于項目開發過程中那些未被保留的證據。

　　4、明確的要求

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

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

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

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

　　安全案例聲明系統的可靠性指標，提供達標的證據。可靠性指標的局限性和指標本身一樣重要。例如，一個醫療成像系統可以滿足IEC 61508 SIL3要求，實現不超過8小時的持續工作，8小時后系統必須重置（更新）。由于成像過程通常是短暫的，所以這一限制不會造成不便，哪怕這個系統一天要用 24小時。

　　5、系統失效

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

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

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

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

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

　　防止錯誤演變為故障——相對于軟件來說，諸如復制和多樣化這樣的技術更適用于硬件，然而謹慎使用依然能夠奏效。

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

6、驗證

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