Data management method of internet of things system and internet of things system

Abstract

The application provides a data management method of an Internet of Things system and the Internet of Things system. After an Internet of Things device obtains first device data generated by the device, the first device data is classified and cached, and redundant data is removed, so that second device data is refined. This step aims to reduce the amount of data and reduce the burden of subsequent processing. If the Internet of Things device abnormally operates, the system identifies and generates corresponding alarm data based on the second device data and a preset data alarm rule. According to an abnormal uploading rule, the alarm data and the device data generated by the operation of the Internet of Things device are subjected to lightweight processing, including filtering out inaccurate data, data that may be tampered with, and the like, so as to generate uploading data when the Internet of Things device abnormally operates, and avoid the situation that the network bandwidth is insufficient, the data transmission is delayed, and the cloud pressure is too large due to the sudden generation of the alarm data.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and more specifically, to a data management method for an IoT system and an IoT system. Background Technology

[0002] Existing IoT systems are integrating an increasing number of IoT devices, which upload massive amounts of data to cloud platforms. This data includes not only device status data and sensor data during normal operation, but also alarm data generated when devices malfunction. While the network bandwidth is designed to handle the device status and sensor data uploaded by all IoT devices during normal operation, it may fail to meet the upload demands of all devices when many malfunctions generate more abnormal data. When a large number of devices simultaneously generate abnormal alarm data, conventionally designed network bandwidth faces the risk of being overloaded. For example, the data volume of a single smart water meter malfunctioning can increase to 3-5 times its normal volume, while in industrial scenarios, the concurrent malfunction of over a hundred devices can lead to a data transmission latency increase of over 70%. This sudden surge in traffic far exceeds the capacity of conventional bandwidth design, potentially causing data packet loss rates to rise to 15%-20%. Furthermore, cloud platforms need to process device status data, sensor time-series data, and abnormal alarm data in parallel, and sudden bursts of abnormal data can cause cloud servers to exceed the redundancy thresholds of their conventional load designs. Summary of the Invention

[0003] The purpose of this application is to provide a data management method and an IoT system to solve the problems of insufficient network bandwidth, data transmission delay and excessive cloud pressure caused by sudden abnormal data generated by IoT devices.

[0004] This application provides a data management method for an Internet of Things (IoT) system, which includes IoT devices and a cloud platform.

[0005] The method is applied to Internet of Things (IoT) devices and includes:

[0006] Acquire the first device data generated by IoT devices;

[0007] The data from the first device is categorized and cached, and redundant data is removed to obtain the data from the second device.

[0008] Alarm data is obtained based on the data from the second device and the data alarm rules;

[0009] According to the abnormal upload rules, the data from the second device and the alarm data are lightweighted to obtain abnormal upload data, which is then sent to the cloud platform.

[0010] In the above technical solution, after acquiring the first device data generated by the IoT device, the system first categorizes and caches this data. During this process, redundant data is removed, refining the data into second device data. This step aims to reduce the data volume and lessen the burden on subsequent processing. If the IoT device malfunctions, based on the second device data and preset data alarm rules, the system will identify and generate corresponding alarm data. According to the abnormal upload rules, the suddenly generated alarm data, along with the device data generated during IoT device operation, undergoes lightweight processing, including filtering out inaccurate data caused by anomalies and potentially tampered data. This generates upload data for abnormal IoT device operation, reducing network load, data transmission latency, and alleviating the processing pressure on the cloud platform. This avoids situations where suddenly generated alarm data leads to insufficient network bandwidth, data transmission latency, and excessive cloud pressure.

[0011] Specifically, IoT devices first acquire the raw data generated during their operation, i.e., the initial device data. This data may include sensor readings, device status information, environmental parameters, etc.

[0012] The first set of equipment data is categorized and cached, meaning the data is stored according to different categories (such as temperature, humidity, pressure, etc.). During the categorization and caching process, redundant data, i.e., duplicate or invalid data, is removed, thereby obtaining refined second set of equipment data.

[0013] Based on data from the second device and preset alarm rules, the IoT device will identify and generate alarm data. These rules may be based on data thresholds, trends, or correlations with other data. When the data from the second device meets the alarm rules, the system will generate corresponding alarm information to indicate potential anomalies or problems with the device.

[0014] According to the abnormal upload rules, IoT devices perform lightweight processing on data from secondary devices and alarm data. Lightweighting may include data compression, extraction of key information, and filtering of inaccurate or potentially tampered data. The lightweighted data is called abnormal upload data, and it contains key information and alarm data from the IoT device's operation. The IoT device then sends the abnormal upload data to the cloud platform for further analysis and processing.

[0015] The IoT system data management method provided in this embodiment can effectively manage the data generated by IoT devices. In particular, when the device is running abnormally, it can quickly generate and upload key information to reduce network burden and cloud platform pressure, thereby improving the overall performance and stability of the system.

[0016] In some alternative implementations, prior to acquiring the first device data generated by the IoT device, the following steps are also included:

[0017] Receive abnormal upload rule templates and data alarm rule templates issued by the cloud platform. The abnormal upload rule templates and data alarm rule templates correspond to the industry and device type of the IoT device.

[0018] Configure abnormal upload rules for IoT devices based on the abnormal upload rule template; configure data alarm rules for IoT devices based on the data alarm rule template.

[0019] In the above technical solution, the cloud platform pre-defines and distributes abnormal upload rule templates and data alarm rule templates based on the industry (such as manufacturing, agriculture, environmental monitoring, etc.) and device type (such as sensors, smart meters, surveillance cameras, etc.) of the IoT devices. IoT devices receive these rule templates when starting up or updating their configuration. These templates typically contain a series of parameters and conditions to guide the device on how to identify abnormal data, how to generate alarm information, and how to lightweight and upload this data.

[0020] IoT devices configure specific abnormal upload rules based on the received abnormal upload rule template and their own characteristics and needs. These rules may include criteria for judging data anomalies, lightweight processing methods, and the format and frequency of uploaded data.

[0021] Similarly, IoT devices will also configure specific data alarm rules based on the data alarm rule template. These rules define which data changes or combinations will trigger alarms, as well as the generation method and content of alarm information.

[0022] In some optional implementations, after obtaining the second device data, the process further includes:

[0023] According to the data from the second device and the data alarm rules, no alarm data was obtained.

[0024] Based on the data from the second device and the normal upload rules, the normal upload data is obtained and sent to the cloud platform.

[0025] In the above technical solution, analysis is performed using data from a second device and preset data alarm rules. These alarm rules may be based on various factors such as device operating parameters, historical data trends, and preset thresholds. If the data from the second device does not trigger these alarm rules, meaning the data fluctuates within the normal range, no alarm data will be generated. In this case, since there is no sudden alarm data, the data can be processed directly according to normal upload rules, which include fixed data formats, transmission frequencies, and data compression or encryption requirements.

[0026] In some optional implementations, the second device data and alarm data are lightweighted according to the abnormal upload rules to obtain abnormal upload data, including:

[0027] Based on the first data type in the second device data corresponding to the alarm data, determine the second data type in the second device data related to the first data type;

[0028] In the second device data and alarm data, the data of the second type is filtered out to obtain the abnormal upload data.

[0029] In some alternative implementations, data anomalies of the first data type indicate inaccuracies in the data of the second data type, and data anomalies of the first data type include sensor malfunctions.

[0030] In the above technical solution, when an IoT device detects an anomaly, it generates alarm data. This alarm data is typically associated with a specific data type (i.e., the first data type), indicating that an anomaly has occurred in that type of data. In the operating environment of IoT devices, different data types may have interdependent or interdependent relationships. For example, a sensor malfunction (an anomaly in the first data type) may mean that other data dependent on that sensor's data (the second data type) is also inaccurate or invalid. After identifying the second data type associated with the alarm data, the IoT device filters out this second data type from both the second device data and the alarm data. This is to remove inaccurate or invalid data caused by anomalies in the first data type. After filtering, the IoT device uploads the remaining data as anomaly data. This data contains critical information about the device's operation while avoiding misleading or redundant information caused by data anomalies.

[0031] In some alternative implementations, data anomalies of the first data type indicate that data of the second data type has been tampered with. Data anomalies of the first data type include discontinuous values, timestamp anomalies, serial number anomalies, consistency anomalies, device behavior pattern anomalies, and tamper sensor triggering.

[0032] Among these issues, discontinuous values, meaning sudden and significant changes in data values ​​without a reasonable explanation or transition, are problematic. For example, if the ambient temperature detected by a temperature and humidity sensor abruptly changes from 10 degrees to 30 degrees, this is considered an anomaly, generating an alarm for temperature detection anomaly. Since this alarm data corresponds to the ambient temperature of the temperature and humidity sensor, and the ambient humidity is correlated with it, there is a risk that the ambient humidity could be tampered with. Therefore, the ambient humidity data is filtered out.

[0033] Timestamp error: The timestamp of the data does not match the actual situation, such as time jump, duplication, or missing.

[0034] Serial number anomaly: Discontinuous or repeated serial numbers in the data indicate that the data may have been tampered with or lost.

[0035] Inconsistency anomaly: Inconsistency between data from the same data source or different data sources, such as sensor readings not matching other sensor or environmental parameters.

[0036] Abnormal device behavior: Devices operating in ways that deviate from normal patterns may indicate malicious control or data tampering. For example, if the frequency or format of data uploaded by a sensor differs from normal patterns, an abnormal sensor alarm will be generated. Since the sensor corresponding to this alarm data is associated with its sensing value, the sensor's sensing value will be filtered out.

[0037] Tamper sensor trigger: This indicates that the device may have been illegally opened or disassembled, increasing the risk of data tampering. For example, if a tamper sensor trigger alarm is generated, then all other data uploaded by the IoT device, except for the tamper sensor trigger alarm data, will be filtered out.

[0038] In the above technical solution, when an IoT device detects data anomalies, it generates alarm data. This alarm data is associated with a specific data type (i.e., the first data type), indicating that this type of data may have experienced anomalies. In an IoT system, different data types may have logical connections or dependencies. If the first data type experiences anomalies, this may mean that other data types that depend on it (i.e., the second data type) are at risk of being tampered with.

[0039] In some optional implementations, the second device data and alarm data are lightweighted according to the abnormal upload rules to obtain abnormal upload data, including:

[0040] The alarm priority is determined based on the severity and importance coefficients of the alarm data;

[0041] Determine the upload frequency of abnormal data based on alarm priority.

[0042] In the above technical solution, alarm priority is determined based on two key coefficients: severity coefficient and importance coefficient. These two coefficients reflect the urgency of the alarm situation and its importance to the entire system or process, respectively. The severity coefficient may be based on a preset threshold or algorithm to determine the severity of the problem indicated by the alarm, such as equipment failure or data anomaly; while the importance coefficient may consider the importance of the equipment, process, or data involved in the alarm within the overall system. Combining these two coefficients, a priority can be assigned to each alarm, with higher priority indicating that the alarm needs to be responded to and processed more quickly. Next, based on the determined alarm priority, the upload frequency of abnormal data uploads is further determined. High-priority alarms require more frequent uploads to ensure that the problem can be quickly detected and resolved; while low-priority alarms have a lower upload frequency to reduce data transmission load without ignoring any potential problems. This priority-based upload frequency adjustment can optimize data transmission efficiency while ensuring timely response to problems.

[0043] This application provides an Internet of Things (IoT) system, which includes IoT devices and a cloud platform.

[0044] IoT devices include: a data acquisition module, a data analysis module, an alarm module, and an upload logic module;

[0045] The data acquisition module is used to: acquire the first device data generated by IoT devices;

[0046] The data analysis module is used to: classify and cache the data from the first device, remove redundant data, and obtain the data from the second device;

[0047] The alarm module is used to: obtain alarm data based on the data from the second device and the data alarm rules;

[0048] The upload logic module is used to: quantize the data from the second device and alarm data according to the abnormal upload rules, obtain the abnormal upload data, and send the abnormal upload data to the cloud platform.

[0049] An electronic device provided in this application includes a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the machine-readable instructions, when executed by the processor, perform any of the methods described above.

[0050] This application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of any of the methods described above. Attached Figure Description

[0051] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 A flowchart illustrating the steps of a data management method for an Internet of Things (IoT) system provided in this application embodiment;

[0053] Figure 2 A functional block diagram of an Internet of Things (IoT) system provided in this application embodiment;

[0054] Figure 3 This application illustrates one possible structure of an electronic device provided in an embodiment of the present application. Detailed Implementation

[0055] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0056] Please refer to Figure 1 , Figure 1 This application provides a flowchart of a data management method for an Internet of Things (IoT) system, which includes IoT devices and a cloud platform.

[0057] The method is applied to Internet of Things (IoT) devices and includes:

[0058] Step 100: Obtain the first device data generated by the IoT device;

[0059] Step 200: Classify and cache the data from the first device, and remove redundant data to obtain the data from the second device;

[0060] Step 300: Obtain alarm data based on the data from the second device and the data alarm rules;

[0061] Step 400: According to the abnormal upload rules, the data of the second device and the alarm data are lightweighted to obtain abnormal upload data, and the abnormal upload data is sent to the cloud platform.

[0062] In this embodiment, after acquiring the first device data it generates, the IoT device first categorizes and caches this data. During this process, redundant data is removed, refining the data into second device data. This step aims to reduce the data volume and lessen the burden on subsequent processing. If the IoT device malfunctions, the system identifies and generates corresponding alarm data based on the second device data and preset data alarm rules. According to the abnormal upload rules, the suddenly generated alarm data, along with the device data generated by the IoT device, undergoes lightweight processing, including filtering out inaccurate data caused by abnormalities and potentially tampered data. This generates upload data for abnormal IoT device operation, reducing network load, data transmission latency, and alleviating the processing pressure on the cloud platform. It also avoids situations where suddenly generated alarm data leads to insufficient network bandwidth, data transmission latency, and excessive cloud pressure.

[0063] Specifically, IoT devices first acquire the raw data generated during their operation, i.e., the initial device data. This data may include sensor readings, device status information, environmental parameters, etc.

[0064] The first set of equipment data is categorized and cached, meaning the data is stored according to different categories (such as temperature, humidity, pressure, etc.). During the categorization and caching process, redundant data, i.e., duplicate or invalid data, is removed, thereby obtaining refined second set of equipment data.

[0065] Based on data from the second device and preset alarm rules, the IoT device will identify and generate alarm data. These rules may be based on data thresholds, trends, or correlations with other data. When the data from the second device meets the alarm rules, the system will generate corresponding alarm information to indicate potential anomalies or problems with the device.

[0066] According to the abnormal upload rules, IoT devices perform lightweight processing on data from secondary devices and alarm data. Lightweighting may include data compression, extraction of key information, and filtering of inaccurate or potentially tampered data. The lightweighted data is called abnormal upload data, and it contains key information and alarm data from the IoT device's operation. The IoT device then sends the abnormal upload data to the cloud platform for further analysis and processing.

[0067] The IoT system data management method provided in this embodiment can effectively manage the data generated by IoT devices. In particular, when the device is running abnormally, it can quickly generate and upload key information to reduce network burden and cloud platform pressure, thereby improving the overall performance and stability of the system.

[0068] In some alternative implementations, prior to acquiring the first device data generated by the IoT device, the following steps are also included:

[0069] Receive abnormal upload rule templates and data alarm rule templates issued by the cloud platform. The abnormal upload rule templates and data alarm rule templates correspond to the industry and device type of the IoT device.

[0070] Configure abnormal upload rules for IoT devices based on the abnormal upload rule template; configure data alarm rules for IoT devices based on the data alarm rule template.

[0071] In this embodiment, the cloud platform pre-defines and distributes abnormal upload rule templates and data alarm rule templates based on the industry (e.g., manufacturing, agriculture, environmental monitoring) and device type (e.g., sensors, smart meters, surveillance cameras). IoT devices receive these rule templates upon startup or configuration updates. These templates typically contain a series of parameters and conditions to guide the device on how to identify abnormal data, how to generate alarm information, and how to lightweight and upload this data.

[0072] IoT devices configure specific abnormal upload rules based on the received abnormal upload rule template and their own characteristics and needs. These rules may include criteria for judging data anomalies, lightweight processing methods, and the format and frequency of uploaded data.

[0073] Similarly, IoT devices will also configure specific data alarm rules based on the data alarm rule template. These rules define which data changes or combinations will trigger alarms, as well as the generation method and content of alarm information.

[0074] In some optional implementations, after obtaining the second device data, the process further includes:

[0075] According to the data from the second device and the data alarm rules, no alarm data was obtained.

[0076] Based on the data from the second device and the normal upload rules, the normal upload data is obtained and sent to the cloud platform.

[0077] In this embodiment, analysis is performed using data from a second device and preset data alarm rules. These alarm rules may be based on various factors such as device operating parameters, historical data trends, and preset thresholds. If the second device data does not trigger these alarm rules, meaning the data fluctuates within a normal range, no alarm data will be generated. In this case, since there is no sudden alarm data, the data can be processed directly according to normal upload rules, which include fixed data formats, transmission frequencies, and data compression or encryption requirements.

[0078] In some optional implementations, the second device data and alarm data are lightweighted according to the abnormal upload rules to obtain abnormal upload data, including:

[0079] Based on the first data type in the second device data corresponding to the alarm data, determine the second data type in the second device data related to the first data type;

[0080] In the second device data and alarm data, the data of the second type is filtered out to obtain the abnormal upload data.

[0081] In some alternative implementations, data anomalies of the first data type indicate inaccuracies in the data of the second data type, and data anomalies of the first data type include sensor malfunctions.

[0082] In this embodiment, when an IoT device detects an anomaly, it generates alarm data. This alarm data is typically associated with a specific data type (i.e., a first data type), indicating that an anomaly has occurred in that type of data. In the operating environment of an IoT device, different data types may have interdependent or interdependent relationships. For example, a sensor malfunction (an anomaly in the first data type) may mean that other data dependent on that sensor's data (a second data type) is also inaccurate or invalid. After identifying the second data type associated with the alarm data, the IoT device filters out this second data type from both the second device data and the alarm data. This is to remove inaccurate or invalid data caused by anomalies in the first data type. After filtering, the IoT device uploads the remaining data as anomaly data. This data contains critical information about the device's operation while avoiding misleading or redundant information caused by data anomalies.

[0083] In some alternative implementations, data anomalies of the first data type indicate that data of the second data type has been tampered with. Data anomalies of the first data type include discontinuous values, timestamp anomalies, serial number anomalies, consistency anomalies, device behavior pattern anomalies, and tamper sensor triggering.

[0084] Among these issues, discontinuous values, meaning sudden and significant changes in data values ​​without a reasonable explanation or transition, are problematic. For example, if the ambient temperature detected by a temperature and humidity sensor abruptly changes from 10 degrees to 30 degrees, this is considered an anomaly, generating an alarm for temperature detection anomaly. Since this alarm data corresponds to the ambient temperature of the temperature and humidity sensor, and the ambient humidity is correlated with it, there is a risk that the ambient humidity could be tampered with. Therefore, the ambient humidity data is filtered out.

[0085] Timestamp error: The timestamp of the data does not match the actual situation, such as time jump, duplication, or missing.

[0086] Serial number anomaly: Discontinuous or repeated serial numbers in the data indicate that the data may have been tampered with or lost.

[0087] Inconsistency anomaly: Inconsistency between data from the same data source or different data sources, such as sensor readings not matching other sensor or environmental parameters.

[0088] Abnormal device behavior: Devices operating in ways that deviate from normal patterns may indicate malicious control or data tampering. For example, if the frequency or format of data uploaded by a sensor differs from normal patterns, an abnormal sensor alarm will be generated. Since the sensor corresponding to this alarm data is associated with its sensing value, the sensor's sensing value will be filtered out.

[0089] Tamper sensor trigger: This indicates that the device may have been illegally opened or disassembled, increasing the risk of data tampering. For example, if a tamper sensor trigger alarm is generated, then all other data uploaded by the IoT device, except for the tamper sensor trigger alarm data, will be filtered out.

[0090] In this embodiment, when an IoT device detects data anomalies, it generates alarm data. This alarm data is associated with a specific data type (i.e., a first data type), indicating that this type of data may have experienced anomalies. In an IoT system, different data types may have logical connections or dependencies. If the first data type experiences anomalies, this may mean that other data types that depend on it (i.e., a second data type) are at risk of being tampered with.

[0091] In some optional implementations, the second device data and alarm data are lightweighted according to the abnormal upload rules to obtain abnormal upload data, including:

[0092] The alarm priority is determined based on the severity and importance coefficients of the alarm data;

[0093] Determine the upload frequency of abnormal data based on alarm priority.

[0094] In this embodiment, alarm priority is determined based on two key coefficients: a severity coefficient and a importance coefficient. These two coefficients reflect the urgency of the alarm and its importance to the entire system or process, respectively. The severity coefficient may be based on a preset threshold or algorithm to determine the severity of the problem indicated by the alarm, such as equipment failure or data anomaly; while the importance coefficient may consider the importance of the equipment, process, or data involved in the alarm within the overall system. Combining these two coefficients, each alarm can be assigned a priority; the higher the priority, the faster the alarm needs to be responded to and processed. Next, based on the determined alarm priority, the upload frequency of abnormal data uploads is further determined. High-priority alarms require more frequent uploads to ensure that the problem can be quickly detected and resolved; while low-priority alarms have a lower upload frequency to reduce data transmission load without ignoring any potential problems. This priority-based upload frequency adjustment can optimize data transmission efficiency while ensuring timely response to problems.

[0095] Please refer to Figure 2 , Figure 2 This application provides a functional block diagram of an Internet of Things (IoT) system, which includes IoT devices and a cloud platform.

[0096] IoT devices include: a data acquisition module, a data analysis module, an alarm module, and an upload logic module;

[0097] The data acquisition module is used to: acquire the first device data generated by IoT devices;

[0098] The data analysis module is used to: classify and cache the data from the first device, remove redundant data, and obtain the data from the second device;

[0099] The alarm module is used to: obtain alarm data based on the data from the second device and the data alarm rules;

[0100] The upload logic module is used to: quantize the data from the second device and alarm data according to the abnormal upload rules, obtain the abnormal upload data, and send the abnormal upload data to the cloud platform.

[0101] Figure 3 This illustration shows a possible structure of an electronic device provided in an embodiment of this application. (Refer to...) Figure 3 The electronic device includes a processor, memory, and a communication interface, which are interconnected and communicate with each other via a communication bus and / or other forms of connection mechanism (not shown).

[0102] The memory includes one or more (only one is shown in the figure), which may be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The processor and other possible components can access the memory, reading and / or writing data therein.

[0103] The processor comprises one or more (only one is shown in the figure), which can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Microcontroller Unit (MCU), a Network Processor (NP), or other conventional processors; or it can be a special-purpose processor, including a Neural-network Processing Unit (NPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Furthermore, when there are multiple processors, some can be general-purpose processors, and others can be special-purpose processors.

[0104] The communication interface includes one or more (only one is shown in the figure), which can be used to communicate directly or indirectly with other devices to exchange data. The communication interface may include interfaces for wired and / or wireless communication.

[0105] One or more computer program instructions may be stored in the memory, and the processor may read and execute these computer program instructions to implement the methods provided in the embodiments of this application.

[0106] Understandable. Figure 3 The structure shown is for illustrative purposes only; the electronic device may also include structures that are more complex than those shown. Figure 3 The more or fewer components shown, or having the same Figure 3 The different structures shown. Figure 3 The components shown can be implemented using hardware, software, or a combination thereof. Electronic devices may be physical devices, such as PCs, laptops, tablets, mobile phones, servers, embedded devices, etc., or they may be virtual devices, such as virtual machines, virtualized containers, etc. Furthermore, electronic devices are not limited to a single device; they can also be a combination of multiple devices or a cluster of a large number of devices.

[0107] This application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of any of the methods described above.

[0108] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0109] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0110] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0111] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0112] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A data management method for an Internet of Things (IoT) system, characterized in that, The Internet of Things (IoT) system includes IoT devices and a cloud platform; The method is applied to the Internet of Things (IoT) device, and the method includes: Data acquisition module: Acquires the first device data generated by the IoT device; Data analysis module: Classifies and caches the data from the first device, removes redundant data, and obtains the data from the second device; Alarm module: Obtains alarm data based on data from the second device and data alarm rules; Upload logic module: Based on the abnormal upload rules, the data of the second device and the alarm data are lightweighted to obtain abnormal upload data, and the abnormal upload data is sent to the cloud platform; The step of lightweighting the second device data and alarm data according to the abnormal upload rules to obtain abnormal upload data includes: Based on the first data type in the second device data corresponding to the alarm data, determine the second data type in the second device data related to the first data type; In the second device data and alarm data, the data of the second type is filtered out to obtain the abnormal upload data; The data anomaly of the first data type indicates that the data of the second data type is inaccurate, and the data anomaly of the first data type includes sensor failure; Alternatively, the data anomaly of the first data type indicates that the data of the second data type has been tampered with. The data anomaly of the first data type includes discontinuous values, timestamp anomalies, serial number anomalies, consistency anomalies, device behavior pattern anomalies, and tamper sensor triggering.

2. The method as described in claim 1, characterized in that, Before acquiring the first device data generated by the IoT device, the method further includes: The system receives abnormal upload rule templates and data alarm rule templates issued by the cloud platform. The abnormal upload rule templates and data alarm rule templates correspond to the industry and device type of the IoT device. Configure abnormal upload rules for IoT devices according to the abnormal upload rule template; configure data alarm rules for IoT devices according to the data alarm rule template.

3. The method as described in claim 1, characterized in that, After obtaining the data from the second device, it also includes: According to the data from the second device and the data alarm rules, no alarm data was obtained. Based on the data from the second device and the normal upload rules, normal upload data is obtained and sent to the cloud platform.

4. The method as described in claim 1, characterized in that, The step of lightweighting the second device data and alarm data according to the abnormal upload rules to obtain abnormal upload data includes: The alarm priority is determined based on the severity and importance coefficients of the alarm data; Determine the upload frequency of abnormal data based on alarm priority.

5. An Internet of Things (IoT) system, characterized in that, The Internet of Things (IoT) system includes IoT devices and a cloud platform; The IoT device includes: a data acquisition module, a data analysis module, an alarm module, and an upload logic module; The data acquisition module is used to: acquire first device data generated by the IoT device; The data analysis module is used to: classify and cache the first device data, and remove redundant data to obtain the second device data; The alarm module is used to: obtain alarm data based on the second device data and the data alarm rules; The upload logic module is used to: weight the second device data and alarm data according to abnormal upload rules to obtain abnormal upload data, and send the abnormal upload data to the cloud platform; the weighting of the second device data and alarm data according to abnormal upload rules to obtain abnormal upload data includes: Based on the first data type in the second device data corresponding to the alarm data, determine the second data type in the second device data related to the first data type; In the second device data and alarm data, the data of the second type is filtered out to obtain the abnormal upload data; The data anomaly of the first data type indicates that the data of the second data type is inaccurate, and the data anomaly of the first data type includes sensor failure; Alternatively, the data anomaly of the first data type indicates that the data of the second data type has been tampered with. The data anomaly of the first data type includes discontinuous values, timestamp anomalies, serial number anomalies, consistency anomalies, device behavior pattern anomalies, and tamper sensor triggering.

6. An electronic device, characterized in that, include: A processor and a memory, the memory storing machine-readable instructions executable by the processor, which, when executed by the processor, perform the method as described in any one of claims 1-4.

7. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1-4.

Images