A SIM card management platform

Abstract

The application relates to the technical field of Internet of Things communication, and discloses a SIM card management platform, which comprises a protocol identification module, an abnormality detection module, a health degree evaluation module, an instruction scheduling module and a flow prediction module.The protocol identification module is used for acquiring original data packets uploaded by engineering mechanical equipment, performing multilevel feature extraction and two-stage identification, and the abnormality detection module is used for performing equipment grouping and lightweight abnormality detection; the health degree evaluation module is used for performing multidimensional index fusion, performing hierarchical analysis, and evaluating the health state of the equipment; the instruction scheduling module is used for distributing transmission strategies and channels, performing instruction sending, and recording the whole life cycle state change of the instructions; the flow prediction module is used for constructing a prediction model, predicting future flow use trends, and performing multi-scene analysis and alarming; and the elastic scaling module is used for performing multistage elastic scaling and intelligent scheduling based on system processing load and real-time performance indexes; the application solves the problems of protocol compatibility, intelligent abnormality detection, weak network communication reliability and system scalability in large-scale engineering mechanical equipment SIM card management.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication technology, and more specifically, to a SIM card management platform. Background Technology

[0002] With the deep application of IoT technology in the construction machinery field, network communication via SIM cards for vehicle equipment has become an industry standard. SIM card management for large-scale construction machinery equipment faces challenges such as the sheer scale of equipment, diverse protocol types, and complex network environments. Existing SIM card management technologies mainly suffer from the following problems.

[0003] Existing technologies typically support only one or a few standard communication protocols, offering insufficient support for enterprise-specific protocols and heterogeneous device access. When new devices are added or protocols are upgraded, specialized secondary development and system deployment are required, leading to high system maintenance costs and poor scalability. Different protocols result in varying data field naming and formats, lacking a unified data model, which complicates data processing in backend business systems. This protocol compatibility issue severely restricts the unified management and interoperability of multi-protocol devices.

[0004] Existing SIM card management systems primarily employ alarm mechanisms based on fixed thresholds, triggering alarms when monitored indicators exceed preset thresholds. This simple threshold-based alarm method has significant drawbacks: different devices operate under vastly different conditions, and a uniform threshold cannot adapt to all devices, leading to a high false alarm rate; threshold-based alarms are a passive response, only detecting problems after they have occurred, failing to provide early warnings; and they cannot identify complex anomaly patterns, such as abnormal fluctuations in traffic usage, frequent disconnections and reconnections, and continuous degradation of signal quality. Some solutions attempt to use deep learning methods for anomaly detection, but maintaining an independent model for each device consumes enormous computational and storage resources, making it difficult to support large-scale device scenarios. Furthermore, newly connected devices lack historical data to train models, resulting in a cold start problem.

[0005] Construction machinery often operates in environments with weak or unstable network signals, such as remote mountainous areas, underground construction sites, and tunnels. In these scenarios, communication between the equipment and the management platform faces problems such as high packet loss rates, long latency, and frequent disconnections. Existing command issuance mechanisms typically employ a simple request-response model, lacking optimization design for weak network environments: they lack command priority management mechanisms, sending all commands in a first-in-first-out order, failing to prioritize urgent commands; retransmission mechanisms are not intelligent enough, typically employing a fixed number of retransmissions and fixed intervals, unable to dynamically adjust based on network quality; and they lack multi-channel concurrent transmission and redundancy backup mechanisms, failing to quickly switch to backup channels when the primary channel becomes unavailable. For safety-related critical commands such as remote engine shutdown, vehicle locking, and emergency shutdown, the reliability and real-time requirements for delivery are extremely high, which existing technologies struggle to meet. Summary of the Invention

[0006] This invention provides a SIM card management platform that solves the technical problems of lack of optimized design for weak network environments, high false alarm rate, and inability to provide early warning in related technologies.

[0007] This invention provides a SIM card management platform, comprising:

[0008] The protocol recognition module acquires the raw data packets uploaded by the engineering machinery equipment, performs multi-level feature extraction and two-stage recognition, and obtains standardized equipment data objects.

[0009] The anomaly detection module performs equipment grouping and lightweight anomaly detection based on standardized equipment data objects, and obtains the results of equipment behavior anomaly detection.

[0010] The health assessment module integrates multi-dimensional indicators based on standardized equipment data objects, performs hierarchical analysis based on anomaly detection results, assesses the health status of the equipment, and obtains an equipment health score and diagnostic report.

[0011] The instruction scheduling module allocates transmission strategies and channels based on device health scores and diagnostic reports, sends instructions, records the status changes of instructions throughout their entire lifecycle, and obtains instruction delivery status and tracking information.

[0012] The traffic prediction module builds a prediction model based on standardized device data objects and device health scores, predicts future traffic usage trends, performs multi-scenario analysis and alarms, and generates traffic prediction values ​​and cost optimization suggestions.

[0013] The elastic scaling module, based on standardized device data objects, device behavior anomaly detection results, device health scores, command delivery status, and traffic prediction values, generates system processing load and real-time performance indicators to perform multi-level elastic scaling and intelligent scheduling, resulting in system resource configuration and scaling operation logs.

[0014] In a preferred embodiment, the protocol identification module includes:

[0015] The frequency of each byte value in the statistical data packet is counted, and the information entropy value is calculated. When the entropy value is greater than the preset encryption judgment threshold, it is determined to be in an encrypted state.

[0016] For encrypted data packets, extract device identification information from the data packets, query the encryption algorithm type and decryption key based on the device identification, and call the corresponding decryption function to decrypt;

[0017] Extract protocol feature vectors, including shallow features and deep features. Shallow features include total packet length, protocol header length, magic number field, version number field position, length field encoding method, and checksum type. Deep features include byte value distribution histogram, printable character ratio, and data payload structure level.

[0018] In a preferred embodiment, the protocol identification module further includes:

[0019] In the first stage, a fast matching algorithm is used to accurately match the shallow features with the protocol feature library. If the match is successful, the protocol type identifier is output and the recognition confidence is set to a preset high confidence value.

[0020] When fast matching fails or the confidence level is lower than the preset fast matching threshold, the second stage is entered, using a convolutional neural network model. The deep feature vector is used as input, and the probability distribution of each protocol type is output. The protocol type with the highest probability is used as the recognition result.

[0021] For data packets whose identification confidence is lower than the preset self-learning threshold, they are marked as samples to be confirmed and pushed to the manual review queue. After being marked, they are added to the protocol sample library. When the number of new samples reaches the preset sample threshold or the time since the last model training exceeds the preset training cycle, incremental training of the model is triggered.

[0022] In a preferred embodiment, the anomaly detection module includes:

[0023] For each device, a feature vector is constructed, including device model, working area, service type, average daily traffic, working time distribution, and traffic usage pattern.

[0024] The K-Means clustering algorithm is used to group all devices, calculate the Euclidean distance between each device and each cluster center, and assign the device to the group to which the nearest cluster center belongs. The assignment and update process is repeated until the cluster centers no longer change.

[0025] An Isolation Forest model is trained for each device group. Historical normal behavior data of all devices in the group is extracted as training samples, and training is completed by constructing multiple isolation trees.

[0026] In a preferred embodiment, the anomaly detection module further includes:

[0027] For newly connected devices, the similarity between the new device and the feature centers of each device group is calculated. The group with the highest similarity is selected as the group to which the new device belongs, and the Isolation Forest model of the group is used for anomaly detection.

[0028] Set a behavior data accumulation period for new devices, increase the anomaly threshold during the accumulation period, and restore the anomaly threshold to the normal level after the accumulation period ends;

[0029] Real-time extraction of device behavior characteristics, including current traffic usage, number of data uploads, average signal strength, and online duration, and calculation of standardized deviation from historical data for the same period;

[0030] The behavioral feature vector is input into the Isolation Forest model of the group to which the device belongs to calculate the anomaly score. A personalized threshold is determined based on the importance level and historical stability of the device. When the anomaly score is greater than the threshold, the current behavior of the device is determined to be abnormal.

[0031] In a preferred embodiment, the health assessment module includes:

[0032] Query the data records of the device within a preset time period, and calculate communication quality indicators, connection stability indicators, service normality indicators, and traffic usage indicators;

[0033] The minimum-maximum normalization method was used to normalize each indicator. Before normalization, the quartile method was used to identify outliers and the median was used instead.

[0034] The analytic hierarchy process (AHP) is used to determine the weight coefficients of the indicators. The first level determines the weights of the four categories, and the second level determines the weights of each indicator within each category. The weights of the two levels are multiplied together to obtain the final weight of each indicator.

[0035] The overall health score of the equipment is calculated using a weighted summation method.

[0036] The results of abnormal equipment behavior detection are used as correction factors, and points are deducted according to the severity of the abnormality.

[0037] In a preferred embodiment, the instruction scheduling module includes:

[0038] Priority levels are assigned based on instruction type. Instructions are divided into urgent instructions, normal instructions, and low-priority instructions. Corresponding transmission strategies are assigned to instructions based on their priority levels.

[0039] Query the health score of the target device and assess the device's communication quality level based on the health score;

[0040] For emergency commands, a hybrid multi-channel concurrent transmission strategy is adopted, using the MQTT main channel, CoAP backup channel and SMS emergency channel to send commands simultaneously. Commands are considered to have been successfully delivered if any channel receives a confirmation message from the device within a preset timeout period.

[0041] In a preferred embodiment, the instruction scheduling module further includes:

[0042] For ordinary commands, a single-channel adaptive transmission strategy is adopted, and the optimal transmission channel is selected based on the device's health score and network quality indicators.

[0043] An adaptive retransmission mechanism is adopted to extract the average delay, packet loss rate and signal strength of communication records, calculate the network quality score, classify the network quality level according to the network quality score, and set different maximum retransmission times and retransmission intervals for different network quality levels.

[0044] For low-priority instructions, a batch delayed transmission strategy is adopted, which combines and packages the instructions for transmission. When the number of instructions in a device group in the buffer queue reaches a preset instruction number threshold or the time since the last transmission exceeds a preset time interval threshold, batch transmission is triggered.

[0045] In a preferred embodiment, the traffic prediction module includes:

[0046] Extract the traffic usage field from standardized device data objects, construct the device's historical traffic time series, and collect multi-dimensional features that affect traffic usage;

[0047] The flow time series was preprocessed, outliers were detected by standard deviation and replaced by the average of the preceding and following data, missing values ​​were filled by linear interpolation, and smoothing was performed by moving average.

[0048] A hybrid prediction model was constructed, using the Prophet model and the LightGBM model for prediction respectively. The prediction results were then fused using a dynamic weighting method, with the weights determined based on the average absolute percentage error of the two models on the validation set.

[0049] In a preferred embodiment, the traffic prediction module further includes:

[0050] For scenarios involving excessive traffic risk warnings, the predicted total traffic is calculated, and an excessive traffic risk warning event is generated when the predicted total traffic exceeds the preset excessive risk threshold of the remaining traffic.

[0051] For traffic waste alarm scenarios, calculate the traffic utilization rate, and generate a traffic waste alarm event when the traffic utilization rate is lower than the preset waste alarm threshold;

[0052] For abnormal traffic detection scenarios, the growth rate of predicted traffic and historical average traffic is calculated. When the growth rate exceeds the preset abnormal growth threshold, an abnormal traffic alarm event is generated. Root cause analysis is performed through multi-dimensional correlation analysis, and abnormal traffic is classified into four types: normal business growth, equipment failure, suspected security attack, and unknown cause.

[0053] The beneficial effects of this invention are as follows:

[0054] By employing multi-level feature extraction and a two-stage recognition model, the system achieves automatic identification and unified transcoding of multiple communication protocols. It comprehensively characterizes protocol features using a combination of shallow and deep features, and balances recognition speed and accuracy through a two-stage strategy of fast matching and deep learning classification. The protocol parser adopts a pluggable design to support hot updates, shortening the time required to integrate new protocols. A unified data model mapping mechanism eliminates processing barriers for heterogeneous data, enabling unified management and data interoperability of multi-protocol devices. A protocol self-learning mechanism continuously improves recognition capabilities through manual annotation and incremental model training, allowing the system to quickly adapt to new protocols. Device clustering and a lightweight anomaly detection model address the resource consumption and cold start issues in large-scale device scenarios.

[0055] By employing intelligent scheduling and a hybrid multi-channel concurrent transmission strategy, the delivery rate and real-time performance of commands in weak network environments are improved. The system selects the optimal transmission strategy based on command priority and device network status. Emergency commands are transmitted concurrently via MQTT, CoAP, and SMS channels to ensure reliable delivery even in weak network conditions. An adaptive retransmission mechanism dynamically adjusts the number of retransmissions and the retransmission interval based on network quality, significantly improving the delivery rate in weak network environments compared to a fixed retransmission strategy. A batch delayed transmission strategy reduces the communication overhead of low-priority commands. A real-time command status tracking mechanism allows administrators to clearly understand command execution status, improving the reliability and efficiency of remote operation and maintenance.

[0056] Through container orchestration and multi-level elastic scaling mechanisms, the system achieves high availability and high performance. The system adopts a cloud-native microservice architecture, supporting smooth scaling from tens of thousands to millions of devices. Predictive scaling mechanisms enable the system to proactively respond to load changes, avoiding service degradation caused by sudden traffic surges. Attached Figure Description

[0057] Figure 1 This is a module diagram of a SIM card management platform according to the present invention;

[0058] Figure 2 This is a flowchart of a SIM card management platform according to the present invention;

[0059] Figure 3 This is a flowchart of a SIM card management platform according to the present invention. Detailed Implementation

[0060] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0061] At least one embodiment of the present invention discloses a SIM card management platform, such as Figures 1 to 3 As shown, it includes:

[0062] Step 1: Obtain the raw data packets uploaded by the construction machinery and equipment, perform multi-level feature extraction and two-stage recognition to obtain standardized equipment data objects;

[0063] Specifically, the following steps are included:

[0064] Step 1.1: Determine the encryption status of the data packet;

[0065] Construction machinery equipment uploads collected data to the system's device access service via a built-in SIM card module using either the MQTT or CoAP protocol. The MQTT protocol is suitable for 4G and 5G network environments, while the CoAP protocol is suitable for NB-IoT network environments.

[0066] After receiving the raw data packet, the device access service determines whether the data packet has been encrypted based on the information entropy theory. The specific calculation process is as follows: the frequency of each byte value in the data packet from 0 to 255 is counted, and the information entropy value is calculated by weighted summation of the frequencies of each byte according to Shannon entropy theory. The system sets the entropy threshold to between 7.0 and 7.8, preferably 7.5. When the calculated entropy value is greater than this threshold, the data packet is determined to be in an encrypted state, and an encryption status indicator of true is output; otherwise, it is determined to be in a plaintext state, and an encryption status indicator of false is output.

[0067] Step 1.2, decrypt the data packet;

[0068] For data packets with a true encryption status, device identification information is extracted. Based on the device identification, the encryption configuration information of the device, including the encryption algorithm type and decryption key, is retrieved from the device management database. Supported encryption algorithms include AES-128, AES-256, and DES symmetric encryption algorithms. After obtaining the encryption algorithm type and decryption key, the corresponding decryption function is called to decrypt the data packet, obtaining the plaintext data packet. For data packets with a false encryption status, the original data packet is directly output as a plaintext data packet.

[0069] Step 1.3, extract protocol feature vectors;

[0070] The system employs a multi-level feature extraction method to characterize the protocol's features from different levels.

[0071] Shallow feature extraction focuses on the structured information and fixed fields of data packets, including: total packet length, protocol header length, magic number field, version number field position, length field encoding method, and checksum type. The magic number is a fixed identifier in the protocol header used to quickly identify the protocol type; for example, the magic number of the JT / T808 protocol is 0x7E.

[0072] Deep feature extraction focuses on the statistical characteristics and content patterns of data packets, including: byte value distribution histogram, proportion of printable characters, frequency of special characters, field delimiter patterns, and the degree of structure of data payload.

[0073] The extracted shallow and deep features are combined into a protocol feature vector, which comprehensively describes the protocol features of the data packet.

[0074] Step 1.4, identify the protocol type;

[0075] Protocol identification employs a two-stage strategy. The first stage uses a fast matching algorithm to precisely match the extracted shallow features with a protocol feature library. This library stores standard features of all known protocols, including key features such as the magic number, protocol header length, and the position of the length field. If all key features match successfully, a protocol type identifier is output, and the identification confidence level is set to 100%.

[0076] When fast matching fails or the confidence level falls below 95%, the system proceeds to the second stage of deep learning classification. This second stage uses a convolutional neural network model. This model takes deep feature vectors as input and extracts high-level abstract features through multiple convolutional and pooling operations, outputting a probability distribution for each protocol type. The model achieves a classification accuracy of over 98% on the test set. The protocol type with the highest probability in the probability distribution output by the deep learning model is taken as the recognition result, and its corresponding probability value is used as the recognition confidence level.

[0077] Step 1.5: Perform protocol self-learning;

[0078] For data packets with an identification confidence level below 80%, the system initiates a protocol self-learning mechanism. Low-confidence data packets are marked as samples awaiting confirmation and are temporarily parsed using a general parser. The general parser employs a heuristic approach, attempting to extract basic fields such as device identifiers and timestamps from the data packets to avoid data loss due to protocol identification failures.

[0079] The sample to be confirmed is pushed to the manual review queue, and protocol experts are notified to annotate it. After annotation, the sample becomes a new training sample and is added to the protocol sample library.

[0080] When the number of new samples added to the protocol sample library reaches a set threshold, such as 100 samples, or when the time since the last model training exceeds a set period, such as 7 days, the system automatically triggers incremental model training. Incremental training uses the new samples to fine-tune the existing deep learning model. After training is complete, the updated model is deployed to the production environment, thereby improving the accuracy and coverage of protocol recognition.

[0081] Step 1.6, parse the business fields;

[0082] After protocol identification, the corresponding protocol parser is loaded from the parser library based on the protocol type identifier. The parser library adopts a plug-in design, with each protocol corresponding to an independent parser plugin. To improve loading efficiency, a hierarchical caching mechanism is used. Parsers for frequently used protocols are preloaded into memory and remain resident during system startup, while parsers for less frequently used protocols are loaded on demand.

[0083] The loaded parser performs field parsing on the complete data packet, extracting the values ​​of each service field from the packet according to the field structure defined in the protocol specification. Service fields include device identifier, timestamp, location information, operating condition data, signal strength, etc. During the parsing process, the parser also needs to handle field encoding conversion, and outputs a data structure containing all service fields after parsing is completed.

[0084] Step 1.7: Generate standardized data objects;

[0085] Different protocols result in different naming and formats for business fields, necessitating mapping these heterogeneous fields to a unified standard data model. The standard data model defines a set of common field names and data types, such as unique device identifiers, data acquisition time, geographical location longitude and latitude, signal strength, network type, and traffic usage.

[0086] The mapping process employs a semantic matching engine, which maintains a field semantic dictionary that records the correspondences of identical semantic fields across different protocols. The semantic matching engine first performs fuzzy matching based on field names, and then verifies the data based on the field's data type and value range. For fields that cannot be automatically mapped, a visual configuration interface is provided, allowing users to manually establish mapping relationships. Mapping configurations support hot updates.

[0087] After mapping, the system populates the values ​​of all business fields into the corresponding fields of the standard data model, generating a standardized device data object. This object contains field names and data types in a uniform format, and can be directly used by backend modules such as data storage, business analysis, and alarm processing.

[0088] Step 2: Based on standardized equipment data objects, perform equipment grouping and lightweight anomaly detection to obtain equipment behavior anomaly detection results;

[0089] Specifically, the following steps are included:

[0090] Step 2.1, equipment clustering;

[0091] The purpose of device clustering is to group devices with similar behavioral patterns into the same group and train a shared anomaly detection model for each group. The clustering process first requires constructing a feature vector for each device, which includes the device's static attributes and dynamic behavioral statistics.

[0092] Static attribute characteristics include device model, working area, and business type. Dynamic behavioral statistical characteristics include average daily traffic, working time distribution, and traffic usage patterns. Average daily traffic is obtained by calculating the average of the daily traffic usage of the device over the past 30 days; working time distribution is obtained by calculating the percentage of online time of the device in each hour of a 24-hour day; traffic usage patterns are obtained by analyzing the stability and periodicity of traffic usage. Specifically, the calculation method is to calculate the coefficient of variation of daily traffic over the past 30 days. The coefficient of variation is equal to the standard deviation divided by the mean. A coefficient of variation less than 0.3 indicates stable traffic usage, a coefficient of variation between 0.3 and 0.6 indicates moderate fluctuation in traffic usage, and a coefficient of variation greater than 0.6 indicates large fluctuations in traffic usage.

[0093] After constructing the feature vectors, the K-Means clustering algorithm is used to group all devices. The clustering process includes: first, randomly selecting K devices as initial cluster centers, with K set between 15 and 30, preferably 20; then calculating the Euclidean distance between each device and each cluster center, and assigning the device to the group to which the nearest cluster center belongs; next, recalculating the feature mean of all devices in each group, which serves as the new cluster center; repeating the above assignment and update process until the cluster centers no longer change or the maximum number of iterations is reached.

[0094] After clustering is completed, a unique group identifier is assigned to each group, and the feature center and the list of included devices of the group are recorded.

[0095] Step 2.2, train the group anomaly detection model;

[0096] Isolation Forest is an anomaly detection algorithm based on the principle of random forests. Its core idea is that outliers are more easily isolated. The algorithm constructs multiple isolation trees, each randomly selecting a feature and a splitting value to recursively partition the data space. Outliers, because their feature values ​​deviate from the normal range, are usually isolated at shallower tree levels, while normal points require deeper tree levels to be isolated.

[0097] The process of training an Isolation Forest model for each device group is as follows: Historical behavior data from the past 30 days for all devices within the group is extracted from a time-series database, and normal behavior data is selected as training samples. A behavior feature vector is constructed for each training sample, including features such as hourly traffic usage, number of data uploads, average signal strength, online duration, network latency, and packet loss rate.

[0098] The Isolation Forest model is trained using the training dataset. The model's hyperparameters include the number of isolation trees, the maximum depth of each tree, and the sampling ratio. The number of isolation trees is set between 80 and 150, preferably 100; the maximum depth of each tree is set between 6 and 10, preferably 8; and the sampling ratio is set between 0.7 and 0.9, preferably 0.8.

[0099] After training, the model can calculate anomaly scores for new behavioral feature vectors, with scores ranging from 0 to 1. Higher scores indicate a greater likelihood of an anomaly. One Isolation Forest model is trained for each device group, for a total of 20 models.

[0100] Step 2.3, handle the cold start of the new equipment;

[0101] Newly connected devices lack historical behavior data, making it impossible to train independent anomaly detection models. The system addresses this issue through a device clustering strategy, allowing new devices to directly use shared models from similar groups.

[0102] The matching process includes: extracting the basic attributes of the new device, including device model, working area, and business type; calculating the similarity between the new device and the feature centers of each device group, using Euclidean distance as the similarity metric; selecting the group with the highest similarity as the group to which the new device belongs; assigning the new device to this group and using the Isolation Forest model of this group for anomaly detection.

[0103] To reduce the false alarm rate, the system sets a 7-day behavioral data accumulation period for new devices. During this period, the system reduces the sensitivity of anomaly detection, raising the anomaly threshold from the normal 0.8 to 0.9. After the accumulation period, the anomaly threshold for new devices is restored to the normal level of 0.8.

[0104] Step 2.4: Extract real-time behavioral features;

[0105] For each device, the system extracts its current behavioral features in real time for anomaly detection. The behavioral features are extracted every hour, meaning that features are extracted and anomaly detection is performed once per hour.

[0106] The feature extraction process includes: querying the time-series database for all data records of the device within the current hour; and calculating various statistical indicators, including traffic usage, number of data uploads, average signal strength, and online duration.

[0107] In addition to the current hourly statistics, it is also necessary to extract the degree of deviation from historical data for the same period. The deviation is calculated as follows: extract the traffic usage for the same hour over the past 30 days from historical data, calculate the historical average and standard deviation; calculate the difference between the current traffic and the historical average, divide by the standard deviation, and obtain the standardized deviation. The system calculates the standardized deviation for four indicators: traffic usage, number of data uploads, signal strength, and online duration.

[0108] The statistical indicators and standardized deviations of the current hour are combined into a behavioral feature vector, which contains feature values ​​in 8 dimensions.

[0109] Step 2.5, detect abnormal behavior;

[0110] The behavioral feature vector extracted in step 2.4 is input into the Isolation Forest model of the device's group, and the model calculates anomaly scores. The anomaly score ranges from 0 to 1, with scores closer to 1 indicating a higher probability of an anomaly.

[0111] The system employs a tiered anomaly threshold strategy, determining personalized thresholds based on the importance level and historical stability of each device. Device importance is categorized into critical and general devices. Critical devices are defined as key business equipment or high-value equipment, identified through device attribute identifiers in the device management system. The threshold for critical devices is set at 0.7, and the threshold for general devices is set at 0.8. If a device's false alarms account for more than 50% of all alarms, its threshold is increased to 0.85.

[0112] The calculated anomaly score is compared with the device's personalized threshold. If the anomaly score is greater than the threshold, the device's current behavior is determined to be abnormal, and a device behavior anomaly flag is output as true; otherwise, a device behavior anomaly flag is output as false.

[0113] Step 2.6, analyze the root causes of the anomalies;

[0114] When a device is identified as behaving abnormally, the system needs to further analyze the root cause of the anomaly. Root cause analysis compares the standardized deviations of each dimension in the behavioral feature vector to identify the dimension with the most severe deviation.

[0115] The system takes the absolute value of the deviations in traffic usage, data upload frequency, signal strength, and online duration, sorts them, and selects the dimension with the largest absolute value as the main anomaly dimension.

[0116] If the traffic usage deviation is the largest, the anomaly type is determined to be a traffic anomaly. A positive deviation greater than 2 indicates a sudden increase in traffic, and a negative deviation less than -2 indicates a sudden decrease in traffic. If the data upload count deviation is the largest, the anomaly type is determined to be an upload anomaly. If the signal strength deviation is the largest, the anomaly type is determined to be a signal anomaly. If the online duration deviation is the largest, the anomaly type is determined to be an online anomaly.

[0117] The system also assesses the severity of the anomaly. Severity is determined based on the absolute value of the standardized deviation: an absolute value between 2 and 3 indicates a mild anomaly, an absolute value between 3 and 5 indicates a moderate anomaly, and an absolute value greater than 5 indicates a severe anomaly.

[0118] The system also analyzes the context information of the device to determine whether the anomaly is caused by normal business changes, and filters out false alarms caused by normal business changes through context correlation analysis.

[0119] Root cause analysis results include information such as anomaly type, anomaly severity, possible causes, and whether it is a normal business change.

[0120] Step 2.7, optimize the anomaly detection model;

[0121] The system establishes an anomaly feedback mechanism, allowing maintenance personnel to confirm or mark system-generated anomaly alarms as false alarms. When the system detects a device anomaly and generates an alarm event, maintenance personnel handle the alarm according to the actual situation. The handling results include: confirming it as a real anomaly, marking it as a false alarm, or leaving it uncertain.

[0122] For alarms confirmed as genuine anomalies, the system adds the sample to the anomaly sample library. For alarms marked as false alarms, the system analyzes the cause of the false alarm and adjusts the detection parameters, while also adding the sample to the normal sample library.

[0123] The system automatically triggers a model update process weekly, retraining the Isolation Forest model using the latest normal and abnormal samples. The update process includes: extracting new samples from the past 7 days from the sample database and merging them with the original training dataset; retraining the model using the updated training dataset; evaluating the performance of the new model on the validation dataset; and deploying the new model to the production environment if its performance is better than the old model.

[0124] Through anomaly feedback and model update mechanisms, the system's anomaly detection capabilities are continuously optimized.

[0125] Step 2 outputs the results of abnormal equipment behavior detection, including anomaly identification and root cause analysis results, providing a basis for subsequent equipment health assessment and operation and maintenance decisions.

[0126] Step 3: Based on standardized equipment data objects, multi-dimensional indicators are fused, hierarchical analysis is performed according to the anomaly detection results, the health status of the equipment is evaluated, and the equipment health score and diagnostic report are obtained.

[0127] Specifically, the following steps are included:

[0128] Step 3.1: Extract health assessment indicators;

[0129] Equipment health assessment requires comprehensive consideration of multiple dimensions of indicators, as a single indicator cannot fully reflect the true state of the equipment. The system queries the time-series database for all data records of the equipment over the past 24 hours and calculates 12 dimensions of health assessment indicators based on these records.

[0130] The metrics are divided into four categories: The first category is communication quality metrics, including mean signal strength, signal strength variance, mean network latency, maximum network latency, and packet loss rate. The mean signal strength is calculated by taking the arithmetic mean of the signal strength fields of all data records over 24 hours, reflecting the average signal level of the device. The signal strength variance is calculated by taking the variance of the signal strength, reflecting signal stability; a larger variance indicates greater signal fluctuation. The mean network latency is calculated by taking the average time difference between the device uploading data and the platform receiving data, reflecting the network transmission speed. The maximum network latency records the maximum latency that occurred within 24 hours, reflecting the worst-case network conditions. The packet loss rate is obtained by statistically analyzing the proportion of lost packets among the data packets uploaded by the device. Lost packets refer to data packets sent by the device but not received by the platform, identified by the discontinuity of the packet sequence number.

[0131] The second category is connection stability indicators, including online time percentage, number of disconnection reconnections, and signal switching frequency. Online time percentage is calculated by dividing the device's online time by 24 hours, reflecting the device's connection continuity. Disconnection reconnection frequency is calculated by counting the number of times the device changes from online to offline and back to online within 24 hours, reflecting connection stability. Signal switching frequency is calculated by counting the number of times the device switches between different base stations or network types; frequent switching may lead to communication interruptions.

[0132] The third category is business normalization indicators, including data upload success rate, device response time, and the proportion of abnormal data packets. The data upload success rate is calculated by dividing the number of successfully uploaded data packets by the total number of uploaded data packets, reflecting the reliability of data transmission; the device response time is calculated by the average time interval between the platform sending a command to the device and the device returning a response, reflecting the device's response speed; the proportion of abnormal data packets is calculated by statistically analyzing the proportion of data packets that cannot be correctly parsed or fail to be verified out of the total number of data packets, reflecting data quality.

[0133] The fourth category is traffic usage metrics, including traffic usage volume and the regularity of traffic usage patterns. Traffic usage volume is obtained by accumulating the total traffic consumed by the device over 24 hours; the regularity of traffic usage patterns is obtained by analyzing the distribution of traffic usage per hour over 24 hours and calculating the entropy value of the distribution. The lower the entropy value, the more regular the traffic usage; the higher the entropy value, the more random the traffic usage.

[0134] After extraction, the original indicator dataset containing 12 dimensions of indicator values ​​is obtained.

[0135] Step 3.2, normalize the indicator data;

[0136] Because the 12 indicators have different dimensions and numerical ranges, normalization is required. The system uses a min-maximum normalization method to map each indicator to the interval between 0 and 1. The normalization process involves subtracting the minimum value from the original value and then dividing by the difference between the maximum and minimum values. The minimum and maximum values ​​are determined based on historical statistical data.

[0137] Before normalization, outlier filtering is required. The system uses the quartile method to identify outliers: the index values ​​are sorted from smallest to largest, and the first and third quartiles are calculated; the interquartile range is calculated; the upper bound of outliers is defined as the third quartile plus 1.5 times the interquartile range, and the lower bound is the first quartile minus 1.5 times the interquartile range; values ​​exceeding the upper bound or falling below the lower bound are considered outliers and replaced by the median.

[0138] Outlier filtering and normalization were performed on the 12 dimensions of indicators to obtain a normalized indicator dataset.

[0139] Step 3.3: Determine the indicator weighting coefficients;

[0140] Different dimensions of indicators have varying degrees of impact on equipment health, requiring the allocation of different weighting coefficients. The weighting coefficients are determined using the Analytic Hierarchy Process (AHP), which transforms subjective judgments into objective weight values ​​by constructing a hierarchical structure model and pairwise comparison matrices.

[0141] The Analytic Hierarchy Process (AHP) groups the 12 indicators into four categories: communication quality, connection stability, service normality, and traffic usage. It determines the weights at two levels: the first level determines the weights of the four categories, and the second level determines the weights of each indicator within each category.

[0142] The weights for the first level were determined based on expert experience and historical failure data analysis. By analyzing equipment communication failure cases from the past year, the proportion of failures caused by abnormal indicators was statistically analyzed. The weights for the four categories were set to 0.35, 0.30, 0.25, and 0.10, respectively.

[0143] The second level of weighting is determined within each category. The relative importance of each indicator is determined through expert scoring and pairwise comparisons. The weights from both levels are then multiplied to obtain the final weight of each indicator in the overall health assessment.

[0144] Step 3.4, calculate the health score;

[0145] The overall health score of the equipment is calculated using a weighted summation method. The 12 normalized index values ​​obtained in step 3.2 are multiplied by the corresponding weight coefficients obtained in step 3.3 to obtain 12 weighted values; the 12 weighted values ​​are summed to obtain the overall score, which ranges from 0 to 1; the overall score is multiplied by 100 to obtain the final health score, which ranges from 0 to 100.

[0146] A higher score indicates a better communication health status for the device, while a lower score indicates a worse health status.

[0147] Step 3.5, correct the health score;

[0148] The anomaly detection results in Step 2 provide information about abnormal equipment behavior, which should be reflected in the health score. The system uses the anomaly detection results as a correction factor for the health score, deducting points according to the severity of the anomaly. A minor anomaly corresponds to a deduction of 5 points, a moderate anomaly to a deduction of 10 points, and a severe anomaly to a deduction of 20 points.

[0149] The correction process is as follows: if the device behavior anomaly flag output in step 2 is true, the corresponding deduction value is subtracted from the health score calculated in step 3.4 to obtain the corrected health score; if the anomaly flag is false, the health score remains unchanged.

[0150] Step 3.6: Classify health levels;

[0151] The system classifies devices into four health levels based on the revised health score: Excellent, Good, Average, and Poor. The classification criteria are as follows: a score between 90 and 100 is Excellent; a score between 75 and 89 is Good; a score between 60 and 74 is Average; and a score below 60 is Poor.

[0152] For devices with a poor health rating, the system generates a health alarm event. The alarm event includes basic information such as device identifier, health score, health level, and alarm time, and is pushed to the operation and maintenance management platform.

[0153] Step 3.7: Generate a diagnostic report;

[0154] For devices with low health scores, the system analyzes the main reasons for the low scores and generates detailed diagnostic reports.

[0155] The diagnostic report comprises four parts. The first part is anomaly identification, where the system compares the normalized values ​​of 12 dimensions with normal thresholds to identify the three dimensions with the most significant deviations. The second part is trend analysis, where the system queries the device's health score history over the past 7 days and analyzes the trend of score changes. The third part is possible causes of failure, where the system infers possible causes of failure based on the anomaly dimensions and the device's contextual information. The fourth part is recommended remedial measures, where the system provides corresponding remedial suggestions based on the inferred causes of failure.

[0156] The diagnostic report is output in a structured format for maintenance personnel to refer to.

[0157] Step 3 outputs device health scores and diagnostic reports, providing a basis for subsequent command scheduling and operation and maintenance decisions.

[0158] Step 4: Based on the device health score and diagnostic report, allocate transmission strategies and channels, send commands and record the status changes throughout the command lifecycle to obtain command delivery status and tracking information;

[0159] Specifically, the following steps are included:

[0160] Step 4.1: Parse the instructions and allocate the transmission strategy;

[0161] The management platform issues various control commands to the devices based on business needs. Upon receiving a command, the system parses the command type field and assigns a priority level based on the command type. Commands are divided into three priorities: Priority 1 is emergency commands, including safety-related commands such as remote engine shutdown, vehicle locking, and emergency shutdown; Priority 2 is normal commands, including routine management commands such as parameter configuration, data query, and remote diagnostics; Priority 3 is low-priority commands, including auxiliary function commands such as firmware upgrade notifications, statistical information reporting, and log collection.

[0162] Based on priority levels, the system assigns corresponding transmission strategies to commands. Priority 1 urgent commands employ a hybrid multi-channel concurrent transmission strategy, simultaneously using the MQTT primary channel, CoAP backup channel, and SMS emergency channel. Priority 2 normal commands employ a single-channel adaptive transmission strategy, selecting the optimal transmission channel based on the device's network status and health score. Priority 3 low-priority commands employ a batch delayed transmission strategy, merging multiple commands into a single package for transmission.

[0163] The system assigns a unique instruction ID to each instruction for subsequent status tracking and acknowledgment matching.

[0164] Step 4.2, assess the device communication quality;

[0165] Before sending commands, the system needs to assess the current communication status of the target device. The system retrieves the target device's health score and detailed indicators from the device health assessment results in step 3.

[0166] The device's communication quality level is assessed based on its health score. A health score greater than 75 indicates good communication; commands can be sent immediately. A health score between 60 and 75 indicates fair communication; ordinary commands can be sent but require increased retransmission attempts, while urgent commands are still sent immediately. A health score below 60 indicates poor communication; low-priority commands should be delayed, while ordinary and urgent commands are sent immediately but require enhanced transmission strategies.

[0167] The system also checks the device's online status. If the device is currently offline, the command cannot be delivered immediately and needs to be added to the pending delivery queue. For urgent commands, the system attempts to send them via SMS even if the device is offline.

[0168] Output device communication quality assessment results.

[0169] Step 4.3: Emergency commands are transmitted concurrently through multiple channels;

[0170] Emergency commands employ a hybrid multi-channel concurrent transmission strategy, using three independent communication channels simultaneously: the MQTT main channel, the CoAP backup channel, and the SMS emergency channel.

[0171] The MQTT primary channel is based on the TCP protocol and is suitable for 4G and 5G network environments. The CoAP backup channel is based on the UDP protocol and is suitable for NB-IoT network environments. The SMS emergency channel is based on GSM SMS service and does not rely on a data network.

[0172] The system sends commands simultaneously through three channels. Each channel has an independent timeout timer set to 3 seconds. If any channel receives an acknowledgment message from the device within 3 seconds, the command is considered successfully delivered, and the system immediately cancels the sending tasks on the other channels. If no acknowledgment message is received by any channel within 3 seconds, the first transmission is considered a failure, and all three channels simultaneously perform their first retransmission. Output the sending tasks for the three channels.

[0173] Step 4.4, Adaptive channel selection for normal instructions;

[0174] Ordinary commands employ a single-channel adaptive transmission strategy, selecting the optimal transmission channel based on the device's real-time status.

[0175] The channel selection decision is based on the device's health score and network quality indicators. If the device's health score is greater than 80 and the 4G or 5G signal strength is good, the MQTT primary channel is selected; good signal strength is defined as a signal strength greater than -70dBm. If the device's health score is between 60 and 80, or the 4G and 5G signals are average, the CoAP backup channel is selected; average signal strength is defined as a signal strength between -70dBm and -90dBm. If the device's health score is below 60, or the 4G and 5G signals are poor, but the NB-IoT signal is available, the NB-IoT low-power channel is selected; poor signal strength is defined as a signal strength below -90dBm.

[0176] After selecting a transmission channel, the system sends commands through that channel. The sent task includes information such as channel type, command content, target device, and timeout. The timeout is set to 10 seconds.

[0177] Output single-channel send task.

[0178] Step 4.5, Adaptive retransmission mechanism;

[0179] The adaptive retransmission mechanism dynamically adjusts the number of retransmissions and the retransmission interval based on network quality, achieving a high delivery rate in different network environments.

[0180] The system extracts network quality-related metrics from the most recent 10 communication records, including average latency, packet loss rate, and signal strength. Based on these three metrics, a network quality score is calculated, and the network quality is categorized into three levels: Excellent, Average, and Poor. A network quality score greater than 80 is considered Excellent, a score between 60 and 80 is Average, and a score less than 60 is Poor.

[0181] Different retransmission parameters are set for different network quality levels. When network quality is excellent, the maximum number of retransmissions is set to 2, and the retransmission interval is set to 1 second. When network quality is average, the maximum number of retransmissions is set to 3, and the retransmission interval is set to 2 seconds. When network quality is poor, the maximum number of retransmissions is set to 5, and the retransmission interval adopts an exponential backoff strategy, with each retransmission interval being twice the time of the previous one, and the maximum retransmission interval not exceeding 16 seconds.

[0182] Output retransmission strategy configuration, including parameters such as maximum number of retransmissions and retransmission interval sequence.

[0183] Step 4.6, low-priority instructions are transmitted in batches;

[0184] Low-priority instructions employ a batch delayed transmission strategy, combining multiple instructions into a single package for transmission to reduce the number of communications and communication overhead.

[0185] The system maintains a buffer queue for low-priority instructions, and newly received low-priority instructions are added to the buffer queue. The buffer queue is grouped according to the target device ID.

[0186] There are two triggering conditions for batch transmission: first, the number of instructions for a device group in the buffer queue reaches a threshold, which is set to 50; second, the time since the last transmission exceeds a time threshold, which is set to 5 minutes. If either triggering condition is met, the system will perform batch transmission for that device group.

[0187] During batch transmission, the system merges all instructions in the device group into a single data packet. This packet is then sent to the device via the selected transmission channel. Upon receiving the packet, the device parses the header to obtain the number of instructions, then parses and executes each instruction in the packet body. The next time the device proactively reports data, it includes batch confirmation information in the reported data packet.

[0188] After receiving the batch confirmation information from the devices, the system updates the status of the instructions based on the instruction ID list.

[0189] Output batch send tasks.

[0190] Step 4.7, Real-time tracking of instruction status;

[0191] The system establishes a state machine and change log for each instruction, enabling full lifecycle state tracking.

[0192] The instruction state machine includes the following states: Created, Queued, Sending, Delivered, Executing, Execution Successful, Execution Failed, and Sending Failed. An instruction undergoes multiple state transitions during its lifecycle, and each transition is recorded in the change log. The change log includes information such as the change time, the state before the change, the state after the change, and the reason for the change.

[0193] The system provides an interface for querying command status, allowing administrators to query the current status, historical status change records, number of retransmissions, and estimated delivery time of commands in real time using the command ID.

[0194] For commands that fail to be sent, the system automatically generates an alarm event and pushes it to the operation and maintenance platform.

[0195] Step 4 outputs the instruction delivery status and tracking information, including the real-time status of each instruction, a complete status change log, the number of retransmissions, the estimated delivery time, and alarm events for instructions that failed to be sent.

[0196] Step 5: Based on standardized device data objects and device health scores, build a prediction model to predict future traffic usage trends, perform multi-scenario analysis and alarms, and generate traffic prediction values ​​and cost optimization suggestions.

[0197] Specifically, the following steps are included:

[0198] Step 5.1: Extract traffic data and features;

[0199] The system extracts the traffic usage field from the standardized device data object generated in step 1, and combines it with historical data stored in the time series database to construct a traffic time series of the device over the past 90 days.

[0200] In addition to the traffic data itself, the system also needs to collect multi-dimensional features that influence traffic usage. These features are categorized into four types: time features, device features, environmental features, and business features. Time features include day of the week, month, whether it's a holiday, and whether it's peak construction season. Device features include device model, operating mode, and business type. Environmental features include geographical location, climate conditions, and network coverage quality. Business features include the number of tasks, data reporting frequency, and number of remote commands.

[0201] After collection, a dataset containing traffic time series and multi-dimensional features is obtained.

[0202] Step 5.2, preprocessing of the flow sequence;

[0203] The raw traffic time series may contain outliers, missing values, and noise, and requires preprocessing.

[0204] Outlier detection employs the 3-standard-deviation method: the mean and standard deviation of the flow series are calculated, and the upper bound for outliers is defined as the mean plus 3 standard deviations, while the lower bound is the mean minus 3 standard deviations. Data points exceeding the upper or lower bounds are marked as outliers. For detected outliers, the average of the preceding and following data is used as a replacement.

[0205] Missing value imputation uses linear interpolation: for a missing value data point, find the nearest non-missing value before it and the nearest non-missing value after it, and calculate the missing value through linear interpolation.

[0206] The smoothing process uses the moving average method: the system uses a 7-day moving average. For each data point in the sequence, the average of the flow rate values ​​for that data point and the 3 days before and after it, for a total of 7 days, is calculated.

[0207] After preprocessing, a flow sequence with outliers removed, missing values ​​filled, and noise reduced is obtained.

[0208] Step 5.3: Construct a hybrid prediction model;

[0209] This invention employs a hybrid prediction model that combines the advantages of the Prophet model and the LightGBM model.

[0210] The Prophet model is an open-source time series forecasting tool from Facebook that decomposes time series data into three components: trend, seasonality, and holiday. The system trains the Prophet model using traffic time series data from the past 90 days. After training, the model can predict traffic usage for the next 7 and 30 days and provide confidence intervals for the predictions.

[0211] The LightGBM model is an open-source gradient boosting decision tree algorithm from Microsoft. The system performs feature engineering on the LightGBM model, including the multi-dimensional features collected in step 5.1 and statistical features extracted from the traffic sequences. The features and their corresponding traffic values ​​are organized into a training dataset, using data from the past 90 days as the training set.

[0212] The hyperparameters of the LightGBM model include the number of trees, the maximum tree depth, and the learning rate. The number of trees is set to 100, the maximum tree depth to 6, and the learning rate to 0.1.

[0213] After training is complete, the trained Prophet model and LightGBM model are output.

[0214] Step 5.4, predict future traffic;

[0215] The prediction process of the hybrid model uses the Prophet model and the LightGBM model for prediction, and then the prediction results of the two models are fused.

[0216] The Prophet model takes historical traffic time series and future time points as input, and outputs the predicted traffic value and confidence interval for each future time point. The system uses the Prophet model to predict daily traffic usage for the next 7 and 30 days.

[0217] The LightGBM model takes feature vectors for each future time point as input and outputs predicted traffic flow values. The system constructs feature vectors for each day of the next 7 and 30 days, inputs these feature vectors into the LightGBM model, and obtains the predicted traffic flow values.

[0218] The fusion process employs a dynamic weighting method, with weights determined based on the prediction errors of the two models on the validation set. The prediction error is measured using the mean absolute percentage error (MASE). The system calculates the MASE of the Prophet and LightGBM models on the validation set separately, and then calculates the weights based on the errors of the two models.

[0219] The final predicted value is calculated by weighted averaging: the predicted value of the Prophet model is multiplied by the Prophet model weights, and the predicted value of the LightGBM model is multiplied by the LightGBM model weights to obtain the final predicted value.

[0220] Output the traffic forecast values ​​and confidence intervals for the next 7 days and 30 days.

[0221] Step 5.5, Multi-scenario analysis and alarms;

[0222] The system analyzes and issues alerts for three typical scenarios.

[0223] Scenario 1 is a traffic overage risk warning. The system queries the device's current data plan information and calculates the predicted total data usage for the next 7 days. It compares the predicted total data usage with the remaining data usage. If the predicted total data usage exceeds 90% of the remaining data usage, a traffic overage risk warning event is generated. The warning event is pushed to the operations and maintenance management platform and the user's mobile app.

[0224] Scenario 2 is a data usage waste alert. The system calculates the predicted total data usage over 30 days and determines the data usage rate. If the data usage rate is below 50%, it indicates that the device's data plan is configured too high, generating a data usage waste alert event. The alert event includes the recommended data plan and the expected cost savings.

[0225] Scenario 3 is abnormal traffic detection. The system calculates the growth rate of predicted traffic compared to the historical average traffic. If the growth rate exceeds 50%, it indicates abnormal growth in predicted traffic, and an abnormal traffic alarm event is generated.

[0226] Output a list of traffic alarm events.

[0227] Step 5.6, Root cause analysis of abnormal traffic;

[0228] For the abnormal traffic detected in Scenario 3, the system needs to further analyze the root cause and risk level of the anomaly.

[0229] Root cause analysis is conducted through multi-dimensional correlation analysis, including dimensions such as changes in device operating modes, changes in geographical location, changes in data reporting frequency, and signs of security attacks.

[0230] Device operating mode change analysis is performed by comparing the operating time distribution of the most recent 7 days with that of the historical 30 days. Geographic location change analysis is performed by comparing the device's GPS coordinates. Data reporting frequency change analysis is performed by comparing the number of data reports in the most recent 7 days with that of the historical 30 days. Security attack indication analysis is performed by analyzing the time patterns and target addresses of traffic usage.

[0231] Based on the root cause analysis results, the system categorizes abnormal traffic into four types: normal business growth, equipment failure, suspected security attack, and unknown cause. For each type, the system assesses the risk level, which is divided into three levels: low risk, medium risk, and high risk. The risk level for normal business growth is low; for equipment failure, it's medium risk; for suspected security attack, it's high risk; and for unknown cause, the risk level is determined by the traffic growth rate: a growth rate between 50% and 100% is medium risk, and a growth rate exceeding 100% is high risk.

[0232] Output an abnormal traffic analysis report.

[0233] Step 5.7: Generate cost optimization suggestions;

[0234] The ultimate goal of traffic management is to minimize communication costs while ensuring business needs are met. The system generates traffic management optimization reports based on traffic prediction and analysis results.

[0235] For a single device, the optimization report includes: current plan usage efficiency analysis, recommended optimal plan, expected cost savings, and the best time to switch plans.

[0236] For enterprise users managing multiple devices, the system offers batch data plan optimization solutions. The system categorizes devices into three groups—high-traffic, medium-traffic, and low-traffic—based on their data usage patterns. Grouping is based on the device's average monthly data usage: devices with an average monthly data usage greater than 2GB are classified as high-traffic, those between 500MB and 2GB as medium-traffic, and those less than 500MB as low-traffic. The system selects the most economical data plan for each group: high-traffic groups are recommended to use large-traffic or unlimited plans, medium-traffic groups to use standard plans, and low-traffic groups to use small-traffic or pay-as-you-go plans. The system also considers data plan sharing and data pooling functionality; for multiple devices within the same enterprise, it assesses whether data pooling can reduce overall costs.

[0237] The batch optimization solution output includes information such as device grouping results, recommended packages for each group, traffic pool configuration suggestions, and estimated total cost savings.

[0238] Output traffic management optimization reports and cost optimization suggestions.

[0239] Step 5 outputs traffic forecasts and cost optimization suggestions, including: traffic forecasts and confidence intervals for the next 7 days and 30 days; a list of traffic alarm events; an abnormal traffic analysis report; a traffic management optimization report; and cost optimization suggestions.

[0240] Step 6: Based on standardized equipment data objects, equipment behavior anomaly detection results, equipment health scores, command delivery status, and traffic prediction values, the system processing load and real-time performance indicators are generated to perform multi-level elastic scaling and intelligent scheduling, and obtain system resource configuration and scaling operation logs.

[0241] Specifically, the following steps are included:

[0242] Step 6.1, Deploy load monitoring;

[0243] The system adopts a microservice architecture, comprising multiple service components. A distributed load monitoring system is deployed, with monitoring agents deployed on the runtime nodes of each service component. Monitoring metrics are divided into four categories: resource metrics include CPU utilization, memory usage, disk I / O, and network bandwidth utilization; business metrics include the number of connected devices, data processing throughput, and command issuance success rate; performance metrics include API response time, message queue backlog, and database query latency; and availability metrics include service health check status, error rate, and timeout rate.

[0244] The monitoring agent collects performance metrics every 10 seconds and reports the metric data to the monitoring center.

[0245] Step 6.2: Calculate the load score and identify bottlenecks;

[0246] The system uses a weighted scoring method to calculate the overall load score. The weights are allocated as follows: CPU utilization 0.25, memory usage 0.20, message queue backlog 0.20, API response time 0.15, data processing throughput 0.10, and error rate 0.10.

[0247] The load score ranges from 0 to 100, with a higher score indicating a heavier system load. The system also identifies load bottleneck components, compares the load scores of each service component, and finds the component with the highest score.

[0248] Step 6.3, trigger the elastic scaling decision;

[0249] The system employs a multi-level elastic scaling strategy, combining reactive scaling and predictive scaling mechanisms.

[0250] Reactive scaling is triggered based on real-time load metrics. A scaling-up operation is triggered when the overall load score remains above 75 for 5 consecutive minutes. A scaling-down operation is triggered when the overall load score remains below 40 for 10 consecutive minutes.

[0251] Predictive scaling is triggered based on historical load trends and business forecasts. The system analyzes load data from the past 30 days, identifies periodic patterns in the load, predicts future load trends, and executes scaling operations in advance.

[0252] Business-driven scaling is triggered by business events, such as adjusting resource configurations in advance when planning to connect new devices or upgrade systems.

[0253] Step 6.4: Perform intelligent capacity expansion;

[0254] Scaling strategies are divided into two types: horizontal scaling and vertical scaling. Horizontal scaling increases the number of service instances and is suitable for stateless services. Vertical scaling increases the resource quota of a single service instance and is suitable for stateful services.

[0255] The capacity expansion rate is dynamically determined based on the load score: when the load score is between 75 and 85, the capacity expansion rate is 20%; when the load score is between 85 and 95, the capacity expansion rate is 50%; and when the load score is above 95, the capacity expansion rate is 100%.

[0256] After the expansion operation is executed, the system records the expansion log and continuously monitors the load changes after the expansion.

[0257] Step 6.5: Perform graceful scaling down;

[0258] When a scaling-down decision is triggered, the system needs to perform a graceful scaling-down operation to ensure that the scaling-down process does not affect ongoing business operations and avoids data loss and service interruption.

[0259] Graceful scaling down involves five key steps. When selecting a scaling-down target, the system chooses the service instance with the lowest load to take offline. Load is comprehensively evaluated based on metrics such as instance CPU utilization, memory usage, and number of requests processed. Taking offline the instance with the lowest load minimizes the impact on the overall service.

[0260] The target instance is removed from the load balancer pool. The load balancer maintains a list of available instances and distributes requests to instances in the list. The system removes the target instance from the available list via the load balancer's API, stopping the distribution of new requests to that instance. However, the instance continues to process requests it has already received.

[0261] Waiting for existing requests to complete. The system monitors the number of active connections and pending requests on the target instance. When these values ​​drop to 0, it indicates that all requests have been processed. To avoid indefinite waiting, the system sets a graceful shutdown timeout, which defaults to 30 seconds. If there are still unfinished requests after the timeout period, the system forcibly shuts down the instance, but logs an alert for later analysis.

[0262] Handle state migration for stateful services. For stateful services, such as database connection pools and caching services, state migration and data synchronization are required before shutting down the instance. State migration for database connection pools includes closing all database connections to ensure there are no uncommitted transactions. State migration for caching services includes synchronizing cached data to other instances or persistent storage to ensure no data loss.

[0263] Shutting down instances and releasing resources. The system deletes Pods through the Kubernetes API, and Kubernetes automatically reclaims the computing resources occupied by the Pods. For virtual machine instances on cloud platforms, the system stops or deletes the instances through the cloud platform's API, releasing computing resources and ceasing billing.

[0264] After the scaling down operation is executed, the system records a scaling down log, including information such as the scaling down time, the components being scaled down, the number of instances before scaling down, the number of instances after scaling down, and the reason for scaling down. Simultaneously, the system continuously monitors load changes after scaling down and evaluates the scaling down effect. If the load score remains below 40 after scaling down, further scaling down may be necessary; if the load score rises above 75, it indicates excessive scaling down, and resizing is required.

[0265] Output the service instance configuration after scaling down, including the number of instances and resource quotas for each service component.

[0266] Step 6.6: Manage resource quotas and optimize costs;

[0267] The system categorizes services into three importance levels: core services, support services, and auxiliary services. Core services include device access services and command issuance services; these directly affect device connectivity and control and have the highest priority. Support services include data storage services and monitoring and alarm services; these support the normal operation of the system and have a medium priority. Auxiliary services include log collection services and report generation services; these provide auxiliary functions and have the lowest priority.

[0268] Set resource quota limits for each service to prevent a single service from excessively consuming resources and impacting other services. Resource quotas include CPU quotas, memory quotas, disk quotas, and network bandwidth quotas. The quota limits are determined based on the service's historical resource usage and business needs, and are typically set at 2 to 3 times the average usage, leaving some margin to cope with load fluctuations.

[0269] When resources are scarce, the system allocates resources based on the importance level of services. Kubernetes' resource management mechanism supports two concepts: resource requests and resource limits. A resource request is the minimum resource required for a service to run, and Kubernetes guarantees that the service can obtain the requested resources. A resource limit is the maximum resource a service can use; exceeding the limit will result in rate limiting or termination of the service. The system sets higher resource requests and higher resource limits for core services to ensure that core services have sufficient resources under all circumstances. Lower resource requests and lower resource limits are set for auxiliary services, and resources for auxiliary services are preferentially compressed when resources are scarce.

[0270] In terms of cost optimization, the system leverages various billing models offered by the cloud platform to reduce costs. Cloud platforms typically provide three billing models: on-demand instances, reserved instances, and spot instances. On-demand instances are billed based on usage duration, offering high flexibility but are the most expensive. Reserved instances require pre-purchasing a certain period of usage rights and are 30% to 50% cheaper than on-demand instances, suitable for services requiring long-term stable operation. Spot instances utilize idle resources on the cloud platform and are 70% to 90% cheaper than on-demand instances, but may be reclaimed at any time, suitable for interruptible batch processing tasks.

[0271] The system selects an appropriate billing model based on the characteristics of the service. Core services use reserved instances to ensure stability and cost-effectiveness. Security services use on-demand instances to maintain flexibility. Auxiliary services prioritize spot instances to minimize costs, automatically switching to on-demand instances when spot instances are reclaimed.

[0272] The system regularly analyzes resource usage and cost expenditures, generating cost analysis reports. These reports include information such as resource usage, resource costs, cost percentages, and optimization suggestions for each service. Through cost analysis, the system identifies resource waste and cost optimization opportunities, continuously reducing operating costs.

[0273] Output resource quota configuration and cost analysis reports for system administrators to refer to and make decisions.

[0274] Step 6.7: Audit and optimize the scaling strategy;

[0275] The system establishes an auditing and optimization mechanism for scaling operations, recording detailed logs for all scaling operations. The system automatically triggers a scaling strategy optimization process weekly to evaluate the effectiveness of the scaling strategy. Evaluation metrics include the frequency of scaling operations, the degree of improvement in resource utilization, cost savings, and impact on service availability.

[0276] Based on the evaluation results, the system automatically adjusts the scaling strategy parameters to continuously optimize the effectiveness of the scaling strategy.

[0277] Step 6 outputs system resource configuration and scaling operation logs, including: real-time system load monitoring data; comprehensive load score and load bottleneck identification results; scaling trigger decision information; service instance configuration after expansion and contraction; resource quota configuration and cost analysis report; complete scaling operation logs; optimized scaling strategy parameters and effect evaluation report.

[0278] In one embodiment of the present invention, a specific example is provided:

[0279] To verify the system's actual operational performance, a 90-day field test was conducted in three typical regions. During the test, 5,000 pieces of equipment, including concrete pump trucks, truck cranes, and excavators, were deployed, covering various application scenarios such as urban construction sites, suburban mines, and infrastructure construction in remote areas, with a total test area exceeding 15,000 square kilometers. The test environment encompassed multiple network types, including 4G, 5G, and NB-IoT, covering various network signal strength conditions from excellent to extremely poor.

[0280] The system converts raw data packets from different protocols into standardized device data objects through multi-level feature extraction and two-stage identification. Examples of standardized data objects for two typical devices are shown in Table 1.

[0281] Table 1: Examples of standardized data objects for two typical devices;

[0282]

[0283] The system calculates equipment health scores based on standardized equipment data objects and anomaly detection results, using multi-dimensional index fusion and analytic hierarchy process (AHP). The health assessment results for the two pieces of equipment are shown in Table 2.

[0284] Table 2: Health assessment results of the two devices;

[0285]

[0286] Through standardized data objects and health assessments, the system achieved unified management and intelligent monitoring of heterogeneous devices. During testing, the system successfully identified and handled over 800 communication anomaly events, reducing the average time to detect device communication failures from several hours to several minutes, and the average repair time by over 70%.

[0287] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A SIM card management platform, characterized in that, include: The protocol recognition module acquires the raw data packets uploaded by the construction machinery equipment, performs multi-level feature extraction and two-stage recognition, and obtains standardized equipment data objects. The anomaly detection module performs equipment grouping and lightweight anomaly detection based on standardized equipment data objects, and obtains the results of equipment behavior anomaly detection. The health assessment module integrates multi-dimensional indicators based on standardized equipment data objects, performs hierarchical analysis based on anomaly detection results, assesses the health status of the equipment, and obtains an equipment health score and diagnostic report. The instruction scheduling module allocates transmission strategies and channels based on device health scores and diagnostic reports, sends instructions, records the status changes of instructions throughout their entire lifecycle, and obtains instruction delivery status and tracking information. The traffic prediction module builds a prediction model based on standardized device data objects and device health scores, predicts future traffic usage trends, performs multi-scenario analysis and alarms, and generates traffic prediction values ​​and cost optimization suggestions. The elastic scaling module, based on standardized device data objects, device behavior anomaly detection results, device health scores, command delivery status and traffic prediction values, generates system processing load and real-time performance indicators to perform multi-level elastic scaling and intelligent scheduling, and obtain system resource configuration and scaling operation logs. The protocol identification module includes: The frequency of each byte value in the statistical data packet is counted, and the information entropy value is calculated. When the entropy value is greater than the preset encryption judgment threshold, it is determined to be in an encrypted state. For encrypted data packets, extract device identification information from the data packets, query the encryption algorithm type and decryption key based on the device identification, and call the corresponding decryption function to decrypt; Extract protocol feature vectors, including shallow features and deep features. Shallow features include total data packet length, protocol header length, magic number field, version number field position, length field encoding method, and checksum type. Deep features include byte value distribution histogram, printable character ratio, and data payload structure level. The protocol identification module further includes: In the first stage, a fast matching algorithm is used to accurately match the shallow features with the protocol feature library. If the match is successful, the protocol type identifier is output and the recognition confidence is set to a preset high confidence value. When fast matching fails or the confidence level is lower than the preset fast matching threshold, the second stage is entered, using a convolutional neural network model. The deep feature vector is used as input, and the probability distribution of each protocol type is output. The protocol type with the highest probability is used as the recognition result. For data packets whose confidence level is lower than the preset self-learning threshold, they are marked as samples to be confirmed and pushed to the manual review queue. After being marked, they are added to the protocol sample library. When the number of new samples reaches the preset sample threshold or the time since the last model training exceeds the preset training cycle, incremental model training is triggered. The anomaly detection module includes: For each device, a feature vector is constructed, including device model, working area, service type, average daily traffic, working time distribution, and traffic usage pattern. The K-Means clustering algorithm is used to group all devices, calculate the Euclidean distance between each device and each cluster center, and assign the device to the group to which the nearest cluster center belongs. The assignment and update process is repeated until the cluster centers no longer change. For each device group, an Isolation Forest model is trained, extracting historical normal behavior data of all devices within the group as training samples, and training is completed by constructing multiple isolation trees; The instruction scheduling module includes: Priority levels are assigned based on instruction type. Instructions are divided into urgent instructions, normal instructions, and low-priority instructions. Corresponding transmission strategies are assigned to instructions based on their priority levels. Query the health score of the target device and assess the device's communication quality level based on the health score; For emergency commands, a hybrid multi-channel concurrent transmission strategy is adopted, using the MQTT main channel, CoAP backup channel and SMS emergency channel to send commands simultaneously. Commands are considered to have been successfully delivered if any channel receives a confirmation message from the device within a preset timeout period.

2. The SIM card management platform according to claim 1, characterized in that, The anomaly detection module also includes: For newly connected devices, the similarity between the new device and the feature centers of each device group is calculated. The group with the highest similarity is selected as the group to which the new device belongs, and the Isolation Forest model of the group is used for anomaly detection. Set a behavior data accumulation period for new devices, increase the anomaly threshold during the accumulation period, and restore the anomaly threshold to the normal level after the accumulation period ends; Real-time extraction of device behavior characteristics, including current traffic usage, number of data uploads, average signal strength, and online duration, and calculation of standardized deviation from historical data for the same period; The behavioral feature vector is input into the Isolation Forest model of the group to which the device belongs to calculate the anomaly score. A personalized threshold is determined based on the importance level and historical stability of the device. When the anomaly score is greater than the threshold, the current behavior of the device is determined to be abnormal.

3. The SIM card management platform according to claim 1, characterized in that, The health assessment module includes: Query the data records of the device within a preset time period, and calculate communication quality indicators, connection stability indicators, service normality indicators, and traffic usage indicators; The minimum-maximum normalization method was used to normalize each indicator. Before normalization, outliers were identified using the quartile method and replaced with the median. The analytic hierarchy process (AHP) is used to determine the weight coefficients of the indicators. The first level determines the weights of the four categories, and the second level determines the weights of each indicator within each category. The weights of the two levels are multiplied together to obtain the final weight of each indicator. The overall health score of the equipment is calculated using a weighted summation method. The results of abnormal equipment behavior detection are used as correction factors, and points are deducted according to the severity of the abnormality.

4. A SIM card management platform according to claim 1, characterized in that, The instruction scheduling module also includes: For ordinary commands, a single-channel adaptive transmission strategy is adopted, and the optimal transmission channel is selected based on the device's health score and network quality indicators. An adaptive retransmission mechanism is adopted to extract the average delay, packet loss rate and signal strength of communication records, calculate the network quality score, classify the network quality level according to the network quality score, and set different maximum retransmission times and retransmission intervals for different network quality levels. For low-priority instructions, a batch delayed transmission strategy is adopted, which combines and packages the instructions for transmission. When the number of instructions in a device group in the buffer queue reaches a preset instruction number threshold or the time since the last transmission exceeds a preset time interval threshold, batch transmission is triggered.

5. A SIM card management platform according to claim 1, characterized in that, The traffic prediction module includes: Extract the traffic usage field from standardized device data objects, construct the device's historical traffic time series, and collect multi-dimensional features that affect traffic usage; The flow time series was preprocessed, outliers were detected by standard deviation and replaced by the average of the preceding and following data, missing values ​​were filled by linear interpolation, and smoothing was performed by moving average. A hybrid prediction model was constructed, using the Prophet model and the LightGBM model for prediction respectively. The prediction results were then fused using a dynamic weighting method, with the weights determined based on the average absolute percentage error of the two models on the validation set.

6. A SIM card management platform according to claim 5, characterized in that, The traffic prediction module also includes: For scenarios involving excessive traffic risk warnings, the predicted total traffic is calculated, and an excessive traffic risk warning event is generated when the predicted total traffic exceeds the preset excessive risk threshold of the remaining traffic. For traffic waste alarm scenarios, calculate the traffic utilization rate, and generate a traffic waste alarm event when the traffic utilization rate is lower than the preset waste alarm threshold; For abnormal traffic detection scenarios, the growth rate of predicted traffic and historical average traffic is calculated. When the growth rate exceeds the preset abnormal growth threshold, an abnormal traffic alarm event is generated. Root cause analysis is performed through multi-dimensional correlation analysis, and abnormal traffic is classified into four types: normal business growth, equipment failure, suspected security attack, and unknown cause.

Images