Sensor remote firmware update IoT big model system, method and medium

Abstract

This invention relates to the field of Internet of Things (IoT) technology, providing a large-scale IoT system, method, and medium for remote firmware updates of sensors. The system includes a sensor management platform configured to: determine multiple sensor update groups based on data characteristics of multiple sensors and their geographical locations within an industrial grid area; determine the update priority of each sensor update group based on its task and transmission characteristics; determine update parameters for the multiple sensor update groups based on update priority, firmware characteristics, and channel state distribution; and generate update instructions and firmware update packages based on the update parameters, and control multiple sensors in the multiple sensor update groups to perform firmware updates. The method can be executed after being read from computer instructions stored on a computer-readable storage medium. This invention enables secure, reliable, and continuous large-scale sensor firmware upgrades under complex industrial network conditions.

Description

Technical Field

[0001] This specification relates to the field of Internet of Things (IoT) technology, and in particular to a large-scale IoT system, method, and medium for remote firmware update of sensors. Background Technology

[0002] In the Industrial Internet of Things (IIoT) environment, a large number of sensor devices are widely deployed in the field, and remote firmware upgrades and maintenance are crucial to ensuring system functionality and security. Currently, most mainstream upgrade solutions adopt a non-discriminatory full firmware push mode, which fails to fully consider the spatial correlation between sensors and the differences in task risk levels, and also lacks dynamic assessment of real-time channel quality.

[0003] Meanwhile, traditional retransmission mechanisms are inefficient and can easily cause network congestion in low-bandwidth, high-packet-loss industrial network environments, leading to a high upgrade failure rate. Once the upgrade is interrupted, the system often cannot resume transmission from where it left off, and may create a blind spot due to related devices simultaneously entering upgrade mode, posing a safety hazard to industrial production.

[0004] Therefore, it is desirable to provide a large-scale IoT system, method, and medium for remote firmware updates of sensors to achieve security, reliability, and continuity in large-scale sensor firmware upgrades under complex industrial network conditions. Summary of the Invention

[0005] To address the issues of sensor firmware updates failing to consider spatial correlations between sensors, differences in task risk levels, and real-time channel quality, as well as low retransmission efficiency, susceptibility to network congestion, high upgrade failure rates, and potential sensing blind spots that could pose safety hazards in industrial production, this specification provides a large-scale IoT system, method, and medium for remote sensor firmware updates.

[0006] The invention includes a large-scale IoT system for remote firmware updates of sensors. The system comprises a sensor management platform configured to: determine multiple sensor update groups based on data characteristics of multiple sensors and their geographical locations within an industrial grid area; determine the update priority of each sensor update group based on its task and transmission characteristics; determine update parameters for each sensor update group based on the update priority, firmware characteristics, and channel state distribution; generate update instructions and firmware update packages based on the update parameters, the update instructions including an update time; and send the update instructions and firmware update packages to a sensing and control platform, controlling the multiple sensors in the multiple sensor update groups to perform firmware updates based on the update instructions.

[0007] The invention includes a remote firmware update method for sensors, executed by the sensor management platform of a large-scale IoT system for remote firmware update. The method includes: determining multiple sensor update groups based on data characteristics of multiple sensors and their geographical locations within an industrial grid area; determining the update priority of each sensor update group based on its task and transmission characteristics; determining update parameters for each sensor update group based on the update priority, firmware characteristics, and channel state distribution; generating an update instruction and a firmware update package based on the update parameters, the update instruction including an update time; and sending the update instruction and the firmware update package to a sensing control platform, which then controls the multiple sensors in the sensor update groups to perform firmware updates based on the update instruction.

[0008] The invention includes a transient readable computer storage medium for storing computer instructions. When the computer reads the computer instructions from the storage medium, the computer executes a remote firmware update method for sensors. The method includes: determining multiple sensor update groups based on data characteristics of multiple sensors and their geographical locations in an industrial grid area; determining the update priority of each sensor update group based on task characteristics and transmission characteristics of the multiple sensor update groups; determining update parameters for the multiple sensor update groups based on the update priority, firmware characteristics, and channel state distribution; generating an update instruction and a firmware update package based on the update parameters, the update instruction including an update time; sending the update instruction and the firmware update package to a sensing control platform, and controlling the multiple sensors in the multiple sensor update groups to perform firmware updates based on the update instruction.

[0009] The beneficial effects of the above invention include, but are not limited to: (1) By comprehensively considering sensor data characteristics, geographical location, task characteristics, transmission characteristics, firmware characteristics and channel state distribution, the sensor update group, update priority and update parameters are accurately determined, and the update traffic is effectively adjusted to avoid network congestion; at the same time, by intelligent batch and time-segmented sequential updates, it is ensured that sensors in the same functional area will not fail at the same time, fundamentally guaranteeing the continuity of key monitoring services; (2) By dividing the firmware update package into multiple update sub-data blocks and selectively retransmitting the data in combination with the first image index returned by the sensor, the retransmitted data The amount of data lost has been reduced from the entire firmware package to only a few individual data blocks, which has improved bandwidth utilization, significantly shortened the update delay caused by packet loss, effectively reduced network load, and improved the efficiency and reliability of large-scale firmware updates of IoT large model systems under unreliable channels; (3) By updating in advance through a small-scale update test group, firmware defects or update strategy problems can be exposed in advance, and the subsequent update plan can be dynamically adjusted according to the test results, so that the update process has self-optimization capability, significantly improving the reliability and security of firmware updates, avoiding the systemic risks that may be caused by the full rollout of defective firmware, thereby reducing potential production interruptions and maintenance costs. Attached Figure Description

[0010] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0011] Figure 1 This is an exemplary platform architecture diagram of a large-scale IoT system for remote firmware updates of sensors, as shown in some embodiments of this specification. Figure 2 This is an exemplary flowchart of a remote firmware update method for sensors according to some embodiments of this specification; Figure 3 This is an exemplary schematic diagram illustrating the processing of updating sub-data blocks according to some embodiments of this specification; Figure 4 This is an exemplary flowchart illustrating the adjustment of the update time of a sensor update group according to some embodiments of this specification.

[0012] Figure label: Sensor management platform 110, sensor network platform 120, perception control platform 130, update sub-data block 310, preset verification algorithm 320, verification code 330, sub-update package 340, first bit image index 350. Detailed Implementation

[0013] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. The accompanying drawings do not represent all implementation methods.

[0014] Unless the context clearly indicates an exception, words such as "a," "an," "a kind," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0015] In the embodiments of this specification, the order of the steps described in the step-by-step instructions is interchangeable unless otherwise specified, and steps may be omitted. Other steps may also be included in the operation process.

[0016] Figure 1 This is an exemplary block diagram of a sensor remote firmware update IoT big data system according to some embodiments of this specification. In some embodiments, the sensor remote firmware update IoT big data system 100 may include a sensor management platform 110, a sensor network platform 120, and a sensing control platform 130.

[0017] The sensor management platform 110 refers to a comprehensive management platform that manages and coordinates the connections and collaboration between multiple platforms. In some embodiments, the sensor management platform 110 is configured as a server or processor. In some embodiments, the sensor management platform 110 engages in bidirectional data interaction with the sensor network platform 120.

[0018] In some embodiments, the sensor management platform 110 includes a data center. The data center is configured to store data, information, or instructions generated or received by the sensor management platform 110. The data center includes a model library. The sensor management platform 110 can call various models through the model library, such as machine learning models, computational models, and large language models.

[0019] In some embodiments, the sensor management platform 110 interacts with the sensor network platform 120 via a data center.

[0020] In some embodiments, the sensor management platform 110 is configured to perform a remote firmware update method for sensors. For example, the sensor management platform 110 may perform the methods of process 200 and / or process 400.

[0021] The sensor network platform 120 refers to a platform used for the comprehensive management of sensor information. In some embodiments, the sensor network platform 120 is configured as a communication network or gateway. In some embodiments, the sensor network platform 120 is configured to interact with the sensor management platform 110 and the sensing control platform 130, respectively.

[0022] The sensing and control platform 130 refers to a platform that generates sensing information and executes control commands. In some embodiments, the sensing and control platform 130 is equipped with communication devices, control devices, sensors, positioning devices, etc. The sensing and control platform 130 interacts bidirectionally with the sensor network platform 120. Sensors include various monitoring sensors deployed in industrial areas, such as temperature and humidity sensors, gas sensors, image sensors, status and motion sensors, and security sensors (such as smoke detectors and door magnetic sensors).

[0023] For further explanation of the above content, please refer to [link / reference]. Figures 2 to 4 And its related descriptions.

[0024] Some embodiments in this specification demonstrate that the IoT large-scale model system 100 for remote firmware updates via sensors can form a closed loop of information operation between various functional platforms and operate in a coordinated and regular manner under the unified management of the sensor management platform. This enables the continuous and reliable operation of the remote firmware update task, improving the informatization and intelligence of remote firmware updates.

[0025] It should be noted that the above description of the IoT large-scale model system 100 for remote firmware update of sensors is for ease of description only and should not be construed as limiting this specification to the scope of the embodiments described. It is understood that those skilled in the art, after understanding the principles of this system, may arbitrarily combine the various platforms or construct subsystems and connect them to other modules without departing from these principles.

[0026] Figure 2 This is an exemplary flowchart of a remote firmware update method for sensors according to some embodiments of this specification. In some embodiments, process 200 may be executed by a sensor management platform 110 or a processor. Figure 2 As shown, process 200 may include the following steps: Step 210: Determine multiple sensor update groups based on the data characteristics of multiple sensors and the geographical locations of multiple sensors in the industrial grid area.

[0027] A sensor is a device used to collect physical quantities or environmental information and convert them into processable signals. For example, sensors can come in various types and are used to collect data such as temperature, pressure, video, and humidity. Sensors are deployed in various locations within industrial areas based on data collection needs.

[0028] Data characteristics refer to attribute information describing the generation and transmission behavior of sensor data. Data characteristics can be used to distinguish the role a sensor plays in the entire data acquisition task and its network resource requirements. The role can include the type of data acquired and the responsible location area. For example, data characteristics include data acquisition type, data acquisition frequency, data upload frequency, and the amount of data uploaded per time.

[0029] In some embodiments, the sensor management platform can obtain the data characteristics of each sensor based on the sensor configuration information database. The sensor configuration information database is a dynamic database that records various configuration information of the sensors, which may include the sensor's identification and basic attributes, hardware and software configuration, physical installation location, network topology, status and upgrade information, etc.

[0030] In some embodiments, data features can also be obtained from configuration information directly reported by the sensors.

[0031] An industrial grid area refers to a geographical region obtained by dividing an industrial area into zones. For example, an industrial grid area can be a region divided according to industrial production processes, operation types, etc. Another example is a gridded area divided based on sensor distribution. In some embodiments, the industrial grid area can be determined according to actual needs.

[0032] In some embodiments, the industrial grid area can reflect the geographical location partitioning of various sensors within an industrial area. In some embodiments, the industrial area can be divided into grids, with each grid corresponding to a region code. The sensor management platform can then manage the geographical location of the sensors based on the region code of the grid where each sensor is located.

[0033] Geographic location characterizes the deployment location of sensors within an industrial grid area. This includes, for example, installation location and spatial relationships. The geographic location of a sensor can be represented by latitude and longitude coordinates, installation address (e.g., "Air compressor room on the west side of workshop 3, XX factory"), or the area code of the industrial grid area.

[0034] In some embodiments, the sensor management platform can obtain the sensor's geographical location through a GPS module integrated within the sensor. In some embodiments, the geographical location can also be determined through cellular network base station positioning or a pre-defined deployment list.

[0035] In some embodiments, the sensor management platform can also determine the geographic location of the sensor based on the area code of the industrial grid area corresponding to the sensor. For example, the geographic location of each area in the industrial grid area can be pre-determined and associated with the area code and stored.

[0036] A sensor update group is a collection of sensors grouped together for collaborative updates. For example, a sensor update group can contain sensors with different data acquisition types that are grouped together for collaborative updates.

[0037] Collaborative updating refers to the dynamic and intelligent updating of multiple sensors in a specific order. Collaborative updating differs from isolated single-sensor updates or synchronous updates of all sensors.

[0038] Collaborative updates enable multi-sensor collaboration and update management from multiple perspectives, including time, resources, environment, and status. This ensures service continuity, optimizes upgrade paths, avoids resource waste, and allows update strategies to be dynamically adjusted and optimized based on tasks and the environment.

[0039] In some embodiments, the process of determining multiple sensor update groups includes the following steps: First, the sensor management platform geographically partitions all sensors based on industrial grid areas.

[0040] In some embodiments, the sensor management platform can geographically partition all sensors based on the area codes of each region within an industrial grid area. For example, the area codes of all regions within the industrial grid area can be divided into multiple groups in coded order, with each group corresponding to a geographical partition.

[0041] In some embodiments, the sensor management platform can determine geographical partitions based on the distribution of each grid area within an industrial grid region. For example, other grid areas adjacent to a specific grid area within an industrial grid region can be divided into a single geographical partition. The number of grid areas in a geographical partition can be a preset number, such as 4, 6, or 9.

[0042] Secondly, within each geographic partition, the sensor management platform sorts the sensors according to their data characteristics based on sorting rules, generating a sensor list. For example, the sorting rules can be set as follows: first priority is data acquisition type, second priority is data acquisition frequency, and third priority is sensor ID. Sorting by data acquisition type can be based on a preset type order, such as: temperature-pressure-video; sorting by data acquisition frequency can be in descending or ascending order; sorting by sensor ID can be based on ID number order. The sensors in the sensor list are presented in the sorted order.

[0043] Secondly, the sensor management platform performs round-robin allocation within each geographic partition based on the sensor list to determine sensor groups. The round-robin allocation specifically includes: setting the target number of sensor groups to K; initializing K empty sensor groups; then iterating through the sorted sensor list, assigning the i-th sensor to the group numbered (imodK)+1, ultimately obtaining K sensor groups. Here, (imodK) represents the remainder when i is divided by k, with the result between 0 and K-1, and adding 1 maps it to groups numbered 1 through K.

[0044] Finally, the sensor management platform merges the sensor grouping results obtained from the above steps for all geographic partitions, thus forming multiple sensor update groups. For example, there are M geographic partitions within an industrial grid area, and each geographic partition contains K sensor groups. The final merged sensor update groups are K. For example, the K sensor update groups determined from the M geographic partitions are as follows: Sensor update group 1: [partition 1_Group_1, partition 2_Group_1, ..., partition M_Group_1]; Sensor update group 2: [partition 1_Group_2, partition 2_Group_2, ..., partition M_Group_2]; ...; Sensor update group K: [partition 1_Group_K+, partition 2_Group_K, ..., partition M_Group_K].

[0045] Where M represents the partition number of the geographic partition, K represents the group number of each sensor group in each geographic partition, and partition M_Group_K represents the Kth sensor group in geographic partition M.

[0046] In some embodiments, sensor update groups can also be determined in a variety of other ways. For example, sensor update groups can be determined based on the connectivity of sensors in the network topology.

[0047] In some embodiments, the sensor management platform determines the degree of correlation between each sensor based on the data characteristics and sub-task characteristics of multiple sensors; and adjusts multiple sensor update groups according to the degree of correlation.

[0048] In some embodiments, the sensor management platform determines the degree of correlation between various sensors in multiple ways based on the data characteristics and sub-task characteristics of multiple sensors.

[0049] Subtask features reflect the importance attributes of the task being acquired by a single sensor or the importance attributes of the local area being deployed. Subtask features are a part of task features; if task features describe the overall task importance of the sensor update group, subtask features can represent the task priority of the sensor itself or a specific subsystem or microenvironment.

[0050] In some embodiments, the sensor management platform can determine the corresponding subtask characteristics based on a method of querying a preset table. Further explanation regarding the determination of task characteristics and subtask characteristics can be found in the relevant description of step 220.

[0051] The degree of correlation refers to an indicator that quantifies the strength of functional coupling, logical dependence, or collaborative relationship between any two or more sensors. For example, a higher degree of correlation means that these sensors are more likely to collectively constitute a key functional unit. The failure or malfunction of one sensor may affect the performance of other related sensors, and may even lead to the failure of the entire monitoring or control chain.

[0052] In some embodiments, the sensor management platform determines attribute vectors composed of task features and data types for each sensor, and then calculates the similarity between the attribute vectors of any two sensors, defining the similarity as the degree of association. For example, attribute vectors are obtained by vectorizing data features and sub-task features. Similarity determination methods include cosine similarity, Pearson correlation coefficient, or Jaccard similarity coefficient.

[0053] In some embodiments, the degree of correlation between sensors can also be determined using a graph neural network model. For example, sensors can be treated as nodes in a graph, and the geographical distance between sensors, the frequency of data interaction, and the proportion of sensors performing tasks together can be used as features of the initial edges. These features are then input into a trained graph convolutional network (GCN) to output the degree of correlation between nodes (i.e., between sensors).

[0054] In some embodiments, the degree of correlation between the various sensors can also be determined in a variety of other ways. For example, it can be determined through methods such as statistical analysis based on historical collaborative working patterns.

[0055] In some embodiments, the sensor management platform adjusts multiple sensor update groups based on their correlation.

[0056] In some embodiments, the sensor management platform geographically partitions all sensors based on industrial grid regions, and then independently and in parallel allocates update groups for sensors within each geographical partition based on their correlation, in order to adjust multiple sensor update groups.

[0057] For more information on how to perform geographic partitioning, please refer to the relevant description above.

[0058] In some embodiments, the allocation of update groups independently and in parallel includes the following steps: First, in each geographic partition, a preset number (K) of empty sensor update groups are initialized, and the similarity of the attribute vectors of all sensors within that geographic partition is calculated pairwise to form a similarity matrix. In some embodiments, the attribute feature vectors can be preprocessed, such as normalized, before calculating the similarity.

[0059] Then, an iterative greedy allocation strategy is used to redistribute sensors. Redistribution is conditional on the existence of unassigned sensors in the current geographic partition. For each geographic partition, the sensor with the highest average similarity to existing groups among the currently unassigned sensors is selected and assigned to the target group with the lowest similarity, until all sensors are assigned. Existing groups refer to the groups of assigned sensors, and the average similarity of existing groups is the average of the attribute vector similarities between any two sensors within the group.

[0060] Finally, sensor groups with corresponding group numbers in all geographic partitions are merged to form the final global sensor update group.

[0061] For example, there are two geographic partitions, 1 and 2. The sensor groups for geographic partition 1 are: Partition 1-Update Group 1—[Sensor 1, Sensor 2, Sensor 3]; Partition 1-Update Group 2—[Sensor 4, Sensor 5]. The sensor groups for geographic partition 2 are: Partition 2-Update Group 1—[Sensor 6, Sensor 7]; Partition 2-Update Group 2—[Sensor 8, Sensor 9].

[0062] The final merged sensor update groups include: Sensor Update Group 1—[Sensor 1, Sensor 2, Sensor 3, Sensor 6, Sensor 7]; Sensor Update Group 2—[Sensor 4, Sensor 5, Sensor 8, Sensor 9].

[0063] In some embodiments, adjusting sensor update groups can also be achieved through hierarchical clustering and optimization algorithms. For example, the sensor management platform first performs hierarchical clustering on all sensors based on their correlation degree, forming a clustering tree. Then, according to a preset number of update groups K, pruning is performed at different levels of the clustering tree to form K initial sensor update groups.

[0064] In some embodiments, adjusting the sensor update group can also be achieved in a variety of other ways. For example, the update group can be dynamically adjusted using a solution method based on a multi-objective optimization problem, such as the NSGA-II algorithm.

[0065] In some embodiments of this specification, the allocation of update tasks is optimized by dynamically grouping sensor data features with sub-task features based on their correlation. This enables parallel updates of loosely coupled sensors, thereby reducing conflicts and resource consumption and improving efficiency; it also enhances fault isolation capabilities, ensuring the continuous operation of critical tasks when some sensors fail, thus improving system reliability and response speed.

[0066] Step 220: Determine the update priority of each sensor update group in the multiple sensor update groups based on the task characteristics and transmission characteristics of the multiple sensor update groups.

[0067] Task characteristics reflect the importance of the tasks undertaken by the sensor update group or the importance of the areas in which they are deployed. For example, task characteristics may reflect the priority of each sensor in the sensor update group that monitors critical equipment, or the criticality of the industrial grid area where each sensor is located.

[0068] In some embodiments, the sensor management platform determines the sub-task characteristics of the sensor by querying a first preset table based on the sensor's task type and geographical location. The first preset table can be pre-set based on experience and stores various different task types and geographical locations, along with their corresponding sub-task characteristics.

[0069] In some embodiments, subtask characteristics can also be set by analyzing historical alarm records from each sensor.

[0070] The task characteristics of a sensor update group can be determined based on the sub-task characteristics of all sensors within that update group. For example, the sensor management platform can calculate the average importance value corresponding to the sub-task characteristics of each sensor, and use this as the task characteristics of the sensor update group.

[0071] Transmission characteristics refer to parameters that measure the stability of sensor communication channels. For example, transmission characteristics can be measured by parameters such as signal-to-noise ratio, packet loss rate, bandwidth utilization, and round-trip time.

[0072] In some embodiments, the sensor management platform determines the transmission characteristics of the sensor by querying a second preset table based on parameters such as signal-to-noise ratio (SNR), packet loss rate, bandwidth utilization, and round-trip time (RTT). The second preset table can store multiple sets of different sensor parameters such as SNR, packet loss rate, bandwidth utilization, and RTT, as well as their corresponding transmission characteristics.

[0073] In some embodiments, the sensor management platform can quantify transmission stability into different levels based on parameters such as signal-to-noise ratio (SNR), packet loss rate, bandwidth utilization, and round-trip time (RTT), using these as transmission characteristics.

[0074] Update priority is a quantitative metric used to sort sensor update groups by update order. For example, a higher update priority value may mean that the update batch of that sensor update group is later in the list.

[0075] In some embodiments, determining the update priority involves mapping the quantized values ​​of the task features and transmission features of each sensor update group to a uniform numerical range (e.g., 0 to 1), and then determining the update priority P by weighting. For example, the weighting calculation formula can be: P = weight1 (1 - Task Characteristics) + Weight 2 Transmission characteristics. Among them, the weight 1 is usually a negative value. The more critical the task, the lower the P value and the higher the priority; the more stable the transmission, the higher the P value and the lower the priority.

[0076] In some embodiments, the sensor management platform can determine update priorities using a trained machine learning model based on the task characteristics and transmission characteristics of the sensor update group.

[0077] In some embodiments, update priority can also be determined in a variety of other ways. For example, priority can be derived from multiple input features using a fuzzy logic inference system.

[0078] Step 230: Determine the update parameters for multiple sensor update groups based on update priority, firmware characteristics, and channel state distribution.

[0079] Firmware characteristics refer to data that describes the size of a firmware update package. For example, firmware characteristics can be expressed as the size of the firmware update package, and the unit can be KB or MB.

[0080] In some embodiments, the sensor management platform can directly query the size of the current update package from the firmware version management server to obtain firmware characteristics. For example, the system stores size information for different firmware versions. In some embodiments, firmware characteristics can also be obtained by analyzing the file metadata of the firmware update package.

[0081] Channel state distribution refers to the regular characteristics of how the quality of a communication channel changes over time. For example, channel state distribution can include statistical data on signal-to-noise ratio, packet loss rate, and bandwidth utilization over a preset time period.

[0082] In some embodiments, channel state distribution can be obtained through statistical data such as signal-to-noise ratio (SNR), packet loss rate, and bandwidth utilization over a preset time period (e.g., 24 hours). For example, a sensor management platform can periodically collect these statistical data from a network monitoring system and perform trend analysis to determine the channel state distribution.

[0083] In some embodiments, the channel state distribution can also be obtained through historical communication log analysis.

[0084] Update parameters refer to the operations or scheduling configuration information that guides the firmware update process. For example, update parameters include update batch and update time.

[0085] In some embodiments, determining the update parameters includes the following steps: First, the sensor management platform sorts all sensor update groups based on the calculated update priority values, and then merges groups with similar update priorities into the same update batch. Similar update priorities can mean that the update priorities are in the same priority range, which can be preset.

[0086] Then, for each update batch, the sensor management platform combines the total size of the firmware packages for all sensor update groups in that batch with the channel status distribution of the corresponding channel to select the most suitable update time. For example, for a batch that needs to transmit a large amount of data, the sensor management platform will schedule the update time in the early morning or other periods with sufficient bandwidth and low packet loss rate, based on the channel status distribution data.

[0087] In some embodiments, the sensor management platform can utilize optimization algorithms to determine update parameters. For example, using update efficiency and network load balancing as optimization objectives, a genetic algorithm can be employed to calculate the optimal update batch division and update time for each batch.

[0088] In some embodiments, update parameters can also be determined in a variety of other ways. For example, by dynamically adjusting the update strategy based on real-time network load.

[0089] In some embodiments, the sensor management platform can identify at least one update test group and adjust the update time of multiple sensor update groups across multiple industrial areas accordingly. Further details can be found in [link to relevant documentation]. Figure 4 And its related descriptions.

[0090] Step 240: Generate update instructions and firmware update package based on update parameters. The update instructions include the update time.

[0091] An update command is a set of commands and parameters required to perform a firmware update. For example, an update command may include information such as the target sensor ID to be updated, the update time, and a checksum.

[0092] Update time refers to the specified point in time or time window used to initiate the firmware update process. For example, sensor nodes will synchronously initiate the firmware update process when a preset update time is reached.

[0093] In some embodiments, the sensor management platform fills a pre-provided instruction template with the determined update parameters to generate an instruction file containing information such as update time, target update sensor ID, and checksum. For example, the instruction template reserves placeholders, and the platform replaces these placeholders with the update time, target update sensor, and checksum of the current update task to generate the update instruction.

[0094] A firmware update package is a file that contains the necessary data for updating the sensor firmware. For example, a firmware update package could be a differential package showing the differences between an older and a newer version of the firmware.

[0095] In some embodiments, the sensor management platform generates a firmware update package by: obtaining binary files of the old firmware version and the new firmware version from the firmware version management server, and then calculating the binary difference between the two using a differential algorithm (e.g., the BsDiff algorithm) to generate a differential package as the firmware update package.

[0096] In some other embodiments, the firmware update package can also be a complete firmware image file. For example, when the current firmware version of the sensor is too old to apply differential updates, the sensor management platform can directly generate and distribute a complete firmware update package.

[0097] Step 250: Send the update command and firmware update package to the perception control platform, and control multiple sensors in multiple sensor update groups to perform firmware updates based on the update command.

[0098] In some embodiments, the perception control platform can receive update instructions and firmware update packages sent by the sensor management platform and transmit them to the corresponding sensors. For example, the sensor management platform sends the generated update instructions and firmware update packages to the corresponding perception control platform via a secure communication protocol (e.g., MQTT or HTTPS). The perception control platform, acting as a gateway or proxy, is responsible for further distributing these update instructions and firmware update packages to the multiple sensors it manages according to sensor IDs.

[0099] In some embodiments, the perception control platform controls the sensor to perform firmware updates based on update instructions and firmware update packages. For example, the perception control platform parses the update instruction, sends the firmware update package to the sensor based on the update time in the update instruction, and controls the sensor to perform firmware updates at the update time. After receiving the instruction, the communication module of the sensor node triggers its firmware upgrade daemon process. This process parses the update instruction, synchronizes the sensor node's internal clock with the timestamp, enters a ready state, and waits for the specified time to arrive. When the update time arrives, the node synchronously starts the firmware update process, including retrieving the firmware update package from the local cache or gateway, performing integrity verification, writing it to the storage area, and performing a restart.

[0100] In some embodiments, the sensor periodically polls the sensing control platform for new firmware versions. Once a new version is found, it will actively download the firmware update package and update the firmware according to the update time and other parameters defined in the update instruction.

[0101] In some embodiments, the sensor management platform divides the firmware update package into multiple update sub-data blocks according to a preset scale and sends them to the perception control platform; the perception control platform transmits the multiple update sub-data blocks to multiple sensors; the first bit map index returned by the multiple sensors is obtained, the first bit map index reflects the first reception status of the update sub-data block of a single sensor; and the update sub-data block is retransmitted to at least one of the multiple sensors according to the first bit map index.

[0102] A preset size refers to a predefined basic unit for segmenting firmware update packages. For example, a preset update size could be 512 bytes or 1KB. Preset update sizes can be preset based on experience.

[0103] An update sub-data block refers to a data segment obtained by sequentially cutting a firmware update package according to a preset scale. For example, an update sub-data block is a number of small data segments formed by cutting a complete firmware update package according to a preset scale, and each small data segment is an update sub-data block.

[0104] In some embodiments, the sensor management platform loads the received complete firmware update package into memory, and then reads the data sequentially according to a preset scale (e.g., 512 bytes or 1KB), starting from the beginning of the firmware update package. Each data segment that reaches the preset scale length is encapsulated into an independent update sub-data block. If the remaining data in the firmware update package is less than a preset scale, the platform pads it to the preset scale with specific padding bytes (e.g., 0x00) to form the last update sub-data block.

[0105] Firmware update packages can be divided in various other ways, such as by dividing them based on file system block size or by dynamically adjusting them according to the network maximum transmission unit (MTU).

[0106] In some embodiments, the sensor management platform can send these divided update sub-data blocks to the sensing control platform via a network transmission protocol. During transmission, the sequence number of each update sub-data block and the total number of blocks can be included to facilitate sorting and integrity checks at the receiving end. The sensing control platform then transmits multiple update sub-data blocks to the corresponding sensors. Each of the multiple sensors will receive its corresponding multiple update sub-data blocks.

[0107] In some embodiments, the sensor management platform acquires multiple first-bit graph indices returned by multiple sensors, the first-bit graph indices reflecting the first reception status of the updated sub-data block of a single sensor.

[0108] The first bit index is a sequence of binary bits that reflects the first update state of an updated sub-data block from a single sensor. Each bit in the binary sequence reflects the first reception state of an updated sub-data block. For example, the first bit index can reflect whether a single sensor has successfully received multiple updated sub-data blocks.

[0109] The first reception state refers to the reception status of a single sensor for the updated sub-data block. The first reception state can be represented by 0 or 1, where 0 indicates that the sensor failed to receive the updated sub-data block, and 1 indicates that the reception was successful.

[0110] In some embodiments, after receiving an updated sub-data block, the sensor performs an integrity check (e.g., cyclic redundancy check, hash check) on each data block to determine a first reception state. If the integrity check indicates missing or no data, the first reception state is 0.

[0111] The sensor maintains a local first-bit map index, where each bit of the binary sequence corresponds to an update sub-data block. If an update sub-data block is successfully received and verified, the corresponding bit is set to 1; otherwise, it is set to 0.

[0112] In some embodiments, the bitmap index can also be a binary array or linked list, where each position or node corresponds to an index number of a sub-update packet and records its reception and verification status. The determination of the bitmap index can be implemented using various data structures and processing logic.

[0113] In some embodiments, after the sensor completes the reception of a certain number of update sub-data blocks or reaches a preset time interval, it generates a first-bit graph index and packages and uploads it to the perception control platform, which then forwards it to the sensor management platform.

[0114] In some embodiments, the sensor management platform generates multiple sub-update packages for multiple update sub-data blocks. These multiple sub-update packages are used to determine the first-order graph index.

[0115] Figure 3 This is an exemplary schematic diagram illustrating the processing of updating sub-data blocks according to some embodiments of this specification.

[0116] In some embodiments, such as Figure 3As shown, for each of the multiple update sub-data blocks, the regulatory management platform determines the corresponding multiple verification codes 330 based on the multiple update sub-data blocks 310 and through a preset verification algorithm 320; generates multiple sub-update packages 340 based on the multiple update sub-data blocks 310 and the multiple verification codes 330; and determines the first bit graph index 350 based on the multiple sub-update packages 340.

[0117] A verification algorithm is an algorithm used to detect whether errors occur during data transmission. For example, a verification algorithm can be a Cyclic Redundancy Check (CRC) algorithm.

[0118] In some embodiments, the preset verification algorithm is configured uniformly in advance on the sensor management platform and the perception control platform.

[0119] A checksum is a short binary sequence calculated using a checksum algorithm to verify the integrity of an updated sub-data block. In some embodiments, one checksum corresponds to one updated sub-data block.

[0120] In some embodiments, the sensor management platform takes the updated sub-data block as input and calculates a fixed-length binary sequence using a preset verification algorithm, which serves as the checksum. For example, a Cyclic Redundancy Check (CRC) algorithm can be used, taking the updated sub-data block as input to calculate a fixed-length CRC checksum. Alternatively, the verification algorithm can employ MD5 or SHA-256 hash algorithms.

[0121] In some embodiments, the sensor management platform generates a sub-update package based on the updated sub-data block and the checksum.

[0122] A sub-update packet is a structured data packet unit that contains updated sub-data blocks and additional information to ensure reliable transmission and correct order. The additional information may include a checksum.

[0123] In some embodiments, in order to generate a sub-update package, the sensor management platform assigns a unique index number to each updated sub-data block and combines it with the updated sub-data block itself and the corresponding checksum to obtain the sub-update package corresponding to the updated sub-data block.

[0124] For example, a sensor management platform can concatenate the index number, update sub-data block, and checksum in a specific order to form a complete sub-update packet. Alternatively, the sub-update packet can be in the format of a general data packet protocol, containing a header (containing the index number), a payload area (containing the update sub-data block), and a trailer (containing the checksum).

[0125] In some embodiments, the sub-update package may also contain other additional information, such as version number, timestamp, or encrypted information.

[0126] In some embodiments, the sensor management platform sends multiple sub-update packages to the corresponding sensing and control platform one by one.

[0127] In some embodiments, after the perception control platform transmits multiple sub-update packets to the corresponding sensors, the sensors will determine the first image index based on the information in the sub-update packets.

[0128] For example, after each sensor receives multiple corresponding sub-update packets, it first extracts the update sub-data blocks and checksums, and then uses the same preset checksum algorithm as the sensor management platform to check the received update sub-data blocks.

[0129] If the verification results are consistent, the index number corresponding to the sub-data block is marked as successfully received, and the corresponding position of the binary bit sequence in the first bit image index is set to 1. If the verification results are inconsistent, the index number is marked as missing or incorrect, and the corresponding position is set to 0.

[0130] Some embodiments in this specification ensure data transmission integrity by generating a checksum for each updated sub-data block and encapsulating it within a sub-update packet for transmission. This scheme effectively detects silent errors and significantly improves the reliability of firmware updates. Simultaneously, the sensor accurately constructs the first-order graph index, laying the foundation for highly reliable selective retransmission, thereby guaranteeing the stability and efficiency of system updates.

[0131] In some embodiments, the sensor management platform retransmits update sub-data blocks to at least one of multiple sensors based on the first bit map index. In some embodiments, the sensor management platform receives and parses the first bit map index of the sensor, identifies all index positions with a bit value of 0, forming a missing index list. These index positions with a bit value of 0 correspond to update sub-data blocks that the sensor failed to receive. Based on the missing index list, the sensor management platform searches for and identifies the corresponding update sub-data blocks in its local cache, then repackages these update sub-data blocks that need to be retransmitted and sends them to the corresponding sensor.

[0132] In some embodiments, retransmissions may carry additional metadata (e.g., retransmission count, timestamp) to aid in the management of sensor firmware updates. The retransmission process may be repeated until the sensor's bitmap index shows that all blocks have been successfully received, or a preset maximum retransmission limit is reached.

[0133] Some embodiments in this specification significantly improve the efficiency and reliability of large-scale firmware updates for IoT large-scale model systems under unreliable channels by dividing the firmware update package into multiple update sub-data blocks and selectively retransmitting them in conjunction with the first-bit graph index returned by the sensor. This scheme drastically reduces the amount of retransmitted data from the entire firmware package to only the lost individual sub-data blocks, improving bandwidth utilization, significantly shortening update delays caused by packet loss, and effectively reducing network load.

[0134] In some embodiments, the sensor management platform divides multiple micro-electromagnetic environment clusters based on historical channel data of multiple sensor update groups within an industrial grid area; for each of the multiple micro-electromagnetic environment clusters, it obtains a second bitmap index returned by multiple sensors, the second bitmap index reflecting the second reception status of update sub-data blocks of multiple sensors in the same micro-electromagnetic environment cluster; and retransmits update sub-data blocks to multiple sensors according to the second bitmap index.

[0135] Historical channel data refers to data describing the quality and characteristics of a communication channel over a historical period. Historical channel data includes signal-to-noise ratio distribution and interference patterns, among other things.

[0136] For example, the signal-to-noise ratio (SNR) distribution could be SNR A accounting for 20% and SNR B accounting for 80%; interference modes could include periodic impulse interference, sudden continuous interference, or frequency band congestion modes, etc. Historical time can refer to the time before the current moment.

[0137] A micro-electromagnetic environment cluster refers to a group of sensors with similar wireless communication channel environments. Sensors within the same micro-electromagnetic environment cluster have similar wireless communication channel environments.

[0138] In some embodiments, the sensor management platform divides micro-electromagnetic environment clusters based on historical channel data.

[0139] For example, a sensor management platform can use clustering algorithms to perform cluster analysis on historical channel data from multiple sensors within an industrial grid area. Sensors with similar historical channel data (e.g., clean average signal-to-noise ratio, similar interference type, and similar signal strength variance) are automatically grouped into the same cluster, each cluster being a micro-electromagnetic environment cluster. By dividing into micro-electromagnetic environment clusters, sensors with similar wireless communication channel transmission environments can be effectively aggregated.

[0140] For example, a sensor management platform can divide micro-electromagnetic environment clusters based on a trained machine learning model (such as a neural network model).

[0141] In some embodiments, the sensor management platform acquires a second bitmap index returned by multiple sensors for each of multiple micro-electromagnetic environment clusters. The second bitmap index reflects the second reception status of the updated sub-data blocks of multiple sensors in the same micro-electromagnetic environment cluster.

[0142] The second bitmap index refers to a composite bitmap index that reflects the reception status of updated sub-data blocks from multiple sensors within the same micro-electromagnetic environment cluster. For example, the second bitmap index can be used to reflect the second reception status of all sensors within the same micro-electromagnetic environment cluster for updated sub-data blocks. The second bitmap index can be a data structure group composed of multiple binary bit sequences, including multiple binary bit sequences corresponding to multiple sensors within the micro-electromagnetic environment cluster.

[0143] The second receiving state refers to the receiving state of each sensor in the same micro-electromagnetic environment cluster for its corresponding updated sub-data block.

[0144] In some embodiments, the sensor management platform can generate a second bitmap index based on the reception status of updated sub-data blocks of multiple sensors in a micro-electromagnetic environment cluster.

[0145] For example, each sensor generates a first bitmap index representing its first reception state. These first bitmap indices are then aggregated according to sensor ID or a certain order to form a composite bitmap representing the entire cluster, i.e., the second bitmap index. The aggregation can use AND or OR logic to concatenate the first bitmap indices of the individual sensors.

[0146] For example, the sensor management platform can pre-set an empty second bitmap index, and then send query requests to each sensor in the micro-electromagnetic environment cluster to obtain their second reception status for updating sub-data blocks. The obtained second reception status is then filled into the empty second bitmap index one by one to generate the final second bitmap index.

[0147] The second bitmap index explicitly indicates whether any sensor in the micro-electromagnetic environment cluster has failed to receive a specific update sub-data block.

[0148] In some embodiments, the sensor management platform retransmits updated sub-data blocks to multiple sensors based on the second bitmap index. In some embodiments, the sensor management platform first parses the second bitmap index to identify bitmap indexes in the micro-electromagnetic environment cluster where at least one sensor is set to 0, and forms a cluster-level missing list accordingly.

[0149] In some embodiments, the sensor management platform determines the missing update sub-data blocks for each sensor based on the bitmap index of the cluster-level missing list, then acquires these update sub-data blocks, packages them, and sends them all at once to the entire micro-electromagnetic environment cluster via broadcast or multicast. Sensors within the micro-electromagnetic environment cluster that have successfully received the data blocks can ignore the retransmitted data packets, while sensors that are truly missing update sub-data blocks can complete their data from this broadcast.

[0150] Some embodiments in this specification achieve edge-side collaborative optimization for retransmissions by dividing the micro-electromagnetic environment into clusters and obtaining a second bitmap index reflecting the common reception state within the cluster. This aggregates a large number of independent sensor retransmission requests into a small number of cluster-level requests, significantly reducing signaling overhead. The platform broadcasts or multicasts missing data blocks within the cluster, satisfying the needs of multiple sensors within the cluster in a single transmission, effectively solving the problem of mass packet loss caused by local interference.

[0151] Some embodiments in this specification accurately determine sensor update groups, update priorities, and update parameters by comprehensively considering sensor data characteristics, geographical location, task characteristics, transmission characteristics, firmware characteristics, and channel state distribution. This solution effectively shapes update traffic, significantly avoiding network congestion. Simultaneously, through intelligent batch and time-segmented sequential updates, it ensures that sensors in the same functional area do not fail simultaneously, fundamentally guaranteeing the continuity of critical monitoring services. Compared with traditional methods, this invention improves firmware update efficiency while effectively solving the problems of frequent network outages and service interruptions in large-scale industrial IoT.

[0152] Figure 4 This is an exemplary flowchart illustrating the adjustment of the update time of a sensor update group according to some embodiments of this specification. In some embodiments, such as Figure 4 As shown, process 400 may include the following steps: Step 410: Obtain multiple industrial zones.

[0153] An industrial zone refers to a physical area encompassing industrial grid zones, defined from a management perspective. For example, an industrial zone may contain multiple industrial grid zones for more macro-level management.

[0154] In some embodiments, the sensor management platform can directly read predefined area information from the area management configuration database to obtain multiple industrial areas.

[0155] In some embodiments, the sensor management platform can also acquire multiple industrial areas by reading electronic map configurations.

[0156] Step 420: Based on the task characteristics, data characteristics, and transmission characteristics of multiple sensor update groups in multiple industrial areas, determine at least one update test group.

[0157] An update test group refers to a subset of sensors that are preferentially selected for small-scale pilot firmware updates. For example, update test groups are used to verify the compatibility of firmware update packages and the stability of the update process before a full update.

[0158] In some embodiments, the method for determining at least one update test group is as follows: The task characteristics, data characteristics, and transmission characteristics of each sensor update group are normalized, weighted, and then one or more sensor update groups with the highest total scores are selected as the update test groups for the industrial area. Further explanation of task characteristics, data characteristics, and transmission characteristics can be found in [link to relevant documentation]. Figure 2 And its related descriptions.

[0159] In some embodiments, the sensor management platform can also use a rule engine to filter and determine update test groups based on threshold conditions corresponding to the task characteristics, data characteristics, and transmission characteristics of each sensor update group.

[0160] In some embodiments, the sensor management platform is further configured to: for each micro-electromagnetic environment cluster, determine the update test sensor based on the sub-task characteristics, sub-data characteristics, and sub-transmission characteristics of multiple sensors in the micro-electromagnetic environment cluster; and determine at least one update test group based on the update test sensors corresponding to the multiple micro-electromagnetic environment clusters.

[0161] Sub-data features refer to attributes that describe the data generation and transmission behavior of sensors within a micro-electromagnetic environment cluster. For example, if the data features describe the overall data acquisition behavior of multiple sensors within an industrial grid area or an industrial area, the sub-data features can be further refined into the data acquisition frequency or the amount of data uploaded per instance by the sensors within the micro-electromagnetic environment cluster.

[0162] Sub-transmission characteristics refer to parameters that measure a more granular or local stability of a sensor communication channel. For example, if transmission characteristics describe the overall stability of a sensor channel in an industrial network area or industrial region, sub-transmission characteristics can be further refined to describe the transmission stability of the sensor in a specific micro-electromagnetic environment.

[0163] For more information on data characteristics, transmission characteristics, and subtask characteristics, please refer to [link / reference]. Figure 2 And its related descriptions.

[0164] Update test sensors refer to sensors selected within a cluster of micro-electromagnetic environments for pilot firmware updates. For example, update test sensors might be sensors with optimal transmission characteristics, low task characteristic values, and non-critical data characteristics.

[0165] In some embodiments, the sensor management platform determines that updating the test sensor includes: First, select the sensors within each micro-electromagnetic environment cluster whose nucleus transmission characteristics satisfy the transmission conditions. Transmission conditions can include one of the following: most stable channel, lowest historical packet loss rate, or highest signal-to-noise ratio.

[0166] Based on this, sensors whose sub-task feature values ​​meet the feature conditions and whose sub-data features satisfy the data conditions (e.g., the generated data has little impact on the system) are further selected and identified as the sensors for update testing. Feature conditions may include task feature values ​​below a threshold, and data conditions may include the data acquisition behavior accounting for the smallest proportion of the total data acquisition in the entire system.

[0167] In some embodiments, the sensor management platform determines at least one update test group based on the update test sensors corresponding to multiple micro-electromagnetic environment clusters.

[0168] In some embodiments, determining at least one update test group includes: for each micro-electromagnetic environment cluster, if multiple update test sensors are determined in the cluster, then these multiple update test sensors are considered as one update test group. If only one update test sensor is determined in a micro-electromagnetic environment cluster, then that single update test sensor is considered as an independent update test group.

[0169] If there are more than a preset number of micro-electromagnetic environment clusters containing only one update test sensor, the sensor management platform can identify them as multiple update test groups according to the method for identifying multiple sensor update groups in step 210.

[0170] In some embodiments, the sensor management platform can also group multiple update test sensors based on preset business rules or manual configuration by the administrator, and determine multiple update test groups to meet specific test requirements or resource allocation strategies.

[0171] Some embodiments in this specification determine the sensors to be updated by meticulously considering the sub-tasks, sub-data, and sub-transmission characteristics of sensors for each micro-electromagnetic environment cluster, and flexibly construct update test groups based on these sensors. This allows the test groups to comprehensively cover the typical electromagnetic environment and sensor operating states within the area, thereby improving the representativeness and accuracy of firmware update testing. This approach effectively avoids the risk of misjudgment caused by a single test environment, ensuring that global firmware update decisions are more scientific and reliable.

[0172] Step 430: Send the firmware update package to at least one update test group and obtain the firmware update status of multiple sensors in at least one update test group.

[0173] Firmware update status refers to information reflecting the status and performance of the firmware update process. For example, firmware update status includes firmware metrics such as device reboot success rate and stability of the new firmware, as well as network metrics such as update time, number of retransmissions, and signal fluctuations during transmission.

[0174] In some embodiments, firmware update status can be obtained by an automated monitoring system proactively collecting metrics data from sensors in the update test group. For example, sensors may proactively report metrics such as device reboot success rate, stability of the new firmware, update time, signal fluctuations during transmission, and number of retransmissions.

[0175] In some embodiments, firmware update information can also be obtained in other ways. For example, by parsing log files uploaded by sensors using a log analysis system.

[0176] Step 440: Adjust the update time of multiple sensor update groups in multiple industrial areas according to the firmware update status.

[0177] In some embodiments, the sensor management platform can adjust the update time according to a predefined adjustment strategy.

[0178] For example, when firmware and network metrics are performing well (such as high device reboot success rate, stable operation of new firmware, short update time, and few retransmissions), the sensor management platform can accelerate the pace of subsequent updates and shorten the update interval between sensor update groups.

[0179] For example, when network metrics are poor (such as long update time and many retransmissions), it indicates network congestion. The sensor management platform can then increase the update interval for subsequent update batches.

[0180] For example, when firmware metrics are poor (such as low device restart success rate or poor operational stability), it indicates that the new firmware has defects, and the sensor management platform can pause or cancel subsequent sensor update groups.

[0181] In some embodiments, the update time can also be dynamically adjusted based on historical update data and the current network status.

[0182] Some embodiments in this specification involve initial updates using small-scale test groups to expose firmware defects or update strategy issues in advance. Subsequent update plans are dynamically adjusted based on the test results, enabling the update process to self-optimize. This significantly improves the reliability and security of firmware updates, avoids the systemic risks that could result from the widespread deployment of defective firmware, and thus reduces potential production interruptions and maintenance costs.

[0183] Some embodiments of this specification also provide a transiently readable computer storage medium for storing computer instructions, and a method for a computer to perform a remote firmware update for a sensor when the computer reads the computer instructions from the storage medium.

[0184] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the scope of the exemplary embodiments described herein.

[0185] Furthermore, certain features, structures, or characteristics in one or more embodiments of this specification may be appropriately combined.

[0186] Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, the numerical parameters should take into account specified significant digits and employ a general method of digit preservation. Although the numerical ranges and parameters used to confirm their breadth of range in some embodiments of this specification are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

[0187] If there is any inconsistency or conflict between the descriptions, definitions, and / or terms used in the materials referenced in this specification and the content described in this specification, the descriptions, definitions, and / or terms used in this specification shall prevail.

Claims

1. A large-scale IoT system for remote firmware updates of sensors, characterized in that, Includes a sensor management platform, which is configured to: Based on the data characteristics of multiple sensors and the geographical locations of the multiple sensors in the industrial grid area, multiple sensor update groups are determined; Based on the task characteristics and transmission characteristics of the multiple sensor update groups, the update priority of each sensor update group in the multiple sensor update groups is determined; The update parameters for the multiple sensor update groups are determined based on the update priority, firmware characteristics, and channel state distribution. Based on the update parameters, an update instruction and a firmware update package are generated, wherein the update instruction includes the update time; The update command and the firmware update package are sent to the perception control platform, and the multiple sensors in the multiple sensor update groups are controlled to perform firmware updates based on the update command.

2. The IoT large-scale model system according to claim 1, characterized in that, The sensor management platform is further configured to: According to a preset scale, the firmware update package is divided into multiple update sub-data blocks and sent to the perception and control platform; The multiple update sub-data blocks are transmitted to the multiple sensors via the perception and control platform; Obtain the first bitmap index returned by the plurality of sensors, the first bitmap index reflecting the first reception status of the plurality of updated sub-data blocks of a single sensor; The updated sub-data block is retransmitted to at least one of the plurality of sensors according to the first bitmap index.

3. The large-scale IoT model system according to claim 2, characterized in that, The sensor management platform is further configured to: For each of the plurality of updated sub-data blocks Based on the updated sub-data block, a verification code is determined using a preset verification algorithm; Based on the updated sub-data block and the verification code, a sub-update package is generated; The multiple sub-update packets corresponding to the multiple update sub-data blocks are sent to the perception control platform, wherein the multiple sub-update packets are used to determine the first bitmap index.

4. The large-scale IoT model system according to claim 1, characterized in that, The sensor management platform is further configured to: Acquire multiple industrial zones; Based on the task characteristics, data characteristics, and transmission characteristics of the multiple sensor update groups in the multiple industrial areas, at least one update test group is determined; The firmware update package is sent to the at least one update test group, and the firmware update status of multiple sensors in the at least one update test group is obtained; Based on the firmware update status, adjust the update time of the multiple sensor update groups in the multiple industrial areas.

5. A method for remote firmware update of a sensor, characterized in that, The sensor management platform of the IoT large-scale model system performs remote firmware updates for sensors, including: Based on the data characteristics of multiple sensors and the geographical locations of the multiple sensors in the industrial grid area, multiple sensor update groups are determined; Based on the task characteristics and transmission characteristics of the multiple sensor update groups, the update priority of each sensor update group in the multiple sensor update groups is determined; The update parameters for the multiple sensor update groups are determined based on the update priority, firmware characteristics, and channel state distribution. Based on the update parameters, an update instruction and a firmware update package are generated, wherein the update instruction includes the update time; The update command and the firmware update package are sent to the perception control platform, and the multiple sensors in the multiple sensor update groups are controlled to perform firmware updates based on the update command.

6. The method according to claim 5, characterized in that, The step of sending the update command and the firmware update package to the perception control platform, and controlling the multiple sensors in the multiple sensor update groups to perform firmware updates based on the update command, includes: According to a preset scale, the firmware update package is divided into multiple update sub-data blocks and sent to the perception and control platform; The multiple update sub-data blocks are transmitted to the multiple sensors via the perception and control platform; Obtain the first bitmap index returned by the plurality of sensors, the first bitmap index reflecting the first reception state of the updated sub-data block of a single sensor; The updated sub-data block is retransmitted to at least one of the plurality of sensors according to the first bitmap index.

7. The method according to claim 6, characterized in that, Further includes: For each of the plurality of updated sub-data blocks Based on the updated sub-data block, a verification code is determined using a preset verification algorithm; Based on the updated sub-data block and the verification code, a sub-update package is generated; The multiple sub-update packets corresponding to the multiple update sub-data blocks are sent to the perception control platform, wherein the multiple sub-update packets are used to determine the first bitmap index.

8. The method according to claim 5, characterized in that, Further includes: Acquire multiple industrial zones; Based on the task characteristics, data characteristics, and transmission characteristics of the multiple sensor update groups in the multiple industrial areas, at least one update test group is determined; The firmware update package is sent to the at least one update test group, and the firmware update status of multiple sensors in the at least one update test group is obtained; Based on the firmware update status, adjust the update time of the multiple sensor update groups in the multiple industrial areas.

9. A transiently readable computer storage medium for storing computer instructions, characterized in that, When the computer reads computer instructions from the storage medium, the computer executes the sensor remote firmware update method as described in any one of claims 5-8.

Images