（二）设计灯号显示系统

预警系统可采取类似交通管制信号灯的灯号显示法。因本系统有五个预警区间，故可设计五灯显示系统，即“蓝灯”、“绿灯”、“黄灯”、“橙灯”、“红灯”五种标识进行单项预警。针对不同的预警区间，灯号显示所表现的警情也会有所不同（见表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个等级：①高风险，即不可接受的风险，需要进一步控制危害，在极端情况下终止行动；②中风险，即进一步分析后决定是否需要整改，该风险水平通常被认为是可以容忍的，但应该进一步降低风险；③低风险，可以被忽略，但应该持续监测。