風險預警系統

（二）設計燈號顯示系統

預警系統可採取類似交通管制信號燈的燈號顯示法。因本系統有五個預警區間，故可設計五燈顯示系統，即“藍燈”、“綠燈”、“黃燈”、“橙燈”、“紅燈”五種標識進行單項預警。針對不同的預警區間，燈號顯示所表現的警情也會有所不同（見表1）。

綜上所述，企業風險預警系統是一項非常複雜的系統項目，涉及因素眾多，可以運用的方法較多。文章對預警系統的基本構架進行了探討，以期為企業構建風險預警系統提供借鑒。而對於採用或考慮該風險管理方式的企業所涉及的組織變革、系統實現方式等還需作進一步研究。

近年來，隨著我國鐵路的發展，原有的以落實安全生產責任製為核心的傳統安全管理模式已經不能完全滿足現代化鐵路安全的需求。加速推進先進科學的安全風險管理模式，加強安全風險預控管理與既有安全管理的有機融合，最大程度地降低安全風險，勢在必行。鐵路行業在推行安全風險管理工作方面取得了初步成效。2012年原鐵道部下發了《關於深化鐵路安全風險管理的指導意見》，從2013年起，要實施以安全風險管理為主線的工作思路。中國鐵路總公司（以下簡稱“總公司”）各專業部門、各鐵路局相繼發布了相關安全風險管理辦法；部分鐵路局建立了安全風險資料庫，通過辨識主要安全風險，進一步明確各項風險的控制措施；還有部分鐵路局制訂了專業系統安全風險的指導手冊、安全風險控制表和崗位風險控制卡等，把安全管理前移，起到了積極的作用。但是，鑒於安全風險管理在鐵路行業實行時間尚短，在安全風險管理及控制方面仍然存在一些問題，主要表現在以下方面。

（1）缺乏統一的安全風險管理平台。目前各個鐵路局自行建設安全風險管理系統；甚至在一個鐵路局內，各專業自行建設安全風險管控系統。從總公司層面上，缺乏一個統一的安全風險管理平台，導致“信息孤島”產生及處理方式各異，不利於標準化建設。

（2）安全風險管理信息不完整。大量的安全檢查信息、安全風險管控信息都保存於各個鐵路局或站段，總公司的安全監督管理部門無法實時獲取到各類安全風險的管控情況，更無法根據歷史數據為管理工作提供決策支持，導致管理成本增加。

（3）安全風險控制方法不夠完善。對主要安全風險的辨識、安全性評價、安全風險管控措施的制訂等缺乏統一的標準；對於典型安全風險治理案例，沒有建立起有效的安全風險字典庫。

為解決鐵路行業中存在的上述安全風險管理問題，提高安全風險管理水平，有必要建立總公司和鐵路局2級統一的鐵路安全風險預警系統（以下簡稱“風險預警系統”）。

1、系統需求

系統的主要服務對象為總公司、鐵路局2級安全監察部門的安全監督管理人員，同時包括各級領導和安全相關的業務部門管理人員。

（1）總公司用戶：實時查詢全路的風險庫數據、風險監測相關綜合信息，主要包括安全監察報告、事故認定書、事故調查報告等事故調查處理信息，安全檢查信息單、安全監察通知、領導添乘、下現場寫實報告、安全考核、安全會議等安全檢查信息，各運輸相關專業系統的安全監測系統提報的報警及對報警處置的信息等。此外，用戶還需實時查詢各個鐵路局的安全狀態評價信息，根據實際情況給各鐵路局發送安全監察通知書、安全監察指令書、安全監督檢查表揚書、安全預警通知書。

（2）鐵路局用戶：實時查詢本局範圍內的風險庫數據、風險監測相關綜合信息；實時查詢本局範圍內的安全狀態評價信息；對總公司下發的“四書”進行整改落實和反饋。

2、系統框架

鐵路安全風險預警系統按照總公司級和鐵路局級分別部署。總公司級的風險預警系統服務對象為總公司用戶；鐵路局級系統分別部署於18個鐵路局，服務於鐵路局用戶。兩級系統之間通過Web服務進行數據交換。鐵路安全風險預警系統的邏輯結構由上至下依次為核心業務層、應用中間件層、數據資源層和支撐平台建設層。

（1）核心業務層。主要包括風險庫管理、風險監測、風險預警、“四書”管理和系統維護等功能。風險庫管理是風險監測和風險預警的數據採集及評價計算的依據。風險監測功能是在風險庫的基礎上採集風險數據，所採集到的數據經過風險預警子系統計算后得出評價結果。“四書”管理功能則依據風險預警功能的評價結論進行風險管控。

（2）應用中間件層。主要包括集成框架、工作流引擎、報表引擎、基於Web Service的數據傳輸、評價模型和圖形工具等組件，這些組件的運用為實現核心業務層提供技術支撐。

（3）數據資源層。主要管理的對象是數據，包括公用基礎數據、安全檢查數據、交通事故數據、風險監測數據、風險評價數據和統計分析數據等。這些數據必須統一規劃存儲，並且要建立安全機制和控制規範。

（4）支撐平台層。主要包括操作系統軟體、資料庫平台、網路平台等硬體設施。

3徠、系統功能

（1）風險庫管理。風險預警系統資料庫包含風險因素庫和風險事故庫，是安全風險數據採集、監測、預警和分析的基礎。風險因素是指引起或增加風險事故發生的機會或擴大損失幅度的條件，是風險事故發生的潛在原因；風險事故是造成生命財產損失的偶發事件，是造成損失的直接的或外在的原因，是損失的媒介。風險庫管理主要負責對風險因素和風險事故字典進行維護，包括錄入、修改、刪除、歸檔等。

（2）風險監測。基於鐵路已經發生的行車、人身和路外事故、設備故障及日常檢查信息，監測並記錄安全風險所發生的頻率、導致損害的嚴重程度等情況，進而對風險進行評價和統計分析，並進行風險的關聯規律分析。此外，還對事故原因、發生單位、性質和事故等級等方面進行分析。

（3）風險預警。包括對風險因素和風險事故作出突出預警、同比預警和環比預警。依據時間序列等演演算法對風險事故進行預測，當預測值超過設定閥值時進行預警提示。基於事故件數、設備故障件數、安全檢查問題情況和半年評估名次，對全路各鐵路局和專業進行安全狀態評價等。

（4）“四書”管理。基於風險預警的評價結果，向被預警鐵路局發送“四書”，並對“四書”進行審核、查詢和統計。

（5）系統維護。包括用戶基本信息、用戶角色和功能許可權等的設置，以及車站、線路、組織機構等基礎數據的維護。

1、工作流技術

在系統運行過程中，信息需要在多個單位之間進行流轉；而不同種類的信息採集處理流程也會有一定的差異。以“四書”管理為例，其核心業務流程為：總公司用戶檢查鐵路局安全管理工作，發現安全問題后填寫安全通知書/指令書，並下發至鐵路局；鐵路局根據總公司的處理要求開展後續安全管理工作，填寫針對通知書/指令書的整改措施並反饋至總公司。總公司查看反饋情況並對已處理完成的通知書/指令書進行銷號處理。為適應不同處理流程之間的差異性要求，系統設計和開發中應用了工作流技術。根據工作流管理聯盟（WFMC）的定義，工作流是一類能夠完全或部分自動執行的過程，根據一系列過程規則，文檔、信息或任務能夠在不同的執行者之間進行傳遞與執行。工作流技術把應用邏輯和過程邏輯分開，不修改具體功能實現而只修改配置模型就能達到改變系統功能的目的，從而實現對業務流程部分或全部過程的有效管理。工作流具有多人協同完成、工作傳遞、多節點組成及狀態變化等特點。基於工作流實現上述“四書”管理業務流程的過程如下。

（1）首先需要為該業務流程定義角色，如“總公司發書人”“鐵路局接收人”。

（2）定義業務流程的節點。①發書；②整改並回復；③銷號。

（3）定義每個節點的角色及該節點對應的功能。①發書由“總公司發書人”角色操作，操作內容包括錄入“四書”的編號、內容、整改要求、接收單位等信息；②其操作完畢之後，流程進入下個節點“整改並回復”，該節點由“鐵路局接收人”角色操作，操作內容包括錄入“四書”的具體整改情況、整改時間等信息；③“銷號”節點由“總公司發書人”角色操作，其收到“鐵路局接收人”的反饋信息后，錄入銷號意見，流程結束。通過擴展上述流程的節點、角色，定義節點功能、節點與角色之間的關係，可以把“四書”的務流程進行靈活的擴展。此外，工作流實現的過程中還需要記錄過程追蹤及日誌信息，以保證流轉的可追溯性及信息流轉過程中狀態信息的計算準確性。

2、基於 Web Service 的數據傳輸

風險預警系統按照總公司和鐵路局2級部署，因而2級系統之間需要進行大量的業務數據傳輸與同步。Web Service基於簡單對象訪問協議（SOAP），數據交換格式為可擴展標記語言（XML），在數據傳輸方面具有高封裝性、標準性、松耦合及高度集約等優勢，適合用於解決總公司與鐵路局之間的數據傳輸問題。系統基於Web Service設計了一個數據傳輸組件。需要發起數據傳輸的一端對應圖中的客戶端，比如需要從總公司向鐵路局傳輸數據，則此時總公司即為數據傳輸的客戶端，鐵路局對應服務端。客戶端主要提供參數解析、循環調用、回調通知和日誌記錄等功能模塊，其中循環調用模塊按照設定時間間隔，依據時間順序和權重依次調用服務端的Web服務來傳輸數據，如果遇到網路情況不良或其他因素導致的調用失敗，客戶端將保留本次調用信息並在下個調用時間點重複調用，直到成功為止。服務端主要包括安全性驗證、參數解析、Web服務和日誌記錄等模塊。

3、風險評價

風險矩陣體現了風險的可能性與嚴重程度的關係，是用于衡量危害事件安全風險是否可以接受的尺度。風險預警系統採用風險矩陣法定量計算風險因素的風險值。參照國家標準《軌道交通可靠性、可用性、可維修性和安全性規範及示例》（GB/T 21562—2008）中對風險水平的要求，風險水平定義為3個等級：①高風險，即不可接受的風險，需要進一步控制危害，在極端情況下終止行動；②中風險，即進一步分析后決定是否需要整改，該風險水平通常被認為是可以容忍的，但應該進一步降低風險；③低風險，可以被忽略，但應該持續監測。