Patent Application
20160016597
This disclosure relates to the field of train management systems and increasing safety in such systems.
One example of a train management system is the Lockheed Martin Advanced Train Management System (ATMS) that uses on-train processing and advanced digital communications to keep track of and manage the location and speeds of trains on a railway. This permits railroads to increase capacity by reducing distance between trains and increase reliability through better on-time performance. In addition, safety is increased through authority and speed limit enforcement.
The ATMS uses a track database containing a variety of data including geographical coordinates of a number of trackside features that are disposed along the railway tracks as well as a unique identifier for each of the trackside features. The track database is used to create a virtual model of the track in the control system of the train.
Track databases have many components that are constructed by a team of surveyors, software operators, database administrators, and other staff, and are distributed by radio links to trains from central data servers. However, the track database can have errors. The track line's 3-D trajectory can have errors (location/curvature/heading/grade), which can degrade the ability to accurately compute offset into track segment. In addition, errors in feature-coordinate assignments can result in erroneous visual presentation of upcoming trackside features and track line characteristics to train crew and can have several unintended consequences. For example, errors in content can result in erroneously determining train's track occupancy (parallel track), computing actual location along a track, affecting braking enforcement distance calculations, and miss-identifying physical features used in authority limits.
Physical trackside features such as kilometer posts, turnouts, speed limits, passenger platforms, division boundaries, yard limits, etc. are used for two-way traffic management and speed management. However, these trackside features can have errors in their partition offsets which results in track database content errors. In addition, trackside features such as kilometer posts and control points can be unintentionally swapped along the track line (for example kilometer post 130 is actually 129 and vice versa). For this example, an authority issued between kilometer posts 135 and 130 on single track could cause an unintentional physical conflict with an opposing train travelling in the opposite direction, as their movement authorities are generated and deconflicted by km post value by a train dispatcher/controller, not by geographic coordinates.
Methods and systems are described that can be used to verify a track database of a train management system, for example that the track database has not been corrupted, built with critical errors, or is not being used properly by the software application.
In some circumstances, software and hardware data of a train management system have to meet safety integrity level (SIL) 3 and above compliance. One recognized way to meet SIL requirements for the underlying ATMS track database is to create and use an independent database, which has the characteristics of a different design, different creation method, generated by a different process with different assets, and maintained by different team members.
The described methods and systems provide real time, continual, train centric techniques to ensure that each train is using its part of the track database without safety reducing navigation errors, is processing the track database correctly, and has correct information on the actual placement of trackside features so that the actual placements match the track database contents which is used to construct the virtual model of the track.
In one embodiment, radio frequency identification (RFID) tags are mounted on the trackside features contained in the track database. The tags contain data such as the geographical coordinates of the trackside features and a unique feature identifier that uniquely identifies the respective feature. As the train passes the trackside feature, a tag reader on the train reads the tag to gather the geographical coordinates and the feature identifier. The train management system then compares the geographical coordinates and/or the feature identifier from the tag with the expected geographical coordinates and/or the expected feature identifier in the track database.
An advantage of the described methods and systems is that the team or individuals that load the data into the RFID tags can be independent from the team that created the track database. This diversity and independence between the two teams are important attributes for a SIL environment.
In one embodiment, the RFID tag is mounted on the trackside feature in a vertical orientation, and the RFID reader on the train has a wide vertical field of view, and a narrow horizontal field of view, in order to detect the trackside feature's passing when it is close to broadside to the train. In one example, the RFID reader is located in the engine or locomotive of the train, such as adjacent to the front end of the locomotive. However, the RFID reader can be located at other locations on the train as long as its location is accounted for when comparing the read RFID data to the expected data from the track database. In addition, in some embodiment, more than one RFID reader may be provided on the train, with each RFID reader reading the RFID tag as it passes the trackside feature.
In one specific embodiment, a method of verifying a railway track database of a train management system is provided. The track database contains information on a plurality of trackside features located adjacent to a railway track including an identifier that uniquely identifies each trackside feature and a geographical coordinate location of each trackside feature. In this example, the method includes, as the train is traveling on the railway track, reading a radio frequency identification tag that is affixed to a first one of the trackside features using a reader disposed on the train. The reader obtains from the tag a feature identifier that uniquely identifies the first trackside feature and geographical coordinates of the first trackside feature, where the feature identifier and the geographical coordinates are stored in memory of the tag. The feature identifier and the geographical coordinates read by the reader are then compared with an expected identifier and expected geographical coordinates obtained from the track database.
In another specific embodiment, a method includes, as a train is traveling on a railway track and passes a trackside feature disposed adjacent to the railway track, reading data from a radio frequency identification tag disposed on the trackside feature using a reader located on the train.
In still another specific embodiment, a method includes mounting radio frequency identification tags to a plurality of trackside features adjacent to a railway track, each tag having memory in which is stored geographical coordinates of the trackside feature to which the tag is fixed and a feature identifier that uniquely identifies the trackside feature to which the tag is fixed.
In still another specific embodiment, a radio frequency identification tag includes a tag body, an antenna on the tag body, and memory on the tag body. The memory includes stored therein geographical coordinates of a railway trackside feature to which the RFID tag is intended to be or has been fixed and a feature identifier that uniquely identifies the railway trackside feature to which the RFID tag is intended to be or has been fixed.
In addition, a system includes a plurality of radio frequency identification tags mounted to a plurality of trackside features disposed adjacent to a railway track, each tag having memory in which is stored geographical coordinates of the trackside feature to which the tag is fixed and a feature identifier that uniquely identifies the trackside feature to which the tag is fixed. The system also includes a tag reader mounted on a train, the tag reader is capable of reading the radio frequency identification tags as the train passes the trackside features, and a processor on the train that is connected to the tag reader, the processor receiving the geographical coordinates and the feature identifier of each tag from the tag reader.
With reference initially to
The trackside features 12 can be any structures typically located along a railway track that are used for such tasks as traffic and/or speed management including, but not limited to, kilometer posts, turnouts, speed limits, division boundaries, yard limits, etc.
The track line 10 can be any railway track on which a train travels including, but not limited to cargo, freight, passenger, and/or commuter train tracks. The train 14 generally includes a locomotive or engine and one or more additional cars connected to the locomotive.
The train 14 is controlled by a train management system on the train, typically on the locomotive, that includes a track database that is used to keep track of the location and speed of the train on the track. The function and construction of track databases and train management systems is well known to those having ordinary skill in the art. An example of a track database is described in U.S. Pat. No. 8,392,103.
When it is created, the track database contains the geographical coordinates of some or all of the trackside features 12 as well as a unique identifier for each of the trackside features in the track database. The train management system includes a location determination unit (LDU), such as a head end rail guide, that determines instantaneous offset into track partition and uses the track database to determine current geographic coordinates from the offset. For example, with reference to
This calculation of the geographical coordinates and the use of the geographical coordinates of the trackside features 12a, 12b is used by the train management system to help control operation of the train. However, as indicated above, there could be errors in the track database that can result in errors in the coordinate calculations as well as errors in advising the train operators which trackside features they are coming up on or have passed. Therefore, a continual, train-based means to validate the data in the track database would be useful.
With reference to
In one embodiment, the tags 20 are mounted on the trackside features 12 and programmed by a crew that is independent from the team involved with creating the track database. This independence greatly reduces the chances that a common error is made both in the track database and in the tag 20.
For each tag 20, the crew loads into the memory 26 a feature identifier that uniquely identifies the trackside feature 12 to which that tag will be or has been mounted, as well as the geographical coordinates of that trackside feature. The loading of the data into each tag 20 can occur prior to or when the tag is mounted on the trackside feature. The geographical coordinates for each trackside feature 12 can be obtained using a conventional GPS receiver, which are then loaded into the tag memory 26. The loading of the data into tag memory can occur via wired or wireless means well known in the art.
The feature identifier in tag memory can be any identifier that uniquely identifies the feature, and in one embodiment matches the feature identifier stored in the track database for the corresponding feature. The feature identifier can be any number and combination of alphanumeric characters and symbols.
The geographical coordinates loaded into the tag memory 26 can be any coordinates that directly or indirectly indicate the geographical location of the feature. In one embodiment, the geographical coordinates are 3-D Cartesian coordinates (Earth Centered Earth Fixed) that indicate the location on Earth, which can also be represented as Geodetic coordinates by latitude, longitude and altitude of the trackside feature.
The RFID system also includes an RFID tag reader 30 that is used to read the data from the memory 26 of the RFID tags 20 on the trackside features. The tag reader 30 is mounted on the train at any location that is suitable for reading the tags 20. In one embodiment, the tag reader 30 is mounted at or adjacent to the front or head end of the locomotive or other forwardmost unit of the train. The tag reader 30 is of conventional construction including an antenna 32 and suitable communication electronics.
The tag reader 30 is in communication with a control unit 34 that receives the tag data signals 36 from the tag reader 30. The control unit 34 includes a microprocessor 38 that is programmed to take the data from the tag memory 26 and use that data to validate the data in the track database.
In one embodiment the RFID tags 20 are mounted on the trackside features 12 so that the tags 20 extend vertically. In addition, the reader 30 on the train is designed to have a wide vertical field of view and a narrow horizontal field of view in order to detect the trackside feature's passing when it is close to broadside to the locomotive.
With reference to
In another part of the process, as the train moves down the track and passes one of the trackside features, the reader 30 reads the tag 20 on that trackside feature as indicated in box 42. As the head end of the train sequentially encounters trackside features with tags, the reader 30 responds with an event time, and reads the geographical data (e.g. the 3-D Cartesian coordinates or the Geodetic coordinates latitude/longitude/altitude) and the unique feature identifier.
The train management system also determines the expected location of the train using data from the track database as indicated at box 44. In this step, the head end LDU captures the instantaneous offset into track partition at that trackside feature, and computes equivalent geographic coordinates in the manner illustrated in
The data read from the RFID tag is then compared to the expected location data as indicated at box 46. The train management system differences the LDU determined location at the event with the data read from the tag 20. This can be simplistically stated as LAT/LON/ALT of the locomotive minus LAT/LON/ALT of the trackside feature. However, in actuality the Cartesian coordinate components would be individually differenced.
If the locomotive is navigating properly (e.g. not built up an offset error), and if the trackside features and track geometry model in the complex track database are correct for that partition, then the coordinates read from the RFID tag will be very close (for example under 3 meters, or even within 1-2 meters) to those computed by the train borne computer. This event would be given a pass. Small differences confirm performance of the train management system and data correctness in the track database. Therefore, the geographical coordinates need not be identical in order to determine that there is a match.
The unique identifier read from the RFID tag matching the track database feature identifier confirms the correct trackside feature known to be at this location.
Any errors in either the geographical coordinates or the unique identifier can be logged and sent to a central location, such as a train management system office, and the train can be dropped out of automatic control.
If there is a match of feature identifier and coordinate locations, that means, at that time and for that train, the LDU's computed offset into partition is correct, the underlying track database is correct (at that time), and the train's crew operational display is correctly showing the track line and trackside features (but not features ahead of it). This type of checking is temporal, not continuous, only occurring every 1 km or less, depending on trackside feature density.
In an alternate embodiment, one could verify the coordinates without verifying the identifier, and vice versa.
This described method of cross checking, being physically performed on the track, also has beneficial use as a way to verify proper database content for both the underlying track database, the data in the tag memory, and LDU navigation performance, after track physical maintenance and database updates are put in place. In other words, it is a good test and verification tool to be employed after track and data changes are implemented on the network.
In addition to or separately from the track database validation described above, the systems and methods described herein can be used for other train management purposes. For example, since the geographical coordinates of the trackside features are known and the time between two readings is known, reading the tags of two consecutive trackside features can be used to determine the rate of travel between the trackside features and thus as a check of the speed of the train.
In addition, although the systems and methods have been described above as employing a single tag reader on the train, a train can have multiple tag readers spread along the length of the train. Each tag reader can read the tag on the trackside feature as the train passes. Failure of a reader to read the tag can indicate a potential problem with the train, such as decoupling of cars of the train from the locomotive.
The examples disclosed in this application are to be considered in all respects as illustrative and not limitative. The scope of the invention is indicated by the appended claims rather than by the foregoing description; and all changes which come within the meaning and range of equivalency of the claims are intended to be embraced therein.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13839453 | Mar 2013 | US |
| Child | 14871081 | US |
