引供水事故应急预案程序统计综述范文

本站小编为你精心准备了引供水事故应急预案程序统计综述参考范文，愿这些范文能点燃您思维的火花，激发您的写作灵感。欢迎深入阅读并收藏。

对于长距离引供水工程而言，能够预防事故，以及在事故突发时提高其应急救援反应速度和协调水平，增强综合处置能力，保障周围群众的生命安全，最大限度地减少财产损失、环境破坏和社会影响，无疑是工程运行管理工作中的重点需求。传统的事故处理方式在事故发生早期的感知能力薄弱，事故扩大后的处理过程相对依赖于运行管理人员的业务能力，并且在事故后的分析总结中通常局限于本次事故，不利于从全局把握流域的运行规律，难以实现优化事故处理流程以及提出事故预防建议。由此，本文探讨了基于面向服务和工作流机制的引供水工程自动化事故应急预案系统，并以历史应急预案处理信息作为输入，基于数理统计模型的事故应急预案流程自优化和事故预警，实现对管理运行单位的事故处理和预防的决策支持［1］。

1面向服务的测量系统集成实际运行实践中，引供水工程一般配有雨情水情测报系统、工程安全监测系统以及闸门、油机控制系统等，以支撑工程的正常管理和运行。但是，这些专业测量系统一般是相互独立的，数据和控制难以共享；而在各种事故发生的早期，可能需要多方面的实测数据进行综合判断分析，才能更为精确地定位事故原因和部位，因此，对于各专业测量系统的数据集成和控制集成，就显得必须和重要了［2］。通过面向服务的方式、最优的实现方法和各个专业测量系统的交互，使之成为自动化应急预案系统的数据与报警信息来源，实现“少人值班”（无人值守）下的事故早期预警，对于抢险减灾无疑具有十分重要的意义。

1．1面向服务架构面向服务的体系结构提供了一种方法，通过这种方法，可以构建分布式系统来将应用程序功能作为服务提供给终端用户应用程序或其他服务，其组成元素可分为功能元素和服务质量元素。服务是粗粒度的处理单元，它使用和产生由值传送的对象集。它与编程语言术语中的对象不同。相反，它可能更接近于业务事务的概念而不是远程公共对象请求体系结构（CORBA）的概念［3］。服务通常实现为粗粒度的可发现软件实体，它作为单个实例存在，并且通过松散耦合的基于消息通信模型来与应用程序和其他服务交互。服务是由一些组件组成的，这些组件一起工作，共同提供服务所请求的业务功能。因此，相比之下，服务比组件的粒度更粗［4］。使用面向服务的架构具有可以利用现有的资产、更易于集成和管理复杂性、具有更快的响应和上市速度以及减少成本和增加重用［5］等优点。

1．2与自动化测量系统的集成通过统一的通信协议和参数，本系统可在线获取专业测量系统的测量数据，加以分析评判。如果评判结果存疑，则可通过召测进行验证，验证的结果将作为是否启动事故预案的依据。通过对雨情水情测报系统、工程安全检测系统以及闸门油机控制系统等主功能模块进行符合WebService规范统一接口的包装，本系统即可在线通过超文本传输协议（HTTP）查询各家系统测量仪器的实时数据，实现对其数据集成和控制集成。基于可扩展置标语言（XML）的服务调用参数，具有保持接口稳定、内容可灵活扩展等优点。以此为基础，本系统通过全局唯一的标识字符串来标记每个自动化测量设备仪器，实现与自动化测量系统之间的数据识别和数据召测。

2事故预案定制与执行实际生产实践中，各种事故对应的应急处理预案内容千差万别。另外，每种预案流程也不是一成不变的，会随着运行管理工作的持续而不断动态更新。因此，本文给出了基于微软公司的Windowsworkflowfoundation（WWF）框架顺序工作流模型的、可在运行中动态创建和修改工作流模板的事故应急预案系统原型。

2．1WWF技术WWF是微软公司的基于Windows平台的工作流开发解决方案，是．NETFramework3．0及更高版本的组成部分，同时也是一个广泛通用、从底层至顶层均可良好扩展的工作流框架。它提供了工作流呈现引擎、应用程序和服务可信通信与执行引擎。它是可声明、可视化的，且工作内容和工作时间相对分隔，允许改变工作流模型（工作时间），而不影响工作內容。它还可将业务逻辑实现为一组独立且可测试的组件装配到工作流中。此外，WWF提供了持久化工作流实例的结构查询语言（SQL）workflowpersistenceservice服务；提供追踪保存在数据库中的工作流实例运行时信息的SQLTrackingService服务［6］。

2．1．1WWF开发组件在基于VisualStudio2008的WWF开发环境中，新建一个Windowsworkflow程序，然后可以从工具箱中拖放工作流组件。工具箱中的内容如附录A图A1所示。

2．1．2WWF命名空间在明确了预案基本组成元素后，通过对WWF框架中的顺序活动、分支活动、并行活动、循环活动和子预案调用活动进行业务包装，形成事故处理流程相关的可视化流程组件，然后通过WWF中的工作量呈现引擎workflowview控件，即可实现所见即所得的运行期预案流程定制。

2．3预案的执行一般而言，在引供水工程运行管理实践中，普遍采用自动化系统监测与人工巡查相结合的模式。基于这种模式，事故被发现并激活应急预案的渠道包含自动化专业测量系统报送的告警信息和巡查人员发现的险情2种可能性。因此，本系统提供2种预案触发机制：自动化系统报送的消息启动预案和值班人员手工启动方案。预案触发执行顺序见图1。

2．3．1自动化系统告警消息触发本系统初始化时，将各家系统的各个监测量的测量项目，通过一组逻辑运算表达式，关联至定制好的预案模板。当运行中监测量发生告警时，告警信息首先会被传入逻辑运算表达式组进行评判，如果满足条件，则将监测量关联的预案模板装载入WWF工作流执行引擎，这样预案就被正式启动。

2．3．2管理人员手工触发如果管理人员巡视中直接发现了某种事故，则可以在系统界面上双击对应的预案模板，并同时输入事故信息，这样也就生成一个预案执行实例，进入事故抢险流程。

3预案优化和预警模型随着引供水工程运行管理工作的持续进行，可以在事故应急预案处理信息累积的基础上，运行统计方法对每个事故预案流程、全局事故发生规律进行初步分析，提出合理的优化建议，实现对管理者的决策辅助。预案优化以经济效益和社会效益为中心，以事故预防和事故处理的决策辅助为出发点，将历史事故处理信息作为输入，根据若干评估指标，运用数理统计方法，得出单个预案流程的优化建议和流域整体事故的预警提示。

3．1评估指标目前本系统在一次事故预案执行完后的评估指标暂定如下。1）执行时间：是一组值，包含预案每个步骤及整体执行时间。本组值由系统在事后自动统计出。2）灾害损失：是一组值，包括因为停止供水造成的供水收益损失、关闸造成的发电收益损失、洪水淹没造成的经济损失等。本组值由专业人员评估出险情造成的损失后输入。3）抢险物资损耗：是一组值，包含直接物资损耗、人力损耗、协作单位人力物力损耗等。本组值由专业人员评估出险情造成的损失后输入。

3．2单个预案迭代优化本系统可以生成同一个预案的所有历史执行明细，并通过上述指标，分析出抢险最耗时的步骤，即预案流程的时间瓶颈所在；同时，结合历次抢险执行指标，按照时间权重递减的顺序，向用户生成关键步骤分析报告、优化流程和实际操作流程，以减少损失。同样的统计方法可以用于步骤时间和所耗物资量的分析，以减少物资损耗。

3．3流域全局预警根据流域全局预案执行情况，统计出流域最常出现的险情种类、险情最易发地段、险情最易发时间、损失最大险情等信息，生成报告给运管人员，以提醒其做好预防，实现决策辅助支持的功能。

4系统原型

4．1开发环境本系统原型的开发环境为微软公司的VisualStudio2008集成开发环境、．NetFramework3．5框架和SQLServer2000数据库。

4．2系统原型

4．2．1系统资源配置首先，必须要配置各家专业测量系统中的监测量，以实现接收自动化系统告警从而获得事故的早期感知。监测量的配置界面如图2所示。其次，需要配置评判告警信息的逻辑表达式，并绑定相应的预案。这样，当接收到告警消息后，若经过评判符合标准，就可加载对应的预案模板执行。评判表达式和预案绑定界面如图3所示。最后，需要定制各种事故对应的应急预案模板。预案模板一经定制完成，就可被重复触发生成运行实例，以实际推动和指导事故的应急抢险。某引供水工程水位骤升预案定制的界面如图4所示。

4．2．2预案执行和报告生成以某引供水系统的某次渠道堵塞事故演练为例，模拟人工巡视时发现险情，则立刻启动渠道堵塞事故应急预案。预案执行完成后，可通过回放功能查看预案实例流程的执行情况。预案实例执行呈现效果如图5所示。图中带阴影的图标表示该步骤执行成功。该流程的执行说明如下：当水位骤升时，首先通知当地运行管理科和中心的工程管理处领导，然后分别告知上下游的其他管理处，通知本地运行管理科人员监视水位变化，通知本管理处调集抢险物资进行抢险；最后，管理处领导在抢险完成后进行抢险完成确认，本工作流实例执行结束。预案执行流程完成后，系统自动生成的执行过程文档如附录B图B1所示。

5结语

本文围绕长距离引供水系统中极为关注的事故预防与事故处置能力提高的问题，介绍了基于服务和工作量机制的自动化事故应急预案系统，以取代传统的依赖人员业务能力和规章制度熟悉程度的处理模式；提出了基于数理统计的事故预案处理流程的优化策略，实现事故处理经验的不断累积和优化，为运行管理者在实际的生产实践中提供科学的决策辅助支持。下一步工作，除了要继续实现和完善现有功能模块外，重点在于研究引入数据挖掘、数据建模算法和工具，进一步尝试挖掘潜在的流域运行规律，为运行管理者提供更好的经济和社会效益。