Transcript 第十七章
關鍵系統規格 ©Ian Sommerville 2000 Dependable systems specification Slide 1 功能性和非功能性需求 系統的功能性需求可以用來定義錯誤查核與復 原機制及與功能，以提供對系統發生故障的保 護措施。 非功能性需求可以用來定義系統必需的可靠度 (reliability)和可用性(availability)。 ©Ian Sommerville 2000 Dependable systems specification Slide 2 系統可靠度規格 硬體可靠度(Hardware reliability) • 軟體可靠度(Software reliability) • 硬體元件故障的可能性以及修復該元件所需的時間。 軟體元件產生不正確輸出的可能性。軟體故障不同於硬體故障 ，軟體不會用太久而損壞。在產生不正確的結果之後，它還是 能夠繼續正常地操作。 操作員可靠度(Operator reliability) • 系統操作員製造錯誤的可能性。 ©Ian Sommerville 2000 Dependable systems specification Slide 3 系統可靠度工程 它是系統工程中的一個子領域，專門研究系統 可靠度的評估。 它必須考慮到系統中各種不同元件的故障率。 • 例如，某個系統有兩個元件A和B，A的故障率為P(A)，B的 故障率為P(B)。 ©Ian Sommerville 2000 Dependable systems specification Slide 4 故障機率 如果系統只有這兩個元件，而且系統的操作也 依賴這兩個元件，那麼系統的故障機率為: • P(S) = P(A) + P(B) 元件數量越多，系統整體故障機率也會越高。 如果是一群相同的複製元件，整體故障率為: • P(S) = P(A)n (所有元件都發生故障) ©Ian Sommerville 2000 Dependable systems specification Slide 5 功能性的可靠度需求 系統必須預先定義操作員可能輸入的所有輸入 值範圍，系統也應該檢查操作員的所有輸入是 否符合預先定義的範圍。 做為初始化程序的一部分，系統應該檢查所有 磁碟是否有壞掉的區塊。 系統應該使用N版的程式設計來實作煞車控制 系統。 系統必須以Ada的安全子集來實作，並且使用 靜態分析方式做檢查。 ©Ian Sommerville 2000 Dependable systems specification Slide 6 非功能性的可靠度規格 系統可靠度需求的程度應該量化表示。 可靠度是一個動態的系統屬性，所以若以原始 碼來定義可靠度規格是沒有意義的。 • 軟體的錯誤應該在每1000行中不超過N個錯誤。 • 非功能性的可靠度規格只有在產品完成後的分析時才有用， 通常會用來評估你的開發技術有多好。 整體的系統可靠度必須選擇適合的可靠度度量 指標(reliability metric)。 ©Ian Sommerville 2000 Dependable systems specification Slide 7 可靠度度量指標(量測值) 可靠度度量指標是測量系統可靠度的單位。 系統可靠度是以計算操作的故障次數來衡量， 而這些都與對系統的要求以及系統上線運作的 時間有關。 關鍵系統的可靠度必須以長期的測量程式來測 量。 ©Ian Sommerville 2000 Dependable systems specification Slide 8 可靠度度量指標 量測值 說明 POFOD 服務故障率 當使用者提出服務要求時，系統失敗而無法提供服務的可 能性。若POFOD為0.001，表示一千個服務要求中可能會 有一次發生故障。 ROCOF 出錯率 非預期行為可能發生的頻率，若ROCOF為2/100，表示每 100個操作時間單位內可能會有2次的故障發生。這個量測 值有時候稱為故障強度。 MTTF 平均故障時間 系統發生故障的平均時間。若MTTF為500，表示每500個 時間單位可以預期的會出現一次故障。 AVAIL 可用率 系統在某個給定時間可否使用的機率。若可用率為0.998， 表示每1000個時間單位內，系統可以使用的時間有998個 時間單位。 ©Ian Sommerville 2000 Dependable systems specification Slide 9 可用率(Availability) 系統在某段時間可否使用的比率 必須考慮修復與重新啟動的時間 可用率0.998表示每1000個時間單位內，系統 可以使用的時間有998個單位 常用於不停機、連續運作的系統 • 電話交換系統、鐵路號誌系統 ©Ian Sommerville 2000 Dependable systems specification Slide 10 服務故障率(POFOD) 系統無法提供使用者提出之服務要求的可能性 。這個度量指標在服務要求為間歇性，且不常 發生的情況下最有用。 適合用在偶爾有服務要求，且若無法提供服務 則會造成嚴重後果的系統保護上。 適合許多具例外管理元件的安全關鍵系統。 • 例如，化工廠的緊急關機系統 ©Ian Sommerville 2000 Dependable systems specification Slide 11 出錯率(ROCOF) 系統發生故障的機率。 若ROCOF為0.002，表示每100個操作時間單位 內可能會有2次的故障發生，例如每1000小時 操作時間中發生2次故障。 適合需要處理大量且經常發生類似要求的作業 系統或異動處理系統。 • 例如，信用卡處理系統、機票預訂系統 ©Ian Sommerville 2000 Dependable systems specification Slide 12 平均故障時間(MTTF) 每個故障發生之間的間隔時間。在一個穩定的 系統中這個度量指標與服務故障率(ROCOF)成 反比。 若MTTF為500，表示每500個時間單位內故障 與故障之間的平均時間。 適合應用於具有長時間異動的系統，也就是需 要花很長時間處理的系統。MTTF應該會比異 動時間更長。 • 例如，設計師需要花費數小時使用的電腦輔助設計系統以 及文書處理系統。 ©Ian Sommerville 2000 Dependable systems specification Slide 13 故障的後果 可靠度的量測並沒有考慮故障的後果。 暫時的故障不會有真正的結果，但是其他的故 障可能會引起資料的流失或損壞以及喪失系統 的服務功能。 可能需要識別出不同的故障類別，並且使用不 同的度量指標來識別。同時也必須建立可靠度 的規格。 ©Ian Sommerville 2000 Dependable systems specification Slide 14 故障的後果 在規定可靠度時不只要看系統發生的故障次數 ，而且要看這些故障造成的後果。 有嚴重後果的故障比可修復和復原的故障有更 大的損害。 因而，在某些情況下必須為不同的故障類型定 義不同的可靠度規格。 ©Ian Sommerville 2000 Dependable systems specification Slide 15 故障類型 故障類型 說明 暫時(Transient) 只有在輸入某些值時才會發生 永久(Permanent) 所有輸入值均會發生 可復原(Recoverable) 不用操作人員介入系統可以自行復原 不可復原(Unrecoverable) 需要由操作人員介入才能從故障中復原 無毀損(Non-corrupting) 故障不會毀損系統狀態或資料 毀損(Corrupting) 故障會毀損系統狀態或資料 ©Ian Sommerville 2000 Dependable systems specification Slide 16 建立可靠度規格的步驟 針對每個子系統分析可能故障的後果。 將系統故障分析的結果做適當的分類。 對每一種故障類別使用適當的可靠度度量指標 定出它的可靠度。對於不同的可靠度需求也可 以使用不同的度量指標。 找出功能性的可靠度需求以降低關鍵故障的機 會。 ©Ian Sommerville 2000 Dependable systems specification Slide 17 銀行自動櫃員機系統 網路上的每部機器每天大約使用300次 銀行有1000部這樣的機器 軟體的壽命為兩年 每部機器大約可以處理200,000筆交易 每天大約有300,000筆資料庫交易要處理 ©Ian Sommerville 2000 Dependable systems specification Slide 18 可靠度規格的範例 故障類別 範例 可靠度量測值 永久、無毀損 系統無法處理輸入的任何卡，軟 體必須重新啟動才能修正這個故 障。 ROCOF 1次/1000天 暫時、無毀損 輸入沒有受損的卡片，但是系統 無法讀取卡片上的磁帶資料。 ROCOF 1000次交易中出現1次 暫時、毀損 某種跨網路的交易模式造成資料 庫的毀損 不合格的！系統的壽命 期限內不應該發生 ©Ian Sommerville 2000 Dependable systems specification Slide 19 規格確認 極高的可靠度規格不可能憑使用經驗來確認。 不能有資料庫的損毀表示POFOD在2億個交易 中必須小於1 。 如果每筆交易需花一秒，那麼模擬網路上一天 的交易量大約要花3.5天。 因此，若要測試系統的可靠度可能必須花比系 統壽命更長的時間。 ©Ian Sommerville 2000 Dependable systems specification Slide 20 重點整理 可信賴度需求分為功能性和非功能性兩種。 非功能性的可用率和可靠度需求必須以量化來 表示。 可以使用的度量指標有AVAIL、 POFOD 、 ROCOF 和 MTTF。 在制定可靠度規格時，不同錯誤類型所產生的 後果也必須列入考慮。 ©Ian Sommerville 2000 Dependable systems specification Slide 21 安全規格 系統的安全需求必須分開規定。 這些需求應該以可能的危險和風險分析為基 礎。 安全需求通常應用於整體系統而不是個別的 子系統。在系統工程名詞中，系統的安全性 是一個突顯的性質。 ©Ian Sommerville 2000 Dependable systems specification Slide 22 安全生命週期 ©Ian Sommerville 2000 Dependable systems specification Slide 23 安全程序 危險和風險分析(Hazard and risk analysis) • 安全需求規格(Safety requirements specification) • 規定一套應用於系統的安全需求 安全關鍵系統的指定(Designation of safetycritical systems) • 評估和系統有關的損壞危險和風險 找出不正確操作會危及系統安全的子系統。在理想壯況下 ，這些子系統應該只佔整個系統的一小部分。 安全確認(Safety validation) • 檢查整體的系統安全 ©Ian Sommerville 2000 Dependable systems specification Slide 24 危險和風險分析 ©Ian Sommerville 2000 Dependable systems specification Slide 25 危險和風險分析 找出會發生並危及系統安全的危險，以及評估 與這些危險有關的風險。 建立不同類別的危險分析，並且徹底執行規格 到實作的軟體程序。 對每個識別出的危險都應該執行風險分析並加 以記錄，並且採取必要動作以確保最嚴重與可 能發生的危險不會造成意外。 ©Ian Sommerville 2000 Dependable systems specification Slide 26 危險分析程序 危險識別(Hazard identification) • 風險分析和危險分類(Risk analysis and hazard classification) • 評估和每個危險有關的風險 危險分解(Hazard decomposition) • 找出可能出現的危險 分解危險以找出它們可能的根本原因 降低風險的評估(Risk reduction assessment) • 定義設計系統時如何將每一個危險列入考慮 ©Ian Sommerville 2000 Dependable systems specification Slide 27 故障樹分析 危險分析的方法是從一個識別出來的故障開始 追溯錯誤的原因。 它可以用在危險分析的各個階段，從初步的分 析到詳細的軟體檢查階段均可。 屬由由上而下的危險分析方法。它也可以和由 下而上的分析方法併用，由下而上的方法是從 系統故障開始尋找危險的地方。 ©Ian Sommerville 2000 Dependable systems specification Slide 28 故障樹分析 找出危險。 找出危險可能的原因。通常有一些其他原因。 在故障樹上使用「or」和「and」來連結這些 原因。 繼續分析直到找出根本原因為止。 下列的例子是有關一些正在進行備份處理的系 統，可能發生資料流失的情形。 ©Ian Sommerville 2000 Dependable systems specification Slide 29 故障樹 Data deleted or or or External attack H/W failure S/W failure or Operator failure or or Backup system failure or or UI design fault or Incorrect operator input or Training fault ©Ian Sommerville 2000 Operating system failure or Incorrect configuration or Human error or Timing fault Dependable systems specification Execution failure or Algorithm fault or Data fault Slide 30 風險評估 評估危險的嚴重性、危險的可能性以及意外事 故的可能性。 風險評估的結果是一份可接受度敘述，分為： • • • 無法忍受(Intolerable)：必須永不發生或造成意外事故。 盡可能降低危險(As low as reasonably practical, ALARP)：在 給定的成本與時間限制下必須降低危險的可能性。 可接受(Acceptable)：危險的結果是可接受的，而且不需增 加成本來降低危險的可能性。 ©Ian Sommerville 2000 Dependable systems specification Slide 31 風險等級 ©Ian Sommerville 2000 Dependable systems specification Slide 32 風險可接受度 風險可接受度(acceptability)是由人、社會、 政 治等因素所決定。 各個可接受度區域的界線已經漸漸往下移動， 也就是說社會大眾已經較不願意接受風險。 • 例如，清除污染情況的費用可能比安裝污染防治系統更便 宜，但是卻可能不會被社會大眾所接受。 風險評估是主觀的 • 風險的情況是以「可能」、「不可能」來判定，但是這樣 的評估方式會因人而異。 ©Ian Sommerville 2000 Dependable systems specification Slide 33 降低風險 系統應該指定規格，以避免發生危險和意外 事故。 避免危險(Hazard avoidance) • 偵測與移除危險(Hazard detection and removal) • 系統必須設計成在正確的運作期間不會發生危險。 系統必須設計成可以能夠在產生意外事故發生之前偵測並 制止危險。 限制損害程度(Damage limitation) • 系統必須設計成能夠將意外事故的後果降到最低。 ©Ian Sommerville 2000 Dependable systems specification Slide 34 規定禁止的行為 系統不應該允許使用者修改不是他建立的任何 檔案之存取權限。(保全性) 在飛機飛行途中，系統不應該允許操作人員選 擇反轉推進模式。(安全性) 系統不應該允許同時有超過三個警報訊號被啟 動。(安全性) ©Ian Sommerville 2000 Dependable systems specification Slide 35 保全規格 保全需求規格有些和安全需求規格一樣 • • 不可能用量化來規定保全需求 保全需求通常是規定「不應該」而不是「應該」的需求 差異點 • 保全管理的保全壽命期沒有很好的概念定義 • 它面臨的是廣泛的威脅而不是系統特定的危險 • 雖然有成熟的保全技術(例如加密)，但是很難將它們移轉 成通用的情況。 ©Ian Sommerville 2000 Dependable systems specification Slide 36 保全規格制定程序 ©Ian Sommerville 2000 Dependable systems specification Slide 37 保全規格制定階段 資產識別與預估 • 識別資產(資料和程式)與它們需保護的程度。所需保護的程 度依據資產的價值而定，所以一個密碼檔案通常比一堆公開 網頁更有價值。 威脅分析與風險評估 • 識別對保全上可能的威脅，並且預估這些威脅相關的風險。 威脅指定 • 識別出與資產有關的威脅，並且為每項識別出的資產列出一 連串相關的威脅。 ©Ian Sommerville 2000 Dependable systems specification Slide 38 保全規格制定階段 技術分析 • 評估可用的保全技術以及對已識別威脅的適用性。 保全需求規格 • 指定保全需求規格。在適當的時機明確地辨認出可能用來保 護系統免於不同威脅的一些保全技術。 ©Ian Sommerville 2000 Dependable systems specification Slide 39 重點整理 危險分析是安全規格程序中的重要活動。 故障樹分析是一項可以用在危險分析程序中的技 術。 風險分析是評估危險造成意外事件的可能性。它 可以辨識出關鍵性危險，也可以根據危險的嚴重 性對風險做分類。 為了指定保全需求，應該要識別出需要受到保護 的資產，並且定義應該如何使用保全的技術來保 護這些資產。 ©Ian Sommerville 2000 Dependable systems specification Slide 40