系統安全
系統安全的概念是以識別、分析危害為基礎的风险管理策略，並且以系統為基礎來進行補救控制的方法[1]。系統安全和傳統的安全策略不同，傳統安全策略是以類似流行病学分析為基礎，或是以針對過往事件的調查為基礎，避免出現會造成意外的條件及發生原因[2]。當機率性風險分析資料不易取得時，系統安全的概念有助於分析現有技術是否已經足夠[3]。其背後的原理是協同效應：整體的效果大於所有元件效果的總和。對於安全的系統化方法需要應用科學、技術及管理技巧，在系統（或是專案、軟體、活動或是產品）的整個生命週期。進行危害識別、危害分析、並且消除、控制或是管理危害[1]。危害與可操作性分析（HAZOP）就是一種危害識別的方法。
系統化方法 编辑
系統可定義為一組互相作用、相關連、或是彼此相依的元件，為了達成共同的目的而整合成的整體[4][5]。此定義強調為了在工作環境中達成任務，系統中元件的交互作用，或是外在環境和系統的交互作用。強調交互作用是為了確認系統中預期或是非預期的需求，以及為了達到此一需求，是否有必須而且充足的資源。這些會以壓力的形式出現。壓力可能是預期的，是正常運作條件的一部份，也可能是非預期的，一些非預期的動作或是事件造成了額外（異常的）壓力。上述對系統的定義，不只是指產品或是制程，也包括周圍環境（包括人員的操作及互動）對產品或是制程安全性能的影響。相對的，系統安全也要考慮系統對周圍環境的影響。因此正確的定義介面及管理介面就格外地重要[4][5]。關於系統較廣的定義包括硬體、軟體、人員系統整合、程序及訓練。因此系統安全是系統工程中的一部份，必需系統性的處理工程以及操作中的所有層面以及領域，以協調的方式來預防、消除或是控制危害。
在系統化的進行危害識別、危害分析及控制時，系統可能會有明確的範圍定義，不過可能也會有隱含的範圍定義。系統可能複雜到有太空人的太空船，也可能是自動的機械工具。系統安全的概念可以讓系統設計者針對危害進行建模、分析，有危害意識、瞭解並且消除危害，應用控制工具達到可接受的安全程度。有關安全事務的無效决策是有關事故因果關係的瑞士奶酪理论中，危險事件因果的第一步[6]。在修正風險認知上，有關系統風險的溝通扮演重要的角色，可以透過創造、分析及瞭解相關資訊模型，來顯示那些因素創造及控制了有危害的程序[3]。對於絕大多數的系統、產品及服務，最有效降低產品責任及意外風險的方式是建構組織化的系統安全機能，系統安全從概念階段開始，經過開發、製造、測試、生產、使用一直到最後的最終處置為止。系統安全概念目的是確保系統及相關機能的行為是安全的，也可以安全的運作。這樣的確認有其必要性。過去的科技進步帶來了不少正面影響，不過也有其負面影響[1]。
根本原因分析 编辑
根本原因分析（Root cause analysis）可以識別可能會造成問題的一些因素。根本原因分析法原來源自其他領域，現在也用在系統安全的主題中，最廣為人知的是本來是工程技術的故障樹分析[7]。根本原因分析技術可以分為兩類，一些是樹分析法，另一類則是檢查表法。有許多根本原因分析技術，例如管理疏忽与危险树（Management Oversight and Risk Tree、MORT）分析[2][8][9]，其他方法包括事件和意外事故因素分析（Event and Causal Factor Analysis、ECFA）、多重線性事件序列（Multilinear Events Sequencing）、事件時間排序圖（Sequentially Timed Events Plotting Procedure）及萨瓦那河电厂（Savannah River Plant）的Root Cause Analysis System等[7]。
在其他領域的應用 编辑
安全工程 编辑
安全工程描述在核能及其也產業中使用的安全方法。傳統的安全工程技術著重在人为错误的結果，沒有探討人为错误發生的原因或是理由系統安全可以用應用在這些領域中，找出系統安全運作的條件組合。像軍事或是NASA使用的先進系統，配合電腦應用程式及控制，這類的系統需要機能性的危害分析，並訂定一組針對各層面的具體規範，說明在設計中需要加入的固有安全特性。相關的有系統安全程序計劃、初步危害分析、機能危害評估及系統安全評估，在這些程序中的目的是產生以證據為基礎的文件系統，不但讓安全系統可以通過認證，也在一但有訴訟發生時可以佐證。系統安全計劃、危害分析及安全評估的主要重點是形成一個全面性的過程，可以有系統的預測或是識別可能會造成危險或潛在事故的安全關鍵系統失效條件、故障條件或是人為失誤，以及這方面的運作特點。這可以用來調整控制策略及安全屬性相關的需求，有安全設計特性或是安全設備來預防、消除或是控制（緩解）安全風險。
在非常早期時，針對很簡單的系統，只會關注其危害。但是隨著1970年代及1980年代技術及複雜性的提昇，已利用整體性的方式發展了更先進，更有效率的方法。現代的系統安全是全面性的、以風險為基礎、以需求為基礎、以機能為基礎，其結構化的目標是獲得工程上的實證，驗證在預期的操作環境下，安全機能是確定性的，風險也是在可接受的範圍。指揮，控制和監控安全關鍵系統的軟體密集系統需要有廣泛的軟體安全分析，來調整細部的設計需求，特別是很少人為介入或是不需人為介入的自動化系統或是機器人系統。由不同系統組成的系統，例如現代的太空船或是戰艦，其中包括了許多的零件及系統，也有多重整合、感測器融合、網路及互操作系統，需要各供應商及設備商之間的大量合作和協調，使系統的安全是其中重要的特性。
武器系統安全 编辑
武器系統若失效或是誤動作，其可能的破壞影響很大，因此武器系統安全是系統安全領域中重要的應用。不論是在需求定義階段或是繪圖階段，都要用健康而懷疑的態度來看待系統，透過導入機能性的危害分析，有助於學習會產生危害的因素，並且來緩解這些造成危害的因素。嚴謹的流程一般會是系統工程的一部份，目的是要調整設備，在錯誤及故障影響系統防衛能力或是發生意外之前，可以提昇系統的狀態[1][2][3][4]。
一般而言，輪船、車輛、导弹及航空器的武器系統有不同的危害及破壞影響，有些是武器的固有特性，例如爆炸，也有些是特殊操作環境下會有的（例如飛機在飛行狀態下）。在軍用飛機產業中，會透過經證實的危害分析過程，來識別安全關鍵機能、徹底分析硬體、軟體及人員系統整合的整體設計架構、衍生並且指定明確的安全需求，目的是確保基本機能仍維持有效，而且機能是以預期的方式正常運作。進行全面性的危害分析，確認會造成危害的可信故障（credible faults）、故障條件、影響因素及因果因素，都是系統工程程序的重要內容。必須衍生、開發、實現明確的安全需求，並且用客觀的安全例證，以及可表示尽职调查的充份安全文件來以加驗證。若是高度複雜的軟體密集系統，又有複雜的交互作用會影響安全關鍵的機能，更需要密集的計劃、特殊的專業知識、使用分析工具、精確的模型、先進的方法及經驗證的技術。以预防事故是目标。
參考資料 编辑
- ^ 1.0 1.1 1.2 1.3 Harold E. Roland; Brian Moriarty. System Safety Engineering and Management. John Wiley & Sons. 1990 [2018-12-19]. ISBN 0471618160. （原始内容存档于2019-12-08）.
- ^ 2.0 2.1 2.2 Jens Rasmussen, Annelise M. Pejtersen, L.P.Goodstein. Cognitive Systems Engineering. John Wiley & Sons. 1994 [2018-12-19]. ISBN 0471011983. （原始内容存档于2019-12-08）.
- ^ 3.0 3.1 3.2 Baruch Fischhoff. Risk Perception and Communication Unplugged : Twenty Years of Process. Risk Analysis, Vol 15, No.2. 1995.
- ^ 4.0 4.1 4.2 Alexander Kossiakoff; William N.Sweet. System Engineering Principles and Practice. John Wiley & Sons. 2003 [2018-12-19]. ISBN 0471234435. （原始内容存档于2019-12-08）.
- ^ 5.0 5.1 Charles S. Wasson. System analysis, design and development. John Wiley & Sons. 2006 [2018-12-19]. ISBN 0471393339. （原始内容存档于2019-12-08）.
- ^ James Reason. Human Error. Ashgate. 1990 [2018-12-19]. ISBN 1840141042. （原始内容存档于2019-12-08）.
- ^ 7.0 7.1 UK Health & Safety Executive. Contract Research Report 321, Root Cause Analysis, Literature review. UK HMSO. 2001. ISBN 0 717619664.
- ^ The Management Oversight and Risk Tree (MORT). International Crisis Management Association. [1 October 2014]. （原始内容存档于27 September 2014）.
- ^ Entry for MORT on the FAA Human Factors Workbench （页面存档备份，存于互联网档案馆）