WO2010096730A1

WO2010096730A1 - System and method for controlling a powered vehicle

Info

Publication number: WO2010096730A1
Application number: PCT/US2010/024844
Authority: WO
Inventors: Todd Goodermuth; Richard Hooker; Glenn Robert Shaffer; Ajith Kuttannair Kumar; Brian D. Lawry; Mark Alan Linebach
Original assignee: General Electric Company
Priority date: 2009-02-23
Filing date: 2010-02-20
Publication date: 2010-08-26

Abstract

An operating system for controlling a powered vehicle includes a plurality of controllers or other control subsystems and a communication system. The control subsystems are onboard the powered vehicle for controlling multiple operations of the vehicle. At least one of the control subsystems has a memory in which vehicle control system data is stored and the data is accessible and used by one or more of the other control subsystems for controlling vehicle operations. The communication system controls the sharing of the data across the plurality of control subsystems on the vehicle, and includes an open defined interface unit configured so that the control subsystems may access the data in a common defined manner with predictable results.

Description

SYSTEM AND METHOD FOR CONTROLLING A POWERED VEHICLE

BACKGROUND OF THE INVENTION

Embodiments of the invention relate to control and communication systems in a locomotive or other powered vehicle.

In addition to the system producing motive power, a locomotive or other powered vehicle will typically include a plurality of other subsystems that perform different functions, such as, but not limited to, distributed power operations, energy management applications, train (or other vehicle consist) control applications, vehicle management system applications, display and event recorder applications, brake control system applications, etc. Such subsystems are oftentimes not seamlessly integrated, resulting in system inefficiencies.

Vehicle operators and owners would benefit from a vehicle operating system or method that provides for better integration and communication between control subsystems in a vehicle.

BRIEF DESCRIPTION OF THE INVENTION

An embodiment of the present invention relates to an operating system for controlling multiple operations of a powered vehicle (i.e., the operating system is a vehicle operations control system). The operating system includes a plurality of controllers or other control subsystems and a communication system. The control subsystems are onboard the powered vehicle for controlling multiple operations of the vehicle. At least one of the control subsystems has a memory in which vehicle control system data and/or other vehicle data is stored and the data is accessible and used by one or more of the other control subsystems for controlling vehicle operations. The communication system controls the sharing of the data across the plurality of control subsystems on the vehicle, and includes an open defined interface unit configured so that the control subsystems may access the data in a common defined manner with predictable results. Thus, in one aspect, "open defined interface" refers to an interface between systems/subsystems in a vehicle (as effectuated by the interface unit) for the exchange of vehicle control system data and/or other vehicle data or other data, which is open for access by a plurality of applications in a common, defined manner. "Predictable" results means the control subsystems are aware of the operational structure and protocol of the open defined interface, and therefore able to operate with a priori knowledge of what will happen when they interact with or operate according to the open defined interface.

Another embodiment relates to an operating system, onboard a powered vehicle, for controlling multiple operations of the powered vehicle. The operating system comprises a communication system for controlling sharing of data across a plurality of subsystems on the vehicle. The communication system comprises an open defined interface unit configured so that a plurality of applications may access vehicle control system data and/or other vehicle data in a common defined manner with predictable results.

Another embodiment relates to a method for controlling a powered vehicle. The method comprises autonomously managing a transmission of data from a vehicle control system to a plurality of applications, between the plurality of applications, from a sensor to one or more of the plurality of applications, from a communication management unit to the plurality of applications, and/or from off-board the vehicle to the plurality of applications. The method further comprises autonomously managing a transmission of data received from the plurality of applications to determine which application data is provided to the vehicle control system. The method further comprises operating the vehicle based on the application data provided to the vehicle control system.

Another embodiment relates to an operating system, onboard a powered vehicle, for controlling multiple operations of the powered vehicle. The operating system includes a plurality of control subsystems onboard the powered vehicle for controlling multiple operations of the vehicle. At least one of the control subsystems has a memory in which data is stored and the data is accessible and used by one or more of the other control subsystems for controlling vehicle operations. The operating system further includes a communication link between the control subsystems for sharing the data stored in the memory of one of the control subsystems to control operations of the powered vehicle.

In another embodiment, an operating system for a powered vehicle includes a plurality of control subsystems onboard the powered vehicle for controlling multiple operations of the vehicle. The operating system also includes a non-distributed memory in which data is stored. The data relates to operations and control of the powered vehicle. The operating system also includes a communication link between the control subsystems and the memory for the control subsystems to obtain the data from the memory and store the data in the memory. The non-distributed memory is the sole data storage in the powered system for long term storage of the data for the plurality of control subsystems.

BRIEF DESCRIPTION OF THE DRAWINGS

A more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof that are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the embodiments of the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. l is a schematic illustration of a powered vehicle incorporating an embodiment of the invention;

FIG. 2 is a schematic illustration of an onboard operating system according to a second embodiment of the invention;

FIG. 3 is a flow chart of a control method according to an embodiment of the invention;

FIG. 4 is a block diagram illustrating an exemplary embodiment for distribution of data between subsystems of a powered vehicle; FIG. 5 is a schematic diagram of a control manager, according to an aspect of the invention;

FIG. 6 is a block diagram illustrating an exemplary embodiment for distribution of data between vehicle subsystems; and

FIG. 7 is a flowchart illustrating an exemplary embodiment of a method for distribution of data between vehicle subsystems.

DETAILED DESCRIPTION OF THE INVENTION

Reference will be made below in detail to exemplary embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numerals used throughout the drawings refer to the same or like parts. Embodiments of the invention can be implemented in numerous ways, including as a system (including a computer processing system), a method (including a computerized method), an apparatus, a computer readable medium, a computer program product, or a data structure tangibly fixed in a computer readable memory. Several embodiments of the invention are discussed below.

Certain aspects of the invention are described herein with reference to trains and locomotives that travel over a railroad track. However, unless otherwise specified (such as in the claims), all the various embodiments set forth herein are applicable to powered vehicles more generally, including marine vessels, off-highway vehicles, on- road vehicles, and the like. The term "powered vehicle" as used herein refers to a vehicle that includes equipment for self-propulsion, which may also have the capacity for moving other, linked vehicles. (A group of vehicles that are linked to travel together is a "consist.") "Non-powered" vehicle refers to a vehicle that is not capable of self-propulsion. The term "track" as used here shall encompass all different pathways or routes for a vehicle, such as railroad tracks and other vehicle guideways, off-road and off-highway routes, paved and graded roads and other roads suitable for on-road travel, and marine routes, unless otherwise specified. FIG. 1 is a schematic view of a train 10 (or other vehicle consist) that includes at least one locomotive 11 (or other powered vehicle) and a plurality of railcars 12 (or other non-powered vehicles). The locomotive 11 includes an onboard operating/control system 13 comprising at least two controllers or other control subsystems that control certain locomotive functions. In the embodiment shown in FIG. 1, the operating system 13 includes four controllers or other control subsystems 14A, 14B, 14C, and 14B. ("Control subsystem" refers to part of the overall control system of a powered vehicle, which is configured for carrying out a particular control function in the powered vehicle; control subsystems may be electronic or electro-mechanical, and may include microcontrollers or other controllers for coordinating/executing the control function of the subsystem.) By way of example, controller (or other control subsystem) 14A may be a tractive control subsystem that generates tractive effort commands and/or braking effort commands responsive to an operator's request or otherwise; controller (or other control subsystem) 14B may be an operating coaching subsystem that assists an operator in maintaining the operation of the locomotive 11 within certain predetermined limits such as a maximum tractive or braking effort, minimum or maximum acceleration/deceleration rates, speed limits, and operating sequences for bells and horns; controller (or other control subsystem) 14C may be a fuel savings subsystem that controls braking and propulsion operations to achieve fuel, emissions, and noise limits or goals; and controller (or other control subsystem) 14D may be a traffic signal control subsystem that receives and responds to off board signals such as switching signals, light signals, cab signaling equipment, and speed restriction signals. Embodiments of the present invention are intended to cover an onboard operating system of a powered vehicle that includes a plurality of, or at least two, controllers (or other control subsystems), and is not necessarily limited to the embodiment shown in FIG. 1 that includes four controllers (or other control subsystems) unless otherwise specified. One or more of the controllers (or other control subsystems) 14A-14D may each include a memory 16 in which data is stored and used by a respective controller (or other control subsystem) to control certain locomotive or train operations. Such data may include, for example, data relative to a track database (wherein, as noted above, "track" refers to any designated route), a train manifest (or, more generally, a vehicle manifest), vehicle operating parameters (e.g., train or other vehicle consist operating parameters), and/or wayside traffic signal status.

More specifically, a track database may include track grade data at various points of interest along the track, track curvature data, civil speed limits and temporary speed restrictions, elevation of the track at selected locations, locations of bridges and tunnels, and the locations of wayside traffic control devices along the track. In the case of a train, train manifest may include data relative to the identification of the locomotive 11 and each of the railcars 12 in the train 10, the length and weight of the train 10, and contents of the railcars. Some railcars may contain materials (e.g., hazardous or flammable chemicals) that require special speed restrictions at selected locations along the track. So the train manifest data may also have data relative to speed restrictions. In addition, or alternatively, such speed restriction and materials data may be stored in the track database.

The data in the track database remains relatively constant with the exception of perhaps the temporary speed restrictions, which may be updated as often as necessary. In an embodiment, the track profile data may be entered directly in the onboard operating system 13 and control subsystems 14A-14D from a single source such as the railroad or track company. Alternatively, or in addition, one or more vendors of the control subsystems 14A-14D may obtain the track profile data from a railroad or track owner and enter the data. In as much as the train (or other vehicle) manifest data may change from day to day, or from trip to trip, the train manifest data may be provided at a dispatch center.

FIG. 2 is a schematic view of a system and method for transmitting data, such as track profile data and train/vehicle manifest data, from an off-board memory to an onboard storage device. More specifically, such a system may provide for the wireless transmission or other communication of data to be stored in a memory onboard the locomotive or other powered vehicle 11. The track profile data and train (or other vehicle) manifest information is typically stored on a first computer module/server 20 operated by entities that own and/or operate the locomotive 11 and trains 10 (or other vehicle or vehicle consist), or that own the track system on the which the trains 10 travel. A second computer module/server 21 is provided and linked to the first server 20 and is allowed limited access to the first server 20 in order to access the track profile data and train manifest data. The servers 20 and 21 may be linked via the Internet, local area networks, direct cable links, etc. The second server 21 may be located at the same train station or other location as the first server 20, or it may be remotely located elsewhere at another business site or other location, or it could be located onboard the locomotive or other vehicle 11. A communication modem or other communication device 22 may be provided for the wireless transmission of data between off-board devices and on-board systems, via satellite, Wi-Fi, wireless LAN, or other wireless data transmission capabilities.

Data is transmitted via signal 23 to the onboard operating system 13 of the locomotive (or other vehicle) 11. A vehicle operator 26 or other person that accesses the first server 20 via the second server 21 (or vice-versa) may provide an access or verification code; or, one of the servers 20, 21 may be configured to provide a verification of the user to allow access to the data for transmission. (Thus, the system includes at least one verification access code associated with the vehicle and/or an operator of the vehicle to access and transmit data from an off-board memory (the server) to the onboard operating system of the vehicle; in an embodiment, a valid verification access code must be provided for accessing and/or transmitting data.) In an embodiment shown in FIG. 2, the data transmitted may be stored in a central database 24, and each of the control subsystems 14 can access the database 24 to obtain the information necessary for the operation of a respective controller or other control subsystem.

With respect to the embodiment as shown in FIG. 1, the transmitted data may be stored in the respective control subsystems 14A-14D. More specifically, the data may be parceled so that data used by one or more of the control subsystems 14A-14D is stored in local control subsystem memory 16 or a data storage device for the control subsystems 14A-14D. For example, control subsystem 14A may utilize track grade data more frequently than the other control subsystems 14B-14D, so the track grade data is stored in memory 16 of control subsystem 14A. Thus, embodiments of the invention relate to distributing and storing vehicle operational data among various control subsystems of the vehicle, based on the relevancy of the data to the particular subsystem. For example, if a first data set is most relevant to a first control subsystem (e.g., the first data set is most likely to be used by the first control subsystem, as opposed to the other control subsystems, and/or the first data set contains data relevant to operations of the first control subsystem), and a second data set is most relevant to a second control subsystem, then the first data set may be stored at the first control subsystem and the second data set may be stored at the second control subsystem. (This would not necessarily preclude use of the data sets by other control subsystems, or that the data sets may be relevant, to a lesser extent, to other control subsystems.)

Data other than the track profile data and the train (or other vehicle) manifest information may be used with the disclosed system. Such data may include data that is acquired or stored during operation of the locomotive (or other powered vehicle) and/or data acquired while the train 10 (or other powered vehicle or vehicle consist) is traveling on the track. For example, data relative to locomotive/train (or other vehicle) operating conditions (altitude, vehicle position, ambient pressure, temperatures, dynamic braking information, horsepower, etc.), vehicle health, health of operating components on the locomotive or railcars or other vehicle, or wayside/signal information is stored during the operation of the locomotive 11 or train 10 (or other vehicle). Data relative to the location of the locomotive 11 (or other vehicle) on the track 15 may be received via a GPS transceiver 28. This information may be stored in one or more of the control subsystems 14A-14E. As discussed above, the data may be grouped and stored, or discrete data elements/pieces may be stored in a memory 16 of a respective control subsystem 14A-14D that uses the data the most often. For example, the data relative to health of the locomotive 11 (or other vehicle) or vehicle components may be stored in the memory 16 of a diagnostics controller or other diagnostics control subsystem.

The operating system 13 and controllers or other control subsystems 14A-14D may be configured to communicate or share data stored in their respective memories 16 through a local area network (LAN) system that incorporates Ethernet, Wi-Fi, or similar technologies, or through another type of communication link or system that allows for communication between the various control subsystems. In an embodiment shown in FIG. 1, a communication system 25 (which may be an integrated component or functional aspect of one of the control sub systems 14 A- 14D) is provided between control subsystems 14A-14D. The communication system provides a direct communication connection between any two or more control subsystems for sharing data stored in the memories 16 in the respective any two or more control subsystems. If more than two control subsystems 14 are used, then each control subsystem 14A-14D may be configured to know which control subsystem contains what data. For example, a control subsystem may be programmed to include data relative to the identity of each control subsystem in the operating system and the type of data stored in the memory 16 of each respective control subsystem.

In the embodiment shown in FIG. 1, the communication system 25 may include a communication router that is programmed to direct commands or requests for data from each control subsystem 14 to the appropriate control subsystem memory 16 that has the requested stored data. That is, the router 25 is programmed to identify the control subsystem 14A-14D and respective memory upon request. In this manner, the control subsystems 14A-14D are able to share track profile data and train (or other vehicle) manifest data, which data is the same for each control subsystem. Moreover, the data contains the most recent updates that are shared among the control subsystems 14A-14D.

FIG. 3 is a flowchart illustrating the steps of a method for controlling multiple operations of a powered vehicle having an onboard operating system, according to an embodiment of the invention. In step 30, a train (or other vehicle) operator or some other authorized individual may access the station (or other off-board) server 20 by entering a verification access code that allows the operator to access the server 20 from the locomotive (or other vehicle) 11. The operator 26 may also provide a vehicle identifier so the server 20 may access the track profile data and train (or other vehicle) manifest data associated with the vehicle identifier. In step 32, the data is transmitted to the onboard operating system 13. In addition, the operator 26 may review portions of the data, such as the vehicle identifier, the track sections, some of the railcar 12 identifiers, and/or a date at which the data was last updated, to verify that the train (or other vehicle) manifest data and track profile data is current. With respect to steps 34 and 36, once the operator has verified that the data is up to date, the data is transmitted from station (or other off-board) server 20 to the onboard operating system 13. During operation of the locomotive (or other powered vehicle) 11, and in steps 38 and 40, control subsystems are able to communicate via a wireless network, by identifying a control subsystem 14A-14D and portions of data needed to transmit the updated data between control subsystems 14A-14D.

Embodiments of the invention may also include a computer readable memory media for controlling operations a powered vehicle, such as a locomotive, that includes an onboard operating system comprising a plurality of controllers (or other control subsystems) onboard the powered vehicle for controlling operations of the vehicle. A computer module is provided for storing data relating to the operations of the vehicle, which is accessible and used by at least two of the control subsystems for controlling vehicle operations. In addition, a computer module is provided for controlling transmission of data between the at least two control subsystems to control operations of the powered vehicle. The computer readable memory media may also comprise a computer module for identifying a control subsystem and pieces of data stored in the memory of the control subsystem and a computer module for transmitting the pieces of data from the identified control subsystem to a requesting control subsystem.

The computer readable memory media may be used in conjunction with the operation of a locomotive and train (or other powered vehicle or vehicle consist) and includes a computer module for storing data including train (or other vehicle) manifest data and/or a track database. The track database includes track profile data in a data storage device off-board the locomotive (or other powered vehicle). A computer module transmits at least a portion of the data to the operating system onboard the locomotive (or other powered vehicle) for storage. A computer module may be provided for entering an access verification code to access data stored in the off-board data storage device, and the data is transmitted to the operating system onboard the powered vehicle upon request. (In an embodiment, a correct access verification must be entered/provided to access and/or transmit data.) In addition, a computer module accesses manifest and track profile data associated with a locomotive (or other vehicle) 12 responsive to entry of the vehicle identifier.

Another embodiment relates to an operating system, onboard a powered vehicle, for controlling multiple operations of the powered vehicle. In this embodiment, the operating system comprises a plurality of controllers or other control subsystems onboard the powered vehicle for controlling multiple operations of the vehicle. The system also comprises a non-distributed memory in which data is stored. The data relates to operations and control of the powered vehicle. The system also includes a communication link or system between the controllers (or other control subsystems) and the memory for the controllers to obtain the data from the memory and store the data in the memory (i.e., read/write operations). The non-distributed memory is the sole data storage in the powered system for long term storage of the data for the plurality of controllers. "Non-distributed" memory refers to a memory that is logically contained within a single system entity, such as a stand-alone database, computer, or memory unit. "Long term" storage refers to non-temporary or non- transitory data storage, such as in a hard disk, flash storage, or other non-volatile memory, as opposed to cache or other processor memory or local data storage that temporarily stores data for processing purposes. Thus, as should be appreciated, the non-distributed memory of this embodiment in effect comprises a sole and centralized database, accessible for data retrieval and storage by the plural controllers, for storing operations and control data in the powered vehicle for the controllers. (This embodiment does not preclude an additional stand-alone processor and associated long-term memory for the stand-alone processor; however, the non-distributed memory of the above-described embodiment is the sole long-term data storage for the plurality of controllers connected to the non-distributed memory through the communication link or system.)

In another embodiment, the non-distributed memory is the sole data storage in the powered vehicle for the long-term storage of data for each and every controller (or other control subsystem) in the powered vehicle. Thus, the powered vehicle includes a plurality of controllers (or other control subsystems), wherein the plurality of controllers (or other control subsystems) comprises each and every controller (or other control subsystem) in the powered vehicle, which are connected to the non- distributed memory by way of a communication link or system.

Another embodiment relates to an operating system, onboard a locomotive, for controlling multiple operations of the locomotive. The operating system comprises a first controller (or other control subsystem) for controlling a positive train control system of the locomotive. The operating system also comprises a second controller (or other control subsystem) for controlling an operator coaching and/or operator interface system of the locomotive. The operating system further comprises a third controller (or other control subsystem) for controlling a trip planner and/or fuel savings system of the locomotive. The operating system still further comprises a memory and a communication link or system. Locomotive operations data is stored in the memory for each of the positive train control system, the operator coaching and/or operator interface system, and the trip planner and/or fuel savings system. The communication link or system is between the controllers and the memory, and allows the controllers to obtain the operations data from the memory and store the operations data in the memory. In an embodiment, the memory is a non-distributed memory, and the non-distributed memory is the sole data storage in the locomotive for long term storage of the operations data for the plurality of controllers and the positive train control system, the operator coaching and/or operator interface system, and the trip planner and/or fuel savings system.

Other embodiments of the present invention relate to a system, method, and computer software code for controlling sharing of data across a plurality of subsystems on a locomotive or other powered vehicle (such as the subsystems 14A-14D described above), for purposes of controlling the vehicle. The system is an operating system (for controlling a vehicle) that comprises a communication system having an open defined interface unit configured so that a plurality of applications may access locomotive (or other powered vehicle) control system data in a common defined manner with predictable results. Thus, in one aspect, "open defined interface" refers to an interface between systems/subsystems in a locomotive (as effectuated by the interface unit) for the exchange of locomotive (or other vehicle) control system data and/or other data, which is open for access by a plurality of applications in a common, defined manner. Each "application" may be a controller or other control subsystem, or a process, functional aspect, or other sub-portion of such a controller or other control subsystem (e.g., an application may be encoded program instructions running on the controller or other control subsystem).

FIG. 4 is a block diagram illustrating distribution of data between a control system 13 (or control subsystem) and applications 42. (Although the applications 42 are shown as being separate from the control system 13 in FIG. 4, it may instead or additionally be the case that the applications are part of the control system, such as if the applications are part of the control subsystems 14 shown in FIGS. 1-2.) The applications 42 are in communication with a data management unit, data distribution unit, or data manager 44. The terms "data management unit," "data distribution unit," and "data manager" are interchangeable terms since such units are configured to manage a distribution of data. (The data manager 44 may be part of the communication system 25, or it may be a separate entity; in an embodiment, there is one management and communication entity that performs the functions of the data manager 44 and communication system 25 described herein.) The underlying embodiment is an open defined interface so that any application may access locomotive (or other vehicle) control system data or other vehicle data in a common defined manner with predictable results. For example, certain applications may be considered source applications, while other applications may be considered service applications, where a service application may request data from either a source application or another service application, and a source application may request data from either a service application or another source application. (Source and service applications are described in more detail below.) In one embodiment, a common communication standard may utilize shared memory, such as provided with a communication management unit (CMU) as illustrated in FIG. 6, or in another embodiment as provided with an independent data management unit, or data distribution unit, as illustrated in FIG. 4. The communication may include requests between service applications and source applications, and/or transfer of data associated with maintaining and/or operating the locomotive (or other vehicle). For example, Application 1 of the plurality of applications 42 may be notified depending on whether other service applications and/or source applications are functioning or are not functioning. Once an application is functioning (more specifically, once an application is recognized through the communication standard), information from that application is identified to the other applications, and information from the now recognized application is available to the other applications. Thus, information from the other applications may be used by Application 1 as it performs its intended function.

In an embodiment, the communication requests may be accomplished with a "publish" and "subscribe" concept (control scheme). The source applications are considered publishers, which declare to send and then publish data available by or from the source application. The service applications are considered subscribers, which declare (request) to receive data and where the data requested is autonomously delivered. Some applications may be both source applications and service applications. The term "autonomous" is defined as being able to perform an intended function with none to minimum operator (e.g., human operator of a locomotive) input. In an embodiment, "autonomous" is limited to performing an intended function without any operating input.

The communication requests are communicated through a communication standard, as implemented on or as part of one or more system components, e.g., the data manager 44 or otherwise. An example of a communication standard is a data- distribution service for real-time systems (DDS) standard. The DDS standard is a middleware standard that directly addresses publish-subscribe communications for real-time and embedded systems. The DDS standard provides for a virtual global data space where applications 42 can share information by simply reading and writing data-objects addressed by means of an application-defined name, or topic, and/or a key that is unique to a specific application. Use of the DDS standard provides for extensive control of quality of service parameters, such as but not limited to reliability, bandwidth, delivery deadlines, and resource limits. Thus, the communications between the service applications and source applications are able to provide for one-to-many data transfers, many-to-one data transfers, many-to-many data transfers, topic-based data transfer, and/or multi-rate message transfer.

In another embodiment, a data dictionary is provided which defines all data available from a control manager 46, described in further detail below. The data dictionary may be unique to each type of locomotive (or other vehicle). The sort of information contained within the data dictionary may include, but is not limited to, specified frequencies at which data is delivered. For example, some data may be provided at 1 Hertz (Hz), while other data is provided at 10 Hz, and still other data is provided at 0.2 Hz. A data dictionary may also be provided that defines data available to at least one of the plurality of applications and/or a command request available from the control manager unit. The data is provided based on a relative priority of the applications, after validating the authority of the application to receive the requested data. The data manager 44 maintains the authority level of each application to receive certain classes of data and its relative application priority.

Though the term "source application" and "service application" are used above, each of these terms may be used interchangeably with respect to how a certain application is being used at any given time. Therefore, for simplicity, "application" will be used instead of these more specific terms.

The data manager 44 may be a standard locomotive standard integration ("LSI") box or hardware with appropriate processor and software applications. The data manager 44 allows for the applications 42 to request and be supplied with data where the data may be from the data manager 44, sensors 48, information from off-board the locomotive (such as but not limited to information from a remote track database), and/or data from other applications 42. To perform this function, the data manager 44, a control system 13 of the locomotive, and each application 42 are in communication directly or indirectly. Some or all of the communication functions of the data manager 44 may be performed through a finite sequence of instructions, an explicit, step-by-step procedure for solving a problem, or an algorithm, that performs its functions in a processor 50 that is a part of the data manager 44. (Alternatively or in addition, functions of the data manager may be performed by a controller or other control subsystem 14.)

Any one of the on-board applications 42 can request data. Data would then be provided at a specific frequency, as provided by the control system 13 (or a controller or other control subsystem) and the data manager 44. In an embodiment, the specific data and frequency available are published so that application designers can design applications 42 to operate within these limitations. The data manager 44 may also be configured to include distribution of dynamic wayside data that may include, but is not limited to, data associated with signal aspect, switch position, crossing gate position, etc.

Information, or data, is provided from the control system 13, through the data manager 44 to the applications 42. The communication connection between the data manager 44 and the control system 13 is through a private interface 52. All of the interfaces 52, 54 disclosed herein may be Ethernet based. Having the private interface 52 means that communications between the control system 13 and any other devices are limited, e.g., with a proprietary connection protocol, to ensure that the other devices are designed to communicate with the control system 13 so as not to interfere with the operation of the control system 13. For example, if an attempt is made to bypass the data manager 44 and connect an application 42 directly to the control system 13, such a bypass attempt would not be possible without knowing the proprietary connection protocol.

The communication connection between the data manager 44 and the applications 42 is an open interface 54. Having an open interface 54 means that other devices and/or applications may be connected through the open interface 54, wherein once connected the connection protocol allows for the transmission of data or information through the open interface 54. The open interface 54 also provides for a uniform, possibly even simplified interface.

As disclosed above, the type of data that can be provided to the applications 42 is not limited to data gathered from the control system 13. The track data that may be provided from off-board the locomotive may be provided through the data manager from an external source. The data may be received via an 802.11 wireless local area network to reduce the cost, or in-route as necessary via a satellite/cell phone and then communicated to the data manager 44, such as may be available via a CMU or a mobile access router. Additionally, prime directive data (track authorities and speed restrictions) data may also be provided through the data manager 44.

An example of sensor data that is provided may include common global positioning system ("GPS") data, wheel speed data, fuel consumption, etc. By using the data manager 44 to provide sensor data to applications 42, sensor replication aboard the locomotive (or other vehicle) is not required. Since sensors 48 are part of the locomotive (or other vehicle), and are likely to be used within the control system 13, data from the sensors 48 may be provided through the private interface 52 connecting the data manager 44 to the control system 13. Though only one sensor 48 is illustrated, this single sensor is representative of any number of sensors 48. Additionally, though the sensor 48 is illustrated as being a subset of the control system 13, the sensor 48 may be an independent element, having its own interface, either a private interface 52 or an open interface 54. As disclosed in FIG. 6, other types of sensors are illustrated where the sensors may be considered source applications.

Additionally, the data manager 44 may be configured to solve application data distribution issues. For example, if two applications 42 are requiring data at the same time where bandwidth is not available for delivery of the data to both of the applications simultaneously, the data manager 44 will schedule delivery of the data. The delivery of the data may be based on any number of factors including, but not limited to, priority, bandwidth, duration, vitality, etc. The data manager 44 may also be used to solve data currency issues.

In operation, the applications 42 are able to register and/or communicate their data needs with the data manager 44. For example, Application 1 may require track data at a certain rate, such as but not limited to a given distance ahead of a current location. The data manager 44 is also able to collect data from other applications, and/or the control system, and provide Application 1 the data required, without impacting the source application. Thus, the data manager 44 provides sharing of data between applications 42 without impact to any of the applications 42. Additionally, point-to- point interface definitions, which may be costly, between the applications 42, and/or the control system 13 are no longer needed since a common interface is provided through the data manager 44.

A common interface is used to provide information from the applications 42 to the control system 13. The common interface is identified as the locomotive (or other vehicle) control manager unit 46, or locomotive (or other vehicle) control manager, and it is a single integration point for all applications 42 that want to provide control input to the locomotive. The "control input" may be data (e.g., data to be provided to the control system 13; some such data, originating from the applications 42, is referred to herein as "application data") and/or a command request, e.g., a request that the control system act upon a particular command. As illustrated in FIG. 5, elements of the control manager 46 may include, but are not limited to, a connector 56 for the open interface 54 to receive control requests from the applications 42, a processor 58 that has an algorithm/software 60 which is operable within the processor 58 to perform the functions discussed below, and a connector or other control system interface 62 specific to the control system 13 for a specific type of locomotive (or other vehicle), as illustrated by "Locomotive A," "Locomotive B," "Locomotive C," and "Locomotive D." Examples of different specific types of locomotives include an EMD SD70™ locomotive, a General Electric (GE) Dash 9™ locomotive, a GE AC4400™ locomotive, and/or a GE Evolution™ series locomotive. The data manager 44 also is equipped with a similar connector 56 for the open interface, a processor 50 in which an algorithm may operate, and a connector for the private interface 52.

The interface between the applications 42 and the control manager 46, or receiving interface, is an open interface 54, which provides a common interface for the applications 42 to access the locomotive control system 13. The interface between the control manager 46 and the control system 13 is a private interface 52. Aspects of the control system 13 that are accessible and controlled include, but are not limited to, throttle or notch control, dynamic brake control, automatic airbrake control, wireless distributed power, wired distributed power, independent brake control or operation, etc. The control manager 46 is able to authorize and prioritize to avoid an undesired state or conflict for controlling data (and other control input) provided from the applications 42 to the locomotive control system 13 that is able to de-conflict any conflicting input from on-board diverse applications like a train control application or an energy management application.

In operation, the control manager 46 processes control input received from the plurality of applications 42, for providing to the control system 13 or otherwise. For example, the control manager 46 may receive application data from the applications 42 (or other data) and process the data for selectively providing the data to the control system, e.g., for determining which application data is provided to the locomotive control system. (For example, it may be the case that data is only provided based upon the needs or requests of the control system 13, or that certain data is only provided depending on the operational state of the control system and/or locomotive generally.) In another example, the control manager 46 may receive command requests from the plurality of applications 42 and determine which of the received command requests is provided to the control system for use in operating the locomotive. This determination may be based on time factors (when the command requests are received, and the timeliness of the command requests), a priority hierarchy among types of different command requests, the relationship between a particular command request and the current operational mode of the locomotive or other vehicle (e.g., certain requests may only be applicable when the locomotive is in a particular mode of operation), the relation between a particular command request and other command requests received either before or after the command request (e.g., one command request may be moot in light of a previously recently received command), etc. In another aspect, the control manager 46 is able to resolve conflicts between the applications 42 and between control input received from the applications. For example, if a locomotive or other vehicle is equipped with an energy management application and a train/vehicle control application, and if the train/vehicle control application does not have the appropriate movement authority to transition the locomotive or other vehicle over a piece of track (or other route), or within a certain territory, it may call for a stop (stop command request) via the train automatic brake application. At the same time, the energy management application may not be aware that the train is not authorized to proceed and may call for notch 6 (throttle command request) over a given territory. The control manager 46 would be able to resolve the conflict by using data from one or more other applications 42 and/or based on a priority that is preset within the control manager 46 that establishes application priority. The control manager 46 is also able to override and/or isolate an application that is malfunctioning. As disclosed above, it also provides for safe interlocks among the controls. Additionally, as disclosed in further detail below, the control manager 46 is able to receive inputs from an operator, which is sent to the control system 13 for implementation. These manual inputs also have to be de-conflicted with requesting applications.

In one embodiment, the data that is being passed from the control system 13 through the data manager 44 and control manager 46 and to the applications 42 is real-time data. Thus, the implementation of controlling the system is accomplished with current data. As further illustrated in FIGS. 4 and 6, a system and/or process are provided. By having a closed loop control system/process, control of the locomotive may be autonomously performed, where inputs from an application, such as, but not limited to, an energy management application and/or a train (or other vehicle) control application, determines a speed to operate over a route based on the train/vehicle consist and terrain, and the control manager 46 operates the throttle and brake in accordance with the inputs. More specifically, the control manager 46 autonomously provides directions, or commands, to the control system 13, which in turn commands the throttle (e.g., notch setting), dynamic brake, automatic train air brake, independent brake, and direction of travel of the locomotive. (For example, providing autonomous operation of the locomotive or other vehicle may comprise providing braking and throttle commands to define speed and/or movement authority to operate over a route by the locomotive or other vehicle.) Hence, the locomotive is able to operate in an "autopilot" mode. Examples of the energy management application and a variation of the control manager 46 are disclosed in trip/mission optimizer patent applications assigned to the Assignee of the present invention, such as U.S. Publication Nos. 2008/0082223, 2007/0219683 and 2007/0219680 (see, for example, U.S. Publication No. 2007-0219680-A1 dated September 20, 2007). The closed loop control system includes at least one application 42, the control system 13, and the control manager 46. The closed loop control system may also include the data manager 44. (Generally speaking, the closed loop control system, in any of the embodiments herein, is characterized by the operation of the locomotive or other vehicle being regulated by, or otherwise based on, feedback regarding the locomotive's operation and operational performance, e.g., the locomotive or other vehicle is operated based both on control input and on sensed feedback of one or more operational characteristics of the locomotive or other vehicle, such as actual speed, actual direction, acceleration, sensed location, and the like. More generally, the closed loop control system may be characterized in that an input forcing function is determined in part by a vehicle system response, wherein a measured response of a vehicle system is compared with a desired response, and the difference between these two responses initiates actions that will result in the actual response of the vehicle system to approach the desired response.)

FIG. 6 is block diagram illustrating distribution of data between a control system and applications also with a display manager unit, or display manager 64. The display manager 64 is used to decide which data is communicated to an operator onboard the locomotive. At least one common display 66 is also provided. Those skilled in the art recognize that a plurality of common displays may be provided. When the operator desires information specific to a certain application and/or an operating aspect of the control system 13 and/or locomotive, the operator is able to select that application 42 and/or the operating aspect of the control system 13 and/or locomotive.

The terms "display manager" and "display" are terms not meant to be limited to providing only data visually to the operator. The display manager may provide a flow, or transmission, of data made available to an operator as visual data, tactile data, and/or audio data. Therefore, the display may be a device that provides the information to the operator in the intended form identified, such as but not limited to visually, through touch, and/or audible. The terms "flow" or "transmission" are not meant to be limiting. These terms are used to include for a distribution of data between two locations, such as but not limited to units, applications, and/or devices.

The display manager 64 is connected directly to the applications 42 through a negotiated interface 68, or more specifically an interface that is defined specific for each application's purpose. The interface between the display 66, user interface 70, and display manager 64 may also be a private interface.

FIG. 6 also illustrates the data manager 44 being connected to a communication management unit ("CMU") 72. Thus, in implementation, instead of the functionality of the CMU 72 being integrated within a single data manager unit, a data manager unit may be connected to an existing CMU 72. The CMU 72 is also in communication with the locomotive control system 13 using its own private interface 52. The connection between the data manager 44 and the CMU 72 may be either a private interface 52 or an open interface 54. The data passed from the CMU 72 to the data manager 44 is data needed by the applications 42, and is generally information that the CMU 72 received from sources that are remote from the locomotive.

A file management staging unit ("FMS") 74 may be part of the data manager 44. The FMS 74 is provided to receive and distribute application replacement/updates for the applications and/or sensors, where the sensors are considered source applications. As illustrated, examples of such source applications include, but are not limited to GPS, Movie Picture Expert Group ("MPEG") encoder, fuel ("FLM") indicator, event recorder ("ER"), etc. The replacement/updates may be provided from an external source from the locomotive, where the data is communicated through the CMU 72, or as illustrated in FIG. 4 though the data manager 44, which includes CMU-like functionality.

The representations of the applications 42 in FIGS. 4 and 6 as blocks are provided to represent that each application performs a unique function. In operation, each application may have its own hardware and software components, or instead of each application having its own hardware, each application (or software, or algorithm) is housed within hardware where all hardware has a common bus and/or a common housing where common processors are used (as in FIGS. 1-2). Servers may be provided, where multiple applications are stored in each server. Instead of allowing any application to reside on any server, the importance of the application may determine which server is installed within. For example, a non-vital server may be used for non-vital applications while a vital server may be used for vital applications. In such a configuration, the vital server may have more redundancy than the non-vital server. Additionally, when multiple servers are used (either hosting an individual application per server or applications grouped together on designated servers), the servers and hence the applications, may use multicasting, or multicast delivery, to publish data. Those skilled in the art will readily recognize that "multicast," or "multicasting," refers to using a network technology for the delivery of data, or information, to a group of destinations simultaneously using the most efficient strategy to deliver the messages over each link of the network only once, creating copies only when links to the multiple destinations split.

Although the control manager 46 is illustrated in FIGS. 4 and 6 as being separate from the control system 13, the control manager 46 may be a part of the control system 13, such as integrated directly into the control system 13. The data manager 44 may be a part of the CMU 72, more specifically hosted within existing CMU chassis and/or processor. Additionally, the interfaces 52, 54 may be part of a router to communicate data from the data manager 44 to the applications 42 and from the applications 42 to the control manager 46. Similarly, even though the data manager 44 and control manager 46 are displayed as being two separate units, those skilled in the art will recognize that these units may be a single unit, and/or within a common housing. Thus, the data manager 44 and control manager 46 within the common housing (or even as separate units) may be considered an open defined interface unit. Towards this end, the processor 50 that is part of the data manager 44 and the processor 58 that is part of the control manager 46 may be a single processor. In general, those skilled in the art will recognize and understand that illustrating all of the units as blocks in FIGS. 4 and 6 is done solely to illustrate functionality of the various units/elements disclosed herein, and should not be considered limiting with respect to packaging. FIG. 7 is a flowchart 76 of a method for operating a locomotive or other vehicle. The flowchart 76 illustrates autonomously managing a flow of data from a control system of the locomotive or other vehicle to a plurality of applications, between the plurality of applications, from a sensor to the plurality of applications (or to other applications), and/or from a communication management unit to the plurality of applications, at 78. The flowchart further illustrates autonomously managing a flow of data received from the plurality of applications to determine which application data is provided to the control system, at 80. The locomotive or other vehicle is operated with the application data provided to the control system, at 82. As discussed above, operating the locomotive or other vehicle may further include autonomously operating the locomotive or other vehicle by autonomously implementing changes to direction of travel, changes to notch/throttle or speed, and/or dynamic braking and air brake operation. Additionally, autonomously managing the flow of data from the locomotive (or other vehicle) control system, at 78, may further include distributing data to the plurality of applications based on an authority and/or priority for distributing data.

The method shown in the flowchart 76 may be performed with a computer software code having computer software modules where the computer software code is stored on a computer media and is executed with a processor. Thus, each process flow in the flowchart 76 is performed by a computer software module specific to the process contained in a specific process. For example, autonomously managing a flow of data from a control system of the locomotive (or other vehicle) to a plurality of applications, between the plurality of applications, from a sensor to the plurality of applications (or to other applications), and/or from a communication management unit to the plurality of applications, at 78, is performed by a computer software module for autonomously managing a flow of data from a control system of the locomotive to a plurality of applications, between the plurality of applications, from a sensor to the plurality of applications, and/or from a communication management unit to the plurality of applications.

As discussed above, one embodiment of the present invention relates to a communication system (different embodiments shown generally in FIGS. 4 and 6) for controlling sharing of data across a plurality of subsystems on a locomotive or other vehicle. In one embodiment, the communication system comprises an open defined interface unit, which establishes an interface between the locomotive/vehicle subsystems for the exchange of locomotive/vehicle control system data and/or other data. The interface is open for access by a plurality of applications in a common, defined manner. The "other" data may be data that is used by the subsystems/applications apart from the locomotive/vehicle control system; examples include: communication data to be transmitted off-board, but that does not originate with the control system, e.g., operator or voice dispatch communications; communications data received from off-board the locomotive or other vehicle that is not used for control purposes; data that is generated and/or stored for archival purposes; certain time data, location data, train/locomotive data, etc.; and the like.

In one embodiment, the open defined interface unit comprises, at least functionally speaking, a data manager 44 for managing data, as described above. In another embodiment, the open defined interface unit comprises, at least functionally, a control manager 46 for managing control input, as described above. In another embodiment, the open defined interface unit comprises, at least functionally, a data manager 44 for managing data (e.g., in the manner described above) and a control manager 46 for managing control input (e.g., in the manner described above). In one embodiment, the data manager 44 and control manager 46 are integrated into a single electronic unit, for systems simplification and/or efficiency purposes. In another embodiment, the data manager 44 and control manager 46 are separate electronic units that are housed in a common housing, for conserving space while providing interconnection and/or systems flexibility, e.g., in terms of how the data manager 44 and control manager 46 are connected and what they are connected to. In another embodiment, the data manager 44 and control manager 46 are separate electronic units that are housed in different housings, for providing a greater degree of flexibility in terms of system positioning and interconnection, e.g., the data manager 44 and control manager 46 can be positioned in different locations, for more flexibility in terms of what components/elements/subsystems in the locomotive they are connected to. In another embodiment, one or both of the data manager 44 or the control manager 46 are functionally implemented in an existing electronic subsystem of the locomotive (either the same electronic subsystem or in different subsystems), for system efficiency and ease of implementation.

Another embodiment relates to a communication system on a locomotive or other vehicle. The communication system comprises a data manager unit and a control manager unit. The data manager unit is configured to manage a transmission of data from a control system of the locomotive (or other vehicle) to a plurality of applications, between the plurality of applications, from a sensor to one or more of the plurality of applications, and from a communication management unit to the plurality of applications. The data manager unit is configured as an open defined interface, for the plurality of applications to access locomotive/vehicle control system data in a common defined manner, as described in more detail above. The control manager unit is configured to receive control input from the plurality of applications and process the control input for providing to the control system for use in operating the locomotive (or other vehicle). For example, the control manager unit may process application data (or other data) and/or command requests in a manner as described above. The communication system further comprises a private interface for communications between the data manager unit and the control system and/or between the control manager unit and the control system, and an open interface for communications between the data manager unit and the plurality of applications and for communications between the control manager unit and the plurality of applications. In another embodiment, the data manager unit is configured to manage the transmission of data, at least between the plurality of applications, based on a publish-subscribe communications structure ("structure" referring to a configuration or setup, using program instructions, electronics, other control mechanism, or otherwise, for implementing publish-subscribe communications in the data manager unit and/or system generally).

As should be appreciated, a modern locomotive is an electro-mechanical system that comprises a plurality of mechanical, electrical, and electro-mechanical subsystems. An "application," as used herein, is a locomotive subsystem or portion thereof that utilizes data, provides data, and/or that provides or utilizes control input. An application may be a processor or processor-based unit, an algorithm or software as executed by a processor or processor-based unit, or the like, but is not limited in this regard unless otherwise specified. For example, an application may be a hardware (e.g., electronics)-based subsystem or portion thereof, an electro-mechanical subsystem or portion thereof, or the like. In one embodiment, all or at least some of the applications are embodied as algorithms/software/programming instructions as executed by a processor or processor-based unit, e.g., for carrying out distributed power operations, other train or other vehicle control operations, on-board and off- board communications operations, emissions control and other engine control operations, data capture and storage operations, operator interface operations, and the like.

An embodiment relates to an operating system, onboard a locomotive, for controlling multiple operations of the locomotive. The operating system comprises a first controller or control subsystem for controlling a positive train control system of the locomotive. The operating system further comprises a second controller or control subsystem for controlling an operator coaching and/or operator interface system of the locomotive. The operating system further comprises a third controller or control subsystem for controlling a trip optimizer and/or fuel savings system of the locomotive. The operating system further comprises a memory in which locomotive operations data is stored for each of the positive train control system, the operator coaching and/or operator interface system, and the trip optimizer and/or fuel savings system. The operating system further comprises a communication link between the controllers (or control subsystems) and the memory for the controllers (or control subsystems) to obtain the operations data from the memory and store the operations data in the memory. In an embodiment, the memory is a non-distributed memory. The non-distributed memory is the sole data storage in the locomotive for long term storage of the operations data for the plurality of controllers (or control subsystems) and the positive train control system, the operator coaching and/or operator interface system, and the trip optimizer and/or fuel savings system.

Though exemplary embodiments of the present invention are described with respect to locomotives, exemplary embodiments of the invention are also applicable for use with other powered systems, such as but not limited to marine vessels, stationary units such as power plants, off-highway vehicles, agricultural vehicles, and/or mass cargo or mass transit transportation vehicles, each which may use at least one engine. Towards this end, when discussing a specified mission, this includes a task or requirement to be performed by the powered system. Therefore, with respect to a railway vehicle, marine vessel, agricultural vehicle, mass cargo or mass transit transportation vehicle, or off-highway vehicle applications, this may refer to the movement of a collective powered system (where more than one individual powered system is provided) from a present location to a destination. In the case of stationary applications, such as but not limited to a stationary power generating station or network of power generating stations, a specified mission may refer to an amount of wattage (e.g., MW/hr) or other parameter or requirement to be satisfied by the powered system.

Exemplary embodiments of the invention solve problems in the art by providing a method, system, and computer implemented method, such as a computer software code or computer readable media, for providing an open defined interface so that any application may access locomotive/vehicle control system data or other vehicle data or other data in a common defined manner with predictable results.

Persons skilled in the art will recognize that an apparatus, such as a data processing system, including a CPU, memory, I/O, program storage, a connecting bus, and other appropriate components, could be programmed or otherwise designed to facilitate the practice of the method of the invention. Such a system would include appropriate program means for executing the method of the invention.

Also, an article of manufacture, such as a pre-recorded disk, computer readable media, or other similar computer program product, for use with a data processing system, could include a storage medium and program means recorded thereon for directing the data processing system to facilitate the practice of the method of the invention. Such apparatus and articles of manufacture also fall within the spirit and scope of the invention. Broadly speaking, a technical effect is to provide an open defined interface so that any application may access locomotive control system data in a common defined manner with predictable results, for more efficient and better operation (possibly including autonomous operation) of a locomotive. To facilitate an understanding of the exemplary embodiments of the invention, it is described hereinafter with reference to specific implementations thereof. Exemplary embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules, being executed by any device, such as but not limited to a computer, designed to accept data, perform prescribed mathematical and/or logical operations usually at high speed, where results of such operations may or may not be displayed. Generally, program modules include routines, programs, objects, components, data structures, etc. that performs particular tasks or implement particular abstract data types. For example, the software programs that underlie exemplary embodiments of the invention can be coded in different programming languages, for use with different devices, or platforms. It will be appreciated, however, that the principles that underlie exemplary embodiments of the invention can be implemented with other types of computer software technologies as well.

Moreover, those skilled in the art will appreciate that exemplary embodiments of the invention may be practiced with other computer system configurations, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Exemplary embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through at least one communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

As should be appreciated, embodiments of the invention reside primarily in a combination of hardware and software elements related to the methods and systems described herein. Accordingly, in at least some instances hardware and software elements have been represented by conventional elements in the drawings, showing only those specific details that are pertinent to the present invention, so as not to obscure the disclosure with structural details that will be readily apparent to those skilled in the art having the benefit of the description herein.

Embodiments described herein may be implemented on a suitable computer system, controller, data processor, or generally a computer readable medium. For example, the steps of the methods described herein may correspond to computer instructions, logic, software code, or other computer modules disposed on a computer readable medium, e.g., floppy disc, hard drive, ASIC, remote storage, optical disc, or the like. The computer-implemented methods and/or computer code may be programmed into an electronic control unit of an engine, a main control system of a locomotive or other vehicle, a remote station that communicates with the vehicle, or the like, as described herein.

While the invention has been described with reference to various exemplary embodiments, it will be understood by those skilled in the art that various changes, omissions and/or additions may be made and equivalents may be substituted for elements thereof without departing from the spirit and scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed as the best mode contemplated for carrying out this invention, but that the invention will include all embodiments falling within the scope of the appended claims. Moreover, unless specifically stated any use of the terms first, second, etc. do not denote any order or importance, but rather the terms first, second, etc. are used to distinguish one element from another.

Claims

WHAT IS CLAIMED IS:

1. An operating system, onboard a powered vehicle, for controlling multiple operations of the powered vehicle, the operating system comprising:

a plurality of control subsystems onboard the powered vehicle for controlling multiple operations of the vehicle, and at least one of the control subsystems has a memory in which vehicle data is stored and the vehicle data is accessible and used by one or more of the other control subsystems for controlling operations of the powered vehicle; and

a communication system for controlling sharing of the vehicle data across the plurality of control subsystems on the powered vehicle, the communication system comprising an open defined interface unit configured so that the control subsystems may access the vehicle data in a common defined manner with predictable results.

2. An operating system, onboard a powered vehicle, for controlling multiple operations of the powered vehicle, the operating system comprising:

a communication system for controlling sharing of vehicle data and/or other data across a plurality of subsystems on the powered vehicle, the communication system comprising an open defined interface unit configured so that a plurality of applications may access the vehicle data and/or other data in a common defined manner with predictable results.

3. The operating system of claim 2, wherein the open defined interface unit further comprises:

a data manager unit configured to manage a transmission of the vehicle data and/or other data from a control system and/or subsystem of the vehicle to the plurality of applications, between the plurality of applications, from a sensor to one or more of the plurality of applications, from a communication management unit to the plurality of applications, and/or from off-board the vehicle to the plurality of applications; and a control manager unit configured to receive control input from the plurality of applications and process the control input for providing to the control system and/or subsystem for use in operating the vehicle.

4. The operating system of claim 3 wherein:

the control manager unit is configured to receive command requests from the plurality of applications and determine which command request is provided to the control system and/or subsystem for use in operating the vehicle; and

the data manager unit and the control manager unit comprise a closed loop control system that further comprises the control system and/or subsystem and at least one application of the plurality of applications, wherein the closed loop control system provides for autonomous operation of the vehicle.

5. The operating system of claim 3, further comprising:

a private interface for communicating between the data manager unit and the control system and/or subsystem, and/or between the control manager unit and the control system and/or subsystem;

an open interface for communicating between the data manager unit and the plurality of applications and/or the control manager unit and the plurality of applications; and

a data dictionary that defines data available to at least one of the plurality of applications and/or a command request available from the control manager unit.

6. The operating system of claim 3, wherein the data manager unit distributes the vehicle data and/or other data at specified frequencies to the plurality of applications.

7. The operating system of claim 3, wherein the data manager unit distributes the vehicle data and/or other data depending on whether at least one application of the plurality of applications and/or the control system and/or subsystem of the vehicle publishes available data and at least a second application of the plurality of applications subscribes to receive the published available data.

8. The operating system of claim 3, wherein the data from off-board the vehicle comprises data from a remote database and/or dynamic wayside data relevant to a signal aspect, switch position, and/or crossing gate position.

9. The operating system of claim 3, wherein a transmission of data managed by the data manager unit is accomplished with a multicast delivery of the data.

10. The operating system of claim 2, further comprising:

a display manager unit that is configured to communicate with at least one of the plurality of applications, wherein the display manager unit is configured to manage a transmission of data made available to an operator; and

a user interface configured to allow the operator to select data to be made available to the operator.

11. An operating system, onboard a powered vehicle, for controlling multiple operations of the powered vehicle, the operating system comprising:

a data manager unit configured to manage a transmission of data from a control system and/or subsystem of the powered vehicle to a plurality of applications, between the plurality of applications, from a sensor to one or more of the plurality of applications, and from a communication management unit to the plurality of applications, wherein the data manager unit is configured as an open defined interface for the plurality of applications to access vehicle data and/or other data in a common defined manner;

a control manager unit configured to receive control input from the plurality of applications and process the control input for providing to the control system and/or subsystem for use in operating the powered vehicle;

a private interface for communications between the data manager unit and the control system and/or between the control manager unit and the control system and/or subsystem; and an open interface for communications between the data manager unit and the plurality of applications and for communications between the control manager unit and the plurality of applications.

12. The operating system of claim 11, wherein the data manager unit is configured to manage the transmission of data, at least between the plurality of applications, based on a publish-subscribe communications structure.

13. A method for operating a powered vehicle, the method comprising:

autonomously managing a transmission of data from a vehicle control system and/or subsystem to a plurality of applications, between the plurality of applications, from a sensor to the plurality of applications, from a communication management unit to the plurality of applications, and/or from off-board the powered vehicle to the plurality of applications;

autonomously managing a transmission of application data received from the plurality of applications to determine which application data is provided to the vehicle control system and/or subsystem; and

operating the powered vehicle based on the application data provided to the vehicle control system and/or subsystem.

14. The method of claim 13, wherein operating the powered vehicle further comprises autonomously operating the powered vehicle by autonomously implementing changes to a direction of travel of the powered vehicle, changes in a notch level or other throttle level of the powered vehicle, changes in a speed of the powered vehicle, dynamic brake operation, automatic air brake operation, and/or independent brake operation.

15. The method of claim 13, wherein autonomously managing a transmission of data from the vehicle control system and/or subsystem further comprises distributing data to the plurality of applications based on an authority and/or a priority of each application of the plurality of applications for distributing and/or receiving data.

16. An operating system, onboard a powered vehicle, for controlling multiple operations of the powered vehicle, the operating system comprising:

a plurality of control subsystems onboard the powered vehicle for controlling multiple operations of the powered vehicle, and at least one of the control subsystems has a memory in which data is stored and the data is accessible and used by one or more of the other control subsystems for controlling vehicle operations; and

a communication link between the control subsystems for sharing the data stored in the memory of one of the control subsystems to control operations of the powered vehicle.

17. The system of claim 16, wherein the communication link is a communication router for receiving commands from one or more control subsystems for sharing data between the control subsystems, and wherein the commands relate to data required for the operation of a control subsystem and the router connects two or more control subsystems responsive to the commands for sharing data.

18. The system of claim 16, wherein:

the powered vehicle is used to control the movement of a series of vehicles in a consist;

the memory comprises a central database onboard the powered vehicle;

the data used by said one or more of the other control subsystems for controlling vehicle operations is stored in the database and comprises at least a portion of a route database comprising route profile data and/or manifest data of the powered vehicle and/or consist; and

the communication link provides access to the database for the control subsystems to retrieve the route profile data and/or manifest data from the database.

19. The system of claim 16, wherein the powered vehicle is used to control the movement of a series of vehicles in a consist, and vehicle manifest data or a route database comprising route profile data is stored in a memory off-board the vehicle, and at least a portion of the route database or the vehicle manifest data is transmitted via wireless communication to and stored in a memory for the onboard operating system; and

the system further comprises a verification access code associated with the powered vehicle or an operator of the powered vehicle to access and transmit data from the off- board memory to the onboard operating system.

20. An operating system, onboard a powered vehicle, for controlling multiple operations of the powered vehicle, the operating system comprising:

a plurality of control subsystems onboard the powered vehicle for controlling multiple operations of the vehicle;

a non-distributed memory in which data is stored, said data relating to operations and control of the powered vehicle; and

a communication link between the control subsystems and the memory for the

control subsystems to obtain the data from the memory and store the data in the memory;

wherein the non-distributed memory is the sole data storage in the powered system for long term storage of said data for the plurality of control subsystems.