CN113762543A - 一种公交运行维护*** - Google Patents

Abstract

本发明公开了一种公交运行维护***，该***包括：物联感知层，用于实时获取与公交运行相关的设备的监控数据；数据处理层，用于对各监控数据进行分析处理，以对应获取不同的运维信息；业务服务层，用于对不同的运维信息进行分析，以构建出不同的业务服务；用户访问层，用于对业务服务层进行访问，以能够开展不同的业务。本发明能够对视频的相关信息进行数据分析，具备移动运维应用服务，且能随时随地响应运维需求，具备流程化管理体条件。

Description

一种公交运行维护***

技术领域

本发明涉及数据处理技术领域，特别涉及一种公交运行维护***。

背景技术

大规模的公交运营网络，长时间的车辆高负荷运行，不断突破新高的客流量和被挤压的夜间维护窗口时间，给公交运营核心的日常运维保障工作提出了更高的要求和不小的挑战，因此，迫切需要智能化技术的赋能，实现公交可用度和运营效率质的提升。

为实现上述目的，现有技术采用的方案如申请号为202010180869.4，名称为一种共公交***安全运行工作方法的专利申请方案所述，其通过智能调度、站点调度、车内监控、人员巡查、交叉检查、人盯死守等方式，对公交车在运行停靠点上、在运行线路上、在运行车辆中、在停放场地上进行全方位安全防范监控和安全提醒。

实践中发现，上述方案虽然在一定程度上能够提高公交企业的管理水平和运营效率，但是，该方案仅支持车辆视频数据的回传，无法对视频的相关信息进行数据分析，不具备移动运维应用服务，不能随时随地响应运维需求，并且无工单管理，不具备流程化管理体条件。

发明内容

为解决上述技术问题之一，本发明提供一种公交运行维护***。

为达此目的，本发明采用以下技术方案：

本发明提供一种公交运行维护***，其改进之处在于，包括：

物联感知层，用于实时获取与公交运行相关的设备的监控数据；

数据处理层，用于对各监控数据进行分析处理，以对应获取不同的运维信息；

业务服务层，用于对不同的运维信息进行分析，以构建出不同的业务服务；

用户访问层，用于对业务服务层进行访问，以能够开展不同的业务。

本发明与现有技术相比，至少具有以下优点：

本发明通过按照高起点、高标准、高质量的要求，采用“产品+服务”的理念，建立与管理体系相适应的公交运行维护***，以对与公交运行相关的设备进行监控，将错综复杂的运维信息，按照综合服务管理的需求进行过滤整理，实现主动故障报警，能够最大限度的屏蔽综合技术的复杂性，降低对人的依赖，帮助***维护人员更专注于对重要事件的管理和响应，为公交用户提供综合、高效、优质的运维服务。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一实施例提供的公交运行维护***的结构图；

图2是B/S结构工作原理示意图；

图3是MVVM架构示意图；

图4是MVVM数据交互示意图；

图5是SNMP协议逻辑结构示意图；

图6是数据监控流程示意图；

图7是用户操作流程示意图。

具体实施方式

下面结合附图并通过具体实施方式来进一步说明本发明的技术方案。

其中，附图仅用于示例性说明，表示的仅是示意图，而非实物图，不能理解为对本专利的限制；为了更好地说明本发明的实施例，附图某些部件会有省略、放大或缩小，并不代表实际产品的尺寸；对本领域技术人员来说，附图中某些公知结构及其说明可能省略是可以理解的。

本发明一实施例提供的公交运行维护***，如图1所示，包括：

物联感知层1，用于实时获取与公交运行相关的设备的监控数据；

数据处理层2，用于对各监控数据进行分析处理，以对应获取不同的运维信息；

业务服务层3，用于对不同的运维信息进行分析，以构建出不同的业务服务；

用户访问层4，用于对业务服务层3进行访问，以能够开展不同的业务。

其中，与公交运行相关的设备包括监控IPC、车载终端等前端感知设备，以及主机、网络设备、CVR、DVR、视频拼控矩阵、智能设备等IT设备，具体可以根据需要设置，在此不进行限定；

监控数据包括配置数据、性能数据、告警数据、视频质量诊断数据等，具体可以根据需要设置，在此不进行限定。

本实施例中，公交运行维护***采用面向对象设计，其技术体系采用B/S结构，支持web端和手机客户端操作，Web端采用MVVM框架，移动端采用MVP框架，其中：

B/S结构为：

第一层是浏览器，即客户端，只有简单的输入输出功能，处理极少部分的事务逻辑，客户不需要安装客户端，只要有浏览器就能上网浏览，面向大范围的用户，所以界面设计得比较简单、通用；

第二层是WEB服务器，扮演着信息传送的角色，当用户想要访问数据库时，首先向WEB服务器发送请求，WEB服务器统一受理请求后，向数据库服务器发送访问数据库的请求，这个请求以SQL语句实现；

第三层是数据库服务器，扮演着重要角色，因为它存放着大量的数据，当数据库服务器收到了WEB服务器的请求后，会对SQL语句进行处理，并将返回的结果发送给WEB服务器，接下来，WEB服务器将收到的数据结果转换为HTML文本形式发送给浏览器，即：打开浏览器呈现的界面。

B/S结构如下表1所示：

B/S结构采取浏览器请求，服务器响应的工作模式，B/S结构工作原理，如图2所示：

用户通过浏览器访问Internet上由Web服务器产生的文本、数据、图片、动画、视频点播和声音等信息；

每一个Web服务器通过各种方式与数据库服务器连接，大量的数据实际存放在数据库服务器中；

从Web服务器上下载程序到本地执行，在下载过程中若遇到与数据库有关的指令，由Web服务器交给数据库服务器解释执行，并返回给Web服务器，Web服务器又返回给用户，在这种结构中，将许许多多的网连接到一块，形成一个巨大的网，即全球网，而各个企业可以在此结构的基础上建立自己的Internet。

在 B/S 模式中，用户是通过浏览器针对许多分布于网络上的服务器进行请求访问的，浏览器的请求通过服务器进行处理，并将处理结果以及相应的信息返回给浏览器，其他的数据加工、请求全部都由Web Server完成。

本实施例中，Web端采用MVVM架构，MVVM架构如图3所示，所有服务在此框架上实现，具体：

（1）View是视图层，即：用户界面，为了更方便地展现ViewModel或者Model层的数据，前端主要由HTML和CSS来构成；

Model是指数据模型，泛指后端进行的各种业务逻辑处理和数据操控，主要围绕数据库***展开；

ViewModel是由前端开发人员组织生成和维护的视图数据层，在这一层，前端开发者从后端获取得到Model数据进行转换出来，做二次封装，以生成符合View层使用预期的视图数据模型，视图状态和行为都封装在ViewModel里，这样的封装使得ViewModel可以完整地描述View层；

（2）在MVVM架构中，不允许数据和视图直接通信，只能通过ViewModel来通信，而ViewModel定义了一个Observer观察者，ViewModel是连接View和Model的中间件，其能够观察到数据的变化，并对视图对应的内容进行更新，也能够监听到视图的变化，并能够通知数据发生变化。

（3）MVVM数据交互图，如图4所示：

MVVM的核心是ViewModel层，负责转换Model中的数据对象，以使得数据变得更容易管理和使用，其作用如下：

该层向上与视图层进行双向数据绑定，向下与Model层通过接口请求进行数据交互。

显然，通过按照高起点、高标准、高质量的要求，采用“产品+服务”的理念，建立与管理体系相适应的公交运行维护***，以对与公交运行相关的设备进行监控，将错综复杂的运维信息，按照综合服务管理的需求进行过滤整理，实现主动故障报警，能够最大限度的屏蔽综合技术的复杂性，降低对人的依赖，帮助***维护人员更专注于对重要事件的管理和响应，为公交用户提供综合、高效、优质的运维服务。

在一些实施例中，业务服务层3，用于对不同的运维信息进行分析，以构建出不同的业务服务，其中，不同的业务服务包括状态监控、事件接收、业务单/巡查单派发，并对应形成数据报表。

显然，在遵循综合ITIL的规范的基础上，通过设置业务服务层能够为用户提供统一的运维管理服务，提高服务和内控水平，实现从救火式变迁到主动式的运维管理。

在一些实施例中，业务服务层3包括运维服务台，以通过运维服务台建立运维人员与用户之间的联系点，统一受理用户的咨询、服务请求、故障报修、投诉事件，并通过数据处理层2获取物理感知层1上报的报警信息，以进行分析预警；

本实施例中，运维服务台还用于跟踪突发事件处理流程，并进行处理通报。

在一些实施例中，业务服务层3包括综合监控模块，以通过综合监控模块提供设备状态监控、视频录像监控、视频矩阵监控、视频质量诊断监控、存储设备监控、主机监控、数据库监控、网络设备监控、标准应用监控、中间件监控和网络拓扑管理，具体为：

设备状态监控，用于通过SDK、Onvif、国标、SNMP等主流协议对监控摄像机进行统一的运维监控，包括对与公交运行相关的设备进行巡检，显示设备在线状态信息，以及对在线状态信息的查询；

视频录像监控，用于根据预设时间对监控点位进行录像完整性检测，并当检测到录像缺失时，进行告警，以及用于记录、查询及显示录像完整性信息。

视频质量诊断监控，用于通过轮巡的方式，对前端设备的码流进行解码与图像质量评估，并将评估结果进行统计分析，并将分析结果以列表导出及图像化展示

显然，通过以上设置能够实现对视频信号中存在的问题进行智能分析、判断和告警。

视频矩阵监控，用于通过SDK协议对视频综合矩阵的运行状态进行采集，其中，采集项包括矩阵设备的离线时长、在线状态、在线通道数、各子板（编码、解码、码分、报警）的在线数、子版号等。

存储设备监控，用于对NVR、CVR、DVR等存储设备运行状态，以及存储使用情况信息进行监控，以及用于按照运维区域、在线状态、设备名称、ip地址等维度的数据查询能力，并支持查询结果的导出。

主机监控，用于通过SNMP协议对windows、Linux主机运行数据进行统一监控，具体包括：监控设备的CPU占用率、内存使用率、磁盘容量及进程数量等信息，以及按照区域查询、统计、导出设备的IP地址、在线信息及进程等信息。

数据库监控，用于通过管理员账户监控数据库表内部运行情况数据。

网络设备监控，用于通过SNMP协议实现对网络设备的上下行速率、上下行丢包率、在线状态等运行数据的统一采集。

标准应用监控，用于对文件传输应用、网页服务、邮件服务和加密传输协议（Sftp和https）集中监控，并提供图像化展示状态信息和性能信息。

中间件监控，用于对MQ、webologic、websphere等中间件和承载业务的基本状态进行统一监管。

网络拓扑管理，用于根据拓扑生成算法，搜索整个网络内的网络设备，并勾画出整个网络的真实物理拓扑图，以真实反映整个网络的构成状况；

网络拓扑管理，还用于拓扑添加，以及对设备流量异常、网络架构合理性进行统计分析。

需要说明的是，上述的设备状态监控、主机监控、网络设备监控均通过SNMP协议实现，SNMP协议逻辑结构，如图5所示：

SNMP为管理员提供网管平台(NMS)，又称管理站，负责网管命令的发出、数据存储、及数据分析；

被监管的设备上运行一个SNMP代理(Agent))，代理实现设备与管理站的SNMP通信；

管理站与代理端通过MIB进行接口统一，MIB定义了设备中的被管理对象；管理站和代理都实现了相应的MIB对象，使得双方可以识别对方的数据，实现通信；

管理站向代理申请MIB中定义的数据，代理识别后，将管理设备提供的相关状态或参数等数据转换为MIB定义的格式，应答给管理站，完成一次管理操作，以主机监控中采集设备的CPU占用率为例，操作步骤如下：

步骤一：创建监控项

登录控制台；

在控制台左侧菜单栏单击网络监控>监控项管理；

单击列表上方的创建监控项按钮，选择创建单设备监控项；

在打开的创建监控项页面，输入创建监控项所需的基础信息，例如监控项名称、描述、采集方式等；

为监控项定义一个全局唯一的监控项名称，如CPU_Monitor；

输入监控项描述，详细介绍当前监控项的意图，方便后期维护，如“通过SNMP监控设备CPU利用率”；

选择设备形态：如网络设备，则代表监控项采集范围为指定安全域下的网络设备；

选择SNMP采集类型，可选值为get、getNext、getBulk、getWalk、snmpwalk，这里选择snmpwalk；

打开启用状态，只有在监控项启用时才会发起采集；

编写解析代码，可根据实际情况修改

【可选】添加告警规则

单击提交按钮，保存监控项；

步骤二：部署监控项

在控制台左侧菜单栏单击网络监控>部署监控项；

从下拉列表中选择步骤一中创建的监控项：CPU_Monitor，可根据监控项名称模糊搜索；

***将自动展示出已经生成的厂商和型号列表，勾选监控项需要生效的型号条目，如期望监控厂商为Juniper，型号为MX480的设备，可勾选型号前的多选框；

针对SNMP监控项，需要对每个厂商型号设置OID，因为用到的OID可能是私有的，各个厂商可能存在差异，本文以Juniper的MX480为例，填入1.3.6.1.4.1.2636.3.1.13.1.8.9；

单击提交按钮，保存部署配置，此时***会将配置下发，开始采集。

步骤三：查看告警状态

在控制台左侧菜单栏单击网络监控>告警状态视图；

左侧选择对应的物理空间，右侧即可展示出该物理空间下所有已经采集的监控项和设备的状态，如需查看指定设备或指定监控项的监控状态，可在页面上方的条件搜索栏中输入对应的搜索条件，单击查询按钮进行过滤；

单击详情按钮，可跳转到详情页面查看详细信息。

单击设备视图按钮，可跳转到设备视图，该页面可总览指定设备的所有监控数据及历史趋势。

在一些实施例中，业务服务层3包括事件管理模块，以通过事件管理模块记录和处理突发事件，例如，IT基础设施和应用***中的突发事件；

事件管理模块，还用于自定义突发事件级别、事件分类，并进行突发事件通知，以及用于对突发事件进行查询统计，

显然，通过以上设置，能够详细记录突发事件处理的全过程，便于跟踪了解事件的整个处理过程。

在一些实施例中，业务服务层3包括工单管理模块，以通过工单管理模块对提交事件进行流程化管理，并与智能终端进行通信，以响应工单派单请求；

工单管理模，还用于对工单进行分类，以根据工单类型执行相应的运维流程，其中，工单分类可以为故障单、巡查单等。

在一些实施例中，业务服务层3包括资产管理模块，以通过资产管理模块获取并更新资产信息，并按照运维区域、资产所属方、资产类型、资产编号查看、统计、导出或导入、显示资产信息。

在一些实施例中，业务服务层3包括资产过保预警模块，以通过资产过保预警模块对资产的保质期进行监控、查询、统计、过保提醒或预警，例如：对已过保设备，剩余质保1个月、3个月、6个月、1年及1年以上的设备进行统计，并明细数据的查看及导出；

同时，可根据资产序列号对单个设备的过保信息进行查询。

在一些实施例中，业务服务层3包括备品备件管理模块，以通过备品备件管理模块与手机APP通信，以实现备品备件的入、出库管理，例如，采购入库、领用出库、返修入库和资产报废等。

在一些实施例中，业务服务层3包括统计分析模块，以通过统计分析模块对事件、资产、人员、设备进行统计和统计报表导出，具体为：

事件统计，包括SLA时效统计、用户业务受理情况统计，其中，以图表相结合的方式对SLA时效进行统计，统计项包括超时维修事件数量、事件总数、按时维修数量、按时维修率等。

用户业务受理情况统计项包括用户报修/咨询/投诉受理总数、完成数量、完成率、超时率等。

资产统计，包括资产数量、资产年限、库存数量、人员领用情况的统计。

人员考核统计，包括对服务台客服人员、前线维修工程师、维修人员开展图形化统计应用，具体：

根据故障问题的派单/确认报修回访数、用户投诉数、投诉回访数等对服务台客服人员开展绩效统计；

根据工单按时处理数量、超时处理数量、按时处理率、签收时长、签到时间、处理时间等对前线维修工程师开展统计。

故障统计，包括故障数量、故障原因的统计，以及对指定资源和区域故障资源进行查看。

工单统计，包括工单处理分布情况、完成工单来源分布情况、各区域故障完成分布情况等方面对工单开展统计。

设备运行统计，包括对监控摄像机在线率、视频完好率开展图形化统计。

在一些实施例中，业务服务层3包括知识库模块，以通过知识库模块提供知识库查看功能，并分类展现运维百科、硬件产品、软件产品、服务规范等内容，并推送展示可能感兴趣的知识、热门知识；

知识库模块，还用于知识库全文查询，根据关键字查询并展示搜索结果，包括标题、内容简略、发布人、时间等信息，并根据该关键字对应的资源类型，展示推荐知识；

知识库模块，还用于知识库内容上传、更新等。

在一些实施例中，业务服务层3包括运维考核模块，以通过运维考核模块综合参考服务水平协议、内部管理指标和服务成本因素，对运维执行过程进行分解量化，实现运维成果的展现和统计，并结合岗位能力给予考评，从而确保运维部门的工作效率和服务质量；

运维考核模块，还用于对服务台客服人员、维修人员以工作量开展考核应用，统计结果通过列表和图形两种方式进行展现。

在一些实施例中，业务服务层3包括移动运维应用模块，以通过移动运维应用模块与移动终端通信，进而通过移动终端部署相应的APP程序，以进行工单处理、知识库查询、GIS定位、语音提醒、备品备件管理等运维应用，进而满足随时随地响应运维需求。

在一些实施例中，用户访问层4包括可视化设备，以通过可视化设备与用户进行互动，其中，可视化设备包括运维大屏和地理信息视图模块，具体：

运维大屏，用于全面展现各类型资源的运行情况，例如，通过地图展现***内监控点、运维人员的运行分布情况，以及：

展现各类型资源的总数、健康度、信息完整度、综合评分，以及：

展现网络摄像机、抓拍机、终端服务器的在线率、图像完好率、硬盘完好率，主机的内存使用率、CPU等；

地理信息视图模块，用于结合GIS（地理信息***）实现空间地理可视化管理，所有运维资源信息的实时位置都通过GIS展示和操作，以及当监控资源与电子地图关联后，可以查看资源的周围地理信息，也可以通过地理位置查询资源，以使得用户能够快速检索GIS地图定位到故障点。

为了便于理解本发明的公交运行维护***的工作过程，在此以数据监控和用户操作类为例，进行说明：

（1）数据监控，如图6示，

步骤一：由数据采集模块进行设备端的IT基础数据采集和视频采集，然后将数据传输至与之连接的数据处理模块；

步骤二：数据处理模块对采集的数据进行分类和运算处理，将处理结果传输至与之连接的业务服务模块；

步骤三：业务服务模块根据各类服务的需求形成不同的表单，将结果传输至用户访问模块；

步骤四：用户访问模块将业务服务结果以图表形式展现给登录平台的管理者或用户，访问方式有PC端和移动端两种方式。

注：本文中的数据采集模块、数据处理模块、业务服务模块和用户访问模块，分别对应物联感知层、数据处理层、业务服务层和用户访问层。

（2）用户操作，如图7示，

步骤一：用户或管理者在PC端或移动终端进行所需服务的操作，数据指令由用户访问模块传输至业务服务模块；

步骤二：业务服务模块根据用户需求向与之连接的数据处理模块传递用户需求；

步骤三：数据处理模块收到业务需求后，对用户所需数据进行数据处理，并将结果返回至业务服务模块；

步骤四：业务服务模块收到处理后数据整理成用户所需的表单返回至用户访问模块 。

在一些实施例中，用户访问层4包括PC终端和/或移动终端，以通过PC终端和/或移动终端对业务服务层3进行访问，进行事件接收处理、满意度回访、工单派送、备品备件管理等应用。

需要声明的是，上述具体实施方式仅仅为本发明的较佳实施例及所运用技术原理。本领域技术人员应该明白，还可以对本发明做各种修改、等同替换、变化等等。但是，这些变换只要未背离本发明的精神，都应在本发明的保护范围之内。另外，本申请说明书和权利要求书所使用的一些术语并不是限制，仅仅是为了便于描述。

Claims (10)

1.一种公交运行维护***，其特征在于，包括：

物联感知层，用于实时获取与公交运行相关的设备的监控数据；

数据处理层，用于对各监控数据进行分析处理，以对应获取不同的运维信息；

业务服务层，用于对不同的运维信息进行分析，以构建出不同的业务服务；

用户访问层，用于对业务服务层进行访问，以能够开展不同的业务。

2.根据权利要求1所述的***，其特征在于，所述业务服务层包括综合监控模块，以通过所述综合监控模块提供设备状态监控、视频录像监控、视频矩阵监控、视频质量诊断监控、存储设备监控、主机监控、数据库监控、网络设备监控、标准应用监控、中间件监控和网络拓扑管理。

3.根据权利要求2所述的***，其特征在于，所述视频录像监控，用于根据预设时间对监控点位进行录像完整性检测，并当检测到录像缺失时，进行告警。

4.根据权利要求2所述的***，其特征在于，所述视频质量诊断监控，用于通过轮巡的方式，对前端设备的码流进行解码与图像质量评估，并将评估结果进行统计分析，并将分析结果以列表导出及图像化展示。

5.根据权利要求2所述的***，其特征在于，所述网络拓扑管理，用于根据拓扑生成算法，搜索整个网络内的网络设备，并勾画出整个网络的真实物理拓扑图，以真实反映整个网络的构成状况。

6.根据权利要求1所述的***，其特征在于，所述业务服务层包括工单管理模块，以通过所述工单管理模块对提交事件进行流程化管理，并与智能终端进行通信，以响应工单派单请求。

7.根据权利要求6所述的***，其特征在于，所述工单管理模，还用于对工单进行分类，以根据工单类型执行相应的运维流程。

8.根据权利要求1所述的***，其特征在于，所述业务服务层包括统计分析模块，以通过所述统计分析模块对事件、资产、人员、设备进行统计和统计报表导出。

9.根据权利要求1所述的***，其特征在于，所述业务服务层包括移动运维应用模块，以通过所述移动运维应用模块与移动终端通信，进而通过所述移动终端部署相应的APP程序，以进行工单处理、知识库查询、GIS定位、语音提醒、备品备件管理。

10.根据权利要求1所述的***，其特征在于，所述用户访问层4包括PC终端和/或移动终端，以通过所述PC终端和/或移动终端对所述业务服务层进行访问。

Images