资讯与服务

    (周一至周日 9:00-21:00)
    微信:liu87712531
    微信:lin445385978

    邮箱:87712531@qq.com

    咨询电话:15321970583

网站服务

您当前位置:首页 -> 计算机论文 -> 计算机理论->详细(目前国内最大最全原创最多的免费论文中心)

客服QQ咨询:点击这里给我发消息 点击这里给我发消息

无忧论文,为您指导,让您轻松发表,轻松晋级!

字号大小:


浅谈应急信息系统的功能需求和规划(二)

作者:来来来 整理:本网站论文网 录入时间:2011-12-14 00:18:11
管理所涉及的信息(如危机态势、应急指挥相关资源分布、应急方案等)在基础的空间地理图形上形象地表现出来,便于指挥和决策人员直观地进行形式判断、形成决策或进行资源调度;各种信息还可能要借助一定的显示设备和显示控制系统表现出来。

  3、信息调度:所有信息在汇聚点被组合和集中呈现,供指挥中心的指挥决策人员作为决策和调度依据;有时还要将信息分发下级指挥中心(或分中心)的不同的专业化处理系统进行处理,或从这些系统收集处理结果。

  4、通讯和物资资源调度:应急指挥最终都表现为通过一定的通讯手段,完成一定的人力、物力资源调度。例如警力的调度、救灾物资和设施调度、对事件现场的疏导和部署,等等。

  5、辅助分析决策:在应急指挥过程中,提供一些逻辑分析模型、统计模型或预案,以及案例库中的参考案例,帮助指挥员进行理性决策;同时,应急信息系统还应记录下整个指挥调度的过程,形成完整案例,丰富案例库,为实现知识化、智能化的危机管理作积累。

  以上是一个较为抽象的逻辑功能模型,它有助于我们把握应急信息系统的核心建设目标,合理运用各种技术和各种“物理的”系统。

  三、应急信息系统与其它信息系统的周边关系

  1、技术型应用系统与应急信息系统的关系

  在应急信息系统建设领域的最大误区,在于信息系统功能需求分析的缺失——从需求的陈述(实质上是一种需求定义)直接跳到技术方案,甚至成为技术方案或产品的简单堆砌。以技术方案代替功能需求,这似乎已经成为了一种应急信息系统建设中的普遍现象。

  例如,我们经常能在招标书或所谓规划中看到这样的做法:即直接把“数字录音系统”、“大屏幕显示系统”、“地理信息系统”等作为“需求”本身的内容,对具体的技术实施方案和产品型号进行招标,甚至还有的招标书把“数据库系统”也作为应急信息系统需求的一部份提出来。这里面缺少了对应急信息系统的实质内容和目标的把握,缺少了一个理性的论证和分析过程。这样的“需求”拿出来招标,多半会造成建设的混乱和失控。

  并不是说以上的技术系统不能作为应急信息系统的一部分,相反,逻辑的功能最终都会落实为一系列“物理”的技术子系统。但是我们在进行技术子系统的划分和分包之前,有必要对有机信息系统的“原始”功能需求作一定义和陈述,为技术方案的展开提供理性的约束,而不会被技术牵着鼻子走。

  例如,GIS是一种广泛使用的、成熟的技术,也已经形成相对独立运行的系统。独立运行的GIS甚至可能成为整个应急信息系统中最主要的操作平台。这也是一些项目直接把GIS作为一种“默认”的“需求”的原因。但是,应急信息系统是否要采纳GIS,还要看具体的应用领域是否具备了应用GIS的数据条件和环境。而且,即使有必要和有条件使用GIS,也要从整个应急信息系统的总体目标出发进行分析,提出技术应用需求:

undefined undefined

  第一, 要实现应急信息系统与GIS的双向联动。GIS虽然可以独立运行,但在应急信息系统环境下,应该可以实现应急信息系统与GIS的多种联动方式——包括双向的相互驱动和基于数据共享的独立操作,等等;

  第二, 要实现应急信息系统与GIS的底层整合。GIS系统与应急信息系统应共同遵循一定的数据标准,产生和传递一致的数据;底层应实现数据库共享或公用。

  第三, GIS与其他系统的数据整合。GIS的基础数据来自测绘部门,而应急指挥所需的“活”的应用数据往往来自其他业务部门,如建设、交通、气象、卫生,等等。为让信息系统能够运行起来而“一劳永逸”地导入数据的做法是不可取的。应该充分利用这些“活”的地理数据,建立与数据源进行同步更新的完整机制,贯彻专用属性数据“

首页 上一页 1 2 3 4 下一页 尾页 2/4/4

上一篇uC/OS-II内核超时等待机制的分析
下一篇赞自由软件(六)