CN117527652A - 心跳周期调整方法、设备及系统 - Google Patents

心跳周期调整方法、设备及系统 Download PDF

Info

Publication number
CN117527652A
CN117527652A CN202210900476.5A CN202210900476A CN117527652A CN 117527652 A CN117527652 A CN 117527652A CN 202210900476 A CN202210900476 A CN 202210900476A CN 117527652 A CN117527652 A CN 117527652A
Authority
CN
China
Prior art keywords
period
iot
event
heartbeat
iot device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210900476.5A
Other languages
English (en)
Inventor
兰继生
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202210900476.5A priority Critical patent/CN117527652A/zh
Publication of CN117527652A publication Critical patent/CN117527652A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/12—Arrangements for remote connection or disconnection of substations or of equipment thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请实施例提供一种心跳周期调整方法、设备及系统，涉及物联网技术领域。在本申请方案中，IoT平台根据IoT设备的注册时间、IoT设备的离线时间、及用户设备控制IoT设备的时间等因素，动态调整IoT设备的心跳周期。当预估用户使用IoT设备的几率较低时，延长心跳周期，从而减少了IoT设备的功耗和IoT平台的性能压力。当预估用户使用IoT设备的几率较高时，缩短心跳周期，从而最大限度保持IoT设备在线状态与数据库记录一致，提升了用户的使用体验。

Description

心跳周期调整方法、设备及系统
技术领域
本申请涉及物联网(internet of things，IoT)技术领域，尤其涉及一种心跳周期调整方法、设备及系统。
背景技术
IoT平台在物联网产业链中起到承上启下的作用，主要提供连接硬件服务、处理不同通讯协议服务、为设备和用户提供安全和身份验证服务、收集数据并进行可视化分析服务，以及与其他万维网(world wide web，Web)服务进行集成。
在智能家居等领域中，用户设备、IoT平台和IoT设备通过比如消息队列遥测传输(message queuing telemetry transport，MQTT)之类的长连接协议实现远程控制。例如，IoT设备通过心跳(ping/pong)机制维持传输控制协议(transmission control protocol，TCP)长连接，IoT平台通过心跳感知TCP长连接是否断开并存储IoT设备的状态，从而用户设备可以从IoT平台查询IoT设备的状态。
然而，大多数IoT设备的心跳周期是固定的。若IoT设备的心跳周期过长，则用户在使用用户设备时无法快速真实感知IoT设备的状态；若IoT设备的心跳周期过短，则增加了IoT设备的功耗和IoT平台的性能压力。如何优化IoT设备的心跳周期成为亟待解决的问题。
发明内容
本申请提供一种心跳周期调整方法、设备及系统，可以结合多种因素动态调整IoT设备的心跳周期，降低了IoT设备的功耗，减轻了IoT平台的性能压力，提升了用户的使用体验。
为达到上述目的，本申请采用如下技术方案：
第一方面，本申请实施例提供一种心跳周期调整方法。该方法应用于IoT平台，包括：
当IoT平台的系统时间达到心跳周期调整任务的第i个执行周期的起始时间时，根据IoT设备注册至IoT平台的时间，确定与第i个执行周期对应的基础心跳周期，i为正整数；
根据在第i-1个执行周期中目标时段的活跃数据，对与第i个执行周期对应的基础心跳周期进行调整，得到在第i个执行周期中目标时段的心跳周期，目标时段为第i-1个执行周期和第i个执行周期分别包括的M个时段中的任意一个时段，活跃数据用于表示在第i-1个执行周期的目标时段内IoT设备的活跃程度，M为正整数；
向IoT设备发送指令，该指令包括在第i个执行周期中每个时段的心跳周期，在第i个执行周期中每个时段的心跳周期用于指示IoT设备在每个时段内向IoT平台发送心跳包的时间间隔。
需要说明的是，心跳周期调整任务为：以IoT设备注册至IoT平台的时间为起始时间，在多个执行周期的每个执行周期计算一次IoT设备的心跳周期。第i个执行周期为心跳周期调整任务的任意一个执行周期。
在本方案中，每个执行周期对应一个预设的基础心跳周期。由于不同用户之间存在个体差异，并且同一用户在一个执行周期的不同时段也可能存在差异，若所有用户在不同时段均采用相同的基础心跳周期发送心跳包，则可能存在有些用户无法通过用户设备快速真实感知IoT设备的状态，或有些IoT设备的功耗较高的问题。因此在确定与一个执行周期对应的基础心跳周期之后，可以根据上一个执行周期中各个时段的活跃数据，对基础心跳周期进行动态调整，从而更为准确地计算得到与本执行周期的各个时段对应的最终心跳周期。例如，当预估用户使用IoT设备的几率较低时，延长心跳周期，从而减少了IoT设备的功耗和IoT平台的性能压力；当预估用户使用IoT设备的几率较高时，缩短心跳周期，从而最大限度保持IoT设备在线状态与数据库记录一致，提升了用户的使用体验。
在一种可能的实现方式中，与第i-1个执行周期对应的基础心跳周期，小于或等于与第i个执行周期对应的基础心跳周期。
应理解，当用户新购置IoT设备后，用户对IoT设备的新鲜感较为强烈，使用用户设备对IoT设备进行远程控制的次数较多，在这种情况下，可以将与一个执行周期对应的基础心跳周期设置较短，以便增加计算心跳周期的次数，从而使得用户能够通过用户设备及时快速感知IoT设备的真实状态。在一段时间后，随着用户对IoT设备的新鲜感减弱，使用用户设备对IoT设备进行远程控制的次数逐渐减小，在这种情况下，可以将与一个执行周期对应的基础心跳周期设置较长，以便减少计算心跳周期的次数，从而降低IoT设备的功耗和IoT平台的性能压力。
在一种可能的实现方式中，第i-1个执行周期和第i个执行周期分别包括N个子周期。N个子周期中的每个子周期包括M个子时段。目标时段为M个时段中的第j个时段。第j个时段包括每个子周期的第j个子时段。其中，N为正整数，j为小于或等于M的正整数。
示例性地，一个执行周期为一个月，一个子周期为一天，一个子时段为0.5小时，1个小时或2个小时。目标时段可以包括第1天的12:00-13:59、第2天的12:00-13:59……第30天的12:00-13:59。
在一种可能的实现方式中，活跃数据为用户活跃指数。在根据在第i-1个执行周期中目标时段的活跃数据，对与第i个执行周期对应的基础心跳周期进行调整之前，该方法还包括：
获取在第i-1个执行周期的目标时段内发生目标事件的次数，目标事件为与IoT设备关联的事件；根据发生目标事件的次数，得到在第i-1个执行周期中目标时段的用户活跃指数，用户活跃指数与发生目标事件的次数成正比例关系。
在一种可能的实现方式中，目标事件包括以下至少一类：
第一事件，第一事件为用户设备通过IoT平台控制IoT设备的事件；
第二事件，第二事件为用户设备的IoT应用程序切换至前台运行状态的事件，IoT应用程序用于控制IoT设备；
第三事件，第三事件为IoT设备向IoT平台上报采集数据的事件；以及，
第四事件，第四事件为IoT设备的离线事件。
在一种可能的实现方式中，目标事件包括第一事件、第二事件、第三事件和第四事件，每类事件分别对应一个用户活跃指数。相应地，根据发生目标事件的次数，得到在第i-1个执行周期中目标时段的用户活跃指数，包括：
根据在第i-1个执行周期的目标时段内发生第一事件的次数，得到第一用户活跃指数；根据在第i-1个执行周期的目标时段内发生第二事件的次数，得到第二用户活跃指数；根据在第i-1个执行周期的目标时段内发生第三事件的次数，得到第三用户活跃指数；根据在第i-1个执行周期的目标时段内发生第四事件的次数，得到第四用户活跃指数。
应理解，在上一个执行周期的IoT设备的活跃程度，与本执行周期的IoT设备的活跃程度强相关。根据上一个执行周期的IoT设备的活跃程度，可以预设出用户在本执行周期使用IoT设备的几率，进而设置与之对应的心跳周期。
在一种可能的实现方式中，根据在第i-1个执行周期中目标时段的活跃数据，对与第i个执行周期对应的基础心跳周期进行调整，得到在第i个执行周期中目标时段的心跳周期，包括：
根据第一用户活跃指数、第二用户活跃指数、第三用户活跃指数和第四用户活跃指数，采用下述等式计算在第i个执行周期中目标时段的心跳周期T2：
其中，T1表示与第i个执行周期对应的基础心跳周期，i1表示第一用户活跃指数，i2表示第二用户活跃指数，i3表示第三用户活跃指数，i4表示第四用户活跃指数，F1表示与第一事件对应的权重系数，F2表示与第二事件对应的权重系数，F3表示与第三事件对应的权重系数，F4表示与第四事件对应的权重系数。
在一种可能的实现方式中，该方法还包括：
在第i-1个执行周期，接收来自用户设备的第一数据和第二数据，第一数据指示第一事件，第二数据指示第二事件；在第i-1个执行周期，接收来自IoT设备的第三数据和第四数据，第三数据指示第三事件，第四数据指示第四事件。
在一种可能的实现方式中，第i-1个执行周期包括N个子周期，N个子周期中的每个子周期包括M个子时段；目标时段为M个时段中的第j个时段，第j个时段包括每个子周期的第j个子时段。N为正整数，j为小于或等于M的正整数。
相应地，获取在第i-1个执行周期的目标时段内发生目标事件的次数，包括：
对于目标事件的每类事件，若在第i-1个执行周期的任意一个子周期的第j个子时段发生每类事件的次数大于或等于1次，则标记1次；对第i-1个执行周期的N个子周期的第j个子时段标记的次数累加求和，得到在第i-1个执行周期的目标时段内发生每类事件的次数。
在一种可能的实现方式中，在确定IoT平台的系统时间达到心跳周期调整任务的第i个执行周期的起始时间之前，该方法还包括：
接收来自IoT设备的注册请求消息；响应于注册请求消息，验证IoT设备为合法设备；创建心跳周期调整任务，并向IoT设备发送成功注册消息。
在一种可能的实现方式中，每个执行周期的周期长度根据以下至少一项确定：IoT设备的设备类型，以及注册至IoT平台的设备的数量。
应理解，针对用户远程操作较为频繁的IoT设备，可以将心跳周期调整任务的执行周期设置较短，以便增加计算心跳周期的次数，从而及时对心跳周期进行调整。此外，当注册至IoT平台的IoT设备的数量越少时，IoT平台的性能压力越小，可以将心跳周期调整任务的执行周期设置较短，以便增加计算心跳周期的次数，从而能够更为准确预估IoT设备的心跳周期。随着注册至IoT平台的IoT设备的数量增加，IoT平台的性能压力越大，此时可以将心跳周期调整任务的执行周期设置较长，以便减少计算心跳周期的次数，从而减轻IoT平台的性能压力。
在一种可能的实现方式中，在向IoT设备发送指令之后，该方法还包括：
若在预设时间内接收到来自IoT设备的心跳包，则确定IoT设备为在线状态，并向IoT设备发送心跳响应。或者，若在预设时间内未接收到来自IoT设备的心跳包，则确定IoT设备为离线状态，并释放IoT平台与IoT设备的连接。其中，心跳包和心跳响应用于维持IoT设备与IoT平台的长连接。
第二方面，本申请实施例提供一种心跳周期调整方法。该方法应用于IoT设备，包括：
接收来自IoT平台的指令，该指令包括在心跳周期调整任务的第i个执行周期中每个时段的心跳周期。在第i个执行周期中的每个时段，按照每个时段的心跳周期，向IoT平台发送心跳包。其中，i为正整数。
应理解，当IoT平台准确预测出本执行周期各个时段的心跳周期后，IoT设备可以在每个时段动态调整心跳周期，并按照调整后的心跳周期发送心跳包，以维持长连接。
在一种可能的实现方式中，若在预设时间内接收到来自IoT平台的心跳响应，则确定IoT设备与IoT平台的长连接有效。
在一种可能的实现方式中，若在预设时间内未接收到来自IoT平台的心跳响应，则确定IoT设备与IoT平台的长连接无效。
在一种可能的实现方式中，在接收来自IoT平台的指令之前，该方法还包括：
在第i-1个执行周期，向IoT平台发送第三数据和第四数据。其中，第三数据指示第三事件，第四数据指示第四事件。第三事件为IoT设备向IoT平台上报采集数据的事件，第四事件为IoT设备的离线事件。第三事件和第四事件用于计算在第i个执行周期中每个时段的心跳周期。
第三方面，本申请实施例提供一种IoT平台，包括通信接口、处理器和存储器。通信接口用于连接IoT设备和用户设备。处理器与存储器耦合。处理器用于执行存储器中存储的计算机程序或指令，以使得IoT平台实现如第一方面中任一项的心跳周期调整方法。
第四方面，本申请实施例提供一种IoT设备，包括通信接口、处理器和存储器。通信接口用于连接IoT平台。处理器与存储器耦合。处理器用于执行存储器中存储的计算机程序或指令，以使得IoT设备实现如第二方面中任一项的心跳周期调整方法。
第五方面，本申请提供一种心跳周期调整装置，该装置包括用于执行上述第一方面或第二方面的方法的单元/模块。该装置可对应于执行上述第一方面或第二方面描述的方法，该装置中的单元/模块的相关描述请参照上述第一方面或第二方面的描述，为了简洁，在此不再赘述。
第六方面，提供一种芯片，该芯片与存储器耦合，该芯片用于读取并执行该存储器中存储的计算机程序，以实现如第一方面或第二方面中任一项的心跳周期调整方法。
第七方面，提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，当该计算机程序在IoT平台上运行时，使得电子设备执行如第一方面中任一项的心跳周期调整方法；或者，当该计算机程序在IoT设备上运行时，使得IoT设备执行如第二方面中任一项的心跳周期调整方法。
第八方面，提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如第一方面或第二方面中任一项的心跳周期调整方法。
可以理解的是，上述第三方面至第八方面的有益效果可以参见上述第一方面和第二方面中的相关描述，在此不再赘述。
附图说明
图1为本申请实施例提供的客户端与服务端的心跳同步过程的示意图；
图2为本申请实施例提供的IoT系统的架构示意图；
图3为本申请实施例提供的IoT平台的软件结构示意图；
图4为本申请实施例提供的心跳周期调整方法的流程示意图；
图5为本申请实施例提供的在不同执行周期的同一时段的心跳周期的示意图；
图6为本申请实施例提供的IoT设备维持长连接的流程示意图；
图7为本申请实施例提供的在3个时段中IoT设备与IoT平台的心跳同步过程的示意图；
图8为本申请实施例提供的用户设备的操作界面的示意图；
图9为本申请实施例提供的装置的示例性框图；
图10为本申请实施例提供的IoT平台的结构示意图。
具体实施方式
为了使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。
在本申请的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B。在本申请的描述中，“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
在本申请的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，或者用于区别对同一对象的不同处理，而不是用于描述对象的特定顺序。例如，第一数据和第二数据等是用于区别不同的数据，而不是用于描述数据的特定顺序。在本申请实施例中，“多个”是指两个或两个以上。
在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
首先对本申请中涉及的一些名词或者术语进行解释说明。
(1)长连接
当网络通信采用TCP协议时，服务端(sever)和客户端(client)进行三次握手以建立TCP连接。在通信双方的数据或信令传输完成后，服务端和客户端进行四次挥手以释放TCP连接。待下一次服务端和客户端有数据或信令传输需求时，再重新建立TCP连接，之后重新释放TCP连接。这种连接方式称为短连接。例如，Web网站的超文本传输协议(hype texttransfer protocol，HTTP)服务一般采用短连接，以节省服务端资源。
TCP连接的建立阶段和释放阶段过程较为复杂。如果客户端频繁向服务端请求建立TCP，之后再频繁断开TCP连接，那么会浪费一定的时间，增加系统开销。为了节省时间，降低系统开销，服务端和客户端可以保持长连接。即，通信双方基于TCP协议建立连接后进行通信，并在通信完毕后，不主动断开连接，继续保持TCP连接。这样，在下一次需要传输数据包时，服务端和客户端可以直接通过长连接传输数据包。
(2)心跳机制
在服务端和客户端保持长连接时，若服务端和客户端在较长的时间内未传输数据或者信令，为了节省网络资源，服务端会断开与客户端之间的长连接，并将更多的网络资源分配给其他有传输需求的设备。例如，若服务端与客户端在10分钟之内未传输数据或者信令，服务端会断开长连接。通常，服务端和客户端会采用心跳机制使长连接尽量不断开，以保证服务端始终判定长连接处于活跃状态，避免长连接被拆链。
其中，心跳机制的原理是：客户端每隔一个时间段向服务端发送一个心跳包，服务端接收到心跳包后，响应于心跳包向客户端返回一个心跳应答，这样就形成客户端和服务端的一次完整的握手过程。通过此次握手过程使得客户端和服务端都确定TCP连接没有断开，客户端仍然在线。如果超过时间阈值，服务端没有收到客户端的心跳包，那么服务端断开TCP连接。或者，如果超过时间阈值，客户端没有收到服务端的心跳应答，那么客户端断开与服务器的TCP连接，重新建立TCP连接。
示例性地，图1示出了客户端与服务端的心跳同步过程的示意图。在客户端与服务端建立TCP连接后，在每个心跳周期，客户端向服务端发送一个Ping帧，Ping帧可以携带客户端自定义的数据。服务端收到Ping帧后，响应于Ping帧，向客户端返回一个Pong帧，Pong帧携带与Ping帧中相同的数据。Ping帧和Pong帧是协议里的心跳，用于检测客户端是否在线，保证长连接存活。
需要说明的是，在本申请实施例中，客户端可以为IoT设备，服务端可以为IoT平台。
目前，IoT涉及智能家居、智慧医疗、智慧交通和智能抄表等多种领域。在这些领域中IoT平台和IoT设备可以通过长连接协议实现远程控制。例如，IoT设备通过心跳机制维持TCP长连接，IoT平台通过心跳感知TCP长连接是否断开，并存储IoT设备的状态。然而，大多数IoT设备的心跳周期是固定的，比如在智能家居领域中IoT设备的心跳周期通常为60秒。若IoT设备的心跳周期过长，则用户在使用用户设备时无法快速感知IoT设备的真实状态，例如，用户设备从IoT平台获取到IoT设备为在线状态，而IoT设备的真实状态为离线状态，此时如果用户尝试通过用户设备远程控制IoT设备，那么IoT设备长时间无响应，从而降低用户的操作体验。若IoT设备的心跳周期过短，则增加了IoT设备的功耗和IoT平台的性能压力。
鉴于上述问题，本申请实施例提供一种心跳周期调整方法：IoT平台根据IoT设备的注册时间、IoT设备的离线时间、用户设备控制IoT设备的时间等因素，动态调整IoT设备的心跳周期。当预估用户使用IoT设备的几率较低时，延长心跳周期，从而减少了IoT设备的功耗和IoT平台的性能压力。当预估用户使用IoT设备的几率较高时，缩短心跳周期，从而最大限度保持IoT设备在线状态与数据库记录一致，提升了用户的使用体验。
需要说明的是，本申请实施例提供的心跳周期调整方法适用于多种IoT系统，比如智能家居系统、智慧医疗系统、智慧交通系统和智能抄表系统等。下文将以智能家居系统为例进行详细说明，其并不构成对本申请实施例提供的技术方案的限定。本领域技术人员可知，随着新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题同样适用。
图2为本申请实施例提供的IoT系统的架构示意图。如图2所示，该系统包括用户设备、IoT设备、IoT平台和数据库(data base，DB)。
用户设备与IoT平台通过网络1连接，IoT设备与IoT平台通过网络2连接。
网络1和网络2可以是局域网(local area network，LAN)，也可以是广域网(widearea network，WAN)，如互联网。网络1和网络2可以使用任何已知的网络通信协议来实现。网络通信协议可以是各种有线或无线通信协议，如以太网、通用串行总线(universalserial bus，USB)、火线(firewire)、全球移动通讯系统(global system for mobilecommunications，GSM)、通用分组无线服务(general packet radio service，GPRS)、码分多址接入(code division multiple access，CDMA)、宽带码分多址(wideband codedivision multiple access，WCDMA)，时分码分多址(time-division code divisionmultiple access，TD-SCDMA)，长期演进(long term evolution，LTE)、全球互联微波接入(worldwide interoperability for microwave access，WiMAX)、第五代(5thGeneration，5G)通信(如新空口(new radio access technology，NR))、蓝牙(bluetooth)、无线保真(wireless fidelity，Wi-Fi)、基于互联网协议的语音通话(voice overInternet Protocol，VoIP)或任何其他合适的通信协议。
用户设备是IoT系统的主控设备，用于通过IoT平台远程监控IoT设备、修改IoT设备信息、添加IoT设备、删除IoT设备等互动操作。在一些实施例中，用户设备为手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)、虚拟现实(virtualreality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)或智慧屏等，或者可以为其他能够进行远程控制的设备或装置。对于用户设备的具体类型，本申请实施例不作任何限制。
IoT设备用于采集其声、光、热、电、力学、化学、生物和位置等各种信息，以实现对环境、物体或过程的智能化感知、识别和管理。在一些实施例中，IoT设备可以是采用了布线技术、网络通信技术、安全防范技术、自动控制技术或音视频技术等与家居生活有关的智能家居设备，诸如智能音箱，路由器，投影仪，温湿度计，智能电视，智慧屏，空气净化器，灯，冰箱，洗衣机，微波炉，烟雾报警器，天然气报警器，暖风机，智能门锁，摄像头以及空调等。
IoT平台是基于互联网，采用多种通讯技术构建的物联网中间平台。IoT平台可以用于提供下述服务：连接硬件、处理不同的通讯协议、为设备和用户提供安全和身份验证、收集数据并进行可视化分析，以及与其他Web服务进行集成。通常，IoT平台包括应用使能平台(application enablement platform，AEP)、设备管理平台(device managementplatform，DMP)、连接管理平台(connectivity management platform，CMP)和IoT代理(IoTAgent)。其中，AEP主要负责业务编排、大数据分析、行业套件和应用程序接口(applicationprogramming interface，API)管理等。DMP主要负责设备鉴权、数据采集、物联网协议适配、订阅通知、固件升级和告警管理等。CMP主要负责使用户身份识别(subscriber identitymodule，SIM)卡接入运营商网络，以及与运营商计费系统对接等。IoT代理主要负责预集成设备平台的接入，以及实现近场控制和边缘计算等。在一些示例中，IoT平台可以为云平台，或云服务器，或网络侧服务器。在又一些示例中，IoT平台可以为部署在边缘侧的边缘网关或者边缘节点。
数据库是一个按照数据结构存储在计算机内的、有组织的、可共享的、统一管理的大量数据集合。数据库可以存储IoT设备的在线/离线状态、IoT设备的注册时间、以及IoT设备采集的数据等。在一些示例中，若IoT平台为云平台或云服务器，则数据库可以存储于IoT平台。在又一些示例中，数据库也可以存储在除IoT平台外的其他计算机设备中。
需要说明的是，图2仅示出了IoT系统的部分设备。应理解，在实际实现时，IoT系统还可以包括更多的设备。比如，当多个IoT设备通过蓝牙相互连接时，IoT系统还可以包括配网设备(provisioner)，该配网设备也可以称为蓝牙网关，蓝牙网关用于对多个IoT设备进行配网设置，将多个IoT设备添加到蓝牙无线网格(mesh)网络中，使多个IoT设备成为蓝牙mesh网络中的节点。再比如，IoT系统还可以包括与IoT平台连接的应用服务器、高可用负载均衡服务器、云网关服务器和中继设备等，本申请实施例不作限定。
图3为本申请实施例提供的IoT平台的软件结构示意图。IoT平台采用分层架构，将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将软件结构的软件层从上至下依次划分为：应用层、业务使能层、设备连接层、接入层以及终端层。
应用层可以包括一系列应用程序(application，APP)包，比如智慧家庭、智慧医疗、智慧交通、智能抄表和第三方应用程序等。当这些应用程序包被运行时，可以通过应用编程接口(application programming interface，API)访问业务使能层提供的各个服务模块，并且执行相应的IoT业务。
业务使能层主要提供APP&API开放管理、数据管理和开放、规则引擎等功能。APP&API开放管理提供API搜索、API帮助等推广功能，以及统一的API生命周期管理服务。数据管理和开放将设备的原生数据根据模型转换后，通过规则引擎和业务编排模块进行商业行为定义。规则引擎使用对象是终端用户，定义系统已经预置支持的规则场景。
设备连接层包括设备管理模块、定时任务模块、数据分析模块、心跳周期调整模块、状态管理模块、传输协议适配模块和轻量化鉴权模块。其中，设备管理模块用于IoT设备注册，以及IoT设备的信息管理，比如，管理IoT设备的类型、IoT设备的注册时间、IoT设备上报的采集数据或报警数据等。定时任务模块用于为每个IoT设备创建心跳周期调整任务。数据分析模块用于统计出用户在每个周期的各时段使用IoT设备的活跃数据，并以此预判出在每个周期的下一周期各时段使用IoT设备的活跃概率。心跳周期调整模块用于根据IoT设备的注册时间、IoT设备的离线时间、用户设备控制IoT设备的时间等多种因素，计算IoT设备在各个时段的心跳周期，并将计算出的心跳周期下发至IoT设备。状态管理模块用于管理IoT设备的在线/离线状态。传输协议适配模块支持的接口协议包括HTTP和MQTT等。轻量化鉴权模块用于对设备、应用程序的验证及授权。需要说明的是，设备连接层中的各个模块仅是示例性说明，在实际实现时，一个模块可以拆分为多个模块，多个模块也可以合并为一个模块，比如设备管理模块和状态管理模块可以为同一个模块。
接入层支持无线、固定接入等多种接入方式，通过IoT代理适配不同厂家的传感器。网络接入可以为移动宽带接入、固定宽带接入和IoT接入等。
终端层包括IoT代理，用于适配操作系统和各类厂商的智能终端和智能硬件。智能终端可以是智能手机、IPAD或计算机等。智能硬件可以是射频识别装置、基于光声电磁的传感器、激光扫描器等各类装置。
下面以如图3所示的IoT平台中的设备管理模块、定时任务模块、数据分析模块、心跳周期调整模块和状态管理模块为例，对本申请实施例提供的心跳周期调整方法进行示例说明。示例性地，如图4所示，该方法可以包括：阶段一、创建心跳周期调整任务，阶段二、数据统计，阶段三、计算心跳周期，阶段四、记录和查询IoT设备的状态。
阶段一、创建心跳周期调整任务
IoT设备和IoT平台通过下述S1-S6创建心跳周期调整任务。
S1.IoT设备向设备管理模块发送注册请求消息。
其中，注册请求消息用于请求将IoT设备注册至IoT平台。
示例性地，注册请求消息包括IoT设备的设备标识信息，如：设备型号、个人识别码(personal identification number，PIN)和/或媒体接入控制(media access control，MAC)地址等，这些信息用于标识IoT设备。其中，设备型号用于识别IoT设备，通常以设备型号命名IoT设备，以及根据设备型号确定IoT设备对应的设备图标。PIN为配网注册过程中密钥协商的根密钥，用于安全认证。MAC地址为IoT设备唯一的标识，用于区分其他IoT设备。应理解，IoT设备还可以包括其他信息，例如厂商信息等，本申请实施例不作限定。
S2.设备管理模块响应于注册请求消息，验证IoT设备是否为合法设备。
S3.在IoT设备为合法设备的情况下，设备管理模块向定时任务模块发送任务请求消息。
在接收到IoT设备发送的注册请求消息后，设备管理模块先验证IoT设备是否为合法设备。在验证IoT设备为合法设备后，如果要定期调整IoT设备的心跳周期，那么设备管理模块需要向定时任务模块发送任务请求消息，以请求定时任务模块创建一个与IoT设备对应的心跳周期调整任务。另外，设备管理模块存储IoT设备注册至IoT设备平台的时间，以便于心跳周期调整模块根据IoT设备的注册时间，计算IoT设备的心跳周期。
S4.定时任务模块创建与IoT设备对应的心跳周期调整任务。
示例性地，设备管理模块以成功验证IoT设备为合法设备的时间作为IoT设备的注册时间，并在任务请求消息中携带IoT设备的注册时间。在定时任务模块接收到来自设备管理模块的任务请求消息后，定时任务模块创建与IoT设备对应的一个心跳周期调整任务。
即，以IoT设备的注册时间为起始时间，在每个执行周期，计算一次IoT设备的心跳周期，从而实现对IoT设备的心跳周期的动态调整。
其中，执行周期用于确定计算心跳周期的时间间隔，比如执行周期可以是一周、半个月、一个月或两个月等，可以根据实际使用需求进行调整，本申请实施例不作限定。
当不同的IoT设备请求注册至IoT平台时，IoT平台可以根据每个IoT设备的注册时间、每个IoT设备的设备类型、注册至IoT平台的IoT设备的数量等一种或多种因素，分别创建与每个IoT设备对应的心跳周期调整任务。
示例性地，表1提供了注册至IoT平台的IoT设备的数量、IoT设备的设备类型、IoT设备的注册时间、心跳周期调整任务的起始时间、心跳周期调整任务的执行周期的对应关系。
表1
如表1所示，摄像头、报警器、智慧屏和智能门锁的注册时间不同，相应地，每个心跳周期调整任务的起始时间也有所不同。
另外，针对智慧屏和摄像头这些用户远程操作较为频繁的IoT设备，定时任务模块可以将心跳周期调整任务的执行周期设置较短，以便增加计算心跳周期的次数，从而及时对心跳周期进行调整；而针对报警器和智能门锁这些用户远程操作不太频繁的IoT设备，定时任务模块可以将心跳周期调整任务的执行周期设置较长，以便减少计算心跳周期的次数，从而减轻IoT平台的性能压力。
此外，当注册至IoT平台的IoT设备的数量越少时，IoT平台的性能压力越小，定时任务模块可以将心跳周期调整任务的执行周期设置较短，以便增加计算心跳周期的次数，从而心跳周期调整模块能够更为准确预估IoT设备的心跳周期。随着注册至IoT平台的IoT设备的数量增加，IoT平台的性能压力越大，此时定时任务模块可以将心跳周期调整任务的执行周期设置较长，以便减少计算心跳周期的次数，从而减轻IoT平台的性能压力。
S5.定时任务模块向设备管理模块返回任务成功创建消息。
任务成功创建消息用于指示定时任务模块已经成功创建心跳周期调整任务。
S6.设备管理模块向IoT设备返回成功注册结果。
成功注册结果用于指示IoT设备已经成功注册至IoT平台。
在一些实施例中，为了实现用户设备对IoT设备的远程控制，在IoT设备请求注册至IoT平台之前，用户设备需要对IoT设备进行配网。以IoT设备为摄像头，用户设备为手机为例。当用户新购入摄像头后，将摄像头接入电源，摄像头开机并进行设备初始化。用户打开手机上的智能家居APP，点击添加IoT设备的控件。手机开始扫描周围的IoT设备。手机显示扫描到的周围的IoT设备的列表。用户从列表中选择需要配网的IoT设备，比如摄像头。然后，用户输入Wi-Fi网络密码，摄像头的PIN等。手机开始对摄像头进行配网，并注册。
阶段二、数据统计
IoT平台通过下述S7-S10统计在第i-1个执行周期中各个时段的活跃数据。
S7.用户设备向数据分析模块发送第一数据，相应地，数据分析模块接收并存储第一数据。第一数据用于指示发生用户设备通过IoT平台远程控制IoT设备的事件，简称为用户设备控制事件。
在一些实施例中，第一数据包括第一事件标识和第一时间。其中，第一事件标识用于指示设备控制事件，比如第一事件标识为00。第一时间为设备控制事件的发生时间，比如包括年、月、日及时刻。
在另一些实施例中，第一数据还可以包括用户设备的标识，应理解，由于可能存在多台用户设备，因此在第一数据中携带用户设备的标识，能够实现对用户设备的区分。
在又一些实施例中，第一数据还可以包括IoT设备的标识，应理解，由于可能存在多台IoT设备，因此在第一数据中携带IoT设备的标识，能够分别统计分析与每个IoT设备对应的事件数据，进而便于计算与每个IoT设备对应的心跳周期。
在一些实施例中，设备控制事件包括下述几种类型：
类型1，用户设备通过IoT平台向IoT设备发送控制指令，以使得控制IoT设备通过IoT平台向用户设备返回IoT设备所采集的各种信息，比如控制摄像头返回采集的视频。
类型2，用户设备通过IoT平台向IoT设备发送控制指令，以使得控制IoT设备执行与控制指令对应的一项或多项功能，比如控制智能音箱播放用户在用户设备输入的语音，或控制空气净化器执行空气净化功能。
在一些实施例中，数据分析模块可以通过下述几种方式获取第一数据：
方式1，当用户对用户设备的IoT APP进行控制操作时，用户设备生成控制指令，并在控制指令中携带第一数据，之后向IoT平台发送控制指令，从而数据分析模块可以从控制指令中解析得到第一数据，并存储第一数据。另外，IoT平台向IoT设备转发控制指令，IoT设备执行与控制指令对应的处理动作。
方式2，当用户对用户设备的IoT APP进行控制操作时，用户设备分别生成控制指令和第一数据，然后存储第一数据，并向IoT平台发送未携带第一数据的控制指令。然后，IoT平台向IoT设备转发控制指令，IoT设备执行与控制指令对应的处理动作。再然后，用户设备可以在预设时间向数据分析模块发送第一数据，比如每隔一天向数据分析模块上报一次在每天发生的设备控制事件的数据，或者在下一个心跳周期调整任务的执行周期之前向数据分析模块上报本周期的所有设备控制事件的数据。
方式3，当用户对用户设备的IoT APP进行控制操作时，用户设备生成控制指令，并向IoT平台发送控制指令。IoT平台接收到控制指令后，确定发生用户设备远程控制IoT设备的事件，因此IoT平台可以根据控制指令及接收到控制指令的系统时间，生成第一数据，并在数据分析模块存储第一数据。另外，IoT平台向IoT设备转发控制指令，IoT设备执行与控制指令对应的处理动作。
S8.用户设备向数据分析模块发送第二数据，相应地，数据分析模块接收并存储第二数据。第二数据用于指示发生用户打开用户设备的IoT APP的事件，即发生用户设备的IoT APP切换至前台运行状态的事件。
在一些实施例中，第二数据包括第二事件标识和第二时间。其中，第二事件标识用于指示IoT APP切换至前台运行的事件，比如第二事件标识为01。第二时间为IoT APP切换至前台运行事件的发生时间，比如包括年、月、日及时刻。
在另一些实施例中，第二数据还可以包括用户设备的标识，应理解，由于可能存在多台用户设备，因此在第一数据中携带用户设备的标识，能够实现对用户设备的区分。
在一些实施例中，用户可以通过点击用户设备的IoT APP的应用图标，或点击IoTAPP的后台卡片，或通过语音助手，触发IoT APP切换至前台运行状态。
在一些实施例中，数据分析模块可以通过下述几种方式获取第二数据：
方式1，当用户触发用户设备切换至前台运行状态时，用户设备生成第二数据，并立即向IoT平台发送第二数据，从而数据分析模块可以从控制指令中解析得到第二数据，并存储第二数据。
方式2，当用户触发用户设备切换至前台运行状态时，用户设备生成第二数据，并存储第二数据。用户设备可以在预设时间向数据分析模块发送第二数据，比如每隔一天向数据分析模块上报一次在每天发生的IoT APP切换至前台运行事件的数据，或者在下一个心跳周期调整任务的执行周期之前向数据分析模块上报本周期的所有IoT APP切换至前台运行事件的数据。
需要说明的是，在实际实现时，用户会先打开用户设备的IoT APP，再通过IoT平台远程控制IoT设备。根据上述实施例的描述，由于第一数据和第二数据存在多种上报方式，因此本申请实施例对S7和S8的执行顺序不作限定，可以根据实际需求进行调整。
S9.IoT设备向数据分析模块发送第三数据，相应地，数据分析模块接收并存储第三数据。第三数据用于指示发生IoT设备向IoT平台上报采集数据的事件，简称上报采集数据事件。
需要说明的是，IoT设备向IoT平台上报的采集数据为采用布线技术、网络通信技术、安全防范技术、自动控制技术和/或音视频技术等，采集的声、光、热、电、力学、化学、生物和/或位置等各种数据。
在一些实施例中，第三数据包括第三事件标识和第三时间。第三事件标识用于指示上报采集数据事件，比如第三事件标识为10。第三时间为上报采集数据事件的发生时间，比如包括年、月、日及时刻。
在另一些实施例中，第三数据还可以包括IoT设备的标识，应理解，由于可能存在多台IoT设备，因此在第三数据中携带IoT设备的标识，能够分别统计分析与每个IoT设备对应的事件数据，进而便于计算与每个IoT设备对应的心跳周期。
在一些实施例中，数据分析模块可以通过下述几种方式获取第三数据：
方式1，在IoT设备采集到数据后，IoT设备对数据进行分析，若满足上报条件，则IoT设备主动向IoT平台发送第三数据，第三数据包括采集到的数据和当前系统时间。
例如，以摄像头为例，若摄像头对数据进行分析后，发现有陌生人入侵，则摄像头向IoT平台发送包含采集的视频数据和当前系统时间的报警信息，IoT平台将报警信息转发至用户设备，即发生报警事件。再例如，用户预先将温湿度计设置为每隔一段时长上报一次温湿度值，在每次达到预设时长后温湿度计向IoT平台上报一次温湿度值，IoT平台将温湿度值发送至用户设备。
方式2，IoT设备接收来自用户设备的控制指令，该控制指令用于指示IoT设备上报采集的数据。IoT设备响应于控制指令，在采集到数据后，向IoT平台发送第三数据，第三数据包括采集到的数据和当前系统时间。然后，IoT平台将第三数据转发至用户设备。
S10.IoT设备向数据分析模块发送第四数据，相应地，数据分析模块接收并存储第四数据。第四数据用于指示发生IoT设备的离线事件。
在一些实施例中，第四数据包括第四事件标识和第四时间。第四事件标识用于指示IoT设备离线事件，比如第四事件标识为11。第四时间为IoT设备离线事件的发生时间，比如包括年、月、日及时刻。
在另一些实施例中，第四数据还可以包括IoT设备的标识，应理解，由于可能存在多台IoT设备，因此在第四数据中携带IoT设备的标识，能够分别统计分析与每个IoT设备对应的事件数据，进而便于计算与每个IoT设备对应的心跳周期。
在一些实施例中，数据分析模块可以通过下述几种方式获取第四数据：
方式1，在IoT设备向IoT平台发送心跳包后，如果IoT平台没有在时间阈值内返回心跳应答，那么IoT设备断开与服务器的TCP连接。在重新建立TCP连接后，IoT设备立即向IoT平台发送第四数据，第四数据包括第四事件标识和第四时间。
方式2，在IoT设备向IoT平台发送心跳包后，如果IoT平台没有在时间阈值内返回心跳应答，那么IoT设备记录第四数据。然后，IoT设备可以在预设时间向数据分析模块发送第四数据，比如每隔一周向数据分析模块上报一次在每周发生的IoT设备离线事件的数据，或者在下一个心跳周期调整任务的执行周期之前向数据分析模块上报本周期的所有IoT设备离线事件的数据。
方式3，在超过时间阈值，IoT平台没有接收到来自IoT设备的心跳包，那么断开与IoT设备的TCP连接，并通过数据分析模块记录第四数据，第四数据包括第四事件标识和第四时间。
阶段三、计算心跳周期
在上述阶段一，定时任务模块创建了与IoT设备对应的心跳周期调整任务：以IoT设备的注册时间为起始时间，在每个执行周期，计算一次IoT设备的心跳周期。在IoT平台的系统时间达到任意一个执行周期的起始时间时，定时任务模块可以触发心跳周期调整模块计算该执行周期中IoT设备的心跳周期。以第i个执行周期为例，心跳周期调整模块可以通过下述S11-S16，根据在第i-1个执行周期中各个时段的活跃数据，计算第i个执行周期中各个时段的心跳周期。其中，i为大于1的整数。
S11.在定时任务模块创建与IoT设备对应的心跳周期调整任务之后，如果IoT平台的系统时间达到心跳周期调整任务的第i个执行周期的起始时间，那么定时任务模块向心跳周期调整模块发送信息，该信息用于指示心跳周期调整模块计算在第i个执行周期中IoT设备的心跳周期。
本申请实施例可以将一个执行周期划分为时间间隔相等或不等的多个时段。
在第一种实现方式中，当用户在一个执行周期中不同时段使用IoT设备的活跃度较为接近时，心跳周期调整模块可以为该执行周期的IoT设备计算一个心跳周期。示例性地，以执行周期为一个月为例，如果计算得到在第1个月IoT设备的心跳周期为0.1T，那么IoT设备按照心跳周期为0.1T，向IoT平台发送心跳包；如果计算得到在第2个月IoT设备的心跳周期为0.2T，那么IoT设备按照心跳周期为0.2T，向IoT平台发送心跳包。其中，T为常规的固定心跳周期，比如在智能家居领域中IoT设备的固定心跳周期通常为60秒。
在第二种实现方式中，当用户在一个执行周期中不同时段使用IoT设备的活跃度相差较为明显时，比如在白天07:00-08:59用户使用IoT设备的概率较高，在夜晚00:00-01:59用户使用IoT设备的概率较低，在这种情况下心跳周期调整模块可以为一个执行周期的每个时段分别计算一个心跳周期。
需要说明的是，下述实施例是以采用第二种实现方式计算IoT设备的心跳周期为例进行示例说明的，其并不对本申请实施例形成限定，在实际实现时也可以采用第一种实现方式计算IoT设备的心跳周期。
S12.心跳周期调整模块向设备管理模块发送请求消息，以查询IoT设备的注册时间。相应地，设备管理模块响应于该请求消息，查询IoT设备的注册时间，并向心跳周期调整模块返回响应消息，该响应消息包括IoT设备的注册时间。
S13.心跳周期调整模块根据IoT设备的注册时间，计算与第i个执行周期对应的基础心跳周期(basic heart beat cycle)。
在本申请实施例中，可以预先获取大量用户使用用户设备控制IoT设备的数据，然后采用数据分析算法，对这些数据进行分析，统计得出在IoT设备注册至IoT平台之后，用户在不同时段使用IoT设备的规律。之后，以IoT设备的注册时间为起始时间，划分多个执行周期，并为每个执行周期设置一个与之对应的基础心跳周期。
需要说明的是，这里的“执行周期”即为心跳周期调整任务的执行周期。
通常，当用户新购置IoT设备后，用户对IoT设备的新鲜感较为强烈，使用用户设备对IoT设备进行远程控制的次数较多，在这种情况下，可以将与一个执行周期对应的基础心跳周期设置较短，以便增加计算心跳周期的次数，从而使得用户能够通过用户设备及时快速感知IoT设备的真实状态。在一段时间后，随着用户对IoT设备的新鲜感减弱，使用用户设备对IoT设备进行远程控制的次数逐渐减小，在这种情况下，可以将与一个执行周期对应的基础心跳周期设置较长，以便减少计算心跳周期的次数，从而降低IoT设备的功耗和IoT平台的性能压力。
示例性地，表2、表3和表4示出了三种预先设置的执行周期和基础心跳周期的对应关系。在表2和表3中，执行周期以1个月为单位，IoT平台每隔1个月对基础心跳周期进行一次调整，比如在第1个月的基础心跳周期为0.1T，在第2个月的基础心跳周期为0.5T，在注册时间达到某个月后用户使用IoT设备的频率基本不再频繁变化，因此维持基础心跳周期T。在表4中，执行周期以2周为单位，IoT平台每隔2周对基础心跳周期进行一次调整，比如在第1-2周的基础心跳周期为0.1T，在第3-4周的基础心跳周期为0.3T，在注册时间达到某周后维持基础心跳周期T。其中，T为常规的固定心跳周期。应理解，若心跳周期调整任务的执行周期越短，则基础心跳周期调整更为频繁，使得基础心跳周期更为准确。
表2
执行周期 第1个月 第2个月 第3个月及之后
基础心跳周期 0.1T 0.5T T
表3
执行周期 第1个月 第2个月 第3个月 第4个月及之后
基础心跳周期 0.1T 0.5T 0.9T T
表4
执行周期 第1-2周 第3-4周 第5-6周 第7周及之后
基础心跳周期 0.1T 0.3T 0.5T T
上述实施例介绍了基础心跳周期。基础心跳周期是根据大量用户数据分析得到的，而不同用户之间存在个体差异，并且同一用户在一个执行周期的不同时段也可能存在差异，若所有用户均采用相同的基础心跳周期发送心跳包，则可能存在有些用户无法通过用户设备快速真实感知IoT设备的状态，或有些IoT设备的功耗较高的问题。因此，本申请提出了先根据IoT设备的注册时间，为每个执行周期分别设置一个基础心跳周期，然后将基础心跳周期作为参照周期，根据上一个执行周期中用户设备控制IoT设备的活跃指数、用户打开IoT APP的活跃指数、IoT设备上报采集数据的活跃指数和/或IoT设备的离线活跃指数等因素，对基础心跳周期进行动态调整，从而更为准确地计算得到最终的心跳周期。
下面通过S14-S15介绍对基础心跳周期进行动态调整的实现方式。
S14.心跳周期调整模块向数据分析模块发送请求消息，以查询在第i-1个执行周期中各个时段的活跃数据。相应地，数据分析模块对S7-S10获取的各种数据进行分析，得到在第i-1个执行周期中各个时段的活跃数据，并向心跳周期调整模块返回在第i-1个执行周期中各个时段的活跃数据。
其中，每个时段的活跃数据用于反映在该时段内IoT设备的活跃程度。
需要说明的是，本申请实施例中的“第i-1个执行周期”为“第i个执行周期”的上一个执行周期。在“第i-1个执行周期”中，IoT平台为IoT设备计算了心跳周期，IoT设备按照该心跳周期向IoT平台发送心跳包维持长连接，进而IoT平台的数据分析模块获取了四类数据：用于指示发生用户设备控制事件的第一数据、用于指示发生用户设备的IoT APP切换至前台运行状态的事件的第二数据、用于指示发生IoT设备上报采集数据事件的第三数据、以及用于指示发生IoT设备离线事件的第四数据。在“第i个执行周期”中，在数据分析模块接收到心跳周期调整模块的请求消息后，数据分析模块可以按照时段，对“第i-1个执行周期”中的一类或多类数据进行统计分析，从而为IoT设备重新计算心跳周期，进而使得IoT设备第i个执行周期按照更新后的心跳周期向IoT平台发送心跳包。
结合上述S11的描述，数据分析模块可以将一个执行周期划分为时间间隔相等或不等的多个时段，当用户在一个执行周期中不同时段使用IoT设备的活跃度相差较为明显时，数据分析模块可以对上一个执行周期的各个时段的数据进行分析，以得到在本执行周期中各个时段的活跃数据。
示例性地，以上一个执行周期为第i-1个执行周期为例。第i-1个执行周期包括N个子周期，比如第i-1个执行周期为1个月，1个子周期为1天。数据分析模块将每个子周期划分为多个时段，比如：以30分钟为单位，将1天划分为48个时段；或者，以1小时为单位，将1天划分为24个时段；或者，以2小时为单位，将1天划分为12个时段。
在一些实施例中，每个时段的活跃数据具体为用户活跃指数。对于在第i-1个执行周期获取的四类数据，数据分析模块可以统计每类数据指示的事件在各时段发生的次数，并根据每类数据指示的事件在每个时段发生的次数，计算在每个时段的用户活跃指数。
下面提供一种根据事件在每个时段发生的次数，计算在每个时段的用户活跃指数的具体实现方式：
假设第i-1个执行周期包括30天，数据分析模块将每天均分为12个时段，则存在：
关系式1：i1＝k1*f1。其中，f1用于表示在第1天至第30天的第j个时段用户设备控制事件发生的次数，i1用于表示与用户设备控制事件对应的用户活跃指数。
关系式2：i2＝k2*f2。其中，f2用于表示在第1天至第30天的第j个时段用户设备的IoT APP切换至前台运行状态的事件发生的次数，i2用于表示与用户设备的IoT APP切换至前台运行状态的事件对应的用户活跃指数。
关系式3：i3＝k3*f3。其中，f3用于表示在第1天至第30天的第j个时段IoT设备上报采集数据事件发生的次数，i3用于表示与IoT设备上报采集数据事件对应的用户活跃指数。
关系式4：i4＝k4*f4。其中，f4用于表示在第1天至第30天的第j个时段IoT设备离线事件发生的次数，i4用于表示与IoT设备离线事件对应的用户活跃指数。
在上述关系式1-关系式4中，1≤j≤12，且j为整数。另外，k1、k2、k3和k4为预设比例系数，k1、k2、k3和k4可以相等，比如k1、k2、k3和k4均为0.1，或者，k1、k2、k3和k4均为0.5，当然k1、k2、k3和k4也可以不等，可以根据实际需求进行调整，本申请实施例不作限定。
示例性地，以k1、k2、k3和k4均等于0.1为例进行说明。下述表5示出了预先设置的时段、某类事件发生的次数、用户活跃指数的对应关系。如表5所示，第一行用于表示某类事件发生的次数，第一列用于表示时段，其余表格用于表示与时段和该类事件发生的次数对应的用户活跃指数。比如，在时段00:00-01:59，如果该类事件出现1次，那么用户活跃指数为0.1，如果该类事件出现2次，那么用户活跃指数为0.2。再比如，在时段12:00-13:59，如果该类事件出现29次，那么用户活跃指数为2.9，如果该类事件出现30次，那么用户活跃指数为3。
表5
需要说明的是，上述表5中的任意一个时段对应的次数是通过对第i-1个执行周期中第1天至最后一天的这个时段的数据统计分析后得到的，比如，00:00-01:59对应的次数：第1天00:00-01:59对应的次数、第2天00:00-01:59对应的次数、第3天00:00-01:59对应的次数、……、第30天00:00-01:59对应的次数累加得到。即，表5中的任意一个时段是由多个非连续的子时段组成。
另外，若在一个执行周期的任意一个时段，某类事件发生的次数为0，即在该时段未发生某类事件，则将与之对应的用户活跃指数设置为0。
某类事件在一个子周期的一个时段可能发生一次或多次。数据分析模块可以统计在各个子周期的该时段内发生的该类事件的所有次数，并将所有次数与预设比例系数的乘积，作为该类事件对应的用户活跃指数。
示例性地，以用户设备控制事件为例。假设第i-1个执行周期包括30个子周期，每个子周期为1天。表6示出了在每天的第一时段用户设备控制事件发生的次数，其中，第一时段为一天12个时段中的任意一个时段。数据分析模块可以对这30天该时段内发生的所有用户设备控制事件的次数进行求和，得到总次数为15次。若k＝0.1，则根据关系式i1＝k*f1，得到用户设备控制事件对应的用户活跃指数为1.5。
表6
然而，在某些特殊情况下，该类事件可能仅在少数子周期发生较多次数，而在大多数子周期该类事件未发生或仅发生一次。如果采用上述方式，将会获取一个较大的用户活跃指数，这与实际情况偏差较大，存在误判的可能性，为此本申请实施例提供了另一种方式：如果在一个子周期的一个时段发生一次或多次，那么均记为一次；如果在一个子周期的一个时段未发生，那么记为0次。如此，通过对第i-1个执行周期的第1天至最后一天的这个时段的数据累加后最多为30次。
示例性地，以IoT设备离线事件为例。假设第i-1个执行周期包括30天。表7示出了在每天的第二时段IoT设备离线事件发生的次数，第二时段为一天12个时段中的任意一个时段。其中，在第7天第二时段IoT设备离线事件发生10次，记为1次；在第16天第二时段IoT设备离线事件发生1次；在第18天第二时段IoT设备离线事件发生1次。数据分析模块可以得到总次数为3次。若k＝0.1，则根据关系式i4＝k*f4，得到IoT设备离线事件对应的用户活跃指数为0.3。应理解，在第7天发生IoT设备离线事件的次数较多，这可能是由于网络服务商故障等特殊原因导致的，如果将10次记为1次，那么可以降低误判的可能性，获得更为准确的用户活跃指数。
表7
需要说明的是，上述S14是将第i-1个执行周期划分为多个时段，并分别计算每个时段的用户活跃指数为例进行说明的，其并不对本申请实施例形成限定。在实际实现时，如果用户在一个执行周期中不同时刻或时段使用IoT设备的活跃度较为接近，心跳周期调整模块也可以仅为该执行周期计算一个用户活跃指数，并根据该用户活跃指数为IoT设备计算一个心跳周期。
S15.心跳周期调整模块根据与第i个执行周期对应的基础心跳周期、第i-1个执行周期中各个时段的活跃数据，计算在第i个执行周期中各个时段的心跳周期(period forsending heartbeat messages)。其中，每个时段的心跳周期用于确定在该时段IoT设备向IoT平台发送心跳包的时间间隔。
在本申请实施例中，第i-1个执行周期中每个时段的活跃数据用于反映在该时段内IoT设备的活跃程度。如果在第i-1个执行周期中某个时段的活跃数据表征映在该时段内IoT设备较为活跃，用户在该时段使用IoT设备的概率较大，那么心跳周期调整模块可以对与第i个执行周期对应的基础心跳周期进行调整，以缩短长连接的心跳周期，从而最大限度保持IoT设备在线状态与数据库记录一致。如果在第i-1个执行周期中某个时段的活跃数据表征在该时段内IoT设备不太活跃，用户在该时段使用IoT设备的概率较小，那么心跳周期调整模块可以对与第i个执行周期对应的基础心跳周期进行调整，以延长长连接的心跳周期，从而减少了IoT设备的功耗和IoT平台的性能压力。
结合上述S14描述，第i-1个执行周期中各个时段的活跃数据具体可以为用户活跃指数，且每类事件分别对应一个用户活跃指数。比如，与用户设备控制事件对应的用户活跃指数为i1，与用户设备的IoT APP切换至前台运行状态的事件对应的用户活跃指数为i2，与IoT设备上报采集数据事件对应的用户活跃指数为i3，与IoT设备离线事件对应的用户活跃指数为i4。在一些实施例中，心跳周期调整模块可以直接根据各个时段的用户活跃指数i1、用户活跃指数i2、用户活跃指数i3和用户活跃指数i4中的至少一项，对基础心跳周期进行调整，得到各个时段的心跳周期。在另一些实施例中，由于这些事件对心跳周期的影响程度不同，比如，用户设备控制事件对心跳周期的影响程度较高，IoT设备离线事件对心跳周期的影响程度较低，因此本申请实施例为这些事件分别设置了与之对应的权重系数，先根据权重系数对各个事件的用户活跃指数进行调整，再根据调整后的各个事件的用户活跃指数，对基础心跳周期进行调整，得到各个时段的心跳周期。
假设基础心跳周期用T1表示，用户设备控制事件的权重系数用F1表示，IoT APP切换至前台运行状态的事件的权重系数用F2表示，IoT设备上报采集数据事件的权重系数用F3表示，IoT设备离线事件的权重系数用F4表示，则在第i个执行周期中某个时段的心跳周期T2可以采用下述关系式计算得到：
示例性地，表8示出了用户设备控制事件的权重系数F1，IoT APP切换至前台运行状态的事件的权重系数F2，IoT设备上报采集数据事件的权重系数F3，以及IoT设备离线事件的权重系数F4。
表8
需要说明的是，表8中的各个权重系数为示例性说明，可以根据实际需求进行调整。
下面以表2示出的执行周期和基础心跳周期的对应关系，表8示出的各类事件的权重系数为例进行示例说明。
假设i＝1，在第1个执行周期的11:00-12:59，用户设备控制事件发生10次，IoTAPP切换至前台运行状态的事件发生5次，IoT设备上报采集数据事件发生3次，IoT设备离线事件发生5次，则存在：
如此，心跳周期调整模块计算得到在第2个执行周期中IoT设备的心跳周期为0.0562T。
假设i＝2，在第2个执行周期的11:00-12:59，用户设备控制事件发生4次，IoT APP切换至前台运行状态的事件发生1次，IoT设备上报采集数据事件发生2次，IoT设备离线事件发生2次，则存在：
如此，心跳周期调整模块计算得到在第3个执行周期中IoT设备的心跳周期为0.2941T。
假设i＝3，在第3个执行周期的11:00-12:59，用户设备控制事件发生3次，IoT APP切换至前台运行状态的事件发生2次，IoT设备上报采集数据事件发生2次，IoT设备离线事件发生1次，则存在：
如此，心跳周期调整模块计算得到在第4个执行周期中IoT设备的心跳周期为0.3226T。
假设T＝60秒。如图5所示，在第1个执行周期，心跳周期调整模块将11:00-12:59的心跳周期均设置为默认的基础心跳周期0.1T＝6秒。在第2个执行周期，心跳周期调整模块根据第1个执行周期采集的数据，以及基础心跳周期0.5T，计算得到11:00-12:59的最终心跳周期为0.0562T＝3.372秒。在第3个执行周期，心跳周期调整模块根据第2个执行周期采集的数据，以及基础心跳周期T，计算得到11:00-12:59的最终心跳周期为0.2941T＝17.646秒。在第4个执行周期，心跳周期调整模块根据第3个执行周期采集的数据，以及基础心跳周期T，计算得到11:00-12:59的最终心跳周期为0.3226T＝19.356秒。可以看出，随着各类事件发生次数的减少，用户在该时段使用IoT设备的概率也逐渐降低，通过延长长连接的心跳周期，可以减少IoT设备的功耗和IoT平台的性能压力。
S16.心跳周期调整模块向IoT设备发送心跳周期调整指令，该心跳周期调整指令包括与第i个执行周期中各个时段对应的心跳周期。相应地，IoT设备接收来自心跳周期调整模块的心跳周期调整指令。
如果第i个执行周期的每个时段分别对应一个心跳周期，那么心跳周期调整模块可以在一个心跳周期调整指令中携带第i个执行周期中各个时段对应的心跳周期。
阶段四、记录和查询IoT设备的状态
IoT平台可以通过下述S17-S18记录IoT设备的状态。用户设备可以通过下述S19-S20查询IoT设备的状态。
S17.在第i个执行周期中的每个时段，IoT设备按照与每个时段对应的心跳周期，向IoT平台的状态管理模块发送心跳包。相应地，在状态管理模块收到心跳包后，向IoT设备返回心跳响应。心跳响应和心跳包携带相同的数据，用于进行验证。
示例性地，图6示出了IoT设备维持长连接的流程示意图。图7示出了在第i个执行周期的3个时段中IoT设备与IoT平台的心跳同步过程的示意图。如图6所示，在第i个执行周期中，IoT设备接收来自心跳周期调整模块的心跳周期调整指令。如果IoT设备与IoT平台已建立TCP连接，那么在第i个执行周期的每个时段，IoT设备按照与每个时段对应的心跳周期向IoT平台的状态管理模块发送Ping帧。比如，如图7所示，当IoT平台的心跳周期调整模块将IoT设备在06:00-07:59的心跳周期设置为26秒时，在06:00-07:59这一时段，IoT设备每间隔26秒，向IoT平台的状态管理模块发送一个Ping帧，状态管理模块在第一预设时间内接收到Ping帧后，向IoT设备返回一个Pong帧；当IoT平台的心跳周期调整模块将IoT设备在08:00-09:59的心跳周期设置为19秒时，在08:00-09:59这一时段，IoT设备每间隔19秒，向IoT平台的状态管理模块发送一个Ping帧，状态管理模块在第一预设时间内接收到Ping帧后，向IoT设备返回一个Pong帧；当IoT平台的心跳周期调整模块将IoT设备在10:00-11:59的心跳周期设置为15秒时，在10:00-11:59这一时段，IoT设备每间隔15秒，向IoT平台的状态管理模块发送一个Ping帧，状态管理模块在第一预设时间内接收到Ping帧后，向IoT设备返回一个Pong帧。在IoT设备在预设时间阈值内收到Pong帧后，确定当前长连接有效，继续按照与每个时段对应的心跳周期向IoT平台的状态管理模块发送Ping帧。如果IoT设备没有在第二预设时间内收到Pong帧，标记心跳失败1次，并在累计次数达到预设Y次的情况下，确定当前长连接无效，断开与IoT平台的TCP连接，重新建立TCP连接。其中，第一预设时间和第二预设时间相等或不等。
S18.状态管理模块根据心跳包的接收情况，在数据库中记录IoT设备的状态。
若状态管理模块在时间阈值内接收到心跳包，则确定IoT平台与IoT设备的长连接处于有效状态，即IoT设备为在线状态。若状态管理模块在时间阈值内未接收到心跳包，则确定IoT平台与IoT设备的长连接处于无效状态，即IoT设备为离线状态。状态管理模块在数据库中实时记录IoT设备的状态，即，在线状态/离线状态。
S19.用户设备响应于用户操作，向状态管理模块发送请求消息，以查询IoT设备的状态。相应地，状态管理模块响应于请求消息，从数据库查询IoT设备的状态，并向用户设备发送响应消息，响应消息包括IoT设备的状态。
S20.用户设备根据响应消息，输出IoT设备的状态。
在一些实施例中，用户操作可以为触发IoT APP前台运行的操作，或者触发显示某个IoT设备的界面的操作等。
示例性地，在用户设备注册至IoT平台以后，在任意时刻用户均可以打开用户设备的IoT APP，比如用户可以点击如图8中的(a)所示的智慧家居图标81。智慧家居的进程切换为前台运行状态，显示如图8中的(b)所示的智慧家居主界面，该界面包括了预先注册至IoT平台的多个IoT设备的图标，比如摄像头的图标82、净化器的图标、洗衣机的图标及灯泡的图标等。如果用户点击摄像头的图标82，用户设备向IoT平台的状态管理模块发送请求消息，以查询摄像头的状态。状态管理模块响应于请求消息，从数据库查询摄像头的状态，并向用户设备发送响应消息，响应消息包括摄像头的状态。
如果响应消息指示摄像头为在线状态，那么用户设备显示如图8中的(c)所示的界面。该界面包括摄像头的设备标识、在线状态标识83、视频播放控件84、网络设置控件、账号安全控件、相册控件和账号安全控件等。用户通过查看在线状态标识83，确定摄像头处于在线状态，从而可以点击视频播放控件84，以触发摄像头将实时采集的视频发送至用户设备，进而用户可以在远程观看室内监控图像。
如果响应消息指示摄像头为离线状态，那么用户设备显示如图8中的(d)所示的界面。该界面包括摄像头的设备标识、离线状态标识85、视频播放控件、网络设置控件86、账号安全控件、相册控件和账号安全控件等。用户通过查看离线状态标识85，确定摄像头处于离线状态，无法远程观看由摄像头采集的室内监控图像。此时，用户可以点击网络设置控件86，触发检测用户设备与摄像头的网络故障，以进行网络重连。
可以理解的是，由于IoT平台能够根据IoT设备的注册时间、IoT设备的离线时间、用户设备控制IoT设备的时间等因素，动态调整IoT设备的心跳周期。当预估用户使用IoT设备的几率较低时，延长心跳周期，从而减少了IoT设备的功耗和IoT平台的性能压力。当预估用户使用IoT设备的几率较高时，缩短心跳周期，从而最大限度保持IoT设备在线状态与数据库记录一致，提升了用户的使用体验。如此达到了设备性能功耗与用户体验的双赢。
上述主要从IoT平台、IoT设备和用户设备之间交互的角度对本申请提供的方案进行了介绍。可以理解的是，为了实现上述功能，各网元包括了执行各个功能相应的硬件结构和/或软件模块或单元。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本发明能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
本申请实施例可以根据上述方法示例对设备进行功能模块的划分，例如，可以对应每一个功能划分每一个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。下面以采用对应每一个功能划分每一个功能模块为例进行说明。
在采用集成的模块或单元的情况下，图9示出了本申请实施例中所涉及的装置的可能的示例性框图，该装置900以软件的形式存在。该装置900可以包括：处理单元901和通信单元902。处理单元901用于对装置900的动作进行控制管理。通信单元902用于支持装置900与其他设备的通信。通信单元902也称为收发单元，可以包括接收单元和/或发送单元，分别用于执行接收和发送操作。
其中，处理单元901可以是处理器或控制器，其可以实现或执行结合本申请的实施例公开内容所描述的各种示例性的逻辑方框，模块和电路。通信单元902可以是通信接口、收发器或收发电路等，其中，该通信接口是统称，在具体实现中，该通信接口可以包括多个接口。
该装置900可以为上述任一实施例中的IoT平台、或者还可以为设置在IoT平台中的半导体芯片。处理单元901可以支持装置900执行上文中各方法示例中IoT平台的动作。或者，处理单元901主要执行方法示例中的IoT平台内部动作，通信单元902可以支持装置900与其他设备之间的通信。
在一些实施例中，处理单元901用于：确定IoT平台的系统时间达到心跳周期调整任务的第i个执行周期的起始时间；根据IoT设备注册至IoT平台的时间，确定与第i个执行周期对应的基础心跳周期；根据在第i-1个执行周期中目标时段的活跃数据，对与第i个执行周期对应的基础心跳周期进行调整，得到在第i个执行周期中目标时段的心跳周期，目标时段为第i-1个执行周期和第i个执行周期分别包括的M个时段中的任意一个时段，活跃数据用于表示在第i-1个执行周期的目标时段内IoT设备的活跃程度。
通信单元902用于：向IoT设备发送指令，该指令包括在第i个执行周期中每个时段的心跳周期，在第i个执行周期中每个时段的心跳周期用于确定IoT设备在每个时段内向IoT平台发送心跳包的时间间隔。
在另一些实施例中，处理单元901还用于：获取在第i-1个执行周期的目标时段内发生目标事件的次数，目标事件与IoT设备关联；根据发生目标事件的次数，得到在第i-1个执行周期中目标时段的用户活跃指数，用户活跃指数与发生目标事件的次数成正比例关系。其中，目标事件包括以下至少一类：第一事件，第一事件为用户设备通过IoT平台控制IoT设备的事件；第二事件，第二事件为用户设备的IoT应用程序切换至前台运行状态的事件，IoT应用程序用于控制IoT设备；第三事件，第三事件为IoT设备向IoT平台上报采集数据的事件；以及，第四事件，第四事件为IoT设备的离线事件。
在另一些实施例中，通信单元902还用于：在第i-1个执行周期，接收来自用户设备的第一数据和第二数据，第一数据指示第一事件，第二数据指示第二事件；在第i-1个执行周期，接收来自IoT设备的第三数据和第四数据，第三数据指示第三事件，第四数据指示第四事件。
在另一些实施例中，通信单元902还用于：接收来自IoT设备的注册请求消息。处理单元901还用于：响应于注册请求消息，验证IoT设备为合法设备，创建心跳周期调整任务。通信单元902还用于：并向IoT设备发送成功注册消息。
在另一些实施例中，处理单元901还用于：若通信单元902在预设时间内接收到来自IoT设备的心跳包，则确定IoT设备为在线状态，并通过通信单元902向IoT设备发送心跳响应；或者，若通信单元902在预设时间内未接收到来自IoT设备的心跳包，则确定IoT设备为离线状态，并断开与IoT设备的连接。其中，心跳包和心跳响应用于维持IoT设备与IoT平台的长连接。
本申请实施例还提供一种IoT平台，该IoT平台可以应用于如图2所示的系统，用于执行上述实施例中IoT平台的功能。参阅图10所示，IoT平台100可以包括：通信接口101、处理器102和存储器103。
其中，处理器102可以是中央处理器(central processing unit，CPU)，网络处理器(network processor，NP)，或者CPU和NP的组合等等。处理器102还可以包括硬件芯片。硬件芯片可以是专用集成电路(application-specific integrated circuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。PLD可以是复杂可编程逻辑器件(complex programmable logic device，CPLD)，现场可编程逻辑门阵列(field-programmable gate array，FPGA)，通用阵列逻辑(generic array logic，GAL)或其任意组合。处理器102在实现上述功能时，可以通过硬件实现，当然也可以通过硬件执行相应的软件实现。
通信接口101和处理器102之间相互连接。在一些实施例中，通信接口101和处理器102通过总线104相互连接。总线104可以是外设部件互连标准(peripheral componentinterconnect，PCI)总线或扩展工业标准结构(extended industry standardarchitecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
存储器103，与处理器102耦合，用于存放程序等。具体地，程序可以包括程序代码，该程序代码包括计算机操作指令。处理器102执行存储器103所存放的应用程序，实现上述实施例中IoT平台的操作。
具体的，IoT平台100在实现上述实施例中IoT平台的操作时，可以包括：
通信接口101，用于收发数据，以及与系统中的其他设备或装置进行通信交互；
处理器102，用于执行存储器103中存储的程序。当程序被执行时，处理器102确定IoT平台的系统时间达到心跳周期调整任务的第i个执行周期的起始时间；根据IoT设备注册至IoT平台的时间，确定与第i个执行周期对应的基础心跳周期；根据在第i-1个执行周期中目标时段的活跃数据，对与第i个执行周期对应的基础心跳周期进行调整，得到在第i个执行周期中目标时段的心跳周期，目标时段为第i-1个执行周期和第i个执行周期分别包括的M个时段中的任意一个时段，活跃数据用于表示在第i-1个执行周期的目标时段内IoT设备的活跃程度。示例性地，处理器102和通信接口101还可以执行上述方法实施例中IoT平台所执行的其它可能的操作，此处不再赘述。
基于上述实施例，本申请还提供了一种IoT设备，包括通信接口、处理器和存储器，处理器与存储器耦合，处理器用于执行存储器中存储的计算机程序或指令，以使得IoT设备实现上述方法实施例中IoT设备所执行的其它可能的操作，此处不再赘述。
基于上述实施例，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令；当该计算机可读存储介质在IoT平台或IoT设备上运行时，使得该IoT平台或IoT设执行如上所示的方法。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质(例如，软盘、硬盘或磁带)，光介质或者半导体介质(例如固态硬盘(solid state disk，SSD))等。
本申请实施例还提供了一种计算机程序产品，该计算机程序产品包括计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述各实施例中的方法。
本申请实施例还提供了一种芯片，该芯片与存储器耦合，该芯片用于读取并执行存储器中存储的计算机程序或指令，以执行上述各实施例中的方法。该芯片可以为通用处理器，也可以为专用处理器。在一些实施例中，该芯片还包括存储器，存储器，用于处理器所执行必要的程序指令和数据。
需要说明的是，该芯片可以使用下述电路或者器件来实现：一个或多个现场可编程门阵列(field programmable gate array，FPGA)、可编程逻辑器件(programmablelogic device，PLD)、控制器、状态机、门逻辑、分立硬件部件、任何其他适合的电路、或者能够执行本申请通篇所描述的各种功能的电路的任意组合。
上述本申请实施例提供的IoT平台、IoT设备、用户设备、装置、计算机可读存储介质、计算机程序产品以及芯片均用于执行上文所提供的方法，因此，其所能达到的有益效果可参考上文所提供的方法对应的有益效果，在此不再赘述。
应理解，上述只是为了帮助本领域技术人员更好地理解本申请实施例，而非要限制本申请实施例的范围。本领域技术人员根据所给出的上述示例，显然可以进行各种等价的修改或变化，例如，上述检测方法的各个实施例中某些步骤可以是不必须的，或者可以新加入某些步骤等。或者上述任意两种或者任意多种实施例的组合。这样的修改、变化或者组合后的方案也落入本申请实施例的范围内。
还应理解，上文对本申请实施例的描述着重于强调各个实施例之间的不同之处，未提到的相同或相似之处可以互相参考，为了简洁，这里不再赘述。
还应理解，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
还应理解，本申请实施例中，“预先设定”、“预先定义”可以通过在设备(例如，包括电子设备)中预先保存相应的代码、表格或其他可用于指示相关信息的方式来实现，本申请对于其具体的实现方式不做限定。
还应理解，本申请实施例中的方式、情况、类别以及实施例的划分仅是为了描述的方便，不应构成特别的限定，各种方式、类别、情况以及实施例中的特征在不矛盾的情况下可以相结合。
还应理解，在本申请的各个实施例中，如果没有特殊说明以及逻辑冲突，不同的实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。
最后应说明的是：以上描述内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (19)

1.一种心跳周期调整方法，其特征在于，所述方法包括：
当物联网IoT平台的系统时间达到心跳周期调整任务的第i个执行周期的起始时间时，根据IoT设备注册至所述IoT平台的时间，确定与所述第i个执行周期对应的基础心跳周期；
根据在第i-1个执行周期中目标时段的活跃数据，对与所述第i个执行周期对应的基础心跳周期进行调整，得到在所述第i个执行周期中所述目标时段的心跳周期，所述目标时段为所述第i-1个执行周期和所述第i个执行周期分别包括的M个时段中的任意一个时段，所述活跃数据用于表示在所述第i-1个执行周期的所述目标时段内所述IoT设备的活跃程度；
向所述IoT设备发送指令，所述指令包括在所述第i个执行周期中每个时段的心跳周期，所述每个时段的心跳周期用于指示所述IoT设备在所述每个时段内向所述IoT平台发送心跳包的时间间隔；
其中，i和M为正整数。
2.根据权利要求1所述的方法，其特征在于，所述心跳周期调整任务的每个执行周期分别对应一个预设的基础心跳周期；
与所述第i-1个执行周期对应的基础心跳周期，小于或等于与所述第i个执行周期对应的基础心跳周期。
3.根据权利要求1所述的方法，其特征在于，所述第i-1个执行周期和所述第i个执行周期分别包括N个子周期，所述N个子周期中的每个子周期包括M个子时段；所述目标时段为所述M个时段中的第j个时段，所述第j个时段包括所述每个子周期的第j个子时段；
其中，N为正整数，j为小于或等于M的正整数。
4.根据权利要求1至3中任一项所述的方法，其特征在于，所述活跃数据为用户活跃指数；所述根据在第i-1个执行周期中目标时段的活跃数据，对与所述第i个执行周期对应的基础心跳周期进行调整之前，所述方法还包括：
获取在所述第i-1个执行周期的所述目标时段内发生目标事件的次数，所述目标事件为与所述IoT设备关联的事件；
根据发生所述目标事件的次数，得到在所述第i-1个执行周期中所述目标时段的所述用户活跃指数，所述用户活跃指数与发生所述目标事件的次数成正比例关系。
5.根据权利要求4所述的方法，其特征在于，所述目标事件包括以下至少一类：
第一事件，所述第一事件为用户设备通过所述IoT平台控制所述IoT设备的事件；
第二事件，所述第二事件为所述用户设备的IoT应用程序切换至前台运行状态的事件，所述IoT应用程序用于控制所述IoT设备；
第三事件，所述第三事件为所述IoT设备向所述IoT平台上报采集数据的事件；
第四事件，所述第四事件为所述IoT设备的离线事件。
6.根据权利要求5所述的方法，其特征在于，所述目标事件包括所述第一事件、所述第二事件、所述第三事件和所述第四事件；
所述根据发生所述目标事件的次数，得到在所述第i-1个执行周期中所述目标时段的所述用户活跃指数，包括：
根据在所述第i-1个执行周期的所述目标时段内发生所述第一事件的次数，得到第一用户活跃指数；
根据在所述第i-1个执行周期的所述目标时段内发生所述第二事件的次数，得到第二用户活跃指数；
根据在所述第i-1个执行周期的所述目标时段内发生所述第三事件的次数，得到第三用户活跃指数；
根据在所述第i-1个执行周期的所述目标时段内发生所述第四事件的次数，得到第四用户活跃指数；
其中，所述用户活跃指数包括所述第一用户活跃指数、所述第二用户活跃指数、所述第三用户活跃指数和所述第四用户活跃指数。
7.根据权利要求6所述的方法，其特征在于，所述根据在第i-1个执行周期中目标时段的活跃数据，对与所述第i个执行周期对应的基础心跳周期进行调整，得到在所述第i个执行周期中所述目标时段的心跳周期，包括：
根据所述第一用户活跃指数、所述第二用户活跃指数、所述第三用户活跃指数和所述第四用户活跃指数，采用下述等式计算在所述第i个执行周期中所述目标时段的心跳周期T2：
其中，T1表示与所述第i个执行周期对应的基础心跳周期，i1表示所述第一用户活跃指数，i2表示所述第二用户活跃指数，i3表示所述第三用户活跃指数，i4表示所述第四用户活跃指数，F1表示与所述第一事件对应的权重系数，F2表示与所述第二事件对应的权重系数，F3表示与所述第三事件对应的权重系数，F4表示与所述第四事件对应的权重系数。
8.根据权利要求5至7中任一项所述的方法，其特征在于，所述方法还包括：
在所述第i-1个执行周期，接收来自所述用户设备的第一数据和第二数据，所述第一数据指示所述第一事件，所述第二数据指示所述第二事件；
在所述第i-1个执行周期，接收来自所述IoT设备的第三数据和第四数据，所述第三数据指示所述第三事件，所述第四数据指示所述第四事件。
9.根据权利要求5至8中任一项所述的方法，其特征在于，所述第i-1个执行周期包括N个子周期，所述N个子周期中的每个子周期包括M个子时段；所述目标时段为所述M个时段中的第j个时段，所述第j个时段包括所述每个子周期的第j个子时段；N为正整数，j为小于或等于M的正整数；
所述获取在所述第i-1个执行周期的所述目标时段内发生目标事件的次数，包括：
对于所述目标事件的每类事件，若在所述第i-1个执行周期的任意一个子周期的第j个子时段发生所述每类事件的次数大于或等于1次，则标记1次；
对所述第i-1个执行周期的N个子周期的第j个子时段标记的次数累加求和，得到在所述第i-1个执行周期的所述目标时段内发生所述每类事件的次数。
10.根据权利要求1至9中任一项所述的方法，其特征在于，在所述IoT平台的系统时间达到所述心跳周期调整任务的所述第i个执行周期的起始时间之前，所述方法还包括：
接收来自所述IoT设备的注册请求消息；
响应于所述注册请求消息，验证所述IoT设备为合法设备；
创建所述心跳周期调整任务，并向所述IoT设备发送成功注册消息；
其中，所述心跳周期调整任务为：以所述IoT设备注册至所述IoT平台的时间为起始时间，在每个执行周期计算一次所述IoT设备的心跳周期。
11.根据权利要求10所述的方法，其特征在于，所述每个执行周期的周期长度根据以下至少一项确定：所述IoT设备的设备类型，以及注册至所述IoT平台的设备的数量。
12.根据权利要求1至11中任一项所述的方法，其特征在于，所述向所述IoT设备发送指令之后，所述方法还包括：
若在预设时间内接收到来自所述IoT设备的心跳包，则确定所述IoT设备为在线状态，并向所述IoT设备发送心跳响应；或者，
若在预设时间内未接收到来自所述IoT设备的心跳包，则确定所述IoT设备为离线状态，并释放所述IoT平台与所述IoT设备的连接；
其中，所述心跳包和所述心跳响应用于维持所述IoT设备与所述IoT平台的长连接。
13.一种心跳周期调整方法，其特征在于，所述方法包括：
接收来自IoT平台的指令，所述指令包括在心跳周期调整任务的第i个执行周期中每个时段的心跳周期，i为正整数；
在所述第i个执行周期中的所述每个时段，按照所述每个时段的心跳周期，向所述IoT平台发送心跳包。
14.根据权利要求13所述的方法，其特征在于，所述方法还包括：
若在预设时间内接收到来自所述IoT平台的心跳响应，则确定IoT设备与所述IoT平台的长连接有效；或者，若在预设时间内未接收到来自所述IoT平台的心跳响应，则确定所述IoT设备与所述IoT平台的长连接无效。
15.根据权利要求13或14所述的方法，其特征在于，所述接收来自IoT平台的指令之前，所述方法还包括：
在第i-1个执行周期，向所述IoT平台发送第三数据和第四数据；
其中，所述第三数据指示第三事件，所述第四数据指示第四事件；所述第三事件为所述IoT设备向所述IoT平台上报采集数据的事件，所述第四事件为所述IoT设备的离线事件；所述第三事件和第四事件用于计算在所述第i个执行周期中每个时段的心跳周期。
16.一种IoT平台，其特征在于，包括通信接口、处理器和存储器，所述处理器与所述存储器耦合，所述通信接口用于连接IoT设备和用户设备，所述处理器用于执行所述存储器中存储的计算机程序或指令，以使得所述IoT平台实现如权利要求1至12中任一项所述的心跳周期调整方法。
17.一种IoT设备，其特征在于，包括通信接口、处理器和存储器，所述通信接口用于连接IoT平台，所述处理器与所述存储器耦合，所述处理器用于执行所述存储器中存储的计算机程序或指令，以使得所述IoT设备实现如权利要求13至15中任一项所述的心跳周期调整方法。
18.一种芯片，其特征在于，所述芯片与存储器耦合，所述芯片用于读取并执行所述存储器中存储的计算机程序，以实现如权利要求1至15中任一项所述的心跳周期调整方法。
19.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在IoT平台上运行时，使得所述IoT平台执行如权利要求1至12中任一项所述的心跳周期调整方法；或者，当所述计算机程序在IoT设备上运行时，使得所述IoT设备执行如权利要求13至15中任一项所述的心跳周期调整方法。
CN202210900476.5A 2022-07-28 2022-07-28 心跳周期调整方法、设备及系统 Pending CN117527652A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210900476.5A CN117527652A (zh) 2022-07-28 2022-07-28 心跳周期调整方法、设备及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210900476.5A CN117527652A (zh) 2022-07-28 2022-07-28 心跳周期调整方法、设备及系统

Publications (1)

Publication Number Publication Date
CN117527652A true CN117527652A (zh) 2024-02-06

Family

ID=89742561

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210900476.5A Pending CN117527652A (zh) 2022-07-28 2022-07-28 心跳周期调整方法、设备及系统

Country Status (1)

Country Link
CN (1) CN117527652A (zh)

Similar Documents

Publication Publication Date Title
US10854059B2 (en) Wireless sensor network
US11727012B2 (en) Data stream analytics at service layer
US20180262533A1 (en) Monitoring Device Data and Gateway Data
US11770444B2 (en) Edge computing for internet of things security with blockchain authentication
JP2017510182A (ja) ワイヤレスセンサネットワーク
US20170046366A1 (en) Search engine optimization for resource directory
US20120124136A1 (en) Context information sharing apparatus and method for providing intelligent service by sharing context information between one or more terminals
Bharti et al. Value of information based sensor ranking for efficient sensor service allocation in service oriented wireless sensor networks
US20210026904A1 (en) Mechanisms for service layer resource ranking and enhanced resource discovery
Zheng et al. Task scheduling using edge computing system in smart city
Liu et al. A trust and priority based code updated approach to guarantee security for vehicles network
US20150149629A1 (en) User online state querying method and apparatus
CN116647572B (zh) 访问端点切换方法、装置、电子设备及存储介质
KR101938734B1 (ko) 게이트웨이 기반의 ｍ２ｍ 디바이스들 기능 공유 방법 및 장치
CN111164951B (zh) 基于服务能力要求和偏好的服务注册
CN117527652A (zh) 心跳周期调整方法、设备及系统
CN110798444B (zh) 一种基于物联网的数据同步方法以及装置
CN110430098B (zh) 数据处理系统
US20220124008A1 (en) Automated Service Layer Message Flow Management In A Communications Network
WO2023217026A1 (zh) 业务处理方法、设备及可读存储介质
EP3912329B1 (en) Automated service layer message flow management in a communications network
EP3750340B1 (en) Service layer methods for offloading iot application message generation and response handling
WO2015130639A1 (en) Wireless sensor network
CN114070830A (zh) 互联网代理单臂部署架构、及互联网代理异地部署系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination