Interlocking lower computer log analysis method and system based on database

Abstract

The invention discloses an interlocking lower computer log analysis method and system based on a database, and the method comprises the steps: reading a log file, and analyzing and extracting key information in the log file; the key information is stored in the form of a structured database, and the key information corresponding to different board card types is classified and stored in different database tables of the structured database; performing multi-dimensional abnormal data detection based on the key information stored in the database table; abnormal log data information obtained through abnormal data detection is stored in an event table; and exporting the abnormal log data information stored in the event table in a table form. The whole process from log reading to report generation is automatic, manual intervention can be reduced, and analysis efficiency and accuracy are improved. Moreover, by constructing a structured database, accurate positioning and traceability verification are facilitated, and long-term historical data analysis and rapid fault investigation can be realized.

Description

Technical Field

[0001] This invention relates to the field of rail transit data processing technology, and in particular to a database-based method and system for analyzing interlocking lower-level machine logs. Background Technology

[0002] As the core of rail transit signal control, the reliability of the interlocking system directly affects train operation safety. The interlocking system mainly consists of the interlocking slave unit, the interlocking operator unit, and the interlocking maintenance console. The interlocking operator unit is responsible for human-machine interaction, sending operation commands and providing a visual representation of the station. The interlocking maintenance console is responsible for collecting, storing, and displaying interlocking logs to record and monitor the status of the interlocking system. The interlocking slave unit, as the core of the interlocking system's operation, is responsible for executing interlocking logic, generating interlocking operation logs, and sending them to the interlocking maintenance console.

[0003] However, while the interlocking maintenance console can receive log information sent by the lower-level interlocking machine, its display interface cannot fully present all the log data. Therefore, when conducting in-depth analysis of the causes of interlocking system failures, maintenance personnel need to manually locate the problem from massive amounts of logs, investing a significant amount of time in manual screening and analysis. This analysis method is not only inefficient and time-consuming in fault location, hindering rapid fault elimination and prolonging system recovery time, but also carries a significant risk of missing critical information, making it difficult to fully guarantee operational safety. Therefore, there is an urgent need for an interlocking lower-level machine log analysis method and system that can solve the above problems.

[0004] The statements herein provide only background information in relation to this invention and do not necessarily constitute prior art. Summary of the Invention

[0005] The purpose of this invention is to address the problems existing in the prior art by providing a database-based method and system for analyzing interlocking lower-level machine logs. This system automates the entire process from log reading to report generation, reducing manual intervention and improving analysis efficiency and accuracy. Furthermore, by constructing a structured board-level database, it facilitates precise location and traceability verification, enabling long-term historical data analysis and rapid fault investigation.

[0006] To achieve the above objectives, the present invention is implemented through the following technical solution: The first aspect of this invention provides a database-based method for analyzing interlocking lower-level machine logs, comprising: Read the log file, and parse and extract the key information from the log file; The key information is stored in the form of a structured database, wherein key information corresponding to different board types is classified and stored in different database tables of the structured database; Based on the key information stored in the database tables, multi-dimensional abnormal data detection is performed; The abnormal log data information obtained through the abnormal data detection is stored in the event table; Export the exception log data information stored in the event table in tabular form.

[0007] Optionally, reading the log files includes: reading all log files in a specified directory; or, filtering and reading a portion of the log files in a specified directory within a specific fault time period.

[0008] Optionally, the key information includes at least: log date and time, message sequence number, A-series / B-series identifier, primary / backup system status, module name, system cycle, application cycle, and / or detailed log content; The detailed log content includes at least status information, alarm information, and / or module information.

[0009] Optionally, boards installed in different physical locations may have different board types.

[0010] Optionally, the abnormal data detection includes at least: detection of discontinuity of message sequence numbers, detection of abnormal operating status, detection of abnormal panel status, detection of abnormal communication status, detection of abnormal board status, detection of abnormal single board status, detection of abnormal switching module status, detection of abnormal common module status, and / or detection of alarm information of external interfaces.

[0011] Optionally, the message sequence number discontinuity detection includes: dividing all message sequence numbers using the message sequence number with a value of 0 as the dividing point, and sorting each segment of message sequence numbers to further detect whether there are any discontinuous message sequence numbers.

[0012] Optionally, the abnormal data detection includes: performing anomaly detection for different states based on changes in the state information in the key information.

[0013] Optionally, the alarm information detection of the external interface includes: searching based on the key information, and when alarm information is found, recording the PID (PERIPHERAL_ID, device number) information of the corresponding external interface and the alarm information.

[0014] Optionally, the abnormal log data information stored in the event table includes at least: log date and time, board type, event type, message sequence number, system cycle, application cycle, PID information and / or event description.

[0015] Optionally, exporting the abnormal log data information stored in the event table in tabular form includes: sorting the contents of the event table according to a combination of log date and time, system cycle and message sequence number, and exporting it to a table.

[0016] Optionally, exporting the abnormal log data information stored in the event table in tabular form further includes: performing secondary processing on the abnormal log data information stored in the event table to obtain abnormal events existing in different types of boards under a certain log date and time and system cycle, so as to generate a board snapshot table.

[0017] A second aspect of the present invention provides a database-based interlocking lower-level machine log analysis system, comprising: The parsing module is used to read log files and parse and extract key information from the log files; A storage module, connected to the parsing module, is used to store the key information in the form of a structured database, wherein key information corresponding to different board types is categorized and stored in different database tables of the structured database; The detection module, connected to the storage module, is used to perform multi-dimensional anomaly detection based on the data stored in the database table; the storage module is used to store the anomaly log data information obtained through the anomaly detection in an event table. The output module, connected to the storage module, is used to export the exception log data information stored in the event table in tabular form.

[0018] This invention has at least the following technical effects: A fully automated process has been established from reading log data to generating analysis results. Users only need to provide the path where the logs are located to automatically extract information, store it, detect anomalies, and output analysis results. This helps reduce manual intervention, improve analysis efficiency and accuracy, and fully ensure driving safety.

[0019] By constructing a structured board-level database, precise mapping of device topology relationships is achieved, facilitating accurate problem localization to specific boards. Simultaneously, original log data is fully preserved, eliminating the need for reloading and rerunning, thus ensuring the accuracy of data analysis and improving the convenience of traceability and verification.

[0020] By using a database system for storing and managing log data, the performance bottleneck of traditional file-based storage is overcome. This enables fast writing, persistent storage, and efficient querying of massive amounts of log data, laying the foundation for long-term historical data analysis and rapid fault investigation. Attached Figure Description

[0021] Figure 1This is a flowchart illustrating a database-based interlocking lower-level machine log analysis method according to an embodiment of the present invention. Detailed Implementation

[0022] The following detailed description, in conjunction with the accompanying drawings and specific embodiments, provides a further detailed explanation of the interlocking lower-level machine log analysis method and system proposed in this invention. The advantages and features of this invention will become clearer from the following description. It should be noted that the accompanying drawings are in a very simplified form and use non-precise proportions, used only to facilitate and clearly illustrate the embodiments of this invention. Please refer to the accompanying drawings to make the objectives, features, and advantages of this invention more apparent and understandable. It should be understood that the structures, proportions, sizes, etc., depicted in the accompanying drawings are only for illustrative purposes to aid those skilled in the art and are not intended to limit the implementation conditions of this invention. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in proportions, or adjustments to the size, without affecting the effects and objectives achieved by this invention, should still fall within the scope of the technical content disclosed in this invention.

[0023] like Figure 1 As shown, this embodiment provides a database-based method for analyzing interlocking lower-level machine logs, including the following steps: Step S1: Read the log file and parse and extract the key information from the log file.

[0024] Step S2: Store key information in the form of a structured database, wherein key information corresponding to different board types is classified and stored in different database tables of the structured database.

[0025] Step S3: Based on the key information stored in the database table, perform multi-dimensional abnormal data detection.

[0026] Step S4: Store the abnormal log data information obtained through abnormal data detection in the event table.

[0027] Step S5: Export the exception log data information stored in the event table in tabular form.

[0028] This embodiment automates the entire process from log reading to report generation by establishing an end-to-end automated analysis workflow. Users only need to provide the path to the logs to automatically complete information extraction, storage, anomaly detection, and report output. This significantly reduces manual intervention, greatly improves analysis speed and efficiency, and ensures the accuracy of the analysis.

[0029] Specifically, in step S1, when reading log files, the user can specify the directory of log files to be analyzed and read all logs in the specified directory for overall analysis. Alternatively, the user can filter and read a portion of the log files in the specified directory within a specific fault time period for more targeted analysis.

[0030] After reading the log file to be analyzed, key information can be further parsed and extracted. Specifically, key information includes, but is not limited to, log date and time, message sequence number, A / B series identifier, primary / backup system status, module name, system cycle, application cycle, and detailed log content.

[0031] The log date and time are the times recorded by the interlocking maintenance console system. The message sequence number is the sequence number assigned to each log message by the interlocking lower-level machine. The module name is the information of the specific functional module within the interlocking lower-level machine that generated the corresponding log message. The system cycle is the working time count of the interlocking lower-level machine system. The application cycle is the working time count of the interlocking program in the interlocking lower-level machine. The detailed log content is a detailed text description of the log message, which may include specific status information, alarm information, and module information.

[0032] As those skilled in the art will understand, interlocking lower-level machines typically employ a 2x2 redundancy architecture to improve reliability. In this architecture, system A is a logical unit, while system B is another logical unit that serves as a backup for system A. The system A / B identifiers are used to record the logical unit that generates the corresponding log messages, while the primary / backup status records the logical operational role of system A or system B within the redundancy architecture when generating the corresponding log messages.

[0033] Furthermore, in step S2, the extracted key information can be stored in the form of a structured database. As those skilled in the art will understand, a structured database is a database that stores data in a structured form, typically presented as a two-dimensional table, suitable for scenarios requiring efficient data querying and management. This embodiment, by employing a structured database system for log storage and management, overcomes the performance bottlenecks of traditional file-based storage, supporting rapid writing, persistent storage, and efficient querying of massive log data, laying the foundation for long-term historical data analysis and rapid fault investigation.

[0034] Furthermore, key information can be structured and stored in different database tables according to board type. Specifically, boards installed in different physical locations have different board types. For example, referring to the above, the dual-system hot standby redundancy architecture adopted by the interlocking lower-level machine includes A-system and B-system. The chassis corresponding to A-system has, for example, two MPU (microprocessor unit) boards inserted, namely A-system MPU1 and A-system MPU2. The chassis corresponding to B-system also has two MPU boards inserted, namely B-system MPU1 and B-system MPU2. That is, the interlocking lower-level machine includes four types of boards: A-system MPU1, A-system MPU2, B-system MPU1, and B-system MPU2. Therefore, key information can be categorized and stored in four database tables corresponding to A-system MPU1, A-system MPU2, B-system MPU1, and B-system MPU2 respectively, thereby achieving direct mapping between log data and physical devices.

[0035] This embodiment achieves precise mapping of device topology by configuring the correspondence between board types and database tables, facilitating accurate fault location to specific boards. Simultaneously, it fully preserves original log data, eliminating the need for reloading and rerunning, thus ensuring the accuracy of data analysis and improving the convenience of traceability and verification.

[0036] Furthermore, in step S3, comprehensive multi-dimensional anomaly detection can be performed on the key information in the database tables corresponding to each board. The detection scope of multi-dimensional anomaly detection includes, but is not limited to, detection of discontinuity in message sequence numbers, anomaly detection of operating status, anomaly detection of panel status, anomaly detection of communication status, anomaly detection of board status, anomaly detection of single board status, anomaly detection of switching module status, anomaly detection of common module status, and alarm information detection of each external interface.

[0037] As those skilled in the art will understand, under normal circumstances, message sequence numbers should be continuously increasing (e.g., 1001, 1002, 1003...). If discontinuous sequence numbers are found (e.g., 1001, 1002, 1005...), it is possible that message packets were lost between 1002 and 1005. A message sequence number being cleared to zero is a typical indicator of a system restart. Because log data contains a large amount of redundancy and message sequence numbers from different time periods may be duplicated, in this embodiment, to detect discontinuity in message sequence numbers, all message sequence numbers can be segmented using a sequence number with a value of 0 as the dividing point. Each segment of message sequence numbers is then sorted to further detect whether there are discontinuous message sequence numbers and to count the number of lost message packets.

[0038] Specifically, when detecting anomalies in different states, the changes in state information in the detailed log content of key information can be used for judgment. When the state information changes at consecutive points in time, such as "connected --> disconnected" or "disconnected --> connected", it can be considered that a state transition has occurred. By combining the analysis of changes in the state information of different modules, it is possible to further determine whether an abnormal state transition has occurred.

[0039] For example, when performing anomaly detection on interface status, log data containing the COM field can be searched, and key information corresponding to the COM field can be extracted, including date and time, message sequence number, system cycle, application cycle, interface information, and detailed log information. As those skilled in the art will understand, the COM field is a key field in the log data used for serial port identification. Furthermore, data in the format {key: oldValue, newValue} can be extracted from the detailed log information using regular expressions, where key represents the status type, oldValue represents the old status value, and newValue represents the new status value. Based on different combinations of key, oldValue, and newValue, the status changes of the corresponding interface can be determined and used as content for log analysis.

[0040] Specifically, when detecting alarm information from external interfaces, the search can be based on module information within the key information. Specifically, it can search whether the information corresponding to the module name field in the key information matches an existing external interface. If a match is found, the corresponding alarm information is extracted. When alarm information is found, the PID information of the corresponding external interface and the alarm information are recorded.

[0041] The anomaly detection method provided in this embodiment adopts a dynamic anomaly detection mechanism. It does not rely on preset fault codes or fixed combination judgment rules. Instead, it dynamically identifies anomalies by analyzing the continuity of message sequence numbers and the rationality of state transitions, effectively reducing the missed detection rate of hidden faults.

[0042] Further, in step S4, the detected abnormal log data can be stored in an event table. The abnormal log data stored in the event table includes, but is not limited to, log date and time, board type, event type, message sequence number, system cycle, application cycle, PID information, and event description. Among these, the detection content based on multi-dimensional anomaly detection includes event types such as discontinuous message sequence numbers, operating status, panel status, communication status, board status, single-board status, switching module status, common module status, and all external interface types. Event descriptions are divided into two types: the first is a description derived from analyzing detailed log content, and the second is directly extracted detailed log content. Specifically, the detection of discontinuous message sequence numbers and anomalies in different states correspond to the first type of event description, while the detection of alarm information from various external interfaces corresponds to the second type of event description. All event records can be sorted in the event table according to log date and time, system cycle, and message sequence number to reconstruct the timeline and logical sequence of events.

[0043] Finally, in step S5, the exception log data stored in the event table can be exported in tabular form, such as as an Excel spreadsheet. The contents of the event table can be sorted according to combinations of log date and time, system cycle, and message sequence number, and then exported to a table.

[0044] Furthermore, the abnormal log data stored in the event table can be processed a second time to obtain abnormal events existing on different types of boards under a certain log date and time and system cycle, in order to generate a board snapshot table. The board snapshot table is used to record the current abnormal status overview of each board at a specific point in time (date and time and system cycle).

[0045] In other aspects, this embodiment also provides a database-based interlocking lower-level machine log analysis system, including a parsing module, a storage module, a detection module, and an output module.

[0046] Specifically, the parsing module reads log files and parses and extracts key information from them. The storage module, connected to the parsing module, stores this key information in a structured database, where key information corresponding to different board types is categorized and stored in different database tables. The detection module, connected to the storage module, performs multi-dimensional anomaly detection based on the data stored in the database tables. The storage module also stores the anomaly log data obtained through anomaly detection in an event table. The output module, connected to the storage module, exports the anomaly log data stored in the event table in tabular form.

[0047] The storage module includes, but is not limited to, random access memory (RAM), solid-state drive (SSD), hard disk drive (HDD), tape library, and optical disc. The parsing module, detection module, and output module can be integrated into the same processor or located on different processors. The processor can be at least one of a central processing unit (CPU), graphics processing unit (GPU), neural network processor (NPU), application-specific integrated circuit (ASIC), digital signal processor (DSP), field-programmable gate array (FPGA), and microcontroller (MCU).

[0048] Furthermore, the interlocking lower-level machine log analysis system may also include a human-machine interaction module. Users can use this module to perform operations such as selecting log files and exporting abnormal log data.

[0049] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0050] It should be noted that the apparatus and methods disclosed in the embodiments herein can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments herein. In this regard, each block in a flowchart or block diagram may represent a module, program, or part of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system to perform the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0051] In addition, the functional modules in the various embodiments of this article can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0052] Although the present invention has been described in detail through the preferred embodiments above, it should be understood that the above description should not be considered as a limitation of the present invention. Various modifications and substitutions to the present invention will be apparent to those skilled in the art after reading the above description. Therefore, the scope of protection of the present invention should be defined by the appended claims.

Claims

1. A database-based method for analyzing interlocking lower-level machine logs, characterized in that, include: Read the log file, and parse and extract the key information from the log file; The key information is stored in the form of a structured database, wherein key information corresponding to different board types is classified and stored in different database tables of the structured database; Based on the key information stored in the database tables, multi-dimensional abnormal data detection is performed; The abnormal log data information obtained through the abnormal data detection is stored in the event table; Export the exception log data information stored in the event table in tabular form.

2. The interlocking lower-level machine log analysis method according to claim 1, characterized in that, The reading of log files includes: reading all log files in a specified directory; or, filtering and reading a portion of log files in a specified directory within a specific fault time period.

3. The interlocking lower-level machine log analysis method according to claim 1, characterized in that, The key information includes at least: log date and time, message sequence number, A-series / B-series identifier, primary / backup system status, module name, system cycle, application cycle, and / or detailed log content; The detailed log content includes at least status information, alarm information, and / or module information.

4. The interlocking lower-level machine log analysis method according to claim 1, characterized in that, The boards installed in different physical locations have different board types.

5. The interlocking lower-level machine log analysis method according to claim 3, characterized in that, The abnormal data detection includes at least: detection of message sequence number discontinuity, detection of abnormal operating status, detection of abnormal panel status, detection of abnormal communication status, detection of abnormal board status, detection of abnormal single board status, detection of abnormal switching module status, detection of abnormal common module status, and / or detection of alarm information from external interfaces.

6. The interlocking lower-level machine log analysis method according to claim 5, characterized in that, The message sequence number discontinuity detection includes: dividing all message sequence numbers into segments with a value of 0 as the dividing point, and sorting each segment of message sequence numbers to further detect whether there are any discontinuous message sequence numbers.

7. The interlocking lower-level machine log analysis method according to claim 5, characterized in that, The abnormal data detection includes: detecting abnormalities in different states based on changes in the state information in the key information.

8. The interlocking lower-level machine log analysis method according to claim 5, wherein the alarm information detection of the external interface includes: The search is performed based on the key information, and when an alarm is found, the PID information of the corresponding external interface and the alarm information are recorded.

9. The interlocking lower-level machine log analysis method according to claim 3, wherein the abnormal log data information stored in the event table includes at least: Log date and time, board type, event type, message sequence number, system cycle, application cycle, PID information and / or event description.

10. The interlocking lower-level machine log analysis method according to claim 9, characterized in that, The step of exporting the abnormal log data information stored in the event table in tabular form includes: sorting the contents of the event table according to a combination of log date and time, system cycle and message sequence number, and then exporting it to a table.

11. The interlocking lower-level machine log analysis method according to claim 10, characterized in that, The step of exporting the abnormal log data information stored in the event table in tabular form further includes: performing secondary processing on the abnormal log data information stored in the event table to obtain the abnormal events existing in different types of boards under a certain log date and time and system cycle, so as to generate a board snapshot table.

12. A database-based interlocking lower-level machine log analysis system, characterized in that, include: The parsing module is used to read log files and parse and extract key information from the log files; A storage module, connected to the parsing module, is used to store the key information in the form of a structured database, wherein key information corresponding to different board types is categorized and stored in different database tables of the structured database; The detection module, connected to the storage module, is used to perform multi-dimensional anomaly detection based on the data stored in the database table; the storage module is used to store the anomaly log data information obtained through the anomaly detection in an event table. The output module, connected to the storage module, is used to export the exception log data information stored in the event table in tabular form.

Images