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

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

[Technical Field]

[0001]

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

train control method.

[Background Art]

[0002]

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.

[0003]

Distributed computing environments offer one method of increasing the flexibility of

train control systems. For example, US 2015/0232110 Al 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).

[Citation List]

[Patent Literature]

[0004]

[Patent Document 1] US 2015/0232110 Al

[Summary of Invention]

[Technical Problem]

[0005]

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.

[0006]

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.

[0007]

One embodiment of the present invention relates to a train control system in a

distributed computing environment, comprising: 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 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 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.

[0007a]

According to another embodiment there is provided 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 comprising: 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.

[0007b]

According to a further embodiment there is provided 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 comprising: 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.

[0008]

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.

[Brief Description of Drawings]

[0009]

[Fig. 1]

FIG. 1 illustrates an exemplary computing infrastructure for executing the

embodiments of the present disclosure.

[Fig. 2]

FIG. 2 is an example high level system configuration of a train control system,

according to embodiments.

[Fig. 3]

FIG. 3 illustrates a functional configuration of a train as part of a train control system,

according to embodiments.

[Fig. 4]

FIG. 4 is a conceptual illustration of train parameters in the onboard unit (OBU) of a

train.

[Fig. 5]

FIG. 5 illustrates an example of a various interfaces for carrying out the embodiments

of the present disclosure.

[Fig. 6]

FIG. 6 illustrates a first example of information stored in a parameter file database,

according to embodiments.

[Fig. 7]

FIG. 7 illustrates a second example of information stored in a parameter file database,

according to embodiments.

[Fig. 8]

FIG. 8 illustrates a third example of information stored in a parameter file database,

according to embodiments.

[Fig. 9]

FIG. 9 is a flowchart illustrating a method of managing train parameters according to

embodiments.

[Fig. 10]

FIG. 10 is a flowchart illustrating a train parameter verification method according to

embodiments.

[Fig. 11]

FIG. 11 is a flowchart illustrating a method of updating train parameters according to

embodiments.

[Fig. 12]

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]

FIG. 13 is a flowchart illustrating an example of a fail-safe network architecture for

train parameter updating, according to embodiments.

[Fig. 14]

FIG. 14 is a flowchart illustrating an example of updating the train parameters of

multiple sets of trains, according to embodiments.

[Fig. 15]

FIG. 15 is a flowchart illustrating an example of updating train parameters in real

time, according to embodiments.

[Description of Embodiment(s)]

[0010]

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.

[0011]

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.

[0012]

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.

[0013]

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.

[0014]

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.

[0015]

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.

[0016]

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.

[0017]

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.

[0018]

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.

[0019]

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.

[0020]

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.

[0021]

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).

[0022]

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.

[0023]

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.

[0024]

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.

[0025]

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.

[0026]

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.

[0027]

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.

[0028]

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.

[0029]

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.

[0030]

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.

[0031]

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.

[0032]

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.

[0033]

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.

[0034]

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.

[0035]

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.

[0036]

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.

[0037]

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.

[0038]

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.

[0039]

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.

[0040]

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.

[0041]

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.

[0042]

FIG. 7 illustrates an example of a parameter database file 585 stored in a parameter

file database, 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 include device units, suppliers, ranges, and values for

parameters such as brake positions, axles, loading gauges, and the like.

[0043]

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.

[0044]

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.

[0045]

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.

[0046]

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.

[0047]

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.

[0048]

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.

[0049]

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.

[0050]

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.

[0051]

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.

[0052]

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.

[0053]

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.

[0054]

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.

[0055]

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, 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.

[0056]

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.

[0057]

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.

[0058]

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.

[0059]

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.

[0060]

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.

[0061]

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.

[0062]

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.

[0063]

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.

[0064]

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.

[0065]

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.

[0066]

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.

[0067]

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).

[0068]

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.

[0069]

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.

[0070]

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.

[0071]

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).

[0072]

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 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.

[0073]

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.

[0074]

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.

[0075]

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.

[0076]

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.

[0077]

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.

[0078]

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.

[0079]

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.

[0080]

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.

[0081]

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.

[0082]

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.

[0083]

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.

[0084]

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).

[0085]

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).

[0086]

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.

[0087]

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.

[0088]

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.

[0089]

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.

[0090]

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.

[0091]

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.

[0092]

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.

[0093]

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.

[0094]

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.

[0095]

The reference in this specification to any prior publication (or information

derived from it), or to any matter which is known, is not, and should not be taken as,

an acknowledgement or admission or any form of suggestion that prior publication (or

information derived from it) or known matter forms part of the common general

knowledge in the field of endeavour to which this specification relates.

[0096]

Throughout this specification and the claims which follow, unless the context

requires otherwise, the word "comprise", and variations such as "comprises" or

"comprising", will be understood to imply the inclusion of a stated integer or step or

group of integers or steps but not the exclusion of any other integer or step or group of

integers or steps.

Claims (10)

The claims defining the invention are as follows:

1. A train control system in a distributed computing environment, comprising:

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.

2. 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.

3. The train control system of either Claim 1 or Claim 2, 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.

4. The train control system of any one of Claims 1 to 3, 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.

5. 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.

6. The train control system of any one of Claims 1 to 5, wherein the first set of

train parameters and the set of parameter setting confirmation data are transmitted

using different communication protocols.

7. The train control system of any one of Claims 1 to 6, 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.

8. The train control system of any one of Claims 1 to 6, 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.

9. 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 comprising:

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.

10. 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 comprising:

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.