A machine learning based internet of things device risk response method and system

Abstract

This invention relates to the field of IoT device operation and maintenance technology, and discloses a machine learning-based IoT device risk response method and system. The method includes acquiring raw alarm data from IoT devices and historical operation records from administrators; extracting and generating operation preference vectors; filtering irrelevant alarms based on the vectors and recombining them to generate customized alarm reports containing risk blocking instructions; real-time sensing of the network status of the administrator's mobile terminal; extracting core semantics and compressing them to generate simplified alarm reports in weak network environments; constructing a weighted directed graph by combining real-time network signal attenuation rate and physical topology; solving for the optimal target transmission path; pushing alarms along the path and recording the results to update the operation records. This method can achieve accurate response and efficient push of IoT device risks, meeting the core requirements of real-time and effective device security management in complex operation and maintenance scenarios.

Description

Technical Field

[0001] This invention relates to the field of IoT device operation and maintenance technology, and in particular to a risk response method and system for IoT devices based on machine learning. Background Technology

[0002] Currently, in the field of IoT device operation and maintenance technology, intelligent response to device risks, as a key link in ensuring device safety and avoiding potential system operation hazards, has become a key research topic in the field.

[0003] In a current technology, a combination of static rule threshold filtering and fixed route push is typically used for risk alerts on IoT devices. However, this technical solution has the following specific drawbacks in actual complex operations and maintenance: On the one hand, the generation of alert content lacks the ability to learn from the administrator's historical operation preferences. When faced with massive concurrent alerts from underlying devices, all alert data is pushed in full using a generic template, leading to severe alerts for administrators, and critical risk blocking instructions that truly require priority handling are easily overwhelmed by redundant information. On the other hand, in mobile operations and maintenance scenarios, the fixed route and uniform data volume push method cannot perceive the real-time network bandwidth and link physical status of mobile terminals. When operations and maintenance personnel are in a weak network environment with high signal attenuation or high congestion, the push of high-priority risk blocking instructions is easily severely delayed or even lost due to excessively large alert data packets or congested routing nodes.

[0004] In summary, existing technologies are insufficient to achieve accurate response and efficient push notification of risks to IoT devices, and cannot meet the core requirements of IoT operation and maintenance technology for real-time and effective device security management in complex operation and maintenance scenarios. Summary of the Invention

[0005] This invention provides a machine learning-based method and system for risk response of IoT devices, enabling accurate response and efficient push notification of IoT device risks, and meeting the core requirements of IoT operation and maintenance technology for real-time and effective device security management in complex operation and maintenance scenarios.

[0006] Firstly, to address the aforementioned technical problems, this invention provides a machine learning-based risk response method for IoT devices, comprising:

[0007] Obtain raw alarm data from IoT devices and historical operation records from administrators; perform feature extraction processing on the raw alarm data and historical operation records to obtain an operation preference vector.

[0008] Based on the operation preference vector, the original alarm data is subjected to content filtering and logical reorganization to generate a risk priority sequence, and a customized alarm report containing risk blocking instructions is obtained based on the risk priority sequence.

[0009] The system obtains the real-time network bandwidth and network latency values ​​from the administrator's mobile terminal, compares the real-time network bandwidth value with a preset bandwidth benchmark threshold, compares the network latency value with a preset latency judgment threshold, and determines the network status based on the comparison results to obtain a network status identifier.

[0010] If the network status is identified as a weak network, then the customized alarm report is compressed to obtain a simplified alarm report.

[0011] The system obtains the real-time signal attenuation rate and physical topology of the current network, performs path planning based on the real-time signal attenuation rate and physical topology to obtain the target transmission path, sends the simplified alarm report to the mobile terminal along the target transmission path, and obtains the push result of the risk blocking command.

[0012] Secondly, the present invention provides a machine learning-based Internet of Things (IoT) device risk response system, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described above.

[0013] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0014] Compared with the prior art, the present invention has the following beneficial effects:

[0015] (1) This invention obtains the original alarm data of IoT devices and the historical operation records of administrators, calculates the feature weight coefficients after standardization, and generates an operation preference vector. Based on the similarity between the vector and the alarm records, the content is filtered, and then a customized alarm report containing risk blocking instructions is generated according to the risk controllability logic. This invention breaks through the limitations of traditional fixed process alarms and general templates that cannot adapt to the individual operation differences of administrators. It explores the response habits and handling preferences of administrators, automatically removes irrelevant alarms that do not conform to the operation habits, reconstructs the risk priority sequence, and provides administrators with accurate matching handling suggestions. This invention effectively solves the problems of alarm information overload and handling suggestions that are out of touch with actual needs, and significantly improves the pertinence and processing efficiency of alarm information.

[0016] (2) This invention collects the network bandwidth and latency values ​​of the administrator's mobile terminal in real time, and determines the network status by combining the preset threshold. Under weak network conditions, it extracts the core semantic text of the customized alarm report, removes redundant fields and multimedia redundant data to generate a simplified alarm report, breaks through the limitations of traditional unified content push and ignores network environment restrictions, dynamically adjusts the volume and presentation form of alarm content according to real-time network conditions, and significantly compresses the data volume while retaining core risk information, ensuring that alarm information can be transmitted quickly under weak network conditions, solving the problem of slow alarm loading and reception failure under complex network conditions, and ensuring the timeliness of information transmission in mobile operation and maintenance scenarios.

[0017] (3) This invention obtains the real-time signal attenuation rate and physical topology of the current network, constructs a weighted directed graph model and updates the edge weights in combination with the signal attenuation rate, solves the shortest path to obtain the target transmission path, sends a simplified alarm report along the path and records the push results to update the historical operation record, breaks through the limitations of traditional single transmission path and lack of dynamic path optimization capability, accurately avoids high attenuation and high congestion links, and continuously optimizes the operation preference model through feedback mechanism, significantly improving the success rate of risk blocking command push and response real-time performance, meeting the core requirements of real-time and effective security management in complex operation and maintenance scenarios of large-scale IoT device clusters. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of a machine learning-based risk response method for IoT devices provided in the first embodiment of the present invention; Detailed Implementation

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

[0020] Reference Figure 1 The first embodiment of the present invention provides a risk response method for Internet of Things (IoT) devices based on machine learning, comprising the following steps:

[0021] S101, Obtain the original alarm data of the IoT device and the historical operation record of the administrator, and perform feature extraction processing on the original alarm data and the historical operation record to obtain the operation preference vector;

[0022] S102, perform content filtering and logical reorganization on the original alarm data according to the operation preference vector to generate a risk priority sequence, and obtain a customized alarm report containing risk blocking instructions according to the risk priority sequence;

[0023] S103, obtain the real-time network bandwidth value and network latency value of the administrator's mobile terminal, compare the real-time network bandwidth value with a preset bandwidth benchmark threshold, compare the network latency value with a preset latency judgment threshold, and determine the network status based on the comparison results to obtain a network status identifier.

[0024] S104, If the network status identifier is a weak network status, then perform text compression processing on the customized alarm report to obtain a simplified alarm report;

[0025] S105, obtain the real-time signal attenuation rate and physical topology of the current network, perform path planning based on the real-time signal attenuation rate and physical topology to obtain the target transmission path, send the simplified alarm report to the mobile terminal along the target transmission path, and obtain the push result of the risk blocking command.

[0026] In step S101, the process of acquiring the original alarm data of the IoT device and the historical operation records of the administrator, and performing feature extraction processing on the original alarm data and the historical operation records to obtain an operation preference vector includes:

[0027] Obtain raw alarm data from IoT devices and historical operation records from administrators;

[0028] The original alarm data and the historical operation records are standardized to obtain a standardized dataset;

[0029] The feature weights are calculated on the standardized dataset to obtain the feature weight coefficients;

[0030] The standardized dataset is subjected to feature fusion processing based on the feature weight coefficients to obtain the operation preference vector.

[0031] It should be noted that, firstly, raw alarm data from IoT devices and historical operation records from administrators are acquired. Raw alarm data is automatically retrieved from the edge gateway via a message queue telemetry transmission protocol, with a collection frequency consistent with the device reporting frequency of once per minute. The collected fields include four core features: alarm type, risk level, device type, and historical processing success rate, as well as auxiliary fields such as the device's unique identifier, trigger time, real-time device load rate, voltage fluctuation amplitude, and temperature value, used for subsequent priority ranking and anomaly backtracking analysis. Only the alarm type, risk level, device type, and historical processing success rate are used in the generation of operation preference vectors and similarity calculations; the other auxiliary fields are not included in the preference learning process. The data time range is fixed at the past 30 days to ensure coverage of the complete device operation cycle. Administrator historical operation records are extracted from the operations and maintenance management database, and the extracted fields include operation type, response time, processing result, operation execution time, and corresponding alarm number. The data time range is fixed at the past 6 months to fully reflect the administrator's long-term operating habits. The data collection process automatically performs data cleaning, removing duplicate and invalid records. Missing numerical fields are filled with the average value of the same type of device during the same period, and missing categorical fields are filled with the category that appears most frequently.

[0032] Next, the original alarm data and the historical operation records are standardized to obtain a standardized dataset. The standardization process uses standard deviation standardization to transform all numerical features into dimensionless values. The transformation process first calculates the mean and standard deviation of each feature, then subtracts the mean from each feature value and divides by the standard deviation, mapping all numerical features to a distribution range with a mean of 0 and a standard deviation of 1. For categorical features such as alarm type and operation type, one-hot encoding is used to convert them into binary numerical vectors, with each category corresponding to an independent dimension. After standardization, the value range of all features is unified, eliminating the influence of different dimensions on subsequent calculations. After processing, the dataset is validated for completeness to ensure that all fields are intact. Data that passes the validation is then stored in the standardized dataset.

[0033] Secondly, feature weights are calculated on the standardized dataset to obtain feature weight coefficients. The feature weight calculation is implemented using the random forest algorithm. The training set consists of 10,000 labeled operation samples, covering 12 common IoT device types and 8 typical risk scenarios. The samples include normal operation records and abnormal operation records in a 9:1 ratio. The model uses 100 decision trees, each with a maximum depth of 10 and a minimum number of splits of 5. Gini impurity is used as the node splitting criterion. The training process employs 5-fold cross-validation, randomly dividing the training set into 5 subsets. The model is trained using 4 subsets in turn, and the stability of feature importance is verified using 1 subset. Training stops when the feature importance fluctuation is less than 0.001 after 5 consecutive rounds of verification, with a maximum of 50 rounds of training. The weight coefficient of each feature is obtained by calculating the average decrease in the Gini coefficient across all decision trees. For example, the weighting coefficient for average response time is 0.42, the weighting coefficient for remote load reduction operation preference is 0.58, the weighting coefficient for equipment type preference is 0.35, and the weighting coefficient for risk level sensitivity is 0.45. All weighting coefficients can be adjusted within the range of 0.9 to 1.1 times the baseline value. The average decrease in the Gini coefficient initially calculated by the random forest algorithm is set as the basic baseline value for adjusting the weights of each feature, in order to adapt to the operating habits of different operation and maintenance teams.

[0034] Subsequently, feature fusion processing is performed on the standardized dataset according to the feature weight coefficients to obtain an operation preference vector. The feature fusion process multiplies each standardized feature value by its corresponding weight coefficient, and then concatenates them into a 128-dimensional floating-point vector in a preset order. Each dimension of the vector corresponds to a specific operation preference feature: the first 32 dimensions correspond to alarm type preference, the middle 64 dimensions correspond to operation type preference, and the last 32 dimensions correspond to response time and processing success rate preference. The vector's numerical range is -1 to 1; the closer the value is to 1, the higher the administrator's preference for that feature, and the closer it is to -1, the lower the preference. After the operation preference vector is generated, its magnitude is automatically calculated and normalized to ensure the accuracy of subsequent similarity calculations.

[0035] It's worth noting that the operation preference vector is updated every 24 hours. Every day at midnight, the system automatically extracts the previous day's operation records, re-executes the standardization, weight calculation, and feature fusion processes, and updates the administrator's operation preference vector. When an administrator's operation records exceed 100 within 24 hours, or when the distribution of operation types changes significantly, the system immediately triggers a temporary update to ensure the vector reflects the administrator's latest operating habits in real time. Adjustments to the weight coefficients must be validated, and after adjustment, testing must be conducted on no fewer than 1000 historical samples to ensure that the accuracy of alarm filtering is not lower than the level before the adjustment.

[0036] In step S102, the step of performing content filtering and logical reorganization on the original alarm data according to the operation preference vector to generate a risk priority sequence, and obtaining a customized alarm report containing risk blocking instructions based on the risk priority sequence, includes:

[0037] Calculate the similarity value between the operation preference vector and each record in the original alarm data;

[0038] The similarity value is compared with a preset similarity threshold;

[0039] If the similarity value is lower than the similarity threshold, the corresponding alarm record is removed to obtain filtered alarm data.

[0040] The filtered alarm data is sorted by priority to generate a risk priority sequence;

[0041] Generate a customized alarm report containing risk blocking instructions based on the risk priority sequence.

[0042] It should be noted that the logical reorganization described in this method refers to reorganizing the presentation order and correlation structure of the filtered and retained alarm records according to the principle of risk controllability. This includes merging multiple related alarms from the same device into a single composite alarm; folding alarm pairs with clear causal relationships, such as a voltage drop followed by an undervoltage alarm, into a single alarm event; rearranging alarm entries according to priority sequence from high to low, and inserting predefined separators and risk level labels between adjacent high-risk alarms, etc., to meet the administrator's reading habits and operational priorities.

[0043] First, the similarity score between the operation preference vector and each record in the original alarm data is calculated. Four types of features are extracted from the original alarm data: alarm type, risk level, device type, and historical processing success rate. All features are subjected to min-max normalization, mapping them to the range of 0 to 1. To address the issue of data dimensionality mismatch, the four normalized initial features are concatenated and input into a pre-trained multilayer perceptron network for nonlinear spatial mapping. This multilayer perceptron network consists of one input layer, two hidden layers, and one output layer. The number of neurons in the input layer is set to 4 to accommodate the four initial features. The number of neurons in the two hidden layers is set to 32 and 64 respectively, and a ReLU activation function with nonlinear rectification characteristics is uniformly used to enhance the network's ability to fit complex high-dimensional mapping relationships. The number of neurons in the output layer is strictly set to 128, and a linear mapping without activation is used, thereby outputting a 128-dimensional alarm feature vector that is strictly aligned with the dimension of the operation preference vector. Similarity calculation employs the cosine similarity algorithm, which performs a dot product operation on the 128-dimensional operation preference vector and the feature vector of the transformed 128-dimensional alarm record, and then divides by the product of the magnitudes of the two vectors. The calculation process iterates through the original alarm data line by line to obtain the similarity value corresponding to each record, with the value ranging from 0 to 1. The larger the value, the higher the matching degree with the operation preference.

[0044] For example, the similarity of 5,000 original alarm records was calculated one by one, and the values ​​ranged from 0.32 to 0.91, of which 2,300 records had similarity values ​​below 0.75.

[0045] Next, the similarity value is compared with a preset similarity threshold. The preset similarity threshold is determined through a grid search on a historical dataset. Content filtering and subsequent alarm classification tasks are performed at multiple candidate thresholds, such as 0.70, 0.75, and 0.80. Finally, the candidate value of 0.75, which maximizes the overall classification accuracy of the model, is selected as the fixed preset similarity threshold. This threshold can be dynamically adjusted within the range of 0.9 to 1.1 times the baseline value according to the accuracy requirements of specific operation and maintenance scenarios. For high-precision operation and maintenance scenarios, it can be increased to 0.80, and for routine operation and maintenance scenarios, it can be decreased to 0.70. During the comparison, the similarity value of each record is directly compared with the threshold. For example, an alarm record involving a direct power outage operation has a similarity value of 0.68, which is lower than the baseline threshold of 0.75, and is therefore determined to be inconsistent with the operation preference.

[0046] Secondly, if the similarity value is lower than the similarity threshold, the corresponding alarm record is removed, resulting in filtered alarm data. The filtering process automatically retains all alarm records with similarity values ​​greater than or equal to the threshold, and records the number and reason for removal for subsequent model optimization. The filtered data is initially sorted by timestamp to ensure correct temporal logic. For example, removing 2300 low-similarity records from 5000 original alarm records yields 2700 filtered alarm data, reducing the data volume by 46%.

[0047] Subsequently, the filtered alarm data undergoes priority sorting to generate a risk priority sequence. Priority sorting employs a weighted scoring method, comprehensively considering three factors: real-time equipment load rate, aging indicators, and historical processing success rate. The correlation strength is derived by weighted summation of these three factors, with real-time load rate weighted at 0.4, aging indicators at 0.3, and historical processing success rate at 0.3. This weighting combination is based on historical alarm processing efficiency statistics. Real-time load rate directly affects the speed of risk propagation and is given a higher weight; aging indicators reflect the inherent risks of the equipment; and historical processing success rate reflects the feasibility of handling and is given a lower weight. A comprehensive score is calculated for each record, and records are sorted from highest to lowest score to generate the risk priority sequence. For example, a transformer node with a real-time load rate of 90%, an aging indicator of 65%, and a historical load reduction success rate of 85% has a comprehensive score of 81, ranking first in the risk priority sequence.

[0048] It's worth noting that the aging index quantifies the degree of performance degradation caused by long-term operation of equipment, with a value ranging from 0 to 100. A higher value indicates more severe aging. The aging index comprehensively considers the equipment's cumulative operating time, historical failure count, average temperature deviation, and voltage fluctuation amplitude, and is obtained through weighted summation. Specifically, the weight of cumulative operating time is 0.4, the weight of historical failure count is 0.3, the weight of average temperature deviation (relative to the factory standard temperature) is 0.2, and the weight of voltage fluctuation amplitude is 0.1. This weighting is based on a multiple linear regression analysis of historical maintenance data from 1000 IoT devices, calculating the contribution of each factor to the equipment failure rate and setting it as the factor weight. Each sub-index is mapped to the 0-100 range using min-max normalization, and the weighted summation yields the aging index, which is then normalized to the 0%-100% range. The system automatically updates the aging index every 24 hours. If a major equipment failure occurs or a critical component is replaced, an immediate recalculation is triggered.

[0049] Then, a customized alarm report containing risk blocking instructions is generated based on the risk priority sequence. Report generation is achieved using the T5-small natural language generation model, with a training set containing over 10,000 labeled operation and maintenance alarm report samples, covering different equipment types and risk scenarios. The model training process is set with a batch size of 16, an initial learning rate of 0.001, decaying by 0.1 every 10 rounds until reaching 0.0001, using the ReLU activation function and cross-entropy loss function. Iteration stops after 8 consecutive rounds when the loss fluctuation is less than 0.001, with a maximum of 100 rounds. The input is structured data of the risk priority sequence, and the output is an alarm report in natural language format, containing information on the top ten high-risk equipment and their corresponding risk blocking instructions. For example, the generated customized alarm report lists 10 high-risk transformers, each with its equipment number, current load rate, and a specific blocking instruction to reduce power by 15%.

[0050] It should be noted that the generation of the risk blocking command adopts a decision tree rule engine based on risk level and device type. This engine pre-builds a rule base based on the device operation and maintenance manual and historical handling cases. The rule format is as follows: if the device type is {transformer, inverter} and the risk level is ≥3 and the real-time load rate is ≥85%, then output a power reduction of 15%; if the device type is {router, gateway} and the packet loss rate is ≥10%, then output a network stack restart; if the device type is {temperature and humidity sensor} and the temperature deviation is ≥5℃, then output a calibration offset. The rule base contains 12 core rules, covering common device types and risk scenarios. For abnormal situations where the rules are not matched, the system uses the T5-small model to generate natural language commands based on historical similar alarm processing records, with a [[manual confirmation required]] flag appended to the end of the command. The generated blocking command, along with the device identifier and risk level, is encapsulated in a customized alarm report.

[0051] In this implementation case, filtered alarm data and risk priority sequences are synchronously stored in a local cache, retaining the results of the most recent 100 processing iterations for backtracking analysis. The generated customized alarm reports are pushed to the administrator's terminal in real time, along with the alarm batch number and generation time. The system automatically verifies the completeness of the reports; if core device information is missing, the report is regenerated to ensure accuracy.

[0052] In step S103, obtaining the real-time network bandwidth and network latency values ​​of the administrator's mobile terminal, comparing the real-time network bandwidth value with a preset bandwidth benchmark threshold, comparing the network latency value with a preset latency determination threshold, and determining the network status based on the comparison results to obtain a network status identifier includes:

[0053] Obtain real-time network bandwidth and network latency values ​​from the administrator's mobile terminal;

[0054] The real-time network bandwidth value is compared with a preset bandwidth benchmark threshold.

[0055] The network latency value is compared with a preset latency threshold.

[0056] If the real-time network bandwidth value is lower than the bandwidth baseline threshold and the network latency value is higher than the latency determination threshold, a weak network status identifier is generated and the weak network status identifier is used as the network status identifier.

[0057] If the real-time network bandwidth value is not lower than the bandwidth baseline threshold or the network latency value is not higher than the latency determination threshold, a normal network status identifier is generated and the normal network status identifier is used as the network status identifier.

[0058] It should be noted that, firstly, the real-time network bandwidth and latency values ​​of the administrator's mobile terminal are obtained. This data collection is achieved through a probe program residing in the background of the mobile terminal, employing an active probe packet sending mechanism, sending a 512-byte test data packet to the cloud server every 5 seconds. The bandwidth value is obtained by calculating the amount of data successfully transmitted per unit time, and the latency value is obtained by calculating the round-trip time of the data packet. The packet loss rate is also recorded during the collection process as an auxiliary indicator. The collection frequency is set to once every 5 seconds, and this frequency setting is determined based on the physical boundary constraints of balancing the communication signal-to-noise ratio and terminal power consumption. In mobile network communication, an excessively high probe frequency can cause the terminal device's battery to deplete rapidly and lead to network congestion, while an excessively low frequency cannot capture millisecond-level network transient degradation. Engineering verification has shown that setting the probe interval to 5 seconds can control the additional bandwidth consumption to within 1% of the total bandwidth, while ensuring that the response latency to weak network conditions does not exceed the timeout retransmission threshold specified in the communication protocol.

[0059] Next, the real-time network bandwidth value is compared with a preset bandwidth benchmark threshold. The bandwidth benchmark threshold is determined through a grid search on a historical network state dataset. Network state classification and subsequent alarm push success rate tests are performed at multiple candidate bandwidth thresholds, such as 300 kbps, 500 kbps, and 800 kbps. Finally, the candidate value of 500 kbps, which results in the highest average alarm delivery rate and the lowest false alarm rate, is selected as the fixed preset bandwidth benchmark threshold. This threshold can be adjusted within the range of 0.6 to 1.6 times the benchmark value; it can be lowered to 300 kbps for emergency alarm scenarios and raised to 800 kbps for regular alarm scenarios. The comparison directly compares the real-time bandwidth value with the threshold.

[0060] Secondly, the network latency value is compared with a preset latency threshold. This latency threshold is determined based on the physical timing boundary constraints of the alarm data packet transmission protocol. The retransmission timeout of the Transmission Control Protocol in conventional mobile networks typically increases exponentially with network fluctuations. When a single round-trip delay exceeds 300 milliseconds, it can easily trigger a continuous retransmission storm, leading to link collapse. Therefore, the basic latency threshold is strictly set at 300 milliseconds to initiate weak network compression intervention before the retransmission mechanism fails. This threshold can be adjusted within the range of 0.6 to 1.6 times the baseline value; it can be increased to 500 milliseconds for emergency alarm scenarios and decreased to 200 milliseconds for regular alarm scenarios. The comparison directly compares the real-time latency value with the threshold.

[0061] Subsequently, if the real-time network bandwidth value is lower than the bandwidth baseline threshold and the network latency value is higher than the latency determination threshold, a weak network status identifier is generated and used as the network status identifier. The weak network status identifier is a Boolean variable; a true value indicates that the current network is in a weak network state. Simultaneously with identifier generation, the current bandwidth, latency, and packet loss rate values ​​are recorded for subsequent path planning and data compression processing.

[0062] Then, if the real-time network bandwidth value is not lower than the bandwidth baseline threshold or the network latency value is not higher than the latency judgment threshold, a normal network status identifier is generated and used as the network status identifier. The normal network status identifier is a Boolean variable, and a value of false indicates that the current network is in a normal state. The current network parameters are recorded simultaneously with the identifier generation for subsequent alarm push processing. For example, if the real-time bandwidth of 600 kilobits per second is higher than the threshold and the latency of 200 milliseconds is lower than the threshold, a normal network status identifier is generated with a value of false.

[0063] It should be further explained that in some operational scenarios with higher sensitivity to network status (such as handling risks of core equipment requiring real-time response within seconds), the above basic binary classification judgment rule can be further refined into a three-classification mode to address the differentiated processing needs in intermediate network environments. Specifically, when the real-time network bandwidth value is lower than the bandwidth baseline threshold and the network latency value is not higher than the latency judgment threshold (i.e., bandwidth is limited but latency is good), or when the real-time network bandwidth value is not lower than the bandwidth baseline threshold and the network latency value is higher than the latency judgment threshold (i.e., bandwidth is sufficient but latency is high), the system classifies it as a moderately limited network state. In this state, only text compression processing of customized alarm reports is performed (removing multimedia attachments and redundant fields), but the path replanning process is not triggered, thereby reducing unnecessary routing calculation overhead while ensuring information delivery. This three-classification mode can be flexibly enabled through configuration parameters, but the basic binary classification rule is still used by default to reduce system complexity.

[0064] It's worth noting that the size of the probe packet can be dynamically adjusted according to network conditions. In weak network environments, it can be reduced to 256 bytes to lower transmission overhead, while in normal network environments, it can be increased to 1024 bytes to improve measurement accuracy. The sampling frequency can also be adjusted according to the urgency of the alarm. For urgent alarms, it can be increased to once per second to improve status response speed, while for regular alarms, it remains once every 5 seconds. Simultaneously, the threshold can be adjusted according to the network infrastructure conditions of different regions. In remote areas, it can be adjusted within the range of 0.8 to 1.2 times the baseline value. For example, in maintenance scenarios in remote mountainous areas, the bandwidth baseline threshold can be lowered to 200 kilobits per second, and the latency judgment threshold can be raised to 600 milliseconds to adapt to local network conditions.

[0065] In this implementation case, real-time network parameters and network status identifiers are synchronously stored in a local cache, retaining the most recent 100 collection results for backtracking analysis. The network status identifier is pushed to the data compression module and path planning module in real time, simultaneously binding the administrator terminal number and timestamp information. The system automatically verifies the validity of the collected data; if three consecutive probes fail, it is determined as a network interruption, triggering an offline alarm caching mechanism. Once the network recovers, the cached alarm information is automatically pushed. For example, the generated weak network status identifier is pushed to the data compression module, bound to terminal number MB001 and timestamp 11:55:52, triggering subsequent text compression and path planning processes.

[0066] In step S104, if the network status identifier is a weak network status, then the customized alarm report is subjected to text compression processing to obtain a simplified alarm report, including:

[0067] Extract text data from the customized alarm report;

[0068] Semantic feature extraction is performed on the text data to obtain the core semantic text;

[0069] Redundant fields are removed from the core semantic text to obtain compressed text data;

[0070] A simplified alarm report is generated based on the compressed text data.

[0071] It should be noted that, firstly, text data is extracted from the customized alarm report. The customized alarm report is stored in structured JSON format. During extraction, the hierarchical structure of the report is parsed, separating the text content from multimedia attachments. The extracted text fields include device identifier, fault code, trigger time, risk level, and risk blocking command. The extraction process automatically removes HTML tags, blank lines, and comments, retaining only plain text data. After extraction, a data integrity check is performed to ensure that all critical fields are complete.

[0072] Next, semantic feature extraction is performed on the text data to obtain key semantic text. Semantic feature extraction is implemented using a BERT-base-uncased pre-trained model, which is fine-tuned on a dataset of 10,000+ labeled operation and maintenance alarm texts. During fine-tuning, the batch size is set to 32, the initial learning rate is 0.0001, and it decays by 0.1 every 10 rounds until it reaches 0.00001. The ReLU activation function and cross-entropy loss function are used. Iteration stops after 6 consecutive rounds if the loss fluctuation is less than 0.001, with a maximum of 50 rounds. The model outputs the weight value of each semantic unit. The preset semantic weight threshold is determined by grid search on historical datasets. Specifically, semantic extraction and subsequent compression tasks are performed under multiple candidate thresholds (e.g., 0.6, 0.7, 0.8), the information retention rate after compression corresponding to each candidate threshold is calculated, and the candidate threshold corresponding to the highest information retention rate is determined as the preset semantic weight threshold. The weight values ​​are compared with the preset semantic weight threshold. If the weight value is greater than or equal to the preset semantic weight threshold, the corresponding semantic unit is extracted. The extracted semantic units are then integrated to generate core semantic text. For example, semantic extraction is performed on 500 kilobytes of text data. A grid search determines the preset semantic weight threshold to be 0.7. Semantic units with weight values ​​higher than or equal to 0.7 are retained, resulting in 120 kilobytes of core semantic text containing all necessary alarm and handling information.

[0073] Secondly, redundant fields in the key semantic text are removed to obtain compressed text data. Redundant fields include descriptive modifiers, repetitive contextual descriptions, unnecessary historical statistics, and auxiliary explanations. The removal process employs a rule-based matching method, pre-configured with a matching library containing over two hundred common redundant phrases. This matching library is constructed based on 100,000 historical alarm logs recorded by the system over the past year. Word frequency and inverse document frequency algorithms are used to identify phrase fragments that appear very frequently in the overall corpus but have very low information entropy in fault diagnosis semantics. These fragments cover formatted prefixes, disclaimers, and routine status announcements, and are solidified into a fixed rule dictionary after secondary manual review by operations and maintenance experts. The system automatically searches this dictionary and automatically identifies and deletes matching content. After removal, a Huffman coding algorithm is used to perform secondary entropy encoding on the text to further compress the data volume. This encoding method is based on character frequency statistics of 10,000 operations and maintenance alarm texts to construct an encoding dictionary, achieving an average compression rate of over 50%.

[0074] Subsequently, a simplified alarm report is generated based on the compressed text data. The simplified alarm report uses plain text format, displaying the top 5 key alarm messages sorted by risk priority. Each message includes the device identifier, fault parameters, and corresponding risk blocking instructions. If the original report contains multimedia attachments, the attachments are compressed. A bilinear interpolation algorithm is used to sample the image resolution from 1920 x 1080 pixels to 320 x 240 pixels, simultaneously converting the color depth from 24-bit true color to 8-bit grayscale mode, compressing the size of a single image to less than 15 kilobytes. The final simplified alarm report is controlled to a total size of less than 45 kilobytes, ensuring fast transmission in weak network environments.

[0075] It's worth noting that the semantic weight threshold can be dynamically adjusted based on network conditions. In extremely weak network environments, it can be increased to 0.8 to further compress text size, while remaining unchanged at 0.7 in normal weak network environments. The Huffman-coded dictionary can be updated every 1000 hours of operation, and combined with newly added alarm text to optimize character frequency statistics, it improves compression efficiency. Simultaneously, the compression level of multimedia attachments can be adjusted as needed. In extremely low bandwidth environments, all multimedia content can be completely removed, retaining only plain text alarm information. For example, in extremely weak network environments with bandwidth below 100 kilobits per second, increasing the semantic weight threshold to 0.8, removing all multimedia attachments, and generating a simplified report size controlled to within 20 kilobytes.

[0076] In this implementation case, the generated streamlined alarm reports are synchronously stored in the local cache, retaining the most recent 50 compressed results for backtracking analysis. After report generation, an MD5 checksum is automatically calculated for integrity verification during transmission. Once verified, the report is pushed to the path planning module in real time, along with the alarm batch number and network status identifier. The system automatically checks the report size; if it exceeds the 45 kilobyte limit, the compression process is re-executed to ensure compliance with weak network transmission requirements.

[0077] In step S105, obtaining the real-time signal attenuation rate and physical topology of the current network, performing path planning based on the real-time signal attenuation rate and physical topology to obtain the target transmission path, and sending the simplified alarm report to the mobile terminal along the target transmission path to obtain the push result of the risk blocking command includes:

[0078] Obtain the real-time signal attenuation rate and physical topology of the current network;

[0079] The physical topology is converted into a weighted directed graph model;

[0080] Obtain the physical distance values ​​and historical congestion frequency values ​​between nodes in the weighted directed graph model, and set the edge weights based on the physical distance values ​​and the historical congestion frequency values;

[0081] The edge weights of the weighted directed graph model are updated according to the real-time signal attenuation rate to obtain the updated topology model;

[0082] The updated topology model is subjected to shortest path solving to obtain the target transmission path;

[0083] The simplified alarm report is sent to the mobile terminal along the target transmission path to obtain the push result of the risk blocking instruction.

[0084] It should be noted that, firstly, the real-time signal attenuation rate and physical topology of the current network are obtained. The real-time signal attenuation rate is calculated by collecting radio frequency parameters from the underlying link probes, with the sampling frequency set to once per second. The calculation measures the difference between the transmit power and the receive power, divides it by the transmission distance to obtain the signal attenuation rate per unit distance, with a value ranging from 0 to 1. The physical topology is pulled from the network management center and includes the connection relationships of all active base stations, edge computing nodes, and terminal devices, updated every 5 minutes. Offline nodes and failed links are automatically removed during the data collection process to ensure the validity of the topology. For example, if the link probes measure the main link's transmit power as 20 milliwatts, receive power as 11.5 milliwatts, and transmission distance as 100 meters, the calculated real-time signal attenuation rate is 42.5%.

[0085] Next, the physical topology is converted into a weighted directed graph model. During the conversion, each network device is mapped to a vertex in the graph, and the communication links between devices are mapped to directed edges. Vertices contain three attributes: device number, geographical location, and operating status; edges contain three attributes: link bandwidth, transmission delay, and connection status. The resulting weighted directed graph model contains 128 vertices and 342 directed edges, covering the network topology of the entire operation and maintenance area. For example, the base station numbered BS001, the edge computing node EC003, and the mobile terminal MB001 are mapped to three vertices, and the two communication links between them are mapped to two directed edges, forming a local topology subgraph.

[0086] Secondly, the physical distance values ​​and historical congestion frequency values ​​between nodes in the weighted directed graph model are obtained. To eliminate the dimensional differences between different physical quantities, the physical distance values ​​and the historical congestion frequency values ​​are first subjected to min-max normalization processing to obtain distance-normalized values ​​and congestion-normalized values. Edge weights are then set based on these values. The edge weights are calculated using a weighted summation method, with the weight of the distance-normalized value set to 0.4 and the weight of the congestion-normalized value set to 0.6. This weight combination was determined by performing multiple linear regression and path connectivity reliability sensitivity analysis on path planning samples from over 10,000 different network scenarios. Specifically, the end-to-end delivery success rate of alarm information is used as the core optimization objective function. Statistical results show that among the factors affecting link transmission stability, historical congestion frequency contributes 60% to the variance of transmission packet loss and delay, while physical distance contributes 40% to the variance of basic transmission delay. Therefore, the system strictly adheres to the aforementioned quantification ratio of variance contribution, objectively setting the weight of historical congestion frequency to 0.6 and the weight of physical distance to 0.4, avoiding the blindness of manual assignment. The initial values ​​obtained through the above weighted summation calculation naturally fall within the closed interval of 0 to 1. To adapt to the numerical resolution requirements of the underlying routing calculation and avoid loss of floating-point precision, the system further multiplies the summation value by 100, linearly mapping it proportionally to the numerical range of 0 to 100. The value obtained after this mapping amplification is the initial edge weight; the larger the value, the higher the transmission cost of the link.

[0087] It is worth noting that before performing minimum-maximum normalization, the statistical value range of each parameter needs to be clearly defined. The statistical minimum value for physical distance is 0 meters (equipment within the same data center), and the maximum value is 3000 meters (between edge nodes and base stations across buildings). This range is determined based on measured data from typical industrial park IoT deployments. The statistical minimum value for historical congestion frequency is 0 times / hour, and the maximum value is 60 times / hour (corresponding to approximately 0.017 congestion events per second; exceeding this threshold is considered a link unavailable). If the actual collected physical distance and congestion frequency exceed the above ranges, they should be truncated to the minimum or maximum value respectively before participating in the normalization calculation.

[0088] Subsequently, the edge weights of the weighted directed graph model are updated according to the real-time signal attenuation rate to obtain the updated topology model. During the update, the initial edge weight is multiplied by 1 and summed with the real-time signal attenuation rate to obtain the updated edge weight. The higher the signal attenuation rate, the greater the increase in edge weight, reflecting the decline in link transmission quality. The update process is performed edge-by-edge to ensure that the weights of all links reflect the current signal quality. For example, the real-time signal attenuation rate of link BS001-EC003 is 42.5%, and the initial edge weight of 32 is multiplied by 1.425 to obtain an updated edge weight of 45.6.

[0089] It is worth noting that the above update formula is an empirical engineering formula based on Shannon's channel capacity theorem. Shannon's channel capacity theorem states that for every 10% increase in signal attenuation, the channel capacity decreases by approximately 15% to 20%. Therefore, the linear incremental estimation used above is used to update the transmission cost. Actual measurements show that in industrial IoT scenarios where the signal attenuation rate does not exceed 60%, the correlation coefficient between this linear approximation and the packet loss rate is above 0.92, meeting engineering accuracy requirements. If the attenuation rate consistently exceeds 60%, it is recommended to directly switch to a backup communication link.

[0090] Then, the updated topology model is processed to find the shortest path to obtain the target transmission path. The shortest path is found using a modified Dijkstra's algorithm, which optimizes node traversal using a priority queue, resulting in a time complexity of O(ElogV), where E is the number of edges and V is the number of vertices. The solution starts at the cloud server and ends at the administrator's mobile terminal, traversing all possible paths and selecting the path with the minimum total weight as the target transmission path. The path contains no more than 5 nodes to avoid excessive relays that could increase transmission latency. For example, after traversing 3420 potential paths, the path with the minimum total weight is found to be Cloud Server-EC002-EC005-Mobile Terminal, with a total weight of 21.3 and containing 3 relay nodes.

[0091] It's worth noting that the weighting coefficients of edge weights can be dynamically adjusted according to network type. For wired networks, the weight of physical distance can be increased to 0.6, while for wireless networks, the weight of historical congestion frequency can be increased to 0.7. The shortest path algorithm can be adjusted according to network size; small-scale networks can use the Floyd algorithm, while large-scale networks retain the improved Dijkstra algorithm. Simultaneously, the topology update frequency can be adjusted within the range of 0.5 to 2 times the baseline value, increasing to once every 2.5 minutes when network fluctuations are frequent and decreasing to once every 10 minutes when the network is stable. For example, in a fully wireless industrial IoT scenario, increasing the weight of historical congestion frequency to 0.7 and adjusting the weight of physical distance to 0.3 improves the ability to avoid unstable wireless links.

[0092] In this implementation case, the updated topology model and target transmission path are synchronously stored in the local cache, retaining the most recent 20 planning results for backtracking analysis. The target transmission path is pushed to the command push module in real time, simultaneously binding the alarm batch number and timestamp information. The system automatically verifies the validity of the path; if the path contains offline nodes, path planning is re-executed to ensure the connectivity of the transmission link. For example, if the generated target transmission path contains 3 relay nodes with a total weight of 21.3, it is pushed to the command push module, bound with alarm batch number AL001 and timestamp 11:58:40, and the path validity verification passes.

[0093] Finally, the simplified alarm report is sent to the mobile terminal along the target transmission path to obtain the push result of the risk blocking instruction. Specifically, the system encapsulates the simplified alarm report into a transmission data frame and sends it hop-by-hop according to the target transmission path. After receiving the simplified alarm report, the mobile terminal parses it and executes the risk blocking instruction contained therein locally. After execution, it returns a confirmation data packet to the cloud system. The system receives and parses the execution status of the confirmation data packet to obtain the push result of the risk blocking instruction. For example, the system sends the encapsulated simplified alarm report along the path "cloud server-EC002-EC005-mobile terminal". After receiving it, the mobile terminal successfully executes the risk blocking instruction and returns a confirmation data packet confirming successful execution. After parsing the data packet, the system records the push result of this instruction as successful.

[0094] It should be noted that after obtaining the push result of the risk blocking instruction, the process also includes:

[0095] The push results will be recorded in the security audit log database;

[0096] Update the historical operation record based on the push results.

[0097] It should be noted that, firstly, the push results are recorded in the security audit log library. The security audit log library uses a distributed time-series database for storage. Each log record contains seven key fields: alarm batch number, administrator number, push time, transmission delay, packet loss rate, execution status code, and risk blocking instruction content. A millisecond-level timestamp is automatically added during the recording process. Sensitive fields are encrypted using advanced encryption standards, with a key length of 256 bits. The key can be stored and rotated using a well-known key management scheme, such as using a Hardware Security Module (HSM) or periodically obtained from a key management server. The log retention period is set according to network security level protection requirements, with a basic retention period of one year. For high-security scenarios, this can be adjusted within the range of 0.5 to 2 times the base value, with a maximum retention period of two years and a minimum retention period of six months. After each record is generated, a SHA-256 hash value is automatically calculated for subsequent integrity verification to prevent log tampering. For example, the successful push result is recorded in the log library. The generated log includes alarm batch number AL001, administrator number AD001, push time 11:59:49.210, transmission delay 145.8 milliseconds, packet loss rate 0, execution status code 200 and blocking command to reduce power by 15%.

[0098] Next, the historical operation records are updated based on the push results. The historical operation records contain three core fields: average response time, execution frequency of each operation type, and processing success rate. The average response time is updated using an exponentially weighted moving average method, with a time decay factor set to 0.95 based on statistics from over 10,000 operation samples. During the update, the current execution time is multiplied by 0.05, and then the historical average response time is multiplied by 0.95 to obtain the new average response time. The execution frequency of each operation type uses an incremental statistical method, incrementing the frequency by 1 for each execution. The processing success rate is the ratio of successful executions to the total number of executions. All updated values ​​are mapped to the 0-1 range using a minimum-maximum normalization method for subsequent operation preference vector generation. For example, if an administrator's historical average response time is 15.3 minutes and the current execution time is 14.8 minutes, after calculating with an exponentially weighted moving average, the new average response time is updated to 15.275 minutes, and the execution frequency of remote load reduction operations increases from 450 to 451.

[0099] It's worth noting that the storage strategy for the security audit log repository can be dynamically adjusted according to business needs. In high-concurrency scenarios, the number of shards can be increased to improve write performance, while in low-concurrency scenarios, shards can be merged to save storage resources. The update frequency of historical operation records can be adjusted within the range of 0.5 to 2 times the baseline value. Administrators who perform frequent operations can increase the update frequency to once per hour, while administrators who perform fewer operations can reduce it to once per day. Simultaneously, log data is automatically backed up to an off-site storage node daily, with the backup retention period consistent with that of local logs, ensuring data reliability and traceability.

[0100] It is worth noting that after obtaining the push result of the risk blocking instruction, the process also includes:

[0101] Based on the push results, optimize the route planning process.

[0102] It is worth noting that the push results are used not only to update historical operation records but also to dynamically optimize subsequent path planning. Specifically, the system records the transmission delay and packet loss rate of each push. If the transmission delay of a push exceeds 1.5 times the preset delay threshold, or the packet loss rate is higher than 5%, the result is used as negative feedback to increase the historical congestion frequency value of each edge in the target transmission path. The increase rule is as follows: a single push failure (timeout or packet loss rate higher than 10%) increases the historical congestion frequency value of the corresponding edge by 1; a single high delay (delay exceeding 1.5 times the threshold but not failing) increases it by 0.5. The updated historical congestion frequency value will participate in the recalculation of edge weights in subsequent step S105 (i.e., re-perform normalization and weighted summation), thereby enabling the system to gradually avoid links with poor quality and achieve adaptive optimization of path planning. The feedback update cycle is consistent with the update cycle of the operation preference vector, and is processed in batches every 24 hours by default. If more than 3 consecutive push anomalies occur, a real-time update is triggered.

[0103] In summary, this invention discloses a machine learning-based risk response method for IoT devices. The method includes acquiring raw alarm data from IoT devices and historical operation records from administrators; extracting and generating operation preference vectors; filtering irrelevant alarms based on these vectors and recombining them to generate customized alarm reports containing risk blocking commands; real-time sensing of the network status of the administrator's mobile terminal; extracting and compressing core semantics in weak network environments to generate simplified alarm reports; constructing a weighted directed graph based on real-time network signal attenuation rate and physical topology; solving for the optimal target transmission path; pushing alarms along the path; recording the results; and updating operation records. This invention solves the problems of alarm information overload in traditional fixed-process systems, command push delays in weak network environments, and low success rates of single transmission paths. It achieves accurate response and efficient push of IoT device risks, meeting the core requirements of real-time and effective device security management in complex operation and maintenance scenarios.

[0104] The second embodiment of the present invention provides a machine learning-based Internet of Things (IoT) device risk response system, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the method described above.

[0105] It should be noted that the machine learning-based IoT device risk response system provided in this embodiment executes all the process steps of the machine learning-based IoT device risk response method described in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0106] It should be noted that the system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the system embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0107] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A risk response method for IoT devices based on machine learning, characterized in that, include: Obtain raw alarm data from IoT devices and historical operation records from administrators; perform feature extraction processing on the raw alarm data and historical operation records to obtain an operation preference vector. Based on the operation preference vector, the original alarm data is subjected to content filtering and logical reorganization to generate a risk priority sequence, and a customized alarm report containing risk blocking instructions is obtained based on the risk priority sequence. The system obtains the real-time network bandwidth and network latency values ​​from the administrator's mobile terminal, compares the real-time network bandwidth value with a preset bandwidth benchmark threshold, compares the network latency value with a preset latency judgment threshold, and determines the network status based on the comparison results to obtain a network status identifier. If the network status is identified as a weak network, then the customized alarm report is compressed to obtain a simplified alarm report. The system obtains the real-time signal attenuation rate and physical topology of the current network, performs path planning based on the real-time signal attenuation rate and physical topology to obtain the target transmission path, sends the simplified alarm report to the mobile terminal along the target transmission path, and obtains the push result of the risk blocking command.

2. The risk response method for IoT devices based on machine learning according to claim 1, characterized in that, The process involves acquiring raw alarm data from IoT devices and historical operation records from administrators, performing feature extraction processing on the raw alarm data and historical operation records to obtain an operation preference vector, including: Obtain raw alarm data from IoT devices and historical operation records from administrators; The original alarm data and the historical operation records are standardized to obtain a standardized dataset; The feature weights are calculated on the standardized dataset to obtain the feature weight coefficients; The standardized dataset is subjected to feature fusion processing based on the feature weight coefficients to obtain the operation preference vector.

3. The machine learning-based risk response method for IoT devices according to claim 1, characterized in that, The step of performing content filtering and logical reorganization on the original alarm data according to the operation preference vector to generate a risk priority sequence, and obtaining a customized alarm report containing risk blocking instructions based on the risk priority sequence, includes: Calculate the similarity value between the operation preference vector and each record in the original alarm data; The similarity value is compared with a preset similarity threshold; If the similarity value is lower than the similarity threshold, the corresponding alarm record is removed to obtain filtered alarm data. The filtered alarm data is sorted by priority to generate a risk priority sequence; Generate a customized alarm report containing risk blocking instructions based on the risk priority sequence.

4. The risk response method for IoT devices based on machine learning according to claim 1, characterized in that, The process of obtaining real-time network bandwidth and network latency values ​​from the administrator's mobile terminal, comparing the real-time network bandwidth value with a preset bandwidth benchmark threshold, comparing the network latency value with a preset latency judgment threshold, and determining the network status based on the comparison results to obtain a network status identifier includes: Obtain real-time network bandwidth and network latency values ​​from the administrator's mobile terminal; The real-time network bandwidth value is compared with a preset bandwidth benchmark threshold, and the network latency value is compared with a preset latency determination threshold. If the real-time network bandwidth value is lower than the bandwidth baseline threshold and the network latency value is higher than the latency determination threshold, a weak network status identifier is generated and the weak network status identifier is used as the network status identifier. If the real-time network bandwidth value is not lower than the bandwidth baseline threshold or the network latency value is not higher than the latency determination threshold, a normal network status identifier is generated and the normal network status identifier is used as the network status identifier.

5. The machine learning-based risk response method for IoT devices according to claim 1, characterized in that, If the network status identifier indicates a weak network status, then the customized alarm report undergoes text compression processing to obtain a simplified alarm report, including: Extract text data from the customized alarm report; Semantic feature extraction is performed on the text data to obtain the core semantic text; Redundant fields are removed from the core semantic text to obtain compressed text data; A simplified alarm report is generated based on the compressed text data.

6. The machine learning-based risk response method for IoT devices according to claim 1, characterized in that, The process of obtaining the real-time signal attenuation rate and physical topology of the current network, performing path planning based on the real-time signal attenuation rate and physical topology to obtain the target transmission path, sending the simplified alarm report to the mobile terminal along the target transmission path, and obtaining the push result of the risk blocking command includes: Obtain the real-time signal attenuation rate and physical topology of the current network; The physical topology is converted into a weighted directed graph model; Obtain the physical distance values ​​and historical congestion frequency values ​​between nodes in the weighted directed graph model, and set the edge weights based on the physical distance values ​​and the historical congestion frequency values; The edge weights of the weighted directed graph model are updated according to the real-time signal attenuation rate to obtain the updated topology model; The updated topology model is subjected to shortest path solving to obtain the target transmission path; The simplified alarm report is sent to the mobile terminal along the target transmission path to obtain the push result of the risk blocking instruction.

7. The machine learning-based risk response method for IoT devices according to claim 1, characterized in that, After obtaining the push result of the risk blocking instruction, the process also includes: The push results will be recorded in the security audit log database; Update the historical operation record based on the push results.

8. The machine learning-based risk response method for IoT devices according to claim 1, characterized in that, After obtaining the push result of the risk blocking instruction, the process also includes: Based on the push results, optimize the route planning process.

9. A machine learning-based risk response system for Internet of Things (IoT) devices, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method described in any one of claims 1 to 9.

Images