Train active control event data automated extraction and analysis engine for root cause analysis of unstructured data

Abstract

A system and method for root cause analysis of mandatory events is presented. The system can accurately detect law enforcement events and find out root causes of the events. The system can use an automated workflow engine to enable accurate detection of mandatory events and identification of root causes of such events. The system may perform root cause analysis based on at least one analysis model. The system may provide a user with an interface to monitor a mandatory event by collecting a series of data points representing characteristics of the mandatory event, and analyze the data points to assess a root cause of the mandatory event.

Description

Technical Field

[0001] The present disclosure relates generally to performing root cause analysis on railroad events, and more particularly to systems and methods for automating workflows and performing root cause analysis on unstructured data structures of a train fleet. Background Art

[0002] The Positive Train Control (PTC) system generates braking events associated with train operation. When a train is in danger of overstepping its authority or exceeding speed, it initiates a penalty application to stop the train, which is called a braking event. Generally, determining the root cause of a locomotive stopping event is time-consuming. Each braking event must usually be manually reviewed to determine the root cause of the event. Manual inspection can take hours or even days to determine the cause.

[0003] The management of a train fleet is a complex system. The mechanical and electrical characteristics of the fleet are so complex that root cause analysis cannot rely on a single data source to resolve a single mandatory event. To complicate matters further, the organization managing the locomotives may need to cope with a large number of events across the fleet, as it takes a lot of time to resolve the root cause of each mandatory event, write an event summary, and send the summary to the right people. Most mandatory events can be resolved to the root cause in about an hour through manual analysis, but in some cases, the resolution may even take more than a full day.

[0004] While existing organizational methods and personnel are capable of identifying and managing root cause analysis of train-related incidents, the inspection process is often still done manually. For example, rail personnel conduct physical inspections of the fleet and ultimately determine the root causes of mandatory incidents. Such personnel may misclassify incidents, require regular training, and make inaccurate records in system component logs. In addition, the root cause may be caused by a variety of factors, such as signal loss, train problems, hardware or software problems, or human error. Due to the complexity of the system, manual inspections of the fleet alone are not sufficient. Summary of the invention

[0005] The present disclosure achieves technical advantages as a system and method for performing root cause analysis on mandatory events that typically provide unstructured data. The system can use an automated workflow engine to accurately detect mandatory events and identify the root causes of such events. The system can provide a user with an interface for monitoring mandatory events by collecting a series of data points that characterize mandatory events, and analyze the data points to evaluate the root causes of mandatory events. The system can also use an extraction model to extract key information from the system component logs of the train to generate an activity window to provide the analysis model with a comprehensive scope for analyzing mandatory events. In addition, the system can provide users with reliable and accurate information about the root causes of mandatory events.

[0006] In one embodiment, the present disclosure solves the technical problem of analyzing data related to forced events from different sources containing unstructured data by providing an automated tool for identifying train events and providing the root cause of forced events in less time than manual inspection. For example, a force may include an event that triggers the system to force a locomotive to come to a complete stop when the locomotive violates a safety policy. Current root cause analysis procedures require hours or even days to determine a solution. The present disclosure provides an automated solution by using data analysis techniques to identify the root cause in minutes or even seconds, surpassing the conventional manual analysis of train events. The system also has the advantage of only providing relevant information required for a specific train event, thereby simplifying the inspection process. This analysis can provide a faster solution than manual inspection, thereby minimizing delays in train functions and optimizing train event investigation time.

[0007] The present disclosure provides a technical solution that is lacking in traditional systems through an extraction and analysis engine that can identify train events, retrieve train system logs, convert structured and unstructured data into predefined standard formats, perform root cause analysis on PTC events and notify subscribers of solutions. The extraction and analysis engine can implement one or more extraction models to identify relevant data. The present disclosure achieves improved system performance through an extraction and analysis engine (and corresponding models) that can parse multiple PTC event-related files to retrieve only relevant details related to a specific PTC event and implement user-defined, actionable scenario-based implementations. Beneficially, the present disclosure provides an automated extraction and analysis engine and method for train active control event data that can determine the cause of a PTC braking event through root cause analysis without user interaction, thereby reducing the repetitive tasks involved in braking event reporting. In another embodiment, the automatic extraction model and the automatic analysis model can automatically (without user interaction) extract relevant log data and analyze the braking event data using a machine learning algorithm. For example, the PTC event automated extraction / analysis engine can implement a natural language processing keyword detection algorithm to identify relevant information. Once the root cause is determined, the system can generate a detailed report for transmission to all event subscribers and close the event. In addition, the system can classify brake events for reporting purposes, escalate events for inspection, and provide detailed and in-depth brake event analysis. The system can also achieve at least the following functions: Real-time or historical analysis; Multiple onboard software versions that can be processed in parallel; ·Solution tracking for problem solving; ·alarm; User subscription; Rich and diverse classification models; Continuous improvement; System reports; Advanced classification; and Data retention.

[0008] The present disclosure technically surpasses the traditional manual analysis of train events, and efficiently identifies relevant data from cumbersome and complex log data through an automated data extraction and analysis engine, and uses data analysis technology to process the data in minutes or even seconds to determine the root cause, thereby minimizing train downtime. Therefore, the present disclosure discloses a number of concepts that are inseparable from computer technology, so that the present disclosure provides technical advantages by only providing relevant information required to identify and analyze specific train events to simplify the data extraction and analysis process. With this analysis, faster solutions can be provided than manual inspections, thereby minimizing delays in train functions and optimizing train event investigation time.

[0009] When an event occurs, the system can identify the new event and download the necessary logs. Once the logs are downloaded, unzipped, and stored in a directory for the system to begin processing, the event can be stored in a queue for execution the next time it is instantiated to begin processing and analyzing the event. The system can implement control logic, machine learning, and / or system services to verify event times, identify the primary CPU during forcing, verify that the event has occurred, determine the appropriate system component software versions, and initiate advanced system health scans to ensure that the data is reliable for performing event analysis. Once completed and the event is authorized for processing, the system can select the appropriate extraction model to obtain the appropriate data points. As software versions change and adjust, more extraction models will be developed and presented for system selection in at least some event analysis. When the extraction model is launched, all logs can be moved into a dictionary to give each line of log data a unique identifier. The extraction model can implement pre-built regular expressions or data manipulation practices (such as splitting) when compiling delimited (structured) lines to obtain insights and valuable information. Logs can be processed according to a unified data structure to normalize the data. The system also allows for extracting data points, calculating variables, and creating event time windows for the data.

[0010] In another embodiment, as the prioritized data points are identified in the log, the system can generate data points about the course of events and the time at which the events occurred compared to the mandatory time. These time windows can simulate the execution of manual analysis. For example, the length of the time window may be seconds, minutes, or hours, and may be positive or negative (occurring before or after) relative to the mandatory time.

[0011] The data may also be transformed and processed by one or more analytical models instantiated on one or more devices. In another embodiment, analytical models may be created using a variety of data science methods, including decision trees, classification, and clustering. Once the model is developed, the system may convert the model into a custom algorithm to be implemented by control logic, servers, processors, or other suitable devices. The analytical model may be customized for specific software and include a hierarchical structure. In another embodiment, data analysis may be completed first. If a defect is found, the analysis may conclude that the defect is identified as the cause of the main problem - rather than a response to the defect. Second, the incident may be processed based on a model created over a long period of time involving engineer interactions, system component responses, and situational behaviors. The model may then be exited and a second (or subsequent) model may be instantiated using the data. If the second model is inconsistent with the first model, the system may determine the appropriate model and end the incident. Each model endpoint (e.g., in two models) may create a unique identifier. The unique identifier allows the system to track and dynamically update the model endpoint from the back end by updating the database value of the specific unique identifier. In another embodiment, if a root cause is not determined, the analytical model can combine the target type, target description, and the last banner displayed to the engineer before forcing, as well as other parameters and values, to create a high-level classification for the incident, thereby providing the user with a level of detail related to the incident without the need for manual investigation.

[0012] In another embodiment, using the data retrieved from the extraction and analysis model, the system can create a detailed summary of the events that led to the force and derive the specified root cause. Such events include: the time the train started, the speed of the train at the time of the force, location details, possible warnings, train configuration details, PTC component information, force type, brake type, etc. By aggregating these data points, the end user can understand the events that are known to have occurred and the decision-making process of the system.

[0013] Once the root cause (or high-level classification) is determined, the system can use parameters from the AES to determine who needs to be notified of the incident and the severity of the notification. If an alert is assigned to an analytical model identifier, the appropriate rail team receives an email notifying them to take additional immediate steps to reduce the chance of repeating the error.

[0014] It is an object of the present invention to provide a system for automating the execution of a workflow and performing root cause analysis on a data structure. It is another object of the present invention to provide a method for automating the execution of a workflow and performing root cause analysis on a data structure. It is another object of the present invention to provide a computer-implemented method for automating the execution of a workflow and performing root cause analysis on a data structure. These and other objects are provided by at least the following embodiments.

[0015] In one embodiment, a system for automating workflow execution and performing root cause analysis on a data structure includes: a memory containing a system component log in a database for determining a root cause; and a networked computer processor operably coupled to the memory and capable of executing machine-readable instructions to perform program steps, the program steps including: receiving extracted data; executing a first analysis model using the extracted data to generate a first result and assigning a first unique ID to the first result; if a defect is detected based on the first analysis model, classifying the defect as a root cause; if a defect is not detected based on the first analysis model, executing a second analysis model using the extracted data to generate a second result, assigning a second unique ID to the second result, and comparing the first result with the second result to determine the most accurate result as the root cause; generating a report to indicate the root cause; and storing the first result, the first unique ID, the second result, and the second unique ID. Wherein, the first analysis model includes decision tree logic. Wherein, the first analysis model includes a classification model. Wherein, the first analysis model includes a clustering model. Wherein, the second analysis model includes a historical analysis model based on historical data such as past engineer interactions, system component responses, and situational behaviors. Wherein, the first analysis model includes a machine learning algorithm, or the second analysis model includes a machine learning algorithm. The program step further includes comparing the second result with the historical classification data to determine the accuracy of the second result. The program step further includes determining the most accurate reason based on user input.

[0016] In another embodiment, a method for automating the execution of a workflow and performing root cause analysis on a data structure includes: receiving extracted data; executing a first analysis model using the extracted data to generate a first result and assigning a first unique ID to the first result; if a defect is detected based on the first analysis model, classifying the defect as a root cause; if a defect is not detected based on the first analysis model, executing a second analysis model using the extracted data to generate a second result, assigning a second unique ID to the second result, and comparing the first result with the second result to determine the most accurate result as the root cause; generating a report to indicate the root cause; and storing the first result, the first unique ID, the second result, and the second unique ID. Wherein, the first analysis model includes decision tree logic. Wherein, the first analysis model includes a classification model. Wherein, the first analysis model includes a clustering model. Wherein, the second analysis model includes a historical analysis model based on historical data such as past engineer interactions, system component responses, and situational behaviors. Wherein, the first analysis model includes a machine learning algorithm, or the second analysis model includes a machine learning algorithm. Wherein, the program step also includes comparing the second result with the historical classification data to determine the accuracy of the second result. Wherein, the program step also includes determining the most accurate cause based on user input.

[0017] In another embodiment, a computer-implemented method for automating the execution of a workflow and performing root cause analysis on a data structure includes: receiving extracted data; executing a first analysis model using the extracted data to generate a first result and assigning a first unique ID to the first result; if a defect is detected based on the first analysis model, classifying the defect as a root cause; if a defect is not detected based on the first analysis model, executing a second analysis model using the extracted data to generate a second result, assigning a second unique ID to the second result, and comparing the first result with the second result to determine the most accurate result as the root cause; generating a report to indicate the root cause; and storing the first result, the first unique ID, the second result, and the second unique ID. Wherein, the first analysis model includes decision tree logic. Wherein, the first analysis model includes a classification model. Wherein, the first analysis model includes a clustering model. Wherein, the second analysis model includes a historical analysis model based on historical data such as past engineer interactions, system component responses, and situational behaviors. Wherein, the first analysis model includes a machine learning algorithm, or the second analysis model includes a machine learning algorithm. Wherein, the program step also includes comparing the second result with the historical classification data to determine the accuracy of the second result. Wherein, the program step also includes determining the most accurate cause based on user input. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The present disclosure will be easily understood by the following detailed description in combination with the accompanying drawings, which illustrate the principles of the present disclosure by way of example. The accompanying drawings show the design and practicality of one or more exemplary embodiments of the present disclosure, wherein the same elements are represented by the same reference numerals or symbols. The objects and elements in the accompanying drawings are not necessarily drawn in proportion, ratio or precise positional relationship. Instead, the focus is on illustrating the principles of the present disclosure.

[0019] Figure 1 An automated workflow system according to one or more embodiments of the present disclosure is presented;

[0020] Figure 2 A block diagram of an automated workflow system according to one or more embodiments of the present disclosure is shown;

[0021] Figure 3 A flow chart showing an analysis model control logic according to one or more exemplary embodiments of the present disclosure is provided;

[0022] Figure 4A An analysis decision tree control logic according to one or more exemplary embodiments of the present disclosure is presented; and

[0023] Figure 4B An analysis decision tree control logic according to one or more exemplary embodiments of the present disclosure is presented. DETAILED DESCRIPTION

[0024] The present disclosure and the various features and advantages details therein set forth in the description below will be more fully explained by reference to the non-limiting examples contained in the accompanying drawings and the detailed description that follows. Descriptions of well-known components are omitted herein so as not to unnecessarily obscure the main features described herein. The following examples are intended to facilitate understanding of the implementation and practice of the present disclosure. Those of ordinary skill in the art will understand that the present disclosure means that any suitable combination of the following functions or exemplary embodiments can be combined to achieve the claimed subject matter. The present disclosure includes the number of representative species within the genus, or structural features common to members of the genus, so that those of ordinary skill in the art can identify members of the genus. Therefore, these examples should not be construed as limiting the scope of the claims.

[0025] A person of ordinary skill in the art will understand that any system claim set forth herein encompasses all elements and limitations disclosed therein, and therefore requires that each system claim be considered as a whole. Any reasonably foreseeable item that has a functional relationship with a claim also falls within the relevant scope. Pursuant to MPEP §904, the examiner searches for prior art disclosed in patents and other published documents (i.e., non-patent literature) after thoroughly understanding the invention disclosed and claimed in the non-provisional application. Therefore, the issuance of this patent proves that the prior art fails to disclose or teach the elements and limitations set forth in the claims supported by the specification and drawings, and therefore the set forth claims are patentable under 35 U.S.C. §§101, 102, 103, and 112.

[0026] Figure 1A schematic diagram of an automated workflow system 100 according to one or more embodiments of the present disclosure is shown. The system 100 may include one or more servers 102 having one or more processors 104, a memory 134, machine-readable instructions 106, including a file collection module 108, a message identification module 110, a log collection module 112, an information parsing module 114, a log download module 116, an automated initialization module 118, an automated workflow module 120, an extraction module 122, an analysis module 124, an event monitoring module 126, an automated production module 128, and other related modules. The server 102 may be operably coupled to one or more clients via a network 140. The client may be a physical device (e.g., a mobile phone 150, a laptop 152, an external server 154, a desktop computer, a wearable device, or other suitable device), a program, or an application. In another embodiment, the client may include a mobile phone 150 with a mobile application that can communicate with the server 102 via the network 140.

[0027] The aforementioned system components (e.g., server 102 and client 150, 152, 154, 156, etc.) can be coupled to each other in a communication manner through network 140, so that data can be transmitted. Network 140 can be the Internet, an intranet, or other suitable networks. Data transmission can be encrypted, unencrypted, through a virtual private network (VPN) channel, or other suitable communication methods. Network 140 can be a wide area network (WAN), a local area network (LAN), a personal area network (PAN), or other suitable network types. Network communications between clients, servers 102, or any other system components can be encrypted using Good Privacy Protocol (PGP), Blowfish, Twofish, Triple Data Encryption Standard (3DES), Secure Hypertext Transfer Protocol (HTTPS), or other suitable encryption methods. System 100 can be configured to provide communication via an application programming interface (API), a peripheral component interface (PCI), PCI-Express, an American National Standards Institute (ANSI)-X12, Ethernet, Wi-Fi, Bluetooth, or other suitable communication protocols or media through various systems, components, and modules disclosed herein. Additionally, third party systems and databases may be operatively coupled to the system components via the network 140 .

[0028] Data transmitted to and from components of system 100 (e.g., server 102 and client) may include any format, including JavaScript Object Notation (JSON), Transmission Control Protocol (TCP) / Internet Protocol (IP), Extensible Markup Language (XML), Hypertext Markup Language (HTML), American Standard Code for Information Interchange (ASCII), Short Message Service (SMS), Comma Separated Values ​​(CSV), Representational State Transfer (REST), or other suitable formats. Data transmissions may include messages, flags, headers, header attributes, metadata, and / or bodies, or be encapsulated and packaged in any suitable format therewith.

[0029] The server 102 may be implemented with hardware, software, or a suitable combination of hardware and software, and may include one or more software systems running on one or more servers, including one or more processors 104, and may access a memory 134. The server 102 may include electronic memory, one or more processors, and / or other components. The server 102 may include communication lines, connections, and / or ports to enable information to be exchanged through a network 140 and / or other computing platforms. The server 102 may also include multiple hardware, software, and / or firmware components that operate together to provide the functions attributed to the server 102 herein. For example, the server 102 may be implemented by a computing platform cloud computing that operates together as the server 102, including software as a service (SaaS) and platform as a service (PaaS) functions. In addition, the server 102 may include a memory 134.

[0030] The memory 134 may include electronic storage, which may include non-transitory storage media that electronically stores information. The electronic storage media of the electronic storage may include one or both of a system memory that may be provided integrally with the server 102 (e.g., substantially non-removable) and / or a removable memory, wherein the removable memory may be removably connected to the server 102 via, for example, a port (e.g., a universal serial bus (USB) port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storage may include one or more optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard disk, floppy disk drive, etc.), charge-based storage media (e.g., erasable programmable read-only memory (EEPROM), random access memory (RAM), etc.), solid-state storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. The electronic storage may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and / or other virtual storage resources). The electronic storage may include a database, or a public or private distributed ledger (e.g., blockchain). The electronic storage may store machine-readable instructions 106, software algorithms, control logic, data generated by a processor, data received from a server, data received from a computing platform, and / or other data that may enable a server to operate as described herein. The electronic storage may also include third-party databases accessible via the network 140.

[0031] Processor 104 may be configured to provide data processing capabilities in server 102. Thus, processor 104 may include one or more digital processors, analog processors, digital circuits for processing information, analog circuits for processing information, state machines, and / or other mechanisms for electronically processing information, such as field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs). Processor 104 may be a single entity or may include multiple processing units. These processing units may be physically located within the same device, or processor 104 may represent processing functionality of multiple devices or software functionality that operates separately or in conjunction.

[0032] The processor 104 may be configured to execute the machine-readable instructions 106 or the machine learning module through software, hardware, firmware, some combination of software, hardware and / or firmware, and / or other mechanisms for configuring processing capabilities on the processor 104. As used herein, the term "machine-readable instructions" may refer to any component or set of components that perform the functionality attributed to the machine-readable instruction component 106. This may include one or more physical processors 104, processor-readable instructions, circuits, hardware, storage media, or any other component during the execution of processor-readable instructions.

[0033] The server 102 may be configured with machine-readable instructions having one or more functional modules. The machine-readable instructions 106 may be implemented on one or more processors 102, and include one or more servers 104, and may access the memory 130. The machine-readable instructions 106 may be a single networked node or a machine cluster, which may include a distributed architecture of multiple networked nodes. The machine-readable instructions 106 may include control logic for implementing various functions, as described in more detail below. The machine-readable instructions 106 may include certain functions related to the system 100. In addition, the machine-readable instructions 106 may include smart contracts or multi-signature contracts that may process, read, and write data to a database, a distributed ledger, or a blockchain.

[0034] Figure 2 A schematic diagram of an automated workflow system 200 according to one or more embodiments of the present disclosure is shown. The automated workflow system 200 may include a document retrieval management system 202, a watchdog system 204, and an automated production system 206. Although some embodiments may be directed to identifying the root cause of a PTC brake event, the automated workflow system 200 may be used to automate workflows that identify the root cause of various types of events and systems, such as policy enforcement events, repeat offender notifications, and permission notification systems.

[0035] In one embodiment, the document retrieval management system 202 may include a file collection module 108, a message identification module 110, a log collection module 112, and an information parsing module 114. The file collection module 108, the file parsing module 110, the log collection module 112, and the information parsing module 114 may implement one or more algorithms to facilitate the retrieval of railway event files and logs of various systems, including status, selection, and authentication algorithms. The algorithm and its associated thresholds and / or signatures may be programmable to suit specific railway events, applications, functions, facilities, or other requirements. The document retrieval management system 202 may be configured to retrieve and modify files and logs (sent to a client or obtained from a client or server) associated with one or more mandatory events or other appropriate activities. In another embodiment, the document retrieval management system 202 may generate one or more elements for display on a user device. These elements may provide additional information related to the status of railway event management. For example, the document retrieval management system 202 may generate a notification and display it on the client to indicate file collection, log parsing, automated workflow initialization, railway event processing, errors, or other appropriate information. In addition, system symbols may be displayed on the client to indicate task, inspection, or analysis status.

[0036] The file collection module 108 may receive an incoming message regarding a railroad event notification. For example, a railroad event notification may include a mandatory event, such as a PTC brake event. In one embodiment, the file collection module 108 may receive an incoming message from a file retrieval manager (FRM). For example, the incoming message may correspond to one or more mandatory events. In another embodiment, the file collection module 108 may transmit an outgoing message to the FRM. For example, the outgoing message may request a system component log corresponding to one or more mandatory events. In another embodiment, the file collection module 108 may receive a notification indicating that a system component log is available.

[0037] In another embodiment, the file collection module 108 can generate an authentication token for a specific user, session, or request. In another embodiment, the file collection module 108 can access the network 140 without user credentials. In another embodiment, the file collection module 108 can generate an authentication token using user data stored on the client. For example, a user can access the client and / or the automated workflow system 200 by providing valid credentials through a login page or screen, and the valid credentials include a username and password, biometrics, multi-factor authentication, or other suitable credentials, which can be stored in the client or server along with the user's information (e.g., name, username, employee number, etc.). In another embodiment, the file collection module 108 can process at least a portion of the credentials and / or user information to generate an authentication token. For example, the authentication token can be generated as a JSON Web Token (JWT), through a dongle or key card, new authentication tokens can be generated periodically according to a known algorithm, using an authenticator application on the client or sent on demand via SMS, by hashing at least a portion of the login credentials, or other suitable methods.

[0038] In another embodiment, the authentication token may allow for single sign-on authentication from the client to the server and / or memory. In another embodiment, the file collection module 108 may operate without a user interface. In another example, the file collection module 108 may provide a user interface for a user to access the file collection module 108. The automated workflow system 200 may utilize the file collection module 108 to provide a user interface for receiving relevant data.

[0039] The message identification module 110 may classify incoming messages and notifications. In one embodiment, the message identification module 110 may receive information about mandatory events from the incoming messages and notifications. For example, the message identification module 110 may classify incoming messages as mandatory messages or status requests and classify notifications as log status. In another embodiment, the message identification module 110 may identify system component logs for mandatory events. For example, the message identification module 110 may identify characteristics of mandatory events. In another example, the characteristics may include the event time, the main CPU of the monitored train during the mandatory period, the corresponding component software version, a high-level system health scan, and other relevant characteristics. In another example, the message identification module 110 may verify the incoming message to identify whether the mandatory event actually occurred based on at least one characteristic.

[0040] The log collection module 112 may receive the system component log. In one embodiment, the system component log is sent from the FRM. In another embodiment, the log collection module 112 may download the system component log from an external memory. The system component log may correspond to a default onboard log set for at least one CPU on the train. The system component log may indicate characteristics of the braking event execution. In another embodiment, the log collection module 112 may store the system component log for future access.

[0041] The information parsing module 114 can parse incoming messages and notifications to obtain relevant information. For example, the relevant information can include information about a mandatory event. In another example, the incoming message can include information such as a user ID, onboard employee information, the employee requesting the information, the train location, and other relevant information. In one embodiment, the information parsing module 114 can establish a connection with a database. For example, the information parsing module 114 can receive incoming messages from a database and transmit relevant information to the database.

[0042] In one embodiment, the watchdog system 204 may include a log download module 116, an automated initialization module 118, and an automated workflow module 120. The log download module 116, the automated initialization module 118, and the automated workflow module 120 may implement one or more algorithms to monitor the status of system component logs, including file acquisition, event monitoring, and service enablement algorithms. The algorithms and their associated thresholds and / or signatures may be programmed to accommodate specific railway event monitoring systems, applications, functions, facilities, or other requirements. The watchdog system 204 may be configured to transmit and receive messages related to status monitoring or other appropriate activities to a client or server. In another embodiment, the watchdog system 204 may generate one or more elements to be displayed on the client. These elements may provide additional information related to workflow automation. For example, the watchdog system 204 may generate a notification and display it on the client to indicate a status update, system component log status, automated service startup, or other appropriate information. In addition, a system symbol may be displayed on the client to indicate the management status.

[0043] In one embodiment, the log download module 116 may query the internal service queue. For example, the internal service queue may be located at a certain IP address. In another example, the log download module 116 may query the internal service queue at a specified frequency. In another example, the specified frequency may include a value set by a user or a predetermined frequency. In another example, the predetermined frequency may include executing once every six minutes. In another embodiment, the log download module 116 may determine whether the internal service queue includes a new mandatory message. For example, the control logic 500 may prompt the internal service queue to notify the log download module 116 of any updated mandatory messages. If the internal service queue lacks a new mandatory message, the control logic 500 does not perform any operation. If the internal service queue includes a new mandatory message, the log download module 116 continues to generate a record. For example, the record may include a mandatory event set based on the mandatory message from the internal service queue. In another example, the log download module 116 may store the record in a database. In another embodiment, the log download module 116 may parse the file retrieval system to find a system component log corresponding to the new mandatory event. For example, the file retrieval system may include an FRM. In another example, the system component log may include a downloadable file.

[0044] In another embodiment, the log download module 116 can determine whether the system component log is available. For example, the log download module 116 can determine whether the system component log is available in the file retrieval system. In another example, the system component log may not be generated when the log download module 116 performs the check because the system component log may be lagging. If the system component log is not available, the log download module 116 repeats the check process after a period of time. For example, the time period can be 49 hours. If the system component log is available, the log download module 116 continues to receive the system component log. For example, the log download module 116 receives the system component log from the file retrieval system. In another example, the log download module 116 can receive the system component log in a downloadable manner. In another example, the log download module 116 can receive the system component log in a virtual manner (e.g., a cloud environment).

[0045] In another embodiment, the log download module 116 may update the status of the system component log in the record. For example, the log download module 116 may update the record to indicate whether the system component log is available. In one example, the log download module 116 may determine whether the system component log includes information about multiple CPUs on the train.

[0046] In one embodiment, the automation initialization module 118 can identify whether the automation service is being executed. For example, the automation initialization module 122 can determine whether the automation service is being executed on a specified server. In another example, the specified server can include a specified IP address. In another example, the automation initialization module 118 can determine whether the automation service is being executed based on the network traffic of the specified IP address, the network traffic of the specified server, or other methods. If the automation service is not currently being executed, the automation initialization module 118 can continue to execute the automation service. For example, the automation initialization module 122 can execute the automation service by executing the initialization instruction of the automation service. If the automation service is currently being executed, the automation initialization module 118 can continue to execute the automation process. For example, the automation process can include algorithms, applications, and functions from the automation production system 206. In another example, the algorithms, applications, and functions can include one or more of the extraction module 122, the analysis module 124, the event monitoring module 126, and the automation production module 128. In another example, the automation initialization module 118 can execute the automation process by executing the initialization instruction of the automation process.

[0047] The automated workflow module 120 may receive processed events. For example, the processed events may include results from an automated process. In another example, the processed events may include the root cause of a forced event. In another example, the automated workflow module 120 may receive processed events from a specified server. In another example, the automated workflow module 120 may store the processed events to an automated production server. In one embodiment, the automated workflow module 120 may generate a notification when the automated process is completed. For example, the notification may correspond to the results of the processed event. In another example, the automated workflow module 120 generates a notification for a set of stakeholders of the processed event. In another example, the automated workflow module 120 sends the notification to the stakeholders via email. In one embodiment, the automated workflow module 120 may transfer the event file to a completed directory. For example, the event file may include information about the processed event. In another example, the completed directory may include a specific file server corresponding to the processed event.

[0048] In one embodiment, the automated production system 206 may include an extraction module 122, an analysis module 124, an event monitoring module 126, and an automated production module 128. The extraction module 122, the analysis module 124, the event monitoring module 126, and the automated production module 128 may implement one or more algorithms to perform automated workflows and identify the root causes of train events, including extraction, analysis monitoring, and event monitoring algorithms. The algorithms and their associated thresholds and / or signatures may be programmed to accommodate specific railway event monitoring systems, applications, functions, facilities, or other requirements. The automated production system 206 may be configured to transmit and receive messages related to workflow automation or other appropriate activities to a client or server. In another embodiment, the automated production system 206 may generate one or more elements for display on a user device. These elements may provide additional information related to root cause analysis. For example, the automated production system 206 may generate a notification and display it on the client to indicate that the root cause has been identified, that the system component log, event monitoring, or other appropriate information has been extracted. In addition, system symbols may be displayed on the client to indicate event status, analysis completion, or identified root causes.

[0049] In one embodiment, the extraction module 122 may receive data from a file server. For example, the data may correspond to a system component log that includes a mandatory event signature. In another example, the file server may include a system component log from multiple mandatory events. In another embodiment, the extraction module 122 may collect data points before and after the mandatory event to generate a time window. For example, the data points may correspond to the system component log. In another example, the time window may include time measurements before, after, or both of the mandatory event. In another example, the time window may include seconds, minutes, or hours associated with the mandatory event. In another example, the extraction module 122 may compare the mandatory time to the data points to verify whether the mandatory event actually occurred.

[0050] In another embodiment, the extraction module 122 may tag the data with a unique identifier. For example, the extraction module 122 may tag the system component log according to the feature. In another embodiment, the extraction module 122 may determine whether the data is structured. For example, when the information in the data is classified in a predetermined manner, the data is structured. In another example, when the information in the data is classified in a manner different from the predetermined manner or is not classified at all, the data is unstructured. In another embodiment, when the data is unstructured, the extraction module 122 may identify the pattern of the unstructured data to convert the data into structured data and extract the data. For example, the extraction module 122 may use a data conversion software tool to convert the unstructured data into structured data. In another embodiment, when the data is structured, the extraction module 122 may extract the data. In another example, the extraction module 122 may extract the data using a regular expression. In another example, the regular expression may include a series of characters that define a search pattern. In another example, the extraction module 122 may extract the data using a data manipulation technique. In another example, the data manipulation technique may include using a commercial software tool (e.g., HADOOP) or developing a custom data tool in various programming languages. In another embodiment, the extraction module 122 transmits the extracted data to the analysis module 124 .

[0051] In one embodiment, the analysis module 124 may analyze the extracted data to generate an analysis result. For example, the analysis result may include whether the analysis module 124 has determined the root cause. In another example, the analysis module 124 may include multiple decision steps to determine whether the root cause is established. In another embodiment, the analysis module 124 may use a defect detection analysis model to analyze the extracted data. For example, the defect detection analysis model can identify when a defect occurs during the analysis process. In another example, when a defect occurs, the analysis module 124 can classify the defect into a root cause. In another example, when a defect does not occur, the analysis module 124 may use a historical analysis model to analyze the extracted data. In another example, the historical analysis model is based on historical data, such as previous engineer interactions, system component responses, and situational behaviors. In another example, the analysis module 124 may use a decision tree model, a classification model, or a clustering model to analyze the extracted data. In one embodiment, the analysis module 124, the event monitoring module 126, and the automated production module 128 may form an analysis model.

[0052] In one embodiment, one or more analysis thresholds can determine whether the automated workflow system 206 executes a single analysis model or multiple analysis models. Such adaptive analysis thresholds can change one or more features of the database. In addition, the analysis threshold is adaptive because the threshold can be changed based on historical data, data types, timestamps, or other relevant data. For example, the system can compare the first accuracy output by the first analysis model with a preset analysis threshold. The preset analysis threshold can include a user-defined accuracy value. Therefore, when the first analysis model outputs the first root cause of the penalty event, the system can verify whether the first root cause is the cause of the penalty event. In one example, when the first accuracy of the first root cause is lower than the preset analysis threshold, the system continues to execute the second analysis model.

[0053] By way of further example, when the second analysis model is executed, the second analysis model compares the historical data to the penalty event. The historical data may include data related to a particular locomotive, a fleet of locomotives, user-defined inputs, or certain other data related to the penalty event. If the system identifies that the historical data matches the penalty event, the system outputs a second root cause of the penalty event based on the historical data. The second root cause corresponds to a second accuracy. The system may compare the first accuracy of the first root cause to the second root cause to determine whether the two root causes are the same or different.

[0054] In another exemplary embodiment, the system may provide an analysis threshold when comparing the first accuracy and the second accuracy. For example, the system may compare the two accuracies based on the accuracy of subsequent measurements. The system may preliminarily compare the similarity of the two root causes, and when the two root causes are the same, the system may conclude that the similar root cause is the cause of the penalty event. At the time of the initial measurement, when one of the accuracies is above the analysis threshold, the accuracy above the analysis threshold may correspond to the root cause of the penalty event. When both accuracies are above the analysis threshold, the system may compare the similarity of the two root causes. If the two root causes are the same, the system determines that the similar root cause is the cause of the penalty event. If the two root causes are different, the system may perform another round of comparison. The second round of comparison may include various forms of comparison, such as measuring a higher accuracy, user intervention, re-running the analysis, or determining the root cause through some other form.

[0055] In one embodiment, the event monitoring module 126 may receive analysis results from the analysis module 124. In one embodiment, when the analysis results do not include a root cause, the event monitoring module 126 may generate a high-level classification for the forced event and assign a unique ID to the analysis results. For example, the high-level classification may include a message type, a message description, and a banner. In another example, the message type may be a warning issued to a train before a forced event. In another example, the message description may include a description of the warning, including information such as the forced event. In another example, the banner may be the last banner displayed to an engineer before the forced event. In another embodiment, when the analysis results include a root cause, the event monitoring module 126 may assign an alarm ID to the analysis results.

[0056] In one embodiment, the automated generation module 128 can transmit a detailed summary to the user. For example, the detailed summary can include multiple events, such as the time of train operation, the speed of the train during the execution of the train event, the detailed location of the train, the warning issued to the train, the detailed configuration of the train, the PTC component information, the type of forced and the type of braking event. In another example, the detailed summary can correspond to a unique ID or an alarm ID. In another example, the automated production module 128 can transmit the detailed summary via AES. In another example, the AES can include a list service of applicable users to be notified. In another embodiment, the automated production module 128 can generate output based on the user list and distribute notifications to users.

[0057] Figure 3An exemplary flow chart of an analysis model control logic 300 according to one or more exemplary embodiments of the present disclosure is shown. The analysis model control logic 300 can be implemented as an algorithm on the server 102, the machine learning module, the client, the database, or other suitable system. In addition, the analysis model control logic 300 can implement or include one or more functions of the automated production system 206, including the extraction module 122, the analysis module 124, the event monitoring module 126, and the automated production module 128. The analysis model control logic 300 can be implemented by software, hardware, API, network connection, network transmission protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or a suitable combination thereof.

[0058] The analysis model control logic 300 can take advantage of the computer platform's capabilities to generate multiple processes and threads by processing data simultaneously. By instantiating multiple processes to implement the analysis model, the speed and efficiency of the analysis model control logic 300 can be greatly improved. However, those skilled in the art of programming will recognize that a single processing thread may also be used and is within the scope of the present disclosure.

[0059] In one embodiment, the command or data may be received via user input generated on a client or server, such as a screen click, a swipe, a mouse click, a key press, a voice command, or other suitable mechanism. In another exemplary embodiment, the inspection command or data may include inspection data having one or more fields, parameters, characteristics, or metadata related to the inspection. The analysis model control logic 300 then proceeds to step 302.

[0060] In one embodiment of step 302, the control logic 300 may receive the extracted data. For example, the extracted data may correspond to a system component log including a mandatory event feature. In another embodiment, the extracted data may include data points before and after the mandatory event to generate a time window. For example, the data points may correspond to the system component log. In another example, the time window may include time measurements before, after, or both of the mandatory event. In another example, the time window may include seconds, minutes, or hours associated with the mandatory event. In another embodiment, the extracted data may include a tag with a unique identifier. For example, the extracted data may include a tag corresponding to the system component log according to the feature. In another embodiment, the extracted data may include structured data. For example, when the information in the data is classified in a predetermined manner, the data is structured. The control logic 300 proceeds to step 304.

[0061] In one embodiment of step 304, the control logic 300 may execute a first analysis model. For example, the control logic 300 may execute the first analysis model to obtain a first result. In another example, the first result may include whether the extracted data contains a root cause. In another example, the first analysis model may include multiple decision steps to determine whether the extracted data contains a root cause. For example, the decision steps may include multiple decisions corresponding to a specific environment. In one example, the specific environment may include a railway event management system containing a railway safety policy. In another example, the railway safety policy may include multiple steps, such as determining whether the brake signal stops, the quality of the signal, the distance of the locomotive from the target value, the speed of the locomotive, the lag time of the locomotive signal, the network quality index, the location of the locomotive, and other relevant safety factors.

[0062] In another example, the first analysis model may use a decision tree model, a classification model, a clustering model, a machine learning model, or other types of data analysis models to analyze the extracted data. In one example, the first analysis model may perform natural language processing (NLP) to analyze the extracted data to identify keywords to indicate the root cause. In one example, when the first analysis model is a machine learning model, the first analysis model may train the machine learning model based on historical data representing the safety conditions described by the railway safety measurement. In another example, the machine learning model may test the accuracy based on real-time data corresponding to at least one locomotive. In another example, the machine learning model may include a deep learning model, a recurrent neural network, an artificial neural network, or other types of machine learning models not limited to the foregoing. In another example, the machine learning model may perform the first analysis in a cloud-based environment. For example, the machine learning model may be executed as software as a service (SaaS), platform as a service (PaaS), infrastructure as a service (IaaS), or other related software-based environments. Control logic 300 proceeds to step 306.

[0063] In one embodiment of step 306 , the control logic 300 may identify defects in the extracted data. For example, the first analysis model may use a decision tree model to analyze the extracted data to identify the extracted data that causes at least one decision tree node to fail. The control logic 300 proceeds to step 308 .

[0064] In one embodiment of step 308 , the control logic 300 may assign a unique ID to the result of the analysis model. For example, the unique ID may include a globally unique ID (GUID). The control logic 300 proceeds to step 310 .

[0065] In one embodiment of step 310, control logic 300 may determine whether there is a defect in the first result. In another example, the defect detection analysis model may identify when a defect occurs during execution of the first analysis model. In another example, the first result may classify the defect as a root cause when the defect occurs. If there is a defect in the result, control logic 300 proceeds to step 318. If there is no defect in the result, control logic 300 proceeds to step 312.

[0066] In one embodiment of step 312, the control logic 300 may perform a second analysis model on the extracted data. For example, when the defect did not occur, the control logic 300 may use a historical analysis model to analyze the extracted data. In another example, the historical analysis model is based on historical data, such as previous engineer interactions, system component responses, and situational behaviors. In another example, the control logic 300 may perform a second analysis model on the extracted data to generate a second result. For example, the control logic 300 may compare the second result with the historical data to determine the accuracy of the second result. The control logic 300 proceeds to step 304.

[0067] In one embodiment of step 314 , the control logic 300 may assign another unique ID to the result of the second analysis model. For example, the unique ID may include another GUID. The control logic 300 proceeds to step 316 .

[0068] In one embodiment of step 316, the control logic 300 may compare the results of the first analysis model and the second analysis model to determine the root cause. For example, the control logic 300 may compare the first result and the second result to identify the root cause based on the user input. In one example, the user input may include a decision between the first result and the second result. The control logic 300 proceeds to step 318.

[0069] In one embodiment of step 318, the control logic 300 may identify the accuracy of the result. In another example, the control logic 300 may compare the first result and the second result and determine the most accurate result as the root cause. For example, the control logic 300 may assign weights to the first analysis model and the second analysis model based on the known accuracy of the first analysis model and the second analysis model. The control logic 300 proceeds to step 320.

[0070] In one embodiment of step 320, the control logic 300 may save the first result, the first unique ID, the second result, and the second unique ID. For example, the control logic 300 may save the result and the unique ID in a database according to a mandatory event corresponding to the extracted data.

[0071] Figure 4A An exemplary flow chart of an analysis decision tree control logic 400 according to one or more exemplary embodiments of the present disclosure is shown. The analysis decision tree control logic 400 can be implemented as an algorithm on the server 102, the machine learning module, the client, the database, or other suitable system. In addition, the analysis model control logic 300 can implement or include one or more functions of the automated production system 206, including the extraction module 122, the analysis module 124, the event monitoring module 126, and the automated production module 128. The analysis decision tree control logic 400 can be implemented by software, hardware, API, network connection, network transmission protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or a suitable combination thereof.

[0072] The analysis decision tree control logic 400 can take advantage of the capabilities of the computer platform to generate multiple processes and threads by processing data simultaneously. By instantiating multiple processes to implement the analysis decision tree control logic, the speed and efficiency of the analysis decision tree control logic 400 can be greatly improved. However, those skilled in the art of programming will recognize that a single processing thread may also be used and this is within the scope of the present disclosure.

[0073] In one embodiment, the command or data may be received via user input generated on a client or server, such as a screen click, a swipe, a mouse click, a key press, a voice command, or other suitable mechanism. In another exemplary embodiment, the inspection command or data may include inspection data having one or more fields, parameters, characteristics, or metadata related to the inspection. Then, the analysis decision tree control logic 400 proceeds to step 402.

[0074] In one embodiment of step 402, the control logic 400 may determine whether the signal requires the locomotive to stop based on the extracted data. For example, the signal may correspond to a communication between the locomotive and at least one network node in response to a forced event. In one example, the extracted data may include information and parameters corresponding to the signal and the forced event (e.g., a PTC braking event). In one example, the extracted data may correspond to a system log component of the forced event. In another example, the control logic 400 may identify characteristics of the forced event. For example, the characteristics may include the event time, the main CPU of the train monitored during the forced period, the corresponding component software version, the high-level system health scan, and other relevant characteristics. In another example, the control logic 400 may receive a signal from a file retrieval manager (FRM). If the signal requires the locomotive to stop, the control logic 400 proceeds to step 404. If the signal does not require the locomotive to stop, the control logic 400 proceeds to step 406.

[0075] In one embodiment of step 404, the control logic 400 may execute a decision tree branch corresponding to the locomotive stop signal, as described in detail below. Figure 4B .

[0076] In one embodiment of step 406, the control logic 400 may determine whether the signal is unknown based on the extracted data. For example, the extracted data may include a list of historical signal values ​​to determine how the signal changes over time. In one example, the control logic 400 may compare the signal to known signals under multiple historical states to determine whether the signal matches any known signal. In another example, the control logic 400 may determine the state of the signal at any time before the forcing event. If the signal is unknown, the control logic 400 proceeds to step 408. If the signal is known, the control logic 400 proceeds to step 430.

[0077] In one embodiment of step 408, the control logic 400 may determine whether the signal changes from a known value to an unknown value based on the extracted data. For example, the extracted data may include a list of historical signal values ​​to determine whether the signal changes over time. In one example, the control logic 400 may compare the signal to the list of historical signal values ​​to determine whether the signal changes from a known value to an unknown value. In another example, the control logic 400 may determine the state of the signal at any time before the forcing event. If the signal changes from a known value to an unknown value, the control logic 400 proceeds to step 410. If the signal does not change from a known value to an unknown value, the control logic 400 has not detected a defect and the decision tree terminates.

[0078] In one embodiment of step 410, the control logic 400 may determine whether the state of the signal has changed based on the extracted data. For example, the extracted data may include information corresponding to a historical state list to determine whether the state of the signal has changed. In one example, the control logic 400 may compare the historical state list with the state of the signal to determine whether the state has changed. If the state of the signal has changed, the control logic 400 proceeds to step 412. If the state of the signal has not changed, the control logic 400 has not detected a defect and the decision tree terminates.

[0079] In one embodiment of step 412, the control logic 400 may determine whether the distance between the locomotive and the target location is less than a predetermined distance based on the extracted data. For example, the extracted data may include distance information about the locomotive location. In one example, the predetermined distance may include a user-defined distance, a distance calculated based on a safety protocol, or other measurement value. In another example, the control logic 400 may compare the distance between the locomotive and the target location to determine whether the distance between the locomotive and the target location is less than the predetermined distance before or during the forcing event. If the distance between the locomotive and the target location is less than the predetermined distance, the control logic 400 proceeds to step 416. If the distance between the locomotive and the target location is greater than the predetermined distance, the control logic 400 proceeds to step 414.

[0080] In one embodiment of step 414, the control logic 400 may determine whether the speed of the locomotive is greater than a predetermined speed based on the extracted data. For example, the extracted data may include speed information of the locomotive. In another example, the predetermined speed may include a user-defined value, a speed calculated based on a safety protocol, or other measured value. In another example, the control logic 400 may compare the speed of the locomotive with the predetermined speed to determine whether the speed of the locomotive is greater than the predetermined speed before or during the forcing event. If the speed of the locomotive is greater than the predetermined speed, the control logic 400 proceeds to step 426. If the speed of the locomotive is less than the predetermined speed, the control logic 400 proceeds to step 428.

[0081] In one embodiment of step 416, the control logic 400 may determine whether the signal state change is delayed based on the extracted data. For example, the extracted data may include information corresponding to the historical state list to determine whether the signal state has changed. In one example, the control logic 400 may compare the historical state list with the state of the signal to determine whether the state has changed. In another example, the signal state change may include a signal change from a known value to an unknown value, a signal change from a known value to other known values, a signal change from an unknown value to a known value, or a combination of any other values ​​indicating a state change. In one example, the state change may be delayed based on poor communication quality between the locomotive and at least one network node, a hardware or software failure of the locomotive or at least one network node, or other delay reasons. If the signal state change is delayed, the control logic 400 proceeds to step 420. If the signal state change is not delayed, the control logic 400 proceeds to step 418.

[0082] In one embodiment of step 418, the control logic 400 may determine whether the application gateway is accessible based on the extracted data. For example, the extracted data may include network information between the locomotive and at least one network node corresponding to the application gateway. In another example, the extracted data may include the status of the application gateway, indicating whether the application gateway is accessible during the mandatory event. In one example, the application gateway may include a specific IP address that identifies the application gateway. In another example, the control logic 400 may identify the accessibility of the application gateway before or during the mandatory event to determine whether the application gateway is accessible. If the application gateway is accessible, the control logic 400 proceeds to step 424. If the application gateway is not accessible, the control logic 400 proceeds to step 422.

[0083] In one embodiment of step 420, the control logic 400 may classify the defect as a locomotive selecting a train track that is too close to a switch based on the extracted data. For example, the extracted data may include travel information corresponding to the locomotive. In one example, the locomotive may select a specific train track to travel. The train track includes an area containing at least one switch. At least one switch is a device that can guide a train from one track to another, such as at a railway intersection. In one example, the control logic 400 may compare a predetermined path with a specific route of the train track to determine whether the selected train track is too close to a switch. When the train track selected by the locomotive is too close to a switch, a forced event is triggered.

[0084] In one embodiment of step 422, the control logic 400 may classify the defect as a communication problem between the locomotive and at least one network node based on the extracted data. For example, the extracted data may include network information between the locomotive and the at least one network node. In one example, the locomotive may communicate with the at least one network node while traveling. For example, the locomotive may communicate using a variety of communication methods, such as a wireless communication system using a standard communication protocol (e.g., TCP / IP, MAC, HTTP, etc.). In another example, the control logic 400 may determine a communication problem between the locomotive and the at least one network node. When there is a communication problem, a forced event is activated.

[0085] In one embodiment of step 424, the control logic 400 may classify the defect as an application gateway problem that causes a communication delay between the locomotive and at least one network node based on the extracted data. For example, the extracted data may include network information between the locomotive and at least one network node. In one example, the locomotive may communicate with at least one network node while traveling. The locomotive may communicate using a variety of communication methods, such as a wireless communication system using a standard communication protocol (e.g., TCP / IP, MAC, HTTP, etc.). In another example, the control logic 400 may determine that there is an application gateway problem between the locomotive and at least one network node. When the signal cannot establish a connection with the application gateway and the application gateway is not functioning properly, a forced event is activated.

[0086] In one embodiment of step 426, the control logic 400 may classify the defect as a locomotive speed greater than a predetermined speed based on the extracted data. For example, the extracted data may include speed information of the locomotive. In another example, the predetermined speed may include a user-defined value, a speed calculated based on a safety protocol, or other measured value. In another example, the control logic 400 may compare the speed of the locomotive to the predetermined speed to determine whether the speed of the locomotive is greater than the predetermined speed before or during the forcing event. When the speed of the locomotive is greater than the predetermined speed, the forcing event is triggered.

[0087] In one embodiment of step 428, the control logic 400 may classify the defect as the locomotive selecting the wrong track based on the extracted data. For example, the extracted data may include a suggested route for the locomotive. In one example, the locomotive may select a track that is contiguous with the route of travel. For example, for travel convenience, reduced travel time, or other reasons, the locomotive may select one track instead of another track. In one example, the locomotive may select the wrong track that is contiguous with the route of travel. In one example, the control logic 400 may compare the suggested route with the route of travel to determine whether the locomotive has selected the wrong track. When the locomotive selects the wrong track, a forced event is triggered.

[0088] In one embodiment of step 430, the control logic 400 may determine whether the locomotive is approaching a work zone. For example, the extracted data may include location information identifying the work zone. In one example, when the locomotive is traveling near the work zone, the locomotive may travel according to safety conditions. For example, the locomotive may travel at a reduced speed, travel along a path farthest from the work zone, or use another method to handle approaching the work zone. In one example, the control logic 400 may compare the location of the locomotive with the work zone to determine whether the locomotive is approaching the work zone. If the locomotive is approaching the work zone, the control logic 400 determines that no defects are detected. If the locomotive is not approaching the work zone, the control logic 400 proceeds to step 432.

[0089] In one embodiment of step 432, the control logic 400 may determine whether the locomotive is traveling using an unknown switch based on the extracted data. For example, the extracted data may include track information of the locomotive, indicating multiple switches on the route. In one example, the locomotive may select a specific train track to travel. For example, the train track includes an area containing at least one switch, and the switch is used to guide the locomotive from one track to another track, such as at a railway intersection. In one example, the control logic 400 may compare multiple switches with an unknown switch to determine whether the locomotive is traveling using an unknown switch. If the locomotive selects an unknown switch, the control logic 400 determines that no defects are detected. If the locomotive selects a known switch, the control logic 400 proceeds to step 434.

[0090] In one embodiment of step 434, the control logic 400 may determine whether the turnouts on the route are not aligned to ensure safe movement based on the extracted data. For example, the extracted data may include track information corresponding to the locomotive to indicate multiple turnouts on the route. In one example, the locomotive may select a specific train track to travel. For example, the train track includes an area containing at least one turnout, and the turnout is used to guide the locomotive from one track to another track, such as at a railway intersection. In one example, the control logic 400 may compare the turnouts on the route with normal turnouts to identify whether the turnouts are not aligned to ensure safe movement. If the turnouts are not aligned to ensure safe movement, the control logic 400 determines that no defects are detected. If the turnouts are aligned to ensure safe movement, the control logic 400 determines that no defects are detected.

[0091] Figure 4B An exemplary flow chart of an analysis decision tree control logic 450 according to one or more exemplary embodiments of the present disclosure is shown. The analysis decision tree control logic 450 can be implemented as an algorithm on the server 102, the machine learning module, the client, the database, or other suitable system. In addition, the analysis model control logic 300 can implement or include one or more functions of the automated production system 206, including the extraction module 122, the analysis module 124, the event monitoring module 126, and the automated production module 128. The analysis decision tree control logic 450 can be implemented by software, hardware, API, network connection, network transmission protocol, HTML, DHTML, JavaScript, Dojo, Ruby, Rails, other suitable applications, or a suitable combination thereof.

[0092] The analysis decision tree control logic 450 can take advantage of the capabilities of the computer platform to generate multiple processes and threads by processing data simultaneously. By instantiating multiple processes to implement the analysis decision tree, the speed and efficiency of the analysis decision tree control logic 450 can be greatly improved. However, those skilled in the art of programming will recognize that a single processing thread may also be used and this is within the scope of the present disclosure.

[0093] In an exemplary embodiment, the command or data may be received via user input generated on a client or server, such as a screen click, a swipe, a mouse click, a key press, a voice command, or other suitable mechanism. In another exemplary embodiment, the inspection command or data may include inspection data having one or more fields, parameters, characteristics, or metadata related to the inspection. The analysis decision tree control logic 450 then proceeds to step 404.

[0094] In one embodiment of step 404, the control logic 450 may execute a decision tree branch corresponding to a signal requiring the locomotive to stop based on the extracted data. For example, the signal may correspond to a communication between the locomotive and at least one network node in response to a forced event. In one example, the extracted data may include information and parameters corresponding to the signal and the forced event (e.g., a PTC braking event). In one example, the extracted data may correspond to a system log component of the forced event. In another example, the control logic 450 may identify characteristics of the forced event. For example, the characteristics may include the event time, the main CPU monitoring the train during the forced period, the corresponding component software version, a high-level system health scan, and other relevant characteristics. In another example, the control logic 450 may receive a signal from the FRM. The control logic 450 proceeds to step 452.

[0095] In one embodiment of step 452, the control logic 450 may determine whether the signal changes from a known value to a stop instruction based on the extracted data. For example, the extracted data may include a list of historical signal values ​​to determine whether the signal changes over time. In one example, the control logic 450 may compare the signal to the list of historical signal values ​​to determine whether the signal changes from a known value to an unknown value. In another example, the control logic 450 may determine the state of the signal at any time before the forcing event. If the signal changes from a known value to a stop instruction, the control logic 450 proceeds to step 454. If the signal does not change from a known value to a stop instruction, the control logic 450 proceeds to step 460.

[0096] In one embodiment of step 454, the control logic 450 may determine whether a fault exists and is valid based on the extracted data. For example, the extracted data may include fault information for a forced event. In one example, the fault information may indicate whether the forced event is in response to one or more faults, such as a signal loss or a brake error. In another example, when the fault still exists after the forced event occurs, the fault may be in an active state. If the fault exists and is valid, the control logic 450 proceeds to step 458. If the fault does not exist or is invalid, the control logic 450 proceeds to step 456.

[0097] In one embodiment of step 456, the control logic 450 may classify the defect as a signal loss based on the extracted data. For example, the extracted data may include information indicating the state of the signal. In one example, the state of the signal may indicate a current state, a previous state, a historical state value, and other state indicators. In another example, if the locomotive is unable to establish or maintain a connection with one or more network elements, the signal may be lost. In one example, the control logic 450 may identify when the signal is lost. When the signal is lost, a forced event is activated.

[0098] In one embodiment of step 458, the control logic 450 may classify the defect as a brake error based on the extracted data. For example, the extracted data may include information indicating the operability of the brake system on the locomotive. In one example, a brake error may occur because the locomotive is unable to apply the brake system. In another example, the control logic 450 may identify when a brake error occurs. When a brake error occurs, a forcing event is activated.

[0099] In one embodiment of step 460, the control logic 450 may determine whether the signal state changes from an unknown value to a stop instruction based on the extracted data. For example, the extracted data may include information corresponding to a historical state list to determine whether the signal state changes. In one example, the control logic 450 may compare the historical state list with the signal state to determine whether the state changes. If the signal state changes from an unknown value to a stop instruction, the control logic 450 proceeds to step 470. If the signal state does not change from an unknown value to a stop instruction, the control logic 450 proceeds to step 462.

[0100] In one embodiment of step 462, the control logic 450 may determine, based on the extracted data, whether the speed of the locomotive at a certain distance from the target is greater than a target speed. For example, the extracted data may include speed information of the locomotive. In another example, the predetermined speed may include a user-defined value, a speed calculated based on a safety protocol, or other measured value. In another example, the control logic 450 may compare the speed of the locomotive with the predetermined speed to determine whether the speed of the locomotive is greater than the predetermined speed before or during the forcing event. If the speed of the locomotive at the certain distance from the target is greater than the target speed, the control logic 450 proceeds to step 490. If the speed of the locomotive at the certain distance from the target is less than the target speed, the control logic 450 proceeds to step 464.

[0101] In one embodiment of step 464, the control logic 450 may determine whether the warning value is greater than the target warning value based on the extracted data. For example, the extracted data may include a warning received by the locomotive in response to a mandatory event. In one example, the target warning value may correspond to the warning received by the locomotive. In another example, the warning received by the locomotive may include a locomotive deceleration warning, a warning to change the locomotive's driving trajectory, a warning indicating poor communication quality, and the like. If the warning value is greater than the target warning value, the control logic 450 proceeds to step 492. If the warning value is less than the target warning value, the control logic 450 proceeds to step 466.

[0102] In one embodiment of step 466, the control logic 450 may determine whether a fault is detected based on the extracted data. For example, the extracted data may include fault information for the forced event. In one example, the fault information may indicate whether the forced event is in response to one or more faults, such as improper train handling or brake calculation failure. If a fault is detected, the control logic 450 proceeds to step 494. If no fault is detected, the control logic 450 proceeds to step 468.

[0103] In one embodiment of step 468, the control logic 450 may classify the defect as improper locomotive operation based on the extracted data. For example, the extracted data may include locomotive operation information. In one example, the operation information may include a quality value of the staff on the locomotive handling professional events. For example, the quality value may include the cumulative amount of handling professional events, such as daily maintenance, inspection, or locomotive driving. In another example, the staff may include parking engineers, locomotive drivers, and other professional members. In another example, the control logic 450 may compare the operation information with conventional operating activities to determine whether there is improper locomotive operation. When the locomotive is improperly operated, a mandatory event is triggered.

[0104] In one embodiment of step 470, the control logic 450 may determine whether the state of the locomotive has changed from the disengaged state to the active state based on the extracted data. For example, the extracted data may include the historical state of the locomotive to determine whether the state of the locomotive has changed. In one example, the state of the locomotive may change based on the driving state. For example, when the locomotive is moving, the driving state may indicate that the state of the locomotive is the active state. Alternatively, when the locomotive is stationary, the driving state may indicate that the state of the locomotive is the disengaged state. In another example, the control logic 450 may compare the state of the locomotive with the active state to determine whether the state of the locomotive has changed. If the state of the locomotive has changed from the disengaged state to the active state, the control logic 450 proceeds to step 480. If the state of the locomotive has not changed from the disengaged state to the active state, the control logic 450 proceeds to step 472.

[0105] In one embodiment of step 472, the control logic 450 may determine, based on the extracted data, whether the speed of the locomotive at a certain distance from the target is less than a target speed. For example, the extracted data may include speed information of the locomotive. In another example, the predetermined speed may include a user-defined value, a speed calculated based on a safety protocol, or other measured value. In another example, the control logic 450 may compare the speed of the locomotive with a predetermined speed to determine whether the speed of the locomotive is greater than the predetermined speed before or during the forcing event. If the speed of the locomotive at a certain distance from the target is less than the target speed, the control logic 450 proceeds to step 484. If the speed of the locomotive at a certain distance from the target is greater than the target speed, the control logic 450 proceeds to step 474.

[0106] In one embodiment of step 474, the control logic 450 may determine whether the warning value is greater than the target warning value based on the extracted data. For example, the extracted data may include a warning received by the locomotive corresponding to a mandatory event. In one example, the target warning value may correspond to the warning received by the locomotive. In another example, the warning received by the locomotive may include a locomotive deceleration warning, a warning to change the locomotive's driving trajectory, a warning indicating poor communication quality, and the like. In another example, the control logic 450 may compare the warning value with the target warning value to determine whether the warning value is greater than the target warning value. If the warning value is greater than the target warning value, the control logic 450 proceeds to step 486. If the warning value is less than the target warning value, the control logic 450 proceeds to step 476.

[0107] In one embodiment of step 476, the control logic 450 may determine whether a fault is detected based on the extracted data. For example, the extracted data may include fault information for the forced event. In one example, the fault information may indicate whether the forced event is in response to one or more faults, such as improper train handling or brake calculation failure. If a fault is detected, the control logic 450 proceeds to step 488. If no fault is detected, the control logic 450 proceeds to step 478.

[0108] In one embodiment of step 478, the control logic 450 may classify the defect as improper locomotive operation based on the extracted data. For example, the extracted data may include locomotive operation information. In one example, the operation information may include a quality value of the staff on the locomotive handling professional events. For example, the quality value may include the cumulative amount of handling professional events, such as daily maintenance, inspection, or locomotive driving. In another example, the staff may include parking engineers, locomotive drivers, and other professional members. In another example, the control logic 450 may compare the operation information with conventional operating activities to determine whether there is improper locomotive operation. When the locomotive is improperly operated, a mandatory event is triggered.

[0109] In one embodiment of step 480, the control logic 450 may determine whether the locomotive has reselected a track based on the extracted data. For example, the extracted data includes track information to determine the travel path of the locomotive. In one example, the control logic 450 may determine whether the locomotive has reselected a track in response to the locomotive changing the travel path. In one example, the travel path may include a predetermined path based on the locomotive's starting point and end point. In another example, the control logic 450 may compare the locomotive's travel path with the predetermined path to determine whether the locomotive has reselected a track. If the locomotive has reselected a track, the control logic 450 proceeds to step 480. If the locomotive has not reselected a track, the control logic 450 determines that no defect has been detected.

[0110] In one embodiment of step 482, the control logic 450 may classify the defect as a signal loss based on the extracted data. For example, the extracted data may include information indicating the state of the signal. In one example, the state of the signal may indicate a current state, a previous state, a historical state value, and other state indicators. In another example, if the locomotive cannot establish or maintain a connection with one or more network elements, the signal may be lost. In another example, the control logic 450 may compare the signal with a normal signal to determine whether the signal is lost. When the signal is lost, a forced event will be activated.

[0111] In one embodiment of step 484, the control logic 450 may classify the defect as a locomotive fault based on the extracted data. For example, the extracted data may include fault information corresponding to a locomotive function. In one example, the fault information may include a system operating capability of a system on the locomotive or a portion of the locomotive. For example, a system on the locomotive or a portion of the locomotive may include a mechanical system, an electrical system, a combination of a mechanical system and an electrical system, or other systems. In another example, the control logic 450 may compare the fault information with normal operation to determine whether a fault exists. When a fault exists, a forced event is activated.

[0112] In one embodiment of step 486, the control logic 450 may classify the defect as a warning being ignored based on the extracted data. For example, the extracted data may include warning information corresponding to at least one warning received by the locomotive in response to the mandatory event. In one example, the warning information may indicate whether the locomotive crew noticed the at least one warning. In another example, the control logic 450 may identify when the crew ignored the warning. When the warning is ignored, the mandatory event is activated.

[0113] In one embodiment of step 488, the control logic 450 may classify the defect as a brake calculation fault based on the extracted data. For example, the extracted data may include brake system information corresponding to the locomotive. In one example, the application of the brake system by the locomotive beyond a predetermined braking threshold may cause a brake calculation fault. For example, the predetermined braking threshold may include a minimum distance that the locomotive can achieve by applying the braking system to maintain a safe environment. In another example, the predetermined braking threshold may correspond to a travel distance calculated based on locomotive parameters. In another example, the control logic 450 may compare the brake system information to the predetermined braking threshold to determine whether a brake calculation fault exists. When a brake calculation fault exists, a forced event is activated.

[0114] In one embodiment of step 490, the control logic 450 may classify the defect as a locomotive fault based on the extracted data. For example, the extracted data may include fault information corresponding to a locomotive function. In one example, the fault information may include a system operating capability of a system on the locomotive or a portion of the locomotive. For example, a system on the locomotive or a portion of the locomotive may include a mechanical system, an electrical system, a combination of a mechanical system and an electrical system, or other systems. In another example, the control logic 450 may compare the fault information with normal operation to determine whether a fault exists. When a fault exists, a forced event is activated.

[0115] In one embodiment of step 492, the control logic 450 may classify the defect as a warning being ignored based on the extracted data. For example, the extracted data may include warning information corresponding to at least one warning received by the locomotive in response to the mandatory event. In one example, the warning information may indicate whether the locomotive crew noticed the at least one warning. In another example, the control logic 450 may identify when the crew ignored the warning. When the warning is ignored, the mandatory event is activated.

[0116] In one embodiment of step 494, the control logic 450 may classify the defect as a brake calculation fault based on the extracted data. For example, the extracted data may include brake system information corresponding to the locomotive. In one example, the application of the brake system by the locomotive beyond a predetermined braking threshold may cause a brake calculation fault. For example, the predetermined braking threshold may include a minimum distance that the locomotive can achieve by applying the braking system to maintain a safe environment. In another example, the predetermined braking threshold may correspond to a travel distance calculated based on locomotive parameters. In another example, the control logic 450 may compare the brake system information with the predetermined braking threshold to determine whether a brake calculation fault exists. When a brake calculation fault exists, a forced event is activated.

[0117] The present disclosure achieves at least the following advantages:

[0118] 1. Perform root cause analysis on various types of data structures using an automation engine;

[0119] 2. Improve the efficiency of inspectors performing root cause analysis by automating the execution workflow;

[0120] 3. Enable accurate detection of train events (e.g. PTC braking events) and identification of the root causes of such events; and

[0121] 4. Provide an analytical framework to perform root cause analysis using data extraction and analytical models.

[0122] Those skilled in the art will readily appreciate that without the specific combination of computer hardware and other structural components and mechanisms assembled in the system of the present invention and described herein, the above advantages and purposes will not be possible to achieve. In addition, the algorithms, methods and processes disclosed herein improve and convert any general-purpose computer or processor disclosed in this specification and the accompanying drawings into a special-purpose computer, which is programmed to execute the disclosed algorithms, methods and processes to achieve the above functions, advantages and goals. It should also be understood that for those who are proficient in this field, there are a variety of programming tools that can be used to generate and implement the functions and operations described above. In addition, the selection of a specific programming tool may be determined by the specific goals and constraints of implementing these concepts, which are selected to implement the concepts proposed in this article and the appended claims.

[0123] The description in this patent document should not be construed as implying that any particular element, step, or function is an essential or critical element that must be included within the scope of the claims. Furthermore, unless the exact words "means for" or "step for" are expressly used in a particular claim and followed by a participle phrase identifying the function, no claim is intended to invoke 35 U.S.C. §112(f) for any additional claim or claim element. Terms used in the claims (such as (but not limited to) "mechanism", "module", "device", "unit", "component", "element", "member", "device", "machine", "system", "processor", "processing device", or "controller") should be understood and intended to refer to structures known to those skilled in the relevant art and are further modified or enhanced by the features of the claims themselves, and are not intended to invoke 35 U.S.C. §112(f).

[0124] The present disclosure may be embodied in other specific forms without departing from its spirit or essential features. For example, each new structure described herein may be modified to accommodate specific local changes or requirements while retaining their basic configuration or structural relationship to each other, or while performing the same or similar functions described herein. Therefore, the present embodiments should be considered illustrative rather than restrictive in all respects. Therefore, the scope of the invention should be determined by the appended claims rather than by the foregoing description. Therefore, all changes within the meaning and equivalent scope of the claims should be included in the claims. In addition, the various elements in the claims are not well-known, conventional or traditional. Instead, the claims point to the non-traditional innovative concepts described in the specification.

Claims

1. A system for performing root cause analysis, comprising: The database includes storage of system component logs for root cause determination; as well as A networked computer processor operatively coupled to a memory and capable of executing machine-readable instructions to perform program steps comprising: receiving the extracted data; executing a first analytical model using the extracted data to generate a first result, and assigning a first unique ID to the first result; If a defect is detected according to the first analysis model, the defect is classified as a root cause; If the defect is not detected according to the first analysis model, executing a second analysis model using the extracted data to generate a second result, assigning a second unique ID to the second result, and comparing the first result with the second result to determine the most accurate result as the root cause; Generates a report indicating the root cause; and The first result, the first unique ID, the second result, and the second unique ID are stored.

2. The system of claim 1, wherein the first analytical model comprises decision tree logic.

3. The system of claim 1, wherein the first analysis model comprises a classification model.

4. The system of claim 1, wherein the first analytical model comprises a clustering model.

5. The system of claim 1, wherein the second analytical model comprises a historical analytical model based on historical data (eg, previous engineer interactions, system component responses, and situational behaviors).

6. The system of claim 1, wherein the first analysis model comprises a machine learning algorithm, or the second analysis model comprises a machine learning algorithm.

7. The system of claim 1, wherein the program steps further include comparing the second result to historical classification data to determine the accuracy of the second result.

8. The system of claim 1, wherein the program steps further include determining the most accurate reason based on user input.

9. A method for automating a workflow and performing root cause analysis of a data structure, comprising: receiving the extracted data; executing a first analytical model using the extracted data to generate a first result, and assigning a first unique ID to the first result; If a defect is detected according to the first analysis model, the defect is classified as a root cause; If the defect is not detected according to the first analysis model, executing a second analysis model using the extracted data to generate a second result, assigning a second unique ID to the second result, and comparing the first result with the second result to determine the most accurate result as the root cause; Generates reports indicating root causes; as well as The first result, the first unique ID, the second result, and the second unique ID are stored.

10. The method of claim 9, wherein the first analytical model comprises decision tree logic.

11. The method of claim 9, wherein the first analysis model comprises a classification model.

12. The method of claim 9, wherein the first analytical model comprises a clustering model.

13. The method of claim 9, wherein the second analytical model comprises a historical analytical model based on historical data (eg, previous engineer interactions, system component responses, and situational behaviors).

14. The method of claim 9, wherein the first analysis model comprises a machine learning algorithm, or the second analysis model comprises a machine learning algorithm.

15. The method of claim 9, wherein the program step further comprises comparing the second result to historical classification data to determine the accuracy of the second result.

16. The method of claim 9, wherein the program step further comprises determining the most accurate reason based on user input.

17. A computer-implemented method for automating workflows and performing root cause analysis of data structures, comprising: receiving the extracted data; executing a first analytical model using the extracted data to generate a first result, and assigning a first unique ID to the first result; If a defect is detected according to the first analysis model, the defect is classified as a root cause; If the defect is not detected according to the first analysis model, executing a second analysis model using the extracted data to generate a second result, assigning a second unique ID to the second result, and comparing the first result with the second result to determine the most accurate result as the root cause; Generates reports indicating root causes; as well as The first result, the first unique ID, the second result, and the second unique ID are stored.

18. The method of claim 16, wherein the first analytical model comprises decision tree logic.

19. The method of claim 16, wherein the first analysis model comprises a classification model.

20. The method of claim 16, wherein the first analytical model comprises a clustering model.

21. The method of claim 16, wherein the second analytical model comprises a historical analytical model based on historical data (eg, previous engineer interactions, system component responses, and situational behaviors).

22. The method of claim 16, wherein the first analysis model comprises a machine learning algorithm, or the second analysis model comprises a machine learning algorithm.

23. The method of claim 16, wherein the program step further comprises comparing the second result to historical classification data to determine the accuracy of the second result.

24. The method of claim 16, wherein the program step further comprises determining the most accurate reason based on user input.

Images