AU2019447961B2

AU2019447961B2 - Train control system, train control device, and train control method

Info

Publication number: AU2019447961B2
Application number: AU2019447961A
Authority: AU
Inventors: Nikhil ADKAR; Andrew Ellison
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2019-05-31
Filing date: 2019-05-31
Publication date: 2023-07-13
Anticipated expiration: 2039-05-31
Also published as: JP2022536059A; JP7174172B2; EP3976441A4; WO2020240862A1; EP3976441A1; AU2019447961A1

Abstract

The present invention relates to a train control system in a distributed computing environment. The train control system may include a train control server configured to communicate with one or more trains via a communication network. The train control server may include a parameter management unit configured to select, from a parameter file database, a first set of train parameters based on the first set of train data from the parameter file database, a communication unit configured to transmit the first set of train parameters to the first set of trains and receive a set of parameter setting confirmation data from the first set of trains, and a verification unit configured to verify that the set of parameter setting confirmation data achieves a consistency level with respect to the parameter file database.

Description

TRAIN CONTROL SYSTEM, TRAIN CONTROL DEVICE, AND TRAIN CONTROL METHOD

The present disclosure relates to a train control system, a train control device, and a train control method.

In recent years, the complexity of train control systems continues to increase, having evolved from early fixed block wayside technologies to fixed block cab-signaling technologies, and most recently to communications based train control (CBTC) technologies. As the complexity of train control systems increases, so too does the demand for greater flexibility in train control system implementations.

Distributed computing environments offer one method of increasing the flexibility of train control systems. For example, US 2015/0232110 A1 describes a method and an apparatus for a train control system that utilizes a virtualization of train control logic and cloud computing resources in which “A train control system is configured into two main parts. The first part includes physical elements of the train control system, and the second part includes a virtual train control system that provides the computing resources for the required train control application platforms. The disclosed architecture can be used with various train control technologies, including communications based train control, cab-signaling and fixed block, wayside signal technology. Further, the disclosure describes methodologies to convert cab-signaling and manual operations into distance to go operation” (Patent Document 1).

[Patent Document 1] US 2015/0232110 A1

Patent Document 1 discloses a method and apparatus for virtualizing train control elements, and utilizing cloud computing resources to facilitate train control management. However, Patent Document 1 does not disclose the dynamic updating of train parameters in real time and the subsequent verification of train parameter integrity to ensure safe and efficient train operation.

Accordingly, aspects of the present disclosure relate to selecting appropriate train parameters for a train based on data for a target train, dynamically updating an onboard (OBU) unit of the train in real time using the selected parameters, and verifying the integrity of the parameters set in the OBU.

One embodiment of the present invention relates to a train control system in a distributed computing environment, wherein the improvement comprises a train control server configured to communicate with one or more trains via a communication network, the train control server including a parameter management unit configured to store a parameter file database that manages a plurality of train parameters for a plurality of trains, a train parameter verification unit configured to verify a consistency level of a set of train parameters, and a communication unit configured to perform communication between the parameter management unit and a first set of trains, wherein the parameter management unit is configured to select, in response to receiving a first set of train data associated with the first set of trains, a first set of train parameters based on the first set of train data from the parameter file database, the communication unit is configured to transmit the first set of train parameters to the first set of trains; and receive, from the first set of trains, a set of parameter setting confirmation data, the verification unit is configured to verify, by comparing the set of parameter setting confirmation data with the parameter file database, that the set of parameter setting confirmation data achieves a consistency level with respect to the parameter file database; and the communication unit is further configured to transmit, in response to verifying that the set of parameter setting confirmation data achieves a consistency level with respect to the parameter file database, an operation approval command to the first set of trains.

According to the present invention, it is possible to select appropriate train parameters for a train based on data for the target train, dynamically update an onboard (OBU) unit of the train in real time using the selected parameters, and verify the integrity of the parameters set in the OBU.

FIG. 1 illustrates an exemplary computing infrastructure for executing the embodiments of the present disclosure. FIG. 2 is an example high level system configuration of a train control system, according to embodiments. FIG. 3 illustrates a functional configuration of a train as part of a train control system, according to embodiments. FIG. 4 is a conceptual illustration of train parameters in the onboard unit (OBU) of a train. FIG. 5 illustrates an example of a various interfaces for carrying out the embodiments of the present disclosure. FIG. 6 illustrates a first example of information stored in a parameter file database, according to embodiments. FIG. 7 illustrates a second example of information stored in a parameter file database, according to embodiments. FIG. 8 illustrates a third example of information stored in a parameter file database, according to embodiments. FIG. 9 is a flowchart illustrating a method of managing train parameters according to embodiments. FIG. 10 is a flowchart illustrating a train parameter verification method according to embodiments. FIG. 11 is a flowchart illustrating a method of updating train parameters according to embodiments. FIG. 12 is a diagram that illustrates a concept of updating the train parameters of a plurality of separate trains based on operation data collected for a first set of trains. FIG. 13 is a flowchart illustrating an example of a fail-safe network architecture for train parameter updating, according to embodiments. FIG. 14 is a flowchart illustrating an example of updating the train parameters of multiple sets of trains, according to embodiments. FIG. 15 is a flowchart illustrating an example of updating train parameters in real time, according to embodiments.

Description of Embodiment(s)

Referring now to FIG. 1, FIG. 1 illustrates an exemplary computing infrastructure for executing the embodiments of the present disclosure. In particular, FIG. 1 illustrates an example of a computing node 10. Computing node 10 is only one example of a suitable computing device and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the disclosure described herein. Regardless, computing node 10 is capable of being implemented and/or performing any of the functionality set forth herein. In embodiments, computing node 10 may be configured to operate as a cloud computing node or server in a distributed computing environment for implementing the functions of the present disclosure described herein.

In computing node 10 there is a computer system/server 12, which is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with computer system/server 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.

Computer system/server 12 may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system/server 12 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

As illustrated in FIG. 1, computer system/server 12 in the computing node 10 is shown in the form of a general-purpose computing device. The components of computer system/server 12 may include, but are not limited to, one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including system memory 28 to processor 16.

Bus 18 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

Computer system/server 12 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server 12, and it includes both volatile and non-volatile media, removable and non-removable media.
System memory 28 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and/or cache memory 32. Computer system/server 12 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, a storage system 34 can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a "hard drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected to bus 18 by one or more data media interfaces. As will be further depicted and described below, memory 28 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the disclosure.

Program/utility 40, having a set (at least one) of program modules 42, may be stored in memory 28 by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules 42 generally carry out the functions and/or methodologies of embodiments of the disclosure as described herein.

Computer system/server 12 may also communicate with one or more external devices 14 such as a keyboard, a pointing device, a display 24, etc.; one or more devices that enable a user to interact with computer system/server 12; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server 12 to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces 22. Still yet, computer system/server 12 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter 20. As depicted, network adapter 20 communicates with the other components of computer system/server 12 via bus 18. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server 12. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

FIG. 2 illustrates an example high-level system configuration of a train control system 200, according to embodiments. As illustrated in FIG. 2, the train control system 200 may include a cloud 215, a first set of trains 210, a second set of trains 220, and a third set of trains 230.

In embodiments, the cloud 215 may refer to a distributed computing environment including a plurality of computing devices communicatively connected via a communication network such as the Internet to provide on-demand availability of computer system resources. In general, the cloud 215 may support a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service.

In addition, the cloud 215 may support features such as on-demand self service, broad network access, resource pooling, rapid elasticity, and measured service. These features may be provided using service-models such as Software-as-a-Service (SaaS), Platform as a Service (PaaS), or Infrastructure-as-a-Service (IaaS). Further, the cloud 215 may support a variety of deployment models including a private cloud infrastructure, a community cloud infrastructure, a public cloud infrastructure, or a hybrid cloud infrastructure.

As illustrated in FIG. 2, the cloud 215 may be connected to one or more sets of trains 210, 220, 230 via a communication network (not pictured) such as the Internet. As is well known, herein, each of the sets of trains 210, 220, 230 may refer to a form of transport consisting of a series of connected vehicles that travel along a rail track to transport cargo or passengers. Herein “a set of trains” may refer to a single train formation comprising one or more cars or carriages, or multiple train formations that share similar attributes (e.g., same type of train, same acceleration/deceleration characteristics, same number of cars).

Each of the sets of trains 210, 220, 230 may include one or more onboard units (OBU). Generally, the OBU may refer to a computing device configured to interact with a train control server located in the cloud 215 as well as trackside signaling systems to receive updated train parameters, route information, and the like to facilitate train operation and performance. In embodiments, an OBU may be located in a lead car of a train formation, a rear car of a train formation, or both a lead car and a rear car. In certain embodiments, an OBU may be located in each car of a train formation. The OBU requires a specially defined set of train parameters for safe and optimal operation. These parameters may change due to aspects such as the type of trains under operation, the track conditions and the OBU/ trackside operation. The parameters have a significant effect on the safety and efficiency of the train operation.

Herein, “train parameters” generally refer to a set of data that defines one or more operational characteristic of a set of trains. The set of train parameters may define the operational speed ranges, acceleration characteristics, deceleration characteristics, linkage-de-linkage protocols, and the like for a set of train parameters in a variety of conditions. As examples, the set of train parameters may include a train speed range, a train deceleration rate, a train acceleration rate, train emergency brake characteristics (e.g., emergency brake deceleration) and the like.

As will be described herein, the OBU may be configured to receive updated train parameters from the cloud 215. These train parameters may be received from the cloud 215 prior to the beginning of train operation, during train operation (e.g., while the train is running), or after completion of train operation.

FIG. 3 illustrates a functional configuration of a train as part of a train control system 300, according to embodiments. As illustrated in FIG. 3, the train control system 300 primarily comprises a train control server 310 and a train 318. The train control server 310 and the train 318 may be communicatively connected via a communication network such as the Internet. The train 318 may substantially correspond to the sets of trains 210, 220, 230 illustrated in FIG. 2.

The train control server 310 may include a computing device or computer program configured to provide functionality to the train 318 (e.g., a client-server architecture). In embodiments, the train control server 310 may be configured to facilitate the transmission, management, and verification of train parameters for one or more sets of trains included in the train control system 300. The train control server 310 may function as a cloud node in the cloud 215 illustrated in FIG. 2. In embodiments, the train control server 310 may be implemented by the computer system server 10 illustrated in FIG. 1.

In embodiments, the train control server 310 may include a train parameter management unit 312, a train parameter verification unit 314, and a communication unit 316. Each of the train parameter management unit 312, the train parameter verification unit 314, and the communication unit 316 may be implemented as software modules or as dedicated hardware.

The train parameter management unit 312 may be a functional unit configured to manage the storage and utilization of train parameters in the train control system 300. As illustrated in FIG. 3 the train parameter management unit 312 may include a train parameter file database 313. The train parameter file database 313 may include a database management system configured to store a set of train parameters for one or more sets of trains. In embodiments, the train parameter file database 313 may be structured as a hierarchical database, a network database, a relational database, an object-oriented database, a graph database, an entity relationship model database, a document database, or the like. Further, the train parameter management unit 312 may be configured to derive train parameters based on operational data collected by the train 318.

The train parameter verification unit 314 may be a functional unit configured to verify the integrity of train parameters set in the OBU 340 of the train 318. For instance, as will be described later, the train parameter verification unit 314 may be configured to verify that a set of train parameters set in the OBU 340 of the train 318 achieves an integrity threshold with respect to a particular set of train parameters stored in the train parameter file database 313 in order to facilitate train operational performance and safety.

The communication unit 316 may be a functional unit configured to facilitate data communication between the train control server 310 and the train 318. For example, the communication unit 316 may be configured to receive train data and operational data from the train 318, and transmit sets of train parameters to the train 318 in order to update the OBU 340.

As illustrated in FIG. 3, the train 318 includes a communication unit 320, a driver 330, an OBU 340, train data 350, train parameters 355, and a trainside control unit 360. The communication unit 320 may substantially correspond to the communication unit 316, and be configured to facilitate data communication between the train control server 310 and the train 318. The driver 330 may be a human operator or an artificial intelligence (AI) unit capable of operating the train 318. The trainside control unit 360 may be a functional unit configured to send and receive data between the train 318 and trackside signaling units.

As previously described, the OBU 340 may include a computing device configured to interact with the train control server 310 as well as trackside signaling systems to receive updated train parameters, route information, and the like to facilitate train operation and performance. In embodiments, the OBU 340 may also be configured to manage a set of train data 350. Herein, the set of train data 350 refers to a set of data that indicates a set of characteristics regarding the set of trains 318. For instance, the set of train data 350 may include a train identifier (e.g., a unique identifier for the train), a set of train length data (e.g., how many cars are included in the train formation), a set of driver identification data (e.g., a unique identifier for the train operator), a set of bogie cut-off data (e.g., information regarding when/where/how many bogies have been cut off from the train), or the like. As will be described later, the set of train data 350 may be transmitted to the train control server 310 and used to select an appropriate set of train parameters 355 for the train 318. Accordingly, the selected set of train parameters 355 may be transmitted from the train control server 310 to the OBU 340 of the train 318 via the communication unit 316 and the communication unit 320.
In certain embodiments, bogie cut-off data may be relevant to the performance characteristics of a set of trains. In general, bogies may be responsible for applying traction and braking. This braking may include both air braking and/or braking using the traction system of the train. Accordingly, cutting off a bogie may lead to a reduction in air brake performance (e.g., stopping distance may decrease) and or a reduction in traction braking/traction, depending on the design of the train. As such, bogie cut-off information may provide insight into the performance characteristics of a set of trains, and be useful when selecting a set of train parameters for a particular set of trains.

FIG. 4 is a conceptual illustration of a conventional configuration of train parameters in the onboard unit (OBU) of a train. As described herein, the OBU may be a computing device configured to include a specifically defined set of train parameters that facilitate safe and efficient train operation. These train parameters may change based on aspects such as the type of trains under operation, the track conditions and the OBU/ trackside operation. In embodiments, these parameters can have a significant effect on the safety and efficiency of the train operation.

Typically, a set of train parameters are embedded into the software of the OBU. The OBU may include a dedicated memory 410 configured to store and maintain a set of embedded train parameters 412. Upon commencing operation, an additional set of train parameters 414 can be received from a trackside signaling unit. Once received, this set of train parameters 414 may temporarily replace a portion of the set of embedded train parameters 412 that correspond to that particular operation (e.g., mission). Upon completion of the operation (e.g., power down of the OBU), the received set of train parameters 410 are deleted from the memory 410, and the OBU returns to the default set of embedded train parameters 412.

Currently, should there be a need to permanently change the train parameters stored in the memory 410 of the OBU, these train parameters need to be updated for each OBU of the train via a maintenance procedure followed by testing to confirm the adequacy and safety of the parameters. Further, since the set of train parameters stored in the OBU are used to control the speed, acceleration, deceleration, coupling/decoupling, and other integral operations of the train, the integrity of these train parameters (e.g., verifying that these train parameters are set correctly) is relevant to ensuring safe and efficient train operation.

Accordingly, the present disclosure relates to utilizing the features of distributed computing environments and secure data interfaces to facilitate the efficient and safe update of train parameters. In addition, aspects of the disclosure relate to the optimization of train parameters based on train operational data, safety regulations, user requirements, and other information collected for a plurality of trains communicatively connected within the train control system.

FIG. 5 illustrates various interfaces for carrying out the embodiments of the present disclosure. In particular, FIG. 5 illustrates a train interface 505 for use on the train side of the train control system and a cloud interface 535 for use on the server side of the train control system.

As described herein, in the train interface 505, the OBU 510 (e.g., corresponding to the OBU 340 in FIG. 3) utilizes a data radio 520 to send and receive train data, operational data, and confirmation data to the cloud 530 (e.g., corresponding to the train control server 310 in FIG. 3) over a secure channel via a communication network such as the Internet. The data radio 520 may, for example, be a Very High Frequency (VHF) or Ultra High Frequency (UHF) data radio modem. As described herein, the train data may include a set of data that indicates a set of characteristics regarding the set of train 318. The set of operational data may include a set of information collected by the OBU 510 regarding the operational performance of the train during a mission. As examples, the set of operational data may include information regarding the actual acceleration/deceleration characteristics of the train, stopping times, energy efficiency, and other performance characteristics under a variety of environmental conditions (e.g., rain, snow, sleet, hail, clear conditions, differing train formation lengths). The set of confirmation data may include information that indicates successful reception of data from the cloud side.

As described herein, in the cloud interface 535, the cloud 530 (e.g., corresponding to the train control server 310 in FIG. 3) may include a train parameter file database configured to store and maintain a set of train parameters for one or more sets of trains. In addition to the train parameters, this train parameter file database may include identification information for the sets of trains, time stamps for the sent/received train parameters, train data and operational data collected from the set of trains, OBU software versions, systems versions, safety regulations and the like. In addition, the cloud interface 535 may offer a cloud operator interface 550 that allows human administrators or other programs (e.g., such as a fail-safe algorithm) 560 to view the contents of the train parameter file database, analyze operational data, and facilitate the optimization of train parameters.

FIG. 6-8 illustrate examples of information stored in a parameter file database, according to embodiments. As described herein, aspects of the present disclosure relate to a train parameter file database (e.g., such as the parameter file database 313 of FIG. 3) configured to store and maintain a set of train parameters and other information for one or more sets of trains. In embodiments, the parameter file database may include a plurality of parameter files for a particular set of trains, and one or more of sets of parameter files may be selected from these parameter files for the set of trains based on the collected train data. As described herein, the set of train parameters generally refer to a set of data that defines an operational characteristic (e.g., voltages, speed limits) of a set of trains. Here, it should be noted that the train parameters illustrated in the following Figures are for the purpose of example only, and the present disclosure is by no means limited to the parameters illustrated herein.

FIG. 6 illustrates an example of a parameter database file 575 stored in a parameter file database, according to embodiments. As illustrated in FIG. 6, the parameter database file 575 may include a plurality of train parameters for a particular train class (e.g., a particular set of primary input attributes). As examples, the parameter database file 575 may define units, providers, ranges, values, and the like for a variety of voltage parameters, traction parameters, speed limits, and the like. In embodiments, the train parameters illustrated in the parameter database file 575 are applicable to any train having a particular set of primary input attributes, regardless of its secondary input attributes. Accordingly, trains having a different set of primary input attributes may have different information defined in the parameter database file 575.

FIG. 7 illustrates an example of a parameter database file 585 stored in a parameter file database 585, according to embodiments. As illustrated in FIG. 7, the parameter database file 585 includes a variety of pre-set parameters for a particular set of trains, as well as configurable parameters for the particular set of trains. As examples, the parameter database file 585 may device units, suppliers, ranges, and values for parameters such as brake positions, axles, loading gauges, and the like.

FIG. 8 illustrates an example of a parameter database file 595 stored in a parameter file database, according to embodiments. As illustrated in FIG. 8, the parameter database file 595 includes a variety of pre-set parameters and configurable parameters relating to the brake system of a particular set of trains. The values of these brake parameters may be set depending on train data (e.g., train formation length, braking system degradation) received for the set of trains as well as environmental conditions (e.g., whether the track is wet, dry, icy). As examples, the parameter database file 595 may define units, suppliers, ranges, and values for parameters such as service brakes and emergency brakes. In embodiments, as the parameters of the parameter database file 595 are determined in accordance with train data received from the set of trains, these parameters may be favorable targets for parameter optimization based on collected operation data.

FIG. 9 is a flowchart illustrating a method 600 of managing train parameters according to embodiments. According to the method 600, the train control server (e.g., the train control server 310 illustrated in FIG. 3) may collect a set of operation data from one or more sets of trains, and this operation data may be used to derive an appropriate set of train parameters to facilitate safe and efficient train operation.

In embodiments, at Step 610, the train control server may collect one or more sets of train parameters and operation data sent by one or more sets of trains. Herein, “collecting” may include obtaining, fetching, retrieving, or otherwise acquiring the one or more sets of train parameters and operation data. For instance, the train control server may receive the one or more sets of train parameters from the communication unit of the train via the Internet. In embodiments, the set of train parameters collected here may be a set of train parameters used by the train for a particular mission, and the set of operation data may include performance statistics collected by the OBU of the train during operation of that particular mission. As an example, the set of operation data may include braking information that indicates when and to what degree braking was performed throughout the train mission.

In embodiments, at Step 620, the set of train parameters collected in Step 610 may be retrieved for analysis and optimization. Here, “retrieving” may include downloading, importing, ingesting, viewing, accessing, or otherwise utilizing the set of train parameters as part of an analysis task. In embodiments, the analysis of the set of train parameters may be carried out by a human user (e.g., a system administrator or train conductor) or by a machine learning technique. As examples, the machine learning technique may include linear regression, logistical regression, random forest, gradient boosted trees, support vector machines, neural networks, decision trees, or nearest neighbor. In embodiments, retrieving the set of train parameters may include downloading the set of train parameters from the train parameter database to a local computing environment for user analysis. In embodiments, retrieving the set of train parameters may include importing the set of train parameters into a neural network configured for reinforcement learning.

In embodiments, at Step 630, the set of train parameters may be optimized based on a set of input attributes and/or a set of operation data. In general, “optimizing” may include deriving revising, enhancing, improving, fine-tuning, or otherwise modifying the set of train parameters to facilitate safe and efficient train operation. Herein, the set of input attributes may include data that indicates characteristics that pertain to the set of trains as well as the environmental conditions in which the set of trains operate. The set of input attributes may be included in the set of train data collected by the train control server in Step 610, and subsequently stored in the parameter file database. In embodiments, optimizing the set of train parameters may include one or more of a linear programming technique, an integer programming technique, a non-linear programming technique, a stochastic programming technique, a numerical method, a linear algebra method, or a machine learning technique.

In embodiments, the set of input attributes may include a set of primary input attributes and a set of secondary input attributes. The set of primary input attributes may indicate characteristics inherent to a particular set of trains, such as the acceleration rate under traction or the deceleration rate under service and emergency braking. Primary input attributes apply only for trains that share the same type and the same operational conditions. For example, a passenger fleet train type consisting of the same number carriages and with the same performance (for example the number of brake systems or traction systems operational) may share the same primary input attributes. The set of secondary input attributes may indicate characteristics external to the set of trains, such as the time of day, weather conditions, trackside conditions, accidents, sudden maintenance, user requirements, or the like. Secondary input attributes may be susceptible to change, and can lead to several pre-sets of train parameters for the same type of train (trains having the same primary input attributes). Secondary input attributes may be directly linked to primary inputs, as they may be the cause of reduced braking performance in poor weather conditions, for example.

As described herein, the set of train parameters may be optimized based on the set of primary input attributes, the set of secondary input attributes for a particular set of trains, and/or a set of operation data. In embodiments, optimizing the set of train parameters may include generating or deriving a second set of train parameters configured to maximize the operational performance and safety of the set of trains based on the collected operational data, the characteristics of the train itself indicated by the set of primary input attributes and the surrounding environmental conditions indicated by the set of secondary input attributes. As an example, in the case of a train that is hauling a large number of cars and is traveling in an environment in which low traction conditions (e.g., due to rain or snow) are anticipated, an optimized set of train parameters that increase the deceleration rate of the brake system of the set of trains may be generated. Other methods of optimizing the set of train parameters are also possible. In embodiments, the optimization/derivation of the set of train parameters may include using a machine learning technique such as linear regression, logistical regression, random forest, gradient boosted trees, support vector machines, neural networks, decision trees, or nearest neighbor to analyze the set of operation data together with the set of input attributes to generate parameters that are associated with a high likelihood of achieving predetermined performance or safety thresholds.

In embodiments, at Step 640, the set of train parameters in the cloud are updated based on the optimized set of train parameters. Generally, “updating” can include amending, overwriting, revising, renewing, refreshing, or otherwise modifying the set of train parameters in the cloud based on the optimized set of train parameters. In particular, the human user or machine learning technique that performed the optimization of the set of train parameters may store the optimized set of train parameters in the train parameter file database stored in the train control server. In this way, the optimized set of train parameters may be prepared for transmission to the OBU of one or more sets of trains in order to facilitate safe and efficient operation.

FIG. 10 is a flowchart illustrating a train parameter verification method 700 according to embodiments. The method 700 may begin at Step 701 and end at Step 799. As described herein, since the set of train parameters stored in the OBU are used to control the speed, acceleration, deceleration, coupling/decoupling, and other integral operations of the train, the integrity of these train parameters (e.g., verifying that these train parameters are set correctly in accordance with those of the train parameter file database) is relevant to ensuring safe and efficient train operation. However, in some cases, data corruption or packet loss during the transmission process may result in incorrect train parameters being set in the OB. Accordingly, the method 700 facilitates verification of the integrity level of the set of train parameters set in the OBU in order to facilitate safe and efficient train operation.

In embodiments, at Step 710, a first set of train parameters are selected from the parameter file database. Generally, “selecting” can include choosing, electing, identifying, ascertaining, picking-out, or otherwise determining the first set of train parameters. In embodiments, the first set of train parameters may be selected by the parameter management unit from the parameter file database based on a first set of train data received from a first set of trains. As described herein, the first set of train data may include a set of data that indicates a set of characteristics regarding the first set of trains (e.g., a train identifier, a set of train length data, a set of driver identification data, or a set of bogie cut-off data). Here, the first set of train parameters may be a set of train parameters expected to facilitate safe and efficient operation of the first set of trains. In embodiments, selecting the first set of train parameters may include using the parameter management unit to analyze a collection of aggregated historical operation data associated with the set of train parameters stored in the parameter file database, and identify a particular set of train parameters that are proven to have achieved safe and efficient train operation for a train having the characteristics defined by the first set of train data.

In embodiments, at Step 720, the first set of train parameters are transmitted to the first set of trains. Generally, “transmitting” can include broadcasting, conveying, transferring, relaying, or otherwise sending the first set of train parameters to the first set of trains. In embodiments, the first set of train parameters may be transmitted using a particular communication protocol that differs from the communication protocol used by the first set of trains for transmitting the set of parameter setting confirmation data to be described later. By leveraging different communication protocols for the data communication to and from the first set of trains, it is possible to avoid systematic errors endemic to a particular communication protocol, and to facilitate the identification of errors arising from data corruption or packet loss. As described herein, the first set of train parameters may be transmitted from the train control server to the OBU by making use of the communication units located in the train control server and the train, respectively.

In embodiments, at step 730, the train control server may receive a set of parameter setting confirmation data from the first set of trains. Generally, “receiving” can include accepting, collecting, obtaining, fetching, or otherwise acquiring the set of parameter setting confirmation data. In embodiments, the set of parameter setting confirmation data may include a set of data that indicates the train parameters that were actually set in the OBU of the first set of trains. In general, the train parameters that are actually set in the OBU of the first set of trains will match those parameters transmitted to the first set of trains in Step 720, but in some cases, data packet loss or data corruption that arises during the communication process may result in incorrect parameters being set in the OBU of the first set of trains. Such incorrect parameters may result in malfunctions, inefficiency, and unsafe train operation. Accordingly, aspects of the present disclosure relate to requiring the OBU of the first set of trains to transmit a set of parameter setting confirmation data to indicate the train parameters that were actually set in the OBU of the first set of trains. As will be described later, by verifying this set of parameter setting confirmation data, it is possible to confirm that the correct train parameters have been set in the OBU, and facilitate safe and efficient train operation.

In embodiments, at Step 740, an integrity level of the set of parameter setting confirmation data may be verified. Generally, verifying can include checking, certifying, checking, confirming, or otherwise authenticating the integrity level of the set of parameter setting confirmation data. Here, the integrity level may refer to a measure of the degree to which the set of train parameters indicated by the set of parameter setting confirmation data match or correspond to the set of parameters transmitted to the first set of trains in Step 720, as stored in the set of train parameter database. In embodiments, verifying the integrity level of the set of parameter setting confirmation data may include using the train parameter verification unit to compare the set of parameter setting confirmation data (e.g., the set of train parameters actually set in the OBU) with the parameter file database (e.g., the set of train parameters originally transmitted to the first set of trains) to ascertain the degree to which the set of parameter setting confirmation data matches the train parameters in the parameter file database. In the case that the integrity level of the set of parameter setting confirmation data does not achieve a predetermined integrity threshold (e.g., 100% match), the train parameter verification unit may transmit an operation denial message to the first set of trains, and prohibit further train operation until setting of the correct train parameters can be verified. In the case that the integrity level of the set of parameter setting confirmation data does achieve a predetermined integrity threshold, the present method may proceed to Step 750.

In embodiments, at Step 750, in response to verifying that the integrity level of the set of parameter setting confirmation data achieves the predetermined integrity threshold, the communication unit of the train control server may transmit an operation approval command to the first set of trains. Here, the operation approval command may include a message that grants the first set of trains permission to initiate or continue operation. Accordingly, the first set of trains may initiate or continue operation (e.g., a predetermined run or mission) using the verified first set of train parameters. In this way, by verifying that the set of train parameters set in the OBU achieve an integrity level with respect to the parameter file database, safe and efficient train operation can be facilitated.

FIG. 11 is a flowchart illustrating a method 800 of transmitting train parameters to a set of trains, according to embodiments. According to the method 800, the train control server (e.g., the train control server 310 illustrated in FIG. 3) may utilize information collected regarding a first run (e.g., train mission from a start point to a predetermined destination) to generate and transmit a second set of train parameters (e.g., an optimized set of train parameters) to facilitate safe and efficient train operation on a subsequent second run.

At Step 805, a driver of the train may input train data associated with a first run. As described herein, the train data may include, for instance, driver identification information, train length information, bogie information, or the like. In embodiments, the train data may be input using a graphical user interface (GUI) of the OBU located in a lead car of a set of trains.

At Step 810, the OBU transmits the train data together with a Train ID (e.g., a NID engine) and time stamp information (e.g., information indicating when the information was input) to the cloud. In particular, the OBU may transmit this information to the train control server via the communication unit located in the set of trains.

At Step 820, the train control server receives the information transmitted by the OBU in Step 810, and selects an appropriate set of train parameters (e.g., a first set of train parameters P1) from the train parameter database. In embodiments, selecting the appropriate set of train parameters may include using the received set of train information to identify a set of train parameters associated with an expected performance level that achieves a target performance threshold for the set of trains.

At Step 825, the train control server transmits the identified first set of train parameters P1 to the set of trains. In particular, the train control server may transmit the identified first set of train parameters P1 to the OBU of the set of trains via the communication unit.

At Step 830, the set of trains receives the first set of train parameters P1, and transmits a set of parameter setting confirmation data that indicates successful reception of the first set of train parameters P1, as well as which parameters were actually set in the OBU, to the train control server.

At Step 835, the train control server receives the set of parameter setting confirmation data, and compares it with the parameter file database to verify that the first set of train parameters P1 has been successfully and correctly stored in the OBU of the first set of trains (e.g., that the train parameters stored in the OBU match the train parameters maintained in the train parameter file database). Subsequently, the train control server transmits an operation approval command to the set of trains that grants the set of trains permission to begin operation (e.g., to begin the first run). In this way, train operation in accordance with the correct train parameters can be ensured.

At Step 840, the set of trains performs the first run. In embodiments, performing the first run may include operating from a designated start of mission (SOM) point to a designated end of mission (EOM) point, using the first set of train parameters P1 to guide the operation.

At Step 845, the set of trains transmits a set of operation data to the train control server after completion of the first run (e.g., after reaching the end of mission point). As described herein, the set of operation data may include performance statistics collected by the OBU of the train during operation. As an example, the set of operation data may include brake performance information, traction performance information, voltage information, or the like.

At Step 850, the train control server analyses the received set of operation data, and uses this set of operation data to optimize the first set of train parameters P1 and generate a second set of train parameters P2. As described herein, the second set of train parameters P2 may be generated in accordance with the first set of train parameters, and calculated based upon the feedback received for those particular conditions as indicated by the set of operation data. In embodiments, this optimization may be performed based on operational data collected for a plurality of sets of trains over a period of time. In embodiments, the optimization of the first set of train parameters P1 may be performed by the train parameter management unit (e.g., the train parameter management unit 312 illustrated in FIG. 3), and substantially correspond to Step 630 of FIG. 9.

At Step 855, a driver may input train data associated with a second run. As described herein, the train data may include, for instance, driver identification information, train length information, bogie information, or the like. In embodiments, the train data may be input using a graphical user interface (GUI) of the OBU located in a lead car of a set of trains. In embodiments, the train data input here may substantially correspond with (e.g., match) the set of train data input for the first run in Step 805. That is, while the set of trains that performs the second run need not be the same set of trains that performed the first run, performing the second run using a set of trains that shares the same primary input attributes as the set of trains that performed the first run ensures the validity of the second set of train parameters P2 for the intended operation conditions (e.g., route, environmental conditions).

At Step 860, Steps 810 to Step 840 are repeated. Here, in response to confirming that the track and weather conditions of the second run substantially correspond to those of the first run, the train control server may transmit the second set of train parameters P2 to the set of trains.

At Step 865, the set of trains transmits a set of operation data to the train control server after completion of the second run (e.g., after achieving the end of mission point). As described herein, the set of operation data may include performance statistics collected by the OBU of the train during operation. As an example, the set of operation data may include brake performance information, traction performance information, or the like.

At Step 870, the train control server analyses the received set of operation data for the second run, and uses this set of operation data to further optimize the second set of train parameters P2 (e.g., generate a third set of further optimized train parameters P3). As such, as illustrated in Step 875, Steps 805 to 855 may be repeated an arbitrary number of times to continue optimizing the set of train parameters as new information becomes available regarding the operational characteristics of a particular set of trains in a given operational context. Accordingly, in this way, continuous increases to the safety level and operational performance of the set of trains can be achieved.

FIG. 12 is a figure illustrating a concept of updating the train parameters of a plurality of separate trains based on operation data collected for a first set of trains. By leveraging the above-described distributed computing environment, the optimized train parameter values of one train could be used by multiple other trains (during operation or at before/after a mission) if the train parameters are applicable to the other trains (e.g., share the same set of input attributes).

As illustrated in FIG. 12, a set of operation data 910 for a first set of trains may be transmitted to the cloud 915 (e.g., corresponding to the train control server 310) of FIG. 3. As described herein, the set of operation data 910 include performance statistics collected by the OBU of the set of first trains during operation. As an example, the set of operation data may include braking information that indicates when and to what degree braking was performed throughout a train mission. Subsequently, if a second set of trains 920 and a third set of trains 930 are ascertained to share the same input attributes as the first train (that is, share the same set of primary input attributes and the same set of secondary input attributes), a set of train parameters 945 optimized based on the set of operation data 910 for the first train 910 may be transmitted to the second set of trains 920 and the third set of trains 930. The second set of trains 920 and the third set of trains 930 may update their internal OBUs using the set of train parameters 945 either during operation or at the next start of mission point. In this way, by updating the train parameters of a plurality of separate trains based on operation data collected for a first set of trains, greater operational flexibility and parameter update efficiency can be realized.

FIG. 13 is a flowchart illustrating an example of a fail-safe network architecture 1000 for train parameter updating, according to embodiments. As described herein, since the set of train parameters stored in the OBU are used to control the speed, acceleration, deceleration, coupling/decoupling, and other integral operations of the train, the integrity of these train parameters (e.g., verifying that these train parameters are set correctly) is relevant to ensuring safe and efficient train operation. Accordingly, the fail-safe network architecture 1000 provides an additional example of a configuration that can be used to facilitate train parameter integrity.

As illustrated in FIG. 13, the fail-safe network architecture 1000 includes two independent cloud servers 1010 and 1020. In embodiments, each of these cloud servers may have a configuration that substantially corresponds to the train control server described above (e.g., the train control server 310 illustrated in FIG. 3), and may each include a train parameter management unit and train parameter file database (not illustrated here). After generating a set of optimized train parameters based on a set of operational data received for a set of trains, a user (e.g., system administrator or machine learning technique) may upload the set of optimized train parameters to both of the cloud servers 1010 and 1020. Here, the cloud servers 1010 and 1020 may perform an initial confirmation procedure with one another to verify that the received set of optimized train parameters match.

Subsequently, both of the cloud servers 1010 and 1020 may transmit the set of optimized train parameters to an OBU 1030 of the set of trains. Here, the OBU may confirm that the sets of optimized train parameters received from each of the cloud servers 1010 and 1020 match. In response to confirming that both sets of optimized train parameters match, the OBU 1030 may update the previously stored train parameters in its memory with the newly received set of optimized train parameters, and transmit a set of train parameter setting confirmation data to both of the cloud servers 1010 and 1020. Both of the cloud servers 1010 and 1020 may verify the integrity of the set of train parameter setting confirmation data with respect to their internal parameter file databases, and transmit operation approval commands to the OBU 1030. The utilization of such a fail-safe network architecture 1000 may provide an additional level of authentication to further ensure the integrity of the train parameters.

FIG. 14 is a flowchart illustrating an example method 1100 for updating the train parameters of multiple sets of trains, according to embodiments. According to the method 1100, multiple sets of trains may be updated simultaneously using a single set of train parameters.

In embodiments, at Step 1105, a driver of a first set of trains may input train data associated with a second run (e.g., the first set of train has already completed a first run, and thus operation data for the first run is already stored in the train control server). As described herein, the train data may include, for instance, driver identification information, train length information, bogie information, or the like. In embodiments, the train data may be input using a graphical user interface (GUI) of the OBU located in a lead car of the first set of trains.

In embodiments, at Step 1110, the OBU transmits the train data together with a Train ID, time stamp information (e.g., information indicating when the information was input), and OBU software version information to the cloud. In particular, the OBU may transmit this information to the train control server via the communication unit located in the set of trains.

In embodiments, at Step 1115, the train control server may use the set of operation data received from the first set of trains after the first run to optimize the set of train parameters for the first set of trains. Here, it should be noted that the set of train parameters optimized for the first set of trains at this time may also be applicable to other sets of trains (e.g., a second set of trains and a third set of trains) that share input attributes (e.g., same primary input attributes and same secondary input attributes) with the first set of trains. Accordingly, at this time, the train control server may identify one or more other sets of trains having a set of input attributes that achieve a similarity threshold (e.g., 80% similarity, 90% similarity, 100% similarity) with the first set of trains.

In embodiments, at Step 1120, the first set of trains, as well as any other sets of trains identified as having a set of input attributes that achieve a similarity threshold with the first set of trains, may simultaneously be updated with the set of optimized train parameters. Here, trains may be updated with the set of optimized train parameters at any time, including prior to operation, during operation, or after operation. In this way, multiple sets of trains may be updated simultaneously using a single set of train parameters, increasing operational flexibility.

FIG. 15 is a flowchart illustrating an example method 1200 for updating train parameters in real time, according to embodiments. According to the method 1200, the train parameters stored in the OBU of a train may be updated in real time while the train is in operation.

In embodiments, at Step 1205, a set of trains operates according to a predetermined mission. For example, the set of trains may perform a mission to carry passengers or cargo from one predetermined station to another. At Step 1210, a user (e.g., administrator of the train control server or alternatively the train driver) may issue a request to the train control server to initiate a train parameter update operation. Subsequently, at Step 1215, the train control server may transmit an appropriate set of train parameters to the set of trains via a secure channel while the set of trains is still operating. In certain embodiments, the set of trains may immediately update the train parameters stored in its OBU with the received set of train parameters. In certain embodiments, the set of trains may wait for an appropriate time (e.g., when stopping at a waypoint, when environmental conditions are favorable) to update the set of train parameters.

Accordingly, by updating the set of train parameters in real time using a distributed computing environment infrastructure, the need for human operators to perform lengthy maintenance operations can be avoided. Further, updating the set of train parameters in real time can be particularly useful in cases when there are sudden changes in weather conditions and disasters (e.g. tornados, earthquakes, hurricanes, floods) and unknown trackside issues, as the train parameters can be updated dynamically based on the nature of the environmental conditions in which the train is operating.

In addition to embodiments described above, other embodiments having fewer operational steps, more operational steps, or different operational steps are contemplated. Also, some embodiments may perform some or all of the above operational steps in a different order. In embodiments, operational steps may be performed in response to other operational steps. The modules are listed and described illustratively according to an embodiment and are not meant to indicate necessity of a particular module or exclusivity of other potential modules (or functions/purposes as applied to a specific module).

In the foregoing, reference is made to various embodiments. It should be understood, however, that this disclosure is not limited to the specifically described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice this disclosure. Many modifications and variations may be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. Furthermore, although embodiments of this disclosure may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of this disclosure. Thus, the described aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s).

The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

Embodiments according to this disclosure may be provided to end-users through a cloud-computing infrastructure. Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. Thus, cloud computing allows a user to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in “the cloud,” without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

While the foregoing is directed to exemplary embodiments, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow. The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the various embodiments. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. “Set of,” “group of,” “bunch of,” etc. are intended to include one or more. It will be further understood that the terms “includes” and/or “including,” when used in this specification, specify the presence of the stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. In the previous detailed description of exemplary embodiments of the various embodiments, reference was made to the accompanying drawings (where like numbers represent like elements), which form a part hereof, and in which is shown by way of illustration specific exemplary embodiments in which the various embodiments may be practiced. These embodiments were described in sufficient detail to enable those skilled in the art to practice the embodiments, but other embodiments may be used and logical, mechanical, electrical, and other changes may be made without departing from the scope of the various embodiments. In the previous description, numerous specific details were set forth to provide a thorough understanding the various embodiments. But, the various embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure embodiments.

Claims

A train control system in a distributed computing environment, characterized by:
a train control server configured to communicate with one or more trains via a communication network, the train control server including:
a parameter management unit configured to store a parameter file database that manages one or more train parameters for the one or more trains;
a train parameter verification unit configured to verify a consistency level of a set of train parameters; and
a communication unit configured to perform communication between the parameter management unit and a first set of trains;
wherein:
the parameter management unit is configured to:
select, in response to receiving a first set of train data associated with the first set of trains, a first set of train parameters based on the first set of train data from the parameter file database;
the communication unit is configured to:
transmit the first set of train parameters to the first set of trains; and
receive, from the first set of trains, a set of parameter setting confirmation data;
the verification unit is configured to:
verify, by comparing the set of parameter setting confirmation data with the parameter file database, that the set of parameter setting confirmation data achieves an integrity level with respect to the parameter file database; and
the communication unit is further configured to:
transmit, in response to verifying that the set of parameter setting confirmation data achieves an integrity level with respect to the parameter file database, an operation approval command to the first set of trains.
The train control system of Claim 1, wherein:
the parameter file database further includes a first set of input attributes corresponding to the first set of trains;
the train parameter verification unit is further configured to identify a second set of trains corresponding to a second set of input attributes that achieves a similarity threshold with respect to the first set of trains; and
the communication unit is further configured to transmit, in response to identifying the second set of trains corresponding to a second set of input attributes that achieves a similarity threshold with respect to the first set of trains, the first set of train parameters to the second set of trains.
The train control system of Claim 1, wherein:
the communication unit is further configured to transmit the first set of train parameters to the first set of trains in real time while the first set of trains are in operation.
The train control system of Claim 1, wherein:
the communication unit is further configured to collect a first set of operation data from the first set of trains; and
the parameter management unit is further configured to:
derive, based on the first set of operation data, the first set of train parameters for the first set of trains; and
store the first set of train parameters in the parameter file database.
The train control system of Claim 4, wherein:
the parameter management unit is further configured to utilize an optimization technique to derive the first set of train parameters for the first set of trains.
The train control system of Claim 1, wherein the first set of train parameters and the set of parameter setting confirmation data are transmitted using different communication protocols.
The train control system of Claim 1, wherein the first set of train data includes one or more selected from the group consisting of:
a set of train length data;
a set of driver identification data; and
a set of bogie cut-off data.
The train control system of Claim 1, wherein the first set of train parameters include one or more selected from the group consisting of:
a train speed range;
a train deceleration rate;
a train acceleration rate; and
train emergency brake characteristics.
A train control device provided in a train control server configured to communicate with one or more trains via a communication network in a distributed computing environment, the train control device characterized by:
a train control device comprising:
a parameter management unit configured to store a parameter file database that manages one or more train parameters for the one or more trains;
a train parameter verification unit configured to verify an integrity level of a set of train parameters; and
a communication unit configured to perform communication between the parameter management unit and a first set of trains;
wherein:
the parameter management unit is configured to:
select, in response to receiving a first set of train data associated with the first set of trains, a first set of train parameters based on the first set of train data from the parameter file database;
the communication unit is configured to:
transmit the first set of train parameters to the first set of trains; and
receive, from the first set of trains, a set of parameter setting confirmation data;
the verification unit is configured to:
verify, by comparing the set of parameter setting confirmation data with the parameter file database, that the set of parameter setting confirmation data achieves an integrity level with respect to the parameter file database; and
the communication unit is further configured to:
transmit, in response to verifying that the set of parameter setting confirmation data achieves an integrity level with respect to the parameter file database, an operation approval command to the first set of trains.
A train control method performed by a train control device provided in a train control server configured to communicate with one or more trains via a communication network in a distributed computing environment, the train control method characterized by:
selecting, using a parameter management unit, a first set of train parameters based on a first set of train data stored in a parameter file database in response to receiving a first set of train data associated with a first set of trains;
transmitting, using a communication unit, the first set of train parameters to the first set of trains;
receiving, using the communication unit, a set of parameter setting confirmation data from the first set of trains;
verifying, using a train parameter verification unit to compare the set of parameter setting confirmation data with the parameter file database, that the set of parameter setting confirmation data achieves an integrity level with respect to the parameter file database; and
transmitting, using the communication unit, an operation approval command to the first set of trains in response to verifying that the set of parameter setting confirmation data achieves an integrity level with respect to the parameter file database.