济南地铁R2线6标隐患排查研制总结报告

安全隐患排查治理系统项目研制总结报告济南轨道集团有限公司R2线6标安全质量隐患排查治理系统总结报告济南轨道集团及中铁四局集团有限公司

目录TOC\o"2-3"\t"标题1,1"1 项目研究的背景 项目研究的背景建筑施工企业安全质量管理现状建筑业是国民经济的重要产业。建筑安全生产工作是全国安全生产工作的重要组成部分。在国民经济持续快速发展和市场需求的拉动下，建筑业持续快速增长，各地、各部门和各建筑施工企业认真贯彻党中央、国务院关于安全生产的一系列重大部署，深化建筑施工安全隐患排查治理和专项整治，加强安全监管体系和制度建设，加大安全监管工作力度，有效保障和促进了建筑业的安全发展，但是国家统计局发布2014年国民经济和社会发展统计公报中指出，2014年全年各类生产安全事故共死亡68061人，亿元国内生产总值生产安全事故死亡人数为0.107人。其中建筑行业事故依然多发，安全形势依然严峻，安全生产问题仍然十分突出。为促进建筑安全生产形势的稳定好转，落实安全生产“隐患治理年”的各项要求，建筑业各施工企业都在综合分析、深入研究建筑安全生产形势和事故多发的成因，探索安全生产管理新手段、新方法，快速发现和消除事故隐患，以防范事故发生，保障安全生产。目前，国内外建筑施工企业还未利用信息化技术研究开发以安全质量隐患排查治理为主要目标的智能化系统平台。项目研究的意义信息化是当今世界经济、社会发展的趋势，安全生产信息化建设是安全生产工作的基础，是实现安全生产监督管理快速、准确、高效的有效途径，有效应对当前紧迫的安全生产形势，促进企业的科学长远发展意义十分重大。安全质量管理是攸关企业生存发展的一项根本性、长期性工作，是企业持续快速健康发展的坚实基础。在国家经济建设形势进入新常态的大背景下，基础设施建设法治时代、品质为王的时代已经到来。近年来，济南轨道集团及中铁四局转型升级、发展步伐不断加快，生产经营规模不断扩大，安全生产管理压力也随之不断增大，迫使济南轨道集团及中铁四局不得不在安全管理上探索创新，寻求突破。为了弥补传统安全生产管控模式的短板和不足，济南轨道集团及中铁四局依托“互联网+”思维，借助网络化平台和科技手段，研发安全质量隐患排查治理系统，并通过规范化、标准化、信息化的手段，加大对项目的管控力度，防止和杜绝安全质量事故的发生。一是适应国家高度重视安全生产监管的需要。新的《安全生产法》明确要求，各建筑施工企业必须建立生产经营单位负责、职工参与、政府监管、行业自律、社会监督的机制，进一步明确各方安全生产职责；必须建立生产安全事故隐患排查治理制度，采取技术、管理措施及时发现并消除事故隐患等。今年1月14日，国务院安委会下发了《2016年安全生产工作要点》，明确提出要大力倡导建筑施工企业健全事故隐患排查治理制度，强化企业安全生产主体责任落实，实现事故隐患自查、自报、自改的闭环管理。同时，北京市等一些地方政府也制订出台了类似的办法要求。行业监管的大环境已经形成，迫使我们加快安全生产信息化建设，提升安全质量隐患自查自纠水平。二是适应企业自身经营规模快速发展的根本需要。近年来，济南经营规模不断扩大。在项目越来越多、管理跨度越来越大、人力资源越来越紧张的情况下，安全质量管理压力突出已成为项目管理的新常态。仅靠传统的两级公司管控和项建管公司自管模式，难以满足安全质量管理的需要。为此，济南轨道集团与济南轨道集团及中铁四局结合自身实际情况，利用互联网的思维和信息化技术，着力推进安全质量管理信息化建设和应用，强化后台监控、前台自控能力，促进制度、标准有效落地，管理规范高效，从根本上提升安全管理水平。三是充分利用信息化成果提升企业经营管理水平的时代需要。当今社会已进入了以“互联网”为标志的信息化时代。“互联网+”是互联网思维的进一步实践成果，它利用信息通信技术以及互联网平台，将互联网的创新成果深度融合于经济、社会的各领域、行业之中，提升全社会的创新力和生产力，形成更广泛的以互联网为基础设施和实现工具的经济发展新形态。日益成熟的“互联网+”技术，使企业运用现代通讯工具、网络技术进行安全生产管理已成为可能，也是必然趋势。研究内容项目研究目标组织集团及四局各类工程专家，研究制定各专业不同施工阶段的安全质量隐患条目库，建立统一的隐患等级认定标准，依托“互联网+”的网络化平台和科技手段，以安全质量隐患排查治理为主要目标，研发安全质量隐患排查治理系统，建立全局项目安全质量隐患排查治理体系，以预防安全质量事故的发生，为局安全质量管理体系落地提供一个有力的工具。系统应具有以下主要功能：隐患条目库管理功能、基础信息管理功能、排查任务自动生成功能、隐患排查上报治理功能、考核管理功能、查询统计功能、移动办公功能、其他辅助功能等。项目研究的主要内容1.安全质量隐患排查治理过程信息化。利用互联网、手机或电脑等设备实现安全质量隐患排查、上报、整治、验证、消除、监控、统计和考核等，各项数据能够实时传输、查询、统计、分析等。2.安全质量隐患清单及分级管理机制研究。按照桥梁、隧道、地铁、房建等专业分别研究编制安全质量隐患条目清单，并根据隐患可能导致事故的人员伤亡、经济损失、社会影响程度及发生的概率等将隐患按照严重程度从高到低分为四个等级（Ⅰ、Ⅱ、Ⅲ、Ⅳ级）。3.安全质量隐患排查治理流程定制。按照隐患等级、项目类别、排查人员所在单位等情况研究制定不同的隐患治理流程，每个流程节点都一一对应相应责任人，固定工作流程，绑定人员责任。4.自动推送任务和排查频次可配置技术研究。系统可以按照管理办法规定的排查频次在每个周期内给相关人员自动推送排查任务，且排查频次可随时调整，重新配置。5.智能考核计分技术研究。根据制定管理办法中扣分规则和计算公式，对各单位、部门、个人的隐患排查治理工作的执行情况进行自动计分，并生成得分排名表，为考核奖惩管理提供依据。同时系统可根据管理办法的扣分规则进行扣分设置，对隐患排查治理过程中的每一个环节智能打分。6.移动端APP研发。通过在移动端（手机、平板等）安装应用系统，可以在移动端完成隐患查询、隐患上报、隐患整改记录填报和批示、得分排名等操作。项目研究的技术路线本项目采用联合研究开发的方式进行，济南轨道集团与中铁四局共同承担研发任务。并成立研发课题组，由中铁四局主管生产的副总经理牵头，安质部主责，网络中心、技术中心、工管中心等相关部门参与。首先组织技术专家研究制定分专业分等级的隐患条目库、安全质量隐患排查治理管理办法、隐患治理流程等，形成安全质量隐患排查治理系统功能需求说明书。本系统研发主要根据“互联网+”安全质量管理的技术路线。主要技术如下：采用J2EE技术标准本项目采用了J2EE技术架构，以保证技术的兼容性和系统建设的延续性。J2EE是使用Java技术开发企业级应用的一种事实上的工业标准，它是Java技术不断适应和促进企业级应用过程中的产物。J2EE利用Java2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。系统技术体系架构系统程序开发采用分层模式，分层可以“解耦”代码——允许新的组件被添加进来，而且让代码易于维护。程序分层职责上被分成4层。这四层是：presentation(表示)，persistence(持久)，business(业务)和domainmodel(域模块)。每个层在处理程序上都有一项明确的责任,相互之间通过通信接口联系。SOA技术架构本项目涉及到众多数据共享和交互需求，需要建立一个开放的，松耦合的，易于扩展的系统架构。因此，本项目以SOA的架构进行设计和建设，方便和各组成系统间进行数据接驳和功能调用，实现整个系统的松散耦合、提高整个系统的可扩展性。SOA是面向服务的体系结构，是一种分布式的软件模型。SOA的主要组件包括：服务、动态发现和消息。研究过程及阶段整个进度安排分为六个阶段：调研阶段、需求制定阶段、设计开发阶段、试运行阶段、正试运行阶段、实施推广阶段。第一阶段为调研阶段从2014年12月01至2014年12月31日，局副总经理刘勃带领生产口部门负责人到北京轨道交通建设管理有限公司对安全质量信息化管理系统进行了调研学习，再组织子分公司、局指、代局指、项目部安全生产管理人员进行座谈，讨论整体设计思路。再结合我局实际情况，以安全质量隐患排查治理为重点，成立了由主管生产的副总经理牵头，局安质、技术等相关部门主责和参与，伯大瑞尔软件公司承担开发任务的研发团队。第二阶段为需求制定阶段从2015年1月1日至2015年3月31日，本阶段目标为：1.研制隐患清单：分专业研制安全质量隐患条目清单并进行分级管理。2.研制隐患治理流程：按照排查人员所在单位、项目类别、隐患等级研制安全质量隐患排查治理流程，且每个流程节点都对应相关责任人。3.研制管理办法：研制安全质量隐患排查治理系统管理办法，建立三个层级的工作管理组织机构，明确不同岗位、不同业务部门的责任分工。给相关人员制定最低的排查频次，并建立严格的考核机制，保证系统的有效运行。4.研制系统需求说明书：系统应具有基础信息管理功能、隐患排查治理功能、考核管理功能、查询统计功能、移动办公功能、其他辅助功能等各项功能，针对每项功能编制详细的需求说明。培训，对试运行中发现的问题进行修改完善。第五阶段为正试运行阶段从2015年9月15日起在全局300多个在建项目全面推广运用。在此之前，局分层分级对相关人员进行操作培训，局负责对各子分公司、局指的单位管理员进行培训；子分公司负责对本单位代局指、项目部的管理员进行培训；其他人员由本单位管理员负责培训。第六阶段为实施推广阶段系统研发成功后，先在本单位各子分公司、局指、代局指、项目（分）部进行推广应用，在取得良好的效果情况下在中国中铁股份有限公司施工生产单位及全国建筑行业进行推广应用，目前中国中铁17家施工单位都已购买本系统。关键技术研究安全质量隐患排查治理体系建设研究研究制定分级分层的组织管理体系为了落实企业安全生产主体责任，深化安全质量隐患排查治理工作，形成“全员参与、分工负责、齐抓共管”的监管机制，把隐患排查治理工作纳入标准化、制度化（常态化）、规范化的轨道，做到责任到位、逐级响应、整改闭环、工作留痕。根据目前中国中铁股份有限公司下属各施工企业安全质量管理模式，绝大多数均实行局、公司（局指、代局指）、项目部“三级管理”管理机制：局负责工作体系的建立及完善、系统平台的建设、体系有效运转的督促、对公司（局指、代局指）隐患排查工作的监督、指导和组织考核；公司（局指、代局指）是项目安全质量隐患排查治理工作的责任主体，负责所管辖项目部的隐患排查治理工作。项目部是项目安全质量隐患排查治理工作的实施主体，按照各自职责和分工开展隐患排查治理工作。各单位主要领导是本单位隐患排查治理工作的第一责任人。各单位安全质量管理部门是体系运转的主责部门，工程、技术、试验、物资、机械、网络等生产口其它业务部门协同配合实施。日常工作按照“谁主管、谁负责”、“谁排查谁上传，谁发现谁负责闭合后消除”的原则运转。研究制定常态化的运转体系为了保证系统研发成功并能够快速得到有效运行，课题组研制了配套的运行机制。隐患排查治理管控机制隐患排查治理工作的部署：局按照项目分级排查及管控的原则，定期下发在建项目隐患排查及片区管控分工通知文件，要求局和公司安全生产管理部门每季度对所有在建工程项目组织一次隐患排查，项目部按照规定的频次自行排查及上报隐患。隐患的排查及整治：所有排查人员在安全质量隐患排查后的24小时内必须将排查结果上传至系统平台。相关人员按照规定对相关隐患进行响应，根据具体情况发出明确的指令，监督整改措施的落实，按时整改闭合验证。规定Ⅰ级隐患整改期限为10天；Ⅱ级隐患整改期限为7天；Ⅲ、Ⅳ级隐患整改期限为3天。隐患排查治理工作的总结：局每季度都召开管控及隐患排查治理工作总结会议，主管领导参加、指导安全质量隐患排查治理工作。对本季度管控及隐患排查治理情况进行总结，对下阶段工作进行部署。子分公司主管生产领导每季度组织召开一次本单位的安全隐患排查治理专题会。根据当期隐患排查治理情况，对现场安全管理状态与风险状况进行分析，有针对性地提出改进措施，并及时将总结材料上传至系统平台。隐患排查治理工作的考核：局每半年对公司（局指、代局指）的隐患排查治理工作进行全面考核一次；公司（局指、代局指）每季度对项目部考核一次，并及时将考评结果上传至系统平台。研制隐患清单条目并分类分级。分专业成立了13个专家小组共60余人，分桥梁、隧道、路基、地铁及车站深基坑、营业线、四电、房建工程等13个专业和1个通用管理要求，编制了隐患条目，并及时对隐患条目进行动态更新。目前共编制隐患条目清单2865条，其中Ⅰ级242条、Ⅱ级832条、Ⅲ和Ⅳ级1791条。同时，为了便于对隐患分级管理、分级响应，将隐患条目根据可能导致的人员伤亡、经济损失、社会影响程度及发生的概率，将隐患按照严重程度从高到低分为Ⅰ级、Ⅱ级、Ⅲ级、Ⅳ级共四个等级，其中Ⅰ级为重大隐患，Ⅱ级为较大隐患，Ⅲ级和Ⅳ级为一般隐患（Ⅳ级为立即能够整改消除的隐患）。研制隐患排查治理工作流程隐患排查治理流程由隐患上报、各级响应、制定整改措施、隐患治理并填报记录、验证闭合、消除等节点组成。目前，根据自身管理需要，根据隐患等级、项目类别、排查人员所在单位等设计了23个隐患治理流程，共144条路径，满足济南轨道集团及中铁四局各级单位隐患排查治理工作的需要。同时还制定了人员请假流程、项目销号流程、下发整改通知书流程等。每个流程节点都对应有相关处理责任人。排查人员排查发现隐患后，根据隐患等级确定整改责任人，再由整改责任人负责在规定期限内整改，并在系统平台上填报整改记录；隐患整改后，按照“谁发现谁负责闭合后消除”的原则，由隐患上报者进行复核或复查然后对隐患进行消除（销号）。独立项目部Ⅱ级隐患上报治理流程图分层级制定隐患排查频次根据各层级管理人员的职能分工不同，突出“一岗双责、岗岗有责”的安全管理要求，实现全员参与安全质量管理。对局、公司（局指、代局指）、项目部相关安全质量管理人员规定了最低排查频次要求。具体详见下表：研制隐患排查治理的分级响应及时限隐患治理按照隐患等级不同实行分级响应，并按照隐患等级、响应人员所在的单位和职责不同制定响应时限。具体响应时限为：局职能部门和管控组对局层级排查发布的和公司（局指、代局指）报请局关注的Ⅰ级隐患予以响应。响应时限是：由责任人在12小时内在系统平台上予以响应。公司（局指、代局指）对各层级上传或报请本单位关注的Ⅰ级、Ⅱ级隐患予以响应。响应时限是：由主要领导、分管领导、职能部门对Ⅰ级隐患各个环节（除制定整改措施外）均在12小时内在系统平台上予以响应，对Ⅱ级隐患各个环节（除制定整改措施外）均在24小时内予以响应。项目部对各层级发布的各级隐患均予以响应及落实整改。响应时限是：由项目经理对Ⅰ级、Ⅱ级隐患于6小时内在系统平台上予以响应；对Ⅲ级、Ⅳ级隐患，由项目部有关领导（副经理、总工程师、安全总监）于12小时内在系统平台上予以响应。具体详见下表：研究工作考核及责任追究机制分级考核：局负责对子分公司（局指、代局指）单位和单位领导进行考核；其他由子分公司（局指、代局指）和项目（分）部分别组织考核。量化计分：采取扣分制进行考核，每个考核周期内各个单位、部门、个人的基础分数均为100分。单位、部门、个人的最终得分数等于基础分数减去相应的考核周期内所有扣分数。扣分项包括如下：未按频次排查；响应超时；整改超时；虚假整改；被局、公司检查发现隐患；被股份公司、建设单位、安全质量监督单位等检查发现隐患；未按规定创建新中标项目；项目工程状态与现场实际情况不符；未按规定创建用户。加分项包括如下：项目部人员如实上报Ⅰ级、Ⅱ级隐患，并按时整改到位，对隐患上报人和项目部进行加分。责任追究：考核周期期末,各层级根据系统平台统计的分数等分别对考核对象进行追责及处罚。最终得分数作为各层级领导及相关人员年薪绩效考核、评优评先等依据之一。全年平均得分低于90分的单位，每低1分在单位领导人员年薪考核中扣0.1分，排名前三名且全年平均得分90分以上的单位可酌情加分。对问题突出的单位、个人进行通报批评、警告等处罚。隐患排查整治工作不力，未能及时发现并上报相关隐患，或对安全质量隐患未按要求整改闭合而使项目发生严重问题或安全质量事故时，经局调查认定，按照《工程项目管理问责办法》或《安全质量奖惩办法》有关条款对相关责任人加重一级处罚。系统整体架构研究总体设计系统总体架构设计系统总体架构系统总体架构图说明：基础设施本项目要增加如下网络和安全设备：应用服务器，实现负载均衡及双机热备，双核心工作以提高系统的基础网络平台的可用性和可靠性。PC端使用互联网访问本系统，移动端采用3G/4G、WIFI访问本系统。信息资源依靠接口平台，整合、优化、采集基本数据和业务数据，通过接口获取股份公司主数据平台的组织机构编码和AD域账号。应用支撑基于工作流引擎，在系统的审批业务中，依据审批环节、审批时限等，进行预警提醒，对超时办理的进行考核。系统技术架构采用J2EE技术框架本项目采用了J2EE技术架构，以保证技术的兼容性和系统建设的延续性。J2EE是使用Java技术开发企业级应用的一种事实上的工业标准，它是Java技术不断适应和促进企业级应用过程中的产物。J2EE利用Java2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如“编写一次、随处运行”的特性、方便存取数据库的JDBCAPI、CORBA技术以及能够在Internet应用中保护数据的安全模式等等，同时还提供了对EJB（EnterpriseJavaBeans）、JavaServletsAPI、JSP（JavaServerPages）以及XML技术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持EnterpriseJavaBeans，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与大型机系统，这种系统单机可支持64至256个处理器。（这是NT服务器所望尘莫及的）J2EE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足应用的需要。J2EE克服了传统Client/Server模式的弊病，迎合Browser/Server架构的潮流，为应用Java技术开发服务器端应用提供一个平台独立的、可移植的、多用户的、安全的和基于标准的企业级平台，从而简化企业应用的开发、管理和部署。J2EE是一个标准，而不是一个现成的产品。各个平台开发商按照J2EE规范分别开发了不同的J2EE应用服务器，J2EE应用服务器是J2EE企业级应用的部署平台。由于它们都遵循了J2EE规范，因此，使用J2EE技术开发的企业级应用可以部署在各种J2EE应用服务器上。系统技术体系架构分层可以“解耦”代码——允许新的组件被添加进来，而且让代码易于维护。应用程序的分层职责上被分成4层。这四层是：presentation(表示)，persistence(持久)，business(业务)和domainmodel(域模块)。每个层在处理程序上都有一项明确的责任,而不在功能上与其它层混合，并且每个层与其它层分开的，但给他们之间放一个通信接口。表示层(ThePresentationLayer)下面是Struts所负责的：管理用户的请求,做出相应的响应。提供一个Controller,委派调用业务逻辑和其它上层处理。处理异常，抛给StrutsAction为显示提供一个模型UI验证。以下条款，不该在Struts显示层的编码中经常出现。它们与显示层无关的。直接的与数据库通信，例如JDBC调用。与你应用程序相关联的业务逻辑以及校验。事务管理。在表示层引入这些代码，则会带来高偶合和麻烦的维护。业务层（TheBusinessLayer）一个典型Web应用的中间部分是业务层或者服务层。从编码的视角来看，这层是最容易被忽视的一层。而我们却往往在UI层或持久层周围看到这些业务处理的代码，这其实是不正确的，因为它导致了程序代码的紧密偶合，这样一来，随着时间推移这些代码很难维护。幸好，针对这一问题有好几种Frameworks存在。最受欢迎的两个框架是Spring和PicoContainer。这些为也被称为microcontainers，他们能让你很好的把对象搭配起来。这两个框架都着手于‘依赖注射’(dependencyinjection)(还有我们知道的‘控制反转’InversionofControl=IoC)这样的简单概念。Spring的注射提供了SetterInjection(type2)，ConstructorInjection(type3)等方式供我们选择。Spring把程序中所涉及到包含业务逻辑和Dao的Objects——例如transactionmanagementhandler（事物管理控制）、ObjectFactoris(对象工厂)、serviceobjects（服务组件）——都通过XML来配置联系起来。业务层所负责的如下：处理应用程序的业务逻辑和业务校验管理事物允许与其它层相互作用的接口管理业务层级别的对象的依赖。在显示层和持久层之间增加了一个灵活的机制，使得他们不直接的联系在一起。通过揭示从显示层到业务层之间的Context来得到businessservices。管理程序的执行（从业务层到持久层）。持久层(ThePersistenceLayer)典型的Web应用的另一个末端是持久层。这里通常是程序最容易失控的地方。开发者总是低估构建他们自己的持久框架的挑战性。系统内部的持续层不但需要大量调试时间，而且还经常缺少功能使之变得难以控制，这是持久层的通病。还好有几个ORM开源框架很好的解决了这类问题。尤其是Hibernate。Hibernate为java提供了OR持久化机制和查询服务,它还给已经熟悉SQL和JDBCAPI的Java开发者一个学习桥梁，他们学习起来很方便。Hibernate的持久对象是基于POJO和Javacollections。此外，使用Hibernate并不妨碍你正在使用的IDE。在持久层编码中，需要了解如下几点：查询对象的相关信息的语句，Hibernate通过一个OO查询语言（HQL）或者正则表达的API来完成查询。HQL非常类似于SQL--只是把SQL里的table和columns用Object和它的fields代替。你需要学习一些新的HQL语言；不管怎样，他们容易理解而文档也做的很好。HQL是一种对象查询的自然语言，花很小的代价就能学习它。如何存储，更新，删除数据库记录。象Hibernate这类的高级ORM框架支持大部分主流数据库，并且他们支持Parent/child关系，事物处理，继承和多态。域模块层（TheDomainModelLayer）该层是ORM思想的产物，ORM用对象关联数据表，我们将这些对象的集合归为一个专门的层即DomainLayer。域对象是各层之间数据通信的载体。实际上域对象也是一个完完全全的业务对象，如User对象、Book对象。通过对业务的对象化，这有利于业务逻辑的重用。技术框架选择本系统将采取B/S结构，整体架构设计选择分层式架构。按照目前业界流行的B/S结构，整个系统分为表示层、业务逻辑层、数据持久层和域模块层。表示层表示层主要展现给操作用户，如单据录入，报表展示等相关功能的人机交互式接口。表示层只负责把业务逻辑层传递的信息展现给用户和把用户操作的数据传递给业务逻辑层处理，其本身并不涉及到具体的业务逻辑处理。业务逻辑层实现具体的商业逻辑，如信用评估，自动分类，监管措施自动匹配等功能。业务逻辑层只负责具体的业务流程、业务规则的处理，并且把处理信息传递给表示层或者数据持久层处理，其本身并不涉及到用户界面展现、直接数据库操作。数据持久层采用数据库持久层代替传统的JDBC+SQL的模式，可以规范系统设计、代码开发，后期系统维护。数据持久层直接和数据库交互，从而从架构上隔离了业务逻辑、表示层对数据库直接操作的弊端。数据持久层只负责从数据库提取数据和保存数据，并不参与业务逻辑运算和界面展示。域模块层域对象是各层之间数据通信的载体，对业务对象化，有利于业务逻辑模块的重用。表示层框架选择表示层目前流行多种框架，一般都采用MVC的模式，即模型(Model)、视图(View)、控制器(Controller)解决方案。MVC具有组件化的优点从而更易于实现对大规模系统的开发和管理。"Model"代表的是应用的业务逻辑（通过JavaBean，EJB组件实现），"View"是应用的表示面（由JSP页面产生），"Controller"是提供应用的处理过程控制（一般是一个Servlet），通过这种设计模型把应用逻辑，处理过程和显示逻辑分成不同的组件实现。这些组件可以进行交互和重用。可以看出，采用MVC结构开发表示层能更好的进行系统模块划分、流程更加清晰，便于分析人员做出更详尽的设计。也便于系统的维护。目前实现MVC的框架比较多，最著名的老牌MVC框架当属于Struts框架，已经非常稳定和成熟，拥有众多的熟悉该框架的开发人员，就能降低了开发的成本和避免了由于系统工具不熟悉给项目造成的风险。作为一个MVC的框架，Struts对Model、View和Controller都提供了对应的实现组件，对应上面的图，分别进行介绍，并且看看它们是如何结合在一起的。Controller：控制器的作用是从客户端接受请求，并且选择执行相应的业务逻辑，然后把响应结果送回到客户端。在Struts中Controller功能由图中ActionServlet和ActionMapping对象构成：核心是一个Servlet类型的对象ActionServlet，它用来接受客户端的请求。ActionServlet包括一组基于配置的ActionMapping对象，每个ActionMapping对象实现了一个请求到一个具体的Model部分中Action处理器对象之间的映射。Model：MVC系统中的Model部分从概念上可以分为两类--系统的内部状态，和改变系统状态的动作。Struts为Model部分提供了Action和ActionForm对象：所有的Action处理器对象都是开发者从Struts的Action类派生的子类。Action处理器对象封装了具体的处理逻辑，调用业务逻辑模块，并且把响应提交到合适的View组件以产生响应。Struts提供的ActionForm组件对象，它可以通过定义属性描述客户端表单数据。开发者可以从它派生子类对象，利用它和Struts提供的自定义标记库结合可以实现对客户端的表单数据的良好封装和支持，Action处理器对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过ActionForm组件对象实现了对View和Model之间交互的支持。Struts通常使用一组JavaBean表示系统的内部状态，根据系统的复杂度也可以使用像EntityEJB和SessionEJB等组件来实现系统状态。Struts实现时把"做什么"（Action）和"如何做"（业务逻辑）分离，实现业务逻辑的重用。View：Struts应用中的View部分是通过JSP技术实现的。Struts提供了自定义的标记库可以使用，通过这些自定义标记可以非常好地和系统的Model部分交互，通过使用这些自定义标记创建的JSP表单，可以实现和Model部分中的ActionForm的映射，完成对用户数据的封装，同时这些自定义标记还提供了像模板定制等多种显示功能。因此，本项目选择Struts作为表示层框架。业务逻辑层框架选择目前J2EE体系结构中分为重量级和轻量级两种架构。重量级架构指EJB体系，由于EJB2.1规范设计的复杂，以往众多的J2EE项目中成功率非常低，由于其结构复杂，设计、开发、开发维护成本居高不下。在业界引起了一致的讨伐声，鉴于EJB2.1设计的失败，众多J2EE阵营的成员重新制定了了EJB3.0。EJB3.0规范的许多特性倾向于轻量级的架构，同时，由于该规范较新，掌握的人少，如果采用它，对于系统的开发成本和稳定性、维护成本明显增加。鉴于重量级J2EE体系的种种弊端，业界众多J2EE专家提出了轻量级解决方案，这就是目前流行的IOC模式，即反向控制，依赖注入模式。IOC简单的讲就是由容器来控制组件的生命周期、事务处理，把组件的生命周期控制由代码转移到了外部容器，由容器统一配置和管理，达到了组件模块功能的高内聚、组件间松散偶合。从而极大的降低的系统的复杂程度，增加了系统后期的扩容和更容易维护。而IOC容器采用POJO类做为组件，一般的JAVA开发人员只需要关注具体的商业逻辑实现，并不需要过多关注系统技术细节，因为POJO类是普通的javabean。这样就极大的提高了工作效率和更多的项目时间在业务逻辑的实现上。组件之间的关系是通过配置文件配置来实现的，修改组件之间的关系只需要修改配置文件即可。而不用象传统的开发模式，修改组件之间的关系需要修改代码、重新编译。同时，采用IOC模式的系统，组件之间是松散偶合的，也便于单元测试、集成测试，从而保证了系统的健壮性、灵活性。因此，本项目决定采用轻量级的IOC模式作为业务层模式。而具体框架选择上我们选择目前最流行的IOC模式Spring轻量级框架，Spring框架是容器无关的IOC框架。因此，基于Spring框架的系统很容易部署到所有J2EE容器中，如Tomcat、IBMWebsphere、BEAWeblogic等企业级容器。数据持久层框架选择数据持久层的设计目标是为整个项目提供一个高层、统一、安全和并发的数据持久机制。完成对各种数据进行持久化的编程工作，并为系统业务逻辑层提供服务。数据持久层提供了数据访问方法，能够使其它程序员避免手工编写程序访问数据持久层(Persistenelayer)，使其专注于业务逻辑的开发，并且能够在不同项目中重用映射框架，大大简化了数据增、删、改、查等功能的开发过程，同时又不丧失多层结构的天然优势，继承延续J2EE特有的可伸缩性和可扩展性。Hibernate是一种新的持久层ORM映射工具，是JDBC的轻量级的对象封装。Hibernate可以用在JDBC可以使用的任何场合，例如Java应用程序的数据库访问代码，DAO接口的实现类，甚至可以是BMP里面的访问数据库的代码。Hibernate不仅提供了从Java类到数据表之间的映射，也提供了数据查询和恢复机制。相对于使用JDBC和SQL来手工操作数据库，使用Hibernate，可以大大减少操作数据库的工作量。Hibernate是一个和JDBC密切关联的、独立的对象持久层框架，可以搭配各种AppServer、WebServer、EJBContainer共同使用，Hibernate的兼容性仅同JDBC驱动、底层数据库产品间有一定的关系，但是和使用它的Java程序、AppServer没有任何关系，也不存在兼容性问题。而且事实表明Hibernate可以和多种Web服务器或者应用服务器良好集成，如今已经支持几乎所有的流行的数据库服务器（达16种）。在较为常用的数据持久方案中，Hibernate无疑是最优秀的，因此，本项目选择Hibernate作为数据持久层框架。SOA技术架构需要建立一个开放的，松耦合的，易于扩展的系统架构。因此，本项目以SOA的架构进行设计和建设，方便和各组成系统间进行数据接驳和功能调用，实现整个系统的松散耦合、提高整个系统的可扩展性。SOA是一种分布式的软件模型。SOA的主要组件包括：服务、动态发现和消息。服务是能够通过网络访问的可调用例程，它公开了一个接口契约，并定义了服务的行为以及接受和返回的消息。接口通常在公共注册中心或者目录中发布，并在那里按照所提供的不同服务进行分类，就像电话簿黄页中列出的企业和电话号码一样。客户（服务消费者）能够根据不同的分类特征通过动态查询服务来查找特定的服务。这个过程被称为服务的动态发现。服务消费者或者客户通过消息来消费服务。因为接口契约是独立于平台和语言的，消息通常用符合XML模式的XML文档来构造。SOA中的不同角色的相互关系如图：SOA的软件模型涉及到如下技术：WebService也叫XMLWebService。WebService是通过SOAP在Web上提供的软件服务，使用WSDL文件进行说明，并通过UDDI进行注册。XML：(ExtensibleMarkupLanguage)扩展型可标记语言。面向短期的临时数据处理、面向万维网络，是SOAP的基础。SOAP：(SimpleObjectAccessProtocol)简单对象存取协议。是XMLWebService的通信协议。当用户通过UDDI找到WSDL描述文档后，可以通过SOAP调用Web服务中的一个或者多个操作。SOAP是XML文档形式的调用方法的规范，它可以支持不同的底层接口，例如HTTP(S)或者SMTP。WSDL：(WebServicesDescriptionLanguage)WSDL文件是一个XML文档，用于说明一组SOAP消息以及如何交换这些消息。大多数情况下由软件自动生成和使用。UDDI(UniversalDescription,Discovery,andIntegration)是WebService集成的一个体系框架。它包含了服务描述与发现的标准规范。在使用者调用WebService之前，必须确定这个服务内包含哪些方法，并找到被调用的接口定义。UDDI利用SOAP消息机制（标准的XML/HTTP）来发布、编辑、浏览以及查找注册信息。它采用XML格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。AJAX技术为了提升前端用户的访问体验，减少服务器负载。本项目将采用AJAX技术处理浏览器和服务器之间的传输。AJAX全称为AsynchronousJavaScriptandXML，是一种创建交互式网页应用的网页开发技术。传统的WEB应用允许用户填写表单，当提交表单时就向WEB服务器发送一个请求。服务器接收并处理传来的表单，然后返回一个新的网页。这个做法浪费了许多带宽，因为在前后两个页面中的大部分HTML代码往往是相同的。由于每次应用的交互都需要向服务器发送请求，应用的响应时间就依赖于服务器的响应时间。这导致了用户界面的响应比本地应用慢得多。与此不同，AJAX应用可以仅向服务器发送并取回必需的数据，它使用SOAP或其它一些基于XML的协议，并在客户端采用JavaScript处理来自服务器的响应。因为在服务器和浏览器之间交换的数据大量减少，结果我们就能看到响应更快的应用。同时很多的处理工作可以在发出请求的客户端机器上完成，所以Web服务器的处理时间也减少了。AJAX应用程序的优势在于：通过异步模式，提升了用户体验;优化了浏览器和服务器之间的传输，减少不必要的数据往返，减少了带宽占用;AJAX引擎在客户端运行，承担了一部分本来由服务器承担的工作，从而减少了大用户量下的服务器负载。数据库系统的安全措施数据库系统安全与保密的特点从安全与保密角度看，数据库系统的基本特点可以概括为：在数据库中要保护的客体比较多；数据库中数据的生存期限较长，对保护的精度要求更高；数据库的安全涉及到信息在不同程度上的安全；数据库系统中受保护的客体可能是复杂的逻辑结构，若干复杂的逻辑结构可能映射到同一物理数据客体上；数据库的安全与数据的语法有关。数据库的安全与保密还应当考虑到对推理攻击的防范；推理攻击是指从非敏感的数据推理得出敏感数据的攻击方式。从所面临的安全与保密威胁方面来看，数据库系统应该重点对付以下威胁：1.篡改（伪造）篡改就是修改数据，使其不真实。例如，删除定单、发货单或收据等。这是一种潜在的威胁，因为在其造成影响之前，很难发现数据已被篡改。对付篡改的一种实用措施是限制对特定数据的访问。2.损坏数据的真正丢失是一个严重威胁。表格和整个数据库都可能被删除、移走或破坏，这样它们的内容就不可用了。数据被损坏的原因可能是恶意破坏、恶作剧或病毒等。3.窃取窃取数据的隐蔽性很强，甚至当数据丢失已经造成损害时，仍未被发现。数据库系统的安全措施数据库作为一种特殊的信息系统，它的安全保密措施与普通的网络信息系统的安全措施有许多共同之处，当然也有自身的一些特点。数据库的安全与保密措施的主要目的在于：1.保证数据库的完整性包括物理上的完整性(数据不受物理故障(如掉电)的影响，并有可能在灾难性毁坏后重组数据库)、逻辑上的完整性(保护数据库的逻辑结构)、数据库中元素的完整性(保证每个元素所含的数据准确无误)。2.保证数据库的保密性包括用户身份鉴别(保证每个用户是绝对可识别的，从而可对它进行审计跟踪，并可以保证对特定数据的访问保护)、访问控制(保证用户仅能访问授权数据，并保证同一组数据的不同用户可以被赋予不同的访问权限)、可审计性(有能力跟踪谁访问了数据库中的哪些元素)。3.保证数据库的可用性数据库系统对用户应该有友好的界面，可用简单方法访问数据库中所有授权访问数据。为达到上述安全目的，数据库系统需要采取一系列的安全措施：1.数据备份为了防止数据库中的数据受到物理破坏，采用定时全量备份。2.访问日志为了在本系统出错时可以重组数据库，数据库管理系统将维护数据库系统的事务日志，以便用这种日志恢复系统故障时丢失的数据。3.事务管理如果在数据修改期间系统发生故障，数据库管理系统将会面临严重的问题。此时，一个记录甚至一个字段中，有的部分得到修改而其余部分维持原样。为了避免这种错误，本系统采用两阶段修改技术来保护数据的完整性。两阶段修改技术的第一阶段叫做准备阶段。这时，数据库管理系统完成修改所需的信息，进行修改前的准备工作。在此阶段，数据库管理系统收集数据，建立记录，打开文件并且封锁其他用户，然后计算最后结果。简言之，数据库管理系统完成修改所需的一切准备工作，但未对数据库作任何修改。第一阶段的最后一步叫做“提交”，它的任务是把“提交”标志写入数据库。提交标志是两阶段修改技术中两阶段的分界点，它意味着一旦数据库管理系统通过这个分界点后就不再返回，也就是说，一旦进入提交阶段数据库管理系统将开始进行永久性的修改。第二阶段叫做永久性修改阶段。在此阶段中，凡是属于提交前的任何动作都是不可重复的，但本阶段的修改活动本身则可重复多次。因此，若在第二阶段系统发生故障，则数据库中可能包含非完整的数据，但可以重复所有第二阶段的活动，使数据恢复完成。第二阶段完成以后，数据库管理系统将把“事务完成”标志写入系统的日志，并清除数据库中的“提交”标志。4.数据完整性校验为了保证数据库元素的完整性，本系统在数据输入时帮助用户发现错误和修改错误。在本方案中使用的方法有三种：首先，数据库管理系统利用字段检查，测试某一位置的值是否正确；其次，数据库管理系统利用访问控制的机制来维护数据的完整性，以防止非授权用户对主体数据的访问；第三种办法是数据库管理系统维持一个数据库的修改日志。修改日志记录数据库的每次修改，既有修改前的值也有修改后的值。借助于修改日志，数据库管理员可以在出错时“废除”任何修改而恢复数据的原值。5.身份鉴别本系统的数据库系统要求严格的用户身份鉴别。为了进一步加强数据库系统的安全性和保密性，必须对使用数据库的时间甚至地点加以限制。系统隐患条目库研究隐患条目库的研究与制定为了制定符合日常安全管理的隐患条目，更好地达到减少隐患发生几率或杜绝隐患发生的目的，在局原有安全管理办法和制度的基础上，收集法律、法规、规范、标准和政府各级规范性文件对隐患排查治理工作的要求，并在以往发生的各类事故的基础上，找出生产过程中存在的致险隐患，加以深入研究分析，形成隐患排查条目。为了在管理中便于应用，以及在隐患排查治理系统中操作方便，按照专业、排查类别、排查项目，将安全隐患条目分类。根据隐患可能导致事故的人员伤亡、经济损失、社会影响程度及发生的概率，将隐患进行等级划分，分别是Ⅰ级、Ⅱ级、Ⅲ级、Ⅳ级共四个等级。移动端APP总体设计混合模式（HybridAPP）HybridApp是指介于web-app、native-app这两者之间的app,它虽然看上去是一个NativeApp，但只有一个UIWebView，里面访问的是一个WebApp，比如街旁网最开始的应用就是包了个客户端的壳，其实里面是HTML5的网页，后来才推出真正的原生应用。再彻底一点的，如掌上百度和淘宝客户端Android版，走的也是HybridApp的路线，不过掌上百度里面封装的不是WebView，而是自己的浏览内核，所以体验上更像客户端，更高效。HTML5技术HTML5是跨平台的网页程序，这种开放环境通常被称之为“Web标准”的保护伞。HTML5WebSocketWebSocket通过一个单一的Socket实现一个全双工，双向通信的信道，实现了服务端完美的PUSH。与Ajax相比，Ajax技术需要客户端发起请求，而WebSocket服务器和客户端可以彼此相互推送信息；XHR受到域的限制，而WebSocket允许跨域通信。HTML5WebSocket提供了一个真正的标准，可以使用它构建可扩展的实时Web应用程序。此外，由于它提供了一个浏览器自带的套接字，消除了Comet解决方案的许多问题，WebSocket显著降低了系统开销和复杂性，减少不必要的网络流量和延迟。浏览器通过JavaScript向服务器发出建立WebSocket连接的请求，连接建立以后，客户端和服务器端就可以通过TCP连接直接交换数据。HTML5WebSocket在实时Web应用扩展性方面朝前迈出了一大步，HTML5WebSocket可以提供5000：1或1000：1的比例（根据HTTP消息头大小）减少不必要的HTTP头流量和3：1的比例减少通信延迟，这不是一个渐进式的改进，而是一次革命性的飞跃。离线缓存以及速度相对传统的应用,web应用不需要安装，所占空间小的特性使其具备传统软件应用所不具备的优势，然而，目前制约web应用最大的问题在于网络连接不能够无时无处，连接断了，数据也就没了。在飞机上，汽车上，火车上，有很多地方都无法被网络信号所覆盖，因此web应用也就无法使用。HTML5的离线存储使得这个问题迎刃而解。HTML5的webstorageAPI采用了离线缓存。缓存的强大并不止在于离线应用，同样在于对cookies的替代，目前我们经常使用的保存网站密码，使用的就是cookies将密码信息缓存到本地，当需要时再发送至服务器端。然而，cookies有其本身的缺点—4KB的大小和反复在服务器和本地之间传输，并且无法被加密。对于cookies的反复传输，不仅浪费了使用者的带宽、供应商的服务器的性能，更增加了被泄露的危险。WebstorageAPI解救了cookies,据现有的资料，webstorageAPI将至少支持4M的空间作为缓存，对于日常的清单文件和基础信息，应该已经足够使用了，毕竟4KB我们不是都使用了这么多年了？速度的提升方式在于，webstorageAPI将不再无休止的传输相同的数据给服务器，而只在服务器请求和做出更改时传输变更的必须文件，这样就大大节省了带宽，也减轻了服务器的压力。Framework7Framework7是一个开源免费的框架可以用来开发混合移动应用（原生和HTML混合）或者开发iOS&Android风格的WEBAPP。也可以用来作为原型开发工具，可以迅速创建一个应用的原型。Framework7最主要的功能是可以使用HTML、CSS和JS来开发iOS7应用。Framework7是完全免费开源的。简单易用使用Framework7创建iOS7应用就和搭建一个网站一样简单。你只需要一个基本的HTML布局，并且把Framework7的CSS和JS文件引入即可！Framework7不会强制你写任何自定义的标签，也不会通过JS来生成任何额外的内容。你不需要通过JS或者JSON来写页面，只需要普通的HTML就可以。IOS操作风格Framework7是一个针对iOS7的框架。从一开始，她就考虑到如何最方便快捷地实现iOS7上各种惊艳的UI组件，以及复杂的动画和灵活的触摸交互。所以Framework7是你实现像素级精度的iOS7应用的最佳选择。滑动返回：Framework7的一个最大特色就是提供了的滑动返回功能，当你从屏幕左侧向右滑动的时候可以返回到上一个页面。并且，这不是一个A-B动画，她完全跟随你的手指触摸而移动。动态导航栏：就像上面说过的，Framework7让一切都有iOS7的体验。其中一个重要的特点就是动态导航栏。当你切换页面的时候可以清楚地看到导航栏的元素是如何滑动并渐变的。下拉刷新：framework7可能是第一个并且是唯一一个使用原生滚动条实现下拉刷新功能的框架。这就是为什么下拉刷新组件和原生的ios7应用一样完美的原因。UI组件Framework7有大量可以直接使用的UI组件和工具，比如modals,popup,actionsheet,popover,listviews,medialists,tabs,sidepanels,layoutgrid,preloader,formelements等。大部分的组件你都完全不需要写任何JS代码。个推消息推送以PAAS模式，为合作伙伴提供长连接SDK和服务器接入的整体解决方案。通过使用个推技术，合作伙伴服务消息可以推送到其用户客户端，通过IP通道实现消息实时到达。支持文字，图片，链接，自定义透传等形式。图片压缩在安全质量隐患排查系统中，所有隐患都需上传整改前和整改后的照片，为节省流量APP开发出自动压缩图片的功能，用户在选择图片或者拍照之后，APP自动将图片压缩成1024*768，压缩完成后APP再将图片上传到安全质量隐患排查系统中，图片大小压缩到300K以内，压缩到原图片的15%并保证了图片的清晰度。自动更新在打开APP后，系统会自动查询是否有新版本更新。机构和人员多重管理关系关联技术组织机构是对局安全质量隐患排查与治理过程的参与者进行划分，实行的是“三级管理”的制度，即是局、子（分）公司（局指、代局指）、项目部（分部）层级，各个层级分别按照职责及分工开展工作，形成隐患排查与治理工作体系。局职能部门及管控组在隐患排查治理工作中有不同的职责。职能部门包括了安质部、工管中心、技术中心、试验检测中心、局管控组和网络中心。其中局管控组按照片区来划分多个不同的组来管理其下不同的子（分）公司（局指、代局指）。处在第二层组织机构的是子（分）公司、局指和代局指。子（分）公司（局指、代局指）是安全质量隐患排查与治理工作的责任主体，对所管辖项目按规定进行全面隐患排查与治理工作。其中代局指是由子（分）公司成立的，一个子（分）公司可以包含多个代局指，代局指名义上是与子（分）公司同级的。局指与子（分）公司存在业务上的交叉，即同一个由项目部整改完成的隐患可能需要由子（分）公司和局指（代局指）同时确认才能完成整改确认。项目部（分部）处于隐患排查与治理组织机构的第三层，是项目安全质量隐患排查与治理工作的实施主体。每个项目部（分部）负责对本项目部的隐患排查和治理工作。一个子（分）公司包含多个项目部（分部）。如下图，虚线部分代表该项目部（分部）同时分属局指（代局指）。组织机构应区分项目部、项目分部、局指（代局指）、派出机构、子分公司、子分公司职能部门、局及局职能部门。项目部（分部）—组织机构多选时，应能够区别“行政隶属”还是“业务隶属”。组织机构关系图业务逻辑局职能部门、子（分）公司、局指、代局指直接建立在济南轨道集团及中铁四局相应类型下面，如局安质部在局职能部门下面，第一工程有限公司在子公司下面。公司或局指的职能部门建立在对应公司或局指下面。代局指组织单位分部除了建立在对应代局指下面，还要关联到组建代局指的子公司下面。项目（分）部包含三个上级管理机构：局管控组、子（分）公司、（代）局指，如果子（分）公司和（代）局指包括多位分管领导，那么项目（分）部还需要指定对应的分管领导。项目（分）部包括四种类型：独立项目部、局指分部、代局指组织单位分部、代局指参建单位分部。系统根据不同的类型自动选择上报流程。机构设计根据系统现有的项目部（分部）—组织机构多选时，应能够区别“行政隶属”和“业务隶属”的多重领导职责，系统通过树形结构设计解决“行政隶属”的关联，再通过另一个管理表的设计解决“业务隶属”的关联，从而从根本上解决了多重领导的关联。关联关系图如下：项目部行政隶属于子（分）公司，在数据结构上通过父子关系实现；项目部的业务隶属在数据结构上通过关联隐射关系实现；行政隶属只有一个，业务隶属可以多个。根据业务需要，系统可以通过行政隶属也可以通过业务隶属查询统计相关数据。角色设计根据业务需求按角色进行划分，根据隐患整改的流程划分成不同的角色，划分为排查人员、整改填报人员、安质人员、项目部经理、分管领导、主管领导、局职能部门。根据隐患的不同等级将隐患信息通知给不同的人员。局层次、子（分）公司（局指、代局指）、项目部（分布）层次的各个职位具备不同的角色权限。隐患整改和治理的过程将会以角色来通知相关的人员。各类角色默认隐患排查频次设置（具有排查职责的角色登录时自动提示需排查信息）。根据业务需求，一个用户可以与多个角色进行关联，同时一个角色可以对应多个用户，系统设计出用户角色中间表，从根本解决了双向多对多的关联关系，关联关系如下图：系统主要功能隐患条目管理功能隐患条目按照专业、排查类别、排查内容等建库，隐患条目具有编号、整改内容、整改时限、扣分值、罚款金额等属性，每条隐患条目都按照专业+类别+项目+内容（各2位数），编制了唯一的8位数编号，以便隐患条目的管理。在实际使用过程中可以根据管理需要定制个性化的隐患排查清单。基础信息管理功能基础信息管理是对系统内的组织机构、用户、角色、权限、项目基本信息等进行统一管理，是整个系统的基础。通过系统建立子分公司、局指（代局指）及项目（分）部等组织机构，并进行管理关系的关联，实现多头管理关系。通过项目基本信息的维护，明确工程在建状态、分管领导、归属片区、施工进展、项目风险等级、高风险时段等信息，基础信息完备后，系统将自动生成个人的隐患排查任务。机构用户管理模块主要是对系统内的用户、角色、权限、组织机构进行统一管理，所有系统的用户和权限都是通过本模块进行管理。系统管理员和单位管理员可通过本模块进行单位用户和单位角色查询。其中：用户管理功能提供对用户信息的管理，包括机构的新增、修改、删除、查看、查询、功能，授予用户的某个角色以及用户所属组织机构；用户分层级进行管理，局信息员管理局用户及子分公司、局指（代局指）信息员角色，公司、局指（代局指）信息员管理本单位用户及项目（分）部信息员角色，项目（分）部信息员管理本项目（分）部用户。单位用户查询功能提供对用户加入系统时间和禁用时间的查询，可查询某时间段账户有效的用户。组织机构模块是对局安全质量隐患排查治理过程的参与者进行划分，实行“三级管理”制度，即局、子分公司（局指、代局指）、项目（分）部层级，各个层级分别按照职责及分工开展工作，形成隐患排查与治理工作体系。系统根据业务需求按角色进行划分，根据隐患整改的流程划分成不同的角色，划分为排查人员、整改记录填报人员、项目经理、分管领导、主管领导、职能部门等不同流程角色。局、子分公司（局指、代局指）、项目（分）部层次的各个职位具备不同的角色权限。隐患整治过程将会以角色来通知相关的人员。用户角色查询功能是对用户授予某个角色时间和清除该角色时间的查询，可查询某时间角色有效的用户。用户角色分为流程角色和排查角色两种，流程角色是为了隐患治理流程而设置的角色，排查角色是为有排查频次要求的人员而设置的角色。项目信息管理功能为用户提供工程基本信息填报、修改、工程信息查询等功能，可以分别按照项目状态、风险专业以及工程类型查询。除了可查询正在运行的项目信息外，也可查询已完工已销号的工程。隐患排查治理功能隐患排查治理流程由隐患上报、各级响应、制定整改措施、隐患治理并填报记录、验证闭合、消除等节点组成，且隐患治理流程可实现个性化定制。根据隐患等级的不同，各级隐患都可配置整改期限。系统根据规定的排查频次在每个周期内给相关人员自动生成排查任务单，并在“排查任务”栏中提醒相关人员进行隐患排查，排查人员必须在规定的时间内进行隐患排查并上传至系统，不然将视为未排查。排查人员在对应隐患条目排查并将隐患上传系统平台后，系统根据隐患的等级自动将待办信息推送给项目经理或项目其他分管领导,项目经理对Ⅰ级、Ⅱ级隐患于6小时内在系统平台上予以响应;对Ⅲ级、Ⅳ级隐患，由项目部有关领导（副经理、总工程师、安全总监）于12小时内在系统平台上予以响应，责任人必须在规定的时间内在系统中进行响应处理，不然造成响应超时。如排查人员在现场排查未发现安全质量隐患时，在处理排查任务单时应将本次排查内容进行上传，否则排查任务单无法提交。在项目经理响应处理Ⅰ级、Ⅱ级隐患时根据需要可报请所在子分公司、局指、代局指帮扶；各子分公司、局指、代局指在处理Ⅰ级隐患时可根据需要报请局帮扶，局组织专家制定整改措施并在系统中下达，项目部再根据整改措施负责落实整改。排查人员在录入排查记录之后，应该立即上报本次排查发现的隐患，默认排查时间为最后一次隐患上报的时间（系统不支持在下次排查记录时补录上次排查记录的隐患），选中具体的隐患条目，逐条上报，并上传隐患附件。系统还单独开发隐患上报模块，主要是针对没有排查任务的用户在施工现场检查发现隐患时也可进行隐患上报，其他人员也可通过此模块上报隐患。排查人员进入隐患上报页面，系统加载隐患类别树和树节点下的隐患条目，应该根据条件（级别、内容等）进行筛选隐患条目。用户选择隐患条目，点击上报，填写隐患具体描述，上传隐患图片或其他附件就可上报。隐患上报时附加的图片、文档等附件系统会自动压缩，限制图片大小。隐患上报后系统会自动将此条隐患推送给相关责任人，也就是隐患响应功能，相关人员可以根据流程在待办事项中按响应时限对其进行处理。收到隐患整改信息，按照权限对其进行响应确认，责成相关人员整改或组织实施整改。填报整治记录、闭合确认及隐患消除等环节与此相同。如处理人快到响应时限时还未进行响应处理，单位管理员可在系统中发出督办指令，再次提醒处理人处理待办任务。用户登录系统后，会收到在自己权限范围内需要响应的隐患整改信息以及与该隐患级别对应的响应时限倒计时的隐患整改信息提示。当选中整改条目时，用户可以查看相关信息，包括查看排查附件、隐患信息、流程信息等等内容。有些响应需要安排主辅责人和部门，部门根据组织机构中选取获得，主责部门进入流程，主责人填治理信息或制定整改措施，辅责部门只是在流程上响应，在线下辅助即可。整改措施响应时，相关职能部门可以在响应时输入整改措施，上传整改措施附件。验证人在验证操作时，可以根据上传的整改记录等资料或现场验收情况，判断是否存在虚假闭合现象，如果发现虚假闭合时选择未闭合提交后，项目部再重新进行整改，直到验证闭合为止。隐患上报人员负责在系统中对隐患进行验证后的最终消号处理。相关人员均可在后台查看隐患处理流程的每个步骤处理情况、当前状态、剩