High Modular Redundancy
With the conception of an architecture contemplating HMR9® technology as the core of the signaling system, ECM™ has developed a completely integrated, flexible, scalable and modular solution.
By analysing working models and the operational requirements ECM has implemented the key requirements of a high modular signaling system.
Based on the fundamental requirements of simplification and standardisation of engineering solutions for the standard practices and customer requirements, ECM has developed a signaling solution that is both future proof and cost-effective, The system is all about enhancing the infrastructure and it can be delivered and put into service very quickly.
On the communication level, the HMR9® uses an IP protocol therefore allowing the possibility of using any type of device that supports an Ethernet system as well as wireless or dedicated fibre optic as physical support. Since the IP protocol is public, the ECM HMR9® architecture is able to integrate with other systems provided by other suppliers.
The ECM HMR9® system is compatible and able to operate with ETCS (European Train Control System).
By implementing the multi-station concept it is now possible to control an entire railway line from a central post with one interlocking, making it possible to make changes to single station layouts without having to reconfigure and retest the entire system.
Unlike the old single-station concept the multi-approach allows each signaling device to be configured as if it were physically connected with a specific station.
This brings with it enormous advantages:
Additional stations can be added when needed, making it easier to carry out a staging approach without having to create a blockade and closing down lines for long periods.
The HMR9® system consists of the following main components:
The Central Post or Control Centre consists of the following:
The central post consists of the central interlocking unit and the control and display system, which includes the signaller control terminals, alarms and fault reporting, and event recording.
The central interlocking unit is realised through a two-out-of-two redundant architecture. The two CIUs are connected over an internal area network. Connection with the field is through wide area networks, while the con troll and display system is connected by a local area network. The CIU also has a watch-dog circuit that votes the validity of the processing and shuts down the faulty unit in the case of an error.
The trackside devices are contained in several types of equipment such as multi-object bays, trackside functional modules and harsh environment location cases.
The multi object bay (commonly referred to as a peripheral post) consists of an open frame arrangement containing object controllers and conditioning modules.
The innovative approach of the HMR CBI means that the control equipment can be installed either inside a peripheral location (containing one or more multi-object bays), inside a case at the side of the track, or in a trackside functional module in the immediate area around the signaling equipment (on a signal mast or gantry). It is also possible to have a wireless connection to equipment at the side of the track.
The data communications network is split-up into five separate communication rings:
The WAN normally consists of a primary and secondary link, but certain applications may only need a primary link with redundant ring switches.
As the name suggests, the local area network (LAN) covers a small local area. This network is used to connect the control and display system to the central interlocking unit at the control centre, and to connect with the diagnostics and maintenance system and related remote terminals.
The internal area network is the network which connects the components of the 2oo2 redundant central interlocking unit with the watch-dog circuit and communications with the outside world. The network is contained within the central interlocking unit module in the control cabinets at the control centre.
The fixed telecommunications network provides a switched Ethernet network between the interlocking location and all of the FTN access points for the object controllers connected to the interlocking. This allows the use of Ethernet through fibre-optics, copper cable or wireless connection from the FTN access point so that the IP network is extended to a gateway in each signaling location which contains object controllers. Within the signaling location, each object controller has its own Ethernet connection and IP address.
The central interlocking unit provides a centralised fail-safe logic management of the interlocking functions, and of communications based on a 2oo2 (two-out-of-two) redundant configuration.
The central interlocking unit cards use the CompactPCI Standard and are enclosed within a rack. The 2oo2 architecture also includes a watch-dog facility and relevant power supply circuits. The watch-dog and power supply circuits are contained in a µTCA 19" card file placed in each of the CIU racks (power control box).
In certain circumstances, the central interlocking units can be in different rooms, but for the standard versions the two central interlocking units are in separate cabinets which are placed side by side. Each independent processing section contains the following devices.
The CIUs can be placed in different rooms far from each other or in neighbouring cabinets. Each independent processing section contains the following devices:
The logic manager is the invariant code that processes the interlocking controls by performing the safety checks and, if these are satisfactory, generates controls for the equipment out in the field.
From a software point of view, it is a "safe interpreter" of a byte-code generated off-line from object-oriented language sources.
Object-oriented language is used to describe the signaling devices as objects belonging to a certain context class which, according to events (field indications, events from other objects, operator or automatic controls), develop their own state. The language also provides the possibility of defining, for each context class, several connections to the object controllers to make the safety logic for the signaling devices independent from the control and indication method. The peculiar characteristics of the ObjRail language, and types of variables in the context classes, are described in separate documents.
For each process cycle of the central interlocking unit, the logic manager processes the byte-code of the context classes, defined by the safety-logic software design engineer. The characteristics of each instance are always extracted during the execution phase from the configuration database.
Execution of the class byte-code produces an update of the class dynamic variables which represent the state of the logic entity, and an update of the interface variables which generate the control messages to the object controllers.
The interlocking rules database contains the specific application’s safety logic which configures the HMR CBI so that it is in line with the signaling principles of the specific country.
The configuration database contains the site-specific data for a particular geographical application. This data defines the actual points, track circuits, signals and so on that are to be used with each of the processes defined in the interlocking rules database.
The data preparation process (DPP) includes all tasks needed to produce the central interlocking unit’s data system files from source documents (the Signaling Scheme Plan and the Control Tables).
The scope includes preparing the safety logic and application-specific geographic data (all elements of application data used by the central interlocking unit). System file generation is a key step of the data preparation process in which the safety logic and geographic data are brought together to be loaded onto the central interlocking unit’s independent processing sections.
The data translation tools used in the data preparation process for the generic application and specific application phases are:
The data preparation process is in compliance with CENELEC EN 50128 Norm Railway applications - Communications, signaling and processing systems - Software for railway control and protection systems, in separate documents.
Progress Rail Signaling S.p.A.
Via IV Novembre 29
51034, Serravalle Pistoiese
Pistoia, Italy
Partita IVA 00089860472
Tel. +39 0573·1916301
amministrazione@progressrail.com
Calata Cattaneo, 15
Edificio Millo,
16128, Genova
Italy
Via Quintino Sella, 15
00187, Roma
Italy
Carl-Benz-Str. 1
68167 Mannheim
Deutschland