GB2487365A

GB2487365A - Vehicle Identification System for Trains with Flexible Formations

Info

Publication number: GB2487365A
Application number: GB1100782.0A
Authority: GB
Inventors: John Ritchie Kinghorn
Original assignee: Individual
Current assignee: Individual
Priority date: 2011-01-18
Filing date: 2011-01-18
Publication date: 2012-07-25
Also published as: GB201100782D0

Abstract

A flexible vehicle identification system is disclosed, which can be applied to trains having a wide variety of formations. The invention uses identification modules in each rail vehicle (e,g. carriage), interconnected through bidirectional serial data interfaces in a simple `string' configuration. Each identification module contains comprehensive information about each vehicle, and can be interconnected to other systems for both controlling functions and sensing data. The system permits any number of train information systems in any vehicles to be connected to the identification modules, and the systems in each vehicle are connected to obtain a common view of the train formation and the status of all the vehicles within it. Each module passes on the data received and adds its own identity to the data. The system can detect if the vehicle is connected at both ends or not. Some vehicles are active, containing management systems, whilst others are passive and solely provide information. This results in an economical and universal framework for managing data in trains without restrictions on vehicle types or how they are coupled together.

Description

Vehicle identification System for Trains with Flexible Formations

Background to the invention

Modern trains, especially passenger trains, require much information to operate effectively. Partly this situation has arisen from automating many processes that were once performed manually. For example, seat reservations are now arranged via an electronic display at every seat, replacing the paper tickets once attached to seats by a member of staff walking through the train. Also, modern control systems allow the monitoring of many facilities such as the water level in tanks supplying toilets, or the temperature of a passenger saloon. Data from all these functions can be brought together and made visible to staff on the train through special terminals, or recorded for later analysis to assist in improving performance or identifying faults.

When a train has a fixed formation, the train information system can be designed to conform to the requirements of all the vehicles in the train. Known methods for transferring data within the train include local area networks (LAN), Internet Protocol (lP) techniques for addressing specific vehicle data sources, optical fibre networks arranged in a ring starting and finishing at a master controller, and wireless transmitters at the ends of the vehicles. Should the formation of the train be changed in a depot and a different type of vehicle substituted, or a vehicle be added or removed, the train information system is reprogrammed at the same time to satisfy the new requirements of the vehicles now present.

When trains are formed from multiple units which can be coupled together, things become slightly more complicated as information needs to be shared between two or more sections. This can be arranged using suitable communication protocols between the groups of vehicles, and usually designating one group as the master' which takes overall control. Most modern trains equipped with sophisticated and complex train information systems conform to the fixed formation or multiple unit philosophy.

It might be desired, however, to have a much more flexible arrangement of trains consisting of a wide variety of vehicle types that can be freely coupled together in many ways to cover many requirements. For example, perhaps a long train hauled by an electric locomotive on a main line arrives at a junction and is split into two sections, the longer part continuing on one route and the remaining coach or two having a diesel locomotive attached for the journey on a local branch line. Or perhaps a short train arrives at a big city and has more coaches and a restaurant car attached for the busier next part of its journey. Maybe even three diesel power cars arrive at a junction from three different routes, and all couple together to head __......--. . off as a combined train to somewhere else. The question then is how best to organise the train information system to cope with this kind of diversity.

Ideally it should be possible for the train information structure to be sorted out automatically when vehicles are shunted together or apart without the need for any prior knowledge of what the new train formation(s) will be. In computer terminology, coupling trains together ought to be plug and play'. In order to achieve this, the train information system(s) need to respond to any coupling or uncoupling event and ask the vehicles now coupled together to identify themselves. Also the sequence of vehicles in the new formation needs to be known. Achieving these functions is the objective of the vehicle identification system described in this invention.

A further objective of the invention is to minimise costs and complexity of the interconnect wiring (electrical or optical fibre) using a bidirectional serial data bus approach.

A further objective of the invention is to identify which way round each vehicle is coupled as well as the sequence of vehicles in the train. This will allow, for example, seat reservations specifying facing direction of travel' to be arranged appropriately.

A further objective of the invention is to allow train information systems in the same train to share data with each other when more than one train information system is present. This can occur when separate trains are shunted together, or may be intrinsic to the architecture of the train.

A further objective of the invention is to have a standard approach to vehicle identification suitable for a large variety of vehicle types, using minimised reprogramming of modules and standardised interfaces to achieve economies of scale in the production of components.

A further objective of the invention is to allow for future expansion of the vehicle identification system to cover vehicle types and facilities which are at present unknown.

Description of the invention

The invention uses vehicle identification modules linked together via dedicated connectors which will normally form part of the standard automatic couplers in use on a particular railway network. The interconnection of modules is a string or daisy chain'; in other words each module has two data interfaces, one of which passes via the coupler to a similar interface in the next vehicle at one end, the other passing via the other coupler to the vehicle at the other end. Each vehicle or group of vehicles equipped with couplers at the outer ends contains one vehicle identification module; if several vehicles are permanently coupled together they are treated as one unit for the purposes of identification. The general arrangement of an example train formation is shown in figure 1.

The data interfaces (2) of the vehicle identification module (1) are bidirectional: they can both transmit and receive serial data. Normally, the data interfaces are in receive' mode; however they can be made to switch into transmit' mode after receiving commands to send certain types of data. Those commands are special codes, which can be sent to a vehicle identification module when it is receiving data from the next module in the chain. The module first checks for any data flow on the interface before switching to transmit' mode, however, to avoid conflicts on the interface connections. If data is still being transmitted from another source, the module waits until that traffic ceases and then after a short time delay transmits its own data as requested. As a result, data only flows in one direction on each interface connection at any given time.

The exact nature of the bidirectional interface (2) can take various forms. In the simplest version, it could be a straightforward two wire electrical connection with serial data and an associated clock signal, the output buffers being normally switched into a high impedance state and only driving to certain high and low voltage levels when transmitting data. Alternatively, data could be modulated onto a carrier frequency or sent as coded data pulses in one of many standard ways. A further option might be to use light transmission through an optical fibre, with both light sources and sensors at each end of the fibre to achieve the bidirectional capability.

It might be decided, for reasons of reliability and electro magnetic compatibility (EMC) to have one format for the interface within the vehicle and convert to a different format at the couplers (3), perhaps using there two one-way channels in parallel to maintain the bidirectional data flow. Whatever method is used, however, each interface to the vehicle identification module always has a bidirectional character.

A further necessary feature of the interface is the ability to detect reliably whether a vehicle is coupled to it or not. Various methods can be used to achieve this. If the interface at the couplers is electrical, it can have a defined impedance on both vehicles and the resulting lower impedance when the interfaces are connected in parallel can be detected to indicate a coupled vehicle. No connection gives a higher impedance, indicating that no other vehicle is coupled. Alternatively, some kind of switch arrangement built into the coupler could be used to alter voltage levels on the interface when vehicles are coupled mechanically or not. In an optical interface, some kind of local echo' protocol could be used, where each vehicle sends a specific kind of light pulse and expects to see another pulse from the other vehicle in response. If nothing is received back, no other vehicle is there.

Many other possible options for this function will occur to those skilled in the art of interfacing.

Vehicles are categorized into two types, active' and passive'. Active vehicles (4) contain a train information system (5) of some kind, which requires to know at least some information about the vehicles in the train and can make requests to the vehicle identification module (1) to find out that information. The vehicle identification module in active vehicles has additional interfaces (6) which connect appropriately to the train information system, allowing both commands to be received from the train information system and data to be transmitted to it.

Passive vehicles (7), on the other hand, contain no separate train information system and cannot make requests for train data. They merely respond to requests from active vehicles via the commands on the bidirectional interfaces to the vehicle identification module.

The vehicle identification modules of both active and passive vehicles may have further interfaces for both sensing inputs from systems in the vehicle (8) and driving control outputs or data interfaces to systems in the vehicle (9).

All vehicle identification modules contain ROM (Read Only Memory) (10) which has programmed into it, in a standard format, fixed information about the corresponding vehicle. This could include, for example, the vehicle type, its number, its manufacturer, its date of construction, number of seats of each class, number of toilets, number of wheelchair spaces, overall length and width, weight, maximum speed, whether the vehicle has seat reservation displays, etc. Most vehicle identification modules will also sense some vehicle parameters, such as whether end corridor doors are open or closed, status of lighting, health of air conditioning, water level in tanks, etc. In combination with the fixed data, this provides a comprehensive set of information relating to the vehicle in question.

Vehicle identification modules may also include output interfaces for control or data functions. This could include data feeds to displays for seat reservation or destinations, digital audio feeds to public address systems, inhibit controls for H _. -...-. ____ selective door opening, etc. The vehicle identification module plays no part in processing such signals: it merely identifies the relevant command code for the function and routes the data to the appropriate interface.

Because of the serial string nature of the interconnection between vehicle identification modules, each vehicle is only connected to the next one on either side. Building up a picture of the whole train formation therefore requires data from other vehicles to be passed through the modules, each of which adds its own information to the data stream. As a result, information passing down the train has more and more data added from each vehicle as it moves from one interface to the next in sequence, until it reaches the module which was requesting that information.

An example of this process is illustrated in figure 2. Suppose there is a locomotive hauled train with four coaches A, B, C and D, which has a train information system (5) located in the locomotive. The locomotive has just been coupled to the coaches, and wants to know exactly what it has been coupled to.

The first thing to happen is that the locomotive senses a coupling event, either initiated by the driver pressing a button or detected automatically by a switch signal from the automatic couplers. This causes the locomotive's train information system (5) to send a what is there?' command to its vehicle identification module (1), which in turn transmits a coded version of this command on both of its serial data interfaces (2).

The coupler at the outer end of the locomotive has nothing coupled to it, however, so the interface detects that and returns a nothing coupled to no.1 end' message back to the train information system. On the second interface, however, the command successfully crosses the coupler (3) and passes into the vehicle identification module (1) of the first coach A. This causes it to retransmit the what is there?' command on its second interface, and so the message passes to the second coach B. In a similar way, the command passes down the tine of coaches until it reaches the train identification module of the last coach D. This would normally pass on the message to its second interface, but it knows there is nothing coupled to that. So the action of receiving the what is there? command on one interface together with the knowledge that nothing is connected on the second interface causes the vehicle identification module to initiate the return of its stored data on its first interface (2).

This information from coach D is thus passed back to the vehicle identification module in coach C, which responds by retransmitting it to coach B. When the data for coach D has all been sent, coach C adds its own data before finishing the message. As a result, the data arriving at coach B is now D and C. In a similar way, coach B receives the 0 and C data and retransmits that to coach A, then adds its own data before the message ends. As a result, the data arriving at coach A is now 0 and C and B. Now the vehicle identification module in coach A receives the D and C and B data and retransmits that to the locomotive, adding its own data before the message ends. As a result, the data arriving at the locomotive is now D and C and B and A. Finally, the vehicle identification module in the locomotive (which made the original what is there?' request in the first place) receives the data and sends it back to the train information system. In other words, coupled to no.2 end you have coaches D, C, B and A in that sequence with D the furthest away and A the nearest'. In addition, the vehicle identification module in the locomotive also sends information about the locomotive (which it has stored in its own ROM) back to the train information system.

In more detail, the message to the train information system might be something like 0 is a brake van with 40 standard class seats, one toilet, one wheelchair space and I luggage space, maximum speed 110 mph and weighing 38 tonnes, B and C are standard class coaches with 74 seats, two toilets and a maximum speed of 125 mph weighing 35 tonnes, and A is a composite coach with 12 first class and 50 second class seats, two toilets and a maximum speed of 125 mph weighing 36 tonnes with the first class section at the front end. This is a Class XYZ electric locomotive of 4.5MW with a weight of 90 tonnes and a top speed of mph'.

The process of detecting which way round each vehicle is coupled is quite simple.

Each vehicle has a designated no.1 end and a no.2 end, with the first interface from the vehicle identification module being connected to the coupler at the no.1 end, and the second interface connected to the coupler at the no.2 end. As part of the response to a what is there?' command, the vehicle identification module adds a data flag with different states according to whether the message is being transmitted from the first or the second interface. The receiving train information system can thus work out which interlace in each vehicle was used to send data to it, and consequently the orientation of each vehicle as well as the sequence of vehicles.

If there is sufficient ROM space in each vehicle identification module, much more comprehensive information about each vehicle could be included, perhaps accessed by different what is there in more detail' commands. This might include both human readable and machine readable information, for example seating layout plans, dates of last servicing, known problems, ownership, power consumption, braking profile, etc. Naturally, the train management systems can make use of the information to perform calculations and set functions automatically: in the example above the locomotive knows it has a trailing load of 144 tonnes and is restricted to a maximum speed of 110 mph, and (if suitably equipped) can set its acceleration and braking profiles appropriately.

In many cases there will be more than one train information system in vehicles coupled together, and of course they all need to have a common view of what the composition of the train is and the status of systems within it. An example of this situation is illustrated in figure 3, where the locomotive has one train information system for the driver (5), and a driving trailer at the other end of the train has two systems; one for the guard or conductor (5), and one for the driver for use when the train is being propelled (5). This example also illustrates the use of one vehicle identification module (1) only in a group of permanently coupled vehicles: here the coaches consist of articulated triplets, but they are treated as single vehicles for the purposes of identification.

The process from the locomotive is similar to that described earlier. After a coupling event (or by request from the driver or automatically at regular intervals to keep information updated) the identification module (1) in the locomotive L sends out a what is there?' command, which passes down the chain until it reaches the driving trailer DT. Since this is the end of the train, the driving trailer echoes back its own data, which returns down the train with data for coach triplets C, B and A being added in turn. Finally the identification module (1) in the locomotive adds its own data, and the combined information DT, C, B, A and L is transferred to the train information system (5) in the locomotive and can be viewed on the driver's terminal.

The same process happens from the driving trailer at the other end of the train, with data flowing in the opposite direction through the interfaces. Either on request from the drivers or guard's terminals, or automatically, the identification module in the driving trailer DT sends out a what is there?' command, which passes down the chain until it reaches the locomotive L. Since this is the end of the train, the locomotive echoes back its own data, which returns down the train with data for coach triplets A, B and C being added in turn. Finally the identification module in the driving trailer adds its own data, and the combined information L, A, B, C and DT is transferred to the train information systems in the driving trailer and can be viewed on the driver's and guard's terminals.

Since commands and data flows may come at random times, it is quite possible that a vehicle identification module will receive data on both interfaces simultaneously. This will make it impossible to relay information from one interface to the other immediately. Consequently each module has local data buffering, sufficiently large to store the longest possible message, allocated to each interface. It then stores up the data from the incoming flows, and waits until the interfaces are quiet again before continuing its task of relaying the messages.

Viewed as a process of information flow, the task is a bit like two trains on a single line crossing at a passing loop; each train (data message) has to wait until the line (interface) becomes clear.

_ _

As well as allowing for multiple train information systems, the vehicles containing those systems can be anywhere, not necessarily at the ends of the train. Figure 4 shows an example of a train formation comprising three coaches and two diesel power cars, with the leading coach A having a driving cab including a train information system and with the diesel power cars in the C and D positions equipped with train information systems too. Coaches B and E are passive vehicles with no train information systems.

The process from the leading coach A is similar to that described earlier. After a coupling event (or by request) the identification module in the leading coach A sends out a what is there?' command, which passes down the chain until it reaches the last coach E. Since this is the end of the train, coach E echoes back its own data, which returns down the train with data for power cars D and C and coach B being added in turn. Finally the identification module in the leading coach A adds its own data, and the combined information E, D, C, B and A is transferred to the train information system in the leading coach and can be viewed on the driver's terminal.

Since power car C is in the middle of the train, it sends out what is there?' commands in both directions. One command heads to the front of the train at coach A, which is echoed back collecting data for first A and then A, B in turn. This tells power car C that it has A and B in front of it, with B the nearest. On the other interface, the second what is there?' command heads to the rear of the train at coach E, which is echoed back collecting data for first E and then E, D in turn. This tells power car C that it has E and D behind it, with D the nearest. The vehicle identification module then adds its own data, allowing the train information system in power car C to work out that the formation from the front is A, B, C, D, E. Similarly, power car D sends out what is there?' commands in both directions.

One command heads to the front of the train at coach A, which is echoed back collecting data for first A, then A, B, then A, B, C in turn. This tells power car D that it has A, B and C in front of it, with C the nearest. On the other interface, the second what is there?' command heads to the rear of the train at coach E, which is echoed back collecting data for E. This tells power car D that it has only coach E behind it. The vehicle identification module then adds its own data, allowing the train information system in power car D also to work out that the formation from thefrontisA, B, C, D, E. In this way all the train information systems present come to a common view of the formation of the train and the details of each vehicle within it. Once that train formation structure has been established (a second or so after coupling vehicles together) the train information systems can address each vehicle individually to send specific information or controls, or to request specific information or status messages to be returned. Every data message from a vehicle identification module contains the vehicle's number, so there is no ambiguity about where the

------

data is coming from. Also, every command message contains the number of the vehicle originating the command, which is also incorporated into the return data in a different position. This allows the vehicle identification module in an active vehicle to identify whether the data arriving on one of its bidirectional serial interfaces is the result of a command it made itself (in which case the data should be passed to the local train information system), or not (in which case it should be retransmitted on the second bidirectional serial interface).

Generic commands (such as what is there?') are always retransmitted on the second interface of a vehicle identification module (except, of course, when nothing is connected there). Specific commands, however, are only retransmitted if the destination vehicle number they contain does not match the number of the vehicle identification module concerned. If it does match, the message is intended for that vehicle and is not retransmitted; instead it takes the appropriate action locally, either retrieving information from the module itself or interacting with systems in the vehicle through the relevant interfaces.

A block diagram of the vehicle identification module (1) is shown in figure 5. This contains the serial to parallel converters (11) and data buffers (12) for the bidirectional serial interfaces (2), together with their control circuits (13). These control circuits monitor the status of the interfaces (2) and permit the retransmission of data at the appropriate times as described earlier. The control circuits (13) are also responsible for detecting the absence of a connection on a bidirectional interface as described earlier, either directly through their own sensing circuits or by collaboration with systems located on the couplers.

When a specific command is received, the comparison circuit (14) compares the incoming destination vehicle number with the module's own vehicle number, and if they do not match activates the control circuit (13) to retransmit the message as usual. If the number does match, the relevant command is processed locally in the command processing unit (16) instead. This might result in the retrieval of data from the ROM (10), sending data or commands to the local interfaces (9), or receiving data or status indications from the local interfaces (8).

If the vehicle identification module is an active one, the comparison circuit (14) is extended to examine return data for the presence of the original command vehicle number. If a match is found, the relevant data is passed on to the returned data buffer (15), which then transfers it to the local train information system via that interface (6). If the numbers do not match, the data is retransmitted on the bidirectional data bus (2) as usual.

Commands coming from the train information system via the interface (6) are coded by the command processing unit (16), which activates the control circuits (13) when appropriate to send those messages out on both serial interfaces (2).

Passive vehicle identification modules are similar to active ones, with a simpler comparison circuit (14), no returned data buffer (15) and no interfaces to a train information system (6).

Each vehicle identification module is powered from the vehicle's usual hotel bus' electricity source via a small power supply unit, with a small rechargeable battery to maintain operation when no power source is available. The complexity of the module is not high by modern standards, and is achievable using such technologies as programmable integrated circuits.

Apart from the variable data in ROM specific to the vehicle, the overall functionality of the vehicle identification module is fixed to confirm to rigorously designed standards without the need for software upgrades. Programmability comes in the train information and management systems connected to the vehicle identification module, not in the module itself. This allows the vehicle identification module to benefit from economies of scale, good reliability and longevity to suit the needs of the railway business.

Naturally standard methods can be used for error protection and correction to give a robust and reliable system with suitable fallback modes in case of fault conditions. The system is not intended for especially time critical or safety critical applications such as traction or braking controls, but is a suitable universal method of managing many other kinds of data necessary for the efficient operation of modern trains.

The speed of operation depends on the bandwidth chosen for the bidirectional serial interfaces primarily. As a guide, a 1 0Mb/s data rate allows the downloading of seat reservations for a fully reserved 1000 seat train in about a second, if 1 Kbyte is allocated for each seat display. Normal identification of basic train formation data after coupling will be accomplished in under I second as far as this system is concerned, although the train information systems connected to it will probably be much slower to process the data.

The coding of data and commands in detail is outside the scope of this invention, but a basic principle is to leave plenty of extra unused command codes to allow for future expansion of facilities, given the long lifetime of rail vehicles.

The system allows automatic identification of rail vehicles in a very flexible way, speeding up the process of shunting and allowing for economy in module design and interconnection.

Claims

Vehicle Identification System for Trains with Flexible Formations Claims 1. An identification module for railway vehicles, containing information about the vehicle and equipped with two bidirectional serial data interfaces for connection to couplers or connectors at each end of the vehicle which operates to retransmit on one interface the data received on the other interface, also adding its own internal data to the output data stream and capable of operating in either direction for serial data transfer.
2. An identification module for railway vehicles as in claim 1, equipped with additional interfaces for train management systems to send commands to or receive data from the identification module and other modules connected to it.
3. An identification module for railway vehicles as in claim I or claim 2, equipped with additional interfaces to send data, commands or control signals to systems in the vehicle and/or to receive data and signals from systems and sensors in the vehicle.
4. An identification module for railway vehicles as in claim I, claim 2 or claim 3, equipped with detection means to identify whether other identification modules are connected to either or both of its bidirectional serial interfaces.
5. An identification module for railway vehicles as in claim 4, equipped with processing means to identify the receipt of an information request' command on a first bidirectional serial interface together with the absence of a connection on a second bidirectional serial interface this condition activating the retrieval of information from the identification module and the retransmission of that data on the first bidirectional serial interface.
6. An identification module for railway vehicles as in claim 5, equipped with processing means to retrieve external data from one or more sources and retransmit that data on a bidirectional serial interface in response to an information request' command on that bidirectional serial interface and the absence of a connection on the other bidirectional serial interface._ _ _ ____
7. A vehicle identification system for trains comprising one or more active' vehicles or groups of vehicles containing train management systems collaborating with each other to share information about the train in addition to providing information about themselves and/or one or more passive' vehicles or groups of vehicles providing information about themselves to the train management systems in the active' vehicles where each vehicle or group of vehicles is equipped with an identification module according to one of the previous claims and all the modules in a train are connected together in a string so that the data output from a module includes both information for that vehicle and also information from all the other vehicles on the input side of the module; the system allowing train management systems in any part of the train to discover information from all vehicles in the train and to determine their sequence by requesting information flow in both directions through the serial data interfaces.
8. A vehicle identification system for trains according to claim 7, where each identification module transmits different data according to which of its two serial data interfaces is being used as an output, allowing train management systems to determine the orientation of each vehicle as well as its sequence in the train formation.