節能監管服務軟體
軟體可靠性與安全性設計準則
1 範圍 3
1.1主題內容 3
1.1適用範圍 4
2 一般要求 4
3 詳細要求 4
3.1計算機系統設計 4
3.1.1硬體與軟體功能的分配原則 4
3.1.2硬體與軟體可靠性的分配原則 4
3.1.3安全關鍵功能的人工確認 4
3.1.4安全性核心 4
3.1.5自動記錄系統故障 5
3.1.6禁止迴避檢測出的不且安全狀態 5
3.1.7保密性設計 5
3.1.8容錯設計 5
3.1.9 安全關鍵軟體的標識原則 5
3.2軟體需求分析 5
3.3軟體危險分析 5
3.3 安全關鍵功能的設計 6
3.4 介面設計 6
3.4.1硬體介面的軟體設計 6
3.4.2人機介面設計 6
3.4.3報警設計 6
3.4.4軟體介面設計 6
3.5 軟體健壯性設計 7
3.5.1監控定時器的設計 7
3.5.2異常保護設計 7
3.6 簡化設計 7
3.6.1模組的單入口和單出口 7
3.6.2模組的獨立性 7
3.6.3模組的扇入與扇出 8
3.6.4模組的耦合方式 8
3.6.5模組的內聚方式 8
3.7 防錯程式設計 8
3.7.1引數化 8
3.7.2公共資料和公共變數 8
3.7.3標誌 9
3.7.4標誌 9
3.7.5非授權儲存的限制 9
3.7.6無意指令跳轉的處理 9
3.7.7程式檢測點得設定 9
3.8 程式設計要求 9
3.8.1語言要求 9
3.8.2高階語言的限制 10
3.8.3軟體單元規模 10
3.8.4命名要求 10
3.8.5程式格式要求 10
3.8.6程式注釋要求與方法 10
3.8.7程式設計風格 11
4 資料庫設計要求 12
3.9.1資料庫表的建立 12
3.9.2資料庫表的命名 13
3.9.3資料庫程式設計規範 13
3.9.4資料查詢優化 14
本指導內容給出了計算機軟體可靠性和安全性設計的準則和要求
本文主要適用於軟體的需求分析、設計和實現。
開發可靠軟體首先必須採用軟體工程方法，搞好軟體開發工程化。應特別注意以下幾點:
1. 軟體開發規範化。圖形符號、程式構造都應該有一致的約定。
2. 盡可能採用先進、適用的軟體開發工具
3. 加強軟體檢查和測試。應該盡早展開軟體測試，採取措施（如自檢、互檢、專檢相結合的三檢制，制定設計檢查單等）使檢查工作切實有效。
對具有高可靠性和安全性要求的功能應權衡用硬體實現還是用軟體實現的利弊，做出妥善的決策
軟體的可靠性指標應與硬體的可靠性指標大體相當，可根具體情況做出調整，但調整的幅度不易過大
在系統控制迴路中，安全關鍵功能的執行在可能時必須經操作人員確認或啟動。
在關鍵的計算機系統中，應該設計乙個稱為安全性核心的獨立電腦程式，用來監視系統並防止系統進去不安全的狀態。當出現潛在不安全的系統狀態或有可能轉到這種狀態時，它將系統轉移到指定的安全狀態
必須採取措施自動記錄檢測出的所有系統故障及系統運**況。
在系統設計時考慮故障的自動檢測，一旦檢測出不安全的狀態系統應作出正確響應，不得迴避。
系統設計應防止越權或意外的訪問或修改軟體
對可靠性要求很高的系統應同時考慮硬體和軟體的容錯設計，而不能只考慮硬體的容錯設計。
1. 故障檢測的優先順序結構及安全性控制或校正邏輯、處理和響應故障的模組
2. 中斷處理程式、中斷優先順序模式及允許或禁止中中斷的例行程式。
3. 產生對硬體進行自主控制訊號的軟體。
4. 產生直接影響硬體部件運動或啟動安全關鍵功能的型號的軟體。
5. 其輸出是顯示安全關鍵硬體的狀態的軟體。
1. 軟體需求分析必須確保軟體需求規格說明的無歧義性、完整性、可驗證性、一致性、可修改性、可追蹤性和易使用性。
2. 對有可靠性指標的軟體，在確定了軟體的功能性需求之後，應考慮軟體的可靠性指標是否能夠達到以及是否能夠驗證，還應與使用者密切配合，確定軟體使用的功能剖面，並制定軟體可靠性測試計畫。
3. 對安全關鍵軟體，必須列出可能的不期望事件，分析導致這些不期望事件的可能原因，提出相應軟體的處理要求
應在開發的各個階段進行軟體危險分析
1. 安全關鍵功能必須至少受控於兩個獨立的功能
2. 安全關鍵的模組必須與其他模組隔離，安全關鍵的模組必須放在一起，以便對其進行保護。
3. 安全關鍵的模組必須具有強資料型別；不得使用一位的邏輯「0」或「1」來表示「安全」或「危險」的狀態；其判定條件不得依賴於全「0」或全「1」的輸入。
4. 安全關鍵的計時功能必需由計算機控制，使操作人員不能隨意修改。
5. 在啟動安全關鍵功能之前，必需對可測試的安全關鍵的單元進行實時檢測。當檢測到不安全的情況時，軟體必需採取措施對其進行處理；如果軟體無法控制，應保證將控制轉換到硬體的安全子系統。
1. 硬體介面的軟體設計必須考慮檢測外部輸入或輸入的裝置失效，並在發生失效時恢復到某個安全狀態。設計必須考慮所涉及硬體的潛在失效模式。
2. 在設計硬體介面的軟體時，必須預先確定資料傳輸資訊的格式和內容。每次傳輸都必須包含乙個字或字串來指明資料型別及資訊內容。至少使用奇偶校驗與檢測來驗證資料傳輸的正確性。
3. 在硬體介面的軟體設計中必須考慮硬體介面中已知元件的失效模式。
4. 安全關鍵功能應使用專用io埠。
1. 人機互動軟體要便於操作員用單一行為處理當前事務，使系統退出潛在不安全的狀態，並使其恢復到某一安全狀態
2. 啟動安全關鍵功能時，必須由兩個或多個人員在「與」方式下操作。
3. 向操作員提供的顯示資訊、圖示、及其它人機互動方式必須清晰、簡明而且無二義性。
1. 必須向操作員提供聲光報警聲，聲音預警訊號必須超過預期的背景雜訊，同時提供表明軟體正在操作的實時指示。
2. 報警的設計必須事例行報警與安全關鍵的報警相區別，並使得沒有採取糾正行為或沒有執行所要求的後續行為以後完成該操作的情況下，操作員無法清除安全關鍵的報警。
在設計軟體介面時必須確保：
1. 模組的引數個數與模組的接受的變元個數一致。
2. 模組的引數屬性與模組的接受的輸入變元屬性一致。
3. 模組的引數單位與模組的接受的輸入變元的單位一致。
4. 模組的引數次序與模組的接受的輸入變元次序一致。
5. 傳送給被呼叫模組的變元個數與該模組的引數個數相同。
6. 傳送給被呼叫模組的變元屬性與該模組的引數屬性相同。
7. 傳送給被呼叫模組的變元單位與該模組的引數單位相同。
8. 傳送給被呼叫模組的變元次序與該模組的引數次序相同。
9. 呼叫內部函式時，變元的個數、單位、屬性、次序必須一致。
可靠性軟體的選型意見
根據所領導和綜合計畫部的安排，我室對廣五所的carmes 美國relex 以色列的ald和英國的isograph等4種可靠性軟體進行了詳細的論證，報告如下 1 任務 2 選型的主導思想 3 關於技術指標 可靠性軟體是基於標準的，但標準是公開的，統一的，因此各家可靠性軟體公司都會使用同一標準，否則就無...
圖書管理系統安全性可靠性
根據業務管理模式，本系統採用資料集中管理方式作為系統開發的基礎，使用者以學校內部上網方式操作該系統。因此，系統對使用者操作的響應時間將受網路速度的影響。本系統在系統效能方面以使用者可以接受的響應時間為準。1 資料要絕對安全防止有意無意的破壞資料。若資料遭到破壞，系統具有資料恢復功能，不可恢復的資料僅...
地鐵供電系統可靠性和安全性分析方法研究
摘要 隨著地鐵線路的不斷增多，地鐵供電系統複雜程度越來越高，出現事故的可能性和故障波及的範圍 造成的損失也不斷增大。供電系統能否安全可靠執行將直接關係到地鐵的安全 穩定運營，為了保證地鐵安全可靠地執行，其供電系統安全措施是極其有意義的。關鍵詞 地鐵供電系統 可靠性 安全性方法研究 地鐵供電系統是否可...