一种用于钢铁冶炼产线上的实时报警方法与流程

1.本发明涉及工业物联网领域，特别涉及一种用于钢铁冶炼产线上的实时报警方法。


背景技术：

2.物联网(internet of things，iot)、云计算、大数据等新兴信息技术的出现，标志着智能制造时代的到来。而智能和互联的主旨都在于通过充分利用信息通讯技术，把资源、机器、产品和人有机结合在一起，推动制造业向基于大数据分析与应用智能化的方向转型。钢铁工业是自动化程度较高的流程式行业之一，也是发展我国先进制造业、打造先进制造业集群不可或缺的一部分。在钢铁冶炼生产场景中，设备报警功能对于工业产线的正常运转、生产安全，甚至劳动者的生命，企业的财产保障都有着极高的重要性。报警功能的重点就是报警模块的稳定性，报警通知的实时性。按照工业物联网的要求，在设备发生故障，设备数据不再安全阈值范围内时，物联网平台、报警设备及相关负责人都要收到通知，并且能够及时查看报警数据，了解设备状态并对其进行相关处理，以免造成严重后果。
3.目前，传统的物联网系统一般将数据保存到关系型数据库中。接收到数据后，根据设备标志符从数据库查询相应报警规则，数据处理后，再将报警数据存回数据库。数据库虽然能可靠地保存数据，但由于在工业物联网场景下，设备上报数据量是相当巨大的，而且数据传输频率也是很高的，在这种大数据的环境下，如果持续进行数据库io操作，势必会给平台造成严重的危害。
4.常见的报警系统在用户页面采用轮询的方式，通过http请求从服务器周期性地拉取报警数据。轮询的方式虽然简单，但是弊端很多。首先轮询是有时间间隔的，所以报警最基本的实时性难以保证。即使缩短轮询时间间隔，仍会引起网络及数据库io频繁操作，在没有报警的时候，造成了很大的信息系统资源浪费。况且，正常情况下报警是极少发生的，不应过度监视。同时，传统的物联网平台，各个模块耦合在同一个软件工程中，这样一旦其中某些业务发生问题，就会导致整个平台出现问题。
5.可以注意到，以上流程有多次的数据库io操作，而通知方式单一，用户无法在第一时间感知设备报警，业务耦合性强。既不能保证报警的实时性和准确性，也给服务器造成了压力。长此以往，会导致平台运行的不稳定。那么如何解决重复的数据库io，及单一的通知方式便是一个现实的问题。另一方面，钢铁冶炼产线设备安全风险不同于其它行业，一旦发生异常很有可能会造成严重后果。而客户端websocket通讯及邮件/短信等方式不一定能百分百第一时间通知到报警联系人，如此便不能及时通知生产现场情况。


技术实现要素：

6.本发明要解决的技术问题是提供一种用于钢铁冶炼产线上的实时报警方法，基于kafka消息队列解耦，非关系型数据库redis存储，多种消息推送方式结合的高效的报警推送方法。
7.为解决上述技术问题，本发明的内容包括：一种用于钢铁冶炼产线上的实时报警方法，所述方法包括如下步骤：步骤s1：设备上报数据通过mqtt协议传输至物联网平台的mqtt broker消息代理服务中间件；步骤s2：mqtt broker将接收到的设备数据直接推送至消息队列kafka，通过消息队列kafka将报警服务与其它服务解耦；步骤s3：规则引擎从kafka中获取设备数据后，根据设备唯一标志符，从非关系型数据库redis中按照业务需求获取预设的相应报警规则，匹配触发报警条件的数据阈值；步骤s4：规则引擎对设备数据进行处理，处于正常值域的设备数据直接跳过，数据处理后触发的报警生成报警通知并发送。
8.进一步的，所述步骤s1中，采用emq x作为mqtt的broker负责接收设备上报数据。
9.进一步的，所述步骤s4中，报警通知被发送到websocket server服务端，再通过设备唯一标识符获取websoket session发送至websocket client客户端。
10.进一步的，所述步骤s4中，报警通知通过mqtt协议下发到报警终端设备。
11.进一步的，所述步骤s4中，报警通知以短信或邮件的方式发送给报警联系人。
12.本发明的有益效果是：本发明首先通过消息队列将报警服务与其它服务解耦，其次将部分数据存储到缓存数据库redis，经过规则引擎的梳理，通过多种方式推送给用户。测试表明，本方法在保证数据实时及准确性的基础上，不仅降低了服务器压力，还降低了网络流量，提高了吞吐量。
附图说明
13.图1是本发明的整体设计数据流程示意图；图2是mqtt broker接收到数据后投递到下游kafka的流程示意图；图3是websocket连接平台及推送报警消息示意图；图4是测试验证结果统计图。
具体实施方式
14.为便于理解本发明，下面结合附图和具体实施方式对本发明作进一步详细的说明。本领域技术人员应该明了，所述实施例仅仅是帮助理解本发明，不应视为对本发明的具体限制。
15.如图1-3所示，本发明提供了一种用于钢铁冶炼产线上的实时报警方法，包括如下步骤：步骤s1：设备上报数据通过mqtt协议传输至物联网平台的mqtt broker消息代理服务中间件。
16.采用emq x作为mqtt的broker负责接收设备上报数据。emqx 是全球领先的开源物联网应用，完全支持mqtt 5.0协议，具备高并发、低延时的特性，支持边缘及云端部署。引入emqx作为mqtt服务的消息代理中间件，是一种高效可靠的技术路线。
17.步骤s2：mqtt broker将接收到的设备数据直接推送至消息队列kafka，通过消息队列kafka将报警服务与其它服务解耦，短时间持久化数据。
18.kafka消息队列负责解耦不同的业务模块，短时间持久化数据。kafka作为时下最流行的开源消息系统，被广泛地应用在数据缓冲、异步通信、汇集日志、系统解耦等方面。相比较于rocketmq等其它常见消息系统，kafka在保障了大部分功能特性的同时，还提供了超一流的读写能力。
19.步骤s3：规则引擎从kafka中获取设备数据后，根据设备唯一标志符，从非关系型数据库redis中按照业务需求获取预设的相应报警规则，匹配触发报警条件的数据阈值。
20.规则引擎作为kafka的消费者，获取到设备上报数据，根据设备唯一标志符，从缓存redis中查询相应报警规则。redis是一个开源的内存数据存储系统，它可以作为数据库、缓存和消息中间件。redis的所有数据均位于服务器的主内存中，因此读写速度非常快。每秒可执行10万次以上的读写操作。采用redis的优势是降低数据库io压力，保证报警消息的实时性。
21.步骤s4：规则引擎对设备数据进行处理，处于正常值域的设备数据直接跳过，数据处理后触发的报警生成报警通知并发送。
22.报警通知发送到websocket的同时，平台还会以mqtt的方式下发到现场报警终端设备，并以短信或邮件的方式发送给报警联系人。最大限度的保证报警通知的有效性，降低生产风险。
23.报警通知被发送到websocket server服务端，再通过设备唯一标识符获取websoket session发送至websocket client客户端。
24.客户端使用websocket协议连接平台时，平台将维护websocket session与设备唯一标识符的关系。经过规则引擎计算后，不需要报警的数据将跳过本流程的后续通知动作。报警消息将通过设备唯一标识符获取websoket session发送至websocket client客户端。websocket是一种在单个tcp连接上进行全双工通信的协议。websocket的出现，使得浏览器具备了实时双向通信的能力。引入websocket的目的在于，取代客户端轮询方案，降低报警延迟，减少网络io，最重要的是降低了数据库压力。
25.如图4所示，针对以上内容进行了相关测试，测试环境如下：服务器硬件配置为8核cpu，16 gb内存。服务器操作系统为centos 7，java使用jdk8，websocket服务端使用springboot集成的websocket。本发明定义报警的延迟为：从服务端产生报警的时间到客户端收到报警的时间差。以生产线进行测试，对传感器终端的数据采集、网络数据收发的逻辑进行监控。比较服务端产生报警的时间戳和客户端接收到报警的时间戳，即可计算出报警推送的延迟。考虑到实际生产中报警这种行为虽然不会高并发产生，为了测试极端情况，每500ms秒推送一次报警，共推送5000条报警数据，从服务端产生报警数据到客户端收到报警推送的时间延迟平均值为6.5 ms。传统页面轮询间隔大约是5s到10s，可见报警实时性大大提高。使用jmeter模拟websocket并发连接，对websocket服务器进行压力测试。在每个并发连接数下， 推送5000条数据，取推送延迟的平均值。结果表明，随着 websocket并发连接数增长，推送延迟并未出现大幅度增长，而是在8ms左右波动。
26.当没有报警数据的时候，如果采用轮询的方式，假设轮询间隔为5s，即便只有100个客户端，那么每分钟也会产生1200网络io，同时会产生1200个数据库io。这就对服务器造成了不必要的资源浪费。而采用websocket的方式，在报警静默的时候不会产生网络及数据库io，显而易见的减少了相应压力。
27.尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。