应急指挥系统建设思路探讨

　　应急指挥体系是针对自然灾害、事故灾难、公共卫生、社会安全等突发公共事件的抢险救援活动实施组织领导的一个科学、有效、运转良好的组织系统。

　　应急指挥体系通常包括组织体制、运行机制、法制基础、保障系统四个方面。它们是衡量指挥体系整体功能的重要指标，直接影响着系统的正常运行，具有不可替代的作用。应急指挥体系是否能高效发挥作用，是与这四个环节密不可分的，任何一部分的缺失都会影响体系的高效运行。这就犹如围成木桶的木板，水桶的容量是由最短的那块板来决定的。

　　当前我国应急体系从2003年“非典”事件开始建设以来，在上述四个方面从无到有，有了长足发展。本文探讨的是应急体系中最主要的应急保障系统，即通常所描述的应急指挥(IT)系统或应急指挥平台在当前的建设趋势与展望。

　　我国的应急指挥体系

　　在我国政府及各部门行政管理体系结构下，我国的应急指挥是一个庞大的体系，它不仅在国家、省、地市等层面上横向拉通各职能部门并做到上传下达，同时纵向上需要在各专业部门上下级组织之间建立起垂直的专业应急沟通网络，而且两者之间还会有交叉。因此在我国应急指挥从应用建设模型上可以说是目前最复杂的IT系统。

　　图1 我国政府应急指挥体系的纵横经纬

　　为了保证科学有序的建设如此复杂的应急指挥系统，近年来国家发布了一系列相关规范及要求。并把应急指挥系统(平台)做了明确的分类定义：应急指挥场所系统、基础支撑系统与综合应用系统等(每个系统中还有很多分系统子项)，如图2。

　　图2应急指挥系统(平台)构成

　　2003年开始我国各类应急指挥系统(平台)建设方兴未艾，但我们也看到建设的最多的是应急指挥场所系统——指挥中心、应急指挥车等，以及围绕这些场所系统建设的一些IT系统——应急网络、视频会议等。建设的重心在场所上，装修是最好的、大屏也是进口名牌。

　　而近年来，我国各类灾害事故和危害公共安全事件，如地震、冰灾、洪灾、交通、卫生、火灾等事故时有发生，特别是2008年的南方冰雪灾害、“5.12”四川汶川大地震，给我们造成了严重损失。

　　例1：甲型H1N1流感进入中国的时候，应急指挥中心大屏上显示的信息是如此之少，我们应急的沟通方式还是点对点的单一沟通手段。应急平台实战作用偏低，过度依赖传统处置手段(如手机、电话)!系统实效还落后于严峻卫生应急形势要求;

　　例2：汶川地震给中国西部部分地区的网络通信造成了极大破坏。在线缆中断、电力中断、网络拥塞等因素的影响下，运营商位于灾区的互联网和通信链路全部中断。其中，四川省绵阳-梓潼、汶川-都江堰二级干线传输系统受地震影响，2条2.5G、1条155M互联网链路中断。各省到四川长途话务拥塞，部分用户上网困难。汶川G、C两网移动通信全部中断;阿坝地区G、C两网约200个基站瘫痪;由于网络繁忙，成都G、C两网拥塞，短信通信迟缓。此外，甘肃甘南地区4个县通信中断。陕西靠近四川地区约500个基站中断。据了解，在地震发生后，北京、成都指挥决策中心最迫切的需求是把灾难现场的图像传送回来，以便决策人员根据现场状况，下达指令，实施救援。最为宝贵的是开始的几个小时，它关系到救援的及时程度、人民生命财产的保障力度，但是，结果很遗憾……当地基于运营商线路而建立的各级应急指挥系统限于瘫痪!

　　当意外事件发生时，应急指挥系统操作繁琐，信息匮乏，综合应用系统与基础支撑系统脱节;系统易故障，缺乏备份手段;各子系统七国八制，管理维护复杂;平时使用就保障率很低，应急时刻更是不堪使用……早期建设的应急指挥系统在实际使用中暴露出很多问题，不好用甚至不能用，是目前各类应急指挥系统(平台)比较尴尬的现状。更多的时候还是靠传统手段解决问题。

　　有了应急指挥室，有了应急指挥系统，当紧急事件发生的时候却是这样一番景象，问题究竟在那里?核心原因有二：

　　从管理的维度看，是应急指挥专业人员与应急指挥专业管理体系还不够成熟：

　　l u应急体系及人员组织框架刚刚明确或建立，缺乏足够的事件驱动优化完善;

　　l u很多行业应急预案还停留在框架总则等早期阶段，还没有得到具体事件的验证;

　　l u应急工作管理模式与现有的应急系统缺乏磨合;

　　l u应急管理水平及人员专业素质有待提高;

　　从技术的维度看，是应急指挥IT系统的建设思路和方法有问题，没有把握住业务需求的核心。

　　因此在我国应急指挥建设多年后，特别是经历了近年来多个重大事件后，很多政府应急指挥主管领导及技术负责人在很多场合重提应急指挥系统(平台)该如何建设!其实有这样的呼声并不奇怪，因为目前我国还处在应急系统发展早期，在国内出现才短短6年(国外30年，如美国的FEMA)。

　　如何规划建设应急指挥系统(平台)

　　应急指挥要解决的核心问题集中在事件爆发后如何在最短的时间内做出正确而全面的反应!最大的挑战是两个要求的同时实现!——这才是应急事件对应急IT系统要求的本质!因此问题的关键并不在于要有多么高档的场所建设，真正重要的是能够满足应急事件特征的IT系统的建设，包括硬件平台和承载在其上的软件应用。这个本质抓住了，即便不用高档大屏，用一堆液晶屏幕凑到一起也可以很好的实施应急指挥。

　　针对应急的本质特点，应急指挥系统需要具备如下能力：

　　l 早期各类信息汇集、分析能力;

　　l 快速反应能力;

　　l 水平信息整合和共享能力;

　　l 足够的信息汇集和指挥通讯能力;

　　l 系统具有冗余性和可靠性设计;(在具备以上四种能力前提下)

　　根据这些能力要求，我们可以将应急指挥IT系统做进一步拆解，如图3。

　　图3 应急指挥方案构成

　　可以看到，基础支撑系统在应急系统起着承上启下的关键作用，没有它应急指挥中心/指挥车只是一个空壳，应急系统只是一个空中楼阁。在基础支撑系统中，下面三层是硬件部分，核心目标是使得应急相关的信息(包含从下面采集来的信息和从上面下发的指令信息两类)在整个支撑系统中安全、快速、无障碍的流动;而管理中间件的设置则向上屏蔽了下面复杂的硬件细节，对应用层开放一个标准、可编程的业务接口，使得千变万化的应急应用能够有效调用下层的硬件资源，从而在系统层面将应急应用与应急支撑系统融为一体，为应急操作与处置提供最好的支撑。

　　进一步细化，一个理想的应急指挥基础支撑系统架构如图4所示。

　　图4 应急指挥基础支撑系统架构

　　它分四个平面：

　　第一平面 应急采集与通讯

　　包括各类前端信息采集和各类通讯系统的终端，为应急指挥系统早期各类信息足够的汇集能力以及指挥通讯能力提供有力保障。

　　信息采集分为视频图像信息采集和数据库数据采集两大类，根据数据的涉密性，又可以分为内网涉密数据和一般数据。一个完整的信息采集系统就是由分布在前端的各种采集设备和后台的控制管理设备构成的。

　　视频图像信息采集将各类厂家各种平台的视频监控图像做整合，统一接入做资源调度。目前基于IP技术的视频监控方案已经比较成熟，对于应急视频接入这种跨域、跨系统、跨物理距离的需求而言，是最适合的解决方案。前端通过IP编码采集，后端通过IP解码呈现，中间通过IP网络承载，IP存储实现数据存放。整个系统控制管理是基于NGN架构的。

　　而对于数据库数据的采集上收，一直是困扰应急指挥的一个大问题。很多专业业务系统，如GIS、气象云图、车辆/人员GPS跟踪、医疗/手术/显微/影像等，有些是结构化数据，有些是非结构化数据。结构化数据在数据整合方面缺乏统一标准，实施难度大，难以基于数据层面在应急指挥中心做呈现;非结构化数据质量高，传统视频接入不能满足要求。从长期来看，随着应急数据中心的建设以及配套的管理规范实施，将逐步实现与应急相关的信息上收、备份，数据库中间件方式或者存储虚拟化方式都是可以采用的技术方案，但就当前而言，反而可以考虑采用远程呈现(TD，Tele-Display)的方式来解决问题。将结构化数据非结构化，把各类专业业务系统的显示结果实时截取过来呈现在应急指挥中心，大大减少技术复杂度;对于非结构化数据，由于TD设备提供高质量的图像，因此能将气象云图、GIS、医疗手术/显微/影像等高质量呈现在各个指挥中心。

　　数据采集是应急系统运作的基础，当前最佳的实现方式就是基于IP的视频接入和远程呈现配合使用，完成各类数据远程呈现的目标，实现应急决策支撑;而未来的建设目标则应针对结构化数据和非结构化数据均具备完整的远程调取能力。

　　指挥通讯系统则由各种不同的通讯接入手段共同构成，如集群语音、普通语音接入、移动电话、卫星电话、视频会议等，其核心是整合和协同。由于应急事件先天的不确定性，我们无法预测在某个时刻、某个地点采用哪种通讯手段是最适合的。因此应急指挥通讯系统最关键的要求就是互通，而且是设备层面和业务层面均需互通。由此在应急系统中就形成了应急联络中心+各类接入终端的一体化通讯系统的概念。从技术的角度讲，基于IP技术的通讯控制，是最佳实践。

　　数据采集和指挥通讯终端位于整个应急支撑平台的最外围，如同应急系统的手脚，在四个平面中负责着最基础的工作。传统的应急系统建设往往忽视了这个平面的重要性，实际上由于物理分散造成的复杂性，这个平面是最需要系统架构设计和整体规划的。

　　第二平面 应急传输网络

　　包含目前所有的通信手段：城域/广域高质量的有线网络、WiFi/WiMAX/3G三种全新高带宽无线接入、紧急情况下的卫星通讯系统、以及作为应急主要指挥手段的集群系统;主要作用为信息的汇集、水平信息的整合和共享、指挥通讯的平台，有充分冗余及可靠性设计。

　　3G/WiMAX/卫星是应急指挥系统重要的组成部分，作为光纤、电缆等有线通信冗余手段，可以提供适合不同场景、各种带宽、可靠性、各种成本的无线通信链路保障。例如，汶川地震中运营商的网络全部瘫痪，汶川一度成为信息孤岛。通过空投卫星电话和搭建小型卫星基站，灾区通信业务和数据传输的恢复得到保障。而WiMAX系统则适用在油田等对无线带宽要求较高的行业，以及森林防火、岛屿通信等人口分布少、地域跨度广的场所。

　　在有条件的情况下，应急系统应尽可能在专网上运行，且应该采用类似RPR等的链路保护技术;在无法提供专网的情况下，则应尽可能采用专线类的运营链路。卫星链路和无线通讯方式作为有线链路必备的备份传送手段，要尽可能的作用于每一个网络节点。各种不同制式之间的切换与保护也是应急网络平台管理最具挑战性的需求。一句话，应急网络的核心要求就是“高可靠”。

　　第三平面 应急数据中心

　　广义的应急数据中心是所有应急系统业务的物理载体，我们常见的应急指挥大厅其实也是应急数据中心另一种表现形式。

　　一切的决策均来源于数据，一切的预案均来自于积累。在整个应急支撑系统中，应急数据中心是最靠近决策中枢的环节，也是最直接支撑上层软件应用的环节。说它是整个应急支撑系统核心中的核心，一点都不为过。之前的建设习惯过多关注了应急指挥大屏和大厅的装修，缺乏根据应急本质业务需求的系统考虑，因此把应急指挥系统中心大厅弄成一个高级会议室也是必然的结果。在未来的应急支撑系统的规划中，不仅应该把应急数据中心作为一个独立的规划课题来进行实施，更应该将传统数据中心的建设实施经验、技术方案与应急系统对数据的要求结合在一起，从而实现一个以应急业务为目标的数据中心方案。

　　应急数据中心和传统数据中心相比，存在两个新的特征，一是数据类型更为多样，尤其是多媒体类数据占有大量比重;二是包含了集中通讯控制和集中显示控制两个功能，需充分考虑这两个控制单元在数据中心的集成。

　　在当前各类数据中心架构技术中，基于以太网的统一交换架构数据中心对于满足应急数据中心的两个新特征最为适合。一方面统一的以太网底层通道为集中控制、集中通讯、集中显示提供了物理上的通道技术基础，只要在需要的环节和位置引入相应的控制设备即可，甚至于还可以做到设备级的各种集成;另一方面，统一交换架构数据中心打通了数据中心中前后端的网络平面，统一了LAN、SAN和服务器互联网，服务器、存储及各类设备之间的互联没有了先后次序的限制，这就为不同类型数据(如媒体类数据)的不同管理方式带来了最大的灵活性。此外，统一交换架构数据中心在容灾方面的实现手段多样化、易于部署，对于应急数据中心的高可靠性也是一个很大的支撑。

　　第四平面 应急管理平面

　　实现应急指挥系统设备管理、网络管理、业务管理(通讯、会议、图像、数据等)、用户管理等各种管理功能，为所有应急业务提供高效的资源管理，并且它的持续优化整合最终体现在应急系统的易用性上。

　　同时也为综合应用系统提供良好业务接口(软件)。综合应用系统的效能最终体现在接口丰富性和管理平面对下面各个平面管理的紧密度。

　　以上四个部分，相互之间有非常紧密的衔接和对应，每个部分自成体系，组合在一起又构成系统。这种规划方式，有助于从根本上改变当前应急指挥平台建设松散耦合、七国八制的不利局面。

　　应急指挥系统(平台)建设展望

　　应急指挥系统(平台)建设应该根据应急业务特点及发展规律做总体合理规划，分层分模块实施，逐步推进建设，模块交付。

　　在政府信息化建设中，就一直强调“整体规划、分步实施”的原则。政府应急指挥联动系统建设作为一个时间长、范围广、应用复杂的大工程，必然也必须遵循这一原则。但就目前情况来看，由于之前没有一个成功的参考，许多地方、部门对整个应急联动系统究竟要建设成什么样子并没有一个很清晰的认识，在建设过程中也只能想到哪里做到哪里。对他们来说，需要明确的是，采取怎样的规划以及怎样的步骤来完成才能事半功倍。

　　1. 总体规划

　　首先要考虑到应急指挥的应用环境，它是需要能应对极端情况的系统，也就是说在重大事件(重大自然灾害)发生后也能够正常工作，或者说能迅速恢复功能，同时它也应该能做到平战结合。其次要考虑承载各类业务需求，如数字集群、视频会议、电话会议、各类视频健康图像的接入、各部门各类数据容灾备份、卫星链路的平滑接入等等都是应急系统的核心业务。另外，还要考虑如何保障这些业务在各种情况的稳定运行。

　　2. 分层分模块实施

　　所谓分层分模块实施，是考虑到系统建设有周期、资金投入、技术能力等多方面的因素，在建设模式上逐步分层建设，特别是在基础部件系统上更要结合应急指挥的业务特点，综合考虑各类技术要素。例如：

　　传输网——现有电子政务网能否满足应急业务的需求?多种链路备份技术如何部署实施?业务带宽如何规划?

　　传输网络安全——应急平台的安全威胁如何评估?全网安全如何规划?

　　存储系统——流媒体数据和应用业务数据如何统一存储?如何为各委办局提供统一的容灾保护?

　　系统运行维护——庞大复杂的应急平台如何统一管理?如何降低运维成本?如何降低对使用人员的技术门槛?

　　综合应用系统建设——用户与专家特别关心其中的应急预案或应急应用软件建设与规划。而经过这几年相关应用建设与发展我们也可以看到：预案是根据具体事件来确立的;预案更多是行政方法和处理流程(预案不能过度的认为是联动软件);预案将会持续增长与优化(组织优化，流程优化);应急指挥系统是协助人实现预案的;应急联动应用软件是应急指挥经验的IT总结，也需要通过实践，结合组织体制、运行机制、法制基础的发展与完善不断总结优化;先基础后应用，基础应用先行，智能应用逐步完善。

　　由于应急IT系统涉及的技术广度和复杂性，在现行的操作模式下，我们看到的绝大多数应急平台的建设，对于硬件平台该怎么规划、怎么建设、怎么运行管理缺乏必要的系统性思考和设计，而更多的是以传统的松散集成模式，拼凑而成。典型的观点是标准系统堆砌在一起就可以了，更重要的是软件部分。这其实是很大的一个问题，也是之所以出现上文中提到的尴尬场面的症结。实际上真正能有效投入使用的应急平台，绝不应该是标准视频会议、标准监控、标准服务器等等的一个堆砌，而应该是按照层次架构、按照业务特征的要求，有序的加以耦合的。客观的讲，应急指挥最需要的是一个带有整合性的硬件平台方案。惟其如此，整个系统才能气血通畅、有效运行。解决之道，就是按照本文中提到的四层模式，来搭建标准、融合、开放、智能的统一平台。