Railway master data verification method, system and device based on multi-rule engine and storage medium

Abstract

The invention belongs to the technical field of data processing, particularly relates to a railway main data verification method, system and equipment based on a multi-rule engine and a storage medium, and aims to solve the problems that rule verification in a railway data base is solidified, the expansibility is poor, and the railway data base cannot adapt to complex business scenes in the prior art. The method comprises the steps that a rule base containing multiple rules is configured, input of data to be verified is received, and verification is executed by a verification engine based on preset groups and priorities. When rule conflicts occur, a multi-strategy conflict resolution mechanism is used for processing, and finally a verification report is generated and displayed. According to the method and the system, configurable management and flexible scheduling of the verification rules are realized, the defects of rule solidification, poor expansibility and the like in a traditional hard coding mode are effectively overcome, and the adaptability and the accuracy of data verification in a complex railway service scene are remarkably improved.

Description

A method, system, equipment, and storage medium for railway master data verification based on a multi-rule engine. Technical Field

[0001] This invention belongs to the field of data processing technology, and specifically relates to a railway master data verification method, system, device and storage medium based on a multi-rule engine. Background Technology

[0002] With the deepening of digital transformation in the railway industry, the data infrastructure, as a core infrastructure supporting intelligent railway operation, is becoming increasingly important. The data infrastructure provides standardized, high-quality data services for upper-level business applications through the unified collection, integration, and management of multi-source heterogeneous data. In the railway sector, the data infrastructure needs to manage various master data, including those related to lines, equipment, vehicles, and personnel. The quality of this data directly affects traffic safety, operational efficiency, and decision-making accuracy.

[0003] However, existing data infrastructures face significant challenges in master data quality management. First, railway master data is characterized by complex business rules, diverse value constraints, and tight relationships. Traditional data validation methods typically employ hard-coding, embedding validation rules within the application. This approach results in insufficient flexibility and scalability; changes in business rules necessitate modifications to the underlying code, impacting the stability and maintainability of the data infrastructure. Second, existing data infrastructures lack a unified rule management mechanism. Data from different sources (such as manual entry, system interfaces, and batch imports) often employs different validation standards, making it difficult to guarantee data quality consistency across the infrastructure. Furthermore, the data infrastructure needs to support various scenarios, including real-time and batch data processing, where traditional validation methods suffer from significant bottlenecks in performance efficiency and resource scheduling.

[0004] In the architecture design of a data infrastructure, master data verification is a crucial step in data quality control, and the quality of its technical solution directly affects the reliability and usability of the data infrastructure. In existing technologies, some data infrastructures employ verification schemes based on a single rule engine. While these schemes achieve data quality control to a certain extent, they are still insufficient when facing the complex business rules of the railway industry. For example, the lack of an intelligent mechanism for resolving rule conflicts leads to inconsistent verification results; the lack of a visual rule configuration interface increases the management complexity of the data infrastructure; and the failure to fully utilize multi-core computing resources affects the processing performance of the data infrastructure.

[0005] In particular, the following technical challenges exist in the practical application of railway data infrastructure: First, it is necessary to support the dynamic configuration and management of various verification rules to meet the data quality requirements of different business scenarios; second, it is necessary to establish an efficient rule execution strategy to ensure the performance of the data infrastructure when processing massive amounts of data; and third, it is necessary to provide comprehensive verification result tracking and auditing functions to ensure the data credibility of the data infrastructure.

[0006] Therefore, there is an urgent need for a master data verification method specifically designed for the characteristics of railway data infrastructure. Through technological innovations such as multi-rule engine collaboration, intelligent conflict resolution, and visualized rule configuration, the data quality management level of the data infrastructure can be improved, providing a solid data foundation for the digital transformation of the railway industry. Summary of the Invention

[0007] To address the aforementioned problems in existing technologies, namely the fixed rule verification, poor scalability, and inability to adapt to complex business scenarios in existing railway data bases, this invention provides a railway master data verification method, system, device, and storage medium based on a multi-rule engine.

[0008] In a first aspect, the present invention proposes a railway master data verification method based on a multi-rule engine, the method comprising:

[0009] The system configures a rule base to store various validation rules, including at least syntax validation rules, uniqueness validation rules, value range validation rules, and required field validation rules. Each rule defines its validation logic, parameters, and metadata. It receives input data to be validated, triggered by manual entry, interface synchronization, or batch import, and contains multiple fields to be validated. In response to the input data, the system uses a validation engine to perform validation based on the rule base. This validation includes applying the various validation rules to the fields of the data to be validated and performing the validation serially or in parallel according to preset rule grouping and priority order. During validation, when multiple validation rules conflict, a conflict resolution mechanism is applied to resolve the conflict. This conflict resolution mechanism is built based on a priority strategy, business importance strategy, or user configuration strategy. Finally, a validation report is generated, indicating the validation results, including displaying the validation status and error information on the front-end interface.

[0010] Furthermore, the configuration rule base includes: defining syntax validation rules to ensure that the data format of the validated fields conforms to predefined specifications, including length, character type, and regular expression patterns; defining uniqueness validation rules to ensure that a specific field or combination of fields is unique throughout the entire system; defining value range validation rules to ensure that the value of a field is within a predefined set of valid values, which includes a static list of valid values ​​or a dynamic database reference value; and defining mandatory field validation rules to ensure that specific key fields provide non-empty values ​​when data is created or updated. The rule base supports the management of the activation status of the validation rules.

[0011] Furthermore, receiving the input data to be verified includes: triggering verification through manual entry, where the user completes the record entry on the data management page and clicks the save or submit button; triggering verification through interface synchronization, where the business system pushes data through an application programming interface, and the data format includes JSON or XML; triggering verification through batch import, where the user imports data through a file template, and the file format includes spreadsheets; in response to the triggering, automatically parsing the input data to be verified and extracting the fields to be verified to initialize the verification process.

[0012] Furthermore, the execution verification includes: applying syntax verification rules to match whether the field value conforms to a predefined format specification using regular expressions; applying uniqueness verification rules to check whether the field value or field combination already exists by querying the associated master data table; applying value range verification rules to check whether the field value belongs to a predefined legal set by parsing a static list of legal values ​​or performing a dynamic database query; applying mandatory field verification rules to check whether the field value is empty; and interrupting the data entry process and returning an error message when any verification rule fails.

[0013] Furthermore, the execution of the verification includes: executing different types of verification rules sequentially according to a preset priority order, wherein the priority order is: required field verification takes precedence over syntax verification, syntax verification takes precedence over value range verification, and value range verification takes precedence over uniqueness verification; for multiple verification rules of the same type, they are executed in parallel, wherein the parallel execution uses thread pool technology to allocate an independent thread for each rule; for verification rules of different fields, the verification is executed in parallel; for verification rules with dependencies, they are executed sequentially to ensure that subsequent verifications are executed only after the preconditions are determined.

[0014] Furthermore, the application conflict resolution mechanism includes: identifying the type of validation rule conflict, including rule priority conflict, condition mutual exclusion conflict, or execution order conflict; resolving conflicts based on a priority strategy, wherein the result of a high-priority rule determines the final state and is processed according to the preset priority order; resolving conflicts based on a business importance strategy, wherein validation rules for core business fields have higher weight, and the priority order of business importance is: uniqueness validation takes precedence over value range validation, value range validation takes precedence over syntax validation, and syntax validation takes precedence over mandatory field validation; and resolving conflicts based on a user configuration strategy, wherein administrators are allowed to set rules to force pass flags or warning levels to adjust the rule execution results during rule configuration.

[0015] Furthermore, the generation of the verification report includes: highlighting error information on the front-end interface by using a status banner or visual marking of error fields, and providing a button to view a detailed report to display complete verification details; storing the verification report for at least a predetermined time and associating it with the operation log to record the user, time, and data model metadata that triggered the verification; and supporting the querying of historical verification reports by data model, time range, and verification status conditions.

[0016] A second aspect of the present invention proposes a railway master data verification system based on a multi-rule engine, and a railway master data verification method based on a multi-rule engine. The system includes: a rule configuration module configured to store multiple verification rules, wherein the verification rules include at least syntax verification rules, uniqueness verification rules, value range verification rules, and required field verification rules, each rule defining its verification logic, parameters, and metadata; a data receiving module configured to receive input data to be verified, wherein the input data to be verified is triggered by any one of manual entry, interface synchronization, or batch import, and contains multiple fields to be verified; and a verification engine module configured to... In response to the input data to be verified, the system uses a verification engine to perform verification based on the rule base. This verification includes applying the various verification rules to the fields of the data to be verified and performing the verification serially or in parallel according to preset rule grouping and priority order. During the verification process, when multiple verification rules conflict, a conflict resolution mechanism is applied to resolve the conflict. This conflict resolution mechanism is built based on a priority strategy, a business importance strategy, or a user configuration strategy. A report generation module is configured to generate a verification report, which indicates the verification results, including displaying the verification status and error information on the front-end interface.

[0017] In a third aspect, the present invention provides an electronic device comprising: at least one processor; and a memory communicatively connected to at least one of the processors; wherein the memory stores instructions executable by the processor for implementing a railway master data verification method based on a multi-rule engine.

[0018] In a fourth aspect, the present invention provides a computer-readable storage medium storing computer instructions for execution by a computer to implement a railway master data verification method based on a multi-rule engine.

[0019] The beneficial effects of this invention are as follows: The implementation of this invention significantly improves the technical effectiveness of railway data infrastructure in master data quality management. By constructing a rule base that supports multiple types of verification rules and employing a dynamically configurable verification engine, the system effectively overcomes the flexibility issues inherent in traditional hard-coded verification methods. When business rules change, administrators can update and maintain verification rules through the rule base without modifying the system source code, greatly enhancing the adaptability and scalability of the data infrastructure.

[0020] By employing a priority-based grouping execution strategy combined with a hybrid serial and parallel processing mode, the system achieves a significant improvement in verification efficiency. Through grouping and prioritizing different types of rules, as well as parallel processing of independent rules and fields, the system can fully utilize computing resources, effectively addressing the real-time processing needs of massive amounts of data in the railway data infrastructure while ensuring verification accuracy. This intelligent scheduling mechanism is particularly suitable for scenarios involving batch data import and high-concurrency interface access in the data infrastructure.

[0021] The introduced multi-dimensional conflict resolution mechanism ensures the consistency of verification results in complex business scenarios. The system effectively resolves potential conflicts between multiple verification rules through three levels: priority strategy, business importance assessment, and user configuration. This feature is particularly important in the complex business rule environment of railway data infrastructure, preventing data processing inconsistencies caused by rule conflicts and ensuring data quality reliability.

[0022] The system's comprehensive verification report generation and storage capabilities provide strong support for data quality traceability and auditing within the data infrastructure. Through association with operation logs and diverse query capabilities, administrators can quickly pinpoint the root causes of data quality issues, analyze the effectiveness of verification rules, and provide a basis for continuously optimizing the governance level of the data infrastructure. This visualized quality control approach significantly improves the maintainability and transparency of the data infrastructure.

[0023] In summary, this invention constructs a complete master data verification solution through comprehensive innovation in rule base design, execution strategy optimization, conflict resolution, and reporting mechanisms. This solution not only meets the stringent data quality requirements of the railway data infrastructure but also provides a solid technical foundation for the long-term evolution and development of the data infrastructure through its configurable and scalable architecture, thereby ensuring the accuracy, integrity, and consistency of master data within the railway data infrastructure from the source. Attached Figure Description

[0024] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 is a flowchart illustrating a railway master data verification method based on a multi-rule engine according to the present invention; Figure 2 is a schematic diagram illustrating the specific architecture of a railway master data verification system based on a multi-rule engine according to the present invention. Detailed Implementation

[0025] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0026] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0027] The first embodiment of the present invention proposes a railway master data verification method based on a multi-rule engine. The method includes: step S10, configuring a rule base, which stores various verification rules, including at least syntax verification rules, uniqueness verification rules, value range verification rules, and required field verification rules, each rule defining its verification logic, parameters, and metadata; step S20, receiving input data to be verified, wherein the input data is triggered by any one of manual entry, interface synchronization, or batch import, and contains multiple fields to be verified; step S30, responding to the input data to be verified, using the verification engine to perform verification based on the rule base, wherein the verification execution includes applying the various verification rules to the fields of the data to be verified, and performing the verification in a serial or parallel manner according to a preset rule grouping and priority order; step S40, during the verification process, when multiple verification rules conflict, applying a conflict resolution mechanism to resolve the conflict, wherein the conflict resolution mechanism is constructed based on a priority strategy, a business importance strategy, or a user configuration strategy; and step S50, generating a verification report, wherein the verification report indicates the verification results, including displaying the verification status and error information on the front-end interface.

[0028] In a specific implementation scenario, this approach constructs a decoupled system architecture, the core of which is the validation engine and the rule base. The rule base, as an independent knowledge base, centrally stores all data quality rules, while the validation engine, as an independent service component, is responsible for reading and executing these rules.

[0029] First, the data administrator initializes the rule base through a visual configuration interface, setting four basic validation rules for different data models in the railway master data, such as lines, equipment, and vehicles. When new master data needs to be entered, whether it's manually filled out by an operator on the front-end page, data pushed by an external business system via an application programming interface, or batch import of files, the validation process is triggered. Once activated, the validation engine retrieves all relevant, active rules from the rule base based on the type of input data.

[0030] Subsequently, the engine intelligently arranges the execution order of these rules according to a preset execution strategy. Some rules can be processed in parallel to improve efficiency, while other rules with dependencies are executed sequentially to ensure logical correctness. If contradictory verification results are found between different rules during execution, the system will activate a conflict resolution mechanism to make a final decision based on preset priority or business importance principles. After the entire verification process is completed, the system will immediately generate a detailed verification report. This report will not only be visually displayed to the user through highlighting and red highlighting on the user interface, but will also be persistently stored for subsequent auditing and analysis.

[0031] For example, when a railway dispatcher enters a new train operation plan, they need to fill in fields such as train number, originating station, destination station, and planned departure time. When they click submit, the validation engine concurrently performs syntax and uniqueness checks on the train number field, value range checks on the originating and destination station fields, and syntax and mandatory field checks on the planned departure time. If the train number format is incorrect, the validation will be immediately interrupted and an error message will be returned; subsequent uniqueness checks will not be performed. In this way, this method achieves comprehensive, efficient, and flexible data quality control of railway master data from the source.

[0032] To more clearly illustrate the railway master data verification method based on a multi-rule engine of the present invention, the following detailed description of each step in the embodiment of the present invention is provided with reference to Figure 1. Each step is described in detail as follows: Step S10: Configure a rule base. The rule base is used to store various verification rules, including at least syntax verification rules, uniqueness verification rules, value range verification rules, and mandatory field verification rules. Each rule defines its verification logic, parameters, and metadata. The configuration of the rule base includes: defining syntax verification rules to ensure that the data format of the verified field conforms to predefined specifications, including length, character type, and regular expression pattern; defining uniqueness verification rules to ensure that a specific field or combination of fields is unique throughout the entire system; defining value range verification rules to ensure that the value of a field is within a predefined legal set, which includes a static list of legal values ​​or a dynamic database reference value; and defining mandatory field verification rules to ensure that a specific key field provides a non-null value when data is created or updated. The rule base supports the management of the activation status of the verification rules.

[0033] In a specific implementation scenario, the configuration of the rule base is a structured process. For defining syntax validation rules, the system provides a configuration interface where administrators can select the target data model and fields, and then input specific formatting specifications. For example, for railway freight car numbers, an administrator can define a regular expression pattern requiring them to begin with a specific letter followed by a fixed number of digits. For uniqueness validation rules, the administrator needs to specify the data table to be applied to and one or more field columns that need to be unique. For example, the locomotive number field in the locomotive information table can be set to unique. For value range validation rules, the system supports two configuration methods. The first is a static value range, where the administrator can directly input a list of valid values ​​separated by a specific delimiter. For example, the valid values ​​for the line grade field can only be National Railway Class I, National Railway Class II, and Local Railway Class I.

[0034] The second type is dynamic value domain, also known as foreign key or reference validation. Administrators need to specify an external data table and field. During validation, the system queries this external table to confirm the validity of the input value. For example, when entering employee information, the value of the department field must exist in the department information master data table. For mandatory field validation rules, the configuration process is the simplest; administrators only need to check the mandatory attribute for a key field. Crucially, each configured rule has an activation switch, allowing administrators to enable or disable rules at any time based on changes in business needs without deleting them from the rule base. This greatly facilitates rule lifecycle management. This rule base design, which separates validation logic from business code, makes data quality control highly flexible and configurable. Even business personnel without technical backgrounds can participate in maintaining data rules, significantly improving system maintainability and responsiveness to business changes.

[0035] For example, a unit needs to create a master data record for a newly added Harmony HXD3D electric locomotive with the serial number HXD3D0123. The data administrator configures a series of rules for the locomotive's master data model through a visual configuration interface.

[0036] First, three rules were configured for the locomotive number field: the first rule is a mandatory field, which is set by checking the mandatory field and configuring the error message that the locomotive number cannot be empty.

[0037] The second rule is the syntax rule. The administrator defines the format through the interface options. It must start with the fixed text "HXD3D", followed by exactly 4 digits. No other extra characters are allowed before or after the entire number. The error message is configured as "Locomotive number format is incorrect. It must start with HXD3D and be followed by four digits".

[0038] The third rule is uniqueness. By checking the uniqueness constraint and specifying that it applies to the locomotive master data table, the error message is set to "the locomotive number already exists." Next, configure a static value range rule for the locomotive model field. Enter HXD3D, HXD1C, SS9, DF4D in the valid value list text box, separated by commas. The error message is "invalid locomotive model."

[0039] Configure a dynamic value range rule for the locomotive depot assigned field, select the association verification type, and specify that its value must exist in the locomotive depot code column of the locomotive depot master data table. The error message should be "The entered locomotive depot code does not exist." Finally, configure another static value range rule for the locomotive status field, with the list of valid values ​​being "In Use," "Under Maintenance," "Pending Repair," and "Scrapped." After completing these configurations and setting all rules to active status, these rule definitions are stored as metadata in the rule base. Subsequently, when any user enters or modifies locomotive data, if they attempt to leave the locomotive number blank, enter HXD3D123, enter an existing number such as HXD3D0001, or enter the locomotive model SS8 which does not exist in the system, the system will immediately intercept and provide precise error feedback based on these preset rules, thereby ensuring the accuracy, completeness, and consistency of the locomotive master data from the source.

[0040] Step S20: Receive the input data to be verified, wherein the input data is triggered by any one of manual entry, interface synchronization, or batch import, and contains multiple fields to be verified; receiving the input data to be verified includes: triggering verification through manual entry, where the user completes the record entry on the data management page and clicks the save or submit button; triggering verification through interface synchronization, where the business system pushes data through an application programming interface, and the data format includes JSON or XML; triggering verification through batch import, where the user imports data through a file template, and the file format includes spreadsheets; in response to the trigger, automatically parse the input data to be verified and extract the fields to be verified to initialize the verification process.

[0041] In a specific implementation scenario, this method ensures that a unified validation standard is applied at all data entry points into the platform. For manual data entry, when a user completes a master data record on a web form, such as a new overhead contact line device, and clicks the save button, the front-end application immediately sends the form data to the back-end. Before writing the data to the database, the back-end service first calls the validation engine to perform synchronous validation on this data. For API synchronization, for example, if an external maintenance system needs to synchronize the flaw detection results of a section of rail to the master data platform, it will push the data in JSON or XML format through a predefined API interface.

[0042] Upon receiving this data packet, the master data platform immediately triggers the verification engine in its data receiving logic to verify the data within the packet. For batch import methods, data administrators may need to import thousands of new vehicle information entries at once. They will first download an Excel template, fill in the data according to the template format, and then upload it. After receiving this spreadsheet file, the system backend will first parse the file content, converting each row of data into a record to be processed, and then sending these records one by one or in batches to the verification engine for verification.

[0043] Under any triggering method, the system first identifies the data model to which the data to be verified belongs, and then automatically extracts the fields to be verified and their corresponding values ​​from the input data structure, thereby initiating the subsequent verification process. By covering these three mainstream data input channels, this method constructs a comprehensive data quality firewall, ensuring that the consistency and accuracy of data are effectively guaranteed regardless of its source, and avoiding data quality problems caused by inconsistent verification standards.

[0044] Step S30: In response to the input data to be verified, the verification engine performs verification based on the rule base. The verification execution includes applying the various verification rules to the fields of the data to be verified, and performing the verification in a serial or parallel manner according to a preset rule grouping and priority order. The verification execution includes: serially executing different types of verification rules according to a preset priority order, where the priority order is: required field verification takes precedence over syntax verification, syntax verification takes precedence over value range verification, and value range verification takes precedence over uniqueness verification; for multiple verification rules of the same type, they are executed in parallel, using thread pool technology to allocate an independent thread for each rule; verification rules for different fields are executed in parallel; and verification rules with dependencies are executed serially to ensure that subsequent verifications are performed only after the preconditions are checked.

[0045] In a specific implementation scenario, the validation engine employs a hybrid execution strategy to balance the logical rigor of validation with processing performance. First, the system establishes a fixed sequential execution priority among different types of rules. This order is carefully designed: required field validations are executed first, because if a required field is empty, performing any other validations on it becomes meaningless.

[0046] Next comes syntax validation to ensure the field values ​​are formatted correctly, avoiding subsequent logical checks on incorrectly formatted data. Then comes value range validation, which is usually faster than database queries. Finally, uniqueness validation is performed, as it typically requires database access and is the most resource-intensive operation; therefore, it's placed last to ensure it only executes if all previous validations have passed.

[0047] However, within the same priority level, the system will utilize parallel computing to accelerate processing as much as possible. For example, when performing syntax validation on a record containing ten fields, if the validation rules for these ten fields are independent, the validation engine will obtain ten threads from a pre-configured thread pool and assign the syntax validation task for each field to an independent thread for parallel execution. Similarly, if multiple independent rules are configured on a field, such as both length and character type validation, these rules can also be executed in parallel. However, when there are dependencies between rules, the system will force serial execution. A typical example is cascading validation, such as the value of the "Country" field determining the valid value range of the "Province" field. In this case, the system must first complete the validation of the "Country" field, dynamically determine the validation rules for the "Province" field based on the result, and then execute the validation of the "Province" field. This intelligent execution strategy combining serial and parallel processing ensures the correct handling of the order of validation logic and dependencies, while fully utilizing the computing power of modern multi-core processors, significantly improving the overall validation performance of the system when processing complex data records or importing large amounts of data.

[0048] The invention will be explained in more detail below with specific examples: Assume an asset record to be added to the inventory contains the following data: "Asset Number" is CNC-2024-03-A01, "Asset Type" is a five-axis machining center, "Workshop" is W05, "Installation Country" is Country A, "City" is City B, and "Rated Power" is 150kW. The system's validation rules for these fields include: all fields are required; the asset number must conform to a specific format and be unique in the system; the rated power must be a valid numerical format; the values ​​of asset type and workshop must exist in their respective associated master data tables; in addition, the validation logic for the city depends on the value of the installation country field, and its list of valid values ​​is dynamically determined by the installation country.

[0049] Once the record is submitted, the validation engine initiates its execution process. First, the engine processes the highest priority required field validations, checking all fields for emptiness simultaneously in parallel. Since all fields have values, this stage is completed quickly. Next, the process moves to the syntax validation level, where the engine again allocates parallel tasks to validate the format of the asset number and the numerical format of the rated power, respectively. Because these validations are independent of each other, parallel execution reduces the total time required for this stage.

[0050] Subsequently, the system enters the value range verification phase. The engine recognizes that the verification of asset type, workshop, and installation country are independent, so these three tasks are executed concurrently, which may involve queries or list matching of different data tables. Simultaneously, the engine detects that the verification of the current city depends on the verification result of the installation country, so the verification task for the current city is placed in a pending state. Only when the verification of the installation country is successfully completed and its value is confirmed as valid country A will the system trigger the verification of the current city, using the list of cities associated with country A to verify the validity of city B.

[0051] Finally, after all preceding verification steps have passed, the engine performs the most resource-intensive uniqueness check. This involves initiating a database query on the asset number field to confirm its uniqueness. Placing this costly operation at the end of the process ensures that the system only performs database interactions on compliant data that has passed all format and logical checks, effectively avoiding the consumption of valuable database resources on obviously erroneous data. Through this strategy combining priority serial processing, intra-layer parallel processing, and dependency handling, the system optimizes resource utilization during the verification process while ensuring data entry accuracy and logical compliance, providing support for system response performance and stability in high-concurrency scenarios.

[0052] More specifically, the parallel execution of multiple verification rules of the same type further includes: before initiating parallel verification, the verification engine performs task modeling on the field to be verified and its associated verification rules, constructing a directed acyclic graph (DAG) to represent the dependencies between tasks; the verification engine calls the task scheduler to perform hierarchical topological sorting on the DAG, identifies the task layer with no current dependencies, and submits all tasks in the task layer with no current dependencies to a dynamic thread pool for execution, the size of which is adjusted in real time according to the system's running status during parallel verification; during task execution, the task scheduler uses a work-stealing mechanism to achieve load balancing, stealing tasks from other task queues when the thread task queue in the dynamic thread pool is empty; for task layers with dependencies, the task scheduler triggers the execution of the next layer of tasks only after all tasks in the previous layer are completed, ensuring that the dependencies are not broken.

[0053] The load balancing mechanism achieved by employing a work-stealing approach includes: when the task queue of the first thread in the dynamic thread pool is empty, the first thread preferentially steals tasks from other verification task queues in the same field; if other verification task queues in the same field are empty, tasks are stolen from the tail of the task queues in other fields; the size of the dynamic thread pool is jointly determined by the current system load, the amount of data to be verified, the number of available processor cores, and the sliding window estimate of the average execution time of tasks; the verification engine maintains the execution status and exception handling mechanism for each task during parallel execution; when a task fails verification, it supports two processing modes: fast failure mode and aggregated failure mode; in the fast failure mode, the verification engine immediately interrupts all unexecuted or currently executing tasks at the same or lower level and returns the first failure result; in the aggregated failure mode, the verification engine continues to execute all independent tasks, and after all tasks at the current level are completed, it summarizes all failure information and returns it uniformly.

[0054] In a preferred embodiment, when multiple validation rules of the same type need to be executed in parallel, the validation engine does not simply submit all rules directly to the thread pool at once. Instead, it first performs task modeling on the field to be validated and the validation rules associated with that field. Task modeling here refers to abstracting each independently executable validation action into a task node, and establishing connections between nodes based on whether there are pre-existing dependencies between tasks, thereby forming a directed acyclic graph (DAG) to describe the validation execution relationships. The task node can correspond to a validation unit in single-field single-rule validation, single-field multi-rule validation, or cross-field linked validation. If the judgment of one rule depends on the output of another rule—for example, some value range validations can only be executed after format validation passes, or some joint uniqueness validations can only be initiated after all relevant fields have completed mandatory and syntax validations—then directed edges are established in the graph from the pre-existing task node to the subsequent task node to clarify the execution order. In this way, the validation engine can transform the originally scattered set of rules into a set of tasks with a clear dependency topology, providing a unified data foundation for subsequent parallel scheduling, hierarchical execution, and conflict control.

[0055] After constructing the directed acyclic graph (DAG), the verification engine further invokes the task scheduler to perform hierarchical topological sorting on the DAG. Hierarchical topological sorting refers to extracting executable task layers layer by layer according to the principle that the in-degree of nodes in the graph is zero: the first layer consists of all task nodes that do not depend on other tasks, the second layer consists of task nodes that only depend on nodes in the first layer, and so on, until all nodes in the graph are divided. Through hierarchical processing, the task scheduler can accurately identify all "independent" task layers at the current moment and submit all tasks in that layer as a group of concurrent execution units to the dynamic thread pool. "Independent" here does not mean that the tasks are completely independent, but rather that at this execution moment, these tasks can run without blocking each other, provided their preconditions are met, thus providing a basis for parallelization. Through parallel execution within layers and serial execution between layers, the system ensures the logical correctness between rules while maximizing verification throughput.

[0056] In one specific implementation, the dynamic thread pool is not a static thread pool of fixed size, but rather an adaptive execution resource pool that can adjust its concurrency scale in real time according to the system's operating status. The dynamic adjustment of the thread pool size takes into account at least the current system load, the amount of data to be verified, the number of available processor cores, and a sliding window estimate of the average task execution time. The current system load can include metrics such as CPU utilization, memory usage, I / O wait time, and database connection pool usage; the amount of data to be verified can be represented by the product of the current batch of input records, the current number of fields, and the current total number of rules; the number of available processor cores is used to constrain the maximum concurrency limit of the thread pool, preventing the number of threads from far exceeding the hardware's computing power and causing excessive context switching overhead; the sliding window estimate of the average task execution time is used to reflect the actual execution time of recent rules, in order to determine whether the current task is more suitable for higher or lower concurrency. Based on these parameters, the task scheduler can dynamically expand or shrink the thread pool using preset adjustment strategies. For example, when the system load is low, the average task time is short, and there are many tasks to be verified, the number of worker threads can be increased appropriately; when the system load increases or the database access pressure is high, the concurrency can be reduced in a timely manner, thereby balancing verification performance and system stability.

[0057] The dynamic thread pool size adjustment can be triggered periodically by the scheduler, or it can be triggered when task layer switching occurs, task queue backlog occurs, or resource monitoring anomalies occur. Specifically, the scheduler can collect system operation indicators every preset time window, calculate a recommended number of threads based on task queue depth and completion rate, and then compare it with the current thread pool size before making adjustments. When the recommended number of threads is higher than the current value and resources are sufficient, the scheduler can create new worker threads and add them to the thread pool; when the recommended number of threads is lower than the current value and some threads are idle, the scheduler can reclaim excess threads to reduce resource consumption. To prevent performance jitter caused by frequent scaling, a hysteresis interval for thread pool adjustment can be further set, that is, adjustment is only performed when the difference between the recommended number of threads and the current size reaches a set threshold. This ensures both adaptability and avoids excessive fluctuations in thread resources.

[0058] During task execution, the task scheduler employs a work-stealing mechanism to achieve load balancing, further improving resource utilization in a multi-threaded environment. The work-stealing mechanism means that when a worker thread has no tasks to execute, it does not immediately idle but actively retrieves unexecuted tasks from the task queues of other worker threads to continue working, thereby reducing thread idle time and shortening overall completion latency. In this implementation, each thread can maintain a local double-ended queue to store assigned verification tasks. Under normal circumstances, tasks are distributed to each thread's queue by the scheduler for execution; when a thread completes its local task and its local queue is empty, the thread will steal tasks from other threads' queues according to a predetermined strategy to ensure continuous utilization of computing resources in the thread pool. Because verification tasks have varying degrees of correlation, work-stealing does not employ a completely random stealing method but prioritizes locality and data consistency for tasks within the same field and task layer.

[0059] Specifically, when the task queue of the first thread in the dynamic thread pool is empty, the first thread preferentially steals tasks from other validation task queues for the same field. If other validation task queues for the same field are empty, tasks are stolen from the tail of other field task queues. The reason for prioritizing stealing from other task queues for the same field is that validation tasks for the same field typically share the same field context, cached data, or input preprocessing results. From the perspective of cache hit rate and context reuse, this is more beneficial in reducing redundant computation overhead. For example, a field may simultaneously have three tasks: syntax validation, value range validation, and uniqueness validation. If these tasks are distributed across different threads, stealing tasks within the same field allows for better reuse of preceding parsing results, field metadata, and input value objects in the local cache. If all tasks for the same field have been completed or cannot be stolen, tasks are then stolen from the tail of other field task queues. Tail-stealing is used here to avoid disrupting the local execution order of tasks in the original queue and to reduce frequent competition for tasks at the head of the queue, thereby improving the stability and fairness of concurrent execution.

[0060] In another preferred implementation, the task scheduler can also comprehensively consider task granularity, task duration, and dependency depth for balanced task allocation. For tasks with long expected execution times, such as uniqueness verification tasks that require access to databases or external services, they can be preferentially assigned to queues with more idle threads to avoid long tasks occupying a few thread resources and causing other tasks to queue. For short-running pure in-memory computation tasks, such as syntax verification for regular expression matching, they can be batched into the same queue to reduce scheduling and thread switching. The work-stealing mechanism can also set a stealing threshold, meaning that a stealing thread will only initiate a stealing request when the target queue length exceeds a certain threshold, avoiding excessive contention among multiple idle threads for short task queues. If a stolen task fails, the failure result will be reported and summarized according to the currently adopted failure handling mode.

[0061] During parallel execution, the validation engine maintains the execution status and exception handling mechanism for each task to precisely control the task lifecycle and handle failures. The execution status includes at least the following states: pending execution, executing, successful execution, failed execution, canceled, and skipped. The exception handling mechanism is used to uniformly intercept and package rule exceptions, data exceptions, and system exceptions that may occur during task execution. Before each task begins execution, the scheduler assigns it a unique task identifier and establishes a status object to record the task's fields, rules, dependent nodes, submission time, start time, completion time, and current status. When a task calls specific validation logic, the validation engine standardizes the returned result. If the rule judgment passes, the task status is set to success; if the rule judgment fails, the status is set to failure, and the failure reason, error code, error message, and associated field values ​​are recorded. If an exception occurs during execution, such as database connection timeout, missing rule configuration, or expression parsing error, the exception handling mechanism converts the exception into a unified failure event for consistent processing by the upper layer.

[0062] When a task verification fails, the system supports two processing modes: fast failure mode and aggregate failure mode, to adapt to different business scenarios with varying requirements for response speed and error integrity. In fast failure mode, once any task returns a failure result, the verification engine immediately interrupts all unexecuted or currently executing tasks at the same or lower levels and returns the first failure result to the caller. To achieve this, the scheduler needs to maintain a list of interruptible tasks and send cancellation signals to all related tasks that have not yet been completed upon receiving a failure event; for tasks that have not yet started execution, they are directly removed from the execution queue and marked as cancelled; for tasks that are currently executing, an interruption checkpoint is set in the task code to stop subsequent execution as soon as possible after completing the current atomic operation. Fast failure mode is suitable for latency-sensitive scenarios where only the first critical error needs to be detected. For example, during online data entry, if a user enters an invalid key field, the system can immediately prompt and prevent subsequent submissions, thereby reducing unnecessary calculations and database accesses.

[0063] In aggregated failure mode, the verification engine does not immediately terminate the entire process due to the failure of a single task. Instead, it continues to execute all independent tasks. Once all tasks in the current layer are completed, all failure information is aggregated and returned uniformly. This mode is particularly suitable for batch import, data governance analysis, or backend auditing scenarios, as these scenarios typically focus on comprehensively understanding all issues present in a batch or record, rather than simply returning the first error. To achieve aggregated failure, the scheduler does not employ an immediate termination strategy for single-point failures in task status management. Instead, it continuously records error information from failed tasks into an aggregated result container. After all tasks in the current layer are completed, the system merges, deduplicates, and sorts the failure results, for example, categorizing them by field dimension, rule dimension, or error severity level, thereby outputting a more complete verification report to the user. For tasks with inter-layer dependencies, if a preceding task fails but does not affect other unrelated tasks in the current layer, the system can still continue to execute subsequent tasks that have no direct dependency on the failed node, thereby improving error detection coverage.

[0064] In handling task failures, the system can further consider the context to determine whether to trigger rollback or compensation operations. If the verification process is only a read-based verification and does not produce persistent side effects, the failed task can simply record the result without rolling back. If the verification process is associated with temporary caching, pre-written states, or pre-occupied resources, resource release and state rollback logic can be triggered in the event of a fast failure or severe exception to prevent the incomplete state from affecting subsequent verification batches. For aggregated failure modes, the system can also assign different priorities to different errors in the failure results, such as classifying required missing fields, format errors, value range errors, and uniqueness conflicts, ultimately forming a structured error list that can be displayed on the front-end page or audited and analyzed by the back-end. This ensures both the efficiency of parallel execution and the traceability and business interpretability of failure handling.

[0065] To ensure the stability and controllability of the parallel execution mechanism, the verification engine performs a validity check on the task graph before initiating parallel verification, ensuring that there are no cycles in the constructed directed acyclic graph. If a circular dependency is formed due to incorrect dependency definition during the rule configuration phase, the scheduler should refuse to initiate parallel execution and return a configuration error message, reminding the administrator to correct the rule dependencies. Simultaneously, the scheduler can also record the number of tasks, average execution time, and failure distribution at each level during topology sorting, enabling subsequent analysis of rule execution bottlenecks through a monitoring panel and continuous optimization of task modeling granularity and thread pool parameters.

[0066] In a preferred implementation, task execution in a dynamic thread pool can also incorporate timeout and retry control mechanisms. For each task, an independent timeout can be set. If a task fails to complete within the timeout threshold, the system can mark it as a timeout failure and decide whether to interrupt the task based on the current mode. For tasks experiencing occasional external resource access failures, such as a brief database unavailability during uniqueness checks, a limited number of retries can be configured without violating the fail-fast strategy to improve the overall success rate. Retrying should avoid infinite retries that prevent thread allocation; therefore, a maximum number of retries and a backoff waiting strategy should be set. Task status, failure information, retry count, and stealing history should all be recorded in the execution log for easy identification of performance issues or rule anomalies.

[0067] Through the above technical solution, in scenarios where multiple verification rules of the same type need to be executed in parallel, the system first explicitly expresses verification dependencies using task modeling and directed acyclic graphs. Then, it achieves secure scheduling of intra-layer parallelism and inter-layer serialism through hierarchical topology sorting. Furthermore, it fully utilizes multi-core resources by combining a dynamic thread pool and a work-stealing mechanism to improve overall throughput and resource balance. Simultaneously, it flexibly adapts to different business scenarios through two modes: fast failure and aggregate failure. This satisfies both the response speed requirements of online interactive scenarios and the error integrity requirements of batch data governance scenarios. Therefore, this implementation transforms parallel verification from simple thread concurrency into a complete execution system built upon rule dependencies, task scheduling, resource adaptation, and exception handling, thereby achieving a balance of high concurrency, high accuracy, and high maintainability in railway master data verification.

[0068] Step S40: During the verification process, when multiple verification rules conflict, a conflict resolution mechanism is applied to resolve the conflict. This conflict resolution mechanism is constructed based on a priority strategy, a business importance strategy, or a user configuration strategy. The application of the conflict resolution mechanism includes: identifying the type of verification rule conflict, which includes rule priority conflict, condition mutual exclusion conflict, or execution order conflict; resolving conflicts based on a priority strategy, where the result of a higher-priority rule determines the final state and is processed according to the preset priority order; resolving conflicts based on a business importance strategy, where verification rules for core business fields have higher weight, and the business importance priority order is: uniqueness verification takes precedence over value range verification, value range verification takes precedence over syntax verification, and syntax verification takes precedence over required field verification; and resolving conflicts based on a user configuration strategy, where administrators are allowed to set forced pass flags or warning level rules during rule configuration to adjust the rule execution results.

[0069] In a specific implementation scenario, when multiple rules simultaneously apply to one or more fields and produce contradictory results, the system initiates a multi-layered conflict resolution mechanism to ensure the determinism and reasonableness of the final result. The system first identifies the type of conflict, such as conditional exclusion conflicts (where two range rules set non-overlapping valid ranges for the same field) or execution order conflicts (where multiple rules of different types fail validation simultaneously), requiring the system to decide which error message should be displayed first. The system provides three resolution strategies for these conflicts.

[0070] The first strategy is based on preset priority, which strictly follows the execution order of required fields > syntax > value range > uniqueness. The result of the rule at the previous level has absolute veto power.

[0071] The second strategy is based on business importance. This priority order may differ from the execution order, focusing more on the core value of the data. For example, for a primary key field, its uniqueness is the most important attribute in the business, so uniqueness validation is set to the highest priority. If a primary key field violates both the format rules and the uniqueness rules, the system will prioritize reporting the uniqueness conflict error because it has a greater impact on the business.

[0072] The third approach is a user configuration strategy that gives administrators maximum flexibility. When configuring a rule, administrators can set its severity level to "Warning" instead of "Error." This way, even if the rule fails validation, the data entry process will not be interrupted; only a warning record will be left in the report.

[0073] Furthermore, administrators can set a "force pass" flag for specific rules, which is very useful in special scenarios such as importing legacy data, allowing certain checks to be temporarily bypassed. For example, when importing data from older devices, their encoding format may not conform to the new rules. In this case, the administrator can temporarily set the corresponding syntax validation rules to the warning level, thus allowing the data import while marking these non-compliant data for subsequent cleaning. This layered, configurable conflict resolution mechanism ensures that the system can make intelligent decisions that meet business expectations when faced with complex and contradictory validation logic, greatly enhancing the practicality of data validation methods.

[0074] Suppose a data entry clerk in a dispatch center is entering information on a newly added freight vehicle. The data they submit is: "Vehicle Number" G80_2024_0012, "Assigned Route" Beijing-Guangzhou Line, and "Axle Load" 26t. However, this seemingly simple data violates multiple preset verification rules in the system, thus activating the conflict resolution mechanism.

[0075] When configured to use a "business importance strategy" for conflict resolution, its decision-making logic will fully serve the core safety and efficiency of railway transportation. The system's default business importance order is: uniqueness check takes precedence over value range check, and value range check takes precedence over syntax check. In this example, the "vehicle number" G80_2024_0012 violates the standard format of "vehicle type-year-serial number" because it contains underscores, triggering a syntax check failure.

[0076] Meanwhile, assuming an identical number already exists in the database, this triggers a uniqueness check failure. Furthermore, system rules stipulate that the maximum axle load of G80 series freight cars assigned to the "Beijing-Guangzhou Railway" must not exceed 25t; therefore, the "vehicle axle load" of 26t triggers a value range check failure.

[0077] Faced with these three simultaneous errors, the system weighed the pros and cons based on its business importance strategy, determining that the uniqueness of the vehicle number was the highest priority for preventing scheduling chaos and safety incidents. Therefore, the system masked the other errors and prioritized returning a uniqueness conflict error message to the user: "Error: Vehicle number G80_2024_0012 already exists; this number must be globally unique." This feedback directly addressed the most critical business issue.

[0078] However, if the system administrator switches the conflict resolution mechanism to a "preset priority strategy," the system's feedback will be drastically different. This strategy strictly follows the validation execution flow of "required fields > syntax > value range > uniqueness," aiming to filter data step-by-step from the source of data entry and improve validation efficiency. In the same scenario, when the system performs the first layer of valid syntax validation, it will find that the "vehicle number" G80_2024_0012 has a format error. Since syntax validation has higher priority than value range and uniqueness validation, the system will immediately interrupt all subsequent validation steps and directly return the format error information to the user: "Error: Vehicle number format is incorrect; a hyphen '-' should be used as the separator." This approach avoids performing an expensive database uniqueness query on data that is already formatted incorrectly, thus saving system resources.

[0079] Building upon this foundation, the "user configuration strategy" provides necessary flexibility for specific business scenarios. For example, the railway department is testing a batch of vehicles equipped with new sensors. The administrator has set a warning-level rule: for any newly entered G80 series vehicles, the system should prompt for a check of the sensor configuration. When the vehicle information is ready to be submitted after correcting major errors (whether uniqueness or syntax errors), even without any additional user action, the system will display a non-blocking prompt on the successful submission screen: "Warning: This vehicle is a new G80 series vehicle; please confirm that its sensor configuration has been synchronized and updated in another system." Furthermore, if a batch of legacy vehicle data is imported and its numbering format generally does not conform to the new regulations, the administrator can temporarily set a "force pass" flag for the syntax validation rule, allowing this batch of data to be entered into the database first, only marked as pending processing, thus ensuring the smooth progress of data migration. Through this multi-strategy conflict resolution mechanism, the railway master data system can make intelligent decisions that both conform to business logic and consider execution efficiency when faced with complex and intertwined rules.

[0080] Step S50: Generate a verification report, wherein the verification report indicates the verification results, including displaying the verification status and error information on the front-end interface.

[0081] The generation of the verification report includes: highlighting error information on the front-end interface by using a status banner or visual marking of error fields, and providing a button to view the detailed report to display the complete verification details; storing the verification report for at least a predetermined time and associating it with the operation log to record the user, time, and data model metadata that triggered the verification; and supporting the querying of historical verification reports by data model, time range, and verification status conditions.

[0082] In a specific implementation scenario, the presentation and management of validation results form a closed loop. For front-end users, the system provides immediate and intuitive feedback when validation errors occur. For example, a red status banner appears at the top of the data entry form, indicating the number of errors. Simultaneously, each failed input field is highlighted with a red border, and the specific error message, such as "This field cannot be empty" or "Format does not meet requirements," is displayed directly below it.

[0083] To facilitate troubleshooting complex issues, the interface also provides a "View Detailed Report" button. Clicking it will bring up a window that displays a list showing the execution status of each validation rule triggered by the submission, including the rule name, validation field, input value, and the final validation result: success, failure, or warning.

[0084] On the backend, every validation operation, regardless of success or failure, generates a structured report record. This record is persistently stored in a database or log system and retained for at least 180 days for auditing purposes. The report not only includes detailed validation results but also rich metadata, such as which user or system triggered the validation, when, and which master data model the operation targeted. The system also provides a powerful historical report query function. Data quality administrators can use a dedicated management interface to retrieve historical validation reports using various criteria, such as querying all failure reports related to the "vehicle information" model within the past month, or querying all warning messages generated when synchronizing data from a specific interface. This comprehensive reporting mechanism not only provides clear operational guidance for end users but also provides strong data support for data governance, enabling managers to easily trace the source of data quality problems, analyze error patterns and trends, and continuously improve data quality management strategies.

[0085] As shown in Figure 2, a railway master data verification system based on a multi-rule engine according to a second embodiment of the present invention is based on a railway master data verification method based on a multi-rule engine. The system includes: a rule configuration module configured to store multiple verification rules, wherein the verification rules include at least syntax verification rules, uniqueness verification rules, value range verification rules, and required field verification rules, each rule defining its verification logic, parameters, and metadata; a data receiving module configured to receive input data to be verified, wherein the input data to be verified is triggered by any one of manual entry, interface synchronization, or batch import, and contains multiple fields to be verified; and a verification engine module. Its configuration is as follows: in response to the input data to be verified, a verification engine is used to perform verification based on the rule base. The verification execution includes applying the various verification rules to the fields of the data to be verified, and performing the verification in a serial or parallel manner according to a preset rule grouping and priority order. During the verification process, when multiple verification rules conflict, a conflict resolution mechanism is applied to resolve the conflict. The conflict resolution mechanism is constructed based on a priority strategy, a business importance strategy, or a user configuration strategy. The report generation module is configured to generate a verification report, which indicates the verification results, including displaying the verification status and error information on the front-end interface.

[0086] In this embodiment, at the core level of master data management, the master data modeling module and the rule configuration module are deeply integrated. When defining the data model, the rule configuration interface is directly called to configure corresponding validation rules for each attribute. The master data classification module sets differentiated validation rule sets for different categories of master data through the rule configuration module, achieving categorized data quality management. The dictionary management module, as an important parameter source for value range validation rules, provides a standard set of legal values ​​for the value range validation rules in the rule configuration module. The model management module, through the rule configuration module, achieves version synchronization management of validation rules and data models, ensuring consistency between rules and models.

[0087] At the data access and distribution level, when the master data integration module receives data from external systems, it first calls the standardized interface of the data receiving module to unify the data format, and then triggers the verification engine module to perform data quality verification. The master data distribution module, before distributing data, uses the verification engine module to review and verify the data to be distributed, ensuring the reliability and quality of the output data. When providing data query services, the data query interface module filters data based on the permission rules defined in the rule configuration module and records data access logs through the report generation module.

[0088] The multi-rule validation engine cluster, as the core component of the validation engine module, comprises four specialized engines: a syntax validation engine, a value range validation engine, a uniqueness validation engine, and a required field validation engine. These engines dynamically load the latest validation rule configurations from the rule configuration module and process the data according to the standardized data format provided by the data receiving module. The syntax validation engine specifically executes the regular expressions and formatting rules defined in the rule configuration module, submitting the validation results to the report generation module in real time. The value range validation engine verifies the legality of data values ​​based on the static value list or dynamic data source references set in the rule configuration module. The uniqueness validation engine ensures data uniqueness by querying the business uniqueness constraints defined in the rule configuration module. The required field validation engine verifies data integrity constraints based on the required field rules marked in the rule configuration module.

[0089] At the business process support level, the master data maintenance module receives user input data through the data receiving module, calls the validation engine module for real-time validation, and finally provides feedback on the validation results to the user through the report generation module. The master data query module, when performing query operations, refers to the data permission rules defined in the rule configuration module and records the query behavior through the report generation module. The approval management module integrates the validation engine module into the approval process to perform a final quality review of approved data, ensuring that only validated data can proceed to the next stage. The unified permissions module works in conjunction with the rule configuration module to configure corresponding data operation permissions and rule management permissions for different user roles.

[0090] The data standards module at the system configuration and management level provides standard specifications for the rule configuration module, ensuring that the definition of validation rules conforms to industry standards and business specifications. The attribute configuration module works closely with the rule configuration module, directly configuring corresponding validation rules while defining data attributes, achieving integrated operation of attribute management and rule management.

[0091] The various modules form an organic working loop through the coordination of core components. When external data enters the system through the master data integration module, the data receiving module is responsible for unified reception and data standardization processing, and then calls the verification engine module to perform multi-rule verification. The verification engine module dynamically obtains the latest rule configuration from the rule configuration module, executes the verification task according to the preset strategy, and submits the verification results to the report generation module in real time. The report generation module is not only responsible for generating detailed verification reports, but also displays the real-time verification results to users through the master data maintenance module. For data changes that require approval, the approval management module calls the verification engine module for review and verification to ensure data quality consistency. Finally, the verified data is distributed to various business systems by the master data distribution module, completing the entire data flow process.

[0092] This system architecture, centered around four core components, achieves high synergy and loose coupling among functional modules. The rule configuration module, acting as the rule management center, provides unified rule services to all modules requiring rule validation. The data receiving module, as the data entry hub, ensures that all data entering the system undergoes standardized processing. The validation engine module, as the validation execution core, provides consistent validation capabilities to all business processes. The report generation module, as the result output center, ensures that all validation results are fully recorded and promptly fed back. Through this architectural design, the system not only ensures clear separation of responsibilities among modules but also achieves seamless integration of the overall workflow, providing reliable technical support for railway master data management.

[0093] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related explanations of the methods described above can be found in the corresponding processes in the foregoing system embodiments, and will not be repeated here.

[0094] It should be noted that the railway master data verification system based on a multi-rule engine provided in the above embodiments is only an example of the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the modules or steps in the embodiments of the present invention can be further decomposed or combined. For example, the modules in the above embodiments can be merged into one module, or further divided into multiple sub-modules to complete all or part of the functions described above. The names of the modules and steps involved in the embodiments of the present invention are only for distinguishing the various modules or steps and are not considered as an improper limitation of the present invention.

[0095] A device according to a third embodiment of the present invention includes: at least one processor; and a memory communicatively connected to at least one of the processors; wherein the memory stores instructions executable by the processor, the instructions being executed by the processor to implement the above-described railway master data verification method based on a multi-rule engine.

[0096] A computer-readable storage medium according to a fourth embodiment of the present invention stores computer instructions, which are executed by the computer to implement the above-described railway master data verification method based on a multi-rule engine.

[0097] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the storage device and processing device described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0098] The terms “first”, “second”, etc., are used to distinguish similar objects, not to describe or indicate a specific order or sequence.

[0099] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0100] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A railway master data verification method based on a multi-rule engine, characterized in that, The method includes: configuring a rule base for storing various validation rules, wherein the validation rules include at least syntax validation rules, uniqueness validation rules, value range validation rules, and required field validation rules, each rule defining its validation logic, parameters, and metadata; receiving input data to be validated, wherein the input data to be validated is triggered by any one of manual entry, interface synchronization, or batch import, and contains multiple fields to be validated; responding to the input data to be validated, using a validation engine to perform validation based on the rule base, wherein performing validation includes applying various validation rules to the fields of the data to be validated, and performing validation serially or in parallel according to a preset rule grouping and priority order; during the validation process, when multiple validation rules conflict, applying a conflict resolution mechanism to resolve the conflict, wherein the conflict resolution mechanism is constructed based on a priority strategy, a business importance strategy, or a user configuration strategy; and generating a validation report, wherein the validation report indicates the validation results, including displaying the validation status and error information on the front-end interface.

2. The railway master data verification method based on a multi-rule engine as described in claim 1, characterized in that, The configuration rule base includes: defining syntax validation rules to ensure that the data format of the validated fields conforms to predefined specifications, including length, character type, and regular expression patterns; defining uniqueness validation rules to ensure that a specific field or combination of fields is unique throughout the entire system; defining value range validation rules to ensure that the value of a field is within a predefined set of valid values, which includes a static list of valid values ​​or a dynamic database reference value; and defining mandatory field validation rules to ensure that specific key fields provide non-null values ​​when data is created or updated. The rule base supports the management of the activation status of these validation rules.

3. The railway master data verification method based on a multi-rule engine as described in claim 2, characterized in that, Receiving input data to be verified includes: triggering verification through manual entry, where the user completes the record entry on the data management page and clicks the save or submit button; triggering verification through interface synchronization, where the business system pushes data through the application programming interface, and the data format includes JSON or XML; and triggering verification through batch import, where the user imports data through a file template, and the file format includes spreadsheets. In response to the trigger, the input data to be verified is automatically parsed and the fields to be verified are extracted to initialize the verification process.

4. The railway master data verification method based on a multi-rule engine as described in claim 1, characterized in that, The validation process includes: applying syntax validation rules, using regular expressions to match whether field values ​​conform to predefined format specifications; applying uniqueness validation rules, checking whether a field value or combination of fields already exists by querying the associated master data table; applying value range validation rules, checking whether the field value belongs to a predefined set of valid values ​​by parsing a static list of valid values ​​or performing a dynamic database query; applying mandatory field validation rules, checking whether the field value is empty; and interrupting the data entry process and returning an error message if any validation rule fails.

5. The railway master data verification method based on a multi-rule engine as described in claim 1, characterized in that, The validation process includes: executing different types of validation rules sequentially according to a preset priority order, wherein the priority order is: required field validation takes precedence over syntax validation, syntax validation takes precedence over value range validation, and value range validation takes precedence over uniqueness validation; for multiple validation rules of the same type, they are executed in parallel, wherein thread pool technology is used to allocate an independent thread for each rule; validation rules for different fields are executed in parallel; and validation rules with dependencies are executed sequentially to ensure that subsequent validations are performed only after the preconditions have been determined.

6. The railway master data verification method based on a multi-rule engine as described in claim 1, characterized in that, The application conflict resolution mechanism includes: identifying the type of validation rule conflict, which includes rule priority conflict, condition mutual exclusion conflict, or execution order conflict; resolving conflicts based on priority strategy, where the result of the higher priority rule determines the final state and is processed according to the priority order; resolving conflicts based on business importance strategy, where validation rules for core business fields have higher weight, and the priority order of business importance is: uniqueness validation takes precedence over value range validation, value range validation takes precedence over syntax validation, and syntax validation takes precedence over required field validation; and resolving conflicts based on user configuration strategy, where administrators are allowed to set rules to force pass flags or warning levels to adjust the rule execution results during rule configuration.

7. The railway master data verification method based on a multi-rule engine as described in claim 1, characterized in that, The generation of verification reports includes: highlighting error information on the front-end interface with a status banner or visual marking of error fields, and providing a button to view detailed reports to display complete verification details; storing verification reports for at least a predetermined time and associating them with operation logs to record the user, time, and data model metadata that triggered the verification; and supporting the querying of historical verification reports by data model, time range, and verification status conditions.

8. A railway master data verification system based on a multi-rule engine, comprising a railway master data verification method based on a multi-rule engine as described in any one of claims 1-7, characterized in that, The system includes: a rule configuration module configured to store multiple validation rules, wherein the validation rules include at least syntax validation rules, uniqueness validation rules, value range validation rules, and required field validation rules, each rule defining its validation logic, parameters, and metadata; a data receiving module configured to receive input data to be validated, wherein the input data to be validated is triggered by any one of manual entry, interface synchronization, or batch import, and contains multiple fields to be validated; a validation engine module configured to respond to the input data to be validated by using the validation engine to perform validation based on the rule base, wherein the validation execution includes applying multiple validation rules to the fields of the data to be validated, and performing validation in a serial or parallel manner according to a preset rule grouping and priority order; during the validation execution process, when multiple validation rules conflict, a conflict resolution mechanism is applied to resolve the conflict, wherein the conflict resolution mechanism is constructed based on a priority strategy, a business importance strategy, or a user configuration strategy; and a report generation module configured to generate a validation report, wherein the validation report indicates the validation results, including displaying the validation status and error information on the front-end interface.

9. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to at least one of the processors; wherein the memory stores instructions executable by the processor to implement a railway master data verification method based on a multi-rule engine as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are executed by the computer to implement the railway master data verification method based on a multi-rule engine as described in any one of claims 1-7.

Images