消防生产安全信息系统技术方案 - 图文

消防生产安全信息系统技术方案

1 背景

消防信息化建设是“金盾工程”不可缺少的重要的组成部分。同时，消防部队还是一支与火灾和灾害事故作战的部队，这就决定了消防信息化有其固有的一些本质、特征和规律，消防工作的中心与信息化直接相关。

近年来，随着信息通信技术的飞速发展，在国家信息化的大形势和“金盾工程”建设的大背景下，消防信息化建设工作取得了较大的进展，特别是在通信网络建设方面有了较大改善，所有总队、支队及部分大中队已建成局域网，并依托二、三级公安网实现了联网；在软件方面，部消防局陆续组织开发、配发了一批业务软件，许多总队也根据业务工作需要自行组织开发了一些单机版和单项性的业务软件，并开始运用信息化手段开展各项消防业务工作，初步实现了信息资源共享和办公自动化，在提高工作效率，促进执法工作的科学化、规范化方面取得了一定的成效。

消防部队的计算机应用工作虽然在90年代中后期以来取得一些成绩，但基本上均属于自发进行，没有形成系统，没有真正从总体上进行考虑和规划，缺少统一规划，存在各自为政、重复开发和低水平开发的现象。大量的单机版和单项性软件不利于信息化的统一建设、维护和管理，信息共享程度和利用率较低，无法适应信息化网络化的发展方向，也不能适应消防工作不断发展的需要；从全国来看，目前公安消防信息化建设工作整体发展还很不平衡，仍存在许多问题，与日益繁重的消防工作的客观要求还有较大差距。

因此开发、完善以防火、灭火信息为核心，综合各项消防业务的消防信息系统，实现消防业务办公自动化和消防业务信息共享和综合利用，建立消防部队快速反应机制，提高消防部队预防和扑救火灾以及处置其它灾害事故的实战能力，优化消防业务工作流程，实现消防业务管理科学化、规范化，提高工作质量和管理水平，显得尤为必要。部消防局也于2002年制定了今后一段时期消防信息化建设的指导性文件《全国公安消防信息化建设一期规划(2003年—2005年)》，明确提出了消防信息化建设的近期目标之一就是开发综合的消防业务信息系统，基

1

本实现日常办公、审批流程、业务工作的计算机化管理。

2 消防信息系统建设现状与存在问题

信息系统在消防的应用缘起于火灾统计的计算机处理。在整个公安系统中公安消防部门是较早应用计算机开展业务工作的，上个世纪80年代初开始运用计算机进行火灾统计工作，80年代末实现了火灾统计数据的超级汇总。90年代中期，部消防局组织开发了火灾统计计算机系统并配发各地，系统的应用不仅提高了火灾统计工作的效率和质量，还培养了一批消防部队从事计算机网络通信工作的业务骨干和技术骨干。随着信息技术的发展，信息系统在消防各个业务方面的应用也愈为广泛和深入。

2.1消防信息化建设现状

1998年，公安部党委面对社会治安的新形势以及公安工作的现状，提出实施“金盾工程”(全国公安信息化工程)的重大战略决策，并将“金盾工程”作为科技强警龙头工程予以推进和实施。在这种国家信息化的大形势和“金盾工程”建设的大背景下，部消防局正式明确了消防信息化的概念，于2002年11月制定了今后一段时期消防信息化建设的指导性文件《全国公安消防信息化建设一期规划(2003年一2005年)》，明确提出了消防信息化就是利用先进可靠、实用有效的现代计算机、网络及通信技术对消防信息进行采集、储存、处理、分析和挖掘，以实现消防信息资源和基础设施高程度、高效率、高效益的共享与共用的过程，其实质是各级公安消防机构在各项消防工作实践活动中对消防信息资源进行广泛而深入地开发利用，为防火、灭火、抢险救援、队伍管理教育、后勤保障等各项工作提供决策性的信息支持。

近年来，按照“金盾工程”的总体部署和《全国公安消防信息化建设一期规划(2003年—2005年)》的要求，公安消防部队的信息化建设取得了较大进展。全国消防通信网络基础设施建设进一步完善，消防业务信息化应用逐渐丰富，各级公安消防部门运用信息化手段开展各项工作的意识普遍增强，全国公安消防部队信息化建设已形成良好发展氛围和态势。

2

2.1.1计算机网络

进入90年代，随着信息通信技术的飞速发展，公安消防部队的计算机网络系统建设也得到了长足的进步。部消防局于1997年建成机关局域网，北京、吉林、上海、江苏、浙江、山东等消防总队也于90年代中后期相继建成机关局域网，并开展了部分网络应用工作。消防通信网络基础设施建设目前主要依托公安主干网，各地消防部队通过与当地公安机关联网，接入公安信息网，实现公安消防部队逻辑上的通信网络。有条件的地区自行组建了相对独立的消防通信网络。到2006年底，部消防局至省(区、市)总队、市(地、州)支队、基层大(中)队的全国消防部队三级计算机通信网已全面建成，形成了较完善的消防通信网络。 2.1.2业务系统

90年代末期以来，部消防局陆续组织统一配发或推广了部分业务管理软件如消防安全重点单位信息系统、火灾数据统计系统等，部分总队也组织开发了一些单项性及综合性业务管理软件，如浙江消防综合信息系统、上海防火业务信息系统以及广东消防综合信息系统等，运用于实际业务工作，取得了较好的成效，也为消防信息化建设和应用工作起到了积极的示范和推动作用。 2.1.3信息标准化

标准规范体系是实现信息共享的基本依据和保证。在消防信息化建设中，没有统一的接口规范，就不可能实现应用系统的互联互通；没有统一的标准，消防信息化建设就不可能协调一致、有序推进，甚至有可能出现混乱局面。部消防局制订的《消防信息系统技术框架体系》和《消防信息系统数据结构体系》已正式列入公安部计算机及信息处理行业标准，为今后消防业务信息系统的设计、开发、整合提供规范性的技术指导意见，保证全国消防业务信息系统的架构、平台、协议的一致性，保证各级公安消防机构之间的数据传输和交换，实现信息资源的共享，避免出现各地在信息化建设中各自为政，导致全国统一的业务工作无法推展的问题。

3

2.1.4信息化保障制度

消防部队全员的计算机技能水平既是消防部队官兵综合素质的一种体现，更是消防信息化应用能否取得成效的关键。近年来消防部队采取了切实有效的措施加大全员计算机技能培训工作，积极组织参加《全国公安机关人民警察计算机应用技能培训》考核，切实提高全体官兵的计算机应用技能水平，为消防信息化各项应用奠定人才基础和智力保障。信息系统和信息化保障制度的建设，进一步提高了各级干部的科技意识，改善了队伍的知识结构，开拓了工作思路，启发了改革设想，有力地促进了日常管理、运行机制、工作方法和队伍建设等方面的创新。

2.2消防信息化中存在的主要问题

虽然消防信息化建设工作取得了一定成绩，但从总体上看，消防信息化建设整体水平还不够高，覆盖面还不够广，建设情况还很不平衡，与“金盾工程”的总体要求、信息技术飞速发展的形势和消防工作和消防部队建设日益发展的实际需求相比，仍然存在很大差距，还存在许多不足和薄弱环节，比较突出的有以下几方面：

2.2.1整体应用急需规划

目前从“纵向”而言，面向某类业务及其各个应用层次(部、省、市、区县)的整体应用规划工作不够：从“横向”而言，缺少面向各个应用层次及所辖业务的整体应用规划。即应用系统建设缺少全国性的“条”、“块”结合的统一规划和标准。应用的整体规划和总体设计滞后，导致各地各部门“自建自用”应用系统，自成体系、独立使用，导致信息共享困难。例如火灾及灭火救援管理系统、重点单位和法律文书管理系统、建筑防火审核管理系统等信息系统，其突出问题在于形成了一个个“信息孤岛”，各部门的信息被封锁，无法实现信息交流共享。如通信指挥系统在抽调重点单位资料时需要到重点单位管理系统中去查找，这种因当时认识不深而造成人为的“割据”状况，既妨碍了公安消防机构整体战斗力发挥，也浪费了人力物力财力。因此，在做好总体应用规划的前提下，充分调动和 发挥各个业务部门的职能作用，从技术上和体制上保障信息的高度共享和综合利

4

用，成为当前迫切需要解决的问题。 2.2.2应用开发缺乏统一规范

各地在系统建设中，所采用的计算机网络结构、网络设备、运行平台、数据库种类、数据库表信息格式、数据库管理层次结构模式、信息传输和交换格式及底层传输软件不尽相同。同时，在建设时没有考虑与其它系统的衔接问题，使得不同系统之间，不同地区之间无法实现数据共享和交换。因此，在技术上做好应用的总体设计，制订相关的技术标准和规范迫在眉睫。 2.2.3信息共享程度较低

消防信息的特点是种类多、互补性强、关联关系较复杂。目前各业务应用管理系统大多处于独立运作、数据独立存放状态，信息系统网络化、集成化程度低。业务部门之间、甚至业务部门内部由于信息不能共享，造成资源的浪费和数据的不一致性，规模效益不高，不能满足消防业务工作对信息支持的急迫要求。业务信息系统间普遍存在信息交叉采集、重复录入的状况，造成存储冗余、重复建设、警力和资金浪费。 2.2.4整体应用水平不高

应用系统的整体功能不完善，网络化应用范围小，信息系统的建设规模小，迫切需要采用新技术扩充系统功能，提高系统共享能力，提升系统规模效益。部分地区领导对信息化建设重视程度不够，系统运行维护和管理水平不高。信息结构不统一，信息综合利用困难，数据准确性较差。各业务信息系统自行确定传输格式，底层传输软件不统一，业务信息系统间数据交换困难。在信息安全机制方面缺乏统一的规范，口令复杂，无法实现“单点登录、全网漫游”，严重影响信息共享。

2.2.5数据资源深层次挖掘不足

消防部门有丰富的信息资源，这些信息资源不仅是消防工作的宝藏，同时也

5

具有极大的社会价值和经济价值。当前各地业务信息系统的应用还仅仅停留在信息的存储管理、业务查询、静态统计上，信息的综合利用、增值服务的意识不强，信息的深层次挖掘很不充分，在消防信息资源如何为国民经济建设服务、为社会服务、为科学决策服务方面还没有形成一套可行的思路。 2.2.6组织机构不健全

随着国家信息化和公安信息化的不断推进，消防信息化建设已成为一项长期的、不断发展和十分重要的工作。目前各级公安消防部门承担信息化工作的人员比较分散，没有专门的工作机构，有的在秘书处，有的在微机室，有的在通信处，特别是支队一级缺乏专业人员，大多为其它业务岗位人员兼任，且人员不稳定，流动性大，这一问题已经严重制约和影响了信息化建设工作的开展和专业技术队伍的稳定，与国家信息化的大趋势，公安信息化发展的总要求，以及消防信息化建设的繁重任务极不适应。 3建设目标

本系统的建设目的，是开发出一套适合河南油田实际工作流程的消防管理信息系统，系统基于互联网技术平台，软件整体采用最新技术的网络开发工具，主要紧紧围绕消防工作（河南油田勘探开发生产与消防相结合），以消防工作为主线把消防工作中的战训管理、防火管理、车辆管理、人员管理、器材管理、预案管理等，紧密结合消防工作实际开发成业务工作平台，重点放在日常工作管理，编制灭火预案，绘制电子地图，熟悉道路、水源及重点要害部位等。最终达到溶入到网络操作，减少来往时间差旅费用，提高工作效率、严谨办事程序，达到消防业务工作的统一管理，即预案制作电子化、熟悉日常化，工作科学化、办公自动化目的，提高消防工作中的科技含量。

实现以下目标：

（1）油田内部建立“上下贯通、横向集成、互连互通”的消防综合信息应用平台，实现与一线生产单位、公安、消防、交通等部门的信息共享。

（2）建立消防支队内部消防业务管理信息系统，实现从战备执勤、防火管理、岗位练兵、装备管理过程的网络化、自动化、规范化管理，提高消防业务管理水平。实现消防支队系统内部工作流程和工作结果网上流转，信息网上发布，

6

统一调度、协同作战、消防应急响应和信息作战能力。

（3）作为中石化系统内部企业专职消防队的试点单位，系统完成后稍做改动可在胜利油田、中原油田等油田应用。

4 宏观需求分析与系统总体框架

4.1系统需求分析

系统需求分析是系统规划与设计阶段的重要工作之一，也是规划与设计的重要依据。在系统规划阶段，需求分析的重点是宏观需求分析，为系统概要设计做准备；设计阶段进行的需求分析必须尽量详尽，以便为应用系统的设计奠定基础。本章的重点是系统的宏观需求分析和和对系统总体框架的讨论。 4.1.1从工作性质、机构设置对系统宏观需求分析

消防部队是一支与火灾和灾害事故作战的部队，其中心工作是灭火救援和消防监督，同时还有内部管理、政工教育、后勤保障等各项业务工作。消防综合信息系统的使用者从横向看，包括司令部、政治部、后勤部、防火部四大部门；从纵向看，包括总队、支队、大、中队三级。因此，必须充分考虑在横向与纵向上三级单位的不同职能所带来的需求上的差别。从纵向看，上级着重于统计分析，全面了解与掌握全局性信息与数据；在基层则着重于业务流程实现，通过业务处理系统实现日常办公自动化，将使用者从手工劳动、重复劳动中解脱出来，减轻工作强度，提高工作效率。应用系统的设计应当充分考虑以下几点： 1．保证数据一致性

应当尽可能做到一处录入、单点采集、多次补充、多处可获取，减少和避免多头向基层官兵部署数据采集任务，保证数据的准确性，减轻基层官兵的工作负担，降低劳动强度，提高工作效率。

2．实现全局与局部相结合的信息共享，提高信息利用率

以网络为支撑，在访问权限可控的前提下实现信息快速传递与访问；通过数据挖掘等技术，提高信息检索、查询的方便程度和利用率。

7

3．规范化、标准化

这包括数据和业务本身的规范化和标准化。除了电子数据、文档的规范化外，还必须实现消防业务工作规范化，即工作模式和管理机制的规范化，克服执法的随意性。

4．操作简便、格式化

消防应用系统的使用者为非计算机专业人员的消防官兵，因此，系统应当操作简便。应当尽可能提供计算机辅助填写功能(如：单位、用户、日期等内容等)、历史数据自动调用和数据查询功能和自动实现关联等。 4.1.2宏观功能性需求分析

河南油田消防支队的业务需求可以分为八大部分：消防门户登录模块、消防地理信息模块、消防网络练兵模块、消防装备管理模块、应急联动信息模块、消防业务管理模块、消防防火管理模块和消防系统统一框架。因此，河南油田消防支队的消防生产安全信息系统也可以分作：一个门户登陆界面，即消防门户登陆模块；六个子系统（模块），消防地理信息模块、消防网络练兵模块、消防装备管理模块、应急接警信息模块、消防战训管理模块、消防防火管理模块。消防系统统一框架和后台数据库构成了上述子系统的运行支撑平台。

传统的信息管理系统中，一般采用两层的客户，服务器结构，即应用层(客户层)和数据服务层。在这种结构中，客户端上运行了大部分计算任务，如数据访问规则、业务规则、合法性校验等等)，并且每个客户端都要与数据库服务器建立独立的数据库连接。基于该体系的数据库应用系统能够适应大部分中小型数据库应用系统的要求。但是随着系统应用的发展、数据容量的不断增长、客户端数量的不断增加，该种体系结构在可扩充性、可维护性、可重用性、安全性等方面显示出了诸多缺陷。为了解决上述问题，在大型应用系统开发中，越来越多地采用中间件组成三层架构应用体系。在三层架构中将业务逻辑放在应用服务层，应用服务层接受客户端的业务请求，根据请求访问数据库，做相关处理，将处理结果返回客户机。基于中间件的三层架构极大的弥补了两层架构在功能上的不足，应用程序结构从二层进化到三层，从安全性、效率、功能分离等诸多方面都有很大提高，并且三层结构的概念已经渗透到B/S应用开发领域中。三层架构

8

B/S体系结构在数据安全性、数据一致性、可扩展性、可维护性等方面有着较大优势，因此河南油田消防生产安全信息系统应采用三层架构B/S模式进行设计。

4.2总体目标

河南油田消防生产安全信息系统的建设目的，是开发出一套适合河南油田实际工作流程的消防管理信息系统，系统基于互联网技术平台，软件整体采用最新技术的网络开发工具，主要紧紧围绕消防工作（河南油田勘探开发生产与消防相结合），以消防工作为主线把消防工作中的战训管理、防火管理、车辆管理、人员管理、器材管理、预案管理等，紧密结合消防工作实际开发成业务工作平台，重点放在日常工作管理，编制灭火预案，绘制电子地图，熟悉道路、水源及重点要害部位等。最终达到溶入到网络操作，减少来往时间差旅费用，提高工作效率、严谨办事程序，达到消防业务工作的统一管理，即预案制作电子化、熟悉日常化，工作科学化、办公自动化目的，提高消防工作中的科技含量。

系统建设的总体目标是：通过消防业务整合、信息共享和综合利用，提高工作效率，优化工作流程，提高消防业务管理科学化、规范化管理水平，改进工作与服务质量。

具体实现以下目标：

1．油田内部建立“上下贯通、横向集成、互连互通”的消防综合信息应用平台，实现与一线生产单位、公安、消防、交通等部门的信息共享。

2．建立消防支队内部消防业务管理信息系统，实现从战备执勤、防火管理、岗位练兵、装备管理过程的网络化、自动化、规范化管理，提高消防业务管理水平。实现消防支队系统内部工作流程和工作结果网上流转，信息网上发布，统一调度、协同作战、消防应急响应和信息作战能力。

4.3系统建设与设计原则

设计时系统的总体框架采用先进、成熟的技术体系，保证整体框架的合理配置与应用。 在开发各种功能模块时采用分层设计原则，按照表现层、业务逻辑层、数据层划分。系统预留与各业务系统的接口。

依据项目组要求和石油行业软件开发的有关标准规范，确定以下设计原则：

9

1．技术先进，结构合理：在设计总体框架时应充分考虑信息技术的发展趋势和最新技术，应为科技管理领域国内处于领先地位的产品。

2．分层设计，结构清晰；具体的模块开发采用分层设计的原则，保证系统的实现方法清晰、明确，有较强可读性，采用分层设计加强系统的稳定性。

3．高可靠性，高安全性；系统的设计必须具备良好的可靠性，使数据录入与输出畅通无阻，整个系统应提供相应的数据安全防护措施。

4．开放性强，扩展性好：系统不仅需要满足现有应用需要，而且要对未来的信息系统提供支持，因此应用的技术需要具备可扩充架构。采用的技术需要充分考虑系统在实施运行以后，新应用需求可能还会增加的情况，因此，采用的技术必须具备良好的升级、扩容、扩充的可行性和便利性。

5．功能强大，易于管理：系统设计应符合河南油田的实际情况，以便系统在实施后能够真正发挥作用，为河南油田消防信息管理带来实际的效果。

6．标准体系

要符合总部关于信息系统的“六统一”标准和规范的体系结构，完全符合目前国际主流的各种IT标准，包括网络通讯标准，数据库标准，主流的编程语言标准，可以提供标准的数据库接口、应用接口和数据访问接口，门户和服务接口，可以为整个一体化平台的各个应用之间有机的结合或集成提供有效的方法。制定各种对象的统一代码和结构，确定各级共享数据库目录、内容和结构；运用系统工程的方法制定软件设计的总体框架和结构。建模工具要求符合国际标准。

本系统的建设原则是：全面规划、分步实施、关键与基础部分先上的原则。总体规划必须贯彻从上而下的统一规划，以便实现“全局信息一体化”、“领域信息一体化”和“区域信息一体化” ；必须摈弃各部门“自建自用”或仅按“条”或“块”进行的传统建设思路，实现“共建共用”、“条”、“块”结合、以“块”为主的建设方法。全面规划包括对总体系统结构、应用系统与数据的规划。在总体规划的指导下，按照轻重缓急，分步实施；优先对影响全局的基础性和关键的分、子系统进行实施。

系统设计应以消防业务需求为出发点，紧紧围绕防火、灭火中心工作，做到全面而重点突出；系统开发中要充分利用现有各种资源和经验，充分考虑实际情况，保证以业务需求和技术可行为前提，使软件尽量做到易于使用，方便维护。

10

1、标准部件：由于采用Microsoft的SharePoint Server 2007作为方案的基础构架，Microsoft不断发布的通用部件随时可以应用到我们的系统中。

2、第三方部件：随着SharePoint Server2007应用的推广和普及，出现了大量的第三方Web部件，这些第三方部件能过对SharePoint Portal Server 在功能上进行适当的扩充，通过一定的部署，可以应用到SharePoint Portal Server中。

3、自定义部件：如果系统所提供的WebPart不能满足需求，就需要来开发自己的WebPart了，这就是自定义部件。通过开发自定义用户部件可以满足我们具体应用的实际需要。

4、WEB服务：通过Web服务的应用，以XML方式提供了可以穿越防火墙的数据传递通道，将Web服务与自定义Web部件结合使用，将大大提高系统的可扩展性。

6.3关键技术

6.3.2.Webpart技术

WebPart是SharePoint中新引入的一个概念。顾名思义，WebPart就是组成网页(Web)的部件(Part)，它是SharePoint站点WebPartPage的基本构建块。直观的看，在SharePoint网站的页面上，数据的显示、数据的编辑，都是通过一个一个的WebPart来完成的。

Webpart的作用

每一个WebPart都是一个相对独立的功能模块，使用这些模块就可以像搭积木一样拼装出我们所需要的页面及应用。这一种模式的优点是显而易见的：

① 自定义页面内容和布局

可以使用SharePoint中现有的WebPart，或第三方WebPart，或者根据需要自行开发的WebPart来拼装页面，使得页面样式，页面内容，页面布局的修改更加容易，也使得页面更有逻辑性。

② 导入、导出WebPart

16

WebPart具有导入和导出的功能，可以方便地将部件进行跨网站移植。 ③ 在不同部件间建立通信

WebPart具有连接的功能，可以使不同的WebPart之间进行相互通信，相互关联，互相传递数据，以使页面成为一个整体，来完成一个更加复杂的任务。

④ 增强代码重用性

WebPart可以大大地提高代码的可重用性。在不同的页面，我们可以使用同一个WebPart，甚至在同一个而面上，也可以使用同一个WebPart，并根据不同的参数设置来完成不同的功能。 6.3.3. WinForm技术

WinForm是.Net开发平台中对Windows Form的一种称谓。.Net 为开发WinForm的应用程序提供了丰富的Class Library（类库）。这些WinFrom 类库支持RAD(快速应用程序开发)，这些类库被封装在一个名称空间之中，这个名称空间就是System.Windows.Forms。在此名称空间中定义了许多类，在开发基于.Net的GUI应用程序的时候，就是通过继承和扩展这些类才使得我们的系统有着多样的用户界面。

在本系统中用户只需登陆客户端，选择相应功能，点击编制报表功能按钮，系统即自动分析数据并直接写入到Excel报表模板中，直接生成可打印的标准报表。

6.4.4 Infopath技术

InfoPath是微软Office家族中的新成员，现在已经发布了2007版本，新版本支持在线填写表单。InfoPath是企业级搜集信息和制作表单的工具，将很多的界面控件集成在该工具中，为企业开发表单搜集系统提供了极大的方便。、

在本系统中，网员填报项目都是通过Infopath来实现的，利用MOSS 2007 的InfoPath Forms Services，用户可以在不安装InfoPath客户端的情况下，在浏览器上直接填写表单。

Infopath的优势：

(1)

将业务过程扩展到防火墙之外。

17

使用 Office InfoPath 2007 和 InfoPath Forms Services 可以轻松地将表单解决方案扩展到防火墙以外，因为您可以使用多种不同的 Web 浏览器和移动设备来完成表单。

(2)

轻松地将 Microsoft Office Word 文档和 Excel 电子表格转换

为 InfoPath 表单。

将 Word 文档和 Excel 电子表格转换为 InfoPath 表单模板，您就可以通过将旧版文档转化为功能丰富的 InfoPath 表单模板，在信息收集过程中确保数据完整性、改进版本控制和实现结构化。

(3)

使复杂的表单设计变得更容易。

Office InfoPath 2007 可以帮助用户使用简单的拖放式界面生成表单，同时也支持预设的模板部件和共享数据连接功能。

(4)

增强了对 InfoPath 表单模板中的重要信息的保护。

Office InfoPath 2007 包含对信息权限管理的支持，可以避免表单被不当使用和分发。

(5)

集中管理整个组织的表单。

Office SharePoint Server 2007 的 InfoPath Forms Services 仅向拥有安全连接的用户提供访问权限，从而使组织可以集中管理电子表单。

(6)

使用 Office InfoPath 2007 和 Microsoft Visual Studio 2005

开发高级表单解决方案。

通过创建 Visual Studio 2005 中托管的 InfoPath 项目来构建 InfoPath 表单解决方案，以便开发人员使用托管代码和 Microsoft .NET Framework 构建解决方案。

6.3.5 .NET VSTO技术

VSTO是Visual studio 2005的一个插件，用于改进和提高创建基于.NET的应用程序的方式，使之能够充分利用微软Office产品的功能。它让你能够在独立的Office产品里托管自己的应用程序，同时利用.NET的特性，比如丰富的用户界面开发，以及将代码从文档分离开等。每个产品都提供了大量的编程对象模型，让你能够使用自己习惯的语言，例如C#或者VB.NET。

18

VSTO的强大特性是已经把Work和Excel应用环境集成到Visual Studio里去了，所以你可以很容易就在这个集成开发环境（IDE）里使用每个应用程序的特性。此外，你还可以使用应用程序里的Windows Form控件，以及用于Word和Excel的主控件（host control）。（主控件可以在Visual Studio的工具箱里找到。）其他可用的特性包括Office文档里的SmartTags和动作窗格。开发的主要领域是后端数据集成，这包括ADO.NET编程和数据库绑定。

本项目中，所有涉及到的报表，如统计表、汇总表等都是通过VSTO技术生成的，使用VSTO能更贴近用户的习惯，定制符合用户需要的样式

6.4软件层次架构

6.5网络结构

依托河南油田局域网，网内工作计算机在90台左右。

19

6.6硬件平台

主交换机是思科3650系列，副交换机是思科2960系列，到桌面100M。

6.6.1操作系统要求

操作系统：WINDOWS2003 ENTERPRISE SERVER ，WINDOWS2003 SERVICE PACK 4 WINDOWXP。

2.6.2数据库平台要求

数据库系统应能存储大量的业务数据、用户资料等，并具有良好的安全性和保密性。数据库应采用大型关系数据库，支持主流厂商的硬件平台及操作系统平台，具有良好的开放性，支持异种数据库的互访，拥有良好的数据备份功能和恢复策略。

考虑到系统为B/S架构，采用国际流行的商用数据库oracle、DB2、SQL Server等数据库。

6.6.3硬件环境要求

投标方需根据现有网络架构、业务系统、联动接警需求和其他系统情况制定相对应的硬件架构方案，该方案需着重注意降低各办公地点之间数据传输量已节省网络带宽。

根据对业务数据量的估算，系统在网络中带宽需求，建议本系统中数据库及应用服务器均采用千兆电口接入交换机，双链路保证网络冗余，通过防火墙百兆接入网络。

6.6.3.1投标方提供的软件系统符合下列原则

(7) 开放性

选择的硬件和网络系统开放性要好，支持流行协议（如TCP/IP、IPX等），

20

保证系统之间的可联接性和可操作性。网络能支持不同厂商的系统，并使各系统之间能够以统一的格式对文件、数据以及应用系统进行访问。 (8) 可用性

在网络带置、带宽效率、时速、负载、故障频率等物理性能上有满意的指标；在文件和数据的传输、访问和共享、多媒体的传输、访问和共享服务上有满意的质量。 (9) 兼容性

当网络系统采用新技术、新设备进行改进、扩充和升级时，新旧系统要相互兼容。 (10) 高性能

所采用的主机服务器吞吐量大、响应时间快，具有强大的实时联机事务处理能力及快速的I/O通道。 (11) 高可靠性

为确保数据不丢失，应用系统应实现双机热备(建议采用操作系统自带功能实现)，从而保证系统不间断运行。

7.1消防信息系统的数据规划

在开发消防信息系统的实际工作中，常常是根据实际应用系统的开发建立数据存储。例如，开发工资系统，按工资单建立数据存储；开发干部管理系统，按干部档案建立数据存储；开发军需供给管理系统，则按供给凭证建立数据存储。在管理工作中，这三个系统需要互相调用数据，致使要编制至少6个数据抽取和格式转换接口。随着新应用的增加，接口的数目和复杂性也按几何级数增加。这种不对相互有关的应用系统的信息资源进行规划和协调，单靠增加接口的办法实现的系统集成在实际应用中非常低效。换句话说，按照管理人员使用的数据格式(也叫“用户视图”)的原样子直接建立数据库，这种开发策略是不合理的，也是不可行的。实践证明，一种行之有效的开发策略是坚持以数据为中心的原理，先自上而下地做好系统的总体数据规划，再自下而上地逐步实现各系统的应用开发。

21

消防数据库建设的任务是建立消防现实世界在信息世界的数据模型，这一模型应客观反映现实世界的实际情况。在建立数据库体系时，首先要采用科学的方法论作指导。实践证明，采用面向对象的方法是建立复杂信息系统的有效手段。与以往面向需求的结构化方法不同，面向对象方法是面向现实世界的实体对象。由于实体对象较其所表现出来的行为特征更具稳定性，因此，利用面向对象规范进行分析、设计和开发的系统无疑具有更强的生命力。

根据面向对象观点，消防现实世界是由消防自身实力(如部队实力)、消防工作对象(如重点单位)组成的，两者依据消防业务规范相互作用，并体现出具体的消防业务行为。由此可见，应当基于消防现实世界中存在的基本实体建立相应的数据库，基于各种业务规范建立相应的知识库(可视为特殊的数据库)，并由此构成消防数据库的基本体系。相反，如果基于业务或部门建立数据库，则由于消防业务只是消防实体的外在表现或特征，部门的划分是为业务服务的，将抓不到问题的本质。

在规划数据库时，消防业务所涉及的消防实体主要有消防实力、消防工作的对象、消防业务规范和消防工作记录等几类，每一类包含若干具体的对象，如表4-1所示。

表4-1消防数据库体系一览表

数据库类别 消防实力 数据库内容 人员实力 装备实力 消防设施 相关消防业务 人事、警务、财务、装备 战训、财务、装备 防火、灭火 防火、灭火 防火、灭火 防火、灭火 防火 防火 防火 灭火 防火 消防工作对象 消防重点单位 火灾信息 化学危险品 消防企业和产品 业务规范 法律法规 标准规范 灭火预案 工作记录 执法检查 22

灭火救援 灭火 例如，消防实力本身是一个实体，由不同业务部门分管的人员实力、装备实力和消防设施组成，从宏观上看应该是一个整体，因此应当建成一个统一的数据库，并以不同侧面呈现于涉及实力信息的不同业务，而不能根据业务和各部门的业务分工建立实力数据库。

4.2界面结构设计

7.2.1主界面结构

主界面是通过门户系统开发实现的。首页如图4-1所示。

图4-1主界面示意图

7.2.2列表界面结构

对题库、装备、业务、任务、文书、附件、档案等的列表，统一采用如图4-2所示的列表界面，即：左侧为各列表内容列，对每行的操作置于右侧，对全表的操作置于表下方。

23

图4-2列表界面

7.2.3可视化流程自定义

可视化流程自定义针对消防业务管理模块，功能包括流程定义和流程监控两个功能。实现在可视化的环境下，通过IE浏览器，运用拖拽(Drag&Drop)手段，让用户在无须编程的环境下定义其流程规则。它提供一个完全开放的用户使用环境，即用户可以容易地实现符合自己单位的流程定义；并提供科学的人员管理功能，可以方便的分配任务及处理权限，在人员变动、系统更改时，可以方便进行调整，无须修改流程。另外工具还提供了一个可视化的工作流监控器，使用户能够查看当前流程规则的图形过程定义，对流程中的处理环节、状态、参与者的工作量及逾时情况进行方便及时的监控。

7.3消防地理信息模块功能实现

7.3.1地理信息系统的基本功能

1．数据采集与编辑

24

GIS的核心是一个地理数据库，建立GIS的第一步是将地面上的实体图形数据和描述它的属性数据输入到数据库中。地理数据如何有效地输入到GIS中是一项琐碎、费时、代价昂贵的任务。

大多数的地理数据是从纸质地图输入到GIS。常用的方法是数字化和扫描。数字化的主要问题是低效率和高代价；扫描输入则面临另一个问题，扫描得到的栅格数据如何变换成GIS数据库通常要求的点、线、面和拓扑关系属性形式。

目前GIS的输入正在越来越多的借助非地图形式，遥感数据已经成为GIS的重要数据来源。与地图数据不同的是，遥感数据输入到GIS较为容易，但需要融入图形处理技术。GPS技术可以准确、快速的定位在地球表面的任何地点，也已成为地理数据采集的一个主要来源。

2．空间数据管理

地理数据存储是GIS中最底层和最基本的技术，它直接影响到其他高层功能的实现效率。对于庞大的地理数据，需要采用数据库管理系统进行管理。GIS中的数据分为栅格数据和矢量数据两大类。大多数的GIS系统中采用了分层技术，根据地图的某些特征，把它分成若干层，整张地图是所有层次叠加的结果，在与用户的交换过程中处理所涉及到的是层次，而不是整幅地图，因而能够对用户的要求做出快速反应。

3．制图功能

GIS的发展是从地图制图和地籍管理开始的，因而GIS的主要功能之一是用于地图制图。通过图形编辑，根据用户的需要和地物的类型，对数字地图进行整饰、添加符号、颜色和注记，就可以得到一张精美的地图。

GIS不仅可以为用户输出全要素地图，而且可以根据用户需要分层输出各种专题地图，还可以通过空间分析得到一些特殊的地学分析用途，如坡降图等。

4．空间查询与空间分析功能

空间查询和空间分析是指从GIS目标之间的空间关系中获取派生的信息和新的知识，包括如拓扑空间查询、缓冲区分析、叠置分析、空间集合分析以及地学分析，如最佳路径分析。

地理数据的空间分析功能是GIS得以广泛应用的重要原因之一。通过GIS提供的空间分析功能，用户可以从已知的地理数据中得出隐含的重要结论，这对

25

于许多应用领域是至关重要的。

GIS的空间分析分为两大类：矢量数据空间分析和栅格数据空间分析。矢量数据空间分析包括：空间数据查询和属性分析，多边形的重新分类、边界消除与合并，点线、点与多边形、多边形与多边形的叠加，缓冲区分析，目标集统计分析。栅格数据分析包括：记录分析、叠加分析、滤波分析、扩展领域操作、区域操作、统计分析。

5．地形分析功能

空间起伏连续变化的数字表示称数字高程模型(DEM)，虽然等高线适应于连续变化的表面的表示，但并不适于地形分析。因此GIS提供了DEM模块用以地形分析，包括等高线分析、透视图分析、坡度坡向分析、断面分析、地表面积和挖填方体积等分析功能。 7.3.2地理信息系统的构成

地理信息系统主要包括四个部分：信息获取与输入、数据存储与管理、数据转换与分析、成果生成与输出。地理信息系统处理、管理的对象是多种地理空间、实体数据及其关系，包括空间定位数据、图形数据、遥感图像数据、属性数据等，用于分析和处理在一定地理区域内分布的各种现象和过程，解决复杂的规划、决策和管理问题。

7.3.3地理信息模块设计目标及功能

系统在总体设计时应充分考虑用户需求，当以人工接警方式接到火灾报警时，应迅速向报警人问清楚着火单位的必要信息(单位名称、大概位置、着火部位、火场现状、楼层等)，通过消防信息系统，迅速在电子地图上查询定位该着火单位，查找火警地点的救火设施、查找火警附近的易燃、易爆区域，并根据必要的实时信息(天气等)，得出消防调度方案以及最佳行动路线等，立即通过消防专线向各个负责消防队下达出动命令。一个消防调度方案至少要包括如下内容：着火单位、着火地点、单位负责人信息、单位类型、主战消防队及增援消防队出动车辆种类和数量情况等。

根据对用户需求的分析，设计的消防地理信息模块具有下述基本功能：

26

1、底图操作

a．布局：创建大小两窗口，小窗口显示整体城区图效果，大窗口显示相应小窗口中的矩形范围的详细地图；

b．显示：可进行放大、缩小、漫游及分层显示，任意点位经纬度坐标显示； c．编辑：包括地图基本要素的增加、修改和删除； 2、信息查询

a．一般性地图要素信息查询及地名定位、距离量算、面积量算； b．消防设施、消防分区及人员部署信息查询； c．重点目标、救护医院及易燃、易爆区信息查询； 3、接警处理接口

a．接报警电话后，相应信息框显示时间、地点及电话号码，地图自动以该地点为中心进行显示，并对出事地点指定范围内的消防设施及人员状况信息进行统计；

b．消防力量到达出事地点的最短路径分析； c．消防力量支援方案分析； 4、日常事务

a．火灾统计报表打印； b．地图打印；

c．信息录入数据库，记录在案； 5、数据录入

a．消防设施、消防分区及人员部署情况录入： b．重点目标、救护医院及易燃、易爆区资料录入； c．重大危险源评估； 7.3.4危险源评估的实现

在开发消防地理信息模块过程中，通过GIS编辑工具建立重大危险源层，涵盖了河南油田长期或临时生产、加工、搬运、使用或贮存危险物质的建筑单元，如油井、加油站等。对于新建含有危险物质的单元，经过评估，若该单元内的危险物质的数量等于或超过临界量，则是重大危险源，将其动态添加到重大危险源

27

层。

评估危险源过程具体为：将重大危险源标识在电子地图上，通过消防地理信息模块，可以一目了然地看到危险源的物质数量、物质性质以及一旦发生事故可能涉及的范围，同时输入电脑的还有危险品的性质、数量、一旦发生危险所波及的范围以及相对应的应采取的措施。比如说该在多大范围撤离群众，根据化学品的性质应该采取什么防护措施，消防车该来多少辆、是水车还是泡沫车等等。这样就提高了对危险源的监控和隐患事故的处理能力。 7.3.5基于GIS的消防应急案例多维时空分析与挖掘功能

1、图形统计分析

图形统计分析由饼图、柱状图与函数曲线图三种图形的统计分析组成。统计分析制图是以消防突发事件数据库为基础，按照预先设置的统计分析条件，采用多维度时空分析算法对突发事件数据集进行分析、统计、分类等，然后提取制图结果。针对消防突发事件，可以按照类型、区域、时间、分布等多维信息综合分析，进而发现突发事件的时空规律，为应急指挥提供辅助决策和预测。

饼图具有一维性，将突发事件按照百分比表示出来，可以按照时间、地点、类型等属性分别制图。柱状图具有多维性，可以按照时间、区域、类型等多维属性制图；柱状图有横纵坐标之分，纵轴主要表示数量值，横轴属性可以时间、区域或类型，根据平台用户的选择制作柱状图，在突发事件各种属性之间进行数量增减和发展趋势的比较。函数曲线图同样具有多维性，纵轴表示数量，横轴可以选取时间、区域或类型；与柱状图相比，函数曲线图可以画出多条曲线，并给每个曲线赋予不同的颜色，进行属性间的发展趋势比较与预测。柱状图以多个柱图的形式在突发事件属性之间进行比较，函数曲线图是属性内部发展趋势的比较。

2、GIS统计分析

GIS统计分析包括基于“点”的统计分析和基于“区域”的统计分析，与图形统计分析相比，GIS统计分析完全建立在可视化数字地图之上。

“点”统计分析，将每个事件发生的时间、地点、类型等作为多维坐标系下一个孤立的样本点。通过突发事件地址信息对点进行定位，进一步查询每个“点”所代表突发事件的各种属性，例如发生时间、地点、事件类型、处置过程等。根

28

据各种要素操作点的形状及其显示与隐藏状态，可以针对数据集进行综合多维分析。

“区域” 统计分析，以区域为基本单位，每个突发事件有其相应的所属区域，区域是事先划分好的应急部门辖区。突发事件以点的形式定位在地图上，对数据库中的突发事件集按照区域进行批量显示。不同的区域以不同的颜色标记；同时可以根据突发事件类型的不同，使用不同的图标标记。不同区域、类型、时间段之间均可以制定出相互依赖的区域显示关系。利用SQL在属性数据库中实现属性信息的复合条件统计分析，然后将分类结果进行区域标识。

3、热点分析

所谓“热点”指的是消防突发事件的集中区域，热点分析的主要算法包括：区域密度分析、K．means聚类分析等。

区域密度分析：将特定的分析区域按照网格进行覆盖，网格尺度可以人工设定，建立消防突发事件到网格之间的映射，并统计不同网格单元中的事件数量，计算各个区域中消防突发事件的发生频率，然后对其排序，以不同的颜色样式显示出频率高的“热点”区域。

K-means聚类分析：该方法应用于时间、空间数据模式分析中，根据用户指定聚类的簇数目，计算指定时间段内事件空间区域分布情况，并按照用户指定的阈值作为输出条件，图形化显示输出分析结果。 7.3.6系统的软件环境

系统采用专门的空间数据库软件来管理大量的空问数据和属性数据，采用ArcGIS系列作为系统开发的GIS平台，通过其中的ArcSDE空间数据库引擎对数据库进行访问。通过 ArcIMS发布引擎与消防生产安全门户进行对接。

1、数据库软件

空间数据库软件采用Oracle存放空间地理数据和属性数据，通过ArcSDE空间数据库引擎对其进行访问。

Oracle数据库经过多年的发展，如今已经成为非常成熟且被广泛使用的大型商用数据库，它具有许多优越的特性，现将其主要的特性介绍如下：

(1)海量数据管理：Oracle一直对海量数据的管理非常重视，为此，采用了数

29

据分区的办法。采用数据分区后，海量数据分成很多可管理的块，当系统操作或用户会话处理查询时又能透明地将分块的数据组织起来。

(2)保密机制：Oracle的高级保密机制通过各种各样的特权，控制对敏感数据的存取。用户根据连接到数据库的用户名被赋予各种特权，如查看、修改和创建数据库等。用这些机制来保证某些用户能查看敏感数据，而有的用户被禁止。

(3)备份与恢复：Oracle提供了高级备份和恢复的工具。备份创建Oracle数据的一个副本，恢复把备份的数据恢复出来。Oracle的备份和恢复把数据丢失的可能性降到最小，并使出现故障时的排错时间最少。Oracle的服务器也提供了备份和恢复的机制，允许每天、每周、每年不问断地访问数据。

(4)空间管理：Oracle提供了灵活的空间管理。用户可以为存放数据分配所需磁盘空间，也可以通过指示Oracle为以后的需求留下多少空间来控制后继的分配。还有一系列为大型的数据库考虑而设计的特殊功能。

(5)开放式连接：Oracle提供和其他软件连接的开放式接口。

(6)优异的空间数据存储和访问能力：Oracle的Oracle Spatial模块和Georaster数据格式，为空间数据的存储和访问提供了优异的处理能力。

2、GIS平台软件

本系统拟采用ArcGIS作为系统开发的GIS平台。ESRI在全面整合了GIS与数据库、软件工程、人工智能、网络技术及其它多方面的计算机主流技术之后，成功地推出了代表GIS最高技术水平的全系列GIS平台——ArcGIS系列。ArcGIS与其他GIS软件(如MapInfo、GeoMedia等)相比较有如下的优点：

(1)ArcGIS的许多先进的设计思想和概念被其他产品借鉴和采纳，成为引导全球GIS发展方向的旗帜。

(2)ArcGIS功能强大，具有强大的数据操作和管理分析功能，适合于大规模海量数据的存储和分析。而MapInfo等许多其他GIS软件虽然图形操作功能也很强，但是其海量数据的处理和分析功能却不如ArcGIS强大。

(3)目前大多数GIS软件的图形数据都是采用文件的方式来进行管理，而ArcGIS采用了面向对象的空间数据模型GeoDatabase。GeoDatabase是基于ArcSDE应用服务器的标准的关系数掘库，以全关系方式存储数据。数据以相同的格式存储。数据的管理更方便高效，可用标准的SQL对数据库进行查询，对

30

大范围的也不必分块进行管理，适合于管理大范围海量数据。 7.3.7系统界面

系统界面如下图所示：

7.4消防网络练兵模块功能实现

7.4.1功能需求

根据需求分析得到消防网络练兵模块应该具备以下功能：

理论教学网络化：提供给消防业务理论的各种资料，提供快捷、方便、优质、现代化的网上教学模式。实现对个人综合信息及考核成绩的管理。

理论考核网络化：实现消防值班室边、远、散、小等单位的异地联网考核，解决因驻地分散而造成的考核困难，方便各种训练考核的组织与实施。

根据上面的分析，消防网络练兵模块用户划分为四类： 1、考试管理员对功能的需求

(1)各种训练计划、考核计划的发布与更新。

31

(2)业务理论网上在线学习和考核的监督。

(3)信息显示。显示被考核人信息，如账号、姓名和所在连队。 (4)上传各种教育训练视频，消防理论的网上授课及在线课程的管理。 (5)组织各种消防理论的考核组卷、考核的监控。 (6)各教学、考核数据库的查找、添加、修改与删除。 2、被考核人对功能的需求

(1)信息显示。显示个人信息，如账号、姓名和所在连队。 (2)查看考核管理员发布的各种训练、考核计划。 (3)参加消防理论的网上学习与考核。 3、系统管理员对功能的需求

系统管理员权限最大，负责整个系统的维护和管理，系统各数据库的添加、删除，对用户、角色及权限进行管理。 7.4.2系统设计

本系统按功能可分为：业务知识学习子系统、测试子系统、个人资料管理子系统、基础题库管理子系统以及帮助子系统。

1、业务知识学习子系统。该系统是供消防队员学习、掌握、巩固业务知识之用。其又分为理论学习、习题讲解和同步测试三个子部分．学习内容包括各个岗位的业务知识、技能以及消防战斗过程中的实战多媒体模拟。该系统可以选择练习题进行练习。在学习过程中系统及时反馈该题的正确答案，并可给出出错答案的原因。练习结束后，给出本次学习的成效，并据此提出学习建议，同时给出近期学习课程的成效图表，帮助学生掌握学习进度。并将被考核人的每—次的学习进度、学习成绩归档存入进度、成绩数据库，作为下次学习控制的依据。

2、测试子系统。该系统是对学习效果进行测试。其试题的选择分为选择样题和题库随机抽取(从题库中随机抽取满足条件的试题，自动生成—套符合用户要求的试卷)两部分。题型分为选择题(包括单选、多选)和填空题。整个测试结束，系统自动将被考核人选择的答案保存，判卷，并给出这次考试的成绩。也可根据题型统计，给出正确率，并同时将近期几次的测试结果以图表图形的方式显示，作为被考核人学习成绩走势的自我对照，可以很清楚了解自己近期的测试情况。

32

3、个人资料管理子系统。一方面专门用一个数据库来管理个人资料，如编号、姓名、用户ID、密码等。另—方面对个人的学习成绩迸行统计管理，形成成绩记录库，以便于学习进度进行保存、控制，用来调节学习步伐、学习内容和学习风格。用户首先必须进行注册才能使用本系统，注册系统将个人资料保存到数据库中，自动对学籍进行管理。保存个人的各种档案，包括个人资料与学习资料。

4、基础题库管理子系统。将试题分为试题序号、题干、供选答案、正确答案、难度系数、错误原因等字段输入，从而形成专业的数据库，通过该系统对题对题库进行管理。可以进行更新、增加、删除学习材料，实现学习内容丰富多彩，无限扩充。这样就实现了题库数据的独立性、完整性、—致性和共享性，便于集中管理和维护，实现题库和系统的相对独立性。

5、帮助子系统。包括系统使用、维护以及在学习过程中答错习题时系统自动给出出错原因、正确答案等。目的是为操作及使用本系统提供方便。 7.4.3系统实现

系统的后台数据库主要包括以下数据表： 表的名称 Person score course Test_question 作用 主要包含的字段 学籍管理表 Name,UserID,Pwd,Dept,Addr,Tel,Description 成绩管理表 ID,CourseNo,TestNo,Score,Description 课程编号表 CourseNo,CourseName,Description 基础题库 Num,Question_trunk,Answer_selected,Correct_answer,Correspond_help,Description Course_content 课程内容库 CourseNo,personDomain,course_content,Descript Selectedkeytab 答题记录表 TestNo,PersonNum,ProblemNo,selectedkey,Descript 7.4.4系统界面

系统界面如下图所示：

33

7.5消防装备管理模块功能实现

7.5.1消防装备数字化动态管理的概念

一般来说，数字化管理是指利用计算机、通信、网络、人工智能等技术，量化管理对象与管理行为，实现计划、组织、协调、服务、创新等职能的管理活动与管理方法的总称。数字化管理有两层涵义：一是管理活动是基于网络的，即单位所拥有的知识资源、信息资源和器材装备可数字化；二是运用量化管理技术来解决实时管理的问题，即管理的可计算性。先进的网络技术、计算机软件技术、通信技术和人工智能技术是数字化管理的外部支撑条件，它们为管理信息的识别、获取、传输和利用提供了强有力的工具。

动态管理的含义。动态即变化发展的状态。装备动态管理就是在制定统一的目标和一定的评定标准的前提下，根据各单位各类器材装备使用、消耗、补充和维护等实际情况，进行定性、定量记录，做出现时的报告和调整，并与具体管理工作对应挂钩的一种装备管理制度。在这一动态管理制度中，制定统一的目标和

34

评定标准，体现了装备管理的目标指向性和可操作性；装备管理工作内容除常规工作外，随执勤备战等中心工作的需要而变化，经常都有新的调整，体现了工作的连续性和管理上的动态性；根据装备使用、维护等实际情况，进行定性、定量的记录，做出现实的报告和调整，体现了管理的时效性；改变过去定期清点、检查为实时监控，体现了装备管理的全程性。 7.5.2建立消防装备数据库

以支队为单位，建立器材装备数字化管理体系，分级实施。机关业务部门应尽快建立起器材装备基本情况与配置情况的计算机数据库，应用相关软件把装备的购入时间、价格、厂家、型号、性能参数、售后服务等内容进行备案，并按使用年限、寿命、保养返修期限、更换组件、标定调整等不同情况制作电子标签，从宏观上掌握基本情况，进行一体化管理。同时开发装备使用和动态管理方面的应用软件，推广基层使用，在录入各单位器材基本数据的基础上，详细记录各种器材使用、损耗、维修、标定和更新、更换等具体情况，以便基层单位及管理人员可以通过简洁明了的微机操作实现装备管理的数字化和动态化。 7.5.3管理模型

基层中队是装备管理的基本单元，它必须具备计算机和支队局域网络终端等相关硬件设施，还要为这些设备安装和输入装备管理软件、本单位装备数据库(二级数据库)和支队装备数据库(一级数据库)等资源。中队级管理主要是收集装备管理中的各种具体情况和各类数据，再把这些信息用数字信号模拟输入计算机以记录和更新相应装备在使用和维护过程中的现实情况。最后，通过计算机进行分析、计算和比较，可自行处理的信息，如出入库情况、使用时长、是否添加燃料、充电、更换配件等，在本单位范围内解决并进行备案；需上报处理的信息，如磨损老化、遗失、失效、申请报废等重大问题，则通过支队局域网传输至支队管理中心(或相关业务部门)。支队机关装备管理中心是装备管理的中枢部分，不论它设在战训科还是装备科，都应配置强于以上中队应具备的软硬件条件，更要有一定数量的计算机网络技术人员、消防装备技术人员和实施管理作业的技术人员，以支持和维护整个管理系统的正常运转。支队管理中心是基于中队信息采集传输和

35

汇总、分析的高一级处理平台，它一旦获取中队上报的信息就及时更新数据库，同时分析得出是否应采取进一步的处理措施，从而监督基层单位实施动态管理，并能从整体上掌握全支队装备使用管理的情况，一方面指导支队调度指挥工作和执勤训练、灭火救援工作；另一方面，提供本单位装备管理能力与效益的评价依据和对下属单位装备管理工作检查、考核的依据。此外，对于一些在计算机中事先设置的标准和参数，管理系统还会自动生成信息、报告管理员或直接提供处理意见、如达到报废年限、需更换部件、超过保质期以及需重新标定仪器、探头等等。

7.5.4系统界面

系统界面如下图所示：

36

7.6应急接警信息模块功能实现

7.6.1需求分析

随着计算机和通信技术的飞速发展，现代消防通信指挥系统也取得了迅猛的进步，在符合国家标准，满足基本功能的基础上各种新技术新产品，不断的被应用其中。使得整个系统的发展趋于更加稳定，操作更加简单流畅，在各级消防部队都得到了广泛的应用。

通信指挥系统大致分三级体系，支队级、大队级和中队级(消防站)系统，支队级指挥系统负责集中接处警，向大队级和中队级系统下达出动命令和进行调度指挥。是整个系统的核心，是事件的接收和发起点，功能也最强大。大队级也可以进行接处警，但规模要比支队级的系统小，在当前的发展趋势下已经弱化了大队级的功能，为了节约整合资源都是采用支队集中接处警的这种方式，而且随着三台合一思想体系的提出，接处警将更加集中，将各种资源统一到支队级进行全盘的指挥调度。优化资源的配置，科学调度，提高了消防部队的战斗力，保障人民生命财产的安全。

37

火警终端台系统对应的就是中队级系统，在消防部队的行政体系结构中，消防中队是最基层的单位，灭火救援行动中最前沿的战斗力量，接收支队级或者大队级系统的指挥调度。因此在系统功能和规模上要小一些，主要的功能就是接收上一级系统下达的出动命令，打印出车单，根据灾害类型能够对联动设备进行控制，并且具备调度专线，进行语音通信。因此对终端台的要求就是系统稳定，操作简单快速。

随着技术的发展，在实际的应用中，消防部队也对终端台提出了很多新的要求。比如说联动控制功能进一步扩展，通过车库门的开关状态，自动设置车辆的状态，因为一门对应一车，系统必须对车库门的状态进行记录和判断，自动分析数据，得出所对应车辆的当前状态；将应用很久的电铃提醒方式进行改进，换成自动语音提醒功能。因为在消防部队，电铃就是命令，行动的集结号，一听到铃声，无论是什么时间什么情况下，都要整装待发，做好战斗准备。经过很多专家的调研如果长期在这种条件下生活，消防战士就会产生一种条件反射，在心里会造成很大的紧张感和无名的压力。在当前提倡以人为本，创建和谐社会的今天，消防部队希望将电铃提醒方式改换成语音提醒，保证消防战士的心理健康。而且语音提醒的信息量更大，内容更丰富，消防战士第一时间就能了解到警情的详细信息，在心里上做好了充分的战斗准备。

在通信指挥系统的不断发展过程中，终端台也不断丰富本身的功能，使系统更加专业化，智能化，简单化，以适应消防部队提出新的想法和要求。将最新的技术和产品应用到终端台系统中去，保证系统不断更新，适应社会的发展，将更加安全可靠的终端台系统提供给消防部队使用。 7.6.2总体设计

火警终端台软件系统是嵌入式火警终端台安全因素之一，在保证了硬件平台，系统稳定的基础上，应用程序软件和网络的安全也尤为重要。因此如何开发安全高效的火警终端台软件也是设计的重要环节。

1、网络协议

火警终端台系统要与指挥中心受理台建立网络连接，进行数据交换，因此首先要确定采用何种网络协议。TCP和UDP是通常网络通信所采用的两种典型协议，

38

在这二者之间进行取舍。TCP/IP，是Internet最基本的协议。UDP协议即用户数据报协议，同样直接位于IP协议的顶层，将网络数据流量压缩成数据报的形式。二者的区别是TCP提供的是面向连接的、可靠的数据流传输，而UDP提供的是非面向连接的、不可靠的数据流传输，TCP保证数据顺序，UDP不保证，因此TCP提供更稳定更便利的传输通道，尤其在多包的情况下，必须保证数据的顺序。在消防通信指挥系统应用中，要求数据的绝对安全准确，因此火警终端台系统采用的是基于TCP/IP协议，进行数据通信。

2、数据库的选择

为了使火警终端台系统操作简单易于维护，在数据库管理方面尽量做到最少，只需维护四种类型数据：出动记录信息、车辆信息、人员信息、电话号码数据库。因此采用操作简单占用系统资源较少的Access数据库。它提供了表、查询、窗体、报表、页、宏、模块7种用来建立数据库系统的对象；提供了多种向导、生成器、模板，把数据存储、数据查询、界面设计、报表生成等操作规范化；为建立功能完善的数据库管理系统提供了方便，也使得普通用户不必编写代码，就可以完成大部分数据管理的任务。其主要的特点有：存储方式单一、面向对象、界面友好、易操作、集成环境、处理多种数据信息、Access支持ODBC(开发数据库互连，Open Data BaseConnectivity)。 7.6.3应急接警终端体系结构

未来终端台的发展趋于更加安全和智能化。如何使终端台系统更加的安全稳定，首先硬件平台是基础。通用计算机虽然也经过严格的测试，但是在实际的使用中由于受到人为或者环境的影响，表现出一定的不稳定性，尤其是在主板和各元器件的配合上更容易产生问题，导致元器件的损坏等。嵌入式计算机在最近几年得到了飞速的发展，在航空航天，工业控制，汽车等领域得到了广泛的应用。可承受高过载，高冲击及其它恶劣环境(如高低温)，具备工业级规格且拥有高效能低功耗等优势，提供可靠的供电系统，良好的通风散热机制，完善的EMC结构，是实现嵌入式计算机高可靠性的必备条件。而且采用CPCI／ATCA技术标准的工业总线设计，将大幅度提高嵌入式计算机的性能。所以采用嵌入式主机作为终端台的硬件平台，提高终端台的可靠性。

39

嵌入式火警终端台的体系结构：最底层的是硬件平台，采用嵌入式主机，然后是硬件抽象层，硬件抽象层将操作系统和硬件平台隔离开来，与硬件密切相关，通过接口向操作系统以及应用程序提供对硬件的操作服务。操作系统或应用程序使用硬件抽象层API接口对硬件进行操作，只要硬件抽象层API能够在下层硬件平台上实现，那么操作系统和应用程序的操作功能就可以实现，使得硬件抽象层具有与操作系统无关性，保证了操作系统可以在不同的硬件体系中移植。嵌入式操作系统内核对硬件的相关操作主要包括系统启动初始化、任务上下文管理、中断异常管理以及时钟管理，都是通过硬件抽象层来实现的。 7.6.4功能模块划分

应急接警终端是消防通信指挥系统的最终执行机构，它的安全稳定运行关系到整个通信指挥系统的安全稳定。确保出动命令的正确下达，调度专线的畅通，充分发挥终端台应有的功能，保障消防部队及时出警，调度有力，终端台的稳定是关键之本。具体功能首先建立起与指挥中心受理台的连接，一旦接收到出动命令，打印出车单，进行联动控制。

在符合国家标准的前提下，本嵌入式火警终端台系统从功能结构上分两大模块：受理子系统和地理信息予系统。 7.6.5系统界面

系统界面如下图所示：

40

本文来源：https://www.bwwdw.com/article/cdr3.html