安全生产监测预警系统技术方案

1  总体建设方案

1.1  建设原则和策略

以规范和创新管理作为“立体化管理”项目总体设计的出发点和落脚点；要深化需求分析，做好需求调查，以“需求为导向、应用促发展”作为项目总体设计指导性方针；技术路线的选择要突出实用性、安全性、先进性原则，重点采用成熟技术，做到节约、实用、好用，不片面追求技术的先进性；要强化资源整合，注重统筹开发，围绕互联互通和信息共享，集成、整合各级、各类业务应用系统和数据库系统，统筹好已有系统与在建系统、各类与各级系统之间的关系。

总体设计方案应当具备明显的实用性、经济性、先进性、易用性、可扩充性、开放性特征，遵循统一的标准规范，支持信息与服务高度共享。

1．安全发展、以人为本

坚持总体国家安全观。坚持以人民为中心和安全发展。使人民获得感、幸福感、安全感更加充实、更有保障、更可持续。在新形势下，坚决贯彻落实总体国家安全观，推进新时代公共安全体系建设；全力防范化解重大公共安全风险，有效应对各类灾害事故。针对全要素管理的多项功能，包括防灾、救灾、灾后重建、风险评估、安全监管等，利用高科技手段来提升工作效率、工作能力、改进工作管理模式，维护国家利益，保证人民生命财产安全。

2.高点定位，统筹规划

在总体设计上，要按照“一盘棋”的建设思路，搞好顶层设计，系统设计要覆盖全要素管理管理全业务、全流程；在技术选择上，要采用先进成熟的信息化建设技术手段，确保系统建设的先进性、经济性和实用性。统一标准的基础上，优化和合理配置各类信息资源。建立协同开发管理体系，从总体上对项目全过程进行统一协调，设计实现异构平台、多业务系统、海量数据以及多个不同建设单位开发成果的有机衔接、互联互通、高效运转及优化集成。

3.资源共享，充分利旧

平台设计与建设需充分利用前期信息化建设成果，发挥现有网络及硬件基础设施环境，以及安全系统等作用；有效整合已有数据资源；充分集成现安全生产信息系统等，统一标准规范，实现全要素管理全业务、全流程网上运行。确保前期信息化投资的充分利用，充分扩大现有信息化资源的价值。

4.统一领导，稳步推进

加强领导、强化管理，统筹资源、集中资金，科学安排、有序实施。

5.数据整合，着眼未来

充分认识到数据整合的重要性，转变传统信息化建设方式，构建统一的数据资源管理系统，以数据反馈指导业务的应用与创新，另一方面充分考虑当前机构改革的现状，运用数据资源管理系统的数据归集整合能力，快速实施数据信息整合全要素管理机构的多方数据，以数据整合为抓手，运用数据服务支撑后续数据融合与业务协同。

1.2  项目建设目标

深入贯彻落实习近平总书记关于全要素管理、防灾减灾救灾、安全生产系列重要论述，充分利用物联网、大数据、地理信息及人工智能技术，全面提升安全生产预防和全要素管理能力。

项目建设目标主要为：

建成相互协调、层次分明、构成合理、相互支持、满足需求的标准体系并贯彻实施，以支持系统的合理建设。

构建统一标准、整合共享的全要素管理数据资源管理系统，充分结合现有全要素管理业务和信息资源，加强信息资源目录统一管理建成全覆盖、高标准、一体化的全要素管理信息资源体系。

融合创新的技术支撑平台体系，实现全要素管理厅所有业务系统、应用支撑和数据支撑所形成的综合性集成整合汇集，实现一体化的安全生产智能化监管平台的快速搭建。

围绕监督管理、监测预警、指挥救援、决策支持、政务管理业务域打造智慧协同的全要素管理业务应用体系，纵向贯通全要素管理机构，横向整合各转隶单位相关系统，快速形成全要素管理一体化综合应用平台；基于数据汇聚融合与业务协同，深入开展大数据分析智能创新应用，充分运用全要素管理“大数据”分析预警能力和“物联网”动态感知能力，提高全要素管理效能，打造全要素管理“一张图”、感知监测“一张网”、布设管理资源“一盘棋”、实现救援指挥“一平台”，服务企业、社会公众、全要素管理机构三个群体，形成“立体化管理”的新格局，并为下一步的业务深入融合与业务创新打下基础。

按照国家等级保护有关规定与要求，依托政务云基础安全环境，建设一个由策略、防护、监测和恢复组成的完整安全体系，从而最大限度地保护信息不受诸多威胁的侵犯，确保信息化系统运行连续性，将损失和风险降低到最小程度。

1.3  总体建设任务

安全生产监测预警系统主要建设内容包括：

搭建数据资源管理系统实现原有安监业务、防汛抗旱、森林防火等新整合的业务和在建新业务系统的数据采集、清洗、转换、整合，并做好与全要素管理相关单位的数据共享交换，补充完善全要素管理数据资源中心数据；

全要素管理大数据分析与应用系统，对采集整合后的数据进行有效的分析、利用，为全要素管理提供决策辅助，并通过大数据的分析预警协助全要素管理综合监管平台优化扩展，完善全要素管理业务，做好管理指挥救援管理体系建设，提升管理指挥救援效率；

通过应用支撑系统升级和信息安全体系建设，做好现有业务系统的快速集成与各转隶单位系统的对接，实现一体化的安全生产智能化监管平台的搭建。

运用物联网技术，实现对重大安全生产行业的监测预警，与水利、气象、旅游、公安、交通、农业等部门实现监控视频及物联监测信息对接，提升安全生产事故的监测预防能力。

利用大数据分析、人工智能等先进技术，对多源异构数据进行多维耦合分析，实现智能预警、综合研判、态势分析，为监管专业、监测预警、指挥救援等提供辅助决策能力。

1.4  总体设计方案

1.4.1  总体建设框架

本工程安全生产监测预警系统总体建设框架图如下：

安全生产监测预警总体建设框架图

1、信息交互层

门户层包括面向企业服务的互联网门户网站（含电脑版、移动版等多种形式）、安全生产监测预警工作门户、外部单位数据交换API网关等，是企业和政府业务人员访问不同网络不同系统的入口，根据不同的访问权限，通过信息交互层（门户）可以访问系统提供的不同服务。

2、业务处理层

应用系统是支撑业务工作的核心，在现有应用框架上进行功能升级和完善，包括三大部分，即以企业多维档案为主线的协同监管类系统、为双重预防提供支撑的政务端和企业端服务系统，为行政专业提供支撑的智能辅助专业的业务知识库和行政专业系统。业务处理层还将为监测预警提供接口和数据支撑。

3、应用支撑层

采用开放技术标准，通过通用功能组件和特定功能组件，以及根据业务需求对组件进行相应配置或二次开发，提供通用应用基础支撑、移动应用支撑、门户集成、工作流引擎、自动化报表引擎、身份认证、访问控制、授权管理、地理信息、内容管理、数据处理等服务，为应用层系统开发提供支撑。

4、信息资源层

信息资源层主要是各类业务应用系统处理的信息，针对四大类业务应用，分别建设企业多维档案库群、双重预防政务库群、双重预防企业库群、行政专业业务库群，以及用于大数据分析的监测预警知识库群和预警预测分析库群。同时，应充分整合利用外部数据资源，助力安全生产监管各项业务工作的开展和决策。信息资源层的各类数据将为监测预警模型和可视化分析系统提供支撑。

5、基础设施层

安全生产监测预警系统将依托政务云平台计算平台，为业务应用系统提供网络传输服务、计算服务、存储服务、备份服务等基本服务和运行基础环境；升级完善网络信息系统，加强移动网络建设，满足各类信息处理要求，全面联通机构和备份中心，实现跨地域、跨层级、跨部门的数据流和业务流的流转。

6、信息安全保障体系

持续升级安全防护体系，满足安全分级保护和等级保护要求。加强安全保密建设。完善身份认证和授权管理；健全完善基础设施、应用系统和数据资源安全保障机制，完善跨网安全交换机制，提升全天候全方位感知网络安全态势能力。

7、运行维护体系

以可视化运维监控管理平台为支撑，实现对各个办公区、各个系统、多类设施的全面覆盖，优化完善运维机制及信息系统全生命周期管理；全面建立健全和完善基础设施运维系统、应用运维系统、数据运维系统、安全运维系统；建设完善信息系统管理处理平台，提高对各类突发事件的管理响应能力。

8、标准规范体系

标准规范体系是本项目建设的基础，对项目建设具有指导和规范作用。制定标准规范，从基础、技术、管理等方面，对相关内容做出规定，支撑实现全国各级人民法院的互联互通、信息共享、业务协同。本项目中拟对数据技术标准、应用技术标准、安全技术标准、基础设施技术标准及管理标准规范等标准规范进行制定和完善，以指导协同、共享、开放的工程建设。

1.4.2  总体技术架构

根据需求分析，将系统技术架构分为：业务应用、应用支撑、数据支撑、运维管理、基础设施、安全防护等部分，如下图所示：

安全生产监测预警总体技术架构图

技术架构作为信息化规划与建设的基础支撑，在安全生产监测预警系统规划设计和建设中起到关键性的支撑作用。技术架构的建设与完善将提供业务应用开发集成、数据治理、数据服务、应用服务、信息安全防护和IT运维服务等不同层面的有力支撑，同时为安全生产监测预警系统中的应用服务系统建立一个服务于业务应用、具有弹性IT架构、高可用、高安全、高性能、易管理的公用技术支撑环境。

1、访问接入

通过对所有的系统进行统一管理访问接入管理，实现统一用户管理、统一门户管理、统一权限管理、展现分析管理、单点登录管理和移动应用管理，并且通过集成门户为企业提供服务，通过API网关与全要素管理大数据中心的系统实现数据对接。

2、应用支撑

安全生产监测预警系统项目将采用基于微服务架构技术进行系统开发、测试、部署和运维。构建基于微服务架构的通用服务组件、安全组件、会话组件，实现技术服用；构建统一的工作流引擎和自动报表引擎；与安全防护系统相结合，实现系统的访问控制和全链路跟踪；采用DevOps过程方法对系统进行全生命周期的升级与维护。

3、数据支撑

采用数据治理技术，对不同部门和不同系统来源的数据进行数据采集、数据清洗、数据比对、数据转换、数据校核和数据质量管理；通过数据资源目录，建立多种数据库形式的数据格式索引，提供数据共享、数据发布、数据订阅功能；构建基于KAFKA、Spark Streaming和分布式计算技术的模型算法服务，通过3D可视化引擎实现数据分析和监测预警。

4、运维管理

运维管理包括统一服务管理和统一运维管理，统一服务管理是对安全生产监测预警系统在全生命周期中，面向业务变更或数据维护服务管理；统一运维管理是对正在运行的操作系统、数据库、中间件、应用系统、网络环境、计算环境、存储环境和动环系统进行的服务保障。

5、基础设施

安全生产监测预警系统主要部署在政务云平台，不在本次项目建设中，此处不再赘述。

6、安全防护

安全生产监测预警系统的安全防护主要为应用系统的信息安全保障和系统持续化运行保障，具体设计参见“4.4.6 总体安全架构”章节部分。

1.4.3  总体网络架构

本项目依托于政务云平台进行建设，各应用系统根据需求部署在政务专有云和公共云。来自互联网侧的访问通过电子政务外网互联网区访问公共云，并通过网闸进行跨域数据交互。

网络架构图

1.4.4  总体数据架构

数据架构设计需满足如下三个要求：

1、数据集中；

2、数据统一规范、统一编码；

3、数据与外部业务库同步实现及对外提供业务支持服务。

基于安全生产监管业务特点，结合对架构设计要求，本项目总体数据架构设计如下图：

安全生产监测预警总体数据架构图

总体数据架构的数据存储主要由ODS区、数据仓库区、数据缓冲区（交换数据临时存储区）、非结构化数据存储区、元数据及资源信息目录等区域构成：

1、ODS区

ODS区存放集成的、可更新的、近实时的业务数据，在数据中心主要四大类25个业务数据库以及大数据分析数据库。ODS主要用于异构业务数据源的明细数据整合后、进入数据仓库前的存储，并提供面向业务的、近实时的统一数据视图，支持全局业务数据的查询与分析。

除此之外，为尽可能集成既有业务系统完整的数据信息源，并尽量降低对当前业务系统的影响，ODS区还辟有业务数据暂存区，主要存放从既有业务系统后台数据库“全量”备份、不进行任何转换清洗操作的数据库，作为数据库的数据来源之一，在入库时再做相应的数据转换。

ODS是业务系统间公共和共享数据的存储区，是业务系统与数据仓库间的数据迁移的缓存区，是支持数据中心应用中实时查询数据的存储区，是日常业务支持的数据存储区。

2.、数据仓库区

数据仓库(Data Warehouse，DW)存放面向主题的、集成的、相对稳定的、反映历史变化的数据。数据仓库统一存放与管理经整合后、具有分析价值的历史数据与现状数据，支持基于大量历史数据的企业决策分析。

数据仓库具体分为两个层次：

第一层次：Master库：该库中的数据是面向主题存放的，存储从ODS中导出的用于决策支持和挖掘的基础明细数据，也导出操作型数据的轻度汇总数据；数据集市基于数据仓库创建，用于不同业务部门的需求和不同分析应用的分析数据的存储，数据集市的数据来自于数据仓库，并对部分数据进行高度汇总。数据集市模型也按主题组织，但其主题域划分与数据模型不同，数据集市的主题是基于不同部门、不同人员的分析需求而组织的。

第二层次：该层次中包含三类数据，第一类是各类主题数据库（业务系统数据库）形成的数据集市(Data Markets，DM)，是以数据仓库Master数据为唯一数据源、面向特定分析应用、按一定方式重新组织的数据集合，是数据仓库的子集。第二类是数据挖掘库，其数据来源于Master库，专为数据挖掘类应用提供数据服务。第三类是共享信息库，该库中的数据是根据特定业务需求，从Master库中抽取、转换形成的，为安全生产监管业务或其它行业提供数据共享。

3、非结构化数据存储区

在目前的业务系统（如：行政许可审批、一企一档一码）中，存在大量的非结构化数据，如文档、图片、视频等信息。这些数据无法存储在关系型数据库中，未来建设时，需要在数据仓库服务器中划分一块存储区域，存储这些非结构化数据。

4、元数据及资源信息目录存储区

在本项目中，元数据库用于存放ODS和DW中基础库、专题库、Master库、主题库中数据的结构信息。如：数据的类别、采集时间、数据标准、精度、访问权限等丰富的元数据信息。

资源目录用于存放分散在各级部门、各领域、各地区的数据资源信息，通过资源目录体系的建设，形成安全生产监管业务统一管理和服务的资源目录体系，为使用者提供统一的数据资源发现和定位服务，实现部门间数据资源共享和管理。

5、数据缓冲区

数据缓冲区也即交换数据临时存储区(Exchange Data Store，EDS)，是用来保证数据交换过程中安全隔离和临时存储的存储区，其数据结构与接入的应用系统保持一致。其次，该区域也可作为在数据整合过程中，对数据进行清洗、转换的临时存储区。

1.4.5  总体安全架构

信息安全的总体要求是针对不同安全保护分级信息系统应该具有的基本安全保护能力提出的安全要求，根据实现方式的不同，基本安全要求分为基本技术要求和基本管理要求两大类。

技术类安全要求与信息系统提供的技术安全机制有关，主要通过在信息系统中部署软硬件并正确的配置其安全功能来实现；管理类安全要求与信息系统中各种角色参与的活动有关，主要通过控制各种角色的活动，从政策、制度、规范、流程以及记录等方面做出规定来实现。基本技术要求从物理安全、网络安全、主机安全、应用安全和数据安全几个层面提出；基本管理要求从安全管理制度、安全管理机构、人员安全管理、系统建设管理和系统运行维护管理几个方面提出，基本技术要求和基本管理要求是确保信息系统安全不可分割的两个部分。

安全生产监测预警系统的总体安全架构如下图所示：

安全生产监测预警总体安全架构图

根据对安全生产监管业务需求分析，从安全域的角度可分为数据安全域、网络安全域、应用安全域（含物联网感知终端接入）、主机安全域和物理安全域。各安全域之间通过边界防护设备进行相应的隔离，在各安全域内部，根据地理位置、功能和重要程度又划分为不同的安全区域，各区域之间通过访问控制列表ACL进行相应的隔离。

方案设计侧重于实现对信息、信息系统的安全保护，不同级别的信息系统应具备不同的安全保护能力，设计目标如下：

应具有能够对抗来自大型的、有组织的团体（如一个商业情报组织或犯罪组织等），拥有较为丰富资源（包括人员能力、计算能力等）的威胁源发起的恶意攻击、较为严重的自然灾难（灾难发生的强度较大、持续时间较长、覆盖范围较广（地区性）等）以及其他相当危害程度（内部人员的恶意威胁、设备的较严重故障等）威胁的能力，并在威胁发生后，能够快速恢复绝大部分功能。

信息安全系统设计方案：

1、在进行等级保护的具体工作规划时，可以参考方案中各个框架的描述来策划安全策略、需求分析、安全措施选择等各个部分的工作。

2、在考虑安全建设时，可以依据本方案中对于相关的技术和管理的基本要求和安全目标进行分析。

3、在具体的信息系统使用到本方案进行规划、设计和建设时，也将用作相关系统建设进行等级保护测评和备案时的文档资料。

1.4.6  总体部署架构

一、逻辑部署架构

安全生产监测预警系统建设包括访问接入、应用服务、数据服务和基础设施等部分，按照所承载的业务需求和信息安全等级保护要求，分级部署在访问接入，应用服务和数据服务三个区域。逻辑部署架构示意图如下：

安全生产监测预警总体数据架构-逻辑部署架构图

逻辑部署架构从安全生产监测预警系统建设需求出发，综合考虑技术需求、系统功能需求、非功能性需求，为物理部署提供参考依据。

逻辑部署架构并不能完全决策物理部署架构，因为物理部署架构要综合考虑预算、原有IT资源、系统扩展需要等制约因素，但逻辑部署架构是物理部署架构设计的最重要的输入件之一。

在进行逻辑部署架构的设计过程中，我们采用这样的思路组织设计内容：首先设计每一类系统（主要的信息系统）的逻辑部署架构；再将这些部署架构合并到一起，同时综合考虑运维管理方面的需求，形成完整的系统逻辑部署架构。

如上图所示，为了更清晰地描述本项目的逻辑部署架构，设计将按照阶次结构分为接入服务、应用服务和数据服务三个层次描述部署相应服务所需的物理环境。

1、接入服务

（1）负载均衡器，统一为所有前置系统提供访问入口，将客户端请求分散到各域、集群中的各个受管服务器上，同时在部分受管服务器出现故障时将请求自动转发到其它受管服务器上，从而避免出现单点故障。

（2）接入服务器：接入服务器主要用于部署前置服务应用系统、门户系统、门户中间件、BI展现工具等。如果业务访问量大，建议组成群集系统用于业务访问。

2、应用服务

（1）应用服务器，应用服务器主要处理系统的应用逻辑，用于部署应用中间件、基础支撑平台、企业多维档案系统、双重预防系统、行政专业系统、监测预警系统等。对于安全生产监测预警系统这样关键的应用系统，系统的每一个环节都要保障无单点故障，应用服务层也不例外，同时考虑要系统的并发压力，应用服务器建议是集群模式，且分别部署在两台以上主机或分区。

（2）基础支撑平台是应用系统的基础支撑框架，其中包括基础组件（标准组建）、业务组件（扩展组件）、工作流引擎、报表引擎及统一访问控制等。

3、数据服务

（1）部署关系数据库，存储和管理所有关系结构存储的本级业务库、安全生产监测预警系统所涉及的工作资源库等。采用并行处理模式。

（2）SAN存储，为业务数据库提供存储空间。

（3）如有必要，建议部署NAS存储，为非结构化数据提供存储空间。

二、物理部署架构

部署物理环境建议参考下图所示搭建：

安全生产监测预警总体数据架构-物理部署架构图

安全生产监测预警系统对外服务采用API网关技术是本期项目建设的主要部分，在部署架构（物理）设计时，为了满足未来3-5年的需求，结合高可靠、高可用，可扩展设计理念，建议项目建设初期的云环境部署时，采用一比一环境配置（如需要20台虚拟机，生产环境10台，测试环境10台）。

1.5  关键技术路线

1.5.1  应用架构选择

近两年中台服务架构的思想越来越流行，传统的烟囱式架构随着业务发展，越来越庞大、越来越笨重，缺点越来越凸显出来。中台服务架构正与微服务的思想大体一致，体现出去中心化、天然分布式的架构理念，“大中台、小前台”的架构也逐渐成为了主流。中台服务架构的主要特点包括：

1、服务重用

普通架构为了迎合业务发展不停的打造各种系统，导致各系统间的重复功能建设和维护带来的重复投资，打通烟囱式系统间交互的集成和协作成本高昂。系统中台架构真正体现微服务理念的核心价值，通过松耦合的服务支撑便捷的业务复用。

2、数据累积

普通架构各系统数据都由各系统独自管理，导致数据之间的关联融合、数据复用、数据积累相对薄弱，容易形成数据孤岛。系统中台架构中，各个业务的数据都沉淀在同一套中台服务中，可以不断累积数据，进行数字化运营，通过对中心核心数据的分析，更加精确地对业务进行调整和优化，全方位动态调整资源利用，最终发挥大数据威力。

3、快速响应

普通架构如果需要多种数据时，需要与各服务进行沟通，获取数据后，独自进行数据组装，独立完成数据计算，相同的数据与计算重复开发，响应速度慢，沟通成本大。系统中台架构能够更快地通过共享服务的组合响应新业务，所有的数据和业务计算统一管理，标准相同，统一处理，对外共享，可以快速响应新业务。

4、服务进化

普通架构只共享单薄的业务，各业务的标准不统一，可能共享方式多种多样，其他系统集成需要适应每一套共享方式和标准，研发成本高昂，研发周期长。系统中台架构随着共享数据类型、数据模型、共享接口的多样化，共享服务从之前共享单薄的业务功能不断进化，适应各种业务线，进化为更健壮更强大的共享体系。

5、降低成本

普通架构对于一些重复性无法共享的资源只能进行重复开发，增加了开发成本；因为开发的程序增多，则维护成本也需要进一步增多；如果新业务涉及的业务较为繁杂，则需要与各业务系统进行沟通，增加了沟通成本等等，重复工作成本投入大。系统中台架构对于新业务，无需再投入重复的开发成本，开发人员更专注某一领域，开发更快，更易维护，减少新系统整体成本。

综上所述，安全生产监测预警系统项目建设中，应用系统均采用中台架构进行构建，避免出现孤立的系统和数据，同时也使得系统间的互通、协同更加便捷，系统开发和维护更加简单。

1.5.2  服务架构选择

随着互联网技术的发展和业务的需求，传统的IT建设已经满足不了客户的需求，因此IT架构也需要作出相应的改进，来支撑企业的数字化转型。随着信息化技术的不断发展，服务架构已形成了两种主流的结构模式，即基于面向对象的SOA结构模式和基于分布式的微服务模式。

从两种服务架构模式看，分别具有不同的特性：

（一）SOA结构特性

1、SOA架构是面向服务的，只不过是基于面向对象

SOA继承了很多面向对象的特点，比如说面向对象的封装，经常代表很多类封装成一个模块，为其他对象调用者提供接口调用，良好的面向对象设计就是暴露接口，隐藏实现，类比到SOA的设计，SOA也需要精准明确地定义好服务接口，具体服务内部的逻辑实现都是隐藏在背后的，只不过有两个很大的区别：

（1）面向对象的实现都是基于同一个编程语言或平台（同构），但SOA服务彻底隐藏了实现上用何种语言平台的具体细节（异构）

（2）面向对象的实现其实大部分都是本地方法之间的调用，当然也具备分布式远程方法调用，但SOA是纯粹提供了独立的服务，面向分布式的远程服务调用。

2、SOA的服务定义是精确的

SOA的服务一旦发布出来，会有很多其他的异构平台服务进行调用，使得服务接口的修改会产生较高成本和具有一定的技术风险，可能涉及到一个大型企业多部门的信息协作，或者对构件已经形成依赖的生态链条。因此这就牵扯出了SOA另外一个特征，那就是服务接口的粒度一般要设置得比较粗。若提供过多的服务接口，服务又定义得很细粒度，那么频繁修改是在所难免的。

（二）微服务结构特性

1、适合体系健全、制度稳定的重管理型企业，每个微服务组件都是简单灵活的，能够独立部署。不再像以前一样，应用需要一个庞大的应用服务器来支撑。

2、业务逻辑复杂，服务的独立性，开放性需求又大，服务的稳定性也是刚需，微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。

同时，微服务更容易的扩展，它基本上是独立的，不可分割的，更容易的发布新的版本。

3、可以由一个小团队负责更专注专业，更高效可靠。

代码开发中可实现前后端分离，即前端和后端的代码分可在技术上做分离，并且更容易的实现物理分离部署。前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。因此，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。

4、微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。

由于微服务模式可在分离模式下进行开发，前端可通过不同开发工具多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的web UI\ 移动App等访问。

微服务带来的价值主要有：

1、技术独立

微服务可采用不同的编程语言与工具进行开发，降低微服务的技术门槛。

2、单一职责

每个服务都比较简单，只关注于一个业务功能，可以根据需求实现服务水平扩展,同时解决新人培养的问题；拥有更小的代码库维护起来更简单也更快捷，节省了开发成本和时间，从而提高了生产效率。

3、系统松耦合

微服务架构方式是松耦合的，可以提供更高的灵活性，可以实现每个微服务独立部署，不再需要协调其它服务部署对本服务的影响，服务变更不影响其它服务使用，增加敏捷性，随时可以增加新的业务功能，并快速上线。

4、团队自治

每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度，添加新的功能，不需要重写整个应用。

5、快速开发与交付

微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性，主要解决服务交付周期长问题。

综上所述，在技术选型方面，前端将采用Vue3+TypeScript+Element Plus的技术组合，后端采用Spring Boot+Spring Cloud Alibaba的微服务架构，数据库采用MySQL+TimescaleDB的混合方案，大数据处理采用Flink实时计算框架。针对物联网设备接入，我们将开发专用的协议转换中间件，支持Modbus、OPC UA等工业协议的无缝对接。同时，系统将内置完善的权限管理机制，支持RBAC权限模型，确保数据访问安全可控。因此，安全生产监测预警系统项目建设中，应用系统均采用微服务架构模式。

1.5.3  系统研发与测试环境

一、开发工具与技术栈

1、开发工具

选用先进的开发工具进行系统模块的开发工作，包括前端页面开发工具、后端业务逻辑开发工具、数据库设计与管理工具等。确保工具能够满足敏捷开发模式的需求，支持迭代开发、持续集成和持续交付等方式。

2、技术栈

前端采用兼容 TypeScript 和 JavaScript 的技术，结合相关的前端框架实现各业务模块数据功能的集成展示，支持菜单栏多功能切换等特性。后端基于 Springcloud 等框架，利用高效的算法和数据结构，结合缓存技术和数据预取机制，提高系统性能。数据库选用主流的关系型数据库或非关系型数据库，根据项目需求进行合理设计与管理。

二、网络环境

1、网络架构

搭建稳定、安全的网络架构，保障开发过程中数据的传输与交互。确保开发环境与测试环境、生产环境之间的网络隔离，防止数据泄露和干扰。同时，配置相应的网络设备，如路由器、交换机等，保障网络的畅通。

2、安全策略

实施严格的网络安全策略，包括防火墙配置、入侵检测系统部署等，防止未授权访问和网络攻击。开发人员接入内网办公环境需遵守相关规定，严禁使用未经授权的设备和软件。定期对网络安全进行检测和评估，及时发现并解决安全隐患。

三、环境部署与管理

1、环境划分

明确划分开发环境、测试环境和生产环境，各环境的配置和参数应根据实际需求进行设置，确保环境的一致性和稳定性。开发环境用于日常的软件开发和调试工作；测试环境用于对开发完成的功能模块进行测试和验证；生产环境用于最终的系统部署和运行。

2、部署流程

制定详细的软件安装部署计划，按照计划在目标环境中进行软件产品的安装部署。确定安装所需的资源和信息，并向甲方提供相关支持。在安装过程中，确保软件编码和数据库按照合同规定初始化、执行和终止，并对安装事件和结果进行记录。

2、环境管理

建立完善的环境管理机制，对各环境的配置、版本、运行状态等进行实时监控和管理。定期对环境进行维护和优化，确保环境的性能和安全性。同时，做好环境备份工作，防止因环境故障导致数据丢失和系统瘫痪。

1.5.4  移动应用技术路线

目前移动端服务载体主要有两个方向，一种是微信H5，另一种是手机APP。微信H5是一种技术，依附的外壳是是浏览器。该项技术演进已经接近10年，相对成熟。通过H5页面设计可以非常丰富的展现各种功能，而且由于其本质是浏览器可以方便的在页面内嵌各种第三方链接，使得WEB端的很多内容可以得到复用。

而手机APP是一种应用，运行的环境是手机操作系统。手机APP相对于H5能获得更多的系统权限，相较H5页面能够实现复杂的业务逻辑、功能也更加多样化；同时微信小程序的代码加载后在操作系统层运行，省去了通过浏览器渲染的步骤，因此手机APP大幅提高了流畅性，各个页面的切换、跳转等体验非常顺滑。但其缺点是首次使用需要下载安装。

考虑到接入端作为个人，其企业相对稳定，首次下载后，后续都可使用，获取成本虽高，但在接受范围之内。同时考虑到APP的功能多样性、操作感好，因此，安全生产监测预警系统项目建设中，移动端将采用手机APP的形式。

2  详细建设方案

2.1  应用支撑平台建设

2.1.1  应用服务支撑框架

安全生产监测预警系统业务流程较为复杂，且业务会逐渐变得更加复杂的系统，单体应用将十分庞大，后期难以修改和维护，应考虑使用微服务架构。

为了满足业务需求，项目中引入了众多的技术栈，中间件，单体应用会给开发者带来很大的困扰，应考虑将应用拆分成多个独立部署的采用最优技术栈实施的微服务。

高并发的，有高可用和弹性伸缩需求的系统，往往是那些面向庞大数量互联网用户的平台类、交易类系统，应考虑利用微服务架构便于横向扩展和弹性伸缩的特性。

单体应用版本发布成本高，而单个微服务的变更和发布都很容易，那些有高频率版本发布需求的系统，应使用微服务架构。

没有数据实时强一致要求，可接受数据最终一致的系统，可使用微服务架构。

因此，在管理救援领域中：

OA、HR、绩效等管理类系统并不需要微服务架构；

安全生产监测预警系统等应用如果体积庞大（几十万行代码以上），要使用微服务改造；

综合监管、行政专业、监测预警等系统由于系统压力大，可以采用微服务架构。

本项目将从这九个方面来解析微服务关键技术架构与设计。

2.1.1.1  前端UI框架

兼容性方面：

Vue是流行的前端框架，其对浏览器的兼容性较好，主流的操作系统和浏览器都支持。

vue响应式双向数据绑定实现自动同步

vue.js采用数据劫持结合发布者-订阅者的方式，通过Object.defineProperty()来劫持各个属性的setter，getter，在数据变动时，发布消息给订阅者，触发相应的监听回调。

具体的来讲，Vue.js通过Directives指令去对DOM做封装，当数据发生变化，会通知指令去修改对应的DOM，数据驱动DOM的变化。vue.js还会对操作做一些监听（DOM Listener），当我们修改视图的时候，vue.js监听到这些变化，从而改变数据。这样就形成了数据的双向绑定。

2.1.1.2  微服务容器

服务运行的容器环境

微服务运行容器，要做可靠高效的微服务架构应用，实际上该项目需要做的事情还是非常多的。如果没有一个统一的微服务容器，这些能力在每个微服务组件中都需要建设一遍，而且会五花八门，也很难集成到一起。

(一)负载均衡：微服务容器的基础服务能力之一就是支持负载均衡。

1、通常所说的负载均衡都指的是服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备，比如F5等；而软件负载均衡则是通过在服务器上安装一些具有负载均衡功能或模块的软件来完成请求分发工作，比如Nigix等。

2、硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备时，该设备按照某种算法（比如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端的地址，然后进行转发。

3、客户端负载均衡和服务器负载均衡最大的不同点在于上面所提到的服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端的清单来自于服务注册中心，建议使用Spring Cloud Netflix 的Ribbon组件。

（二）服务熔断、容错、升降级、限流

微服务容器的基础服务能力之二就是服务熔断、容错、升降级、限流，在系统出现异常时提供故障恢复能力。

2.1.1.3  注册中心

服务注册与发现：

注册完成后，单块应用之间互相调用时配置个IP就行了，但在微服务架构下，服务提供者会有很多，手工配置IP地址又变成了一个不可行的事情。那么服务自动注册发现的方案就解决了这个问题。

服务注册发现能力是依赖SpringCloud Eureka组件实现的。服务在启动的时候，会将自己要发布的服务注册到服务注册中心，运行时，如果需要调用其他微服务的接口，那么就要先到注册中心获取服务提供者的地址，拿到地址后，通过微服务容器内部的简单负载均衡器进行路由。

通常情况，系统内微服务的调用都通过这种客户端负载均衡的模式进行，否则就需要有很多的负载均衡进程。跨业务系统的服务调用，也可以采用这种去中心化的路由方式。当然采用SOA的模式，由中心化的服务网管来管理系统间的调用也是另一种选择，要结合企业的IT现状和需求来决定。

2.1.1.4  配置中心

（一）集中配置管理

微服务分布式环境下，一个系统拆分为很多个微服务，一定要告别投产或运维手工修改配置的方式。需要采用集中配置管理的方式来提升运维的效率。

配置文件主要有运行前的静态配置和运行期的动态配置两种。静态配置通常是在编译部署包之前设置好。动态配置则是系统运行过程中需要调整的系统变量或者业务参数。

要想做到集中的配置管理，那么需要注意以下几点：

1、配置与介质分离，这个就需要通过制定规范的方式来控制。千万别把配置放在Jar包里。

2、配置的方式要统一，格式、读写方式、变更热更新的模式尽量统一，要采用统一的配置框架

3、运行时需要有个配置中心来统一管理业务系统中的配置信息，这个就需要平台来提供配置中心服务和配置管理门户。

（二）配置修改同步交互

配置修改后通过推送或者定时拉取的方式更新并缓存到应用程序所在的微服务容器中供应用程序使用。

（三）高可用运行架构设计

配置中心有两种部署模式

1、高可用模式，见上图，支撑大规模微服务访问时根据负载情况可以对“配置查询同步服务”进行横向扩展

2、ALL-IN-ONE模式，配置变更服务、配置查询服务合并为一个进程。适合支撑少量系统的场景使用。

配置中心可以支持高可用模式部署，满足金融行业的要求。

2.1.1.5  监控中心

基于Skywalking定制实现

SkyWalking主要就是通过收集各种格式的数据进行存储，然后展示。所以我们需要关注的是 SkyWalking Collecter、SkyWalking UI 和 存储设备。

（一）APM探针

JavaAgent 是JDK 1.5 以后引入的，也可以叫做Java代理。

JavaAgent 是运行在 main方法之前的拦截器，它内定的方法名叫 premain ，也就是说先执行 premain 方法然后再执行 main 方法。

使用agent技术构建一个独立于应用程序的代理程序（即为Agent），用来协助监测、运行甚至替换其他JVM上的程序。使用它可以实现虚拟机级别的AOP功能。

（二）APM全链路运行监控

调用链跟踪分析：把同一TraceID的Span收集起来，按时间排序就是timeline。把ParentID串起来就是调用栈。

实时分析：对单条日志直接分析，不做汇总，重组。得到当前QPS，延迟。

离线分析：按TraceID汇总，通过Span的ID和ParentID还原调用关系，分析链路形态。

2.1.1.6  日志中心

日志中心架构：

日志分析是运维工程师解决系统故障，发现问题的主要手段。日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。

项目实施中，日志被分散的储存在不同的设备上。如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志，即繁琐又效率低下。为此，我们使用集中化的日志管理，将所有服务器上的日志收集汇总。

集中化管理日志后，日志的统计和检索又成为一件比较麻烦的事情，这时实时日志分析ELK平台能够完美的解决上述的问题，ELK由ElasticSearch、Logstash和Kiabana三个开源工具组成。

规范日志与流水，问题追根溯源：

作为一个微服务应用平台除了提供支撑开发和运行的技术组件和框架之外，还应该提供一些运维友好的经验总结，我们推荐的日志与流水实现如下：

1、首先看日志，平台应提供的日志主要有三种，系统日志，引擎日志还有跟踪日志。有了这些日志，在出问题的时候能够帮助我们获取一些关键信息进行问题定位。

2、问题能够追根溯源，流水号的设计也是非常重要的，日志与各种流水号配合，能够快速定位问题发生的具体时间地点以及相关信息，能够快速还原业务交易全链路。对这些日志与流水的细节处理，对于系统运维问题定位有非常大的帮助，没有这些有用的日志内容，ELK日志收集套件搭建的再漂亮，收一堆垃圾日志也是没用的。

开源框架只是提供个框架有开发人员自由发挥，而设计一个平台则一定要考虑直接提供统一规范的基础能力。

2.1.1.7  API Gateway

基于Spring Cloud Netflix的Zuul组件定制实现：

异步非阻塞模式启动的线程很少，一个CPU core上需启一个处理线程，使用的线程资源很少，上下文切换(Context Switch)开销也少。非阻塞模式可以接受的连接数大大增加，消息请求只需要进队列，这个队列的容量可以设得很大，只要不超时，队列中的请求都会被依次处理。

API Gateway逻辑架构：

API网关是整个系统的门面，所有的外部访问都经过它实现调度、过滤、请求路由、负载均衡、校验等等。

API Gateway 功能：

API网关上还可以实现更多更复杂的功能。详见本项目技术分册技术专题部分描述。

2.1.1.8  IAM（Identity and Access Management）

IAM架构：

IAM为该项目提供统一的账号管理视角，对所有基于ID的管理、认证、授权、审计进行集中的统一管理，提高了数据管理的安全，帮助系统管理员提高了工作效率，降低了管理负担，同时改善了安全生产监管人员在不同资源中登录认证的重复繁琐过程，为日常工作提供了更高的安全性。

统一用户中心：

IAM可以为本项目所有的资源使用人员如普通用户、系统管理人员、开发人员、技术管理者等工作人员等定义主账号，按照技术实施的组织方式对人员进行管理。通过一对一的主账号管理模式，可以在该平台实现对所有资源使用人员进行集中定义、集中维护等生命周期管理。

统一认证与鉴权：

安全认证方面，基于Spring Security结合Auth2再加上JWT(Json web token)做安全令牌，实现统一的安全认证与鉴权，使得微服务之间能够按需隔离和安全互通。认证鉴权一定是个公共的服务，而不是多个业务系统各自建设。

2.1.1.9  微服务管理

服务管理机制：

（一）服务提供者：

1、服务注册

在服务注册时，需要确认下eureka.client.register-with-eureka=true参数是否正确，默认为true，若设置为false将不会启动注册操作。

2、服务同步

由于服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。

3、服务续约

eureka.instance.lease-renewal-interval-in-seconds参数用于定义服务续约任务的调用间隔时间默认30秒。

eureka.instance.lease-exptration-duration-in-seconds参数用于定义服务失效时间，默认为90秒。

（二）服务消费者：

1、获取服务

当启动服务消费者时候，会发送一个REST请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑，Eureka Server会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30秒更新一次。

2、服务调用

当应用系统在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据。因为有这些服务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例。

单服务异常导致雪崩：

采用微服务架构后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务。

在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，造成所谓的雪崩效应，这样的架构较传统架构更加不稳定。

自我保护：

当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，而微服务本身是正常运行的，此时不应该移除这个微服务，所以引入了自我保护机制。

服务注册到Eureka Server之后，会维护一个心跳连接，告诉Eureka Server自己还活着。Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况，Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。

服务容错处理：

1、资源隔离：包括线程池隔离和信号量隔离，限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用

2、降级机制：超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。

3、熔断：当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复。

4、缓存：提供了请求缓存、请求合并实现。

2.1.2  业务服务基础框架

2.1.2.1  统一门户引擎

（1）单点登录

系统提供单点登录功能。SSO(SingleSingOn)单点登录，是指用户只需要进行一次登录，就可以访问到所有的授权服务，即可获得需访问系统和应用软件的授权服务，在此条件下，管理员无需修改或干涉用户登录就能方便地实施希望得到的安全控制。这是一个为了能够在分布式计算机环境中，安全和方便的鉴别用户而产生的课题。

在此次建设中，通过该功能用户只要登录一次就可以在授权的不同业务系统之间切换，不需要重复的输入用户名和密码。这不仅能够提高工作人员的工作效率，同时能够增强工作人员利用信息化的热情，为推进信息化的建设和深入起到推动作用。

（2）统一菜单管理

统一菜单管理实现对同一类用户同一类角色的功能菜单统一的管理和定制。通过统一管理，方便对不同用户和角色功能的维护和管理。

（3）统一门户定制

统一门户定制是以人为本的信息集成服务，包括：内容聚集和个性化表现、搜索服务、Web应用访问、个性化定制及单点登录体验等应用，存在于与最终用户进行个性化的交互中，实现个性化的内容、内容展示、页面与风格等，满足每个最终用户的不同需求，极大的提高了用户的使用体验。

2.1.2.2  用户管理引擎

用于对所有用户进行编码管理和维护。包括以下功能：

（1）添加、删除、修改用户，查询用户，查看用户详细信息；

（2）修改用户细粒度权限，不同的权限意味着用户对于系统资源的访问能力不同；

（3）修改用户所属的部门，并实现某些用户信息的保密功能；

（4）方便克隆用户、批量删除、批量修改用户权限的功能；

（5）分级用户管理功能。某些管理员可以管理系统中所有的用户，而某些管理员只能管理本部门的用户；

（6）日志功能，对于每次操作进行跟踪，保证系统的可靠性，并为组织人事部门的监控管理提供支持；

（7）用户管理与组织机构设置密切相关，注册人员时，首先选定所注册人员的部门，写入个人相关信息，注册结束后，系统自动将此人放置到选定的部门中，并赋予该部门的默认权限。

（8）系统支持全部用户的模糊查询，并有对指定对象进行确认、增加、删除和修改的权限。

（9）用户管理按照分布式的方式管理，以不同机构、角色进行分类管理，维护界面简单易用，无需专业技术人员参与。

2.1.2.3  组织机构管理引擎

用于进行编码管理和维护。具有管理员权限的用户可以通过本功能以可视化或表格化的方式新建或修改相应的部门信息。

管理方式以树状的组织机构管理形式表现，管理员可以方便地按照编码进行组织机构信息的查询、增加、删除、调整及维护。

具体功能有：

支持无限级的部门组织结构；

添加、删除、修改部门，查询部门，查看部门详细信息；

批量删除、移动部门、移动用户功能，支持人员调动和机构重组；

支持部门领导管理，可以设置每个部门的上级分管领导和部门的实际领导；

组织管理。系统会根据部门的级别动态设置下级机构的级别，还可以根据部门的名称动态生成部门领导职务，使得部门管理更加简单、方便；

部门用户管理，可以通过部门管理直接进入该部门的用户管理；

分级部门管理功能。某些管理员可以管理系统中所有的部门，而某些管理员只能管理本部门和相关的子部门；

日志功能，对于每次操作进行跟踪，保证系统的可靠性，并为组织人事部门的监控管理提供支持。

2.1.2.4  权限管理引擎

在部门编码的基础之上添加不同的工作权限，这些权限是与用户人员的实际职务分配相一致的。

具有管理员权限的用户可以新建和维护权限编码，管理员可以规定不同的权限所能够具备地对平台中相应的业务系统功能数据库的访问或是管理权限，然后再将平台内部的所有用户添加到相应的权限组中，实现不同的用户具有不同的系统访问和管理权限。

按照分布式的方式管理，以不同角色设计、不同权限、不同专业或者产品编码分类，维护界面简单易用，无需专业技术人员参与。

可以设置细粒度权限，不同的权限意味着用户对于系统资源的访问能力不同。

支持无限级的权限层次结构，每个用户支持超过1000个细粒度权限。

强大的日志功能，对于每次操作进行跟踪，保证系统的可靠性。

2.1.2.5  表单引擎

表单引擎是安全生产监测预警系统应用支撑平台的一个重要特点。也是本平台实现对在业务办理过程中的各种各样的表单的灵活定制。使业务人员就可以轻松定义各种表单并建立起与数据库的关联，从而可以很方便快捷的完成数据表格的修改。

（1）文档类表单定义编辑

文档类表单是指业务表格以类似WORD文档的形式出现的，在这种情况下，我们可以定义相关的数据元素，并定义它们与数据库之间的关联关系。模板中还有一个重要作用是定义显示格式。本模块支持各种类WORD文档格式。使得系统可以与实际文字表格材料以相同的方式在浏览器上显示并进行相关操作。

（2）表格类表单定义编辑

在数字信息处理过程中，具体业务操作人员需要针对不同类型的业务类型、不同部门进行数据的采集和填写，他们所要处理的都是跟他本人业务相关的各种表单，这些表单在每一个不同的业务中的表现方式和显示内容往往是不一样的。我们的表单编辑可以在word、excel中完成并导入。针对数字信息管理表单特点，本平台对流程中的表单进行组织和管理。我们采用XML对表单进行表示，采用schema对表单的标准进行描述。表单引擎根据标准将各个表单组织起来，对外提供标准的接口，通过接口可以操作表单。这样在具体的业务中，相关人员可通过表单引擎实现对表单的操作和数据的定制。

智能表单页设计器：基本操作同Office产品以及流行的网页编辑产品类似。提供了多种工具和输入插件，可以设计出不同风格的表单。用户只需要将HTML格式的表单粘贴到表单编辑器之中，表单设计向导会指导完成其它所有的操作，用户不需要具备任何编程的能力。可以根据应用需要生成多种格式的表单，包括但不限于HTML表单，JSP表单等等。

（3）表单组合

自动数据绑定：设计好的表单页中的数据可以自动和各种数据源进行绑定。对于关系数据库来说，会根据表单页的具体情况自动在数据库中创建数据表，包括相应的子表。表单页中填写的数据可以自动存储到相应的数据库表之中去，完全不需要任何编程。

表单测试：表单设计者设计完表单之后可以立即测试，验证表单是否满足要求。

表单样例：表单设计者为使用者提供的样例表单，在用户实际填写的表单上会显示出来。

（4）基本数据格式定义配置

表单引擎对“表格类表单模板定义编辑”模块和“文档类表单模板定义编辑”模块提供基本数据格式定义的基本操作。

（5）表单精确打印

表单引擎提供100%纯HTML开发的用于生成电子表单的工具。应用此引擎可以设计应用程序表单模板，通过此模板产生应用程序以完成在Web上实时，自动生成电子表单。具体来说，就是利用此可视化开发工具生成一个中间文件，之后系统内部的软件包的分析程序可以对中间文件进行处理，并自动生成作为服务器端完成电子文档生成工具的应用程序。

（6）智能表单数据处理

数据自动比对：当用户修改表单数据时，可以记录修改项；可以实现表单数据的自动比对，将比对的结果生成报告。

数据自动填写：可以根据业务数据之间的关联关系，自动将表单中的关联数据预先自动填写到表单之中，减少用户的输入次数，实现“一表式”填写。可以自动将相关联的数据进行加载，用户只需要进行少量的修改和填写工作即可。

数据验证：可以根据需求定制客户端验证，包括单个表单字段的验证、多个字段的关联验证。可以根据需求开发服务器端验证插件，实现灵活的服务器端验证，并且将验证的结果自动返回到表单界面上。

可以导出到Word，Excel等格式的文档中并从Excel文档和TXT、XML文档中导入，这就可以实现同其他系统和OA系统的部分数据接口的兼容。

2.1.2.6  工作流引擎

工作流引擎是一个底层的应用支撑平台。要从技术上实现招标文件的要求以可视化的方式灵活定制业务流程、支持丰富的过程逻辑、多样的活动类型。一个必然的方案是使用工作流引擎。

但只用工作流引擎来远远不够。经过我们分析，目前的工作流引擎或是因为过于通用化而要做太多的再开发工作和配置管理工作，或是因为是专用于某些商业领域而无法用于本项目。

因此我们的基本思路是在传统工作流引擎思想的基础上为此项目开发专用工作流引擎。这个专用工作流引擎的一个基本特点就是针对安全生产监测预警系统的业务特点对流程进行了分类，并在分类的基础上定义了业务工作流模板。

进行业务流程定制的人员可以直接使用流程模板，也可以在它们基础上进行修改来适应更复杂的业务情况。

安全生产监测预警系统应用支撑平台将使用强大的工作流引擎。它是遵照工作流管理联盟（WFMC）的标准接口，支持分支、并发、循环、子过程、同步、异步、竞争、多工作流、活动组、静态活动等。引擎不仅支持顺序流程的流转，而且还支持分支、并发、循环、子过程、同步、异步、竞争、多工作流、活动组、静态活动等，在分支上可以定义条件，实现按条件自动流转，条件转移之间还可设置逻辑关系；在并发流转中，多个活动节点可以同时激活；在某些活动节点上，也可以通过创建子过程来完成任务。

工作流的核心模块包括：从流程建模、流程引擎、流程角色管理及流程监控等。

2.1.2.7  业务规则引擎

业务规则引擎是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

大多数业务流程包含多个决策点。在这些决策点处，将对某个条件进行评估。业务流程根据这些标准或业务规则更改它们的行为。以前将这些规则嵌入到业务流程本身或自定义Java代码的内部，但规则引擎很好的把它们人代码中撮出来。具体包括以下功能：

规则引擎支持通过配置文件进行规则的定义与配置。

与流程引擎对接，通过配置文件中的规则对流程进行控制。从业务流程中以单独实体的形式提取业务规则可更好地对系统进行分离，从而提高可维护性。

在Web服务层将现有业务规则的解释公开为服务。这样，多个业务流程便可以重用这些服务，从而实现面向服务体系结构(SOA)的承诺。

规则引擎可以对规则集进行并行和按顺序的评估。此外，规则能够对输入数据和中间数据的值进行评估并确定是否应引发规则。

其它典型特性包括：

(1)包含耦合和复杂的逻辑

(2)支持使用并行执行进行高效的业务逻辑评估

(3)包含基于多个业务规则评估构建的复杂返回结构

(4)允许将域逻辑转换为简单规则

(5)实现高度易变的业务策略

2.1.2.8  日志与审计引擎

系统每天会产生海量的安全事件；操作系统的系统及安全日志；大量的数据库、网络和主机的用户操作行为。通过对以上信息集中管理，并实现有效的关联分析，可以发现其中的安全故障和隐患，保障系统的安全。

日志管理

日志管理可以及时收集被管系统中所有设备、应用系统、数据库运行产生的日志，对收集到的日志信息根据一定的规则和需要进行集中管理。

日志管理支持多种日志格式的分类、筛选和最大效率保存；提供了对日志的导出、导入、备份、删除、查询和设置等功能。提供对所有日志进行本地备份功能，对历史日志，提供按时间段的删除功能。根据需要可对日志记录进行自定义条件的查询。根据需要可对日志记录的内容、时间等进行设置。

应用行为审计

根据本项目的业务需要，业务系统的用户较多，使用部门涉及较广，使业务系统面临了更大的风险。除了Internet的病毒、黑客攻击外，还可能有内部恶意行为和误操作，都直接影响着业务系统的稳定运行，为了保障业务持续可用和保障业务信息安全，需要进行应用审计，加强对系统应用的安全管理。

主要审计内容包括（不限于）：

记录应用日志，包括事件的日期、时间、发起者信息、类型、描述和结果、相关的操作的核心数据；

探测应用服务的关键进程运行情况；

Apache产生的error.log文件里的启动和错误日志。

审计综合统计

系统可以提供强大的审计记录的查询和统计以及分析，可对日志与行为审计管理内的各项监控信息进行综合统计，并对特定的审计内容制定统计报表，定期对重大的审计事件进行分析并产生相关的预警信息。

用户可以根据需要自定义查询统计条件，系统可提供用户需要的行为审计相关的统计数据。具体包括（不限于）：

结合用户的真实身份，进行命令级的审计和访问控制的统计报表；

基于时间跨度的跟踪及数据量统计；

基于指定事件的列表和分析报告。

2.1.2.9  报表引擎

报表引擎根据定义的报表主题及它的算法，在人工或日程安排

报表引擎输出的数据信息，经报表解释接口实现它的解释，并生成相应的报表展示给用户。用户也可以根据实际需求，随时调整报表主题及算法的定义语言，再重新运行报表引擎时，报表引擎立即根据定义后的内容进行处理，产生经过改变后的报表数据。这样，报表引擎可以跟随用户的需求变化，而所需求的维护量非常少，也非常简单，灵活。

对于报表的输出格式，在报表引擎的输出接口中，定义要求的报表格式；当用户打印报表时，报表引擎根据定义的格式打印所需的报表；同时，如果用户需要改变报表的样式时，可以非常即时、灵活的重新定义，以满足用户的各种需求。

2.2  应用系统建设

2.2.1  统一门户

2.2.1.1  监管专业管理平台门户

2.2.1.1.1  概述

在安全生产监测预警系统已建政府端用户统一门户基础上，通过扩展门户展示信息内容、增加集成应用、提高门户效能等优化提升，建立业务系统专项政府侧统一门户，作为各级全要素管理部门对内展示资源的窗口，是所有数据、服务、应用的统一出口，是政府侧用户登录平台、访问数据和调用功能的唯一入口，为政府侧各类用户使用和共享平台资源提供一站式服务，通过建立统一用户认证中心，解决政府用户多头登录的问题。

2.2.1.1.2  门户布局设计

门户布局包括用户个性化设置、通知公告提醒、工作提醒、待办事宜、个人信息维护、欢迎信息等功能。

2.2.1.1.2.1  用户个性化配置

支持样式、颜色等个性化配置，并且不影响他人使用效果。系统提供多种样式主题，用户可自行选择个人喜欢或符合自己习惯的视觉主题；

2.2.1.1.2.2  通知公告提醒

提供通知公告提醒模块，可对未读的通知公告进行标注提醒，可直接点击未读公告打开公告详情页面。

2.2.1.1.2.3  工作提醒

提供工作提醒模块，系统可自动抓取需政府用户关注的业务信息，并进行统一提醒，如企业超期未整改隐患、许可证到期提醒等。

2.2.1.1.2.4  待办事宜

提供待办工作提醒模块，显示当前用户需要处理或审核的业务信息，如待审批的事项、待审核的申请信息等。

2.2.1.1.2.5  个人信息维护

提供个人信息维护功能，可调整修改个人电话、邮箱等信息，定期修改系统登录密码。

2.2.1.1.3  应用功能集成

为集成的业务系统功能设置功能图标，系统提供三种功能图标样式：常规状态、鼠标滑过状态、点击状态。点击对应功能图标，通过单点登录的方式跳转至对应集成业务系统功能模块中。

2.2.1.1.3.1  企业数据中心

提供企业数据中心管理功能的应用集成，通过点击应用功能图标可无缝衔接至企业数据中心管理系统，可对企业基本信息、行业信息、安全监管信息、行政处罚信息等进行统一的监督管理。

2.2.1.1.3.2  行政许可审批系统

提供企业数据中心管理功能的应用集成，通过点击应用功能图标可无缝衔接至行政许可审批系统，可实现对企业申请的各项行政许可事项进行线上审批，对企业行政许可信息进行日常管理和维护功能。

2.2.1.1.3.3  行政专业管理系统

提供企业数据中心管理功能的应用集成，通过点击应用功能图标可无缝衔接至行政专业管理系统，可实现对企业的各类专业信息和案件信息的全过程线上管理功能。

2.2.1.1.3.4  双重预防体系系统

提供企业数据中心管理功能的应用集成，通过点击应用功能图标可无缝衔接至双重预防体系系统，可实时掌握企业双重预防体系落实情况，企业风险分布、隐患治理情况等。

2.2.1.1.3.5  重大危险源备案系统

提供企业数据中心管理功能的应用集成，通过点击应用功能图标可无缝衔接至重大危险源备案系统，可实现对企业申请的重大危险源备案信息的线上受理和审核，可实时动态掌握重大危险源备案信息。

2.2.1.2  监管专业企业平台门户

2.2.1.2.1  概述

建立业务系统专项企业侧统一门户，作为企业用户登录平台、访问数据和调用功能的唯一入口，为企业用户使用和共享平台资源提供一站式服务，通过建立统一用户认证中心，解决企业用户多头登录的问题。

2.2.1.2.2  门户布局设计

门户布局包括用户个性化设置、通知公告提醒、待办事宜、个人信息维护、欢迎信息等功能。

2.2.1.2.2.1  用户个性化配置

支持样式、颜色等个性化配置，并且不影响他人使用效果。系统提供多种样式主题，用户可自行选择个人喜欢或符合自己习惯的视觉主题；

2.2.1.2.2.2  通知公告提醒

提供通知公告提醒模块，可对未读的通知公告进行标注提醒，可直接点击未读公告打开公告详情页面。

2.2.1.2.2.3  待办事宜

提供待办工作提醒模块，显示当前用户需要处理或反馈的业务信息，如监测预警待反馈信息、隐患待整改信息等。

2.2.1.2.2.4  个人信息维护

提供个人信息维护功能，可调整修改个人电话、邮箱等信息，定期修改系统登录密码。

2.2.1.2.3  应用功能集成

为集成的业务系统功能设置功能图标，系统提供三种功能图标样式：常规状态、鼠标滑过状态、点击状态。点击对应功能图标，通过单点登录的方式跳转至对应集成业务系统功能模块中。

2.2.1.2.3.1  企业信息管理

提供企业信息管理功能的应用集成，通过点击应用功能图标可无缝衔接至企业信息管理系统，企业用户可通过此功能补充、修改、更新企业基本信息、安全生产、安全投入等信息。

2.2.1.2.3.2  行政许可

提供企业信息管理功能的应用集成，通过点击应用功能图标可无缝衔接至行政许可系统，企业可通过此功能查看已发许可证信息、历史许可申请信息及许可证申请过程中审批部门给企业发送的各种通知信息。

2.2.1.2.3.3  重大危险源管理

提供企业信息管理功能的应用集成，通过点击应用功能图标可无缝衔接至重大危险源管理系统，企业用户可通过此功能进行重大危险源的备案申请、变更申请及备案信息管理等。

2.2.1.2.3.4  双重预防体系系统

提供企业信息管理功能的应用集成，通过点击应用功能图标可无缝衔接至双重预防体系系统，企业用户可通过此功能进行企业安全生产风险的辨识、分级管控、日常巡查、隐患登记、隐患整改等工作。

2.2.1.2.3.5  安责险管理

提供企业信息管理功能的应用集成，通过点击应用功能图标可无缝衔接至安责险管理系统，企业可通过此功能完成企业安责险相关线上管理业务工作需求，如安责险保单信息查看、安责险赔付申请、安责险服务申请等。

2.2.1.2.3.6  高风险作业管控

提供企业信息管理功能的应用集成，通过点击应用功能图标可无缝衔接至高风险作业管控系统，企业用户可通过此功能完成高风险做的的报备，特殊作业审批、特殊作业码管理等工作。

2.2.1.2.3.7  “天眼+全要素管理”推送信息处置

提供从“天眼+全要素管理”系统推送的企业违法违规信息的处置和反馈功能，企业用户可通过在线填报预警信息的处置反馈结果，完成预警信息的处置反馈。

2.2.1.3  移动端集成平台

2.2.1.3.1  移动服务支撑

在移动集成服务平台基础上，通过优化集成平台框架、扩展集成移动端应用范围、提高移动端处置工作待办效率等方面，打造贯通掌上办公唯一入口，提升组织体系的执行力和管控力。

2.2.1.3.2  移动应用集成

2.2.1.3.2.1  企业数据中心

企业用户可通过移动端实现企业账号注册、信息完善、密码找回、企业安全档案信息查看等日常管理需求。政府用户可通过移动端对企业申请信息进行审核、查询企业安全档案信息、查询辖区企业统计信息等。

2.2.1.3.2.2  行政许可

政府用户可通过移动端审批企业许可证申请信息，可查询企业现有许可信息就建设项目审批信息，能综合查看辖区内企业许可业务办理情况。

2.2.1.3.2.3  行政专业

政府用户可通过移动端审批专业业务流程，可实现移动端线上专业检查和文书生成，可综合查询专业检查统计情况，支持通过移动端查看并下载专业文书，支持链接蓝牙打印机实现文书的现场打印。

2.2.1.3.2.4  双重预防

企业用户可通过双重预防移动端查询企业辨识的风险信息和登记的隐患信息，可按照风险巡查清单开展风险检查工作，可通过移动端方便快捷的登记隐患信息，隐患整改信息等。

2.2.1.3.2.5  辅助业务

政府用户可通过移动端查询辅助业务库信息，包含MSDS库、法律法规库、案例库等。

2.2.1.3.2.6  安责险管理

政府用户可动过移动端实现对企业安责险的统计分析查看，可掌握辖区内企业安责险交保情况和赔付情况统计信息，实时动态掌握企业安责险相关管理信息。

2.2.1.3.2.7  监测预警

政府用户可通过移动端查看企业监测预警接入情况，接入设备在线的统计分析及企业监测预警实施预警信息和预警处置信息。企业端用户可通过移动端方便快捷的对监测预警信息进行处置反馈，查询查看企业实时和历史预警信息等。

2.2.1.3.2.8  特种作业码

政府用户可通过移动端扫描企业用户提供的特种作业码，并验证企业特种作业证的真伪和有效期等。企业用户可通过移动端，录入特种作业资质及证书信息，并生成二维码进行展示，方便企业管理人员及监管部门对企业特种作业的管控。

2.2.1.3.2.9  “天眼+全要素管理”消息处置

提供移动端处置从“天眼+全要素管理”系统推送的企业违法违规信息的功能，企业用户可通过移动端填报预警信息的处置反馈结果，完成预警信息的处置反馈。

2.2.1.3.3  工作待办集成

2.2.1.3.3.1  审批类待办

可为政府和企业用户提供移动端的审批业务办理，提高审批效率，如行政许可审批类业务、专业流程审批类业务、企业侧的特种作业审批类业务提醒等。

2.2.1.3.3.2  提醒类待办

可为政府和企业用户提供移动端的提醒类业务，如提醒企业定期的进行风险排查、及时的整改隐患和处置预警信息等，提醒政府类用户对企业即将超期的许可证进行延期办理提醒，提醒即将到期未整改隐患的企业及时整改隐患等。

2.2.2  企业安全一码通

2.2.2.1  企业台账

2.2.2.1.1  企业基础信息

实现企业基础经营信息的收集与管理，包含企业注册信息、经营场所、行业信息、主要负责人、企业性质、行业特点、经营地址、生产地址、联系方式等信息，并自动生成一档一码（二维码），实现数据动态更新。系统可实现企业信息的新增、修改、删除、迁出、综合查询等功能操作。由于辖区企业信息数据的巨大，初始化的企业基础信息的主要来源是：企业安全生产管理系统填报、市场管理局法人库的共享数据交换与清洗治理。

2.2.2.1.2  企业组织结构

实现企业间、企业内部组织关系的管理，全面支持集团型企业、社会团体生产经营型企业以及内部部门、车间、班组等安全管理单元的细化，可有效落实企业主体责任的落实，实现安全生产精细化组织和管理，为安全责任层层负责、层层落实建立基础。企业基础信息的主要来源是：企业安全生产管理系统企业填报数据。

2.2.2.1.3  企业安全人员

为了贯彻新安全生产法人人参与的管理准则，人员作为企业日常安全工作的最小参与单元，理应参与到日常安全管理工作中去。系统功能实现人员信息管理以及用户实名绑定与认证，实现企业安全管理人员、企业负责人、企业员工的档案得到精细化管理，并实现层层授权。系统可将安全责任细化至每一个岗位、每一个人员、每一个角色，可通过用户权限匹配，实现个人实名参与安全生产工作，建立每个人员的细化档案。获得实名认证后，可与全要素管理局特种操作证书数据打通，获得人员资质的绑定与互联互通。

2.2.2.1.4  安全资质台账

管理和维护企业的安全生产相关资质、包括安全生产许可证、消防资质、工程资质等行政许可资质。

数据信息来源来自：系统数据登记、企业端报送；

2.2.2.1.5  经营场所台账

管理与登记企业名下真实存在经营和生产的场所，掌握场所位置、场所生产经营性质，有利于监管部门对区域里的被监管对象、风险类型、风险特征、风险级别、相关负责人等信息进行全面掌握。

数据信息来源来自：系统数据登记、工贸企业端报送；

2.2.2.1.6  关键设施台账

管理与登记企业或生产经营场所内部的关键性措施，掌握其设施名称、设施类型、设施风险特征、风险级别、风险类型、巡查频次、是否已纳入工业监控、维修保养记录、检修档案等信息。

数据信息来源来自：系统数据登记、企业端报送；

2.2.2.1.7  特种设备台账

管理企业经营过程中涉及到的特种设备的基础信息、检修记录、维修保养记录等信息。

数据信息来源来自：系统数据登记、企业端报送、市场监督管理局的共享交换数据；

2.2.2.1.8  重点工艺台账

管理与登记企业或生产经营场所内部的重点工艺，掌握其工艺名称、工艺类型、工艺流程中的关键性风险环节、风险级别、风险类型、伤害类型、危险因素等信息。

重点记录重点工艺的关键性风险环节的管理方法，隐患排查方法、风险管控措施、安全负责人、是否纳入监控等。

数据信息来源来自：系统数据登记、企业端报送；

2.2.2.1.9  重大危险源台账

建立重大危险源管理系统，获得企业重大危险源信息、危险源位置、风险级别、能量介质类型、实时监测数据、视频监控数据、历史曲线趋势等数据。

支持查看储罐、装置、仓库等处的液位、温度、压力和气体浓度的实时监测数据、历史数据、报警数据，DCS、SIS系统联锁运行状态，联锁投用、摘除、恢复以及变更历史信息，视频监控画面信息，安全承诺信息；可查看重大危险源物料的最大储量产能和具体实时储量产能分布；支持通过设备名称、编号、重大危险源等级和名称进行精确和模糊查询；可接收各类预警推送信息；也可查看重大危险源的安全评价报告，并支持全文内容查询。

数据信息来源来自：重大危险源监控系统、系统数据登记、企业端报送与申请；

2.2.2.1.10  企业管理资源

管理并登记企业的管理资源情况，包含管理救援队伍、管理预案、储备物资、行业专家等信息的管理与维护。

对储备物资实现统一的数据编码，能够实现企业预警能力评估，同时也能将企业的资源做好战略储备，实现战备化管理。

数据信息来源来自：系统数据登记、企业端维护与报送；

2.2.2.1.11  企业风险管控数据台账

通过数据的汇聚和整理，实现工贸企业风险管控台账的统管，管理内容包含风险名称、风险级别、风险类型、风险位置、详细位置、所属企业、致灾因素、管控方法、管控责任、监控方法、监控参量、介质内容、型号规格、是否监控等内容。

风险管控数据来源：系统登记、工贸企业端安全生产管理系统、重大危险源系统、监督专业系统等。

2.2.2.1.12  企业隐患排查数据台账

实现工贸企业隐患排查、事故隐患信息的汇聚、整理和统管，管理数据内容包含，隐患名称、隐患类型、隐患级别、隐患位置、隐患级别、隐患整改计划、隐患整改措施、隐患整改资金、应急措施、整改时限、整改状态等内容。

数据来源：企业端安全生产管理系统、重大危险源实时监测系统、事故隐患排查系统的数据对接。

2.2.2.1.13  企业安全培训组织情况台账

实现企业组织安全生产培训、内训、考试等形式的培训活动的记录收集、整理和汇聚，实现包含培训主题、培训类型、组织单位、组织人员、人员签到、包含学时、考试成绩、培训课件、发证情况等内容的管理。

培训学时将累计到签到人员的年度学时里，对学时培训不满的工贸企业负责人，系统将予以信息推送与提示。

数据来源：企业端安全生产管理系统。

2.2.2.1.14  企业危险作业情况台账

实现工贸及危化企业危险作业信息的汇聚，通过工贸及危化企业对危险作业的自我流程化管理，包含作业现场勘验、危险作业申请、危险作业审批、电子作业票生成、作业过程管控、关键环节管控、过程数据采集、作业报告生成等功能环节，分析和掌握高风险作业的分布、作业内容。

为专业人员提供明确的作业地点、作业时间、作业内容、作业负责人等信息，便于专业人员进行抽查检查。

2.2.2.1.15  企业主体责任台账

2.2.2.1.15.1  企业安全投入

维护和上传企业的安全费用提取台账和安全费用使用台账记录及上传的文件。

2.2.2.1.15.2  安全标准化等级

维护和上传企业安全生产标准化等级相关信息及证明，包括公布的日期和证书图片。

2.2.2.1.15.3  安全生产责任制

维护和上传企业中政府与主要负责人的安全责任书、企业主要负责人与分管负责人的安全责任书、分管负责人与班组长的安全责任书。

2.2.2.1.15.4  规章制度和操作流程

上传企业的规章制度和操作流程的相关文件信息。

2.2.2.1.15.5  全要素评价

维护和上传企业全要素评价的得分以及评价内容。

2.2.2.1.15.6  企业诚信管理

2.2.2.1.15.7  特种作业人员台账

维护管理企业特种操作作业人员的相关信息。

2.2.2.1.15.8  劳动防护用品发放台账

维护企业劳动防护用品发放情况。

2.2.2.1.15.9  设备清单

维护企业特种设备和生产设备情况。

2.2.2.2  安全生产指数综合评估系统

“安全生产指数”以事故指标（预防指标、发生指标或事故当量）作为分析对象或指数基元，根据分析评价的需要进行指数测算，从而对安全生产的规律进行科学的评估和分析。设立“安全指数”评估模型，并进行统计监测分析和预警，更加全面、及时、准确的反映企业的安全生产情况，生成企业画像。

2.2.2.2.1  企业主体责任落实评估系统

企业主体责任落实评估子系统，以大数据分析为基础，以企业隐患数据为线索，建立一套企业安全生产主体责任落实大数据分析机制，实现对企业、行业、属地的状况、责任、动态的监管，推动精准监管与精细化服务，有效防范各类事故发生。

2.2.2.2.1.1  指标体系管理

企业主体责任落实指标包括安全生产会议、安全生产资金投入、安全生产教育培训和特种作业人员管理、劳动防护用品管理、安全设施和设备管理、职业病防治管理、安全生产检查、危险作业管理、事故隐患排查治理、重大危险源监控管理、安全生产奖惩、事故报告、应急救援，以及法律、法规、规章规定的其他内容，对指标进行量化和统一管理。

2.2.2.2.1.2  责任落实评价模型构建

通过责任落实指标量化值及其指标权重，建立数学模型，得出企业主体责任落实情况，推动精准监管与精细化服务，有效防范各类事故发生。

责任落实评价模型可根据政策、时间等进行动态调整。

2.2.2.2.1.3  责任落实评价数据管理

对接“企业主体责任考核台账”，获取评价模型所需数据，为后续责任落实评价模型的计算提供充实的数据基础。

2.2.2.2.1.4  责任落实评价分析

根据已构建的指标体系，经过统计、汇总、计算得到责任落实评价指数的计算值，并在此基础上，对指数当前状态、历史情况进行分析。

2.2.2.2.1.5  责任落实评价信息发布

根据企业的责任落实信息，自动生成企业主体责任落实评价报告，发布给安全管理机构及各相关部门，辅助企业管理层及各部门的安全管理、决策工作。

2.2.2.2.1.5.1  评价阈值

根据企业主体责任落实程度，确定责任落实阈值，划分为“优、良、中、差” 4个等级。

2.2.2.2.1.5.2  评价指数图

根据责任落实指数值，生成责任落实指数图，对未落实的责任，在指数图进行报警。

2.2.2.2.1.5.3  评价报告生成

自动生成企业主体责任落实评价报告，报告内容应包括：企业主体责任落实指数各指标数据组成，各指标数据分析存在的问题及改进的措施，报告分析描述可人工录入。

2.2.2.2.2  安全生产风险指数评估

安全生产风险指数主要综合考虑企业生产工艺、设备设施、作业环境、人员行为、管理体系等方面因素，通过计算固有风险指数、风险管控指数、补偿措施指数，确定每家企业的最终安全风险。

2.2.2.2.2.1  风险指数评价指标管理

2.2.2.2.2.1.1  指标管理

选取影响企业安全生产风险控制的指标，包括安全员素质和应急预案合理化两项指标，对指标进行量化和统一管理。

2.2.2.2.2.1.2  指标阈值管理

根据历史评价经验进行分析，也可运用数学方法，对各指标在整体风险指标体系中的相对重要程度，确定各指标在风险系统中的权重赋值。

2.2.2.2.2.2  风险指数评价模型构建

根据安全生产风险指数评价的要求和准则，建立数学模型，得出安全生产风险指数值。

可根据模型的应用情况对模型进行修改完善。

2.2.2.2.2.3  风险指数评价数据管理

由企业或管理人员将企业员工的安全素质水平、培训状况、应急预案的合理化评估结果按照指标的量化要求上报至系统，作为风险指数评价的基础。

2.2.2.2.2.4  风险指数评价分析

根据已构建的指标体系，经过统计、汇总、计算得到风险指数的计算值，并在此基础上，对指数当前状态、历史情况进行分析。

2.2.2.2.2.5  风险信息发布

根据企业的安全风险管控信息，自动生成安全生产风险指数图和安全生产风险报告，发布给安全管理机构及各相关部门，辅助企业管理层及各部门的安全管理、决策工作。

2.2.2.2.2.5.1  风险阈值

根据企业各区域特点及风险管控程度，确定安全生产风险阈值，划分为低风险、中风险和高风险等3个等级。

2.2.2.2.2.5.2  风险指数图

根据系统风险指数值，生成风险指数图，对超过警戒的风险点，在指数图进行报警。

2.2.2.2.2.5.3  风险报告生成

自动生成安全生产风险报告，报告内容应包括：安全生产风险指数各指标数据组成，各指标数据分析存在的问题及改进的措施，报告分析描述可人工录入。

2.2.2.2.3  安全生产预警指数评估

安全生产动态预警指数评估是通过数据统计、建模、计算、分析，定量化表示企业安全生产状态指标，并以综合预警指数的形式发布预警报告的信息化系统，可有效提升企业安全生产管理的预防和“免疫”能力，从事故源头降低企业事故风险，实现企业的本质安全。

2.2.2.2.3.1  指标体系管理

从人、物、环境、管理、事故等因素进行预警指标初筛，选取符合安全生产特点的预警指标，对指标进行量化，建立安全生产预警指标体系。

2.2.2.2.3.1.1  指标管理

根据安全生产企业特点选取符合企业安全生产管理特点的预警指标，包括事故隐患、安全教育培训、应急演练及生产安全事故等预警指标，量化后进行统一管理。

2.2.2.2.3.1.2  指标权重管理

根据历史安全数据、事故情况等进行分析，也可运用数学方法，对各指标在整体预警指标体系中的相对重要程度，确定各指标在预警系统中的权重赋值。

2.2.2.2.3.1.3  指标预警阀值管理

根据历史安全数据和经验，确定指标预警的阀值。

2.2.2.2.3.2  预警模型管理

通过预警指标量化值及其指标权重，建立数学模型，得出安全生产预警指数值，表征当前安全生产状态的数值。安全生产预警指标对安全生产预警指数的生成，根据其指标对安全生产状况的影响，产生正向和负向的系数影响。

2.2.2.2.3.3  预警信息接入

实现和预警指标体系相关的业务信息采集，一是对企业信息化系统运行中产生的生产过程实时状态信息和报警信息进行采集和接入，二是对各生产经营单位已有信息系统对接或数据导入方式进行采集和接入，包括隐患排查整改统计信息、事故信息、职业健康信息、培训演练信息、全要素管理信息等安全生产管理信息，建立与各业务系统之间的信息采集接口，实现信息的分类采集和数据交换，为后续预警指数模型的计算提供充实的数据基础。

2.2.2.2.3.4  预警指数评价及分析

根据已构建的指标体系，利用信息接入模块采集的数据，经过统计、汇总、计算得到预警指数的计算值，并在此基础上，对指数当前状态、历史情况进行分析。

2.2.2.2.3.5  预警信息发布

根据不同部门及不同管理层级，自动生成安全生产预警指数图和安全生产预警报告，发布给安全管理机构及各相关部门，辅助企业管理层及各部门的安全管理、决策工作。

2.2.2.2.3.5.1  预警阈值

预警阈值为各等级之间的界定数值，可根据企业历史预警指数值与企业事故发生状况或风险可接受程度来确定预警阈值，划分为安全、注意、警告、危险等4个等级。

2.2.2.2.3.5.2  预警指数图

根据系统不同时刻的预警指数值，绘出安全生产预警指数图，对超过警戒的预警点，在预警指数图进行报警；同时在预警指数图区域内，将企业安全生产预测值曲线在图形上用其他颜色进行绘制，表征未来时间安全生产状态。

2.2.2.2.3.5.3  预警报告生成

自动生成安全生产预警报告，预警报告内容应包括：安全生产预警指数各指标数据组成，各指标数据分析，预警指数与上周期预警指数值比较分析，本期预警指数分析结果，存在的问题及改进的措施，报告分析描述可人工录入。

2.2.2.2.4  安全生产事故指标评估

安全生产事故统计标体系主要针对企业发生的事故大小、伤亡情况、损失情况的信息进行统计分析，反映企业或区域的安全生产的持续水平。

2.2.2.2.4.1  事故指数评价模型

将企业一段时期发生的各类事故，其导致的死亡、伤残（重伤、轻伤）、职业病、经济损失的综合结果进行综合评价，建立企业事故综合危害严重程评价分析模型。

可根据模型的应用情况对模型进行修改完善。

2.2.2.2.4.2  事故指数评价数据管理

由企业或管理人员在事故发生后，将事故的详细信息上报至系统，包括事故起数、死亡事故起数、死亡人数、受伤人数、特别重大事故起数、特别重大事故死亡人数、重大事故率、特大事故率等，作为事故指数评价的基础。

2.2.2.2.4.3  事故指数评价分析

根据评价模型进行计算分析，评估企业安全生产事故的危害严重程度。

2.2.2.2.4.4  事故评价结果发布

自动生成安全生产事故评估报告，报告内容应包括：安全生产事故指数各指标数据组成，评估结果等，报告分析描述可人工录入；按照管理权限将安全生产事故评估结果及评估报告发送给相关部门，辅助企业和管理部门的安全管理和决策。

2.2.2.2.5  安全生产专业指标评估

安全生产专业指数考虑专业力量、专业对象、专业检查和事故查处等方面因素，评估专业效能。包含专业力量、专业对象、专业检查和事故查处等方面的综合评价指标,为安全生产专业效能分析拓展空间。

2.2.2.2.5.1  专业指数评价模型

将专业的情况与企业或区域的事故情况之间建立关联分析模型，分析专业的力度、全面性。

2.2.2.2.5.2  专业数据接入

从现场监督监察、事故隐患与重大危险源监督监察、行政处罚与罚款、查处事故、重大生产安全事故结案及责任追究、非法违法较大生产安全事故结案及责任追究、听证复议诉讼、安全生产培训持证、安全生产许可持证和使用专业文书等情况。

2.2.2.2.5.3  专业指数评价分析

根据评价模型进行计算分析，评估专业的整体情况。

2.2.2.2.5.4  专业分析结果发布

自动生成安全生产专业统计表和统计分析报告，报告分析描述可人工录入；按照管理权限将安全生产专业统计分析结果发送给相关部门，辅助企业和管理部门的安全管理和决策。

2.2.2.2.6  问题整改

企业或管理人员应定期对各个模型的计算结果进行评估，评估其对安全生产状况判断的准确性。当准确性无法满是企业需求时，应及时调整预警指标、指标权重等内容，完成问题整改，并及时上报，保证预警系统的闭环管理。

2.2.2.2.7  区域画像

在“企业画像”基础上绘制 “区域画像”等，形成企业安全生产数据地图，以不同颜色展现区域安全生产现状，反馈各企业、各区域等实时状态，客观评估属地履职情况，查找安全监管漏洞，科学研判安全发展趋势，为精准监管和领导决策提供数据支撑。

风险指某种不安全事件或事故发生的可能性P与后果严重性L的组合。但由于事故发生的时间、地点和社会接受程度对事故后果严重性也存在一定影响，即事故对时间敏感、空间敏感、社会敏感。因此引入敏感性S概念，则风险数学模型可表示为：

R＝f (P，L，S)

式中：R为风险，是事故发生可能性、严重性和敏感性的组合；P为可能性,不安全事件或事故发生的可能性；L为严重性，不安全事件或事故发生可能的后果严重度；S为敏感性，不安全事件或事故发生的时间、空间或系统的影响敏感程度。

因此，区域安全生产综合风险可以定义为某一行政区域（或功能区域）范围内各类生产经营单位发生特定危险情况的可能性、严重性和敏感性的综合表现。

区域安全生产综合风险属于宏观安全风险的范畴，根据风险分级的基本思想，基于风险理论的数学关系：

风险程度=事故发生概率×事故后果严重度×事故后果敏感性

如果能够定量计算出风险程度，则可根据风险程度水平来进行风险分级。但是，区域综合安全风险分级，很难进行精确和定量的风险计算，因此采用定性或半定量的方法进行风险定量。以R＝F(p，l，s)为基础，选择影响风险的指标体系，将指标量化，打分，按照不同的分值确定等级，从而建立风险分级评价模型。

区域宏观综合安全风险评价模型包括事故发生的可能性p，风险事件后果的严重程度l，事件敏感性s三个一级指标。

事故发生可能性p包含区域基本情况、区域固有风险源程度等二级指标；风险事件后果严重度l包含事故及损失指标、全要素管理能力等二级指标；风险事件敏感性s包含社会敏感性、区位敏感性等二级指标，部分指标如下表所示。

2.2.2.2.7.1  指标选取

选取有关“人机物环管”等五个层次以及化工装置、危化品道路运输两个领域的各类属性组成预警指标体系，通过对石油、化工等涉及危险化学品生产、储存的区域进行火灾、爆炸、泄漏、中毒等多种灾难事故的叠加风险分析、定量计算与可视化模拟，实现化工装置、危化品道路运输两大类型的风险源定量化风险评价工作，集个人风险、社会风险、安全风险容量、事故场景、多米诺效应等多功能于一体，为区域范围内的安全生产工作提供决策依据。比如以下指标，对人员密集场所指标分析体系：

2.2.2.2.7.2  建立评估模型

区域宏观综合安全风险分级评价指标分级取值方法有两种，一种为确认赋分型，一种为排序分区取值型。确认赋分型指标通过德尔菲法确定赋分标准，如事故频率，每发生1起较大事故加10分，每发生1起一般事故加5分；排序分区取值型指标需要通过对收集的数据进行排序分区，按照不同区域进行赋值，其具体操作方法如下文所述：

基于帕累托法则（即在任何一组东西中，最重要的只占小部分，约20%，其余80%尽管是多数，却是次要的），对指标取值进行合理分区取值，最终达到指标分级的目的。具体实现过程为：将各区域单一指标的实际数据按照从高到低进行排序，将取值范围平均分为四个区间，前25%为一区，25%-50%为二区，50%-75%为三区，后25%为四区。不同权重指标各区得分不同，详细内容如下表所示。

建立区域综合风险评价指标体系后，依据风险分级评价原理，形成一套区域综合风险分级评价方法，达到科学设计分级管控策略的目的。根据评价区域各项指标的实际情况，对应区域综合风险评价指标体系及不同权重的指标排序分区取值结果，将各项指标的得分相加，得到该区域的风险值。风险计算模型如下所示：

式中：R表示区域宏观综合风险值；Di，Dj，Dk分别为第i, j, k个指标的现实得分。

根据风险分级模型计算出所评价的每个区域的风险值，将各区域按照风险值从高到低进行排序，排名位于前20%的区域为一级风险区域，排名位于20%-50%的区域为二级风险区域，排名位于50%-80%的区域为三级风险区域，排名位于后20%的区域为四级风险区域，遵循“帕累托”法则，如下表。

2.2.2.2.7.3  分析结果可视化

通过对模型的定量计算，做到对石油化工装置和危化品道路运输的定量分析，给出风险等级数值，为区域范围内的安全生产工作提供决策依据。

（1）火灾区域风险评估

区域火灾风险评估，可根据消防救援队伍分布、数量、消防栓分布及数量、灭火器等设备数量及分布、灭火救援设备预警状态、火灾救援预案、消防通道情况监测、火灾防控宣传及培训次数等多个指标因素统计分析，综合评估区域火灾风险。

（2）区域风险预警标识

风险预警，根据企业风险四色划分，对区域的风险也可以同样采用四色标识，对区域通过评估为重大风险的，进行预警，并通过文字描述，说明引起重大风险预警的因素。

各级监管机构通过以上指标的柱状图、饼状图、折线图、数据列表等多个维度的数据展现方式以及相应的预警说明，综合分析区域内的安全生产乃至全要素管理风险，用户辅助各级监管机构及时调配安全生产储备救援资金和物资、救援力量，从而达到降低区域风险的目的。

2.2.2.2.8  行业画像

在“企业画像”基础上绘制“行业画像”，以不同颜色展现不同行业企业安全生产现状，反馈各企业、各行业等实时状态，呈现行业监管薄弱环节和情况趋势变化，并通过“大数据”指导行业查找差距与不足，强弱项、补短板。

2.2.2.2.8.1  危险化学品行业安全生产态势

2.2.2.2.8.1.1  危化品企业地域变化态势分析

根据历史数据，以月度、季度、年度为筛选指标，按照生产企业、存储企业、销售企业、使用企业、运输企业等类型，展示各类危化品企业数量变化态势；通过大数据可视化引擎进行展示。

2.2.2.2.8.1.2  危化品企业规模变化态势分析

根据历史数据，以月度、季度、年度为筛选指标，展示不同规模的危化品企业数量变化态势；通过大数据可视化引擎进行展示。

2.2.2.2.8.1.3  危化品企业所有权隶属变化态势分析

根据历史数据，以月度、季度、年度为筛选指标，展示不同企业所有权（央属、省属、市属、民营、合资、外资）的数量变化态势；通过大数据可视化引擎进行展示。

2.2.2.2.8.1.4  危化品企业经营状态变化态势分析

根据历史数据，以月度、季度、年度为筛选指标，展示危化品企业经营状态（开业、停业、整顿）的数量变化趋势。

2.2.2.2.8.1.5  危化品企业生产环节变化态势分析

根据历史数据，以月为单位，展示危化品生产企业的数量变化趋势、不同种类危化品产量变化趋势；通过大数据可视化引擎进行展示。

2.2.2.2.8.1.6  危化品企业仓储环节变化态势分析

根据历史数据，以月为单位，展示危化品仓储企业的数量变化趋势、不同种类危化品仓储量变化趋势；通过大数据可视化引擎进行展示。

2.2.2.2.8.1.7  危化品企业运输环节变化态势分析

根据历史数据，以月为单位，展示危化品运输企业数量变化趋势、不同种类危化品运输量变化趋势；通过大数据可视化引擎进行展示。

2.2.2.2.8.2  非煤矿山行业安全生产态势大数据分析应用

包括金属非金属矿地域分布态势分析、金属非金属矿经济规模变化态势分析、金属非金属矿所有权变化态势分析、金属非金属矿经营状态变化态势分析等。

2.2.2.2.8.2.1  金属非金属矿地域分布态势分析

根据历史数据，以月度、季度、年度为筛选指标，展示金属非金属矿数量变化态势。

2.2.2.2.8.2.2  金属非金属矿经济规模变化态势分析

根据历史数据，以月度、季度、年度为筛选指标，展示不同规模的金属非金属矿经济规模变化态势。

2.2.2.2.8.2.3  金属非金属矿所有权变化态势分析

根据历史数据，以月度、季度、年度为筛选指标，展示不同金属非金属矿山所有权（央属、省属、市属、民营、合资、外资）的数量变化态势。

2.2.2.2.8.2.4  金属非金属矿经营状态变化态势分析

根据历史数据，以月度、季度、年度为筛选指标，展示金属非金属矿经营状态（开业、停业、整顿）的数量变化趋势。

2.2.2.2.8.3  粉尘涉爆行业安全生产态势大数据分析应用

2.2.2.2.8.3.1  粉尘涉爆企业地域分布态势分析

根据历史数据，以月度、季度、年度为筛选指标，展示粉尘涉爆企业数量变化态势。

2.2.2.2.8.3.2  粉尘涉爆企业规模变化态势分析

根据历史数据，以月度、季度、年度为筛选指标，展示不同规模的粉尘涉爆企业数量变化态势。

2.2.2.2.8.3.3  粉尘涉爆企业所有权变化态势分析

根据历史数据，以月度、季度、年度为筛选指标，展示不同企业所有权（国有、民营、合资、外资）的粉尘涉爆企业数量变化态势。

2.2.2.2.8.3.4  粉尘涉爆经营状态变化态势分析

根据历史数据，以月度、季度、年度为筛选指标，展示粉尘涉爆企业经营状态（开业、停业、整顿）的数量变化趋势。

2.2.2.2.8.3.5  粉尘涉爆生产环节变化态势分析

根据历史数据，以月为单位，展示粉尘涉爆生产企业的数量、产量变化趋势。

2.2.2.2.8.3.6  粉尘涉爆仓储环节变化态势分析

根据历史数据，以月为单位，展示粉尘涉爆仓储企业的数量、仓储量变化趋势。

2.2.2.2.8.3.7  粉尘涉爆物流环节变化态势分析

根据历史数据，以月为单位，展示粉尘涉爆运输企业数量、运输量变化趋势。

2.2.2.2.8.3.8  粉尘涉爆销售环节变化态势分析

根据历史数据，以月为单位，展示粉尘涉爆批发企业数量、零售企业数量、批发量、零售量变化趋势。

2.2.2.2.9  评估报告

依据大数据分析机制成果直观清晰展现“企业画像”、“行业画像”、“区域画像”，根据工作需要生成月、季度、年度分析报告，实现数据的统一输出。主管部门可依据生成的三个“画像”开展差异化专业，对存在薄弱环节较多的企业加强监督检查。

2.2.2.2.10  大屏展示

通过构建综合显示大屏，实时展示企业、行业、区域安全生产数据与评估画像。从宏观上满足重点信息展示、核心指标管理的需要，从中观呈现上满足问题显性化、优先级排序的需要，从微观上强调持续、实时的信息汇报，解决业务报表等诉求，实现一站式智能数据分析平台需要。

2.2.2.3  企业端

2.2.2.3.1  企业安全码

通过分类管理企业安全生产动态数据和静态数据，建立企业主体责任基础指标、正向（负向）补偿指标和“一票否决事项”等指标体系，通过企业自主录入、系统自动抓取，对企业安全生产状况进行赋码赋分管理，生成“企业安全码”，企业用户和政府部门通过扫码便可对企业安全状况一目了然。其作用一是督促企业完成主体责任落实规定动作。二是为日常监管专业提供辅助决策，用于企业分级分类监管；三是用于专业评估，将企业综合得分列入对下级考核的指标体系。

2.2.3  安全生产监管服务

2.2.3.1  安全生产责任保险管理系统

安全生产责任保险管理系统主要包含政府端、企业端、中介机构端及保险机构端四个端。

2.2.3.1.1  政府端

政府端主要包含安责险情况总览、保险机构管理、保险机构查询、中介服务查询、安责险综合查询、安责险累计情况统计、安责险新增情况统计及保险机构安责险统计几部分内容。

2.2.3.1.1.1  安责险情况总览

安责险情况总览模块可对人员单位所在行政区划的企业情况、安责险投保情况、理赔情况、各行业安责险投保情况、各月安责险投保情况、各月安责险投保情况进行统计分析展示。

2.2.3.1.1.2  保险机构管理

保险机构管理模块主要用于保险机构的基础信息维护和查询。主要内容包含保险机构名称、地址、联系人和联系人电话，以列表的形式进行展现，用户通过保险机构名称可对列表细心进行快速搜索查询。列表信息还支持用新增、修改、删除等操作。

2.2.3.1.1.3  保险机构查询

保险机构查询模块用于保险机构的基础信息维护和查询。主要内容包含保险机构名称、地址、联系人和联系人电话，以列表的形式进行展现，用户通过保险机构名称可对列表细心进行快速搜索查询。

2.2.3.1.1.4  中介服务查询

中介服务查询模块主要实现对中介机构服务基础信息的统计和维护。主要内容包含中介机构名称、企业名称、检查日期、检查类型、排查标准数量、不通过项、隐患数及复查结果等内容，并以列表的形式进行展现，列表信息支持用户按着中介机构名称、企业名称、检查类型、检查日期和复查结果等字段信息对列表信息进行快速搜索查询。

2.2.3.1.1.5  安责险综合查询

安责险综合查询主要实现对安责险综合情况进行统计分析展示。

主要内容包含保险机构、保单号、企业名称、行政区划、所属行业、保险起期、保险止期、保单状态、承保方式、理赔次数和保险期服务次数等内容，列表支持用户按着企业名称、行政区划、保险起期、理赔次数、保单状态、保单号、所属行业、保险止期、保险期服务次数、承保方式等字段对列表信息进行快速搜索查找，列表信息还支持用户批量导出操作。

2.2.3.1.1.6  安责险累计情况统计

安责险累计情况统计主要实现对安责险累计情况进行统计分析展示。系统支持按区域、按行业（危险化学品、烟花爆竹、非煤矿山、冶金行业、有色金属、建材行业、机械制造、轻工业、纺织工业、烟草行业、商贸行业其他）对在保企业数、累计保单数、累计保费（万元）、有效保额（亿元）、累计理赔次数和累计理赔金额（万元）以列表的形式进行统计，列表信息支持用户导出操作。用户还可根据查询时间和保险机构字段对列表信息进行快速查询。

2.2.3.1.1.7  安责险新增情况统计

安责险新增情况统计主要实现对安责险新增情况进行统计分析展示。系统支持按着区域行业（危险化学品、烟花爆竹、非煤矿山、冶金行业、有色金属、建材行业、机械制造、轻工业、纺织工业、烟草行业、商贸行业其他）对新增投保企业数、新增投保额（亿元）、新增保费（万元）、理赔次数、理赔金额（万元）及保险服务次数以列表的形式进行过统计，列表信息支持用户导出操作。用户还可根据查询时间和保险机构字段对列表信息进行快速查询。

2.2.3.1.1.8  保险机构安责险统计

保险机构安责险统计主要实现对保险机构安责险累计情况和新增情况进行统计分析展示。累计情况查询包含保险机构、在投保企业数、累计保单数、累计保费（万元）、有效保额（亿元）、累计理赔次数及累计理赔金额（万元）等信息，并以列表的形式进行展现。新增情况查询包含保险机构、新增投保企业数、新增保额（亿元）、新增保费（万元）、理赔次数、理赔金额（万元）及保险服务次数等信息，并以列表的形式进行展现。列表信息支持用户按查询时间进行查询。