苏州电信无线建维支撑系统项目方案.docx
《苏州电信无线建维支撑系统项目方案.docx》由会员分享，可在线阅读，更多相关《苏州电信无线建维支撑系统项目方案.docx（31页珍藏版）》请在冰豆网上搜索。
苏州电信无线建维支撑系统项目方案
中国电信股份有限公司
苏州分公司
苏州电信无线建维支撑系统
项目建议书
中国电信股份有限公司苏州分公司
二〇一八年十月
1概述
1.1项目背景
随着C网的不断发展和壮大，对于网络的优化建设和统一管控有着迫切的需求，从现网的实际覆盖、容量需求、服务质量需求、市政规划需求以及其他的专题需求等多方面影响着C网的网络优化和建设。
但随着C网建设资金越来越紧张，现阶段无法同时满足以上各方面需求，因此在站点规划时，需要一个多维度的评估体系，综合考虑各方面因素，充分利用有限的投资，实现效益的最大化。
同时，现有的规划及评估体系，仅仅依靠人工的操作和一些其他系统的辅助支撑，从需求的提出到审核、规划需要漫长的流程，同时在实际操作的过程中，由于仅靠EXCEL、邮件等传统的方式进行流转和沟通，对于流程无法做到统一的管控和数据的统一汇总，最终导致信息缺失、信息不对称、实施效率低下等结果，从而阻碍网络的优化建设影响客户感知。
根据以上对规划现状，急需建立一套以工作流管控为主线的集成化平台，实现对于无线需求及规划支撑管理的综合管控。
将需求收集、站址审核、站点评分、方案制定、状态跟踪等流程，以IT化的手段进行有效的流程管控，并结合相应的接口与各个分散的第三方系统进行对接，形成一套综合的无线规划支撑体系。
1.2系统面临主要问题
1.2.1主要问题
数据支撑方面
基站建设流程化管理完全依赖人工，缺乏快速有效的自动化数据支撑。
管理支撑方面
具有多个部门、多个专业，对整体的进度无法统一集中管控。
基站建设数据分散在各个专业维护人员的文档中，对部门和人员的指标管理（工作量、及时率、准确率等等）分散在各个运维人员中，无法对运维工作做出有效评估。
1.3系统建设目标
1.3.1业务目标
根据苏州电信的现状和需求分析，我们提出如下的业务建设目标：
统一的工作流程管理平台，组织人员和权限管理平台，整合后端多个人工处理流程；
支持多纬度展示基站建设的数据报表；
支持多个系统的对接整合，在统一平台对基站建设的全流程进行管控；
系统具备高扩展性、易集成性、易维护性，新增业务能够快速实现。
1.3.2技术目标
如上所述，技术建设是为业务目标的实现，针对上述业务目标需要达到以下技术目标：
Ø通过基于集中统一的业务基础平台打通各专业网管和设备、其他应用系统的流程，适应各应用系统和流程集成变化的需要；建立统一的客户作业视图和共享核心数据模型。
Ø通过数据、代码、流程可重用和分层次的应用软件体系结构，保护IT业务资源，达到快速扩充新业务，降低软件开发、测试、维护成本的目标。
Ø满足“7×24”的全天候运行的高可靠性要求。
Ø达到指标可监控、安全可审计、工单可追踪、操作可控制的技术管理目标。
Ø建立一套安全的系统，达到从应用、系统、数据多个层面保证系统的安全性。
Ø达到业务发展的容量的要求。
1.4系统遵循标准与规范
1.4.1主要的国际标准与规范
Ø层次模型设计遵循ITU-TMN
Ø操作系统接口符合POSIX及OSF标准
Ø数据库接口符合SQL结构化查询语言标准
Ø人机界面基于Windows/xWindow
Ø计算机通信协议：
IEEE802.3、TCP/IP、X.25
Ø编程语言为标准C++（ANSIISOIEC14882-1998）与JSP
ØIUT、EIA、IEEE等关于计算机硬件、软件、网络设备、数据交换接口和格式等国际标准
2总体设计
2.1解决方案
系统主要分数据支撑和管理支撑两大部分。
系统建设总体目标：
建设目标
典型应用
使用人员
系统接口
总体目标
⏹完成各部门各专业维护人员对无线基站建设的全流程管控
⏹部门管理员可以对基站建设的多纬度数据报表全方位呈现
⏹基站建设过程中的GIS地图全过程呈现
⏹基础建设资源管理
⏹规划建设需求流程化管理
⏹基站建设报表呈现
⏹基站建设流程管控处理
⏹无线中心优化组
⏹无线中心建设组
⏹无线中心设计院
⏹无线中心前段区局
⏹预留第三方厂商接口
⏹资源同步接口
2.2设计思想
系统是一个基于开源技术实现的业务系统。
基于开源Tomact、ApacheHttp服务器，以及Apachecommons系列Lib、Log4jLib、ExtJs等开源Lib使得系统有足够的灵活性来适应不断变化的业务流程的需求。
并且还提供了模板管理的功能，使得系统能够定制基站建设中各个纬度的数据分析。
系统是一个基于J2EE的分布式应用管理系统。
J2EE体系架构保证了多专业作业计划自动执行系统软件平台独立性、可重用以及模块化。
系统应用服务器采用面向服务的设计思想。
面向服务的结构体系更加适合企业级应用，尤其随着互联网的应用，为企业应用提供让外部应用和系统访问的服务接口已经成为一种趋势，如：
B2B、B2C等。
只有面向服务的系统才能达到更好的松耦合和模块化。
系统服务模块之间采用异步消息驱动，提供企业应用集成的强大功能和良好的用户体验。
服务模块之间耦合度进一步降低，XML格式的消息使得系统可以很好地与其它系统和应用集成。
系统提供了门户页面功能。
为企业信息化工作的开展提供了一致和统一的基础架构。
实现统一的系统管理、端对端的安全架构、内容管理及服务的个性化和集成服务。
2.3系统功能架构
系统总体架构分为三个层次，应用层、数据处理层以及接口层。
每一层都有各自的功能并且通过接口相互关联。
对于用户来说，只对应用层进行相关的操作，各种返回的结果也在应用层展示给用户。
对用户屏蔽了复杂的业务处理及与其他系统的交互过程，在简化了用户操作的同时，也保障了整个处理过程的安全性。
2.3.1业务应用层
应用层是系统直接提供给用户操作、查询的界面，是系统与用户交互的门户。
本系统主要面向市场、规划、建设、无线维护部门的相关人员使用，提供相应的操作界面，包括查看系统采集的资源信息数据、查看和发起规划的流程管理、对流程的推进操作、通过直观的地图查看资源及关联的信息。
2.3.2事件处理层
数据处理层是系统的核心业务层，在整个系统中接受上层（应用层）的用户操作请求响应，将用户的界面操作转换为系统预置的操作服务，对流程的流转、数据的更新进行操作，同时将相应的结果反馈给上层的用户界面。
事件处理层出了必要的调度、处理、分析进程外，在本系统中还承载了业务流程管控的核心——工作流引擎，为业务的流转提供基础。
2.3.3服务接口层
接口层通过对接及开放接口的数据收集，将不同系统、专业、部门信息进行采集和入库，为规划建设的分析和数据共享提供底层的数据支撑。
2.4系统技术构架
随着软件技术的发展，尤其是互联网技术及其应用的迅猛发展，三层/多层体系结构已经成为企业级应用的主要架构。
平台独立、可重用、模块化是企业级应用系统的三大要素，J2EE是目前最满足这三大要素，并且日益成熟的技术架构。
系统采用了电信企业级系统所必须具有的开放，健壮，可扩展的架构，该架构建立在J2EE这个标准工业基础以及企业级计算平台之上。
3系统功能规划
3.1系统主要功能点
系统主要的业务功能包括基础资源管理、需求建设流程管理、GIS地图展示三大模块。
3.2系统接口及外部系统
Ø系统对接及开放接口的数据收集，将不同系统、专业、部门信息进行整合并通过平台进行共享，并尽可能地理化、可视化和嵌入式。
以充分改善及时性、便捷性和集成性的需求；
Ø系统具有适配层，可无缝增加其他接口。
3.3系统分权分域
系统对于不同的模块，不同区域根据用户的属性进行权限的划分。
Ø系统管理员：
拥有对系统的最高管理权限，可以配置系统的相应参数，分配用户权限等；
Ø规划需求发起人员：
在系统中可以进行需求的提出，执行的班组可以是优化组、建设组、前端区局。
Ø勘察人员：
主要进行实地的考察，形成初步的优化方案，执行的班组是优化组、建设组。
Ø方案设计人员：
需要进行方案的具体设计和制定，形成方案的文案及图纸，执行的班组包括建设组、集成商、设计院。
Ø会审人员：
对方案进行审核，是否通过流转到立项环节，执行的班组包括优化组、建设组、设计院、建设部。
Ø立项申请人员：
对立项的情况在系统中进行反馈，执行的班组是建设组。
4系统功能介绍
系统主要的业务功能包括掌上基础资源管理、需求规划建设流程管理、GIS地图展示三大模块。
流程化的管控体系结构：
各个模块的详细功能如下。
4.1基础建设资源管理
基础资源管理提供了信息管理的基础功能，包括综合资源和动态数据资源部分，数据的来源可以是用户进行导入、录入的基础信息，也可以是通过底层的接口，对接其他的系统采集而来的其他平台的信息。
本系统首先先实现站点资源信息的基础管理功能。
4.1.1站点资源信息
⏹功能需求
对包括各系统（C\E\W\驻地网），各状态（需求、规划、预查勘、选址、现网），不同级别（机房、站点、扇区），室内外（宏站和室分）的所有站点信息进行基础资料的管理和维护，包括站点的编码、站点的名称、位置、类型、功能、经纬度坐标等必要的基础信息。
系统提供站点的手工录入和批量的导入导出功能，以便于站点数据的更新和修改。
站点的经纬度信息是供GIS图形展现的基础，只有提供了经纬度信息，才能够在GIS中展现所在的位置。
4.1.1基站建设需求管理
⏹功能需求
基站建设需求管理包括需求重要等级、需求建设地点、需求实时状态等信息，此部分的信息资源可以通过第三方厂商系统或者人工输入方式获得，对基站建设的需求集中化管理，包括历史留痕、需求处理状态等。
4.1.2基站建设前期操作历史管理
⏹功能需求
基站建设需求管理包括需求重要等级、需求建设地点、需求实时状态等信息，此部分的信息资源是系统根据维护人员在系统界面上的每一步操作留痕。
颗粒度细化到相关人员、时间、操作内容等信息。
方便基站建设初期方案的合理化回退和向下进行
4.1.3基站建设操作历史管理
⏹功能需求
基站建设需求管理包括需求重要等级、需求建设地点、需求实时状态等信息，此部分的信息资源是在基站建设过程中的系统数据的留痕操作。
并可以实现统计出当前基站资源的维护情况、工作情况等详情信息。
多维度展现建设施工中的项目经理的工作计划和工作效率。
4.2规划建设需求流程化管理
建设需求的流程化管理是本系统本期需要解决的重点问题，主要是对于现有的以人工操作为主的规划管理流程进行系统化，将原先不能很好管控的流程纳入IT系统进行统一的节点管控，明确各个阶段的责任人员、完成目标、完成时限等要素；同时系统通过资源信息与管理流程相结合的模式，将原先分散在各个不同岗位、不同部门、不同系统中的有价值的资源信息进行整合，提供统一的网络优化管理平台。
在系统化的管理流程中，以需求的发起为起点，直到项目的立项，全流程的跟踪和管控需求的状态和进度，在系统中可以随时查看当前需求从提出到目前为止所经历的和处理的人员、处理的时间等信息，以及后续还要进行的步骤及相关的人员信息等。
每个需求录入系统后即生成一个唯一的工单编号，伴随全部的流程，可通图形的方式查看工单的流程状态；可以通过工单所涉及的地理区域在地图中通过全景视图把控全区的情况。
4.2.1规划需求收集
需求的规划收集是整个需求规划管理的开始，需求的来源分类有前端需求、服务投诉、市政规划、专项行动几大类。
通过系统的规划需求管理功能，可以由相应的人员对应不同种类的需求进行录入到系统的无线规划需求资源池中。
需求提出之后，系统根据需求的来源进行分类入库。
系统化之后的处理流程：
4.2.2规划需求整合
优化组每周定期登入系统后查看无线规划需求资源池中的当前未处理的需求进行整合，根据实际情况完善下是否要新建工单，需要建设工单的则说明流程需要人工触发，输出审表，系统的工作流引擎根据节点流转到下一节点。
4.2.3现场查勘、方案初定
需求入库由优化侧的受理岗处理形成审表之后，转入优化侧、建设侧的现场人员进行联合查勘。
通过实地考察，考虑现有资源，根据优化需求进行看点，查勘内容：
经纬度、塔桅具体位置、机房属性、塔型类别、塔高、挂高等。
上述查勘的结果参数，通过系统录入，作为工单的附属信息存储，同时，根据实际的地理位置或关联的站点位置，录入坐标信息，作为需求的地理信息以便在GIS中能够统一展现。
2、考虑上一步联合查勘结果，结合考虑优化侧需求、建设侧施工条件，做出网优方案（方案包含需求分析、解决方案：
站点经纬度、塔桅位置、机房属性、塔型类别、塔高、挂高等）。
在完成现场的查勘之后，工单的状态进入初步优化方案制定，由系统的工作流提交到相应的处理岗位进行处理。
在处理完成之后，输出网优方案，系统提供优化方案管理的界面，录入相关的方案内容及附件，方案和需求工单做关联。
4.2.4现场谈点
根据上一节点的方案初定的结果，建设组根据优化组发来的站点建设方案及具体实现方式后去现场谈点，现场谈点的目的就是为了进一步确定站点建设的具体位置等信息
4.2.5设计方案管理
设计方案管理状态的责任岗位为建设组，在系统工作流将需求工单流转到方案设计环节时，自动派发给建设组的相应处理岗位。
建设侧牵头集成商、设计院，集成商根据优化方案初定输出的网优方案制作文本方案、设计图纸、材料预算表，通过建设侧送设计院审核，设计院审核方案合理性。
最终，由建设组的相应在在系统中反馈方案是否通过，如果方案通过则将方案的相关文件作为附件录入系统，并且将流程推进到下一个环节；如果审核不通过，则需要在系统中录入不通过的原因及措施，系统可以提供终止该需求的推进还是重新设计方案等操作。
4.2.6联合会审管理
优化侧对设计方案的输出进行最终审核，考虑信源天线的布放使用合理性，是否满足最初的方案解决需求；建设部对项目资金材料进行审核；对于会审的结果，通过系统进行录入。
审核通过，系统工作流自动将该需求工单跳转至下一步“立项申请”，审核不通过，返回上步“设计方案”。
联合会审的输出结果包括会审会议纪要以及项目审核情况表，均以附件的形式作为系统中需求工单的附属文件保存。
4.2.7立项管理
建设侧根据系统工单审核结果提交申请立项表至建设部立项申请通过，系统工作流流进入下一步，进行建设需求发起；不通过，返回上一步联合会审。
需求工单进入立项状态后，完成了需求工单的发起到规划到立项的过程。
4.2.8建设规划跟踪管理
对已经立项进行建设的项目，对建设的过程以及后续评估进行相应的流程化管理控制。
实时地跟踪规划点的建设状况，在预查勘、选址、设计、竣工等关键环节，获取经纬度、挂高等关键信息，并与规划方案进行对比，并给出各类指导意见。
当规划点进入站点验收环节后，应触发后评估任务，利用指标观察、客户回访等手段，对站点建设的效果进行评估，确认是否满足当初的原始需求。
状态跟踪管理
站址进入建设流程后，从站址的站点获取到开通入网的状态跟踪，以及建设过程中的站址调整和方案变更。
站址建设按照完成进度百分比的方式在全景视图上呈现。
4.2.9维护验收
网优部门维护人员通过系统接口对基站建设进行评估。
工作分为如下步骤:
工单查询:
查询维护验收状态下的工单，进行分权分域处理
维护验收资料录入与提交:
基站在建设施工完成后维护工作组成员现场进行评估验收，并完善系统。
审核功能:
对验收通过、不通过进行评判
派单与转派功能:
对工单进行派发到项目经理处理
信息反馈功能:
对工单进行反馈操作，记录操作的日志信息
4.2.10优化评估
优化组成员根据维护专项操作的报告实行对基站进行全面的网络评估。
从而使得基站在最后的验收阶段能达到最优的工作状态。
优化评估的操作流程如下：
工单查询：
查询优化入网状态下的工单，进行分权分域处理
优化入网资料录入与提交：
优化组根据维护组的输入系统的报告和数据等进行性能评估验收。
评估功能：
对入网通过、不通过进行评判
派单与转派功能：
对工单进行派发到项目经理处理
信息反馈功能：
对工单进行反馈操作，记录操作的日志信息
4.2.11评估管理
网优部门维护人员通过系统接口对站址入网前后的维护验收和信号质量、覆盖效果等的综合效果分析并确认。
规划站址达到预期效果：
综合确认并结束需求；规划站址部分达到效果：
整改调整方案；多次规划调整无效：
列入疑难库。
4.3报表管理
报表管理模块根据应用和业务数据，提供完善的报表统计功能。
运维人员可以自定义周期和范围进行统计。
主要报表功能包括：
站点资源信息统计报表、考核指标统计报表、报表管理和CEO视图。
统计时间粒度：
小时、日、周、月、年和阶段时间。
报表呈现包括：
文本列表、历史趋势曲线、图形方式（饼状、直方图等）。
4.3.1站点建设统计报表
基站建设需求统计报表（日/周/月/年/阶段报表）；基站资源建设统计报表（基站类型、建设阶段、故障处理等级统计）。
4.3.2考核指标统计报表
考核指标统计报表根据各部门、专业、维护人员基站建设的成果数据，周期性生成工作的完成情况、需求的处理率数据报表等，作为考核指标依据。
4.3.3CEO视图
以各个部门、区域为管控节点，呈现各管控点的工作质态；
以直观的图形方式展现各管控节点的执行情况，将各项指标计算获得效率值，并用不同颜色、颜色深浅标识具体效率值；
4.4系统工作流引擎
本次系统采用固化的工作流引擎进行业务流程的流转，应用于规划建设的需求流程管理、跟踪管理、评估管理流程。
业务流程在需求梳理阶段进行定义，在系统开发阶段进行设计及编码，不随用户的使用而变化或增减。
4.4.1流程基本实现
4.4.1.1流程定义
流程是指完成某一项活动的一个过程定义。
包括流程的名称、流程的描述等要素。
它又由具体的节点、事务来构成。
在本系统中，每一个流程，就定义了一项活动的开始到结束，不同的流程之间不存在关联。
一个完整的业务过程，它由若干节点组成。
包括流程的基本信息、开始和结束条件、组成的节点、节点间流转的规则、需要用户执行的工作任务（工作项）、可能调用的应用程序以及流程相关数据（表单）等信息。
在本系统中，流程的定义是在系统开发阶段完成的。
4.4.1.2节点定义
节点的实质是一个流程中所经的状态。
节点的定义包含在业务流程定义之中，代表了一个相对独立的逻辑工作单元。
一个环节代表一个需要由相关资源处理，或者由计算机处理的任务。
其中定义了该环节的基本信息、执行该节点的参与者（与人员岗位关联）、时间限制、工作项信息、触发事件、启动策略等信息。
在本系统中，节点的定义是在系统开发阶段完成的。
4.4.1.3事务定义
事务是指一个流程中由一个节点变更为另一个节点的动作，事务是一个瞬时的过程，而非流程的一个状态。
每一个事务定义了起始节点、结束节点、流转条件等要素。
Ø事务触发事件：
触发事件是流程事务中插入的一些用户自定义的动作，类似于数据库中的触发器。
当一个事务配置了相应的触发事件后（例如发送通知提醒、表单数据同步修改等操作），在实例话的流程中，调用该事务的时候，会触发相应的事件完成某项操作。
4.4.1.4流程实例
流程实例在本系统中具体的表现形式就是一张工单。
同一个流程定义可以有多个流程实例。
每一个流程实例会被保存在流程实例库中，包括流程实例ID（唯一标识）、流程实例名称（订单名称）、流程ID（记录该订单做引用的具体流程）、流程实例的状态、该实例的启动者、启动时间等信息。
4.4.1.5表单实例
创建流程的实例时，同时会生成与之对应的业务表单，以承载流程流转的过程中所必需的数据实体。
表单实例的数据随流程实例（需求工单或建设规划跟踪）进行流转，在流程实例（工单）的整个生命周期中，表单的数据会随着流程的提交自动或人工填写而变化。
4.4.2业务对象之间的关联
系统配置时的数据对象包括流程定义和环节定义；在运行阶段的数据对象包括流程实例、节点实例。
●一个流程定义由多个节点定义组成；
●节点之间的关系连线成为事务；
●一个流程定义可以创建多个流程实例；
●一个流程实例包含多个节点实例。
其相互之间的关系如下图：
4.4.3流程实例的基本运行过程
在本系统中，在一个流程实例启动以后，流程的各个环节实例是按照以下规则进行推进的：
1.开始节点总是第一个被实例化并启动的节点，开始节点存在一个瞬间状态，启动以后立即结束；
2.开始节点结束以后，会根据开始节点的分支模式去实例化后面的迁移线，并触发相应的后继节点；
3.如果被触发的后继节点满足启动条件，则会启动该节点；
4.对于每一个被启动的节点，结束以后，都会完成上述的动作，推动后续节点的运行；
5.当推进过程遇到结束节点的时候，流程实例结束；
流程实例结束时，会把流程中所有的还未完成工作项和环节实例全部终止
5系统配置管理
系统配置管理是管理员进行系统设置、用户管理的平台，为确保安全性和可管理性，该功能只在WEB界面由系统的管理员进行使用。
5.1系统用户管理
实现系统的新增用户、修改用户等基础功能，以及用户的角色、功能权限的分配，起到分权分域的作用。
5.2操作日志管理
由管理员对各个用户、客户端的使用记录进行查询统计，可以作为指标考核的依据以及跟踪使用情况的数据支撑。
6技术实现介绍
6.1系统设计原则
在应用系统设计时，以“设计时考虑维护、设计时考虑将来”作为总的设计原则，并严格遵循先进性、实用性、开放性、稳定性、安全性、符合国际标准的原则。
✓系统安全性要有保证，主要从四个方面保证：
1）要有日志功能，对数据库的操作、文件的操作等要求记录进用户日志；2）对用户要分配不同的访问和使用权限；3）系统要能防止病毒、黑客等攻击，保证资料在网上存储与传播的保密性和准确性；4）对备份功能的考虑，保证系统中文件等数据的万无一失；
✓保证系统的稳定性，要能保证多人同时访问时系统负载能力；保证系统在365天，每天24小时的运行稳定性，在突发事件出现时，要求保证系统恢复的快速性；
✓保证系统的易用性，易用性主要从两个方面把握：
1）整个系统体系结构灵活，方便使用部门能够在最短的时间内对系统进行较少的调整就可以重新投入应用，换句话说，系统要有一定程度的灵活性；2）要能保证所有用户（包括系统管理员）都能在最短的时间内快速地掌握各项应用与维护的操作。
保证最高效率、最便捷的人机交互。
具体说来，要做到界面人性化和操作个性化。
对具体的每一个用户来说，要考虑个性化界面配置的要求；
✓经济性的考虑，主要从三个方面整体考虑系统的经济性，也就是IT行业建设常提到的概念，即系统总拥有成本：
1）各项平台与设备采购总体成本；2）系统安装、维护、培训等成本；3）系统使用成本；
✓系统可扩充性的考虑，系统需要具备与其它业务系统接口的业务连接、数据交换能力。
比如各专业网管、各网元设备、综合告警、短信接口、综合调度、资源管理系统等；
✓系统主要采用B/S架构，考虑技术领先性和日后升级要求：
由于IT技术日新月异，系统必须充分考虑日后的升级换代方便和可行。
因此本系统的管理、应用、维护全面采用Internet解决方案，降低维护使用成本，保证技术的先进性。
6.2软件体系架构
6.2.1J2EE多层架构模型
J2EE的全称是Java2PlatformEnterpriseEdition，它是由SUN公司领导的、各厂商共同制定并得到广泛认可的工业标准，是典型的多层体系（或三层）应用架构，前端为WEB浏览器，中间层为应用服务器，提供WEB容器和EJB容器，后端采用Sybase
升级会员 