An Internet of Things device peak-shaving online scheduling method, system and server

Abstract

This application provides a method, system, and server for staggered online scheduling of IoT devices, belonging to the field of photovoltaic power plant monitoring technology. In this application, the effective sunshine start time of the area where each IoT device is located is predicted based on meteorological forecast data. The installation location information, rated power generation, network signal strength, and device health of each IoT device are obtained. Based on the above parameters of all IoT devices, an ordered device sequence is obtained. The total global online time window is divided into time slots according to the ordered device sequence, the total number of devices, and the maximum number of devices that can access the device per time slot, resulting in a target connection time slot for each device. The target connection time slot is then distributed to each IoT device so that it can initiate service connections within the target connection time slot. Therefore, the priority ranking result simultaneously reflects the comprehensive demand for devices to be prioritized for online operation, solving the problem of device online scheduling in scenarios with multiple coupled factors.

Description

Technical Field

[0001] This application relates to the field of IoT communication and distributed device scheduling technology, specifically to an IoT device staggered online scheduling method, system and server. Background Technology

[0002] In the field of photovoltaic power plant operation and maintenance management, each photovoltaic module (also known as a string) is typically equipped with a data acquisition device. This data acquisition device has a built-in communication module used to collect operating parameters such as power generation, voltage, current, and temperature of the photovoltaic string it belongs to, and uploads the collected operating parameters to the cloud server via cellular network or low-power wide area network. Since the power generation of photovoltaic modules depends on sunlight conditions, all data acquisition devices in the photovoltaic power plant are in a power-off or sleep state at night when there is no sunlight. After sunlight is restored at dawn every day, all data acquisition devices are powered on and awakened almost simultaneously, and within a short period of time, they collectively initiate transmission control protocol connection requests, hypertext transfer protocol requests, or message queue telemetry transmission protocol connection requests, as well as business data reporting operations to the cloud server.

[0003] However, large-scale photovoltaic power plants deploy tens of thousands to millions of data acquisition devices, with a large number of devices simultaneously powered on and initiating cloud connection requests around sunrise. Currently, the common approach is to use random backoff or fixed grouping based on device identifiers for peak-shaving schemes. These schemes employ a single-dimensional, static scheduling strategy, where delay parameters remain in effect once set. They cannot dynamically adjust based on multiple factors such as device location, the importance of the monitored object, network quality, and device operating conditions. This makes them unsuitable for complex scenarios with multiple coupled factors, leading to unreasonable allocation of network resources and potential server overload.

[0004] Therefore, how to formulate online scheduling strategies for each device in a multi-factor coupled scenario is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this application provides a method, system, and server for staggered online scheduling of IoT devices.

[0006] Firstly, this application provides a method for staggered online scheduling of IoT devices, applied to a cloud scheduling server, wherein the cloud scheduling server is communicatively connected to multiple IoT devices; the method includes: The effective illumination data of the area where each IoT device is located is obtained, and the effective illumination data is obtained by predicting the area where each IoT device is located based on meteorological forecast data; Obtain the static and dynamic device attributes of each IoT device. The static device attributes include the installation location information and rated power generation of each IoT device. The dynamic device attributes include the network signal strength and device health of each IoT device. Based on the effective illumination data, static device attributes, and dynamic device attributes of each IoT device, priority sorting is performed on each IoT device to generate an ordered sequence of devices arranged from high to low priority. Based on the ordered device sequence, the total number of IoT devices, and the set maximum number of devices that can access the device in a single time slot, time slot division processing is performed on the total time window from the global online start time to the global online end time to generate the target connection time period for each IoT device. The target connection time period is sent to each IoT device, enabling each IoT device to initiate a service connection within the target connection time period.

[0007] Secondly, in one embodiment, this application provides an IoT device staggered online scheduling system, comprising: The illumination prediction module is used to obtain the effective illumination data of the area where each IoT device is located. The effective illumination data is obtained by predicting the area where each IoT device is located based on meteorological forecast data. The attribute acquisition module is used to acquire the static device attributes and dynamic device attributes of each IoT device. The static device attributes include the installation location information and rated power generation of each IoT device. The dynamic device attributes include the network signal strength and device health of each IoT device. The priority sorting module is used to perform priority sorting processing on each IoT device according to the effective illumination data, static device attributes and dynamic device attributes of each IoT device, and generate an ordered sequence of devices arranged from high to low priority. The time slot partitioning module is used to perform time slot partitioning processing on the total time window from the global online start time to the global online end time based on the ordered device sequence, the total number of each IoT device and the maximum number of devices that can be accessed in a single time slot, and to generate the target connection time period for each IoT device. The heartbeat management module is used to send the corresponding target connection time period to each IoT device, so that each IoT device can initiate a service connection within the target connection time period.

[0008] Thirdly, in one embodiment, this application provides a cloud scheduling server, including a memory and a processor; the memory stores a computer program, and the processor runs the computer program in the memory to perform the steps in the IoT device off-peak online scheduling method in any of the above embodiments.

[0009] Fourthly, in one embodiment, this application provides a storage medium storing a computer program that is loaded by a processor to execute the steps in the IoT device off-peak scheduling method of any of the above embodiments.

[0010] In summary, this application obtains effective illumination data predicted from meteorological forecast data for the area where each IoT device is located, and acquires the installation location information, rated power generation, network signal strength, and device health of each IoT device. Then, it prioritizes all IoT devices based on the above parameters. Subsequently, it divides the total time window into time slots based on the ranking results, the total number of devices, and the maximum number of devices that can access the device in a single time slot. Finally, it sends the corresponding target connection time period to each IoT device so that the IoT device can initiate a service connection within the target connection time period, thus realizing the scheduling transformation from disordered concurrency to ordered batching.

[0011] In the above scheme, the prediction results of effective illumination data transform the scheduling time base from a fixed astronomical time to a dynamic time base that matches the actual illumination wake-up time. This eliminates the impact of meteorological conditions and geographical location differences on scheduling accuracy and solves the problem of mismatch between scheduling time and actual equipment online time caused by the deviation between the astronomical sunrise time and the actual wake-up time in related technologies. Installation location information serves as a geographical location parameter representing the difference in sunrise time in different longitude regions due to the Earth's rotation; rated power generation capacity serves as a parameter representing the equipment's service value; network signal strength serves as a real-time environmental parameter representing the equipment's communication success rate; and equipment health status serves as a self-state parameter representing the equipment's operating status. These five dimensions of parameters participate in the priority ranking process from five different perspectives: time, space, service value, communication environment, and equipment self-state. This ensures that the priority ranking result simultaneously reflects the comprehensive demand for equipment to be prioritized for online deployment, thus solving the equipment online scheduling problem in multi-factor coupled scenarios.

[0012] Furthermore, the time slot partitioning process divides the total time window into multiple time slots based on the ordered device sequence, the total number of devices, and the maximum number of devices that can be accessed in a single time slot. This ensures that devices in the ordered device sequence are allocated to each time slot in order of priority, and that the number of devices in each time slot does not exceed the maximum number of devices that can be accessed in a single time slot. This transforms the simultaneous arrival of a massive number of devices into the batch arrival of a limited number of devices, controlling the number of connection requests that the cloud server needs to process within a unit of time within the preset carrying capacity, thus solving the server overload problem caused by the concentrated online deployment of massive numbers of devices. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a schematic diagram illustrating an application scenario of the staggered online scheduling method for IoT devices in one embodiment of this application; Figure 2 This is a flowchart illustrating an embodiment of the IoT device staggered online scheduling method in this application; Figure 3 This is a schematic diagram showing the relevant information for prioritizing multiple IoT devices in one embodiment of this application; Figure 4 This is a schematic diagram of an IoT device staggered online scheduling system in one embodiment of this application; Figure 5 This is a schematic diagram of a cloud scheduling server provided in one embodiment of this application. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified. In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to implement and use this application. In the following description, details are set forth for illustrative purposes. It should be understood that those skilled in the art will recognize that this application can be implemented without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid unnecessary detail that would obscure the description of this application. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0017] First, the background of this application will be further explained. In large-scale photovoltaic power plants, the number of data acquisition devices deployed can reach tens of thousands to millions. When these massive data acquisition devices are simultaneously powered on and initiate connection requests within a preset time period before and after sunrise, the following technical problems arise: First, the simultaneous arrival of massive concurrent connection requests to the cloud server causes a sudden spike in the utilization rate of the cloud server's central processing unit and memory usage, resulting in connection request timeouts, connection rejections, increased response delays, and even server service crashes. Second, due to the disorderly competition for connection requests, key equipment such as the data acquisition devices corresponding to high-power photovoltaic strings and the main transformer acquisition points cannot obtain stable connection resources, leading to delays in core data acquisition and affecting the real-time monitoring and scheduling decisions of the photovoltaic power plant. Third, the random backoff algorithm or fixed hash grouping algorithm based on device identifiers used in related technologies only achieve randomized or fixed grouping of devices coming online. They do not consider the differences in sunrise time caused by geographical longitude differences between the locations of different data acquisition devices, nor do they consider the differences in the power importance of the photovoltaic strings monitored by different data acquisition devices, the differences in real-time network signal quality at the locations of different data acquisition devices, or the differences in the health status of the data acquisition devices themselves. This leads to high-value devices potentially being placed at the same competitive level as low-value devices, resulting in unreasonable allocation of network resources. Fourth, sunrise time is affected by longitude, latitude, and meteorological conditions. There is a deviation between the actual power-on wake-up time of photovoltaic modules and the astronomical sunrise time. The sunrise time calculated based on astronomical calendars in related technologies cannot accurately predict the true power-on wake-up time of each data acquisition device.

[0018] To address the aforementioned issues, common solutions include: assigning each data acquisition device a random delay time ranging from zero to a maximum delay value, allowing the device to wait for this random delay time after power-on before initiating a connection request; or, using a modulo operation on a preset number of groups based on the device identifier to solidify the data acquisition device into multiple groups, and assigning different fixed delay times to different groups. However, in these solutions, both the random delay time and the fixed group delay time are static preset values. Once set, they remain unchanged throughout the entire operating cycle and cannot be dynamically adjusted based on differences in device geographical location, device importance, real-time network signal quality, and device health status. Furthermore, none of these solutions involve predicting actual effective light data, making it impossible to achieve precise peak-shifting scheduling that matches the actual wake-up time of the devices.

[0019] like Figure 1 As shown, Figure 1 This is a schematic diagram illustrating an application scenario of an IoT device staggered online scheduling method according to an embodiment of this application. Exemplarily, the IoT device staggered online scheduling method according to an embodiment of this application is applied to a cloud scheduling server 100. The cloud scheduling server 100 can be deployed in the station control layer network environment of a photovoltaic power station. The cloud scheduling server 100 integrates an IoT device staggered online scheduling system, and runs a computer-readable storage medium corresponding to the IoT device staggered online scheduling method to execute the steps of the IoT device staggered online scheduling method.

[0020] Combination Figure 1 In addition to the cloud-based dispatch server 100, the photovoltaic power station can also be equipped with multiple IoT devices (such as photovoltaic data acquisition rods 1, 2, ... etc.), communication network equipment, equipment attribute database, meteorological data interface, and historical power generation database, etc. All components are connected sequentially through data links to form a complete business path from on-site equipment data acquisition, peak-shaving dispatch calculation processing by the cloud-based dispatch server 100, to the orderly online deployment of IoT devices according to dispatch instructions.

[0021] Multiple IoT devices and communication network devices constitute the field device access layer. Each IoT device is a data acquisition device deployed at a photovoltaic module or photovoltaic string. This data acquisition device integrates a microcontroller, cellular communication module, global positioning module, real-time clock, and photovoltaic power supply and backup battery. Each IoT device is used to collect operating data such as power generation, voltage, current, and temperature of the photovoltaic string it is located in, and accesses the communication network device through the cellular network. The communication network device is a transparent data transmission channel connecting the IoT devices and the cloud scheduling server 100. It can use fourth-generation cellular networks, fifth-generation cellular networks, narrowband IoT, or low-power wide area networks. It is used to upload lightweight heartbeat request messages and business data sent by IoT devices to the cloud scheduling server 100, and to forward lightweight heartbeat response messages and scheduling instructions issued by the cloud scheduling server 100 to the corresponding IoT devices. The above-mentioned collected data and communication data are uniformly connected to the cloud scheduling server 100, which completes the status aggregation and scheduling management of all IoT devices. The cloud scheduling server 100 receives lightweight heartbeat request messages uploaded by IoT devices through communication network devices on the one hand, and generates a target connection time period for each IoT device by executing the IoT device staggered online scheduling method on the other hand, and sends the target connection time period to the corresponding IoT device through a lightweight heartbeat response message.

[0022] The data support layer consists of a device attribute database, a meteorological data interface, and a historical power generation database. The device attribute database stores the static and dynamic device attributes of all IoT devices. Static attributes include the device identifier, installation location information (including longitude and latitude), and rated power output for each IoT device. Dynamic attributes include the network signal strength and device health status reported by each IoT device in its most recent heartbeat update. The meteorological data interface obtains daily weather forecast raster data from meteorological service providers, including total cloud cover, low cloud cover, visibility, and relative humidity. The historical power generation database stores historical power generation data for each photovoltaic module, used for training the solar radiation prediction model. The cloud-based scheduling server 100 obtains the daily weather forecast data through the meteorological data interface at a preset trigger time each day. Combined with the longitude, latitude, and altitude of the installation location of each IoT device stored in the device attribute database, it executes the effective solar radiation data prediction step in the IoT device off-peak scheduling method. The cloud scheduling server 100 also reads the static and dynamic device attributes of each IoT device from the device attribute database, performs priority sorting and time slot allocation processing, and generates the target connection time period for each IoT device.

[0023] Furthermore, it should be noted that the cloud-based scheduling server 100 in this embodiment supports multiple deployment forms. It can be deployed independently as a peak-shaving scheduling server at the photovoltaic power station control layer, or as an advanced application function module within the "four-capable" server of a new energy power station. The "four-capable" refers to the observable, measurable, controllable, and adjustable scheduling and management requirements that a new energy power station must meet; the "four-capable" server is a dedicated power station server that carries the corresponding power grid scheduling and management functions. It can also be deployed as an advanced application function module within an energy management system, allowing for flexible selection based on the existing hardware architecture and system configuration of the power station. It is understood that the number of IoT devices connected in this scenario can be flexibly adjusted according to the installed capacity of the power station, ranging from several thousand to millions of units. Changes in the number of devices and the specific deployment form do not affect the implementation of the core technical solution of this method and are all within the scope of equivalent substitution or derivation of the technical solution of this application.

[0024] It should be noted that, Figure 1 The application scenario of the staggered online scheduling method for IoT devices shown is merely an example. The application scenario of the staggered online scheduling method for IoT devices described in this application embodiment is to more clearly illustrate the technical solution of this application embodiment and does not constitute a limitation on the technical solution provided in this application embodiment. Based on the above application scenario of the staggered online scheduling method for IoT devices, an embodiment of the staggered online scheduling method for IoT devices is proposed.

[0025] Reference Figure 2 Firstly, this application provides a method for staggered online scheduling of IoT devices, including steps S110-S150, which will be described in detail below.

[0026] Step S110: Obtain effective illumination data for the area where each IoT device is located. The effective illumination data is obtained by predicting the area where each IoT device is located based on weather forecast data.

[0027] As a possible example, a cloud-based scheduling server could initiate the scheduling preparation process at approximately 3:00 AM each day. This cloud-based scheduling server works in conjunction with multiple data acquisition devices deployed at the site of a large photovoltaic power plant (such as…). Figure 1The "photovoltaic data acquisition rods 1, 2, ..., N, etc." shown maintain a communication connection, with each data acquisition device being an IoT device. The cloud-based scheduling server first acquires weather forecast data for the location of each IoT device. This weather forecast data can be extracted from gridded weather forecast data provided by a third-party weather service provider. Based on the latitude and longitude coordinates pre-reported by each IoT device, the cloud-based scheduling server locates the corresponding grid cell (which can also be understood as the grid area corresponding to the IoT device) from the gridded weather forecast data and extracts the total cloud cover, low cloud cover, visibility, and relative humidity values ​​contained in that grid cell. Subsequently, the cloud-based scheduling server concatenates the extracted latitude and longitude, altitude, total cloud cover, low cloud cover, visibility, and relative humidity into a fixed-dimensional input feature vector. For example, this input feature vector has seven dimensions, arranged in the order of longitude, latitude, altitude, total cloud cover, low cloud cover, visibility, and relative humidity. The cloud-based scheduling server then feeds this input feature vector into the input layer of a pre-trained illumination prediction model. The illumination prediction model is a regression model based on a gradient boosting decision tree architecture, such as the XGBoost machine learning model, which contains multiple regression decision trees. The input feature vector is sequentially processed by each regression decision tree in the model. Each regression decision tree traverses the tree structure from the root node to the leaf node based on the values ​​of each dimension of the input feature vector, eventually reaching a leaf node that stores a prediction score. The model accumulates the prediction scores of all regression decision trees and outputs two predicted values ​​representing effective illumination data. The first prediction value is the effective illumination start time in the area where the IoT device is located. This effective illumination start time is defined as the moment when the output power of the photovoltaic module begins to stably exceed a preset proportion of the rated power. This moment more accurately reflects the actual power-on and wake-up time of the IoT device due to photovoltaic power supply than the astronomical sunrise time. The second prediction value is the expected illumination duration in the area where the IoT device is located. The cloud scheduling server performs the above processing for each IoT device, obtaining the effective illumination start time and expected illumination duration for each IoT device, and stores this data in a memory cache with the device identifier as the primary key.

[0028] In this embodiment, the effective illumination data includes the effective illumination start time and the expected illumination duration. Step S110 may include the following steps S111-S112 to achieve the above function.

[0029] Step S111: Obtain the latitude and longitude of the area where each IoT device is located, the altitude of the area where each IoT device is located, and the weather forecast data of the area where each IoT device is located. The weather forecast data includes at least one of total cloud cover, low cloud cover, visibility, and relative humidity.

[0030] In this embodiment, the cloud scheduling server can read the installation location longitude and latitude of each IoT device from the device attribute database. These installation location longitude and latitude are recorded and stored when the device is first installed. Figure 1 The device attribute database is shown. The cloud scheduling server retrieves the altitude value of the corresponding location from the digital elevation model based on the read latitude and longitude. The cloud scheduling server also obtains the day's weather forecast raster data from the meteorological service provider's application programming interface (API), which covers the area where all IoT devices are located. Based on the latitude and longitude of each IoT device, the cloud scheduling server locates the corresponding raster cell in the weather forecast raster data and extracts the total cloud cover, low cloud cover, visibility, and relative humidity values ​​for that raster cell. The cloud scheduling server combines the latitude and longitude, altitude, total cloud cover, low cloud cover, visibility, and relative humidity into a complete input feature record, associates it with the corresponding IoT device's device identifier, and stores it in a temporary data table.

[0031] Step S112: Input the latitude and longitude location, altitude and weather forecast data of the area where each IoT device is located into the illumination prediction model, and output the effective illumination start time and expected illumination duration of the area where each IoT device is located through the illumination prediction model.

[0032] In one possible example, the illumination prediction model can be a regression model based on a gradient boosting decision tree architecture. The input features are sequentially processed by each regression decision tree in the model. Each regression decision tree traverses the tree structure from the root node to the leaf node based on the numerical values ​​of each dimension of the input features, eventually reaching a leaf node and outputting the predicted score stored at that leaf node. The model accumulates the predicted scores of all regression decision trees to obtain a first output value and a second output value. The first output value is the effective illumination start time, and the second output value is the expected illumination duration. The cloud scheduling server repeats the above reasoning process for the input features corresponding to each IoT device to obtain the effective illumination start time and expected illumination duration for all IoT devices.

[0033] As another possible example, the illumination prediction model can be trained through the following steps S210-S230.

[0034] Step S210: Obtain the historical power generation sequence of each IoT device. The historical power generation sequence records the moment when the power generation of each IoT device is greater than a preset proportion of the rated power generation for the first time in a series of consecutive sampling moments on a historical date. The moment is taken as the historical effective illumination start time of each IoT device on the historical date.

[0035] As a possible example, historical power generation data for each IoT device over the past full year can be read from a historical power generation database. This historical power generation data is stored in time series format, with a power generation value recorded at fixed sampling intervals. The power generation value at each sampling moment is associated with a timestamp of that sampling moment. For each historical date, the cloud scheduling server iterates through the power generation time series for that historical date, starting from the early morning of that day, sequentially recording the power generation values ​​at each sampling moment. The cloud scheduling server checks if there are multiple consecutive sampling moments (e.g., five, sampled one per minute) where the power generation value is greater than 5% of the rated power of the IoT device. When the first five consecutive sampling moments that meet the above condition are detected, the timestamp corresponding to the first of the five consecutive sampling moments is recorded as the historical effective illumination start time for the IoT device on that historical date. Alternatively, the time point when the power generation for the first five consecutive minutes of the day is greater than 5% of the rated power can also be recorded as the historical effective illumination start time; this embodiment does not limit this.

[0036] Step S220: Obtain the historical latitude and longitude, historical altitude and historical weather forecast data corresponding to the historical date. The historical weather forecast data includes at least one of historical total cloud cover, historical low cloud cover, historical visibility and historical relative humidity.

[0037] In this embodiment, for each historical date processed in step S210, the cloud scheduling server obtains the corresponding historical latitude and longitude, historical altitude, and historical weather forecast data. The cloud scheduling server reads the installation location longitude and latitude of each IoT device from the device attribute database as its historical latitude and longitude. Based on this historical latitude and longitude, the cloud scheduling server queries the corresponding historical altitude from the digital elevation model. Then, it reads the historical weather forecast data corresponding to that historical date from the historical weather database. This historical weather forecast data includes any one or more of the following: historical total cloud cover, historical low cloud cover, historical visibility, and historical relative humidity. Finally, the server associates the above data with the historical effective sunshine start time of the IoT device on that historical date obtained in step S210, forming a complete training sample record.

[0038] Step S230: Using the historical latitude and longitude location, the historical altitude, and historical weather forecast data as training input data, and the historical effective sunshine start time and the historical sunshine duration corresponding to the historical date as training label data, the selected artificial intelligence model is trained to obtain the sunshine prediction model.

[0039] In one possible example, the cloud scheduling server can divide all the training sample records obtained above into a training set and a validation set. The historical latitude and longitude, historical altitude, historical total cloud cover, historical low cloud cover, historical visibility, and historical relative humidity of each training sample record are used as training input data, and the corresponding historical effective sunshine start time and historical sunshine duration are used as training label data. Then, the training input data is fed into a selected initial artificial intelligence model, such as a regression model based on a gradient boosting decision tree architecture. The initial artificial intelligence model performs forward computation on the training input data, outputting the predicted effective sunshine start time and predicted sunshine duration. The cloud scheduling server calculates the first difference between the predicted effective sunshine start time and the historical effective sunshine start time in the training labels, and the second difference between the predicted sunshine duration and the historical sunshine duration in the training labels. Then, based on the combined loss value of the first and second differences, a new regression decision tree is constructed tree by tree using the gradient boosting method. Each newly constructed regression decision tree fits the residuals of the prediction results of all previous decision trees. Finally, the changes in the overall loss value are monitored on the validation set. Training is stopped when the overall loss value no longer decreases in multiple consecutive iterations, and the set of multiple trained regression decision trees is used as the illumination prediction model.

[0040] Step S120: Obtain the static device attributes and dynamic device attributes of each IoT device. The static device attributes include the installation location information and rated power generation of each IoT device. The dynamic device attributes include the network signal strength and device health of each IoT device.

[0041] As a possible example, cloud-based scheduling servers can be used to... Figure 1 The system reads the static device attributes of each IoT device from the device attribute database. These static attributes include the installation location information and rated power output of each IoT device. The installation location information includes the longitude and latitude of the installation location, and the rated power output is the rated output power of the photovoltaic string monitored by the IoT device. Additionally, the system can also read the dynamic device attributes of each IoT device from the device attribute database. These dynamic attributes include the network signal strength and device health of each IoT device. The network signal strength is the signal strength indicator value reported by each IoT device during its most recent communication with the cloud scheduling server. The device health score is a health rating calculated by each IoT device based on its internal self-check status; a higher score indicates a more normal operating status.

[0042] Step S130: Based on the effective illumination data, static device attributes, and dynamic device attributes of each IoT device, perform priority sorting on each IoT device to generate an ordered sequence of devices arranged from high to low priority.

[0043] In this embodiment, the cloud scheduling server can generate at least two priority factors for each IoT device based on the effective illumination data, static device attributes, and dynamic device attributes of each IoT device. Then, based on these at least two priority factors, the cloud scheduling server sorts the IoT devices to obtain the ordered device sequence. Each priority factor can represent the priority contribution of an IoT device in different dimensions. The cloud scheduling server weights and fuses multiple priority factors for the same IoT device to obtain a priority evaluation index for that IoT device. Then, the same weighted aggregation process is performed on each IoT device to obtain the priority evaluation indexes for all IoT devices. Finally, the cloud scheduling server sorts all IoT devices according to their priority evaluation indexes from highest to lowest to obtain the ordered device sequence.

[0044] Specifically, step S130 can be implemented through the following steps S1311-1317, as explained in detail below.

[0045] Step S1311: Extract the latest effective light start time and the earliest effective light start time of each IoT device from the effective light start time of each IoT device, and calculate the first priority factor of each IoT device using the effective light start time, the latest effective light start time and the earliest effective light start time of each IoT device.

[0046] In this embodiment, the cloud scheduling server iterates through all the effective illumination start times of all IoT devices obtained in step S110, retrieving the effective illumination start time with the largest value as the latest effective illumination start time, and iterates through the effective illumination start time with the smallest value as the earliest effective illumination start time. For example, for each IoT device, the difference between the latest effective illumination start time and the effective illumination start time of that IoT device can be calculated to obtain a first difference; the difference between the latest effective illumination start time and the earliest effective illumination start time can be calculated to obtain a second difference; the first difference is divided by the second difference to obtain the first priority factor of that IoT device. During the calculation process, if the second difference is zero, the first priority factor of that IoT device is set to a preset constant. The value of the first priority factor reflects the priority difference of the IoT device due to the sunrise time; IoT devices with earlier sunrise times receive a larger first priority factor value.

[0047] Step S1312: Extract the longest expected illumination duration and the shortest expected illumination duration from the expected illumination duration of each IoT device, and calculate the second priority factor for each IoT device based on the expected illumination duration, the longest expected illumination duration and the shortest expected illumination duration of each IoT device.

[0048] Step S1313: Extract the maximum rated power from the rated power of each IoT device, and calculate the third priority factor for each IoT device based on the rated power and the maximum rated power of each IoT device.

[0049] Step S1314: Extract the maximum and minimum network signal strengths from the network signal strengths of each IoT device, and calculate the fourth priority factor for each IoT device based on the network signal strength, the maximum network signal strength, and the minimum network signal strength.

[0050] Step S1315: Use the device health of each IoT device as the fifth priority factor.

[0051] In this embodiment, the cloud scheduling server directly uses the device health score of each IoT device obtained in step S120 as the fifth priority factor for that IoT device. The device health score itself is a dimensionless scalar value, and its value can reflect the health status of the IoT device. The higher the health score of the IoT device, the more normal its operating status, and the higher the success rate when it is prioritized for online deployment.

[0052] Step S1316: Perform weighted processing on the first priority factor, the second priority factor, the third priority factor, the fourth priority factor and the fifth priority factor of each IoT device to obtain the priority evaluation index of each IoT device.

[0053] In one possible example, the cloud scheduling server obtains the first weight value corresponding to the first priority factor, the second weight value corresponding to the second priority factor, the third weight value corresponding to the third priority factor, the fourth weight value corresponding to the fourth priority factor, and the fifth weight value corresponding to the fifth priority factor. These weight values ​​are pre-set, and their magnitude determines the contribution of the corresponding priority factor to the final priority evaluation index. For each IoT device, the cloud scheduling server multiplies the first priority factor by the first weight value to obtain the first weighted term, multiplies the second priority factor by the second weight value to obtain the second weighted term, multiplies the third priority factor by the third weight value to obtain the third weighted term, multiplies the fourth priority factor by the fourth weight value to obtain the fourth weighted term, and multiplies the fifth priority factor by the fifth weight value to obtain the fifth weighted term. Finally, the first, second, third, fourth, and fifth weighted terms are added together to obtain the priority evaluation index for the IoT device. The cloud scheduling server repeats the above weighting process for all IoT devices to obtain the priority evaluation index for each IoT device.

[0054] Step S1317: Sort each IoT device in descending order of priority evaluation index to obtain the ordered device sequence.

[0055] In this embodiment, after obtaining the priority evaluation indicators of all IoT devices, the cloud scheduling server performs a descending sorting operation on all IoT devices using the priority evaluation indicators as the sorting key. The cloud scheduling server stores the sorted result as an ordered device sequence, which is a list structure. Each element in the list contains the device identifier of the IoT device and its corresponding priority evaluation indicator. The list is arranged in descending order of priority evaluation indicators.

[0056] As one possible embodiment, the above process is illustrated below with an example.

[0057] See Figure 3As shown, assume a photovoltaic power station is equipped with three data acquisition devices: a first IoT device, a second IoT device, and a third IoT device. The first IoT device has a longitude of 121.5 degrees East, a rated power output of 10 kW, a network signal strength of -55 dBm, a device health score of 0.99, and its effective sunshine start time is 5:10 AM, with an expected sunshine duration of 10.0 hours. The second IoT device has a longitude of 121.0 degrees East, a rated power output of 5 kW, a network signal strength of -75 dBm, a device health score of 0.95, and its effective sunshine start time is 5:20 AM, with an expected sunshine duration of 9.8 hours. The third IoT device has a longitude of 120.5 degrees East, a rated power output of 15 kW, a network signal strength of -60 dBm, a device health score of 0.80, and its effective sunshine start time is 5:25 AM, with an expected sunshine duration of 10.2 hours. The cloud-based scheduling server extracts the latest and earliest effective light start times from the effective light start times of the three IoT devices. The latest effective light start time is 5:25 AM on the same day, and the earliest effective light start time is 5:10 AM on the same day. The cloud-based scheduling server also extracts the longest and shortest expected light durations from the expected light durations of the three IoT devices. The longest expected light duration is 10.2 hours, and the shortest expected light duration is 9.8 hours. Finally, the cloud-based scheduling server extracts the maximum rated power from the rated power output of the three IoT devices. The maximum rated power output is 15 kilowatts. Finally, the cloud-based scheduling server extracts the maximum and minimum network signal strengths from the network signal strength of the three IoT devices. The maximum network signal strength is -50 dBm, and the minimum network signal strength is -100 dBm.

[0058] Based on the above, the cloud scheduling server calculates the first priority factor for the first IoT device. In terms of time, using a time measurement method with 00:00 as the zero point of the day, each effective light start time is converted into a value in minutes. The latest effective light start time, 5:25 AM, corresponds to 325 minutes, and the earliest effective light start time, 5:10 AM, corresponds to 310 minutes. The first IoT device's effective light start time, 5:10 AM, also corresponds to 310 minutes. Then, the first difference between the latest effective light start time and the first IoT device's effective light start time is calculated, yielding 15 minutes; a second difference between the latest and earliest effective light start times is also calculated, yielding 15 minutes; dividing the first difference by the second difference yields the first priority factor for the first IoT device. F1_A = (325-310)÷(325-310+0.001)=15÷15.001≈0.9999; For the first IoT device, a second priority factor is calculated. The third difference is the 0.2-hour difference between the expected illumination duration of 10.0 hours and the shortest expected illumination duration of 9.8 hours. The fourth difference is the 0.4-hour difference between the longest expected illumination duration of 10.2 hours and the shortest expected illumination duration of 9.8 hours. Dividing the third difference by the fourth difference yields the second priority factor for the first IoT device. F2_A = (10.0-9.8)÷(10.2-9.8+0.001)=0.2÷0.401≈0.4988; To calculate the third priority factor for the first IoT device, divide its rated power of 10 kW by its maximum rated power of 15 kW. The resulting third priority factor for the first IoT device is: F3_A = 10÷15≈0.6667; For the first IoT device, the fourth priority factor is calculated as follows: the difference of 45dBm between the network signal strength of the first IoT device (-55dBm) and the minimum network signal strength (-100dBm) is used as the fifth difference; the difference of 50dBm between the maximum network signal strength (-50dBm) and the minimum network signal strength (-100dBm) is used as the sixth difference; and the fifth difference is divided by the sixth difference to obtain the fourth priority factor for the first IoT device. F4_A=(-55-(-100))÷(-50-(-100))=45÷50=0.9000; The device health score of the first IoT device, 0.99, is directly used as the fifth priority factor.

[0059] Based on the above, the cloud scheduling server obtains the following weight values ​​for the first priority factor: 0.30; the second priority factor: 0.20; the third priority factor: 0.25; the fourth priority factor: 0.15; and the fifth priority factor: 0.10. After multiplying each of the five priority factors of the first IoT device by its corresponding weight value and summing them, the priority evaluation index for the first IoT device is obtained as follows: Score_A=0.30×0.9999+0.20×0.4988+0.25×0.6667+0.15×0.9000+0.10×0.99=0.3000+0.0998+0.1667+0.1350+0.0990=0.8005.

[0060] Similarly, using the same method, the priority evaluation indices for the second and third IoT devices were calculated to be 0.3533 and 0.6495, respectively. The three IoT devices were then sorted in descending order of priority evaluation indices. The sorting result was that the first IoT device had the highest priority evaluation index, the third IoT device had the second highest, and the second IoT device had the lowest, generating an ordered device sequence of {first IoT device, third IoT device, second IoT device}.

[0061] Based on the above, the first weight corresponding to the first priority factor and the second weight corresponding to the second priority factor can be determined according to the seasonal type of the current scheduling cycle. For example, when the seasonal type is summer, the first weight is reduced and the second weight is increased, and when the seasonal type is winter, the first weight is increased and the second weight is reduced.

[0062] In one possible example, before performing the weighted processing in step S1316, the cloud scheduling server first determines the season type of the current scheduling period. For example, the season type is determined based on the month range of the current date within the year; if the month falls within the summer month range, the season type is summer; if the month falls within the winter month range, the season type is winter. A first weight value and a second weight value are then determined based on the determined season type. When the season type is summer, the cloud scheduling server sets the first weight value to a first summer weight value lower than the default value and sets the second weight value to a second summer weight value higher than the default value. When the season type is winter, the cloud scheduling server sets the first weight value to a first winter weight value higher than the default value and sets the second weight value to a second winter weight value lower than the default value.

[0063] Furthermore, the fourth weight corresponding to the fourth priority factor and the fifth weight corresponding to the fifth priority factor can be determined based on the network congestion status of the current scheduling period. For example, when the network congestion status is congested, the fourth weight can be reduced and the fifth weight can be increased.

[0064] In this embodiment, before performing the weighted processing in step S1316, the cloud scheduling server also obtains the network congestion status for the current scheduling period. The cloud scheduling server comprehensively determines the current network congestion status by monitoring the round-trip latency and packet loss rate of the cellular network communicating with IoT devices. When the round-trip latency exceeds a preset latency threshold and the packet loss rate exceeds a preset packet loss rate threshold, the cloud scheduling server determines the network congestion status as congested. When the network congestion status is congested, the cloud scheduling server sets the fourth weight value to a fourth congestion weight value lower than the default value and sets the fifth weight value to a fifth congestion weight value higher than the default value. When the network congestion status is good, the cloud scheduling server sets the fourth weight value to a fourth good weight value lower than the default value and sets the third weight value corresponding to the third priority factor to a third good weight value higher than the default value.

[0065] Finally, according to the first weight, the second weight, the third weight corresponding to the third priority factor, the fourth weight, and the fifth weight, the first priority factor, the second priority factor, the third priority factor, the fourth priority factor, and the fifth priority factor of each IoT device are weighted and summed to obtain the priority evaluation index of each IoT device.

[0066] Step S140: Based on the ordered device sequence, the total number of IoT devices, and the set maximum number of devices that can access the device in a single time slot, perform time slot division processing on the total time window from the global online start time to the global online end time to generate the target connection time period for each IoT device.

[0067] In this embodiment, step S140 may be implemented by steps S141-S147 as described below, which will be described in detail below.

[0068] Step S141: Determine the total number of time slots based on the total number of each IoT device and the maximum number of devices that can access a single time slot. The total number of time slots is the integer obtained by dividing the total number of each IoT device by the maximum number of devices that can access a single time slot and then rounding it up.

[0069] Step S142: Obtain the global online start time based on the earliest effective light illumination start time of each IoT device, and obtain the global online end time based on the latest effective light illumination start time of each IoT device.

[0070] The global online start time is the time obtained by subtracting a preset advance time from the earliest effective light exposure start time of each IoT device, and the global online end time is the preset normal operation start time. The global online end time can be the time obtained by adding a preset lag time to the latest effective light exposure start time of each IoT device, or it can be the preset normal operation start time.

[0071] Step S143: Determine the total duration of the total time window based on the global online start time and the global online end time.

[0072] Step S144: Determine the width of each time slot based on the total duration and the total number of time slots, wherein the width of each time slot is the duration obtained by dividing the total duration by the total number of time slots.

[0073] Step S145: Determine the start time and end time of each time slot based on the global online start time and the time slot width.

[0074] Step S146: According to the order of priority from high to low in the ordered device sequence, and taking the maximum number of access devices per time slot as the unit, allocate the IoT devices in the ordered device sequence to each time slot, so that the number of IoT devices in the same time slot does not exceed the maximum number of access devices per time slot.

[0075] Step S147: Generate the target connection time period for each IoT device based on the start time and end time of the time slot in which each IoT device is located.

[0076] In one example, based on the ordered device sequence {first IoT device, third IoT device, second IoT device} generated above, time slot partitioning is performed based on the maximum number of devices that can access a single time slot. The process of generating the target connection time period for each IoT device described in steps S141-S147 is illustrated in this example.

[0077] Assuming the maximum number of devices that can access a single time slot is set to 1, and the total time window is from 5:00 AM to 5:30 AM of the current day, with a total duration of 30 minutes. The cloud scheduling server determines the total number of time slots based on the total number of devices (3) and the maximum number of devices that can access a single time slot (1). The total number of time slots is 3 divided by 1 and rounded up to obtain 3 time slots. The cloud scheduling server divides the total duration of 30 minutes by the total number of time slots (3) to obtain a time slot width of 10 minutes for each time slot. Then, taking the global online start time of 5:00 AM of the current day as the start time of the first time slot, and adding the time slot width of 10 minutes to the start time of the first time slot, we get the end time of the first time slot as 5:10 AM of the current day. Taking the end time of the first time slot of 5:10 AM of the current day as the start time of the second time slot, and adding the time slot width of 10 minutes to the start time of the second time slot, we get the end time of the second time slot as 5:20 AM of the current day. The end time of the second time slot, 5:20 AM, is used as the start time of the third time slot. Adding the time slot width of 10 minutes to the start time of the third time slot gives an end time of 5:30 AM. Following the ordered device sequence, the first IoT device (ranked first) is assigned to the first time slot, the second-ranked third IoT device to the second time slot, and the third-ranked second IoT device to the third time slot. Target connection time periods are generated based on the start and end times of each IoT device's time slot: the first IoT device's target connection time period starts at 5:00 AM and ends at 5:10 AM; the third IoT device's target connection time period starts at 5:10 AM and ends at 5:20 AM; and the second IoT device's target connection time period starts at 5:20 AM and ends at 5:30 AM.

[0078] After generating the target connection time period, a daily online time slot allocation table is generated using the device identifier as the key and the start and end times of the target connection time period as values. This time slot allocation table is then stored in the in-memory database of the cloud scheduling server. The heartbeat manager can listen to the User Datagram Protocol (UDP) port. When it receives a lightweight heartbeat request message from an IoT device, it parses the device identifier from the message and uses it as the key to perform a query operation in the time slot allocation table, retrieving the start and end times of the target connection time period corresponding to that device identifier. The heartbeat manager then constructs a lightweight heartbeat response message, filling it with the IoT device's device identifier, the start and end times of the target connection time period, and the current time of the cloud scheduling server. The heartbeat manager can also employ a hash-based message authentication code algorithm. Using the start and end times of the target connection period for the IoT device as signature data and a pre-stored shared key as the signature key, a digital signature value is calculated and added to a lightweight heartbeat response message, which is then returned to the IoT device. Upon receiving the lightweight heartbeat response message, the IoT device verifies the digital signature value. If verification is successful, it stores the start and end times of the target connection period locally and then enters a low-power standby state, maintaining only its local real-time clock. When the local real-time clock reaches 5:00 AM, the first IoT device is awakened by an interrupt signal generated by the local real-time clock and initiates a standard service connection process. When the local real-time clock reaches 5:10 AM, the third IoT device is awakened and initiates a service connection. When the local real-time clock reaches 5:20 AM, the second IoT device is awakened and initiates a service connection. Three IoT devices were launched in batches in sequence. The number of connection requests received by the cloud scheduling server at the beginning of each time slot did not exceed the maximum number of devices that can be accessed in a single time slot (1).

[0079] In another possible example, if an IoT device fails to establish a service connection due to network jitter within the target connection period, the IoT device can re-initiate the service connection within the same target connection period. If the IoT device has not established a service connection by the end of the target connection period, the cloud scheduling server sends a connection termination command to the IoT device, and the IoT device stops initiating service connections. The cloud scheduling server reserves a compensation time slot after the global online end time. After all normal time slots and compensation time slots have expired, the cloud scheduling server counts all IoT devices that failed to initiate service connections and generates a random delay compensation duration independently for each IoT device. The value of this random delay compensation duration is a random value between zero and a preset maximum compensation duration, and each IoT device generates this random value independently. The cloud scheduling server adds this random delay compensation duration to the global online end time to obtain the compensation initiation time for the IoT device, at which point the IoT device re-initiates the service connection.

[0080] In addition, IoT devices can start a timer after sending a lightweight heartbeat request message. If no lightweight heartbeat response message is received from the cloud scheduling server when the timer expires, the heartbeat request is considered to have failed. The IoT device obtains its own device identifier, performs a hash operation on the device identifier to obtain a hash value, and performs a modulo operation on the preset delay baseline interval length to obtain an integer value between zero and the preset delay baseline interval length. This integer value is used as the fixed delay baseline duration. Then, after waiting for the fixed delay baseline duration, the lightweight heartbeat request message is reconstructed and sent to the cloud scheduling server.

[0081] The cloud-based scheduling server is configured with a scheduled task that is triggered and executed daily at 3:00 AM. When the scheduled task is triggered, the entire scheduling process is re-executed, generating a new time slot allocation table. The cloud-based scheduling server stores the target connection time periods generated in the current scheduling cycle as the currently valid scheduling table in the first storage area, and the target connection time periods generated in the previous scheduling cycle as the historical scheduling table in the second storage area. The historical scheduling table is retained in the first storage area after the currently valid scheduling table is updated, and is only cleared when the next scheduling cycle reaches the trigger time of 3:00 AM.

[0082] Furthermore, based on the above, at least one compensation time slot can be reserved after the global online end time. For example, after the cloud scheduling server completes the time slot allocation in step S147, it reserves one or more additional compensation time slots after the global online end time. The time width of this compensation time slot is the same as the time slot width of the aforementioned ordinary time slot. The cloud scheduling server sets the start time of the compensation time slot to the global online end time and sets the end time of the compensation time slot to the global online end time plus the time slot width.

[0083] Furthermore, after all time slots and the compensation time slots have ended, random delay compensation durations can be allocated to all IoT devices that have not successfully initiated a service connection within the corresponding target connection time period. The random delay compensation duration is a random duration generated independently for each IoT device that has not successfully initiated a service connection. Each IoT device that has not successfully initiated a service connection initiates a service connection at the compensation initiation time obtained by adding the random delay compensation duration to the global online end time.

[0084] In this embodiment, after all normal time slots and reserved compensation time slots have ended, the cloud scheduling server counts all IoT devices that failed to successfully initiate a service connection within their respective target connection time periods. Then, it independently generates a random delay compensation duration for each IoT device that failed to initiate a service connection. The value of this random delay compensation duration ranges from zero to a preset maximum compensation duration, and each IoT device generates this random value independently. The cloud scheduling server adds this random delay compensation duration to the global online end time to obtain the compensation initiation time for the IoT device, and then instructs the IoT device to attempt to initiate a service connection again at the compensation initiation time.

[0085] Step S150: Send the corresponding target connection time period to each IoT device, so that each IoT device can initiate a service connection within the target connection time period.

[0086] As a possible example, after generating the target connection time period for each IoT device in step S140, the cloud scheduling server distributes the target connection time period to the corresponding IoT device. The cloud scheduling server completes the distribution process through a heartbeat interaction mechanism. When the cloud scheduling server receives a lightweight heartbeat request sent by an IoT device after it is powered on and woken up, it extracts the device identifier of the IoT device from the heartbeat request, queries the target connection time period corresponding to the IoT device based on the device identifier, and encapsulates the queried target connection time period in a heartbeat response message and returns it to the IoT device. After receiving the heartbeat response message, the IoT device parses its own target connection time period and performs a service connection initiation operation according to the start and end times specified in the target connection time period. In detail, step S150 may include steps S151-S155 as described below.

[0087] Step S151: After each IoT device is powered on and woken up, receive a lightweight heartbeat request message sent by each IoT device. The lightweight heartbeat request message contains the device identifier of each IoT device, the current network signal strength, the current device health, and the current installation location information, including longitude and latitude.

[0088] In one possible example, each IoT device, after being woken up by solar power before dawn each day, first initializes its communication module and attaches to the cellular network. After attaching, the IoT device does not immediately initiate a data connection; instead, it constructs a lightweight heartbeat request message. This message is structured using a lightweight data exchange format and includes the IoT device's identifier, the network signal strength collected by the device at the current moment, the device's current health status calculated through internal self-testing, and the longitude and latitude of its current installation location obtained through its built-in positioning module. The IoT device then sends this lightweight heartbeat request message to the cloud scheduling server via a short connection using either User Datagram Protocol (UDP) or Transmission Control Protocol (TCP).

[0089] Step S152: Query the target connection time period corresponding to each IoT device based on the device identifier.

[0090] In this embodiment, after receiving a lightweight heartbeat request message from an IoT device, the cloud scheduling server parses and extracts the device identifier from the message. Using this device identifier as the query key, it performs a query operation on the time slot allocation table in the in-memory database. This time slot allocation table uses the device identifier as the primary key and the start and end times of the target connection time period as values, organized using a key-value pair storage structure. The cloud scheduling server retrieves the corresponding record from the time slot allocation table based on the device identifier and reads the start and end times of the target connection time period for the IoT device from that record.

[0091] Step S153: Return a lightweight heartbeat response message to each IoT device. The lightweight heartbeat response message includes the start time of the target connection time period corresponding to each IoT device, the end time of the target connection time period corresponding to each IoT device, and the current time.

[0092] In one possible example, after retrieving the start and end times of the target connection period for the IoT device, the cloud scheduling server constructs a lightweight heartbeat response message. This lightweight heartbeat response message is structured using the same lightweight data exchange format as the lightweight heartbeat request message. The cloud scheduling server fills the IoT device's device identifier, the retrieved start and end times of the target connection period, and the cloud scheduling server's current time into the corresponding fields of the lightweight heartbeat response message, and then returns the constructed lightweight heartbeat response message to the corresponding IoT device via a User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) short connection.

[0093] Step S154: Control each IoT device to calibrate its local real-time clock according to the current time and then enter standby mode, and wake up and initiate the service connection when the local real-time clock reaches the start time of the target connection time period.

[0094] In this embodiment, after receiving the lightweight heartbeat response message returned by the cloud scheduling server in step S153, the IoT device parses and extracts the start time, end time, and current time of the target connection period from the message. The IoT device uses the current time of the cloud scheduling server as a reference to calibrate its internal local real-time clock, ensuring synchronization. After clock calibration, the IoT device stores the start and end times of the target connection period in its local non-volatile memory and then enters a low-power standby state, maintaining only the local real-time clock. When the local real-time clock reaches the start time of the target connection period, the IoT device is awakened by an interrupt signal generated by the local real-time clock, switches from the low-power standby state to the working state, and initiates a standard service connection process to establish a service connection.

[0095] Step S155: Update the current installation location information of each IoT device to the device attribute database as static device attributes for the next scheduling cycle, and update the current network signal strength and current device health of each IoT device to the device attribute database as dynamic device attributes for the next scheduling cycle.

[0096] In one possible example, after receiving a lightweight heartbeat request message from an IoT device, the cloud scheduling server parses and extracts the current installation location's longitude and latitude from the message. Using the IoT device's device identifier as an index, the cloud scheduling server locates the corresponding attribute record in the device attribute database, updates the longitude and latitude fields in the attribute record to the current installation location's longitude and latitude, respectively. These updated longitude and latitude values ​​will then be used as static device attributes in the next scheduling cycle for priority ranking.

[0097] After step S155, a digital signature can be generated based on the target connection time period corresponding to each IoT device, and the digital signature can be added to the lightweight heartbeat response message. After receiving the lightweight heartbeat response message, each IoT device can verify the digital signature and store the target connection time period after the digital signature is verified.

[0098] In this embodiment, when constructing the lightweight heartbeat response message, the cloud scheduling server further performs a digital signature generation operation for the target connection time period corresponding to each IoT device. For example, using a hash-based message authentication code algorithm, the start and end times of the target connection time period of the IoT device are used as signature data, and a shared key pre-stored in the cloud scheduling server and the IoT device is used as the signature key to calculate a digital signature value. The cloud scheduling server adds this digital signature value as an additional field to the lightweight heartbeat response message. After receiving the lightweight heartbeat response message, the IoT device extracts the start and end times of the target connection time period and the digital signature value from the message. The IoT device uses the same hash-based message authentication code algorithm as the cloud scheduling server, using the extracted start and end times of the target connection time period as signature data, and its own stored shared key as the signature key to calculate a verification signature value. The IoT device compares the verification signature value with the received digital signature value. When the two match, the digital signature verification is deemed successful. The IoT device stores the start time and end time of the target connection period in local non-volatile memory.

[0099] In the event that the IoT device does not receive the lightweight heartbeat response message, the IoT device may perform hash mapping processing based on its own device identifier to generate a fixed delay baseline duration, and after the fixed delay baseline duration, resend the lightweight heartbeat request message to the IoT device.

[0100] In one possible example, the IoT device starts a timer after sending a lightweight heartbeat request message. If the IoT device does not receive a lightweight heartbeat response message from the cloud scheduling server when the timer expires, the IoT device determines that the heartbeat request has failed. The IoT device obtains its own device identifier, performs a hash operation on the device identifier to obtain a hash value. The IoT device performs a modulo operation on the hash value with a preset delay baseline interval length to obtain an integer value between zero and the preset delay baseline interval length, and uses this integer value as the fixed delay baseline duration. After waiting for this fixed delay baseline duration, the IoT device reconstructs and sends the lightweight heartbeat request message to the cloud scheduling server.

[0101] In addition, each IoT device can be controlled to initiate the service connection within the target connection time period after the local real-time clock reaches the start time of the target connection time period, and not send the lightweight heartbeat request message within the target connection time period.

[0102] In this embodiment, after the IoT device is woken up when its local real-time clock reaches the start time of the target connection period, it only executes the standard service connection procedure to initiate a service connection during the entire time interval between the start and end times of the target connection period. The IoT device does not send any lightweight heartbeat request messages during this time interval.

[0103] Furthermore, if any IoT device fails to initiate a service connection within the target connection time period, it can re-initiate the service connection within the target connection time period. In one possible example, if an IoT device initiates a service connection within the target connection time period and the connection fails due to network jitter or temporary server overload, the IoT device does not immediately abandon the connection attempt. The IoT device re-initiates the service connection within the same target connection time period, i.e., the time interval between the start and end of the target connection time period. The IoT device can re-initiate the service connection multiple times, but all re-initiation operations must be completed before the end of the target connection time period.

[0104] Furthermore, if any IoT device fails to establish a service connection by the end of the target connection time period, a connection termination command can be sent to the IoT device to stop initiating the service connection. In this embodiment, the cloud scheduling server continuously monitors the connection status of each IoT device within its corresponding target connection time period. When the cloud scheduling server detects that an IoT device has not yet established a service connection by the end of the target connection time period, it sends a connection termination command to that IoT device. Upon receiving the connection termination command, the IoT device immediately stops any ongoing or yet-to-be-started service connection initiation operations.

[0105] Secondly, such as Figure 4 As shown, in one embodiment, this application provides an IoT device staggered online scheduling system. The IoT device staggered online scheduling system includes a light prediction module, an attribute acquisition module, a priority sorting module, a time slot division module, and a heartbeat management module.

[0106] The illumination prediction module is used to obtain the effective illumination data of the area where each IoT device is located. The effective illumination data is obtained by predicting the area where each IoT device is located based on meteorological forecast data. The attribute acquisition module is used to acquire the static device attributes and dynamic device attributes of each IoT device. The static device attributes include the installation location information and rated power generation of each IoT device. The dynamic device attributes include the network signal strength and device health of each IoT device. The priority sorting module is used to perform priority sorting processing on each IoT device according to the effective illumination data, static device attributes and dynamic device attributes of each IoT device, and generate an ordered sequence of devices arranged from high to low priority. The time slot partitioning module is used to perform time slot partitioning processing on the total time window from the global online start time to the global online end time based on the ordered device sequence, the total number of each IoT device and the maximum number of devices that can be accessed in a single time slot, and to generate the target connection time period for each IoT device. The heartbeat management module is used to send the corresponding target connection time period to each IoT device, so that each IoT device can initiate a service connection within the target connection time period.

[0107] For details on the specific implementation of each of the above modules, please refer to the corresponding descriptions in the above method embodiments, which will not be repeated here.

[0108] Thirdly, in one embodiment, this application provides a server, such as Figure 5 The illustration shows a cloud scheduling server (hereinafter referred to as the "server") involved in this application, including a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, a power supply 403, and an input unit 404, etc. Those skilled in the art will understand that... Figure 5 The server structure shown does not constitute a limitation on the server and may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. Wherein: The processor 401 is the control center of the server, connecting various parts of the server through various interfaces and lines. It performs various server functions and processes data by running or executing software programs and / or modules stored in the memory 402, and by calling data stored in the memory 402, thereby providing overall monitoring of the server. Optionally, the processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and computer programs, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 401.

[0109] The memory 402 can be used to store software programs and modules. The processor 401 executes various functional applications and data processing by running the software programs and modules stored in the memory 402. The memory 402 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, computer programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the server, etc. In addition, the memory 402 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 with access to the memory 402.

[0110] The server also includes a power supply 403 that supplies power to the various components. Preferably, the power supply 403 can be logically connected to the processor 401 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 403 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0111] The server may also include an input unit 404, which can be used to receive input numeric or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0112] Those skilled in the art will understand that all or part of the steps in any of the methods in the above embodiments can be performed by a computer program or by a computer program controlling related hardware. The computer program can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0113] Fourthly, in one embodiment, this application provides a storage medium storing a plurality of computer programs that can be loaded by a processor to perform the steps of the method described above.

[0114] Since the computer program stored in the storage medium can execute the steps of the IoT device staggered online scheduling method in any embodiment of the present application, the beneficial effects that the IoT device staggered online scheduling method in any embodiment of the present application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0115] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0116] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed descriptions of other embodiments above, which will not be repeated here.

[0117] The above provides a detailed description of the method, system, and server for staggered online scheduling of IoT devices. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0118] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A method for staggered online scheduling of Internet of Things (IoT) devices, characterized in that, The method is applied to a cloud-based scheduling server, which is communicatively connected to multiple IoT devices; the method includes: The effective illumination data of the area where each of the IoT devices is located is obtained, and the effective illumination data is obtained by predicting the area where each of the IoT devices is located based on meteorological forecast data; Obtain the static device attributes and dynamic device attributes of each IoT device. The static device attributes include the installation location information and rated power generation of each IoT device. The dynamic device attributes include the network signal strength and device health of each IoT device. Based on the effective illumination data, static device attributes, and dynamic device attributes of each IoT device, priority sorting is performed on each IoT device to generate an ordered sequence of devices arranged from high to low priority. Based on the ordered device sequence, the total number of IoT devices, and the set maximum number of devices that can access the device in a single time slot, time slot division processing is performed on the total time window from the global online start time to the global online end time to generate the target connection time period for each IoT device. The corresponding target connection time period is sent to each of the IoT devices, so that each of the IoT devices can initiate a service connection within the target connection time period.

2. The method for staggered online scheduling of IoT devices according to claim 1, characterized in that, The effective illumination data includes the effective illumination start time and the predicted illumination duration; obtaining the effective illumination data for the area where each IoT device is located includes: The latitude and longitude of the area where each IoT device is located, the altitude of the area where each IoT device is located, and the weather forecast data of the area where each IoT device is located are obtained. The weather forecast data includes at least one of total cloud cover, low cloud cover, visibility, and relative humidity. The latitude and longitude location, altitude, and weather forecast data of the area where each IoT device is located are input into the illumination prediction model, and the illumination prediction model outputs the effective illumination start time and the expected illumination duration of the area where each IoT device is located.

3. The method for staggered online scheduling of IoT devices according to claim 2, characterized in that, It also includes the step of training the illumination prediction model, which includes: Obtain the historical power generation sequence of each IoT device. The historical power generation sequence records the moment when the power generation of each IoT device is greater than a preset proportion of the rated power generation for the first time in a series of consecutive sampling moments on a historical date. The moment is taken as the historical effective illumination start time of each IoT device on the historical date. Obtain the historical latitude and longitude, historical altitude, and historical weather forecast data corresponding to the historical date. The historical weather forecast data includes at least one of historical total cloud cover, historical low cloud cover, historical visibility, and historical relative humidity. The selected artificial intelligence model is trained using the historical latitude and longitude, the historical altitude, and the historical weather forecast data as training input data, and the historical effective sunshine start time and the historical sunshine duration corresponding to the historical date as training label data, so as to obtain the sunshine prediction model.

4. The method for staggered online scheduling of IoT devices according to claim 2, characterized in that, The step of prioritizing each IoT device based on its effective illumination start time, static device attributes, and dynamic device attributes to obtain an ordered sequence of devices arranged from high to low priority includes: Based on the effective illumination data, static device attributes, and dynamic device attributes of each IoT device, at least two priority factors are generated for each IoT device, and the IoT devices are sorted according to the at least two priority factors to obtain the ordered device sequence.

5. The method for staggered online scheduling of IoT devices according to claim 4, characterized in that, The step of generating at least two priority factors for each IoT device based on the effective illumination data, static device attributes, and dynamic device attributes of each IoT device, and sorting the IoT devices according to the at least two priority factors to obtain the ordered device sequence, includes: Extract the latest effective light start time and the earliest effective light start time of each IoT device from the effective light start time of each IoT device, and calculate the first priority factor of each IoT device using the effective light start time, the latest effective light start time and the earliest effective light start time of each IoT device. The longest and shortest expected light durations are extracted from the expected light durations of each IoT device. Based on the expected light duration, the longest expected light duration, and the shortest expected light duration of each IoT device, a second priority factor for each IoT device is calculated. The maximum rated power is extracted from the rated power of each IoT device, and a third priority factor for each IoT device is calculated based on the rated power and the maximum rated power of each IoT device. The maximum and minimum network signal strengths are extracted from the network signal strengths of each IoT device, and a fourth priority factor for each IoT device is calculated based on the network signal strength, the maximum network signal strength, and the minimum network signal strength of each IoT device. The device health score of each IoT device is used as the fifth priority factor; The first priority factor, the second priority factor, the third priority factor, the fourth priority factor, and the fifth priority factor of each IoT device are weighted to obtain the priority evaluation index of each IoT device; The IoT devices are sorted in descending order of priority evaluation criteria to obtain the ordered device sequence.

6. The method for staggered online scheduling of IoT devices according to claim 5, characterized in that, The weighted processing of the first priority factor, second priority factor, third priority factor, fourth priority factor, and fifth priority factor for each IoT device to obtain a priority evaluation index for each IoT device includes: Based on the seasonal type of the current scheduling period, determine the first weight corresponding to the first priority factor and the second weight corresponding to the second priority factor; Based on the network congestion status of the current scheduling period, determine the fourth weight corresponding to the fourth priority factor and the fifth weight corresponding to the fifth priority factor; According to the first weight, the second weight, the third weight corresponding to the third priority factor, the fourth weight, and the fifth weight, the first priority factor, the second priority factor, the third priority factor, the fourth priority factor, and the fifth priority factor of each IoT device are weighted and summed to obtain the priority evaluation index of each IoT device.

7. The method for staggered online scheduling of IoT devices according to claim 1, characterized in that, The step involves dividing the total time window from the global online start time to the global online end time into time slots based on the ordered device sequence, the total number of each IoT device, and the maximum number of devices that can access the network in a single time slot. This process generates a target connection time period for each IoT device, including: The total number of time slots is determined based on the total number of all IoT devices and the maximum number of devices that can be accessed in a single time slot. The total number of time slots is an integer obtained by dividing the total number of all IoT devices by the maximum number of devices that can be accessed in a single time slot and then rounding it up. The global online start time is obtained based on the earliest effective light illumination start time of each of the IoT devices, and the global online end time is obtained based on the latest effective light illumination start time of the IoT devices. The total duration of the total time window is determined based on the global online start time and the global online end time. The width of each time slot is determined based on the total duration and the total number of time slots; The start time and end time of each time slot are determined based on the global online start time and the time slot width. According to the order of priority from high to low in the ordered device sequence, the IoT devices in the ordered device sequence are allocated to each time slot in units of the maximum number of devices that can be accessed in a single time slot, so that the number of IoT devices in the same time slot does not exceed the maximum number of devices that can be accessed in a single time slot. The target connection time period for each IoT device is generated based on the start time and the end time of the time slot in which each IoT device is located.

8. The method for staggered online scheduling of IoT devices according to claim 1, characterized in that, The step of sending the corresponding target connection time period to each of the IoT devices, enabling each IoT device to initiate a service connection within the target connection time period, includes: After each IoT device is powered on and woken up, a lightweight heartbeat request message is received from each IoT device. The lightweight heartbeat request message contains the device identifier of each IoT device, the current network signal strength, the current device health status, and the current installation location information. Query the target connection time period corresponding to each IoT device based on the device identifier; A lightweight heartbeat response message is returned to each IoT device. The lightweight heartbeat response message includes the start time of the target connection time period corresponding to each IoT device, the end time of the target connection time period corresponding to each IoT device, and the current time. Each IoT device is controlled to enter a standby state after calibrating its local real-time clock according to the current time, and wakes up and initiates the service connection when the local real-time clock reaches the start time of the target connection time period. The current installation location information of each IoT device is updated to the device attribute database as a static device attribute for the next scheduling cycle, and the current network signal strength and current device health of each IoT device are updated to the device attribute database as dynamic device attributes for the next scheduling cycle.

9. The method for staggered online scheduling of IoT devices according to claim 8, characterized in that, The step of sending the corresponding target connection time period to each IoT device, enabling each IoT device to initiate a service connection within the target connection time period, further includes: A digital signature is generated based on the target connection time period corresponding to each IoT device. The digital signature is added to the lightweight heartbeat response message. After receiving the lightweight heartbeat response message, each IoT device verifies the digital signature and stores the target connection time period after the digital signature is verified.

10. A staggered online scheduling system for Internet of Things (IoT) devices, characterized in that, include: The illumination prediction module is used to acquire the effective illumination data of the area where each IoT device is located. The effective illumination data is obtained by predicting the area where each IoT device is located based on meteorological forecast data. The attribute acquisition module is used to acquire the static device attributes and dynamic device attributes of each IoT device. The static device attributes include the installation location information and rated power generation of each IoT device. The dynamic device attributes include the network signal strength and device health of each IoT device. The priority sorting module is used to perform priority sorting processing on each IoT device according to the effective illumination data, static device attributes and dynamic device attributes of each IoT device, and generate an ordered sequence of devices arranged from high to low priority. The time slot partitioning module is used to perform time slot partitioning processing on the total time window from the global online start time to the global online end time based on the ordered device sequence, the total number of each IoT device and the maximum number of devices that can be accessed in a single time slot, and to generate the target connection time period for each IoT device. The heartbeat management module is used to send the corresponding target connection time period to each of the IoT devices, so that each of the IoT devices can initiate a service connection within the target connection time period.

11. A cloud-based scheduling server, characterized in that, It includes a memory and a processor; the memory stores a computer program; the processor is used to run the computer program in the memory to perform the steps of the IoT device off-peak online scheduling method according to any one of claims 1 to 9.

Images