A terminal asset anomaly identification method based on multi-system comparison

Abstract

A method for identifying anomalies in terminal assets based on multi-system comparison is beneficial for automatically verifying data consistency and providing early warnings of anomalies during the flow of terminal assets across multiple systems, including supply chain, asset management, business operations, construction scheduling, and resource management. The method comprises the following steps: Step 1, multi-system data collection, collecting terminal asset data from multiple data source systems; Step 2, standardizing and mapping the terminal asset data into fields; Step 3, constructing a complete lifecycle event chain for each terminal device serial number (SN); Step 4, establishing a unified comparison rule base for multi-level anomaly identification; Step 5, using the unified comparison rule base, executing multi-level comparison rules through anomaly identification and multi-dimensional classification modules to generate structured anomaly identification results; and Step 6, outputting the anomaly identification results and early warning information from the early warning and reporting output layer.

Description

Technical Field

[0001] This invention relates to the field of data governance and asset management technology for IT systems of telecommunications operators, and in particular to a method for identifying anomalies in terminal assets based on multi-system comparison. This method is beneficial for automatically verifying data consistency and providing early warning of anomalies during the flow of terminal assets across multiple systems such as supply chain, asset management, business operations, construction scheduling, and resource management. Background Technology

[0002] As telecommunications operators deepen their digital transformation, the scale of terminal assets (including various user-side devices such as optical modems, set-top boxes, and routers) under management continues to expand, with a single provincial operator managing tens of millions of terminal assets. These terminal assets need to be transferred and recorded across multiple business systems throughout their entire lifecycle:

[0003] (1) Terminal Management System (AMS): It is responsible for the entire process management of terminal equipment, including warehousing, outbound, allocation, installation, recycling, and repair. It is the core system for terminal asset management.

[0004] (2) Construction scheduling system (integrated scheduling): responsible for the dispatch and execution of installation work orders and dismantling work orders, and recording the equipment SN information used in actual construction.

[0005] (3) BOSS business system: responsible for user business acceptance and management, recording user broadband business status (on the network, out of service, disconnected, etc.) and related equipment information.

[0006] (4) RMS Resource Management System: Responsible for the unified management of network resources, recording information such as port occupancy, computer room location, and resource status of devices.

[0007] (5) Supply chain system: responsible for the management of supply chain links such as material procurement, warehousing and outbound of terminal equipment, and recording information such as batch, quantity and flow of materials.

[0008] (6) O-domain activation system: responsible for online activation and authentication of terminal devices, and records information such as device activation status, authentication time, and online status.

[0009] (7) Big data platform and cloud monitoring system: aggregate data from various systems for statistical analysis and monitoring, and provide data reports and decision support.

[0010] Currently, data consistency verification in the industry mainly relies on manual verification, periodic report comparison, or internal verification mechanisms within a single system.

[0011] For example, existing technologies include single-system internal process verification: the AMS system performs internal consistency verification on its managed processes such as warehousing, outbound, allocation, and installation to ensure the integrity of operation records within the system; the BOSS system verifies the consistency between user business status and orders; and the supply chain system verifies the matching of material receipt and dispatch data. However, the above verifications are all limited to their respective systems and belong to the "intra-system verification" mode, which cannot detect data inconsistencies between cross-systems.

[0012] For example, in existing technologies, manual spot checks and report comparisons involve operators periodically (usually monthly or quarterly) organizing manual spot checks and verifications. Reports are exported from various systems and compared using tools such as Excel. This method is inefficient, relies on human experience, and is difficult to cover all abnormal scenarios, often only identifying the most obvious data discrepancies.

[0013] For example, in existing technologies, script-based batch comparison involves some operators developing automated scripts that periodically extract data from various system databases for batch comparison. However, these scripts are typically written for specific scenarios, lack a unified comparison rule system and anomaly classification capabilities, and are costly to maintain and have poor scalability.

[0014] The aforementioned existing technical solutions share the following common characteristics:

[0015] (1) Fragmentation: Each system is governed independently, data is not related to each other, and there is a lack of unified verification criteria and standards across systems.

[0016] (2) Lag: Multi-system reconciliation relies on reports and manual scripts, which has a long cycle and serious delays in anomaly detection.

[0017] (3) Inefficiency: Periodic manual verification is a huge workload and it is difficult to detect anomalies at the daily or hourly level.

[0018] (4) Incompleteness: It can only detect local and surface anomalies, and does not have the ability to perform full life cycle serial code link analysis and deep logic anomaly identification.

[0019] The shortcomings of the existing technology are as follows:

[0020] 1. Inconsistent serial number records across multiple systems prevent automatic detection of discrepancies. The same SN terminal device may display different status information in different systems. For example, an optical modem may show as "online" in the BOSS system, but be marked as "disassembled and recycled" in the AMS system; similarly, a device may show as "activated" in the O-domain system, but have no installation record in the AMS system. Existing technical solutions lack the ability to automatically compare status across systems, and these cross-system data inconsistencies remain undetected for a long time, leading to discrepancies between asset records and actual inventory.

[0021] 2. Lack of "end-to-end comparison" capability. From procurement and warehousing to final disposal, terminal equipment undergoes a complete lifecycle process: "supply chain warehousing → AMS outbound → integrated commissioning and installation → BOSS activation → O-domain activation → operation → integrated commissioning and dismantling → AMS recycling → disposal." Current technology cannot string together these events scattered across various systems into a coherent lifecycle event chain for end-to-end consistency verification, lacking a global perspective for link analysis.

[0022] 3. The anomaly classification is crude, only able to detect simple errors. Existing solutions can typically only identify the most basic data missing or format errors, and cannot identify complex cross-system business logic contradictions. For example, the following anomaly scenarios are difficult for existing solutions to detect: (a) the same SN has conflicting states in multiple systems; (b) the device SN associated with the construction work order is inconsistent with the actual installed device SN in the AMS system; (c) the BOSS system shows that the user is online, but the corresponding device in the AMS system has been reclaimed; (d) the O domain system shows that the device is activated, but there is no corresponding installation operation record in the AMS system; (e) the device activation time is earlier than the installation time, etc., which are time-series logic contradictions.

[0023] 4. The data logic is complex and difficult to manually verify. Different systems differ in field structure, time format, status enumeration values, and business logic definitions. For example, the same "device serial number" field may be named "SN," "serial code," "device identification number," or "devCode" in different systems; the enumeration values ​​for device status also vary across systems. Manual verification requires a deep understanding of each system's data dictionary and business rules, which is extremely costly and prone to omissions.

[0024] 5. Lack of automated early warning mechanisms. Current anomaly detection mainly relies on post-event report analysis and manual investigation, which cannot achieve near real-time monitoring and proactive early warning. Once a data anomaly occurs, there is often a lag of several days or even months between the occurrence of the anomaly and its discovery, leading to the accumulation and expansion of problems and a significant increase in repair costs. Summary of the Invention

[0025] This invention addresses the shortcomings or defects in existing technologies by providing a method for identifying anomalies in terminal assets based on multi-system comparison. This method facilitates automatic verification and early warning of anomalies in the flow of terminal assets across multiple systems, including supply chain, asset management, business operations, construction scheduling, and resource management.

[0026] The technical solution of the present invention is as follows:

[0027] A method for identifying anomalies in terminal assets based on multi-system comparison, characterized by comprising the following steps:

[0028] Step 1: Multi-system data collection, collecting terminal asset data from multiple data source systems;

[0029] Step 2: Standardize and map the terminal asset data.

[0030] Step 3: Construct a complete lifecycle event chain for each terminal device serial number (SN);

[0031] Step 4: Establish a unified comparison rule base for multi-level anomaly identification;

[0032] Step 5: Using a unified comparison rule base, execute multi-level comparison rules through the anomaly identification and multi-dimensional classification modules to form structured anomaly identification results;

[0033] Step 6: The early warning and reporting output layer outputs the anomaly identification results and early warning information.

[0034] In step 1, multiple data source systems include the supply chain system, AMS system, BOSS system, integrated dispatch system, O-domain activation system, and RMS system. The terminal asset data is associated with the device serial number (SN) as a unified primary key. Metadata information recorded during the collection process includes the collection timestamp, data source identifier, and data version number, which are used for subsequent data traceability and consistency verification. For data that fails to be collected, the system automatically records the reason for the failure and triggers a retry mechanism to ensure the integrity of the data collection.

[0035] Step 2 includes a standardization process that converts heterogeneous data from various systems into a unified standard data format. The standardization process includes four steps: field name mapping, data type conversion, enumeration value unification, and time format standardization.

[0036] Step 3 includes event type definition, event chain construction algorithm, and event chain integrity analysis; the SN event chain structure in the event chain construction algorithm includes event nodes with sequence numbers from E01 to E11: E01, purchase receipt; E02, warehouse departure; E03, transfer; E04, installation; E05, service activation; E06, equipment activation; E08, service change; E09, dismantling and recycling; E10, repair and maintenance; E11, scrapping.

[0037] Step 4 includes a hierarchical unified comparison rule base, where basic comparison rules are defined as one-star R1 class, logical comparison rules as two-star R2 class, and time-series comparison rules as three-star R3 class. R1 class involves cross-system state consistency verification, R2 class involves business relationship verification, and R3 class involves event chain time sequence constraints. R1 class includes R1-01 (device type must be consistent), R1-02 (core state compatibility), R1-03 (installed equipment traceability), and R1-04 (in...). Network device status binding; R2 category includes R2-01 work order device consistency, R2-02 installation-activation correlation, R2-03 recycling-dismantling correlation, R2-04 one machine for multiple users detection, R2-05 inventory flow consistency; R3 category includes R3-01 purchase and outbound sequence, R3-02 outbound installation sequence, R3-03 installation and activation sequence, R3-04 installation and activation sequence, R3-05 shutdown and dismantling sequence, R3-06 dismantling and repair sequence, R3-07 geographical and time consistency.

[0038] Step 5 involves inputting the SN event chain data into the first-layer basic comparison rule, the second-layer logical comparison rule, and the third-layer temporal comparison rule, respectively, and then starting the rule execution engine. The engine performs conflict resolution and result aggregation according to the priority order R3 > R2 > R1, resulting in the following anomaly classification outputs: EX-01 status conflict, EX-02 work order anomaly, EX-03 serial number conflict, EX-04 temporal anomaly, EX-05 data missing, and EX-06 correlation contradiction.

[0039] The anomaly record in step 5 includes the anomaly identification result, including the number, serial number, type, triggering rule, system involved, data snapshot, severity level, anomaly confidence level, and suggested handling method.

[0040] The abnormal results output in step 6 include: a terminal abnormality list, an abnormality classification statistical report, an abnormality distribution heat map, an SN link restoration diagram, real-time early warning push, and an abnormality handling work order.

[0041] This invention provides a terminal asset anomaly identification method based on multi-system comparison, which has the following significant technical advantages compared with existing technologies:

[0042] 1. Unified governance capability for cross-system, multi-source data. This invention is the first to achieve unified collection, standardized mapping, and fusion analysis of terminal asset data from six core systems, including supply chain, AMS, integrated dispatch, BOSS, O domain, and RMS, breaking the data silos between systems in traditional solutions. Through a unified field mapping mechanism and standardized processing flow, it solves the technical challenge of directly comparing heterogeneous data from multiple systems.

[0043] 2. This invention introduces "event chain timing comparison" technology for the first time. It innovatively proposes a timing comparison method based on the entire lifecycle event chain of the SN, capable of identifying hidden timing anomalies that traditional solutions cannot detect. For example, complex anomaly scenarios such as "activation time earlier than installation time" or "the same device appearing in different locations within a short period" can only be effectively identified through the timing comparison rules of this invention.

[0044] 3. Refined anomaly classification with strong interpretability. This invention establishes a refined classification system encompassing six major anomaly categories. Each anomaly record includes complete traceability information such as triggering rules, involved systems, and data snapshots. Operations personnel can directly locate the root cause system and responsible link based on the anomaly classification and link reconstruction results, significantly reducing anomaly investigation time.

[0045] 4. Automated processing, supporting near real-time verification. Compared with existing solutions that rely on manual periodic verification, this invention realizes a fully automated process for data collection, standardization, comparison, anomaly identification, and early warning push. It supports near real-time verification frequencies at the daily or even hourly level, reducing the anomaly detection time from several days or months in traditional solutions to the hourly level.

[0046] 5. The comparison rule system is scalable and customizable. The three-tier rule system of this invention adopts an architecture that separates rules from the engine. Adding new comparison rules does not require modification of the core engine code; simply adding rule definitions through configuration is sufficient for them to take effect. Furthermore, the framework supports flexible integration with new data source systems, exhibiting excellent scalability.

[0047] 6. Improve the quality of business operations. Through automated anomaly identification and early warning mechanisms, common business operation errors such as incorrect installation codes, incorrect equipment recycling, and multiple users for one device can be effectively avoided, reducing user complaints and operational losses caused by data inconsistencies, and improving the level of precision in terminal asset management.

[0048] 7. Enhance data credibility and solidify the foundation for decision-making. This invention continuously improves the consistency and accuracy of data across systems through multi-system data comparison and anomaly repair, providing a more accurate and reliable data foundation for operators' decision analysis, performance evaluation, and regulatory reporting. Attached Figure Description

[0049] Figure 1 This is a schematic diagram of the overall process for implementing the present invention, a terminal asset anomaly identification method based on multi-system comparison. Figure 1The process includes: Step 1, multi-system data collection (e.g., multiple data source systems such as supply chain system, AMS system, BOSS system, integrated dispatch system, O domain activation system, and RMS system; RMS is the resource management system, O domain is the operation domain, BOSS is the business operation support system, and AMS is the asset management system); Step 2, data standardization and field mapping of the collected data from multiple systems; Step 3, constructing the terminal's full lifecycle event chain (SN is the device serial number) at the SN link construction and comparison layer; Step 4, establishing a unified comparison rule base for multi-level anomaly identification; Step 5, using the unified comparison rule base, executing multi-level comparison rules through the anomaly identification and multi-dimensional classification module to form structured anomaly identification results; Step 6, outputting the anomaly identification results and early warning information by the early warning and reporting output layer.

[0050] Figure 2 This is a schematic diagram of the SN event chain structure involved in the terminal asset anomaly identification method based on multi-system comparison of the present invention. SN stands for Serial Number. Figure 2 The process from the starting point to the ending point of the SN equipment includes the following event nodes: E01, Procurement and Warehousing (Supply Chain System, new equipment arrives and is put into storage); E02, Warehouse Outbound (Supply Chain System / Asset Management System AMS, equipment is moved from the warehouse to a branch office or outlet); E03, Transfer and Allocation (Asset Management System AMS, equipment is transferred between different warehouses or outlets); E04, Installation and Setup (Asset Management System AMS / Comprehensive Dispatch System, equipment is installed on the user side); E05, Business Activation (BOSS System, user business is officially activated); E06, ... Equipment activation (O domain activation system, equipment online activation authentication successful); E07, Operation (O domain / monitoring system, equipment is running normally); E08, Business change (BOSS system, user business status changes, shutdown / restart, etc.); E09, Dismantling and recycling (Asset Management System AMS / Comprehensive Dispatch System, equipment is dismantled and recycled from the user side); E10, Repair and maintenance (Asset Management System AMS, equipment is sent for repair or repair is completed); E11, Scrap disposal (Asset Management System AMS, equipment meets the scrap conditions and is scrapped).

[0051] Figure 3 This is a diagram of the three-level comparison rule system architecture involved in the terminal asset anomaly identification method based on multi-system comparison of the present invention. Figure 3It includes a hierarchical unified comparison rule base, namely: the first layer of basic comparison rules (cross-system status consistency verification, R1-01 device type must be consistent; R1-02 core status compatibility; R1-03 installed equipment traceability; R1-04 on-network device status binding); the second layer of logical comparison rules (business relationship verification, R2-01 work order device consistency; R2-02 installation-activation correlation; R2-03 recycling-disassembly correlation; R2-04 one machine for multiple users detection; R2-05 inventory flow consistency); and the third layer of time sequence comparison rules (event chain time sequence constraints, R3-01 purchase and delivery time sequence; R3-02 delivery and installation time sequence; R3-03...). The following time-series data are generated: R3-04 Installation and Activation Time-series; R3-05 Shutdown and Dismantling Time-series; R3-06 Dismantling and Repair Time-series; R3-07 Geographic Time Consistency. The SN event chain data is input into the first-layer basic comparison rules, the second-layer logical comparison rules, and the third-layer time-series comparison rules, respectively. The rule execution engine is then started, and conflict resolution and result aggregation are performed according to priority: R3 > R2 > R1. The following anomaly categories are output: EX-01 Status Conflict; EX-02 Work Order Anomaly (Work Order Equipment Inconsistency); EX-03 Serial Code Conflict; EX-04 Time-Series Anomaly; EX-05 Data Missing; EX-06 Association Contradiction (Recycling / Activation Contradiction).

[0052] Figure 4 This is a flowchart of the anomaly identification and classification process involved in the anomaly identification method for terminal assets based on multi-system comparison of the present invention. Figure 4 This includes performing event chain integrity analysis based on SN event chain data input (missing key events are marked EX-05); determining whether cross-system state consistency verification is triggered based on basic comparison rules R1-01 to R1-04; if so, matching exception categories EX-01 state conflict and EX-03 serial code conflict and then summarizing all exception records; if not, directly summarizing all exception records; or determining whether business relationship verification is triggered based on logical comparison rules R2-01 to R2-05; if so, matching exception categories EX-02 work order device inconsistency and EX-06 recycling / activation contradiction and then summarizing all exceptions. If no record is found, proceed directly to summarizing all abnormal records; or, based on the time sequence comparison rules R3-01 to R3-07, determine whether the event chain time sequence constraint has been triggered. If so, match the abnormality category EX-04 time sequence abnormality and then summarize all abnormal records. If not, proceed directly to summarizing all abnormal records. For all abnormal records, prioritize and resolve conflicts, with R3 > R2 > R1, and higher priority conclusions take precedence in case of conflicts. Generate abnormal records, including number, SN, type, triggering rule, involved system, data snapshot, severity level, abnormality confidence, and suggested handling method; abnormal list, statistical report, and early warning push. Detailed Implementation

[0053] The following is in conjunction with the attached diagram ( Figures 1-4 The present invention will be described in conjunction with the embodiments.

[0054] Figure 1 This is a schematic diagram of the overall process for implementing the present invention, a terminal asset anomaly identification method based on multi-system comparison. Figure 2 This is a schematic diagram of the SN event chain structure involved in the terminal asset anomaly identification method based on multi-system comparison of the present invention. Figure 3 This is a diagram of the three-level comparison rule system architecture involved in the terminal asset anomaly identification method based on multi-system comparison of the present invention. Figure 4 This is a flowchart illustrating the anomaly identification and classification process involved in the terminal asset anomaly identification method based on multi-system comparison of this invention. (Reference) Figures 1 to 4 As shown, a terminal asset anomaly identification method based on multi-system comparison includes the following steps: Step 1, multi-system data collection, collecting terminal asset data from multiple data source systems; Step 2, standardizing and mapping the terminal asset data into fields; Step 3, constructing a complete lifecycle event chain for each terminal device serial number (SN); Step 4, establishing a unified comparison rule base for multi-level anomaly identification; Step 5, using the unified comparison rule base, executing multi-level comparison rules through anomaly identification and multi-dimensional classification modules to form structured anomaly identification results; Step 6, outputting the anomaly identification results and early warning information from the early warning and reporting output layer.

[0055] In step 1, multiple data source systems include the supply chain system, AMS system, BOSS system, integrated dispatch system, O-domain activation system, and RMS system. The terminal asset data is associated with the device serial number (SN) as a unified primary key. Metadata information recorded during the collection process includes the collection timestamp, data source identifier, and data version number, which are used for subsequent data traceability and consistency verification. For data that fails to be collected, the system automatically records the reason for the failure and triggers a retry mechanism to ensure the integrity of the data collection.

[0056] Step 2 includes a standardization process that converts heterogeneous data from various systems into a unified standard data format. This standardization process includes four steps: field name mapping, data type conversion, enumeration value unification, and time format standardization. Step 3 includes event type definition, event chain construction algorithm, and event chain integrity analysis. The SN event chain structure in the event chain construction algorithm includes event nodes with sequence numbers from E01 to E11: E01, Procurement receipt; E02, Warehouse outbound; E03, Transfer; E04, Installation; E05, Service activation; E06, Equipment activation; E08, Service change; E09, Dismantling and recycling; E10, Repair and maintenance; E11, Scrap disposal.

[0057] Step 4 includes a hierarchical unified comparison rule base, where basic comparison rules are defined as one-star R1 class, logical comparison rules as two-star R2 class, and time-series comparison rules as three-star R3 class. R1 class involves cross-system state consistency verification, R2 class involves business relationship verification, and R3 class involves event chain time sequence constraints. R1 class includes R1-01 (device type must be consistent), R1-02 (core state compatibility), R1-03 (installed equipment traceability), and R1-04 (in...). Network device status binding; R2 category includes R2-01 work order device consistency, R2-02 installation-activation correlation, R2-03 recycling-dismantling correlation, R2-04 one machine for multiple users detection, R2-05 inventory flow consistency; R3 category includes R3-01 purchase and outbound sequence, R3-02 outbound installation sequence, R3-03 installation and activation sequence, R3-04 installation and activation sequence, R3-05 shutdown and dismantling sequence, R3-06 dismantling and repair sequence, R3-07 geographical and time consistency.

[0058] Step 5 involves inputting the SN event chain data into the first-layer basic comparison rules, the second-layer logical comparison rules, and the third-layer temporal comparison rules, respectively, and then starting the rule execution engine. Conflict resolution and result aggregation are performed according to priority (R3 > R2 > R1), resulting in the following anomaly classification outputs: EX-01 Status Conflict, EX-02 Work Order Anomaly, EX-03 Serial Code Conflict, EX-04 Temporal Anomaly, EX-05 Data Missing, and EX-06 Association Conflict. The anomaly records in Step 5 include the anomaly number, SN, type, triggering rule, involved system, data snapshot, severity level, anomaly confidence, and suggested handling method. Step 6 outputs the following anomaly results: a terminal anomaly list, anomaly classification statistical report, anomaly distribution heatmap, SN link reconstruction diagram, real-time early warning push, and anomaly handling work orders.

[0059] This invention relates to the field of data governance and asset management technology for telecommunications operator IT systems, specifically an automatic diagnostic method for terminal assets based on multi-system data comparison, verification, and anomaly identification, falling under the category of terminal asset lifecycle management and data consistency detection technology. Specifically, this invention utilizes key technologies such as multi-source heterogeneous data acquisition, cross-system field standardization mapping, construction of a full lifecycle event chain for terminal serial numbers (SNs), a multi-level comparison rule engine, and automated anomaly identification and classification to achieve automatic verification and anomaly warning for data consistency during the flow of terminal assets across multiple systems, including supply chain, asset management, business operations, construction scheduling, and resource management.

[0060] The technical problems involved in this invention include:

[0061] 1. How to build a unified terminal asset reconciliation model across multiple heterogeneous business systems to achieve standardized integration of multi-source data.

[0062] 2. How to automatically identify data conflicts and logical contradictions across systems during the entire lifecycle of a terminal SN.

[0063] 3. How to provide multi-dimensional and interpretable anomaly classification results to accurately locate the root cause system of anomalies.

[0064] 4. How to develop automated, near real-time data anomaly identification and early warning capabilities to replace manual periodic checks.

[0065] 5. How to build an extensible comparison framework that supports flexible access to more external systems and custom comparison rules.

[0066] This invention proposes a method for identifying anomalies in terminal assets based on multi-system comparison. Through multi-source data collection, reconciliation model construction, hierarchical verification rule base, event chain analysis, and anomaly classification, it achieves data consistency verification and anomaly identification throughout the entire lifecycle of terminal assets. The overall technical solution comprises six core steps (S1 to S6), and the overall process is as follows: Figure 1 As shown. Figure 1 The left side of the middle section contains multiple data source systems (supply chain system, AMS system, BOSS system, integrated dispatch system, O domain activation system, RMS system). Data is collected from multiple sources through the data acquisition layer (S1); fields are uniformly mapped through the data standardization and mapping layer (S2); the SN link construction and comparison layer (S3) constructs the terminal's full lifecycle event chain; multi-level comparison rules are executed through the anomaly identification and classification module (S4); and finally, the early warning and report output layer (S5 / S6) outputs the anomaly identification results and early warning information. The data flow between these layers is top-down.

[0067] Step S1: Multi-system data acquisition

[0068] This invention first establishes a multi-system data acquisition mechanism to collect core data related to terminal assets from various business systems. The acquisition methods include direct database connection, system API calls, message queue subscription, and batch file import, supporting both full and incremental acquisition modes. Key fields collected from each system are shown in Table 1.

[0069] Table 1 Key Fields Collected by Each System

[0070] Serial Number Data source system Collect key fields sampling frequency 1 Supply chain system Inbound order number, outbound order number, serial number (SN), material number, material name, warehouse code, inbound time, outbound time, supplier Daily increase / real-time 2 AMS Terminal Management System Serial Number (SN), Equipment Type, Inbound Record, Outbound Record, Transfer Record, Installation Record, Recycling Record, Repair Record, Equipment Status, Operation Time Daily increase / real-time 3 Construction scheduling system (integrated scheduling) Work order number, work order type (installation / removal), equipment serial number (SN), work address, work personnel, planned time, completion time, work order status Daily increase 4 BOSS Business System User ID, Broadband Number, Service Status (Online / Out of Service / Disconnected), Associated Device SN, Service Activation Time, Service Change Time Daily increment / real-time 5 O-domain activation system Device SN, Activation Status, Authentication Method, First Activation Time, Last Online Time, Online Status Daily increase 6 RMS Resource Management System Device SN, resource status, port information, data center location, region, resource allocation time Daily increase

[0071] All system data is linked using the device serial number (SN) as a unified primary key. During data acquisition, metadata such as data acquisition timestamp, data source identifier, and data version number are recorded simultaneously for subsequent data traceability and consistency verification. For data acquisition failures, the system automatically records the reason for the failure and triggers a retry mechanism to ensure the integrity of the data acquisition.

[0072] Step S2: Data Standardization and Field Mapping

[0073] Because different systems have different data dictionaries and field naming conventions, this invention designs a unified data standardization and field mapping mechanism to convert heterogeneous data from various systems into a unified standard data format. The standardization process includes four steps: field name mapping, data type conversion, enumeration value unification, and time format standardization.

[0074] (1) Field name mapping. A global field mapping table is established to map fields with the same meaning but different names in different systems to standard field names. The main mapping rules are shown in Table 2.

[0075] Table 2 Field Standardization Mapping Table

[0076] Standard field name Field meaning Supply chain system AMS system Integrated Dispatch System BOSS System O-domain system RMS system devCode Device serial number SN Serial number Device SN Terminal SN Device SN Device SN devType Equipment type Material Name Equipment type - - Equipment type - status Equipment / Service Status Inventory status Equipment status Work order status Business Status Activated Resource status opTime Operation time Inbound and outbound time Operation time Completion time Change time Activation time Allocate time location Location information Warehouse code Installation address Construction address User address - Computer room location operatorId Operator identification Person in charge Operator Construction workers Service Number - -

[0077] (2) Data type conversion and unified enumeration value. Unified encoding is performed for enumeration values ​​that have the same meaning but different expression methods in different systems. For example, the value of the device status field in different systems may be "in stock / out stock / installed" (AMS), "on network / out of service / dismantled" (BOSS), "activated / not activated" (O field), etc. This invention establishes a unified status encoding system to map the above heterogeneous status values ​​to a standardized status encoding set.

[0078] (3) Time format standardization. Time fields in different systems may use different formats (such as "yyyy-MM-ddHH:mm:ss", "yyyyMMdd", Unix timestamp, etc.). This invention converts all time fields into the standard UTC timestamp format to facilitate subsequent time series comparison and analysis. At the same time, records with missing or abnormal time fields are marked as input for subsequent anomaly identification.

[0079] (4) Data quality pre-inspection. Data quality pre-inspection is performed simultaneously during the standardization process, including: completeness check of required fields, compliance check of SN format (length, character set), reasonableness check of time field (not earlier than the equipment production date, not later than the current time), and identification and deduplication of duplicate records. The pre-inspection results are recorded in the data quality log to provide a reference for subsequent anomaly analysis.

[0080] Step S3: Construct the terminal's full lifecycle event chain

[0081] One of the core innovations of this invention is the construction of a complete lifecycle event chain for each terminal device (SN). The event chain uses the SN as a unique identifier and sequentially links the device's operation records across all systems to form a directed, time-series event sequence.

[0082] (1) Event type definition. The present invention defines the following standard event types, covering the complete life cycle of the terminal device, as shown in Table 3.

[0083] Table 3. Definition of Terminal Device Lifecycle Event Types

[0084] Event Number Event Type Event Source System Meaning of the event E01 Purchase and warehousing Supply chain system New equipment arrived and was put into storage. E02 Warehouse outbound Supply Chain System / AMS Equipment is shipped from the warehouse to branch offices or outlets. E03 Transfer AMS system Equipment transfer between different warehouses or outlets E04 Installation AMS / Comprehensive Control System Equipment installed on the user side E05 Service activation BOSS System User services officially launched E06 Device activation O-domain activation system Device online activation and authentication successful E07 Use Run O Domain / Monitoring System Equipment is running normally E08 Business Change BOSS System User service status changes (service suspension / reinstatement, etc.) E09 Dismantling and recycling AMS / Comprehensive Control System The equipment was removed and recycled from the user side. E10 Repair and maintenance AMS system Equipment sent for repair or repair completed E11 Scrapping AMS system The equipment has reached the end of its service life and will be disposed of accordingly.

[0085] (2) Event Chain Construction Algorithm. For each device SN, all operation records of that SN are retrieved from all standardized system data, sorted in ascending order by operation time (opTime), and a time-series event chain for that device is generated. The data structure definition of the event chain is as follows: Figure 2 As shown. Figure 2 This example uses a single SN device to illustrate its complete event chain from warehousing to disposal. The event chain is a directed timeline from left to right, with each event node labeled sequentially: [Purchase and Warehousing] → [Warehouse Outbound] → [Transfer and Relocation] → [Installation] → [Equipment Activation] → [Usage and Operation] → [Dismantling and Recycling] → [Disposal]. Each node is labeled with the event's source system and timestamp. Dashed nodes in the event chain indicate that the event is missing in the corresponding system.

[0086] (3) Event chain integrity analysis. After the event chain is constructed, the system automatically analyzes the integrity of the event chain. According to the predefined standard lifecycle process template, the system checks whether there are any missing key events in the event chain of each SN. For example, if a device shows that the service has been activated in the BOSS system, but the "installation" event is missing in the event chain, it is marked as a "key event missing" anomaly.

[0087] Step S4: Unify the comparison rule base (key innovation)

[0088] This invention designs a hierarchical unified comparison rule base, which includes three levels: basic comparison rules, logical comparison rules, and temporal comparison rules, forming a multi-level anomaly identification system from simple to complex and from surface to deep.

[0089] (1) Basic Comparison Rules. Basic comparison rules are used to detect the most basic data consistency between systems, and mainly include the following rules:

[0090] Rule R1-01: The device type recorded for the same SN in multiple systems must be consistent. If the AMS system records it as "optical modem" while the BOSS system records it as "set-top box", a device type conflict exception will be triggered.

[0091] Rule R1-02: The core states of the same SN in multiple systems must satisfy a predefined compatibility matrix. For example, if the BOSS system state is "online", then the AMS system state cannot be "reclaimed" or "scrapped".

[0092] Rule R1-03: The equipment SN recorded in the installation work order of the integrated dispatch system must exist in the warehousing record of the supply chain system or the inventory record of the AMS system.

[0093] Rule R1-04: The device SN associated with a user in the "online" state in the BOSS system must exist in the AMS system and be in the "installed" state.

[0094] Example of a formal expression for a basic comparison rule: IF (BOSS.status = "Online") AND (AMS.status = "Disassembled" OR AMS.status = "Reclaimed") THEN Exception_Type = "Cross-system status conflict", Severity = "Severe".

[0095] (2) Logical comparison rules. Logical comparison rules are used to identify deep-seated anomaly scenarios where "the surface data appears normal, but there are actual business logic contradictions." These anomalies typically involve verifying the business relationships between two or more systems:

[0096] Rule R2-01 (Work Order Equipment Consistency): The actual installed equipment SN recorded in the installation work order of the integrated commissioning system must be consistent with the equipment SN associated with this installation operation in the AMS system. If they are inconsistent, it will be marked as an "Inconsistent Work Order Equipment" exception.

[0097] Rule R2-02 (Installation-Activation Association): Devices displayed as "Activated" in the O domain activation system must have a corresponding "Installation" operation record in the AMS system. If there is no installation record in the AMS system, it is marked as an "Activation without Installation" exception.

[0098] Rule R2-03 (Recycling-Dismantling Correlation): Equipment marked as "Recycled" in the AMS system must have a corresponding dismantling work order in the integrated commissioning system, and the work order status must be "Completed". If there is no dismantling record or the work order is incomplete in the integrated commissioning system, it is marked as "Recycled but Not Dismantled" abnormal.

[0099] Rule R2-04 (Multiple Users per Device Detection): Within the same time period, the same SN device should not be associated with multiple users in an "online" state. If this situation is detected, it will be marked as an "multiple users per device" anomaly.

[0100] Rule R2-05 (Inventory Flow Consistency): The target warehouse or outlet for equipment outbound from the supply chain system should be consistent with the source of the equipment inbound from the AMS system. If they are inconsistent, it should be marked as "Inventory Flow Abnormal".

[0101] Example of a formal expression for a logical comparison rule: IF (Comprehensive Inspection.Work Order Equipment SN != AMS.Installation Equipment SN) AND (Comprehensive Inspection.Work Order Number = AMS.Associated Work Order Number) THEN Exception_Type = "Work Order Equipment Inconsistency", Severity = "Severe".

[0102] (3) Timing Comparison Rules (Core Innovation of this Invention). Timing comparison rules are one of the core innovations of this invention. Based on the event chain constructed in step S3, the timing sequence of events is logically verified. The lifecycle events of the terminal device must meet strict temporal order constraints; violation of these constraints constitutes an anomaly. The timing constraint rules defined in this invention are as follows:

[0103] Rule R3-01: The time of purchase receipt must be earlier than the time of warehouse departure (equipment must be received into the warehouse before it is issued).

[0104] Rule R3-02: Warehouse outbound time must be earlier than installation time (equipment must be outbound before installation).

[0105] Rule R3-03: The installation time must be earlier than the activation time (the device must be installed before activation).

[0106] Rule R3-04: The installation time must be earlier than the service activation time (the equipment must be installed before the service is activated).

[0107] Rule R3-05: Service downtime must be earlier than the dismantling and recycling time (service must be stopped before dismantling).

[0108] Rule R3-06: The disassembly and recycling time must be earlier than the repair time (the machine must be disassembled and recycled before it can be repaired).

[0109] Rule R3-07: The same SN cannot appear in installation records in two different geographical locations within the same time window (e.g., within 24 hours).

[0110] Formal expression example of timing comparison rule: IF EventChain(SN).E06.opTime < EventChain(SN).E04.opTime (i.e., device activation time < installation time) THEN Exception_Type = "activation - installation timing exception", Severity = "severe".

[0111] The execution process of the timing comparison algorithm is as follows: traverse each pair of adjacent events in the event chain and check whether the timestamps meet the predefined timing constraints. For non - adjacent events with timing dependencies (such as storage time and activation time), transitive constraints are used for checking. When a timing exception is detected, record the exception event pair, time difference, and the system source information involved.

[0112] (4) Rule priority and conflict handling. When multiple rules are triggered by the same SN simultaneously, a priority mechanism is used for handling: the timing comparison rule has the highest priority, the logical comparison rule has the second - highest priority, and the basic comparison rule has the lowest priority. When the conclusions of multiple rules conflict with each other, the conclusion of the high - priority rule shall prevail, and the conclusion of the low - priority rule is marked as "pending review".

[0113] Figure 3 The hierarchical relationship of the basic comparison rule (bottom layer), logical comparison rule (middle layer), and timing comparison rule (top layer) is shown. The three levels are executed sequentially from bottom to top, and the comparison result of each layer is used as the input of the upper layer. The rule execution engine uniformly schedules the execution of rules at each level and the convergence of results.

[0114] Step S5: Exception identification and multi - dimensional classification

[0115] Based on the comparison rule execution results in step S4, the present invention classifies and marks the identified exceptions according to multiple dimensions, forming a structured exception identification result. The exception classification system is shown in Table 4.

[0116] Table 4 Exception classification system

[0117] Abnormal categories Exception coding Exception Description Severity level Typical scenarios State conflict class EX-01 The states of the same SN are contradictory in different systems serious The BOSS is online, but AMS has been retrieved. Work order exceptions EX-02 Inconsistency between construction work orders and actual operation records serious The work order number (SN) does not match the installation number (SN). Serial number collision class EX-03 Inconsistent SN association information between multiple systems medium The same user is associated with different SNs on different systems. Timing exception class EX-04 The chronological order in the event chain violates logical constraints. serious Activation time is earlier than installation time Data missing class EX-05 The critical system lacks the necessary operation logs. medium There is an installation but no corresponding inventory record. Related contradictions EX-06 There are contradictions in the business relationships across systems. medium One machine for multiple households or one household for multiple machines

[0118] Each exception record contains the following complete information: exception number, device SN, exception type code, exception description, triggering rule number, involved system list, exception data snapshot, identification time, severity level, and recommended handling method. The system automatically calculates the exception confidence (based on the number of triggering rules and data integrity) to assist manual judgment of the priority.

[0119] Figure 4The document demonstrates a complete anomaly handling process, from rule matching to anomaly classification, confidence score calculation, and alert output. After data is output from the comparison rule engine, it is categorized into six major classes by the anomaly classifier, and a confidence score is calculated, ultimately outputting structured anomaly records.

[0120] Step S6: Early Warning and Report Output

[0121] The early warning and reporting output layer of this invention provides various forms of abnormal result output to support operational management decisions:

[0122] (1) Terminal anomaly list: Output detailed information of all anomaly devices by SN dimension, including anomaly type, involved system, anomaly details, and supports filtering and sorting by city, district / county, anomaly type, etc.

[0123] (2) Abnormal classification statistical report: summarizes and statistically analyzes abnormalities by abnormal type, severity level, city distribution, etc., generates trend analysis charts, and supports year-on-year and month-on-month analysis.

[0124] (3) Abnormal distribution heat map: Based on geographical regions, it displays the distribution and density of abnormal numbers in various cities, districts and counties, helping managers to quickly identify areas with high incidence of abnormalities.

[0125] (4) SN Link Reconstruction Diagram: For a specific abnormal SN, its complete lifecycle event chain and abnormal nodes are visualized, intuitively showing the links and context in which the abnormality occurred.

[0126] (5) Real-time early warning push: When a new anomaly is identified, an early warning notification is pushed to the upper-level monitoring system or the responsible person's terminal through API interface, message queue or SMS.

[0127] (6) Anomaly Handling Work Order: For anomalies with a severity level of "severe", an anomaly handling work order is automatically generated and pushed to the corresponding system maintenance personnel for verification and handling.

[0128] This invention has the following characteristics:

[0129] 1. A method for constructing a full lifecycle event chain for terminal devices across multiple heterogeneous business systems, using the device SN as a unique identifier, and connecting operation records scattered across the supply chain system, AMS system, integrated control system, BOSS system, O-domain activation system, and RMS system in chronological order to form a complete event chain data structure.

[0130] 2. A method for field standardization and unified mapping of heterogeneous data from multiple systems, including a complete processing flow of field name mapping, data type conversion, unified encoding of enumeration values, and time format standardization.

[0131] 3. A timing constraint verification mechanism based on SN event chain, which defines the temporal order constraint relationship between events in the life cycle of terminal device, and detects timing violation anomalies by traversing the event chain.

[0132] 4. A hierarchical cross-system anomaly identification rule system, comprising three levels: basic comparison rules, logical comparison rules, and time-series comparison rules, to achieve comprehensive anomaly identification ranging from simple data inconsistencies to complex business logic contradictions.

[0133] 5. An automatic anomaly classification and early warning method based on link analysis, which classifies the anomaly identification results in a structured manner according to multiple dimensions, and supports automatic early warning push and anomaly handling work order generation.

[0134] 6. A scalable multi-system data comparison framework that supports flexible access to new data source systems and custom comparison rules through configuration, without requiring modification of the core comparison engine.

[0135] Explanation of Terms and Abbreviations

[0136] This invention relates to specialized terms and abbreviations for multiple business systems. For ease of understanding, key terms are explained below.

[0137] Table 5. Comparison of Key Terms and Abbreviations

[0138] Terms / Abbreviations Full name Meaning Explanation SN Serial Number The device serial number is a unique physical identifier for a terminal device. It is usually written into the device hardware by the manufacturer during the production stage and cannot be changed. AMS Asset Management System The terminal asset management system is responsible for the full lifecycle management of terminal equipment from its entry into the warehouse to its disposal. BOSS Business & Operation Support System The business operations support system is responsible for managing core business processes such as user service acceptance, billing, and accounting. RMS Resource Management System The resource management system is responsible for the unified management and allocation of network resources (ports, optical paths, IP addresses, etc.). O domain Operation Domain The operations and maintenance domain refers to a collection of systems for the operation and maintenance management of network devices. In this article, it specifically refers to the online activation and authentication management system for terminal devices. Comprehensive investigation Integrated Dispatch System The construction scheduling and management system is responsible for the dispatching, tracking, and management of on-site construction work orders such as machine installation and dismantling. Event Chain Event Chain The core data structure defined in this invention is a directed time sequence formed by arranging the operation records of the device in each system according to time, using SN as the identifier. Comparison rules Comparison Rule Predefined data validation logic is used to detect inconsistencies or logical contradictions in data across multiple systems. Timing constraints Temporal Constraint Logical constraints imposed on the chronological order of events in an event chain.

[0139] Typical application scenarios description

[0140] The following describes the actual operation of the method of the present invention through specific application scenarios to help understand the implementation effect of the technical solution.

[0141] Scenario 1: Automatic identification of incorrect serial numbers during system installation.

[0142] A user applies for broadband service. The BOSS system generates a service order and associates it with device SN "A001". The integrated dispatch system dispatches an installation work order. The construction personnel actually install a device with SN "A002" on-site (human error caused the serial number registration error), but still enter SN "A001" in the integrated dispatch system. At this time, the AMS system, receiving the integrated dispatch receipt, marks SN "A001" as "installed". This invention, through the logical comparison rule R2-01 in step S4, compares the work order device record in the integrated dispatch system with the actual activated device in the O-domain activation system. It finds that the actual activated device in the O-domain system is SN "A002" instead of "A001", thus triggering a "work order device inconsistency" exception (EX-02). The system automatically generates an abnormal work order to notify the maintenance personnel to verify and correct it.

[0143] Scenario 2: Discovery of anomalies in equipment that was not disassembled during recycling.

[0144] A batch of equipment was marked as "returned to inventory" in the AMS system, but no corresponding dismantling work order record existed in the integrated dispatch system. After constructing the event chain for this batch of equipment in step S3, this invention found that while a "recovery" event existed, a "dismantling" event was missing. Simultaneously, through the logical comparison rule R2-03 in step S4, a contradiction was detected between the AMS "recovered" and the integrated dispatch system's "no dismantling record," triggering a "recovered but not dismantled" anomaly (EX-06). Further inspection through the time-series comparison rule R3-05 revealed that the user service status associated with these devices in the BOSS system was still "online," further triggering a "status conflict" anomaly (EX-01). This scenario reveals potential batch misoperation or system data synchronization failures, which this invention can automatically detect and issue warnings within an hour.

[0145] Scenario 3: Detection of abnormal device activation timing.

[0146] The initial activation time of a certain device SN "B003" in the O-domain activation system was March 1, 2024. However, the installation operation time recorded for this device in the AMS system was March 5, 2024, and the completion time of the installation work order in the integrated commissioning system was March 4, 2024. After constructing the event chain for this device in step S3, this invention executes the timing comparison rule R3-03 in step S4 and detects that "activation time (March 1) < installation time (March 5)," violating the timing constraint that "the device must be installed before activation," triggering an "activation-installation timing anomaly" (EX-04). This anomaly suggests that there may be problems such as delayed installation time recording or the device being activated before formal installation.

[0147] Cross-system state compatibility matrix

[0148] This invention uses a "state compatibility matrix" in the basic alignment rules to determine whether there are state conflicts between multiple systems. The following is an example of the state compatibility matrix between the AMS system and the BOSS system ("Y" indicates compatibility and "N" indicates conflict). This matrix is ​​the core criterion of the basic alignment rule R1-02.

[0149] Table 6 AMS-BOSS Cross-System State Compatibility Matrix

[0150] AMS Status\ BOSS Status On the Internet shutdown Disassembly Pre-activation In stock N N Y Y Out of stock N N Y Y Already installed Y Y N Y Recycled N N Y N Scrapped N N Y N Under repair N N Y N

[0151] When a device's status in the AMS system is "reclaimed" while the associated user's status in the BOSS system is "online," the matrix query result will be "N" (incompatible), triggering a status conflict anomaly in basic comparison rule R1-02. This matrix can be configured and adjusted according to the operator's actual business rules and supports dynamic updates.

[0152] Data Acquisition Interface Description

[0153] This invention supports multiple data acquisition interface methods to adapt to different system architectures. The main interface methods are as follows:

[0154] (1) Direct database connection method: Data extraction is performed by directly connecting to the databases of various systems through standard database interfaces such as JDBC / ODBC. This method is suitable for scenarios where external systems are allowed to directly access the database. It supports two modes: incremental collection (based on timestamp fields or database change logs) and full collection.

[0155] (2) API interface calling method: Data is obtained through the RESTful API or WebService interface provided by each system, which is suitable for scenarios where systems exchange data through standard interfaces. It supports two interaction modes: synchronous calling and asynchronous callback.

[0156] (3) Message queue subscription method: Real-time data is obtained by subscribing to business event messages published to message queues (such as Kafka, RabbitMQ, etc.) by various systems. It is suitable for scenarios with message middleware infrastructure and can realize near real-time data collection.

[0157] (4) Batch file import method: Data files (CSV, Excel, XML, etc.) exported periodically by various systems are obtained through FTP / SFTP, which is suitable for legacy systems that cannot provide online interfaces. File format and field mapping are defined through configuration files.

[0158] Expected performance and scale reference indicators

[0159] In a typical provincial telecom operator application scenario, the method of this invention is expected to support the following scale and performance indicators (the following data are based on theoretical analysis of the technical solution; actual performance depends on hardware configuration and data scale):

[0160] (1) Data scale support: The scale of terminal asset management in a single province can reach 20 million to 50 million devices, with approximately 100,000 to 500,000 new operation event records added daily, and the amount of historical event chain data is approximately several billion records.

[0161] (2) Comparison processing capability: The full comparison processing of daily incremental data should be completed within 4 hours, and the daily batch comparison mode is supported; in the real-time collection mode based on message queue, the end-to-end latency from collection to anomaly identification of a single event should be controlled within minutes.

[0162] (3) Rule expansion capability: The comparison rule base supports maintaining hundreds of comparison rules at the same time. New rules take effect through configuration without restarting the system or modifying the code.

[0163] (4) Anomaly handling capability: It is expected that the discovery cycle of terminal asset data anomalies can be shortened from the monthly or quarterly level of the traditional solution to the daily or hourly level, and the anomaly identification coverage (relative to the known anomaly types that can be discovered by manual investigation) is expected to reach more than 95%.

[0164] Implementation Recommendations

[0165] The method of this invention is recommended to be implemented in stages according to the following steps: First, complete the construction of data acquisition channels for each system and the configuration of standardized data mapping, and verify the effectiveness of the basic comparison rules through offline batch comparison; Second, launch logical comparison rules and time-series comparison rules, gradually build a complete event chain, and optimize the accuracy of anomaly classification; Third, connect to real-time data acquisition channels and early warning push mechanisms to achieve near real-time anomaly identification and automatic early warning capabilities. Each stage should continuously optimize the comparison rules and anomaly classification thresholds according to the actual business scenario.

[0166] Contents not described in detail in this specification are existing technologies known to those skilled in the art. It is hereby indicated that the above description is intended to help those skilled in the art understand the present invention, but does not limit the scope of protection of the present invention. Any equivalent substitutions, modifications, improvements, and / or simplifications of the above descriptions that do not depart from the essence of the present invention fall within the scope of protection of the present invention.

Claims

1. A method for identifying anomalies in terminal assets based on multi-system comparison, characterized in that, Includes the following steps: Step 1: Multi-system data collection, collecting terminal asset data from multiple data source systems; Step 2: Standardize and map the terminal asset data. Step 3: Construct a complete lifecycle event chain for each terminal device serial number (SN); Step 4: Establish a unified comparison rule base for multi-level anomaly identification; Step 5: Using a unified comparison rule base, execute multi-level comparison rules through the anomaly identification and multi-dimensional classification modules to form structured anomaly identification results; Step 6: The early warning and reporting output layer outputs the anomaly identification results and early warning information.

2. The terminal asset anomaly identification method based on multi-system comparison according to claim 1, characterized in that, In step 1, multiple data source systems include the supply chain system, AMS system, BOSS system, integrated dispatch system, O-domain activation system, and RMS system. The terminal asset data is associated with the device serial number (SN) as a unified primary key. Metadata information recorded during the collection process includes the collection timestamp, data source identifier, and data version number, which are used for subsequent data traceability and consistency verification. For data that fails to be collected, the system automatically records the reason for the failure and triggers a retry mechanism to ensure the integrity of the data collection.

3. The terminal asset anomaly identification method based on multi-system comparison according to claim 1, characterized in that, Step 2 includes a standardization process that converts heterogeneous data from various systems into a unified standard data format. The standardization process includes four steps: field name mapping, data type conversion, enumeration value unification, and time format standardization.

4. The terminal asset anomaly identification method based on multi-system comparison according to claim 1, characterized in that, Step 3 includes event type definition, event chain construction algorithm, and event chain integrity analysis; the SN event chain structure in the event chain construction algorithm includes event nodes with sequence numbers from E01 to E11: E01, purchase receipt; E02, warehouse departure; E03, transfer; E04, installation; E05, service activation; E06, equipment activation; E08, service change; E09, dismantling and recycling; E10, repair and maintenance; E11, scrapping.

5. The terminal asset anomaly identification method based on multi-system comparison according to claim 1, characterized in that, Step 4 includes a hierarchical unified comparison rule base, where basic comparison rules are defined as one-star R1 class, logical comparison rules as two-star R2 class, and time-series comparison rules as three-star R3 class. R1 class involves cross-system state consistency verification, R2 class involves business relationship verification, and R3 class involves event chain time sequence constraints. R1 class includes R1-01 (device type must be consistent), R1-02 (core state compatibility), R1-03 (installed equipment traceability), and R1-04 (in...). Network device status binding; R2 category includes R2-01 work order device consistency, R2-02 installation-activation correlation, R2-03 recycling-dismantling correlation, R2-04 one machine for multiple users detection, R2-05 inventory flow consistency; R3 category includes R3-01 purchase and outbound sequence, R3-02 outbound installation sequence, R3-03 installation and activation sequence, R3-04 installation and activation sequence, R3-05 shutdown and dismantling sequence, R3-06 dismantling and repair sequence, R3-07 geographical and time consistency.

6. The terminal asset anomaly identification method based on multi-system comparison according to claim 1, characterized in that, Step 5 involves inputting the SN event chain data into the first-layer basic comparison rule, the second-layer logical comparison rule, and the third-layer temporal comparison rule, respectively, and then starting the rule execution engine. The engine performs conflict resolution and result aggregation according to the priority order R3 > R2 > R1, resulting in the following anomaly classification outputs: EX-01 status conflict, EX-02 work order anomaly, EX-03 serial number conflict, EX-04 temporal anomaly, EX-05 data missing, and EX-06 correlation contradiction.

7. The terminal asset anomaly identification method based on multi-system comparison according to claim 1, characterized in that, The anomaly record in step 5 includes the anomaly identification result, including the number, serial number, type, triggering rule, system involved, data snapshot, severity level, anomaly confidence level, and suggested handling method.

8. The terminal asset anomaly identification method based on multi-system comparison according to claim 1, characterized in that, The abnormal results output in step 6 include: a terminal abnormality list, an abnormality classification statistical report, an abnormality distribution heat map, an SN link restoration diagram, real-time early warning push, and an abnormality handling work order.

Images