Intelligent operation and maintenance system for traffic information networking charging

Abstract

The application relates to the technical field of intelligent operation and maintenance, and particularly relates to an intelligent operation and maintenance system for traffic informatization networking charging. The system comprises a terminal management module, an edge coordination module and a cloud management module. The terminal management module is arranged at each charging terminal and is used for processing emergency failures requiring second-level response, collecting running state data of the terminal in real time, monitoring abnormal data according to the running state data and local preset emergency rules, and executing emergency response operations when abnormal data is monitored. The edge coordination module is arranged at an edge computing node, is in communication connection with the plurality of terminal management modules, is used for processing minute-level failures without intervention of the cloud management module, receives running state data of each terminal in a jurisdictional area, performs data fusion and local fault diagnosis, executes a cooperative processing operation according to an edge autonomous strategy when a local fault is identified, and generates summary data.

Description

Technical Field

[0001] This invention relates to the field of intelligent operation and maintenance technology, and specifically to an intelligent operation and maintenance system for networked toll collection in transportation information systems. Background Technology

[0002] With the continuous integration of advanced technologies such as big data and artificial intelligence into the transportation sector, the development of transportation informatization is gradually moving towards the stage of intelligent transportation. In the highway network toll collection system, software operation and maintenance plays a crucial role in ensuring the continuous and stable operation of toll collection services. The quality of operation and maintenance management directly affects the availability of the toll collection system, the accuracy of transaction data, and public satisfaction with travel.

[0003] Currently, the operation and maintenance of highway network toll collection systems mainly relies on traditional manual operation and maintenance methods. In terms of asset management, most toll stations still use manual statistics and spreadsheets to manage the ledgers of workstation terminals, server hardware and software, network equipment, etc. Asset information is updated late and the actual status of equipment cannot be reflected in real time, resulting in serious discrepancies between the ledgers and the actual situation. When maintenance personnel remotely handle faults, they often face problems such as chaotic IP addresses and unclear equipment ownership.

[0004] Regarding fault handling, when terminal devices malfunction, maintenance personnel need to manually log into remote tools or travel to the site to handle the issue based on phone reports from on-site personnel. This results in delayed fault detection and low efficiency. In terms of password management, maintaining password ledgers for terminal devices and servers is labor-intensive, with inconsistent password versions and significant shared security issues. Each remote maintenance requires entering the operating system password, further reducing remote maintenance efficiency. Regarding monitoring and early warning, some terminal issues, such as hard drive write failures and core process crashes, cannot be automatically detected using existing technologies. Fault detection relies entirely on user reports or periodic inspections, making it difficult to guarantee system stability.

[0005] Furthermore, due to the varying construction times and developers of toll station information systems, their complex data structures, difficulties in inter-system interaction, and lack of a holistic monitoring perspective, maintenance personnel struggle to quickly locate and resolve performance issues. Existing maintenance systems generally suffer from data silos, preventing closed-loop maintenance processes and often resulting in delayed fault handling. Regarding management indicator systems, most transportation systems lack end-to-end performance management indicator systems, hindering comprehensive system evaluation and early warning of potential problems. Overall, traditional maintenance models operate independently in terms of management philosophy, tools, handling methods, and security, making effective integration difficult. Maintenance personnel face increasing challenges in terms of timeliness and precision, and maintenance efficiency, system stability, and security fail to meet the actual needs of intelligent transportation development. Therefore, there is an urgent need to develop a set of efficient software maintenance tools capable of automating and intelligentizing maintenance work to address the current challenges in the maintenance management of highway network toll collection systems. Summary of the Invention

[0006] The technical problem solved by this invention is to provide an intelligent operation and maintenance system for networked toll collection in transportation information systems, which can solve the problems of delayed fault response and low degree of automation in existing operation and maintenance models.

[0007] The basic solution provided by this invention is an intelligent operation and maintenance system for networked toll collection in transportation information systems, comprising a terminal management module, an edge collaboration module, and a cloud management module. The terminal management module is deployed on each toll terminal to handle emergency faults that require a response time of seconds. It collects the terminal's operating status data in real time, monitors abnormal data based on the operating status data and locally preset emergency rules, and executes emergency response operations when abnormal data is detected. The edge collaboration module is deployed on edge computing nodes and communicates with multiple terminal management modules. It is used to handle minute-level faults that do not require intervention from cloud management modules. It receives the operating status data of each terminal in the area under its jurisdiction, performs data fusion and local fault diagnosis. When a local fault is identified, it performs collaborative processing operations according to the edge autonomy strategy and generates summary data. The cloud management module, deployed in the cloud data center, communicates with each edge collaboration module to perform policy optimization. It receives aggregated data reported by each edge collaboration module, performs global data analysis based on the aggregated data, generates a global optimization policy based on the global data analysis results, and distributes it to each edge collaboration module. The edge collaboration module updates its own edge autonomy policy based on the global optimization policy.

[0008] The principles and advantages of this invention are as follows: The terminal management module is deployed on each charging terminal device, responsible for collecting operational status data such as CPU utilization, memory utilization, disk read / write status, network connectivity, core process survival status, and log error frequency. It also monitors abnormal data in real time according to locally preset emergency rules, and directly executes emergency response operations when an emergency fault requiring a second-level response is detected. The edge collaboration module is deployed on edge computing nodes, communicating with multiple terminal management modules. It is responsible for receiving operational status data reported by various terminals within its jurisdiction, performing data fusion and local fault diagnosis on this data, and executing collaborative processing operations according to edge autonomy strategies when a local fault is identified. The processed data is then aggregated and reported. The cloud management module is deployed in the cloud data center, communicating with each edge collaboration module. It is responsible for receiving aggregated data reported by each edge collaboration module, performing global data analysis to generate a global optimization strategy, and distributing it to each edge collaboration module for updating its edge autonomy strategy. This achieves hierarchical fault handling: the terminal management module handles emergency faults requiring a second-level response for a single terminal, the edge collaboration module handles regional faults requiring a minute-level response, and the cloud management module performs global strategy optimization. In existing technologies, traditional operation and maintenance systems typically upload all data to a central server for unified processing, resulting in high network bandwidth pressure, high fault response latency, and the loss of operation and maintenance support for the terminal if the network between the central server and the terminal is interrupted. This solution achieves decentralized fault handling through a three-tier architecture, with terminals and edge nodes possessing independent processing capabilities. Even if the network connection to the cloud is interrupted, the terminals and edge nodes can still maintain basic operation and maintenance functions, significantly improving system reliability and fault response speed.

[0009] Furthermore, the terminal management module includes a data acquisition module, a fault diagnosis module, and an emergency operation module; The data acquisition module is used to collect the operating status data of the charging terminal in real time. The operating status data includes CPU utilization, memory utilization, disk read / write status, network connectivity, core process survival status, and log error frequency. The fault diagnosis module is used to analyze the collected operating status data in real time according to the preset emergency fault diagnosis rules, and to determine whether the current anomaly is an emergency fault that requires a second-level response. The emergency operation module is used to execute emergency operations based on the local emergency strategy library when an emergency fault is determined to be an emergency.

[0010] The data acquisition module is responsible for collecting real-time operational status data from the toll collection terminal, specifically including CPU utilization, memory utilization, disk read / write status, network connectivity, core process liveness status, and log error frequency. The fault diagnosis module analyzes the collected operational status data in real-time according to preset emergency fault diagnosis rules to determine whether the current anomaly is an emergency fault requiring a second-level response. The emergency operation module executes emergency operations based on the local emergency policy library when an emergency fault is determined to be an emergency. The principle behind this design is to decentralize fault diagnosis and emergency handling capabilities to the terminal device itself, enabling the terminal to autonomously complete emergency responses without waiting for instructions from the cloud or edge when it detects a fault. For example, when the data acquisition module detects the disappearance of a core process, the fault diagnosis module determines according to rules that the fault requires a second-level response, and the emergency operation module immediately executes a process restart operation. In existing technologies, when a toll collection terminal malfunctions, maintenance personnel often need to log in remotely or handle the issue on-site, resulting in long fault recovery times. Furthermore, in the event of a large-scale fault, maintenance personnel cannot simultaneously handle multiple terminals. Each terminal in this solution has independent fault diagnosis and emergency handling capabilities. Core processes can be automatically restored within seconds of disappearing. When the network is interrupted, the network card can be automatically reset. When the disk is full, temporary files can be automatically cleaned up. These operations are all completed autonomously by the terminal without manual intervention, which significantly shortens the fault recovery time and reduces the workload of maintenance personnel.

[0011] Furthermore, the edge collaboration module includes a data aggregation module, a local fault diagnosis module, and an edge autonomous decision-making module; The data aggregation module communicates with multiple terminal management modules within its jurisdiction to receive operational status data, emergency operation records, and real-time operational status data reported by each terminal. After cleaning and aligning the received data, it generates a unified data view for the region. The local fault diagnosis module is used to perform real-time analysis based on a unified regional data view and a pre-trained local fault diagnosis model to identify local faults occurring within its jurisdiction. These local faults include similar anomalies occurring simultaneously on multiple terminals, network interruptions between terminals, and faults that a single terminal cannot handle autonomously. The edge autonomous decision-making module is used to automatically generate and execute collaborative processing operations by matching the identified local fault types with the collaborative processing strategies in the edge autonomous strategy library. The data reporting module communicates with the cloud management module and is used to summarize the unified regional data view, local fault diagnosis results, collaborative processing operation records, and strategy execution effects to generate summary data, which is then periodically reported to the cloud management module.

[0012] The data aggregation module communicates with multiple terminal management modules within its jurisdiction, receiving operational status data, emergency operation records, and real-time operational status data reported by each terminal. After cleaning and aligning this data, it generates a unified regional data view. The local fault diagnosis module, based on the unified regional data view and combined with a pre-trained local fault diagnosis model, performs real-time analysis to identify local faults occurring within its jurisdiction. These include simultaneous occurrences of similar anomalies across multiple terminals, network interruptions between terminals, and faults that a single terminal cannot handle autonomously. The edge autonomous decision-making module matches the identified local fault types with collaborative processing strategies from the edge autonomous strategy library, automatically generating and executing collaborative processing operations. The data reporting module summarizes the unified regional data view, local fault diagnosis results, collaborative processing operation records, and strategy execution effects to generate aggregated data, which is periodically reported to the cloud management module. The principle behind this design is to allow edge nodes to act as regional-level operation and maintenance hubs, collaboratively managing multiple terminals within the region. When multiple terminals experience the same type of anomaly simultaneously, the edge node can identify it as a regional-level problem rather than a single terminal issue. For example, if five lane terminals under an edge node simultaneously experience network outages, the local fault diagnosis module identifies this abnormal pattern, and the edge autonomous decision-making module determines that it may be a regional switch failure. It then automatically issues a downgrade operation command to all terminals in the region and notifies maintenance personnel to check the switch. In existing technologies, each terminal reports a fault independently, requiring maintenance personnel to check each terminal individually, making it difficult to quickly determine the root cause as a problem with the regional switch. This solution, through data aggregation and correlation analysis at the edge node, can quickly identify regional fault patterns and execute collaborative processing, achieving an upgrade from single-point maintenance to regional collaborative maintenance, effectively improving the efficiency and handling capabilities of regional fault diagnosis.

[0013] Furthermore, the cloud management module includes a data aggregation module and a fault classification module; The data aggregation module is used to receive aggregated data reported by each edge collaboration module, and to store the received aggregated data in the cloud database after standardization processing. The fault classification module is used to perform horizontal comparative analysis on the received aggregated data from various regions, and to identify and distinguish between common faults and faults specific to the jurisdiction. The fault classification module includes: The fault event standardization module is used to standardize and map fault events reported by various regions according to a preset fault type coding system, and generate standardized fault event records. The cross-regional frequency statistics module is used to count the frequency of the same standardized fault type occurring in different edge collaboration modules within their respective jurisdictions, and to generate a fault-region distribution matrix. The general fault identification module is used to identify fault types that occur more frequently than a preset regional threshold and are distributed in multiple regions based on the fault-region distribution matrix, and mark them as general faults; the general faults are characterized as common faults that are prevalent in all jurisdictions; The jurisdiction-specific fault identification module is connected to the cross-regional frequency statistics module. It is used to identify fault types that only appear in a single or fewer than a preset number of regions based on the fault-region distribution matrix, and mark them as jurisdiction-specific faults. The jurisdiction-specific faults are characterized as specific faults related to the environment, equipment model or configuration of a specific region.

[0014] The data aggregation module receives aggregated data reported by each edge collaboration module, performs standardization processing, and stores it in the cloud database. The fault event standardization module standardizes and maps fault events reported by each region according to a preset fault type coding system, generating standardized fault event records. The cross-regional frequency statistics module counts the frequency of the same standardized fault type occurring in different edge collaboration module jurisdictions, generating a fault-region distribution matrix. The general fault identification module, based on the fault-region distribution matrix, identifies fault types that occur more frequently than a preset regional threshold and are distributed across multiple regions, marking them as general faults, representing common faults prevalent in each jurisdiction. The jurisdiction-specific fault identification module, based on the fault-region distribution matrix, identifies fault types that occur only in a single region or fewer than a preset number of regions, marking them as jurisdiction-specific faults, representing specific faults related to a specific regional environment, equipment model, or configuration. The principle behind this design is to classify massive amounts of fault data into general faults and jurisdiction-specific faults through cross-regional horizontal comparative analysis. For example, a standardized fault type, "core process anomaly," occurring in all thirty regions with frequencies exceeding a threshold, is classified as a general fault. Another fault type, "overheating of a certain model of industrial control computer," occurring only in three regions using that model, is classified as a region-specific fault. In existing technologies, maintenance systems typically analyze all fault data together, failing to distinguish between industry-wide issues and those occurring only in specific regions, resulting in a lack of targeted optimization strategies. This solution, through fault classification analysis, enables maintenance managers to clearly understand which problems require system-wide solutions and which only need to be addressed in specific regions, providing precise decision-making basis for subsequent strategy generation and avoiding resource waste.

[0015] Furthermore, the cloud management module also includes a policy generation module; The strategy generation module is used to calculate the proportion of general faults and the proportion of specific faults in each region based on the general faults and specific faults in the regions under the jurisdiction of each edge collaboration module, and to select regions whose proportion of specific faults exceeds a preset threshold as key attention regions. For key areas of concern, the strategy generation module retrieves historical fault event records and a unified data view for that area, and identifies common characteristics of faults specific to that area through correlation analysis. These common characteristics include common fault occurrence time periods, common fault terminal models, common software version numbers, and common configuration parameters. The cause of the fault is located based on the identified common characteristics. The strategy generation module is also used to generate a global optimization strategy for the region based on the identified fault cause. The global optimization strategy includes one or more of the following: configuration parameter correction instructions, software patch upgrade packages, and baseline check strategy updates. The strategy is then sent to the corresponding edge collaboration module through a secure channel.

[0016] The system calculates the percentage of general and specific faults in each region and identifies regions where the percentage of specific faults exceeds a preset threshold as key areas of focus. For these key areas, the strategy generation module retrieves historical fault event records and a unified regional data view. Through correlation analysis, it identifies common characteristics of the region's specific faults. These common characteristics include shared fault occurrence times, shared terminal models, shared software version numbers, and shared configuration parameters. Based on these identified common characteristics, the module pinpoints the cause of the fault. The strategy generation module then generates a global optimization strategy for the region based on the identified fault cause. This strategy may include one or more of the following: configuration parameter correction instructions, software patch upgrade packages, or baseline check strategy updates. This strategy is then distributed to the corresponding edge collaboration module via a secure channel. The principle behind this design is to locate the root cause of faults by analyzing the common characteristics of region-specific faults and to generate precise optimization strategies. For example, if the proportion of unique faults in a certain area exceeds a preset threshold, historical data correlation analysis reveals that these unique faults all occur between 2:00 AM and 4:00 AM, and the faulty terminals are all industrial control computers of a certain model, with software version V1.2.3. The scheduled task settings in the configuration parameters differ from those in other areas. Therefore, the cause of the fault is identified as a memory leak in the scheduled tasks of this model of industrial control computer under this software version. Based on this, the policy generation module generates a software patch upgrade package and scheduled task configuration correction instructions for this model of device in that area, and sends them to the corresponding edge collaboration module for execution. In existing technologies, when a large number of unique faults occur in a certain area, maintenance personnel need to manually check the fault causes of each machine, which is inefficient and prone to overlooking common characteristics. This solution, through automated correlation analysis, quickly locates the cause of the fault and generates targeted policies, realizing a closed-loop automated process from fault discovery to policy generation, significantly improving problem-solving efficiency.

[0017] Furthermore, the policy generation module also includes a policy verification module; The strategy verification module is used to continuously monitor the execution effect of the global optimization strategy after it is issued to the corresponding edge collaboration module, and automatically adjust the strategy parameters or trigger the strategy rollback based on the execution effect. The policy verification module includes: The policy execution tracking module is used to receive policy execution status information fed back by the edge collaboration module. The policy execution status information includes policy issuance success status, terminal configuration update result, software patch installation progress, and failure event change trend after policy execution. The effectiveness evaluation module, connected to the strategy execution tracking unit, is used to quantitatively evaluate the effectiveness of strategy execution based on preset evaluation indicators. These indicators include: changes in the incidence rate of the target fault type, changes in fault recovery time, and the number of new faults after strategy execution. When the incidence rate of the target fault type decreases for more than a preset threshold for a consecutive preset number of days after strategy execution, the strategy is evaluated as effective. When the incidence rate of the target fault type does not decrease or the number of new faults exceeds the preset threshold, the strategy is evaluated as ineffective. The strategy adjustment module, connected to the effect evaluation unit, is used to automatically perform one or more of the following operations when the strategy is evaluated as invalid: adjust the strategy parameters and reissue, trigger the strategy rollback operation to restore the state before execution, generate an exception report and mark the strategy as pending manual review. The policy optimization learning module is connected to the performance evaluation unit and the model training module, respectively. It is used to feed back policies evaluated as effective and their execution conditions as positive samples, and policies evaluated as ineffective and their execution conditions as negative samples to the model training module to optimize the accuracy of subsequent policy generation models.

[0018] The strategy verification module continuously monitors the execution effect of the global optimization strategy after it is issued to the corresponding edge collaboration module, and automatically adjusts the strategy parameters or triggers strategy rollback based on the execution effect. The strategy execution tracking module receives strategy execution status information from the edge collaboration module, including successful strategy issuance status, terminal configuration update results, software patch installation progress, and the trend of fault events after strategy execution. The effect evaluation module quantitatively evaluates the strategy execution effect based on preset evaluation indicators, including changes in the incidence rate of the target fault type, changes in fault recovery time, and the number of new faults after strategy execution. When the incidence rate of the target fault type decreases for more than a preset threshold for a consecutive preset number of days after strategy execution, the strategy is evaluated as effective; when the incidence rate of the target fault type does not decrease or the number of new faults exceeds the preset threshold, the strategy is evaluated as ineffective. When a strategy is evaluated as ineffective, the strategy adjustment module automatically adjusts the strategy parameters and reissues it, triggers a strategy rollback to restore the state before execution, generates an anomaly report, and marks the strategy as one or more operations awaiting manual review. The strategy optimization learning module uses effective strategies and their execution conditions as positive samples and ineffective strategies and their execution conditions as negative samples, feeding them back to the model training module to optimize the accuracy of subsequent strategy generation models. The principle behind this design is to establish a closed-loop verification mechanism for strategy execution effectiveness, ensuring that the issued strategies truly solve problems without introducing new ones. For example, after a software patch upgrade package for a specific model of equipment in a certain region is issued, the strategy execution tracking module provides feedback on the patch installation progress and the trend of post-installation fault events. The effectiveness evaluation module calculates the incidence rate of the target fault type for that model of equipment in that region. If the incidence rate decreases by more than a preset threshold for seven consecutive days without any new faults, the strategy is considered effective. If the incidence rate of the target fault type does not decrease, or a large number of new fault types appear after patch installation, the strategy is considered ineffective, and the strategy adjustment module automatically triggers a rollback operation to restore the equipment to its pre-upgrade state. In existing technologies, there is a lack of effectiveness verification mechanisms after strategy issuance. Incorrect strategies may run for a long time, leading to worsening problems, and each strategy formulation is independent, making it impossible to accumulate experience. This solution ensures the effectiveness of the strategy through a closed-loop strategy verification process, while feeding the verification results back to the model training module, thereby continuously improving the accuracy of subsequent strategy generation and realizing the self-learning and continuous optimization capabilities of the operation and maintenance system.

[0019] Furthermore, the strategy generation module also includes a fault cause localization module; The fault cause localization module is used to retrieve historical fault event records and a unified regional data view for the selected key areas of concern, analyze the common characteristics of faults specific to the jurisdiction, and locate the fault causes. The fault cause location module includes: The time concentration calculation module is used to divide a day into a preset number of time windows, count the number of occurrences of each specific fault type in each time window, and calculate the time concentration index of the fault. The time concentration index is equal to the number of windows with the most fault occurrences divided by the total number of occurrences. When the index exceeds the preset time concentration threshold, it is determined that the fault has time concentration, and the time window in which the fault occurs is located. The model concentration calculation module is used to count the frequency of occurrence of different models of terminals involved in each specific fault type, and calculate the model concentration index of the fault. The model concentration index is equal to the number of times the most frequently occurring model is divided by the total number of faulty terminals. When the index exceeds the preset model concentration threshold, it is determined that the fault is strongly correlated with a specific model, and the terminal model associated with the fault is located. The version concentration calculation module is used to count the frequency of occurrence of different software version numbers of terminals involved in each specific fault type, and calculate the version concentration index of the fault. The version concentration index is equal to the number of times the most frequently occurring version is divided by the total number of fault terminals. When the index exceeds the preset version concentration threshold, it is determined that the fault is strongly correlated with a specific software version, and the software version number associated with the fault is located. The configuration similarity calculation module is used to extract the configuration parameter vectors of the terminals involved in each specific fault type, calculate the average similarity between the configuration parameter vectors of all fault terminals, and the average similarity is the mean of the similarity between all terminal pairs. When the average similarity exceeds the preset configuration similarity threshold, it is determined that the configuration parameters of the fault terminal have a high degree of consistency. The comprehensive confidence score calculation module is used to calculate the comprehensive confidence score according to the time concentration index, model concentration index, version concentration index and configuration similarity index, according to the preset weights. When the comprehensive confidence score exceeds the preset confidence threshold, it is determined that the cause of the fault has been located, and the fault cause location result is generated based on the common feature that contributes the most.

[0020] The time concentration calculation module uses the following formula to calculate the time concentration index:

[0021] in, The number of time windows to be divided. This represents the number of times the fault type occurs within the k-th time window. At this time, the fault has a time-concentrated nature. The preset time concentration threshold; The model concentration calculation module uses the following formula to calculate the model concentration index:

[0022] Where M represents the set of all terminal models involved in the fault. This represents the number of faulty terminals of model m. The fault was determined to be strongly correlated with a specific model. The preset model concentration threshold; The version concentration calculation module uses the following formula to calculate the version concentration index:

[0023] in, This is the set of all software version numbers involved in the fault. For the number of faulty terminals with version number v, when The fault was determined to be strongly correlated with a specific software version. The preset version concentration threshold; The configuration similarity calculation module uses the following formula to calculate the average similarity:

[0024] Where n is the number of faulty terminals. and These are the configuration parameter vectors for the p-th and q-th faulty terminals, respectively. To configure the Jaccard similarity coefficient of the parameter vector, when The configuration parameters of the faulty terminals are highly consistent. Configure a similarity threshold; The comprehensive confidence score calculation module uses the following formula to calculate the comprehensive confidence score:

[0025] in , , , For the preset weighting coefficients, when The cause of the fault has been determined in time. To pre-set the reliability threshold. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of an embodiment of the present invention. Detailed Implementation

[0027] The following detailed description illustrates the specific implementation method: The basic implementation examples are as follows: Figure 1 As shown: An intelligent operation and maintenance system for networked toll collection in transportation information systems includes a terminal management module, an edge collaboration module, and a cloud management module; The terminal management module is deployed on each toll terminal to handle emergency faults that require a response time of seconds. It collects the terminal's operating status data in real time, monitors abnormal data based on the operating status data and locally preset emergency rules, and executes emergency response operations when abnormal data is detected. The edge collaboration module is deployed on edge computing nodes and communicates with multiple terminal management modules. It is used to handle minute-level faults that do not require intervention from cloud management modules. It receives the operating status data of each terminal in the area under its jurisdiction, performs data fusion and local fault diagnosis. When a local fault is identified, it performs collaborative processing operations according to the edge autonomy strategy and generates summary data. The cloud management module, deployed in the cloud data center, communicates with each edge collaboration module to perform policy optimization. It receives aggregated data reported by each edge collaboration module, performs global data analysis based on the aggregated data, generates a global optimization policy based on the global data analysis results, and distributes it to each edge collaboration module. The edge collaboration module updates its own edge autonomy policy based on the global optimization policy.

[0028] The terminal management module includes a data acquisition module, a fault diagnosis module, and an emergency operation module. The data acquisition module is used to collect the operating status data of the charging terminal in real time. The operating status data includes CPU utilization, memory utilization, disk read / write status, network connectivity, core process survival status, and log error frequency. The fault diagnosis module is used to analyze the collected operating status data in real time according to the preset emergency fault diagnosis rules, and to determine whether the current anomaly is an emergency fault that requires a second-level response. The emergency operation module is used to execute emergency operations based on the local emergency strategy library when an emergency fault is determined to be an emergency.

[0029] Specifically, in the actual deployment of a provincial highway network toll collection system, the terminal management module was installed on approximately 3,000 toll collection terminal devices across 600 toll stations throughout the province. These included ETC lane hosts, mixed lane hosts, unattended hosts, overload control lane hosts, workstation hosts, gantry hosts, and gantry server hosts. The data acquisition module collected operational status data every five seconds, including CPU utilization, memory utilization, disk read / write status, network connectivity, core process liveness status, and log error frequency. Taking a mixed lane host as an example, when the data acquisition module detected the disappearance of the core process "LaneService.exe" and the appearance of the keyword "fatal error" in the log file, the fault diagnosis module performed real-time analysis based on preset emergency fault diagnosis rules. These rules stipulated that the disappearance of a core process would be directly identified as an emergency fault requiring a second-level response, triggering an emergency response regardless of other indicators. The emergency operation module immediately executed the process restart operation based on the corresponding operation instructions stored in the local emergency strategy library. The entire process, from the occurrence of the fault to the completion of the process restart, took no more than three seconds, and the lane resumed normal toll collection service after a brief interruption.

[0030] In another scenario, the data acquisition module detects that the disk write failure count of a certain ETC lane host reaches five times within three seconds. The fault diagnosis module determines this as an emergency fault based on the threshold triggering rules. The emergency operation module automatically executes a temporary file cleanup script, cleaning up approximately 2GB of temporary log files, and disk writes return to normal. When the data acquisition module detects that the network connectivity of a certain gantry host is unavailable for five consecutive seconds, the fault diagnosis module determines this as an emergency fault based on the network interruption rules. The emergency operation module automatically executes a network card reset command, and the network connection is restored within eight seconds. All emergency operations are recorded and reported to the edge collaboration module.

[0031] The edge collaboration module includes a data aggregation module, a local fault diagnosis module, and an edge autonomous decision-making module. The data aggregation module communicates with multiple terminal management modules within its jurisdiction to receive operational status data, emergency operation records, and real-time operational status data reported by each terminal. After cleaning and aligning the received data, it generates a unified data view for the region. The local fault diagnosis module is used to identify local faults occurring within its jurisdiction through real-time analysis based on a unified regional data view and a pre-trained local fault diagnosis model. The fault diagnosis model is a gradient boosting decision tree-based classification model. The input feature vector of this model is extracted in real-time from the unified regional data view, and the model's output is a local fault type label and its corresponding confidence score. When the confidence score exceeds a preset threshold, the fault type is identified as the currently occurring local fault. These local faults include similar anomalies occurring simultaneously on multiple terminals, network interruptions between terminals, and faults that a single terminal cannot handle autonomously. Before deployment, the fault diagnosis model is trained offline using historical operational status data for each region and tagged local fault event records. During training, feature vectors are extracted from the unified historical data view of the region as model input, and the tagged local fault types are used as labels. The model parameters are obtained through iterative training using a gradient boosting decision tree algorithm, and the model is deployed to each edge computing node after the model evaluation index reaches the preset accuracy. During real-time analysis, the local fault diagnosis module periodically extracts feature vectors from the unified data view of the current region and inputs them into the fault diagnosis model. The model outputs the most likely local fault type and its confidence level. If the confidence level is higher than the judgment threshold of 0.75, the local fault is confirmed.

[0032] The edge autonomous decision-making module is used to match the identified local fault type with the collaborative processing strategy in the edge autonomous strategy library, automatically generate and execute collaborative processing operations. The edge autonomous strategy library stores the mapping relationship between fault types and collaborative processing strategies in the form of key-value pairs. When the local fault diagnosis module outputs the fault type and confidence level, the edge autonomous decision-making module uses the fault type as the key to perform a table lookup and obtain the corresponding collaborative processing strategy. When multiple strategies are matched for a certain fault type, the strategy with the highest priority is selected according to the pre-set strategy priority order. After obtaining the strategy, the edge autonomous decision-making module automatically parses the strategy into the corresponding operation instruction sequence and executes the collaborative processing operation.

[0033] The mapping relationships in the edge autonomy strategy library are represented as follows: The local fault type "multi-terminal core process abnormality" is mapped to the collaborative processing strategy P001, which is to determine that it is a regional server fault and execute degraded operation, pull backup service package, and push service restart command; The local fault type "inter-terminal network interruption" is mapped to the collaborative processing strategy P002, which is to execute the configuration parameter synchronization command and channel reconstruction. The local fault type "unknown anomaly" is mapped to the lowest priority policy P999, which generates an alarm and forwards it to the operation and maintenance personnel; when the local fault diagnosis module outputs a compound fault, the policy with the highest priority among the policies mapped to each individual fault type is executed.

[0034] The data reporting module communicates with the cloud management module and is used to summarize the unified regional data view, local fault diagnosis results, collaborative processing operation records, and strategy execution effects to generate summary data, which is then periodically reported to the cloud management module.

[0035] Specifically, at a highway management sub-center, an edge computing server was deployed as the edge collaboration module for five toll stations under the sub-center's jurisdiction, connecting all approximately eighty toll terminals at these five toll stations. The data aggregation module continuously receives operational status data, emergency operation records, and real-time monitoring data reported by these terminals, and generates a unified regional data view after data cleaning. At 2:00 AM one day, the local fault diagnosis module, through analysis of the unified regional data view, discovered that twelve ETC lane hosts at the five toll stations under the sub-center's jurisdiction had successively reported core process disappearance anomalies within a three-minute interval, but each terminal's own emergency operation module failed to successfully restore the process. The local fault diagnosis module, combined with a pre-trained fault diagnosis model, performed real-time analysis. The fault diagnosis model extracted feature vectors of the twelve ETC lane host core process anomalies from the current unified regional data view, calculating a confidence score of 0.92 for the 'multi-terminal core process anomaly' fault type, exceeding the judgment threshold. Therefore, it was identified that this local fault was a regional-level fault mode where multiple terminals simultaneously experienced the same type of anomaly, rather than a problem with a single terminal.

[0036] The edge autonomous decision-making module matches the identified fault type with a collaborative processing strategy from the edge autonomous strategy library. Specifically, the module uses 'multi-terminal core process anomaly' as the key to query the mapping table, matching collaborative processing strategy P001, and then automatically executes the operation sequence defined by that strategy. This strategy stipulates that when more than five terminals simultaneously experience core process anomalies and a single terminal fails to recover autonomously, it is considered a regional server-side fault. The edge autonomous decision-making module automatically performs the following collaborative processing operations: broadcasting a downgraded operation instruction to suspend toll collection services to all terminals in the region to avoid inconsistencies in transaction data; pulling the latest core service package from the backup service node; issuing a core service restart instruction to all ETC lane hosts in the region and pushing the updated package; and simultaneously generating a regional fault report and notifying maintenance personnel through a message channel. The entire collaborative processing process is completed within two minutes, and the faulty terminals gradually return to normal. The data reporting module summarizes the region's unified data view, local fault diagnosis results, collaborative processing operation records, and strategy execution effects into summary data, which is periodically reported to the cloud management module every six hours. In another scenario, the local fault diagnosis module identifies that the heartbeat connection between two adjacent lane terminals has been continuously lost for more than 30 seconds. The edge autonomous decision-making module determines that there is a communication failure between the terminals and automatically sends a configuration parameter synchronization command to the two terminals to restore the communication connection.

[0037] The cloud management module includes a data aggregation module and a fault classification module; The data aggregation module is used to receive aggregated data reported by each edge collaboration module, and to store the received aggregated data in the cloud database after standardization processing. The fault classification module is used to perform horizontal comparative analysis on the received aggregated data from various regions, and to identify and distinguish between common faults and faults specific to the jurisdiction. The fault classification module includes: The fault event standardization module is used to standardize and map fault events reported by various regions according to a preset fault type coding system, and generate standardized fault event records. The cross-regional frequency statistics module is used to count the frequency of the same standardized fault type occurring in different edge collaboration modules within their respective jurisdictions, and to generate a fault-region distribution matrix. The general fault identification module is used to identify fault types that occur more frequently than a preset regional threshold and are distributed in multiple regions based on the fault-region distribution matrix, and mark them as general faults; the general faults are characterized as common faults that are prevalent in all jurisdictions; The jurisdiction-specific fault identification module is connected to the cross-regional frequency statistics module. It is used to identify fault types that only appear in a single or fewer than a preset number of regions based on the fault-region distribution matrix, and mark them as jurisdiction-specific faults. The jurisdiction-specific faults are characterized as specific faults related to the environment, equipment model or configuration of a specific region.

[0038] Specifically, at the provincial highway network toll collection center, a cloud server cluster deploys a cloud management module responsible for receiving aggregated data reported by edge collaboration modules from thirty branch centers across the province. The data aggregation module standardizes the received aggregated data and stores it in the cloud database. The fault event standardization module standardizes and maps fault events reported by each region according to a preset fault type coding system. For example, different expressions such as "lane service unresponsive," "toll collection program stuck," and "core process crash" are uniformly mapped to the standardized fault type code F001, representing core process abnormality; "network disconnected," "ping unsuccessful," and "connection timeout" are uniformly mapped to F002, representing network connection failure. The cross-regional frequency statistics module counts the frequency of the same standardized fault type occurring in different edge collaboration module jurisdictions, generating a fault-region distribution matrix. The general fault identification module analyzes this matrix and finds that the standardized fault type F001, core process abnormality, occurs in all thirty regions, and the frequency in each region exceeds the preset regional threshold of ten times per day. Therefore, it is marked as a general fault, representing a common fault prevalent in all jurisdictions. The standardized fault type F015, overheating of a certain model of industrial PC, only occurred in three regions—Region A, Region B, and Region C—that used this model of industrial PC. This fault did not occur in other regions, and the region-specific fault identification module marked it as a region-specific fault. In another scenario, the standardized fault type F020, scheduled task execution failure, only occurred in Region D, and was also marked as a region-specific fault. Through this classification method, the cloud management module clearly understands that F001, core process anomaly, is a general problem that needs to be addressed at the system-wide level, while F015, overheating of the industrial PC, and F020, scheduled task execution failure, are specific problems that only occur in specific regions, providing accurate decision-making basis for subsequent strategy generation.

[0039] The cloud management module also includes a policy generation module; The strategy generation module is used to calculate the proportion of general faults and the proportion of specific faults in each region based on the general faults and specific faults in the regions under the jurisdiction of each edge collaboration module, and to select regions whose proportion of specific faults exceeds a preset threshold as key attention regions. For key areas of concern, the strategy generation module retrieves historical fault event records and a unified data view for that area, and identifies common characteristics of faults specific to that area through correlation analysis. These common characteristics include common fault occurrence time periods, common fault terminal models, common software version numbers, and common configuration parameters. The cause of the fault is located based on the identified common characteristics. The strategy generation module is also used to generate a global optimization strategy for the region based on the identified fault cause. The global optimization strategy includes one or more of the following: configuration parameter correction instructions, software patch upgrade packages, and baseline check strategy updates. The strategy is then sent to the corresponding edge collaboration module through a secure channel.

[0040] Specifically, the strategy generation module calculates the percentage of common faults and the percentage of unique faults for each region based on the common faults and region-specific faults within the jurisdiction of each edge collaboration module. Calculations revealed that region D had a unique fault rate of 38%, exceeding the preset threshold of 25%, thus region D was selected as a key focus region. The strategy generation module retrieved historical fault event records and the region's unified data view for correlation analysis of region D, finding that the F020 scheduled task execution failure rate was relatively high among the region-specific faults. Further analysis revealed common characteristics of this fault: the faults all occurred between 2:00 AM and 4:00 AM, the faulty terminals were all industrial control computers of a certain model, all with software version V1.2.3, and the scheduled task settings in the configuration parameters differed from other regions. The strategy generation module thus determined the cause of the fault to be a memory leak in the scheduled tasks of this model of industrial control computer under software version V1.2.3. Based on the identified cause, the strategy generation module generated a global optimization strategy for region D, including a software patch upgrade package for this model of industrial control computer and scheduled task configuration correction instructions, and distributed it to the corresponding edge collaboration module of region D through a secure channel. In another scenario, the proportion of unique faults in Region C reached 42%. Correlation analysis revealed that overheating of a certain model F015 industrial computer was a significant component of these unique faults in Region C. The faulty terminals were concentrated during the high-temperature summer months, and the air conditioning capacity in the data center of this region was insufficient. Based on this, the strategy generation module generated a global optimization strategy for Region C, including updating the baseline check strategy, adding temperature monitoring threshold adjustments, and checking the data center air conditioning operation status. This strategy was then deployed to the edge collaboration module of Region C for execution.

[0041] The strategy generation module also includes a fault cause localization module; The fault cause localization module is used to retrieve historical fault event records and a unified regional data view for the selected key areas of concern, analyze the common characteristics of faults specific to the jurisdiction, and locate the fault causes. The fault cause location module includes: The time concentration calculation module is used to divide a day into a preset number of time windows, count the number of occurrences of each specific fault type in each time window, and calculate the time concentration index of the fault. The time concentration index is equal to the number of windows with the most fault occurrences divided by the total number of occurrences. When the index exceeds the preset time concentration threshold, it is determined that the fault has time concentration, and the time window in which the fault occurs is located. The model concentration calculation module is used to count the frequency of occurrence of different models of terminals involved in each specific fault type, and calculate the model concentration index of the fault. The model concentration index is equal to the number of times the most frequently occurring model is divided by the total number of faulty terminals. When the index exceeds the preset model concentration threshold, it is determined that the fault is strongly correlated with a specific model, and the terminal model associated with the fault is located. The version concentration calculation module is used to count the frequency of occurrence of different software version numbers of terminals involved in each specific fault type, and calculate the version concentration index of the fault. The version concentration index is equal to the number of times the most frequently occurring version is divided by the total number of fault terminals. When the index exceeds the preset version concentration threshold, it is determined that the fault is strongly correlated with a specific software version, and the software version number associated with the fault is located. The configuration similarity calculation module is used to extract the configuration parameter vectors of the terminals involved in each specific fault type, calculate the average similarity between the configuration parameter vectors of all fault terminals, and the average similarity is the mean of the similarity between all terminal pairs. When the average similarity exceeds the preset configuration similarity threshold, it is determined that the configuration parameters of the fault terminal have a high degree of consistency. The comprehensive confidence score calculation module is used to calculate the comprehensive confidence score according to the time concentration index, model concentration index, version concentration index and configuration similarity index, according to the preset weights. When the comprehensive confidence score exceeds the preset confidence threshold, it is determined that the cause of the fault has been located, and the fault cause location result is generated based on the common feature that contributes the most.

[0042] The time concentration calculation module uses the following formula to calculate the time concentration index:

[0043] in, The number of time windows to be divided. This represents the number of times the fault type occurs within the k-th time window. At this time, the fault has a time-concentrated nature. The preset time concentration threshold; The model concentration calculation module uses the following formula to calculate the model concentration index:

[0044] Where M represents the set of all terminal models involved in the fault. This represents the number of faulty terminals of model m. The fault was determined to be strongly correlated with a specific model. The preset model concentration threshold; The version concentration calculation module uses the following formula to calculate the version concentration index:

[0045] in, This is the set of all software version numbers involved in the fault. For the number of faulty terminals with version number v, when The fault was determined to be strongly correlated with a specific software version. The preset version concentration threshold; The configuration similarity calculation module uses the following formula to calculate the average similarity:

[0046] Where n is the number of faulty terminals. and These are the configuration parameter vectors for the p-th and q-th faulty terminals, respectively. To configure the Jaccard similarity coefficient of the parameter vector, when The configuration parameters of the faulty terminals are highly consistent. Configure a similarity threshold; The comprehensive confidence score calculation module uses the following formula to calculate the comprehensive confidence score:

[0047] in , , , For the preset weighting coefficients, when The cause of the fault has been determined in time. To pre-set the reliability threshold.

[0048] The strategy generation module also includes a strategy verification module; The strategy verification module is used to continuously monitor the execution effect of the global optimization strategy after it is issued to the corresponding edge collaboration module, and automatically adjust the strategy parameters or trigger the strategy rollback based on the execution effect. The policy verification module includes: The policy execution tracking module is used to receive policy execution status information fed back by the edge collaboration module. The policy execution status information includes policy issuance success status, terminal configuration update result, software patch installation progress, and failure event change trend after policy execution. The effectiveness evaluation module, connected to the strategy execution tracking unit, is used to quantitatively evaluate the effectiveness of strategy execution based on preset evaluation indicators. These indicators include: changes in the incidence rate of the target fault type, changes in fault recovery time, and the number of new faults after strategy execution. When the incidence rate of the target fault type decreases for more than a preset threshold for a consecutive preset number of days after strategy execution, the strategy is evaluated as effective. When the incidence rate of the target fault type does not decrease or the number of new faults exceeds the preset threshold, the strategy is evaluated as ineffective. The strategy adjustment module, connected to the effect evaluation unit, is used to automatically perform one or more of the following operations when the strategy is evaluated as invalid: adjust the strategy parameters and reissue, trigger the strategy rollback operation to restore the state before execution, generate an exception report and mark the strategy as pending manual review. The policy optimization learning module is connected to the performance evaluation unit and the model training module, respectively. It is used to feed back policies evaluated as effective and their execution conditions as positive samples, and policies evaluated as ineffective and their execution conditions as negative samples to the model training module to optimize the accuracy of subsequent policy generation models.

[0049] Specifically, regarding the software patch upgrade package and scheduled task configuration correction instructions issued to Region D, the strategy execution tracking module continuously receives strategy execution status information from the edge collaboration module of Region D. On the first day after execution, the strategy execution tracking module received feedback showing that 28 industrial control computers of this model in Region D successfully installed the patch upgrade package, and the configuration correction instructions had been issued to all 36 terminals, of which 32 had successfully updated their configurations, and 4 had not yet updated due to network issues. The effect evaluation module quantitatively evaluates the strategy execution effect according to preset evaluation indicators, including changes in the incidence rate of target fault type F020, changes in fault recovery time, and the number of new faults after strategy execution. Over the next 14 consecutive days after strategy execution, the effect evaluation module tracked and calculated that the incidence rate of target fault type F020 decreased from an average of 15 times per day before execution to an average of 2 times per day, a decrease exceeding the preset threshold of 60%, and remained low for 14 consecutive days. Furthermore, no new fault types related to this strategy appeared, therefore the strategy was evaluated as effective. The strategy optimization learning module feeds this effective strategy and its execution conditions as positive samples back to the model training module to optimize the accuracy of subsequent strategy generation models.

[0050] In another scenario, regarding the baseline check policy update issued to Region C, after the policy execution tracking module provides feedback on the execution status, the effect evaluation module tracks and calculates that the occurrence rate of the target fault type F015 did not decrease significantly within seven days after execution. Instead, a new fault type F025 appeared on the third day, manifesting as frequent false alarms triggered by some terminals due to overly sensitive temperature monitoring threshold adjustments. Based on this, the effect evaluation module assesses the policy as ineffective. The policy adjustment module automatically performs a policy rollback operation, restoring the baseline check policy for Region C to its pre-execution state, and simultaneously generates an anomaly report marking the policy as awaiting manual review. The policy optimization learning module feeds back the ineffective policy and its execution conditions as negative samples to the model training module. After learning from this negative sample, the model training module avoids generating similar highly sensitive temperature monitoring threshold adjustment policies in subsequent policy generation. Through this closed-loop policy verification mechanism, the system ensures that the issued policies truly solve problems without introducing new ones, while continuously improving the accuracy of the policy generation model through the accumulation of positive and negative samples.

[0051] The above are merely embodiments of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. An intelligent operation and maintenance system for networked toll collection in transportation information systems, characterized in that: It includes a terminal management module, an edge collaboration module, and a cloud management module; The terminal management module is deployed on each toll terminal to handle emergency faults that require a response time of seconds. It collects the terminal's operating status data in real time, monitors abnormal data based on the operating status data and locally preset emergency rules, and executes emergency response operations when abnormal data is detected. The edge collaboration module is deployed on edge computing nodes and communicates with multiple terminal management modules. It is used to handle minute-level faults that do not require intervention from cloud management modules. It receives the operating status data of each terminal in the area under its jurisdiction, performs data fusion and local fault diagnosis. When a local fault is identified, it performs collaborative processing operations according to the edge autonomy strategy and generates summary data. The cloud management module, deployed in the cloud data center, communicates with each edge collaboration module to perform policy optimization. It receives aggregated data reported by each edge collaboration module, performs global data analysis based on the aggregated data, generates a global optimization policy based on the global data analysis results, and distributes it to each edge collaboration module. The edge collaboration module updates its own edge autonomy policy based on the global optimization policy.

2. The intelligent operation and maintenance system for networked toll collection in transportation information system according to claim 1, characterized in that: The terminal management module includes a data acquisition module, a fault diagnosis module, and an emergency operation module. The data acquisition module is used to collect the operating status data of the charging terminal in real time. The operating status data includes CPU utilization, memory utilization, disk read / write status, network connectivity, core process survival status, and log error frequency. The fault diagnosis module is used to analyze the collected operating status data in real time according to the preset emergency fault diagnosis rules, and to determine whether the current anomaly is an emergency fault that requires a second-level response. The emergency operation module is used to execute emergency operations based on the local emergency strategy library when an emergency fault is determined to be an emergency.

3. The intelligent operation and maintenance system for networked toll collection in transportation information system according to claim 2, characterized in that: The edge collaboration module includes a data aggregation module, a local fault diagnosis module, an edge autonomous decision-making module, and a data reporting module. The data aggregation module communicates with multiple terminal management modules within its jurisdiction to receive operational status data, emergency operation records, and real-time operational status data reported by each terminal. After cleaning and aligning the received data, it generates a unified data view for the region. The local fault diagnosis module is used to perform real-time analysis based on a unified regional data view and a pre-trained local fault diagnosis model to identify local faults occurring within its jurisdiction. These local faults include similar anomalies occurring simultaneously on multiple terminals, network interruptions between terminals, and faults that a single terminal cannot handle autonomously. The edge autonomous decision-making module is used to automatically generate and execute collaborative processing operations by matching the identified local fault types with the collaborative processing strategies in the edge autonomous strategy library. The data reporting module communicates with the cloud management module and is used to summarize the unified regional data view, local fault diagnosis results, collaborative processing operation records, and strategy execution effects to generate summary data, which is then periodically reported to the cloud management module.

4. The intelligent operation and maintenance system for networked toll collection in transportation information system according to claim 3, characterized in that: The cloud management module includes a data aggregation module and a fault classification module; The data aggregation module is used to receive aggregated data reported by each edge collaboration module, and to store the received aggregated data in the cloud database after standardization processing. The fault classification module is used to perform horizontal comparative analysis on the received aggregated data from various regions, and to identify and distinguish between common faults and faults specific to the jurisdiction. The fault classification module includes: The fault event standardization module is used to standardize and map fault events reported by various regions according to a preset fault type coding system, and generate standardized fault event records. The cross-regional frequency statistics module is used to count the frequency of the same standardized fault type occurring in different edge collaboration modules within their respective jurisdictions, and to generate a fault-region distribution matrix. The general fault identification module is used to identify fault types that occur more frequently than a preset regional threshold and are distributed in multiple regions based on the fault-region distribution matrix, and mark them as general faults; the general faults are characterized as common faults that are prevalent in all jurisdictions; The jurisdiction-specific fault identification module is connected to the cross-regional frequency statistics module. It is used to identify fault types that only appear in a single or fewer than a preset number of regions based on the fault-region distribution matrix, and mark them as jurisdiction-specific faults. The jurisdiction-specific faults are characterized as specific faults related to the environment, equipment model or configuration of a specific region.

5. The intelligent operation and maintenance system for networked toll collection in transportation information system according to claim 4, characterized in that: The cloud management module also includes a policy generation module; The strategy generation module is used to calculate the proportion of general faults and the proportion of specific faults in each region based on the general faults and specific faults in the regions under the jurisdiction of each edge collaboration module, and to select regions whose proportion of specific faults exceeds a preset threshold as key attention regions. For key areas of concern, the strategy generation module retrieves historical fault event records and a unified data view for that area, and identifies common characteristics of faults specific to that area through correlation analysis. These common characteristics include common fault occurrence time periods, common fault terminal models, common software version numbers, and common configuration parameters. The cause of the fault is located based on the identified common characteristics. The strategy generation module is also used to generate a global optimization strategy for the region based on the identified fault cause. The global optimization strategy includes one or more of the following: configuration parameter correction instructions, software patch upgrade packages, and baseline check strategy updates. The strategy is then sent to the corresponding edge collaboration module through a secure channel.

6. The intelligent operation and maintenance system for networked toll collection in transportation information system according to claim 5, characterized in that: The strategy generation module also includes a fault cause localization module; The fault cause localization module is used to retrieve historical fault event records and a unified regional data view for the selected key areas of concern, analyze the common characteristics of faults specific to the jurisdiction, and locate the fault causes. The fault cause location module includes: The time concentration calculation module is used to divide a day into a preset number of time windows, count the number of occurrences of each specific fault type in each time window, and calculate the time concentration index of the fault. The time concentration index is equal to the number of windows with the most fault occurrences divided by the total number of occurrences. When the index exceeds the preset time concentration threshold, it is determined that the fault has time concentration, and the time window in which the fault occurs is located. The model concentration calculation module is used to count the frequency of occurrence of different models of terminals involved in each specific fault type, and calculate the model concentration index of the fault. The model concentration index is equal to the number of times the most frequently occurring model is divided by the total number of faulty terminals. When the index exceeds the preset model concentration threshold, it is determined that the fault is strongly correlated with a specific model, and the terminal model associated with the fault is located. The version concentration calculation module is used to count the frequency of occurrence of different software version numbers of terminals involved in each specific fault type, and calculate the version concentration index of the fault. The version concentration index is equal to the number of times the most frequently occurring version is divided by the total number of fault terminals. When the index exceeds the preset version concentration threshold, it is determined that the fault is strongly correlated with a specific software version, and the software version number associated with the fault is located. The configuration similarity calculation module is used to extract the configuration parameter vectors of the terminals involved in each specific fault type, calculate the average similarity between the configuration parameter vectors of all fault terminals, and the average similarity is the mean of the similarity between all terminal pairs. When the average similarity exceeds the preset configuration similarity threshold, it is determined that the configuration parameters of the fault terminal have a high degree of consistency. The comprehensive confidence score calculation module is used to calculate the comprehensive confidence score according to the time concentration index, model concentration index, version concentration index and configuration similarity index, according to the preset weights. When the comprehensive confidence score exceeds the preset confidence threshold, it is determined that the cause of the fault has been located, and the fault cause location result is generated based on the common feature that contributes the most.

7. The intelligent operation and maintenance system for networked toll collection in transportation information system according to claim 5, characterized in that: The time concentration calculation module uses the following formula to calculate the time concentration index: in, The number of time windows to be divided. This represents the number of times the fault type occurs within the k-th time window. At this time, the fault has a time-concentrated nature. The preset time concentration threshold; The model concentration calculation module uses the following formula to calculate the model concentration index: Where M represents the set of all terminal models involved in the fault. This represents the number of faulty terminals of model m. The fault was determined to be strongly correlated with a specific model. The preset model concentration threshold; The version concentration calculation module uses the following formula to calculate the version concentration index: in, This is the set of all software version numbers involved in the fault. For the number of faulty terminals with version number v, when The fault was determined to be strongly correlated with a specific software version. The preset version concentration threshold; The configuration similarity calculation module uses the following formula to calculate the average similarity: Where n is the number of faulty terminals. and These are the configuration parameter vectors for the p-th and q-th faulty terminals, respectively. To configure the Jaccard similarity coefficient of the parameter vector, when The configuration parameters of the faulty terminals are highly consistent. Configure a similarity threshold; The comprehensive confidence score calculation module uses the following formula to calculate the comprehensive confidence score: in , , , For the preset weighting coefficients, when The cause of the fault has been determined in time. To pre-set the reliability threshold.

8. The intelligent operation and maintenance system for networked toll collection in transportation information system according to claim 5, characterized in that: The strategy generation module also includes a strategy verification module; The strategy verification module is used to continuously monitor the execution effect of the global optimization strategy after it is issued to the corresponding edge collaboration module, and automatically adjust the strategy parameters or trigger the strategy rollback based on the execution effect. The policy verification module includes: The policy execution tracking module is used to receive policy execution status information fed back by the edge collaboration module. The policy execution status information includes policy issuance success status, terminal configuration update result, software patch installation progress, and failure event change trend after policy execution. The effectiveness evaluation module, connected to the strategy execution tracking unit, is used to quantitatively evaluate the effectiveness of strategy execution based on preset evaluation indicators. These indicators include: changes in the incidence rate of the target fault type, changes in fault recovery time, and the number of new faults after strategy execution. When the incidence rate of the target fault type decreases for more than a preset threshold for a consecutive preset number of days after strategy execution, the strategy is evaluated as effective. When the incidence rate of the target fault type does not decrease or the number of new faults exceeds the preset threshold, the strategy is evaluated as ineffective. The strategy adjustment module, connected to the effect evaluation unit, is used to automatically perform one or more of the following operations when the strategy is evaluated as invalid: adjust the strategy parameters and reissue, trigger the strategy rollback operation to restore the state before execution, generate an exception report and mark the strategy as pending manual review. The policy optimization learning module is connected to the performance evaluation unit and the model training module, respectively. It is used to feed back policies evaluated as effective and their execution conditions as positive samples, and policies evaluated as ineffective and their execution conditions as negative samples to the model training module to optimize the accuracy of subsequent policy generation models.

Images