一种多平台的工业设备维护管理系统及方法与流程

1.本发明涉及工业设备维护管理领域，尤其涉及一种多平台的工业设备维护管理系统及方法。


背景技术：

2.随着经济和科技的不断发展，在工业生产中所用到的自动化、智能化设备的数量与日俱增，设备作为工业生产的生命线，对工业生产活动的正常进行起着决定性的作用。如何快捷、高效的实现海量设备的维护与管理，已成为现代工业设备管理研究的一个重要组成部分。而设备维护管理系统作为企业的内部管理系统，是连接企业内部各部门之间分工协作的桥梁；目前，大多数企业采用的设备维护管理方法是将采购进来的设备的设备信息在设备维护管理系统中存档，然后每次设备故障或设备巡检后人为的将故障、巡检信息记录在设备维护管理系统的信息档案中；这种方法存在如下问题：1、当设备的数量较少时，采用这种方法具有一定的效益，但设备数量达到一定规模时，这种方法将会使得设备维护管理的工作量成倍增加；2、工作繁琐，导致效率低下，使得企业需要耗费大量的人力和物力资源来完成设备的维护管理，而且还可能因为工作人员的个人疏忽造成信息错误和/或信息缺失；3、设备管理人员与设备维护人员之间沟通不够流畅，跨部门合作跨公司合作效率低下，甚至会出现故障描述不清晰等问题，使得设备维护流程的整体效率不高。
3.因此，现有技术存在缺陷，需要改进。


技术实现要素：

4.本发明的目的是克服现有技术的不足，提供一种多平台的工业设备维护管理系统及方法。
5.首先，本发明提供一种多平台的工业设备维护管理系统，包括：app客户端，所述app客户端包括通过设备管理入口进入的设备管理端和通过设备维护入口进入的设备维护端，所述设备管理端用于满足设备管理员的工作需求，所述设备维护端用于满足设备维修员的工作需求；所述设备管理端设有设备管理模块，用于供所述设备管理员查询个人所负责设备的信息以及在发现设备故障时填写维修申请单，该维修申请单通过设备管理模块发送到系统，并通过系统派送给所述设备维护端以发起维修流程；所述设备维护端设有设备维护模块，用于供所述设备维修员接收及查看系统派发的维修申请单以及在完成维修任务后填写完工审查单，该完工审查单通过设备维护模块发送到系统，并通过系统派送给所述设备管理模块；web客户端，所述web客户端用于满足运维负责人的工作需求，包括用户管理模块、设备配置模块、设备台账模块和维保计划模块；所述用户管理模块用于供所述运维负责人根据每位下属用户的工作职责赋予该下属用户相对应的用户角色；所述设备配置模块用于供所述运维负责人将设备的信息录入系统，用于供所述运维负责人将设备的管理权限分配
给所述设备管理员以生成设备管理员清单，以及用于供所述运维负责人将设备的维护权限分配给所述设备维修员以生成设备维修员清单；所述设备台账模块用于供所述运维负责人查询设备维修信息及报表；所述维保计划模块用于供所述运维负责人制定并发布设备的定期维保计划，以及用于供所述运维负责人将制定好的定期维保计划与设备进行绑定；服务端后台，所述服务端后台分别与所述app客户端和web客户端通信连接，用于接收所述设备管理模块发送的维修申请单并将接收到的维修申请单派送给所述设备维护模块，用于接收所述设备维护模块发送的完工审查单并将接收到的完工申请单派送给所述设备管理模块，用于存储设备的信息、设备管理员清单、设备维修员清单、定期维保计划、以及基于设备维修流程分阶段记录的维修数据，以及用于根据定期维保计划生成相应的维修申请单并根据设备维修员清单分派给相应的设备维修员；所述服务端后台还与物联设备通信连接，所述物联设备通过定时发送心跳包的方式主动将设备的健康状态上报给所述服务端后台，所述服务端后台接收到所述物联设备发送来的心跳包后，通过判断该心跳包所含的信息是否存在异常来决定是否主动触发分派任务以实现对物联设备健康状态的智能管理。
6.进一步地，所述物联设备主动将设备的健康状态上报给所述服务端后台的具体实现方式包括如下步骤：步骤s11，将所述物联设备与服务端后台、设备接入网关对接好通信协议，并定义好传输的心跳包的数据包内容；其中，所述通信协议为tcp/ip协议，所述心跳包的数据包内容包含：请求头部、设备编号、消息长度、消息唯一识别码、及消息的内容；步骤s12，所述物联设备定时向所述设备接入网关推送心跳包；步骤s13，所述设备接入网关接收到所述物联设备推送来的心跳包后，将该心跳包推送给所述服务端后台；步骤s14，所述服务端后台接收到所述设备接入网关推送来的心跳包后，根据预先配置好的决策逻辑对该心跳包所含的消息的内容中各字段的值是否处于正常区间之内进行判定：c、如果服务端后台判定心跳包所含的消息的内容中各字段的值都是处于正常区间之内，则服务端后台生成设备正常的健康状态结论；d、如果服务端后台判定心跳包所含的消息的内容中各字段的值不是都处于正常区间之内，则服务端后台生成设备异常的健康状态结论，执行步骤s15；s15，如果服务端后台判定心跳包所含的信息存在异常，服务端后台记录物联设备的异常信息，并生成维修申请单派送给所述设备维护模块。
7.进一步地，所述消息的内容使用json格式实现，通过json中字段的嵌套来支持包含文字、数字、图片、音频、视频在内的所有类型的数据传输，且音频和视频数据通过base64转码后再进行传输；所述消息的内容的数据内容包含：设备状态、温度及电量。
8.进一步地，所述步骤s12和所述步骤s13通过java nio组件来进行所述物联设备与所述设备接入网关之间的tcp通信。
9.进一步地，所述java nio组件的实现方式为：首先，创建一个同步非阻塞线程类，包含一个用于监听通道的选择器对象和一个用于存储通道的阻塞队列；然后，重写线程对
象的运行方法实现对通道的监听和处理工作；接着，创建一个选择器队列并初始化，启动一个监听新进来的tcp连接的通道，将选择器队列中的选择器和监听新进来的tcp连接的通道绑定，完成服务端服务的编码；最后，所述物联设备在与所述设备接入网关建立连接后，向通道中的缓存区写入信息来完成与所述服务端后台的通信。
10.进一步地，所述设备管理端和所述设备维护端还均设有个人中心模块，所述个人中心模块用于供所述设备管理员和设备维修员查询个人工作情况。
11.进一步地，所述app客户端的载体包括手机、电脑、平板、pda之中的任意一种。
12.进一步地，所述设备管理员通过所述设备管理模块填写的维修申请单记载的信息至少包括设备编号、设备名称、地点、故障时间、设备故障描述、设备现场图像和维修紧急程度；所述设备维修理员通过所述设备维护模块填写的完工审查单记载的信息至少包括工作的内容、维修的设备的信息、设备当前状态、故障是否已解决和备注说明。
13.其次，本发明还提供一种多平台的工业设备维护管理方法，包括如下步骤：步骤s1，生成维修申请单，并通过服务端后台分派生成的维修申请单；步骤s2，设备维修员通过设备维护模块接收并查看维修申请单；步骤s3，设备维修员对设备进行维修；步骤s4，设备维修员完成维修任务后，通过设备维护模块填写完工审查单，并将该完工审查单发送给服务端后台；步骤s5，服务端后台接收到来自设备维护模块的完工审查单后，根据设备管理员清单将该完工审查单分派给相应的设备管理员；步骤s6，设备管理员通过设备管理模块接收及查看服务端后台发送来的完工审查单，根据设备故障恢复情况对维修结果进行判定：e、如果设备故障恢复情况达到要求，则设备管理员通过该完工审查单；f、如果设备故障恢复情况达不到要求，则设备管理员驳回该完工审查单，重复步骤s3~步骤s6。
14.进一步地，所述步骤s1的具体实现方式包括：g、设备管理员发现设备故障后，通过设备管理模块填写维修申请单并发送给服务端后台，服务端后台接收到来自设备管理模块的维修申请单后，根据设备维修员清单分派该维修申请单；h、运维负责人通过维保计划模块发布定期维保计划后，服务端后台根据该定期维保计划生成相应的维修申请单，并根据设备维修员清单分派维修申请单；i、服务端后台接收到来自物联设备的心跳包且判定该心跳包所含的信息存在异常后，服务端后台记录物联设备的异常信息并生成维修申请单，并根据设备维修员清单分派维修申请单。
15.采用上述方案，本发明具有以下有益效果：1、通过app客户端和web客户端给设备运营总责人、设备管理人员、设备维护人员甚至是第三方厂家维修人员提供了一个直接沟通的渠道，使不同工种、不同部门甚至不同公司的工作人员能十分方便快捷的对接工作，直接提升了运维工作的时效性，使整个维修流程变得透明，规避了维修流程中由于人为原因导致的消息不对称问题；
2、优选方案中将角色与权限进行绑定，再将用户与角色进行绑定，然后将用户与设备进行绑定，从而完成设备、权限、人员之间的隔离，基于单个设备实现rbac访问控制，用户对设备资源的访问是基于其对于该设备所被赋予的角色，每个用户只用对自己的任务负责，当设备数量不断增长时，也不会对系统的运行效率和稳定性产生影响，使系统具备了海量设备的运维管理接入能力；3、优选方案中编解码器能通过请求头部参数head和消息长度参数length快速解析出一条指令的头部和尾部，十分便捷的解决了tcp通信中最烦人的粘包拆包问题，并且没有对指令的内容作出任何限制；4、优选方案中消息的内容参数content默认使用json格式实现，通过json中字段的嵌套，能支持包含文字、数字、图片、音频、视频在内的所有类型的数据传输，音频、视频等数据可通过base64转码后完成传输；5、优选方案中使用selector来监听多个通道事件，因此使用单个线程就能同时和多个设备通信，且nio以块的方式处理数据，比流式处理的速度要更快，所以系统的响应时间更短，同时selector在一台设备的通信空闲时，可以处理所监听的其他设备的信息，提高了系统资源的利用率。
附图说明
16.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图示出的结构获得其他的附图。
17.图1为本发明多平台的工业设备维护管理系统的系统结构框图；图2为本发明多平台的工业设备维护管理系统中物联设备与设备接入网关实现通信的通信原理框图；图3为本发明多平台的工业设备维护管理方法的步骤流程图。
18.本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
19.以下结合附图和具体实施例，对本发明进行详细说明。
20.首先，参照图1和图2所示，本发明提供一种多平台的工业设备维护管理系统，用于对工业生产活动中所用的设备进行维护管理，该设备包括传统设备和物联设备4（物联设备4为具有物联属性的设备）；该工业设备维护管理系统包括：app客户端1，所述app客户端1的载体包括手机、电脑、平板、pda（手持终端）之中的任意一种，用于满足设备管理员和设备维修员的工作需求；所述app客户端1包括通过设备管理入口进入的设备管理端11和通过设备维护入口进入的设备维护端12，所述设备管理端11用于满足所述设备管理员的工作需求，所述设备维护端12用于满足所述设备维修员的工作需求；所述设备管理端11和所述设备维护端12均设有个人中心模块，所述设备管理端11还设有设备管理模块，所述设备维护端12还设有设备维护模块，所述设备管理模块用于供所述设备管理员查询个人所负责设备的信息以及在发现设备故障时填写维修申请单，该维
修申请单通过设备管理模块发送到系统并通过系统派送给所述设备维护模块以发起维修流程，所述设备维护模块用于供所述设备维修员接收及查看系统派发的维修申请单以及在完成维修任务后填写完工审查单，该完工审查单通过设备维护模块发送到系统并通过系统派送给所述设备管理模块，所述个人中心模块用于供所述设备管理员和设备维修员查询个人工作情况，也就是说，实际工作中设备管理员通过设备管理模块能够查询到个人所负责设备的信息，当设备管理员现设备故障时，设备管理员通过设备管理模块填写维修申请单，并通过设备管理模块将该维修申请单发送到系统的服务端后台3，由服务端后台3将该维修申请单派送到设备维护模块，从而发起维修请求，当设备管理员需要查询个人所负责设备是否有维修记录时，设备管理员可通过个人中心模块查询个人的维修申请单来获取设备的维修情况，而设备维修员通过设备维护模块接收到系统的服务端后台3派发的维修申请单后，设备维修员可通过设备维护模块查看接收到的维修申请单，当设备管理员完成维修申请单所对应维修任务后可通过设备维护模块填写完工审查单，并通过设备维护模块将该完工审查单发送到服务端后台3，由服务端后台3将该完工审查单派送到设备管理模块，从而发起审查请求，当设备维修员需要查询个人所负责设备是否有维修记录时，设备维修员可通过个人中心模块查询个人的完工审查单来获取设备的维修情况；其中，所述设备管理员通过所述设备管理模块填写的维修申请单记载的信息至少包括设备编号、设备名称、地点、故障时间、设备故障描述、设备现场图像和维修紧急程度，所述设备维修理员通过所述设备维护模块填写的完工审查单记载的信息至少包括工作的内容、维修的设备的信息、设备当前状态、故障是否已解决和备注说明；web客户端2，所述web客户端2用于满足运维负责人的工作需求；所述web客户端2包括用户管理模块、设备配置模块、设备台账模块和维保计划模块；所述用户管理模块提供对系统成员、角色进行统一管理的功能，用于供所述运维负责人根据每位下属用户（即归属该运维负责人管理的用户）的工作职责赋予该下属用户相对应的用户角色，不同用户角色对应不同的权限，从而实现用户与权限的绑定，进而实现权限资源的隔离，也就是说，实际工作中运维负责人登录web客户端2后，运维负责人根据每位下属用户的工作职责通过用户管理模块赋予该下属用户账号相对应的用户角色，例如：运维负责人通过用户管理模块给下属设备管理人员的账号赋予设备管理员的用户角色，并通过用户管理模块给下属设备维修人员的账号赋予设备维修员的用户角色；所述设备配置模块提供设备权限管理功能，用于供所述运维负责人将设备的信息录入系统的服务端后台3，用于供所述运维负责人将设备的管理权限分配给所述设备管理员以生成设备管理员清单，以及用于供所述运维负责人将设备的维护权限分配给所述设备维修员以生成设备维修员清单，从而实现用户与设备的绑定，使得不同的用户只需负责个人任务，进而实现设备资源的隔离，也就是说，实际工作中运维负责人通过设备配置模块将设备的信息录入到系统的服务端后台3，通过设备配置模块将设备的管理权限分配给设备管理员生成设备管理员清单，并通过设备配置模块将设备的维护权限分配给设备维修员生成设备维修员清单，其中，运维负责人将用户与设备进行绑定包括以下两种方式：a、如果设备的数量较少，运维负责人通过设备配置模块将单个设备直接与下属用户进行绑定，从而完成单个用户与单个设备细粒度的权限映射；b、如果设备的数量较大或者数量不明确，运维负责人通过设备配置模块先将所有
设备分成若干分组，再将每一分组与下属用户进行绑定，从而完成单个用户与每个分组细粒度的权限映射，单个用户对同一分组内的设备拥有相同权限；在本实施例中，统一采用b绑定方式进行用户与设备的绑定，从而为后期可能的设备接入预留空间，方便于扩展；所述设备台账模块提供设备信息查询、报表功能，用于供运维负责人查询设备维修信息及相关报表，具体用于供所述运维负责人查询及导出单台设备维修信息、设备维修记录报表、设备维修费用报表、设备维护员个人维护记录报表、设备故障率报表等信息；所述维保计划模块提供设备定期维护功能，用于供所述运维负责人制定并发布设备的定期维保计划，以及用于供所述运维负责人将制定好的定期维保计划与设备进行绑定，从而实现自动化通知相关负责人；服务端后台3，所述服务端后台3分别与所述app客户端1和web客户端2通信连接，所述服务端后台3用于存储数据与分派任务，具体是用于存储该工业设备维护管理系统的所有数据以及用于分派任务到具体的负责人；具体的，所述服务端后台3用于接收所述设备管理模块发送的维修申请单并将接收到的维修申请单派送给所述设备维护模块，从而将具体设备的维修申请单分配给负责该设备的设备维修员进行维修以实现任务分派，所述服务端后台3还用于接收所述设备维护模块发送的完工审查单并将接收到的完工申请单派送给所述设备管理模块，从而将具体设备的完工审查单分配给该设备的设备管理员进行审核以实现任务分派，所述服务端后台3还用于存储所述运维负责人通过所述设备配置模块录入的设备的信息、所述运维负责人通过所述设备配置模块生成的设备管理员清单和设备维修员清单、所述运维负责人通过所述维保计划模块制定并发布的定期维保计划、以及基于设备维修流程分阶段记录的维修数据等数据，所述服务端后台3还用于根据定期维保计划生成相应的维修申请单并根据设备维修员清单分派给相应的设备维修员，从而服务端后台3能够将接收到的维修申请单根据设备维修员清单分派给相应的设备维修员，能够将接收到的完工审查单根据设备管理员清单分派给相应的设备管理员，还能够根据定期维保计划触发分派任务，进而实现任务的分派操作，且由于服务端后台3基于设备维修的流程分阶段记录维修数据，保障了过程数据的完整性和可靠性，同时配合设备台账模块能方便快捷的生成各种设备信息、维修信息报表，自动化的完成了设备运维记录的管理工作，相比于目前的设备档案人工管理，具有数据更可靠、查询更便捷、报表更直观的优点，而且管理成本也不会随着管理规模的扩大而明显增加；所述服务端后台3还与具有物联属性的物联设备4通信连接，具体的，所述服务端后台3与所述物联设备4是通过设备接入网关5实现的通信连接，所述物联设备4通过定时发送心跳包的方式主动将设备的健康状态上报给所述服务端后台3，所述服务端后台3接收到所述物联设备4发送来的心跳包后，通过判断该心跳包所含的信息是否存在异常来决定是否主动触发分派任务以实现对物联设备4健康状态的智能管理，也就是说，当服务端后台3判断接收到的心跳包所含的信息存在异常时，服务端后台3主动触发分派任务通知负责该设备的设备维修员进行维修，具体的，所述物联设备4主动将设备的健康状态上报给所述服务端后台3的具体实现方式包括如下步骤：步骤s11，将所述物联设备4与所述服务端后台3、设备接入网关5对接好通信协议，并定义好传输的心跳包的数据包内容；在本实施例中，所述通信协议为tcp/ip协议，即使用tcp/ip协议来进行数据传输，也就是说，物联设备4、设备接入网关5、服务端后台3三者之间进行的是tcp通信，保障了数据传输的可靠性，其中，所述心跳包的数据包内容通过定义数
据包格式的方式进行定义，本实施例采用的数据包格式为：public class messageprotocol implements serializable {
ꢀꢀꢀꢀꢀꢀ
private short head;
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
//请求头部
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
private byte cmd;
ꢀꢀꢀꢀꢀꢀꢀ
//设备编号
ꢀꢀꢀꢀꢀꢀ
private int length;
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
//消息长度
ꢀꢀꢀꢀꢀꢀ
private byte[] uuid;
ꢀꢀꢀꢀꢀꢀꢀꢀꢀ
//消息唯一识别码
ꢀꢀꢀꢀꢀꢀꢀꢀ
private byte[] content;
ꢀꢀꢀꢀ
//消息的内容}，也就是说，所述心跳包的数据包内容包含：请求头部、设备编号、消息长度、消息唯一识别码、及消息的内容；其中，消息的内容（即参数content，content表示内容）包含设备的健康信息，因设备类型不同，需要发送的数据格式也往往不一样，只需根据设备特征定义好参数content即可，消息的内容默认使用json格式实现，通过json中字段的嵌套来支持包含文字、数字、图片、音频、视频在内的所有类型的数据传输，且音频、视频等数据要先通过base64转码后再进行传输，本实施例提供的一种消息的内容定义的数据内容如下：{
ꢀꢀꢀꢀ
"status":x,
ꢀꢀꢀꢀꢀꢀꢀꢀꢀ
"electric":y,
ꢀꢀꢀꢀ
"temperature":z}，需要说明的是，x用于表示设备状态，y用于表示设备电量，z用于表示设备温度，因为不同物联设备4的状态可能不同，所以设备状态、设备电量和设备温度为变量，这里采用x、y、z进行示例表述，实际运行中是通过具体数值进行表示，例如：以0代表设备状态正常，设备电量为80%且设备温度为50℃时，则消息的内容的数据内容表示为：{
ꢀꢀꢀꢀ
"status":0,
ꢀꢀꢀꢀꢀꢀꢀꢀꢀ
"electric":80,
ꢀꢀꢀꢀ
"temperature":52}；也就是说，消息的内容的数据内容包含：设备状态、温度、及电量；值得一提的是，采用此数据包格式，具有如下优点：1、编解码器能通过请求头部参数head和消息长度参数length快速解析出一条指令的头部和尾部，十分便捷的解决了tcp通信中最烦人的粘包拆包问题，并且没有对指令的内容作出任何限制；2、消息的内容参数content默认使用json格式实现，通过json中字段的嵌套，能支持包含文字、数字、图片、音频、视频在内的所有类型的数据传输，音频、视频等数据可通过base64转码后完成传输；步骤s12，所述物联设备4定时向所述设备接入网关5推送心跳包，即各物联设备4根据步骤s1定义好的数据包格式，通过定时心跳的方式将心跳包推送给所述设备接入网关5；
步骤s13，所述设备接入网关5接收到所述物联设备4推送来的心跳包后，将该心跳包推送给服务端后台3；步骤s14，所述服务端后台3接收到所述设备接入网关5推送来的心跳包后，根据预先配置好的决策逻辑对该心跳包所含的消息的内容中各字段的值是否处于正常区间之内进行判定：c、如果服务端后台3判定心跳包所含的消息的内容中各字段的值都是处于正常区间之内，则服务端后台3生成设备正常的健康状态结论；d、如果服务端后台3判定心跳包所含的消息的内容中各字段的值不是都处于正常区间之内，即服务端后台3判定心跳包所含的信息存在异常，则服务端后台3生成设备异常的健康状态结论，执行步骤s15；步骤s15，如果服务端后台3判定心跳包所含的信息存在异常，服务端后台3记录物联设备4的异常信息，并生成维修申请单派送给所述设备维护模块，从而通知到相应的设备维修员；由于本系统具有设备数量多、设备种类杂的特点，如果以bio的方式采用serversocket来进行tcp通信，那么每有一个设备接入，设备接入网关5和服务端后台3就需要启动一个新的线程与之通信，而随着线程数的增加，服务端后台3的响应速度也会越来越慢，对系统的吞吐量会造成很大困扰；为解决这一问题，所述步骤12和所述步骤13通过java nio组件来进行物联设备4与设备接入网关5之间的tcp通信，也就是在步骤s12、s13的过程中使用java nio组件来进行所述物联设备4与所述设备接入网关5之间的tcp通信，从而实现了一套多线程非阻塞的tcp通信方式；具体的，所述java nio组件的实现方式如下：首先，创建一个niothread线程类（同步非阻塞线程类），包含一个用于监听channel（通道）的selector（选择器）对象和一个用于存储channel（通道）的阻塞队列（blockingqueue）；具体的，创建niothread线程类的一种实现代码如下：class selectorthread extends thread {
ꢀꢀꢀꢀꢀ
selector selector = null;
ꢀꢀꢀ
//用于监听channel
ꢀꢀꢀꢀꢀ
static int selectors = 0;
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
//最大连接数
ꢀꢀꢀꢀꢀ
volatile static blockingqueue<socketchannel>[] queue;
ꢀꢀꢀꢀꢀꢀꢀꢀꢀ
//用于存放channel
ꢀꢀꢀꢀꢀ
}；然后，重写thread（线程）对象的run（运行）方法实现对channel（通道）的监听和处理工作；具体的，一种实现代码如下：
；其中，run（运行）方法实现的主要逻辑如下：1、循环查询该线程下的selector（选择器），看该通道注册的事件有没有就绪；2、如果没有则继续死循环继续查询，如果有则查询该事件的种类；3、如果是通讯事件，则读取数据包中的内容，并按照业务逻辑对数据进行处理；4、如果是连接事件，则把该连接对象放入阻塞队列中，与该通道建立连接；5、捕获异常，并抛出异常信息；接着，创建一个selector（选择器）队列并初始化，启动一个serversocketchannel（监听新进来的tcp连接的通道），将selector（选择器）队列中的selector（选择器）和serversocketchannel（监听新进来的tcp连接的通道）绑定，完成服务端service（服务）的编码；具体的，一种实现代码如下：//启动服务socketmultiplexingthreads service = new socketmultiplexingthreads();//初始化list <niothread> niothreadlist=new arraylist();service.selectorlist.foreach(e
‑
>niothreadlist.add(new niothread(e)));niothreadlist.foreach(e
‑
>e.start());最后，设备端（即物联设备4）在与服务网关（即设备接入网关5）建立连接后，向
channel（通道）中的buffer（缓存区）写入信息来完成与客户端（即服务端后台3）的通信；采用这种通信方式具有如下优点：1、使用selector（选择器）来监听多个通道事件，因此使用单个线程就能同时和多个设备通信；2、nio以块的方式处理数据，比流式处理的速度要更快，所以系统的响应时间更短；3、selector（选择器）在一台设备的通信空闲时，可以处理所监听的其他设备的信息，提高了系统资源的利用率；也就是说，本系统对传统设备进行的维护管理主要通过人为干预的方式，而本系统对物联设备4进行的维护管理是通过自动逻辑决策和人为干预相结合的方式，从而能够让物联设备4在无人干预的情况下，实现故障自发现、故障自处理、故障自修复。
[0021]
以上可以看出，本发明提供的一种多平台的工业设备维护管理系统的工作过程及原理如下：首先，运维负责人通过web客户端2将设备的信息录入到服务端后台3并分别与设备管理员和设备维修员进行绑定，设备管理员通过app客户端1的设备管理端11完成对设备的管理，而设备维修员通过app客户端1的设备维护端12完成对设备的维护，即当设备管理员发现设备故障时，设备管理员通过设备管理模块填写维修申请单并发送到服务端后台3，服务端后台3根据维修员清单将维修申请单分派给具体的设备维修员，设备维修员通过设备维护模块接收及查看维修申请单，并在完成维修任务后通过设备维护模块填写完工审查单，该完工审查单发送到服务端后台3，由服务端后台3根据设备管理员清单将该完工审查单分派给具体的设备管理员，设备管理员通过设备管理模块接收及查看完工审查单，并根据设备故障恢复情况通过或驳回该完工审查单，且服务端后台3基于设备维修的流程分阶段详细记录维修数据，并对数据进行分类、汇总、分析等操作，最终通过web客户端2对外提供设备维修信息及报表，实现维修信息的自动归档和自动结算；另一方面，运维负责人通过维保计划模块发布定期维保计划后，服务端后台3会根据该定期维保计划生成相应的维修申请单，并根据设备维修员清单分派维修申请单，后续维修流程参照通过设备管理员发起维修流程的相关流程；再一方面，服务端后台3接收到来自物联设备4的心跳包且判定该心跳包所含的信息存在异常后，服务端后台3会记录异常信息并生成维修申请单，并根据设备维修员清单分派维修申请单，后续维修流程参照通过设备管理员发起维修流程的相关流程。
[0022]
值得一提的是，本系统将角色与权限进行绑定，再将用户与角色进行绑定，然后将用户与设备进行绑定，从而完成设备、权限、人员之间的隔离，基于单个设备实现rbac访问控制，用户对设备资源的访问是基于其对于该设备所被赋予的角色，每个用户只用对自己的任务负责，当设备数量不断增长时，也不会对系统的运行效率和稳定性产生影响，使系统具备了海量设备的运维管理接入能力；本系统通过app客户端1和web客户端2，给运维负责人、设备管理人员、设备维修人员甚至是第三方厂家维修人员提供了一个直接沟通的渠道，使不同工种、不同部门甚至不同公司的工作人员能十分方便快捷的对接工作，直接提升了运维工作的时效性，使整个维修流程变得透明，规避了维修流程中由于人为原因导致的消息不对称问题。
[0023]
其次，参照图3所示，本发明还提供一种多平台的工业设备维护管理方法，包括如下步骤：步骤s1，生成维修申请单，并通过服务端后台分派生成的维修申请单；其中，步骤s1的具体实现方式包括：g、设备管理员发现设备故障后，通过设备管理模块填写维修申请单，并将该维修申请单发送给服务端后台；服务端后台接收到来自设备管理模块的维修申请单后，根据设备维修员清单分派该维修申请单；h、运维负责人通过维保计划模块发布定期维保计划后，服务端后台根据该定期维保计划生成相应的维修申请单，并根据设备维修员清单分派维修申请单；i、服务端后台接收到来自物联设备的心跳包且判定该心跳包所含的信息存在异常后，服务端后台记录物联设备的异常信息并生成维修申请单，并根据设备维修员清单分派维修申请单；步骤s2，设备维修员通过设备维护模块接收并查看维修申请单，即设备维修员通过设备维护模块接收到维修申请单后，设备维修员通过设备维护模块查看维修申请单以获取维修任务的信息；步骤s3，设备维修员对设备进行维修；步骤s4，设备维修员完成维修任务后，通过设备维护模块填写完工审查单，并将该完工审查单发送给服务端后台；步骤s5，服务端后台接收到来自设备维护模块的完工审查单后，根据设备管理员清单将该完工审查单分派给相应的设备管理员；步骤s6，设备管理员通过设备管理模块接收及查看服务端后台发送来的完工审查单，根据设备故障恢复情况对维修结果进行判定：e、如果设备故障恢复情况达到预设要求，说明维修解决了故障，则设备管理员通过该完工审查单，完成一个维修流程；f、如果设备故障恢复情况达不到预设要求，说明维修没有解决故障，则设备管理员驳回该完工审查单，重复步骤s3~步骤s6，直至维修通过。
[0024]
与现有技术相比，本发明具有以下有益效果：1、通过app客户端和web客户端给设备运营总责人、设备管理人员、设备维护人员甚至是第三方厂家维修人员提供了一个直接沟通的渠道，使不同工种、不同部门甚至不同公司的工作人员能十分方便快捷的对接工作，直接提升了运维工作的时效性，使整个维修流程变得透明，规避了维修流程中由于人为原因导致的消息不对称问题；2、优选方案中将角色与权限进行绑定，再将用户与角色进行绑定，然后将用户与设备进行绑定，从而完成设备、权限、人员之间的隔离，基于单个设备实现rbac访问控制，用户对设备资源的访问是基于其对于该设备所被赋予的角色，每个用户只用对自己的任务负责，当设备数量不断增长时，也不会对系统的运行效率和稳定性产生影响，使系统具备了海量设备的运维管理接入能力；3、优选方案中编解码器能通过请求头部参数head和消息长度参数length快速解析出一条指令的头部和尾部，十分便捷的解决了tcp通信中最烦人的粘包拆包问题，并且没有对指令的内容作出任何限制；
4、优选方案中消息的内容参数content默认使用json格式实现，通过json中字段的嵌套，能支持包含文字、数字、图片、音频、视频在内的所有类型的数据传输，音频、视频等数据可通过base64转码后完成传输；5、优选方案中使用selector来监听多个通道事件，因此使用单个线程就能同时和多个设备通信，且nio以块的方式处理数据，比流式处理的速度要更快，所以系统的响应时间更短，同时selector在一台设备的通信空闲时，可以处理所监听的其他设备的信息，提高了系统资源的利用率。
[0025]
以上仅为本发明的较佳实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。