An API full-link automatic processing system for signal intelligent operation and maintenance

Abstract

The application provides an API full-link automatic processing system for signal intelligent operation and maintenance, which adopts a hierarchical architecture design and comprises an access layer, a core processing layer, a data storage layer and a system adaptation layer. Based on the Swagger framework, the system realizes core functions such as automatic generation and synchronization of API documents, automatic test case generation, automatic distinction of interface and device fault sources, operation and maintenance fault directional pushing, cross-interface data dependency association and rule engine threshold alarm pushing by analyzing standard annotations and custom annotations. The system solves the problems of the existing API management tools in the signal operation and maintenance scene, such as the lack of annotation driving, the dependence on manual document updating and the insufficient automation capability, and realizes technical effects such as near-zero manual intervention in document maintenance, significant improvement in test efficiency, more accurate fault location, more front-end operation and maintenance response, more fine permission control and more efficient fault processing, and is fully adapted to the operation and maintenance business requirements of urban rail transit signals.

Description

Technical Field

[0001] This invention relates to the field of rail transit and interface document management technology, and in particular to an API full-link automated processing system for intelligent signal operation and maintenance. Background Technology

[0002] As urban rail transit expands, signaling intelligent operation and maintenance systems often adopt a "front-end visual operation and maintenance + back-end microservices" architecture, involving multiple functional modules such as real-time data monitoring, historical data management, and intelligent fault diagnosis. These modules rely on API interfaces for data interaction and command transmission. Current mainstream API documentation management tools, such as APIDOC and Postman, suffer from issues like a lack of annotation-driven functionality, reliance on manual document updates, and insufficient automation capabilities. Similar general-purpose API solutions only address basic document generation and debugging, failing to adapt to the specific needs of signaling operation and maintenance scenarios. Summary of the Invention

[0003] In view of the above problems, the present invention is proposed to provide an API full-link automated processing system for intelligent signal operation and maintenance that overcomes or at least partially solves the above problems.

[0004] This invention provides an API end-to-end automated processing system for intelligent signal operation and maintenance, comprising: The access layer provides an entry point for API documentation and performs permission verification and request forwarding. The core processing layer is used to parse standard and custom annotations in the interface code, generate API documentation and extract interface metadata, automatically generate test cases based on the interface metadata, and synchronize the generated API documentation to the data storage layer. The data storage layer is used to store API documentation, permission configuration information, and automated test execution logs; The system adaptation layer is used to interact with the external signal intelligent operation and maintenance system and push messages based on the instructions or data generated by the core processing layer.

[0005] Optionally, the access layer includes an Nginx gateway component and an authentication module. The Nginx gateway component is used to provide an API documentation access point and forward access requests; The permission authentication module is used to perform hierarchical permission verification for accessing users.

[0006] Optionally, the core processing layer includes an annotation parsing module, a standardized verification engine, an automated test case generation module, and a document synchronization center. The annotation parsing module is used to parse Swagger standard annotations and custom annotations in the interface code, generate standardized OpenAPI documentation, and extract interface metadata. The standardized verification engine is used to perform compliance verification on the generated API documents for RESTful paths, parameter classification, and return structure standardization. The automated test case generation module is used to automatically generate test cases including request methods and expected responses based on the parsed interface types and parameters. The document synchronization center is used to synchronize and store the generated API documents to the data storage layer, and to aggregate API documents generated by multiple microservices and perform version management.

[0007] Optionally, the system adaptation layer includes an interface adaptation module and a data push component. The interface adaptation module is used to interact with the external signal intelligent operation and maintenance system based on the instructions or data generated by the core processing layer, and to obtain equipment status and business data. The data push component is used to push fault information or alarm information to the corresponding responsible person according to preset push rules.

[0008] Optionally, the automated test case generation module is used for: For query-type interfaces, test cases are automatically generated, including valid values ​​for required parameters, combinations of optional parameters, and invalid parameters. For creating or updating class interfaces, basic test cases are automatically generated, including request URLs, methods, parameter values, and expected responses.

[0009] Optionally, The annotation parsing module of the core processing layer is used to parse the @ApiDevice annotation to obtain the signal device bound to the interface and the dependent device status fields. The interface adaptation module of the system adaptation layer is used to obtain the device status of the signal device when the interface call is abnormal. The automated test case generation module of the core processing layer is used to automatically distinguish fault types by combining device status and interface test results, and generate a detailed report including the root cause of the fault, device information and interface logs; the fault types include interface faults and device faults. The data push component of the system adaptation layer is used to push fault information to the corresponding responsible person in real time according to the pre-configured mapping rules of fault type, responsible person and push channel, and to track the status after push and provide secondary reminders for faults that have not been read within the time limit.

[0010] Optionally, The annotation parsing module of the core processing layer is used to parse the @ApiDataDependency annotation and build a data dependency chain between interfaces; The automated test case generation module of the core processing layer is used to execute the preceding interfaces in the order of the data dependency chain during the automated testing process, automatically extract the dependent data and populate it into the current test case, and execute the current interface test; if any preceding interface fails to execute, the current interface test is terminated, and the data push component of the system adaptation layer is triggered to send a reminder.

[0011] Optionally, The core processing layer also includes a rule engine for configuring threshold rules for signal monitoring data. The threshold rules include upper limit, lower limit, interval, and rate of change types. The interface adaptation module of the system adaptation layer is used to collect business data returned by the interface in real time and send it to the rule engine. The rule engine is used to continuously compare business data with the threshold rules. When the data exceeds the threshold, an alarm message is generated, and the data push component of the system adaptation layer is triggered to push the alarm message to the corresponding operation and maintenance personnel according to the preset push rules. The alarm message includes the alarm level.

[0012] Optionally, the access layer also includes a shared portal, which provides a fault center for summarizing and displaying fault information generated by the system. It supports filtering by fault type, signal device, and time range, viewing fault details including fault root cause, device status, and interface logs, and receiving fault handling results and status updates entered by the responsible person.

[0013] This invention has the following advantages: This invention presents a fully automated API processing system for intelligent signal operation and maintenance, employing a layered architecture design including an access layer, a core processing layer, a data storage layer, and a system adaptation layer. Based on the Swagger framework, the system parses standard and custom annotations to achieve core functions such as automatic API documentation generation and synchronization, automated test case generation, automatic differentiation of interface and device fault root causes, targeted push notifications for operation and maintenance faults, cross-interface data dependency association, and rule engine threshold alarm push notifications. This system addresses the shortcomings of existing API management tools in signal operation and maintenance scenarios, such as the lack of annotation-driven features, reliance on manual documentation updates, and insufficient automation capabilities. It achieves near-zero manual intervention in documentation maintenance, significantly improved testing efficiency, more accurate fault location, more proactive operation and maintenance response, more refined access control, and more efficient fault handling, fully adapting to the operational needs of urban rail transit signal operation and maintenance. Attached Figure Description

[0014] Figure 1This is an architecture diagram of the API end-to-end automated processing system for intelligent signal operation and maintenance according to the present invention; Figure 2 This is a flowchart of the fault handling and push notification process when the interface is abnormal according to the present invention; Figure 3 This is a flowchart of the automated testing process for cross-interface data dependencies according to the present invention. Detailed Implementation

[0015] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0016] 1. System Implementation Environment This invention presents a fully automated API processing system for intelligent signaling operation and maintenance, implemented based on a Spring Boot microservice architecture. The system environment includes multiple microservice modules such as real-time data monitoring and intelligent fault diagnosis services. Data storage utilizes a MySQL database and an IoTDB time-series database. The gateway layer employs an Nginx component, and signaling equipment communicates with the system via Ethernet and serial ports. The system is deployed in an intelligent signaling operation and maintenance environment for urban rail transit and seamlessly integrates with existing intelligent signaling operation and maintenance systems.

[0017] 2. System Architecture Figure 1 This is a layered architecture diagram of an API end-to-end automated processing system for intelligent signal operation and maintenance. From top to bottom, it includes external roles, access layer, core processing layer, data storage layer, system adaptation layer, and external interface system. The core components and connections of each layer are as follows: (1) Access layer The access layer, serving as the system's unified entry point, consists of an Nginx gateway component and a Spring Security-based authentication module. The Nginx gateway component provides a unified access point for the API documentation and forwards user requests to the appropriate backend services. The authentication module is based on the RBAC (Role-Based Access Control) model, pre-setting roles such as system administrators, developers, testers, and operations personnel to implement hierarchical permission verification for different roles.

[0018] Specifically, the access layer first authenticates user access requests, verifying the validity of user credentials. Then, it performs permission checks based on user roles, ensuring that users can only access API documentation and functions within their authorized scope. For access to sensitive interfaces, the permission authentication module uses a custom `@ApiSensitive` annotation to implement fine-grained permission checks for document viewing, exporting, and debugging. All operations are logged for subsequent auditing. The access layer also includes a shared portal, which provides a fault center to aggregate and display system-generated fault information. It supports filtering by fault type, signal device, and time range, allowing users to view fault details including root cause, device status, and interface logs, and receive fault handling results and status updates from responsible personnel.

[0019] (2) Core processing layer The core processing layer is the core functionality implementation layer of the system, comprising four main components: an annotation parsing module, a standardized verification engine, an automated test case generation module, and a document synchronization center. The specific functions of each component are as follows: The annotation parsing module is responsible for parsing Swagger standard annotations (such as @Api, @ApiOperation, @ApiParam, etc.) and custom annotations (including @ApiSensitive, @ApiDevice, @ApiDataDependency, etc.) in the API code. During the system compilation phase, the annotation parsing module scans all API code using a Maven plugin, extracting metadata information such as API paths, request methods, parameter definitions, and return value structures, and generating API documentation that conforms to the OpenAPI 3.0 standard. For custom annotations, the annotation parsing module extracts additional business semantic information, such as sensitive interface identifiers, device binding relationships, and data dependencies, providing foundational data for subsequent automated processing.

[0020] The standardized validation engine performs compliance checks on the generated API documentation to ensure that all interfaces adhere to a unified RESTful design specification. Validation includes: API path naming conventions (using lowercase letters and hyphens), parameter classification conventions (correct use of path parameters, query parameters, and request body parameters), and return value structure conventions (a unified JSON response format, including status codes, messages, data, and other fields). For interfaces that do not conform to the specifications, the standardized validation engine generates a validation report and prompts developers to make corrections.

[0021] The automated test case generation module automatically generates test cases based on the parsed interface metadata. For query interfaces (GET methods), the system automatically generates three types of test cases: test cases for valid values ​​of required parameters, test cases for combinations of optional parameters, and test cases for invalid parameters. For create or update interfaces (POST / PUT methods), the system generates basic test cases containing the request URL, request method, parameter values, and expected response. During the test case generation process, the system automatically populates sample data.

[0022] The document synchronization center is responsible for synchronizing and storing the generated API documentation to the data storage layer, and for aggregating and managing the versions of documentation from multiple microservices. In a microservice architecture, each microservice independently generates its own API documentation. The document synchronization center periodically scans the documentation output directories of each microservice and aggregates all documentation into a unified document repository. Simultaneously, the document synchronization center generates a version number for each document update, records version change history, and supports version rollback and difference comparison functions.

[0023] (3) Data storage layer The data storage layer uses a MySQL relational database to store various types of structured data in the system. The stored content includes: API structured document data (interface definitions, parameter information, return value structures, etc.), permission configuration information (role definitions, permission assignments, sensitive interface configurations, etc.), and automated task execution logs (test case execution records, fault handling logs, alarm records, etc.).

[0024] Specifically, the data storage layer employs multiple tables to organize and store various types of information. The API documentation table stores basic information and detailed definitions of interfaces; the permission configuration table stores the mapping relationships between roles, users, and permissions; the test log table stores the execution results and detailed information of test cases; the fault record table stores information such as fault occurrence time, fault type, and processing status; and the alarm rule table stores the configuration information of threshold rules. All data tables are appropriately indexed to ensure efficient data retrieval.

[0025] (4) System adaptation layer The system adaptation layer is responsible for interfacing with external intelligent signal operation and maintenance systems, and includes two main parts: an interface adaptation module and a data push component.

[0026] The interface adaptation module interacts with the existing intelligent signal operation and maintenance system via RESTful APIs or message queues. In fault handling scenarios, the interface adaptation module calls the device status query interface of the intelligent signal operation and maintenance system to obtain real-time status information of specified signal equipment (such as switch machines, signal controllers, etc.), including key parameters such as online status, interface voltage, and operating temperature. In rule engine scenarios, the interface adaptation module pulls business data returned by the signal monitoring interface in real time, such as train position, track occupancy status, and signal display status, and passes this data to the rule engine of the core processing layer for analysis and processing.

[0027] The data push component is responsible for pushing important messages such as fault information and alarm information to the corresponding responsible persons. Multiple push channels are supported, including DingTalk, WeChat Work, SMS, and email. The data push component determines the recipients and push method based on a preset "fault type-responsible person-push channel" mapping rule. During the push process, the data push component records the push status. For messages that are not read within the timeout period, the system automatically triggers a secondary reminder mechanism to ensure that important information is delivered to relevant personnel in a timely manner.

[0028] The following is a detailed description of the implementation process of several core functions: (1) Automatic differentiation of interface and equipment fault root causes and targeted push function for operation and maintenance faults The automatic identification of interface and device fault root causes is achieved by using a custom `@ApiDevice` annotation to bind the interface to the corresponding signal device. In the interface code, developers use the `@ApiDevice` annotation to mark the signal device corresponding to the interface and specify the dependent device status fields.

[0029] When an API call encounters an exception, the system triggers an exception handling mechanism. The annotation parsing module parses the `@ApiDevice` annotation on the API to obtain the bound device information. Then, the API adaptation module in the system adaptation layer calls the device status query interface of the intelligent signal operation and maintenance system to obtain the real-time status of the device. The automated test case generation module in the core processing layer performs a comprehensive analysis based on the device status and API test results. If the device is in normal condition (e.g., online status is true, voltage is within normal range), but the interface call is abnormal, it is determined to be an interface failure. If the device status is abnormal (such as offline, abnormal voltage, etc.), it is determined to be a device malfunction; The system automatically generates a detailed report containing the root cause of the fault, device information, and interface logs, and pushes the fault information to the responsible personnel via a data push component. Interface faults are pushed to developers, and device faults are pushed to maintenance personnel, ensuring that faults are handled promptly.

[0030] The targeted push notification function for maintenance faults is implemented based on a preset fault push rule table. The rule table defines the mapping relationship between fault types, responsible persons, and push channels.

[0031] When a fault occurs, the system queries the rule table to determine the responsible party and the push channel, and then sends a fault notification through the data push component. The notification includes detailed information such as the fault type, occurrence time, scope of impact, and handling suggestions. The system records the push status, and for faults that are not read within the timeout period, a secondary reminder mechanism is automatically triggered. Simultaneously, the system provides a shared portal fault center function, supporting fault filtering, detailed viewing, and processing result entry, forming a complete fault handling closed loop.

[0032] Reference Figure 2 The specific process is as follows: ① An API call exception occurs, triggering the exception handling mechanism; ② The system queries the device status bound to this interface (via the @ApiDevice annotation); ③ Based on the device status and interface response, automatically distinguish the fault type (interface fault or device fault). ④ Based on the fault type, query the push rule table to determine the responsible person and push channel; ⑤ Send fault notifications to the responsible person via the data push component; ⑥ The person in charge handles the fault and updates the status in the system.

[0033] (2) Automated testing function for cross-interface data dependencies This feature defines dependencies between interfaces using a custom `@ApiDataDependency` annotation. In test cases, developers use the `@ApiDataDependency` annotation to mark the preceding interfaces that the current interface depends on, as well as the mapping relationships of data fields.

[0034] When the system starts, the annotation parsing module parses the `@ApiDataDependency` annotation in all test cases and builds a complete dependency chain. During automated testing, the automated test case generation module executes the preceding interfaces sequentially according to the dependency chain. If any preceding interface fails, the system immediately terminates the current test and sends a notification via the data push component to inform the testers of the broken dependency chain.

[0035] Reference Figure 3 The specific process is as follows: ① Parse the @ApiDataDependency annotation in the test case and build the dependency chain; ② Execute the preceding interfaces in sequence to extract the required data; ③ Populate the extracted data into the current test case; ④ Execute the current interface test; ⑤ If the preceding interface fails to execute, terminate the current test and send a notification.

[0036] (3) Rule engine threshold alarm push function The rule engine is a lightweight, built-in rule processing engine that supports visual configuration of threshold rules. Rule types include: Upper limit rule: An alarm is triggered when the monitored data exceeds a specified upper limit value; Lower limit rule: An alarm is triggered when the monitored data falls below a specified lower limit value; Interval rule: Trigger an alarm when monitored data exceeds the specified interval range; Change rate rule: An alarm is triggered when the rate of change of the monitored data exceeds a threshold within a specified time.

[0037] During system operation, the interface adaptation module pulls business data returned by the monitoring interface in real time, and the rule engine continuously compares the data with threshold rules. When the data exceeds the threshold, the rule engine immediately generates an alarm message, including the alarm level (alert / general / urgent), alarm time, and abnormal data value. Then, the data push component is triggered to send the alarm message to the corresponding operations and maintenance personnel according to the preset push rules. The system records alarm logs, including alarm status, processing status, and processing results, supporting alarm tracking and statistical analysis.

[0038] The following is a description of the actual usage process: (1) Developers update the interface code and add relevant annotations. After compilation, the documentation is automatically synchronized to the shared portal. (2) Testers perform tests, the system generates basic test cases according to interface type, automatically associates cross-interface data according to dependency chain, and completes the whole process test; (3) When the interface is abnormal, the system synchronously queries the device status, distinguishes the fault type, and pushes the information to the corresponding responsible person; (4) Unauthorized users accessing sensitive interfaces are blocked, and operation logs are retained for auditing; (5) The system monitors the threshold configured on the real-time data monitoring interface through the rule engine. When the threshold exceeds the limit rule, the system automatically generates an emergency alarm and pushes it, so that maintenance personnel can handle it in advance.

[0039] Results: Interface failure rate is reduced, document maintenance is close to zero manual intervention, proactive system early warning is achieved, operation and maintenance response is more forward-looking, testing, access control and fault handling efficiency are significantly improved, failure rate is further reduced, and it is fully adapted to the operation and maintenance needs of urban rail transit signaling.

[0040] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0041] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, electronic devices, storage media, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0042] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0043] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0044] The foregoing has provided a detailed description of the API end-to-end automated processing system for intelligent signal operation and maintenance provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are merely for the purpose of helping to understand the method and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application. The above embodiments are merely preferred embodiments given to fully illustrate this invention, and the scope of protection of this invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on this invention are all within the scope of protection of this invention.

Claims

1. An API end-to-end automated processing system for intelligent signal operation and maintenance, characterized in that, The system includes: The access layer provides an entry point for API documentation and performs permission verification and request forwarding. The core processing layer is used to parse standard and custom annotations in the interface code, generate API documentation and extract interface metadata, automatically generate test cases based on the interface metadata, and synchronize the generated API documentation to the data storage layer. The data storage layer is used to store API documentation, permission configuration information, and automated test execution logs; The system adaptation layer is used to interact with the external signal intelligent operation and maintenance system and push messages based on the instructions or data generated by the core processing layer.

2. The system according to claim 1, characterized in that, The access layer includes an Nginx gateway component and an authentication module. The Nginx gateway component is used to provide an API documentation access point and forward access requests; The permission authentication module is used to perform hierarchical permission verification for accessing users.

3. The system according to claim 1, characterized in that, The core processing layer includes an annotation parsing module, a standardized verification engine, an automated test case generation module, and a document synchronization center. The annotation parsing module is used to parse Swagger standard annotations and custom annotations in the interface code, generate standardized OpenAPI documentation, and extract interface metadata. The standardized verification engine is used to perform compliance verification on the generated API documents for RESTful paths, parameter classification, and return structure standardization. The automated test case generation module is used to automatically generate test cases including request methods and expected responses based on the parsed interface types and parameters. The document synchronization center is used to synchronize and store the generated API documents to the data storage layer, and to aggregate API documents generated by multiple microservices and perform version management.

4. The system according to claim 1, characterized in that, The system adaptation layer includes an interface adaptation module and a data push component. The interface adaptation module is used to interact with the external signal intelligent operation and maintenance system based on the instructions or data generated by the core processing layer, and to obtain equipment status and business data. The data push component is used to push fault information or alarm information to the corresponding responsible person according to preset push rules.

5. The system according to claim 3, characterized in that, The automated test case generation module is used for: For query-type interfaces, test cases are automatically generated, including valid values ​​for required parameters, combinations of optional parameters, and invalid parameters. For creating or updating class interfaces, basic test cases are automatically generated, including request URLs, methods, parameter values, and expected responses.

6. The system according to claim 3 or 4, characterized in that, The annotation parsing module of the core processing layer is used to parse the @ApiDevice annotation to obtain the signal device bound to the interface and the dependent device status fields. The interface adaptation module of the system adaptation layer is used to obtain the device status of the signal device when the interface call is abnormal. The automated test case generation module of the core processing layer is used to automatically distinguish fault types by combining device status and interface test results, and generate a detailed report including the root cause of the fault, device information and interface logs; the fault types include interface faults and device faults. The data push component of the system adaptation layer is used to push fault information to the corresponding responsible person in real time according to the pre-configured mapping rules of fault type, responsible person and push channel, and to track the status after push and provide secondary reminders for faults that have not been read within the time limit.

7. The system according to claim 3 or 4, characterized in that, The annotation parsing module of the core processing layer is used to parse the @ApiDataDependency annotation and build a data dependency chain between interfaces; The automated test case generation module of the core processing layer is used to execute the preceding interfaces in the order of the data dependency chain during the automated testing process, automatically extract the dependent data and populate it into the current test case, and execute the current interface test; if any preceding interface fails to execute, the current interface test is terminated, and the data push component of the system adaptation layer is triggered to send a reminder.

8. The system according to claim 1, characterized in that, The core processing layer also includes a rule engine for configuring threshold rules for signal monitoring data. The threshold rules include upper limit, lower limit, interval, and rate of change types. The interface adaptation module of the system adaptation layer is used to collect business data returned by the interface in real time and send it to the rule engine. The rule engine is used to continuously compare business data with the threshold rules. When the data exceeds the threshold, an alarm message is generated, and the data push component of the system adaptation layer is triggered to push the alarm message to the corresponding operation and maintenance personnel according to the preset push rules. The alarm message includes the alarm level.

9. The system according to claim 1, characterized in that, The access layer also includes a shared portal, which provides a fault center for summarizing and displaying fault information generated by the system. It supports filtering by fault type, signal device, and time range, and allows users to view fault details including the root cause of the fault, device status, and interface logs. It also receives fault handling results and status updates entered by the responsible person.

Images