CN112164210A

CN112164210A - 一种基于对象的预警方法、装置、存储介质及电子设备

Info

Publication number: CN112164210A
Application number: CN202010974471.8A
Authority: CN
Inventors: 朱礼勇; 高建丰; 徐鹏; 朱亚华; 陶万军
Original assignee: Nanjing Leading Technology Co Ltd
Current assignee: Nanjing Leading Technology Co Ltd
Priority date: 2020-09-16
Filing date: 2020-09-16
Publication date: 2021-01-01
Anticipated expiration: 2040-09-16
Also published as: CN112164210B

Abstract

本申请实施例公开了一种基于对象的预警方法、装置、存储介质及电子设备。该方法包括：获取检测对象的周期性检测的状态数据；若所述状态数据满足预设条件，则将当前检测周期累加到连续执行时间；若所述连续执行时间超过第一预设时长，则创建预警触发器；其中，所述预警触发器包括第一预警计时参数；基于所述预警触发器的第一预警计时参数进行计时，计时完成后发送预警信息。通过执行本技术方案，可以对业务对象的风险进行预测和管理，准时地进行预警和管理。

Description

一种基于对象的预警方法、装置、存储介质及电子设备

技术领域

本申请实施例涉及智慧出行技术领域，尤其涉及一种基于对象的预警方法、装置、存储介质及电子设备。

背景技术

随着社会的发展，出现了越来越多需要监控大量对象来实现风险预警的情况，但由于监控对象数量较大，度量指标又非常多，数据量大，计算能力要求高，因此现有技术很难通过实时监测的方法来实现预警效果。

目前现有技术一般都是通过使用一些实时计算框架如flink、spark来定时循环计算出度量指标值，再对计算结果的分析，来实现这种预警场景。

但是，现有技术中往往会出现告警已经发生了，计算只是暴露这个问题的情况，并且这种计算结果的时效性会有一个延时，尤其是对于海量数据的监控，这个时效性因为计算资源的有限与规模的增长而变大，这个延时对于需要通过度量指标的预警来进行业务控制的场景影响会比较大，用户体验也较差。在安全敏感的领域，这种延时往往是无法接受的。因此，如何能够提前预测预警的机制，让业务主动提前感知存在的风险并准时管控，成为领域内亟待解决的技术问题。

发明内容

本申请实施例提供一种基于对象的预警方法、装置、存储介质及电子设备，可以达到管理风险，准时对风险进行预警和管理的目的。

第一方面，本申请实施例提供了一种基于对象的预警方法，该方法包括：

获取检测对象的周期性检测的状态数据；

若所述状态数据满足预设条件，则将当前检测周期累加到连续执行时间；

若所述连续执行时间超过第一预设时长，则创建预警触发器；其中，所述预警触发器包括第一预警计时参数；

第二方面，本申请实施例提供了一种基于对象的预警装置，该装置包括：

状态获取模块，用于获取检测对象的周期性检测的状态数据；

时间累加模块，若所述状态数据满足预设条件，则用于将当前检测周期累加到连续执行时间；

触发器创建模块，若所述连续执行时间超过第一预设时长，则用于创建预警触发器；其中，所述预警触发器包括第一预警计时参数；

信息发送模块，用于基于所述预警触发器的第一预警计时参数进行计时，计时完成后发送预警信息。

第三方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请实施例所述的基于对象的预警方法。

第四方面，本申请实施例提供了一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器运行的计算机程序，所述处理器执行所述计算机程序时实现如本申请实施例所述的基于对象的预警方法。

本申请实施例所提供的技术方案，首先通过获取检测对象的周期性检测的状态数据，如果所述状态数据满足预设条件，则将当前检测周期累加到连续执行时间，当所述连续执行时间超过第一预设时长时，创建预警触发器，其中，所述预警触发器包括第一预警计时参数，最后基于所述预警触发器的第一预警计时参数进行计时，计时完成后发送预警信息，实现对所述检测对象的风险预警。

采用本申请技术方案，能够设计一个通用的组件，或服务，对业务场景进行了抽象和设计，剥离了业务的特殊性，不随业务场景变化而改变，具有较高的通用性，通过对业务对象状态风险的提前预测，协助对象提前识别风险，提前管理风险，准点管控风险，从而做到主动风险识别和防控。

上述发明内容仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1是本申请实施例一提供的一种基于对象的预警方法的流程图；

图2是本申请实施例二提供的另一种基于对象的预警方法的流程图；

图3是本申请实施例三提供的又一种基于对象的预警方法的流程图；

图4是本申请实施例四提供的基于对象的预警装置的结构示意图；

图5是本申请实施例六提供的一种电子设备的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。

在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各步骤描述成顺序的处理，但是其中的许多步骤可以被并行地、并发地或者同时实施。此外，各步骤的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

实施例一

图1是本申请实施例一提供的一种基于对象的预警方法的流程图，本实施例可适用于主动预测预警风险的情况，该方法可以由本申请实施例所提供的基于对象的预警装置执行，该装置可以由软件和/或硬件的方式来实现，并可集成于用于风险预警的智能终端等电子设备中。

如图1所示，所述基于对象的预警方法包括：

S110、获取检测对象的周期性检测的状态数据。

其中，具有相应计算能力的终端设备或者服务器从检测对象的客户端中获取检测对象的周期性检测的状态数据。业务场景可以是网约车司机服务时长预警场景、长途客车司机疲劳驾驶预警场景和工厂车间工人工作时长预警场景等。其中，检测对象可以是司机，工人等。

客户端可以是检测对象携带的移动终端中的软件应用，也可以是设置在业务场景的连接互联网或者具备通信功能的硬件设备。周期性检测是服务器或终端设备按照预设的时间间隔从客户端获取检测对象的状态数据。状态数据可以是服务器从客户端获取的服务状态、车辆行驶状态或者工厂车间操作设备的工作状态的数据。其中车辆行驶状态通过GPS定位组件对车辆的位置进行定位来确定，操作设备的工作状态可以由操作设备是否通电来判断。其中，服务状态可以是订单状态、计费状态、无订单状态和停车休息状态。订单状态是在接到订单到订单结束的状态，计费状态是在接到客人到客人下车之间的状态。例如，网约车平台的服务器按照预设的时间间隔，一般最初的预设时间为5分钟，从网约车司机携带的移动终端上的客户端获取到当前网约车司机的订单状态和车辆行驶状态。

S120、若所述状态数据满足预设条件，则将当前检测周期累加到连续执行时间。

其中，若检测对象的状态数据满足预设条件，终端设备或服务器将当前的检测周期累加到连续执行时间，其中，所述满足预设条件可以是检测到当前司机为服务状态时。检测周期是服务器预设的两次检测中间的一段时间间隔。累加是指将检测周期与连续执行时间相加。连续执行时间是指在间隔不超过预设时间下被检测对象连续服务或连续保持工作状态的时间长度。例如，网约车平台服务器检测到司机的状态数据当前为订单状态，那么服务器将会把当前对司机进行检测的周期5分钟累加到司机的连续服务时长1小时20分当中，得到连续执行时间为1小时25分。

在本实施例中，可选的，所述状态数据满足预设条件，则将当前检测周期累加到连续执行时间，包括：若所述状态数据为第一状态，则将当前检测周期累加到连续执行时间，得到更新连续执行时间。其中，第一状态为网约车司机的订单状态，更新连续时间是通过将当前检测周期累加到连续执行时间之后得到的连续执行时间。例如，若服务器或终端设备通过客户端获取检测数据得到司机状态处于订单状态，那么就把当前检测周期的时间加进当前被检测司机的连续服务时长，来对上一次记录的连续服务时长进行更新。这样设置，可以对网约车的司机的累计工作时长进行精准的确定，以便为后续的预警提供数据基础，以使预警的发出对网约车司机有很好的提醒作用。

在本实施例中，可选的，若所述状态数据为第二状态，则将连续执行时间减掉当前检测周期，得到更新连续执行时间。其中，所述第二状态为无订单状态(休息状态)。例如，若服务器或终端设备通过客户端检测数据得到司机状态处于无订单状态或停车休息状态，那么就用上一次记录的连续服务时长减去当前的检测周期时间，来对连续服务时长进行更新。这样设置的好处是能够使得所得到的连续执行时间能够真实的反映出网约车司机的疲劳程度，在达到预警作用的同时，避免了预警次数过多，导致网约车司机的重视程度不够的问题。

S130、若所述连续执行时间超过第一预设时长，则创建预警触发器；其中，所述预警触发器包括第一预警计时参数。

其中，若检测对象的连续执行时间超过第一预设时长，第一预设时长是在服务器中预先设置的一个时间长度，可以表示网约车司机可能达到疲劳驾驶的服务时长，则创建预警触发器。预警触发器可以是服务器中的一段软件程序或者是一个硬件计时器设备，可以根据触发器的类别，在指定条件下触发。

可选的，所述预警触发器包括第一预警计时参数。第一预警计时参数是预设在触发器中的一个时间参数，倒计时触发器会在触发器创建之后按照预设时间参数进行倒计时，到点后准时触发。例如，在网约车行业中，一般若网约车司机连续服务时长超过4小时的要求，将强制下线休息20分钟，因此，第一预设时长可以为3.5个小时，第一预警计时参数可以为0.5个小时。

在本实施例中，可选的，在创建预警触发器之后，所述方法还包括：若所述连续执行时间由超过第一预设时长更新为小于第一预设时长，则销毁所述预警触发器。

其中，当服务器检测到当前司机的连续执行时间减小到第一预设时长以下时，销毁预警触发器。销毁预警触发器可以是关闭硬件设备的使用或者是让一段程序代码停止运行。例如，由于司机的连续服务时长在中断服务状态休息一段时间之后是会相应降低一段时间来更新的，因此当司机的连续执行时间更新为小于3.5个小时时，销毁所述预警触发器。这样设置的好处是可以在触发器在创建之后，仍然可以应对司机处于空闲状态的情况下进行处理，无需暂停触发器。

S140、基于所述预警触发器的第一预警计时参数进行计时，计时完成后发送预警信息。

在本实施例中，具体的，确定创建预警触发器的标定时间戳为连续执行时间超过第一预设时长检测时间戳；

按照所述预警触发器从所述标定时间戳开始进行倒计时；

若所述第一预警计时参数倒计时完成，则进行预警信息的发送。

其中，在服务器创建触发器之后，预警触发器在没有被销毁的情况下将会按照预设的第一预警计时参数进行计时，倒计时开始的时间戳是创建预警触发器的标定时间戳，是在第一次检测发现连续执行时间超过第一预设时长的时间戳，当预警触发器倒计时完成时，服务器将发送预警信息给检测对象，可选的，司机可以通过回调的方式收到预警信息。例如，当对司机进行检测的时间戳为17:30分，此时首次发现司机连续服务时长已经超过预设的3.5个小时，那么服务器就会创建触发器，从17:30分开始倒计时30分钟进行计时，18:00分发送预警信息，司机接收预警信息的方式可以是http回调和RPC回调。

本实施例的技术方案，通过获取检测对象的周期性检测的状态数据；若所述状态数据满足预设条件，则将当前检测周期累加到连续执行时间；若所述连续执行时间超过第一预设时长，则创建预警触发器；其中，所述预警触发器包括第一预警计时参数；基于所述预警触发器的第一预警计时参数进行计时，计时完成后发送预警信息来实现了一种基于对象状态的预警方法，通过该方法，准时准点进行风险预警和管理，并且具有较高的通用性，和极高的可复用性，不随业务变化而改变，稳定可靠，开发成本低。

实施例二

图2是本申请实施例二提供的另一种基于对象的预警方法的流程图。本实施例是在上述实施例的基础上进行的优化。具体优化为：所述预警触发器还包括检测周期参数；在创建预警触发器之后，所述方法还包括：根据所述预警触发器的检测周期参数，确定周期性检测的执行时间间隔；根据所述执行时间间隔，进行状态数据的检测。

如图2所示，所述另一种基于对象的预警方法包括：

S210、获取检测对象的周期性检测的状态数据。

S220、所述状态数据满足预设条件，则将当前检测周期累加到连续执行时间。

S230、若所述连续执行时间超过第一预设时长，则创建预警触发器；其中，所述预警触发器包括第一预警计时参数。

S240、所述预警触发器还包括检测周期参数；在创建预警触发器之后，所述方法还包括：根据所述预警触发器的检测周期参数，确定周期性检测的执行时间间隔；根据所述执行时间间隔，进行状态数据的检测。

其中，服务器所创建的触发器还包括检测周期参数，检测周期参数为执行检测次数，根据检测周期参数确定周期性检测的执行时间间隔，执行时间间隔为本次检测与下一次检测间隔的时间，根据执行时间间隔，对检测对象进行状态数据的检测。例如，由于在一般情况下对司机服务状态数据监测的周期往往是5分钟，如果第一次监测时间恰好是司机服务时长3小时35分钟时，那么设置的预警触发器将会在0.5小时后的服务时长4小时05分时预警，此时的告警就已经延时了，只是在问题发生后收集问题，暴露问题，不能实现预警的效果，因此在首次创建触发器之后，再次进行服务状态检测的时候，如果所述更新连续时间也就是连续服务时长继续增加，那么将会通过重新创建触发器来更新触发器的检测周期参数和第一预警计时参数，来缩短状态检测的执行时间间隔和预警计时时间，进一步精确地监测接近告警时长司机的服务状态和连续服务时长。在上述示例中，可选的，状态检测周期可随预警触发器更新为5分钟、3分钟、2分钟、1分钟、30秒、15秒、10秒、5秒。

S250、基于所述预警触发器的第一预警计时参数进行计时，计时完成后发送预警信息。

在本实施例中，可选的，所述第一预警计时参数的预警倒计时时间可更新为30分钟、10分钟、5分钟、1分钟、30秒、15秒、10秒、5秒，在这种情况下，网约车司机的连续服务时长超过4个小时的时候，预警信息将会在连续服务时长到达4小时之前的5秒钟之内发送。

原有的网约车司机服务状态预警方法在一般的定时循环监测情况下，往往是在司机连续服务时长超过4小时后的最近一个检测才能算出超标发出警报，时间上会有一个延时，而采用本实施例的技术方案可以通过检测对象状态是否越来越接近于待预警的状态，若接近则通过不断加快检测频率和缩短预警倒计时时间来降低发送预警信息的时间误差，保证业务系统能够在合适的时间点提前或准点发出预警，并进行合适的安全管控。

在上述技术方案的基础上，可选的，也可以对高度安全敏感的场景，在司机连续服务时长达到设定值以后提升触发器的预警频率，其中，高度安全敏感的场景可以是大风、大雨、大雾、深夜等场景，也可以在司机的安全风险指标减低到某个值以后，减低触发器的预测预警级别。对应的就是在司机连续服务时长超过第一预设时长但预警信息尚未发送的情况下，连续服务时长的变化导致预警触发器的各项参数不断发生变化。

本实施例在上述实施例的基础上，提供了一种基于触发器的检测周期的参数进行检测的方法。这样设置的有益效果在于，随着触发器逐渐接近最终的预警时间，会变更检测周期，从而实现准确的计时，使得预警的发出时间更加精准的目的。

实施例三

图3是本申请实施例三提供的又一种基于对象的预警方法的流程图。本实施例是在上述各实施例的基础上进行的优化。具体优化为：若所述状态数据为第三状态，则将当前检测周期累加到累计执行时间，得到更新累计执行时间；若所述累计执行时间达到第二预设时长，则创建预警触发器；其中，所述预警触发器包括第二预警计时参数；基于所述预警触发器的第二预警计时参数，进行预警信息的发送。

如图3所示，所述又一种基于对象的预警方法包括：

S310、获取检测对象的周期性检测的状态数据。

S320、所述状态数据满足预设条件，则将当前检测周期累加到累计执行时间。

其中，当检测对象的状态数据满足预设条件时，服务器会将当前的检测周期时间间隔累加到累计执行时间，所述累计执行时间可以是司机在一天时间内，计费状态下的总时长，所述计费状态指的是从接到客人到客人下车之间的状态。

S330、若所述状态数据为第三状态，则将当前检测周期累加到累计执行时间，得到更新累计执行时间。

其中，若服务器检测到对的状态数据为第三状态，所述第三状态可以是计费状态，则将当前检测周期累加到累计执行时间，得到更新累计执行时间，所述更新累计执行时间可以为对累计执行时间进行更新。对累计执行时间的更新方法与实施例二中对连续执行时间更新的方法相同。

S340、若所述累计执行时间达到第二预设时长，则创建预警触发器；其中，所述预警触发器包括第二预警计时参数。

其中，服务器检测到对象的累计执行时间达到第二预设时长，第二预设时长是在服务器中预先设置的另一个时间长度，可以表示网约车司机24小时之内可以处于计费状态的最长时间，则创建预警触发器；其中，所述预警触发器包括第二预警计时参数，第二预警计时参数是另一个设置在触发器中的时间参数，触发器创建之后将会按照这个时间进行倒计时操作。例如，在网约车行业，24小时之内司机被限制最多可以有10个小时处于计费状态，如果超过，将会被踢下线，因此

设置第二预设时长为9小时，第二预警计时参数为1小时，与实施例二的情况相同，可选的，第二预警倒计时时间可随预警触发器更新为1小时，30分钟，10分钟、5分钟、1分钟、30秒、10秒、5秒。

S350、基于所述预警触发器的第二预警计时参数，进行预警信息的发送。

采用本实施例的技术方案能够通过检测对象状态是否越来越接近于待预警的状态，若接近则通过不断加快检测频率和缩短预警倒计时时间，这样设置的有益效果在于，可以降低发送预警信息的时间误差实现精确到秒的预警信息发送，实现提前管理风险、准时管控风险。

在上述各个实施例的基础上，可选的，可以根据不同业务场景的需要在服务器中定义预警类型；然后服务器将对象的最新状态投递到预警算法中，由预警算法实例进行分析，生成预警触发器、更新预测预警触发器或者销毁触发器；触发器创建后，由触发器负责准点发出预测预警消息给业务系统，从而让业务系统能够在合适的时间点提前或准点检测对象状态识别风险，并进行合适的安全管控。

实施例四

图4是本申请实施例四提供的基于对象的预警装置的结构示意图。该装置用于实现上述实施例上述的方法，该装置位于电子设备中，包括：

状态获取模块410，用于获取检测对象的周期性检测的状态数据；

时间累加模块420，若所述状态数据满足预设条件，则用于将当前检测周期累加到连续执行时间；

触发器创建模块430，若所述连续执行时间超过第一预设时长，则用于创建预警触发器；其中，所述预警触发器包括第一预警计时参数；

信息发送模块440，用于基于所述预警触发器的第一预警计时参数进行计时，计时完成后发送预警信息。

进一步的，时间累加模块420用于：

若所述状态数据为第一状态，则将当前检测周期累加到连续执行时间，得到更新连续执行时间。

若所述状态数据为第二状态，则将连续执行时间减掉当前检测周期，得到更新连续执行时间。

进一步的，信息发送模块440用于：

基于所述预警触发器的第一预警计时参数进行计时，计时完成后发送预警信息，包括：

确定创建预警触发器的标定时间戳为连续执行时间超过第一预设时长检测时间戳；

按照所述预警触发器从所述标定时间戳开始进行倒计时；

若所述第一预警计时参数倒计时完成，则用于进行预警信息的发送。

进一步的，触发器创建模块430用于：

若所述连续执行时间由超过第一预设时长更新为小于第一预设时长，则销毁所述预警触发器。

触发器创建模块430还用于：

所述预警触发器还包括检测周期参数；

在创建预警触发器之后，所述方法还包括：

根据所述预警触发器的检测周期参数，确定周期性检测的执行时间间隔；

根据所述执行时间间隔，进行状态数据的检测。

信息发送模块440还用于：

若所述状态数据满足预设条件，则将当前检测周期累加到累计执行时间；

若所述累计执行时间达到第二预设时长，则创建预警触发器；其中，所述预警触发器包括第二预警计时参数；

基于所述预警触发器的第二预警计时参数，用于进行预警信息的发送。

时间累加模块420还用于：

若所述状态数据满足预设条件，则将当前检测周期累加到累计执行时间，包括：

若所述状态数据为第三状态，则将当前检测周期累加到累计执行时间，得到更新累计执行时间。

上述装置可执行本申请前述所有实施例所提供的方法，具备执行上述方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请前述所有实施例所提供的方法。

实施例五

本申请实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种基于对象的预警方法，该方法包括：

获取检测对象的周期性检测的状态数据；

基于所述预警触发器的第一预警计时参数进行计时，计时完成后发送预警信息。

存储介质——任何的各种类型的存储器电子设备或存储电子设备。术语“存储介质”旨在包括：安装介质，例如CD-ROM、软盘或磁带装置；计算机系统存储器或随机存取存储器，诸如DRAM、DDR RAM、SRAM、EDO RAM，兰巴斯(Rambus)RAM等；非易失性存储器，诸如闪存、磁介质(例如硬盘或光存储)；寄存器或其它相似类型的存储器元件等。存储介质可以还包括其它类型的存储器或其组合。另外，存储介质可以位于程序在其中被执行的计算机系统中，或者可以位于不同的第二计算机系统中，第二计算机系统通过网络(诸如因特网)连接到计算机系统。第二计算机系统可以提供程序指令给计算机用于执行。术语“存储介质”可以包括可以驻留在不同位置中(例如在通过网络连接的不同计算机系统中)的两个或更多存储介质。存储介质可以存储可由一个或多个处理器执行的程序指令(例如具体实现为计算机程序)。

当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的基于对象的预警操作，还可以执行本申请任意实施例所提供的基于对象的预警方法中的相关操作。

实施例六

图5是本申请实施例六提供的一种电子设备的结构示意图。本申请实施例提供了一种电子设备，该电子设备中可集成本申请实施例提供的基于对象的预警装置。图5是本申请实施例六供的一种电子设备的结构示意图。如图5所示，本实施例提供了一种电子设备500，其包括：一个或多个处理器520；存储装置510，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器520执行，使得所述一个或多个处理器520实现本申请实施例所提供的基于对象的预警方法，该方法包括：

获取检测对象的周期性检测的状态数据；

当然，本领域技术人员可以理解，处理器520还实现本申请任意实施例所提供的基于对象的预警方法的技术方案。

图5显示的电子设备500仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图5所示，该电子设备500包括处理器520、存储装置510、输入装置530和输出装置540；电子设备中处理器520的数量可以是一个或多个，图5中以一个处理器520为例；电子设备中的处理器520、存储装置510、输入装置530和输出装置540可以通过总线或其他方式连接，图5中以通过总线550连接为例。

存储装置510作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块单元，如本申请实施例中的基于对象的预警方法对应的程序指令。

存储装置510可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储装置510可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储装置510可进一步包括相对于处理器520远程设置的存储器，这些远程存储器可以通过网络连接。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置530可用于接收输入的数字、字符信息或语音信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入。输出装置540可包括显示屏、扬声器等电子设备。

本申请实施例提供的电子设备，可以达到提高基于对象的预警速度以及处理效果的目的。

上述实施例中提供的基于对象的预警装置、存储介质及电子设备可执行本申请任意实施例所提供的基于对象的预警方法，具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的基于对象的预警方法。

注意，上述仅为本申请的较佳实施例及所运用技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由所附的权利要求范围决定。

Claims

1.一种基于对象的预警方法，其特征在于，包括：

获取检测对象的周期性检测的状态数据；

2.根据权利要求1所述的方法，其特征在于，若所述状态数据满足预设条件，则将当前检测周期累加到连续执行时间，包括：

3.根据权利要求2所述的方法，其特征在于，在获取检测对象的周期性检测的状态数据之后，所述方法还包括：

4.根据权利要求1所述的方法，其特征在于，基于所述预警触发器的第一预警计时参数进行计时，计时完成后发送预警信息，包括：

按照所述预警触发器从所述标定时间戳开始进行倒计时；

5.根据权利要求1所述的方法，其特征在于，在创建预警触发器之后，所述方法还包括：

6.根据权利要求1所述的方法，其特征在于，所述预警触发器还包括检测周期参数；

在创建预警触发器之后，所述方法还包括：

根据所述执行时间间隔，进行状态数据的检测。

7.根据权利要求1所述的方法，其特征在于，在获取检测对象的周期性检测的状态数据之后，所述方法还包括：

基于所述预警触发器的第二预警计时参数，进行预警信息的发送。

8.根据权利要求7所述的方法，其特征在于，若所述状态数据满足预设条件，则将当前检测周期累加到累计执行时间，包括：

9.一种基于对象的预警装置，其特征在于，包括：

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-8中任一项所述的基于对象的预警方法。

11.一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1-8中任一项所述的基于对象的预警方法。