Application of Distributed Architectures of Interlocking in Metropolitano

7/27/2019 Application of Distributed Architectures of Interlocking in Metropolitano

1/8

THE APPLICATION OF DISTRIBUTEDARCHITECTURES ON VITALINTERLOCKING SYSTEMSDwayne AllanB Eng (Hons), PGradCert (Railway Signalling), AMIRSE, MIEAust, CPEngSiemens Ltd.

IRSE Australasia Technical Meeting: Adelaide 22 July 2011 Page 1 of 8

SUMMARY

Distributed control systems have their heritage in manufacturing, process or other forms of dynamic systems in which

the control of sub-systems is distributed throughout the system but controlled by one or more programmable logiccontrollers (PLCs) in a central location. This philosophy is often applied in process environments with equivalent SIL

requirements to railway signalling systems.

This paper will outline the use of distributed architectures in a railway signalling context, in particular the system flexibilityand resultant changes in system design and requisite cost implications for railway authorities when used as vitalinterlocking systems. Sample system layouts using traditional and distributed architectures will be reviewed as well asthe benefits and limitations of the each system application.

The advancements in PLC technology its application in safety-critical systems will be reviewed. The open data

communications functionality and the streamlined programming techniques used as part of industrial automationapplications will be outlined. How these advancements and techniques are used in a railway signalling interlockingapplication will also be discussed. In particular, the use of function blocks and function calls to create a library ofsignalling principles will be addressed.

An overview of the significant benefits of applying industrial automation philosophies to railway signaling projects will beprovided. The impact of these benefits on the Total cost of Ownership of distributed architecture systems using industrialautomation technology will also be discussed.

1. INTRODUCTION

Process control is a generic term commonly applied todescribe a system for maintaining the output of aprocess within defined limits. Modern systems that

provide process control are predominately based ondistributed architectures utilising industrial automationcomponents, in particular, Programmable LogicControllers (PLCs) and distributed I/O modules.

The aim of this paper is to show how a railway signallingsystem, via its distributed infrastructure, lends itself to

control by distributed architectures.

The benefits of applying this philosophy along with the

adoption of industrial automation components will bedemonstrated.

The paper will also provide an overview of theseindustrial automation components and their applicationin a railway signalling context.

The impact on the Total Cost of Ownership whenadopting this philosophy and technology will also beexplored.

2. CLASSES OF CONTROL SYSTEMS

Systems that provide process control can be in the formof logic (or sequential) and feedback (or linear)controllers.

In a manufacturing or process control sense logiccontrollers use inputs from sensors, switches and

operator commands etc to control desired outputs oractions, such as starting or stopping an electric motor.Historically, logic control was implemented via relayinterfaces. Programmable Logic Controllers (PLCs) arenow predominately used in place of relay controlledsystems.

Feedback controllers on the other hand, whist potentiallyusing the same sensors and switches as in a logic

control system, output the control commands as a

variable signal to maintain a process within a definedoperating range. An example of this would becontrolling the flow of a fluid in a pipeline by varying theflow through a controlled valve.

This paper will focus on logic control as it is morealigned to the context of Railway Signalling.

3. PROGRAMMABLE LOGIC CONTROLLERS

Programmable Logic Controllers (PLCs) areprogrammable microprocessor-based devices used in

process control applications. PLCs differ from generalpurpose computers by the number and type of I/O portsthey provide and by their I/O scan rate. They are alsodesigned for applications within industrial environments.

Programming of the early PLCs was via ladder logic.This is essentially a program language which closelyresembles the diagrammatic structure of relay circuits.


2/8

IRSE Australasia The application of distributed architectures on vital interlocking systems


This had the distinct advantage of reducing the trainingrequirements for programmers due to the similar logicphilosophies of ladder and relay circuits.

One of the most significant advancements that the PLCbrought was the communications functionality. A

standard PLC will have built in communicationscapability. The communications protocols used aregenerally open protocols such as Profibus, Modbus,TCP, Profinet IO etc.

The addition of the communications functionality wasintegral to the advancement of Distributed Architecturesin the process control environment.

Recent developments in PLCs have seen theintroduction of safety PLCs for use in safety-critical

applications.

4. CONTROL SYSTEMS IN A RAILWAYSIGNALLING CONTEXT

A railway signalling system and in particular theinterlocking is essentially a dynamic process control

whereby a movement authority is not provided to adriver unless the route to be used is safe. To achieve

this; inputs (i.e. track occupancy, points detection,opposing signals etc) and outputs (i.e. point operation,signal aspects etc) are collected and processed toensure that the required prerequisites for the intendedroute have been satisfied. The processing is inaccordance with the railway authoritys signallingprinciples via the application programming.

5. RAILWAY SIGNALLING SYSTEMARCHITECTURES

Architectures for vital Railway signalling interlockingsystems can be separated into three categories;

centralised, decentralised, and distributed.

These types of architectures are distinguishable not onlyby their architecture, but also by the functionality of thesystem.

The following sections will provide an overview of the

various architectures in a railway interlockingapplication.

5.1 Centralised Architectures

Centralised architectures have their heritage on railwayswith dense population centres such as those foundpredominately in Europe. These systems generallyhave a large amount of controlled equipment as part of

the interlocking system and the distribution of thecontrolled equipment is usually over long distances(refer to Figure 1). For these applications, large and

powerful controllers are employed.

Since a single controller is responsible for a largeamount of equipment, the reliability of these systems isparamount. The field equipment is hard-wired to thecontroller. A failure of the controller in a centralisedarchitecture has dramatic and significant effects on theavailability of the signalling system.

For this reason, the controllers used in centralised

architectures are nearly always two out of threesystems. A typical centralised controller comprises

three identically programmed microcomputers,identically structured, command-synchronised, butindependent of one another. This provides the requisitesafety functionality whilst providing a measure of

improved availability via the redundant controllermicrocomputer.

Centralised controllers are also typically high costoptions; however in the correct application they can becost effective.

Figure 1: Sample centralised architecture

A summary of the respective advantages anddisadvantages of centralised architectures are shown

below.

Advantages:

Can control many elements in complex interlockingapplications

Large control distances (some examples of over6km)

Maintenance / fault rectification of the interlockingin a centralised location

Limited interlocking equipment located in thetrackside environment

Disadvantages:

Significant amount of copper cabling required to

connect to the field equipment

High availability requirements of the controller,therefore high unit cost


3/8



5.2 Decentralised Architectures

Decentralised architectures in railway signallingapplications were, in the main, developed for longnarrow networks i.e. freight and ore lines.

The architecture of decentralised systems is onewhereby many controllers are used to individually

control smaller groups of elements. Each singlecontroller is located near the equipment (refer to Figure2). Often there is no traditional cabled connectionbetween the controllers. Communication between thecontrollers is limited and typically, in a North Americanapplication for example, achieved via coded trackcircuits.

Since multiple controllers are responsible for smallergroups of equipment, the reliability of these systems is

often not as high a requirement as in centralisedsystems. A failure of a controller in a decentralisedarchitecture will mostly be confined to the immediatearea of control and possibly the adjacent controllers.

The controllers used in decentralised architectures aretypically single microprocessors running diversesoftware to provide a two out of two system. Thisprovides the requisite safety functionality but cancompromise the availability of the system.

Decentralised controllers are typically a low unit costoption for railway signalling applications.

The respective advantages and disadvantages ofdecentralised architectures are essentially the converseof a centralised architecture. A summary is shownbelow.

Advantages:

Lower availability requirements of the controller,therefore lower unit cost

Limited amount of copper cabling required toconnect to the field equipment

Disadvantages:

Limited number of controlled elements percontroller

Reduced control distances for the field equipment(i.e. potentially many controllers required)

Maintenance / fault rectification of the interlockingis dispersed along the trackside

Substantial quantity of interlocking hardwarelocated trackside

Figure 2: Sample decentralised architecture

5.3 Distributed Architectures

Distributed architectures in railway signallingapplications are relatively new developments. With thistype of architecture a controller is responsible for a

defined control area. However, as opposed to acentralised system, the controller is not hard-wired tothe field elements. Distributed Input/Output (I/O)modules are connected to the controller via acommunications system. The distributed I/O modules

provide the connection to the field elements (refer toFigure 3). The sample architecture provided in Figure 3demonstrates a system using three controllers.

Depending on the complexity of each controlled area,this could in reality be achieved using one controller.

The controllers used in distributed architectures arepredominately the same structure as those used indecentralised architectures i.e. single microprocessorsrunning diverse software. This raises the questionregarding reliability and availability. If one decentralisedstyle controller is responsible for potentially a similar

number of elements as a centralised controller, surelyavailability is a concern. This is where the industrialautomation world comes to the fore.

A significant feature of industrial PLCs is their reliability.End users of PLC based automation systems includecompanies such as the Ford motor company. When


4/8



PLCs are controlling entire factories for thesecompanies, they demand, and receive reliability fromtheir controllers.

Railway signalling systems with distributed architectureshave the closest alignment of the three described in this

paper to the current applications in the industrialautomation world. As discussed earlier in Section 4,safety PLC technology is now applied in safety-criticalapplications.

A failure of a controller in a distributed architecture willultimately have the same outcome as that of acentralised architecture system, however the highreliability of the controller used somewhat mitigates thiseventuality. Failure of the distributed I/O, whether that

be the entire I/O unit or discrete modules will howeverbe localised to the relevant field equipment.

Figure 3: Sample distributed architecture

Controllers used in conjunction with distributedarchitectures, as with decentralised systems, aretypically low unit cost options for railway signalling

applications.

The advantages and disadvantages of distributedarchitectures are shown below.

Advantages:

Limited amount of copper cabling required toconnect to the field equipment

Capable of controlling many elements in complexinterlocking applications

Maintenance / fault rectification of the interlockingin a centralised location

Large control distances (only limited by thecommunications system)

Ability to use industrial automation technology

Disadvantages:

High availability requirements for the controller

Reliant on the communications system to providereliable connection

Some of the interlocking hardware locatedtrackside

6. INDUSTRIAL AUTOMATION IN VITALINTERLOCKING SYSTEMS

The preceding sections have served to outline differingarchitectures that can be used in Railway signallingarchitectures.

As mentioned in the distributed architecture section,industrial automation is at the forefront of distributedprocess control. Given the advancements in PLCtechnology and with their growing application in safety-critical systems, why then do railways stay on the pathof bespoke technology when it comes to vitalinterlocking systems? A true distributed railwaysignalling interlocking architecture is a viable and

achievable goal using industrial automation componentsand practices.

6.1 Safety PLCs

Safety PLCs are used in a variety of safety-criticalapplications. These range from simple lock-outapplications, to complex process control applicationsassociated with nuclear power stations.

Safety-critical functionality is mainly implemented bysafety functions in the software and firmware. Thesafety functions are executed by the system so that, in

the case of a hazardous event, the process can be setto or kept in a safe condition.

Fail-safety, in a Siemens safety PLC for instance, isachieved by use of the following features:

coded monoprocessor

safety-related software in the fail-safe CPU

automatic self-testing, carried out by the operatingsystem

dual-channel processing of the distributed I/O

functions

fail-safe fault detection

separation of fail-safe and standard single-channelperipherals

high reliability of the components


5/8



6.1.1 Safety Microprocessor Structure

A safety PLC, and once again using the Siemens PLCas an example, uses the principle of time redundancyand diversity rather than structural redundancy toachieve the requisite safety objectives.

The user programs the project specific data. Next, a

second diverse redundant form of the program isautomatically generated and compared with the originalprior to download to ensure identical function. Thesafety PLC runs both programs with the results ofeach being compared each cycle to ensureconsistency.

The safety-related input signals are processed diverselyand redundantly in time (refer to Figure 4).

The signals A and B are processed with an AND logic

operation, giving output signal C. In parallel, thecomplements of signals A and B are processed with anOR logic operation, giving an output signal D. Outputsignals C and D are then compared with one another. If

D does not equal the complement of C, the CPU revertsto the stop state. If the comparison is successful, theoutput is set.

The PLC checks that the controls are operating correctlyby carrying out regular self-tests and command tests as

well as a program run check.

Figure 4: Diversity in a Siemens safety PLC

This structure is referred to as 1 out of 1 Diverse(1oo1D) structure. 1oo1D implements diverseapplication software on single channel hardware.

6.2 Data communication

Communication between the PLC and the distributed I/Omodules in the case of a Siemens safety PLC is via

PROFINET IO. PROFINET IO is a comprehensivestandard for industrial automation and is based onIndustrial Ethernet. PROFINET IO is used to connectthe distributed equipment to the central controllerdirectly via Industrial Ethernet.

Vital functions are implemented over thecommunications system via PROFIsafe. ThePROFIsafe protocol ensures fail-safe communicationbetween the PLC and the distributed components.

PROFIsafe relies on established standardcommunication components such as cables, ASICs(application-specific integrated circuits) and softwarepackages.

Communication between the controller and the HMI canbe achieved through numerous, generally open source,protocols. Most communications processors have noless than eight protocols available as standard. Other

bespoke communications protocols can also beconnected to the PLC via communications mappingblocks within the software.

6.3 Software and Programming

The software structure on a safety PLC is divided into ageneric part and a customer-specific part (refer to figure

5).

The generic part of the software is customer-independent and comprises a library of fail-safe functionblocks (F-FBs) and fail-safe Function Calls (FCs). In arailway signalling application, these F-FBs and F-FCsare essentially the signalling principles of the railwayauthority.

Figure 5: Software structure

The F-FBs and F-FCs of the base system;

contain all components involved in the processcontrol as software elements

contain software modules which feature self-contained individual functions

permit the coordination and intercommunication ofdistributed controllers

The customer-specific part of the software isprogrammed and tested separately by the customer orintegrator and comprises the configured, site specific,interlocking data.

The site specific data is programmed via an elementinterconnection diagram using drag-and-drop

functionality (refer to Figure 6).

Figure 6: Element interconnection diagram


6/8



The element interconnection diagram is based on ageographical circuitry principle. In a railway signallingcontext, all elements or at least all elements useable forroutes are part of the element interconnection diagram.It contains all the physical and logical elements of the

interlocking area and other important information, suchas:

element number and element type

element characteristics

designation of the installation and assignment ofthe physical elements to the peripherals

connections and detection areas of track vacancydetection devices

interfaces to adjacent stations or other interlocking

adjacent element relationships

The element interconnection diagram provides the linkbetween the actual architecture of the field equipment

and the application software. Figure 7 shows the logicbehind the element interconnection diagram. Thisexample is for a point control element. The functionblock is represented by the square element. Thefunctions on the left hand side of the diagram are inputs

into the function block, the right had side are the outputsfrom the function block.

The DEWEMO is one of the distributed I/O modulesused by Siemens for point control. FM is theabbreviation used for track vacancy detection sections.The Spoor functions are possible routes over this set ofpoints. The inputs to the function block are primarilythese three pieces of information:

From DEWEMO the detection status of the points

From FM Groups the track occupancy status ofrelevant track sections

From Spoor Functions the route relatedinformation relevant to this set of points

Fundamentally, these are the same pieces ofinformation contained within a point mechanism controltable.

The outputs are generally to make the points move oneway or the other depending on the desired route.

The processing of these inputs and outputs takes placein the function block.

Using the element interconnection diagram andunderlying FBs and FCs provides significant timesavings to the application development process.

Additionally it provides uniform structures for theapplication data. Moreover, the function blocks are

developed, tested and validated according to theCENELEC process, and form part of the overallapproval. Therefore after being certified once thefunction blocks do not need to be certified again as partof the site specific testing.

The programming principles outlined above for therailway signalling interlocking context are essentially thesame as a standard safety PLC used in a non railway

application. The fundamental differences betweenrailway and non-railway are in the fail-safe function blocklibrary, which is obviously now railway signalling centric,and small changes to the element interconnection

diagram. Overall the high level process is that which isapplied in an industrial automation application.

Figure 7: Configuration parameters for a Point element

If we compare the process outlined above with that of aconventional PBI application data design process, somesignificant differences can be highlighted.

Conventional PBI application data is generally aBoolean representation of the interlocking functionsdescribed in the control tables. The data is usuallywritten from scratch relying on the correct interpretationof the control tables and underlying signalling principlesby the designer. With this method, every line of datamust be thoroughly checked and independently verifiedprior to proceeding to the testing phase. This is required

to ensure that a complete and correct interpretation of

the control tables and signalling principles has beenused in the preparation of the application data.

This use of the element interconnection diagram and theease of application programming it provides, allows theoption of using junior signalling engineers to produceapplication data. This task in the conventional PBIsignalling design process is generally undertaken by

senior signalling engineers or at least specialistapplication data signalling engineers. With the Industrial

Automation platform the application data could in fact beprepared by someone other than a signalling engineer,possibly external labour. The prerequisite for theindustrial automation style of programming is moreproficiency in the programming tools, rather than

proficiency in the signalling principles of a railwayauthority.

Another area of departure from conventional signallingprocess is that related to testing of the application data.


7/8



A conventional PBI must undergo a principles test.Principles testing of a conventional PBI traditionallyinvolves testing by a competent, usually senior, engineerworking from first principles, not from control tables.Once again this requires an intimate and complete

understanding of the signalling principles of the railwayauthority.

Conversely, using the industrial automation principlesand techniques largely removes the underlyingrequirement of complete understanding of the principles.

As discussed earlier, the signalling principles areinherent, and unchangeable, within the generic part ofthe software. These rules have already been tested andvalidated as part of the overall interlocking system.

Consequently, the principles test now becomes more aset to work test proving that all elements (i.e. routes,points, etc) are functioning correctly and as specified inthe control tables.

A white paper produced by Invensys Rail in the UKfound that around 2/3 of the labour allocation during the

implementation phase of a railway signalling project (i.e.design and testing) was undertaken by specialist design

houses [1]. The Industrial Automation approach toprogramming and testing would surely reduce thisreliance on signalling specialists during projectimplementation.

7. BENEFITS

The benefits of applying industrial automation

components and philosophies in distributedarchitectures to a railway signalling interlockingapplication are numerous.

7.1 Reduced Project Implementation Time

The industrial automation platform provides short projectimplementation times. This is achieved through the useof readily available hardware and parameterisablesoftware. The software elements provide the self-contained functions of a geographical circuitry systemwith a constantly growing scope of functionality.

The use of pre-tested, verified and certified functionsthat contain the requisite signalling principlessignificantly reduces the requirements of principlestesting. In essence the principles testing has alreadybeen performed during the creation and validation of thefunction blocks. The principles testing is basicallyreplaced by functional testing of the interlocking with thistechnology.

Labour savings, both in actual time and the grade ofresource used, can be realised through the adoption ofthese programming and testing philosophies.

7.2 Simple Configuration

Compared to traditional interlocking data development,the industrial automation process via the drag-and-dropfunctionality of the element interconnection diagramsprovides substantial savings during the engineeringphase. The used of non-signalling resources to provideapplication data services is a real possibility.

7.3 Scalability

Safety controllers with different levels of performanceare available and can be selected on the basis ofinterlocking complexity. Should future expansion of thesystem (and subsequent increased complexity) occur,

the safety PLC can be easily upgraded if required toprovide additional processing power.

The distributed I/O is also easily adapted to futureexpansion. As previously described, the link betweenthe PLC and the I/O is via a communications network,

not a cabled connection. Additional I/O units can beadded to the interlocking system by simply providing acommunication connection.

7.4 Maintainability and Spares

The diagnostic and maintenance capability of theindustrial automation equipment is superior to traditionalinterlocking platforms. In the event of a fault, thediagnostics functions can be accessed from any locationwithin the distributed system. This provides for flexibleand rapid fault rectification.

Using the industry based tools the topology of thedistributed system is displayed graphically in a window.The status of each of the distributed modules isdisplayed within this window thereby providing pertinent

information at a glance. More detailed information foreach module is available from the overviewwindow. This information includes comprehensive errordetails of the affected module in plain text. Additionally,the system inputs and outputs can be directly monitored

from the system overview window.

In terms of corrective maintenance the industrialautomation platform provides hot swappablereplacement of the boards and modules. This providesfor rapid fault rectification with limited impact of non-affected modules and elements.

8. TOTAL COST OF OWNERSHIP

A measure of a systems long term benefit to an

organisation is its lifecycle cost, or better stated, theTotal Cost of Ownership (TCO). The TCO is anestimate of the financial benefit of an investment to anorganisation.

A recent white paper produced and sponsored byInvensys Rail found that around 60% of the total cost of

ownership of a railway signalling system over 20 yearswas associated with the implementation phase of theproject i.e. in the first year [1]. This includes activitiessuch as; design, acquisition, installation, testing andcommissioning.

The paper goes on to compare a railway signallingsystem implementation phase proportionally with that in

the telecoms industry. It found that, whilst having manyparallels to the railway signalling industry, such as highavailability, distributed physical infrastructure andcombing physical assets with computing processes, theimplementation costs are around 50% higher in railwaysignalling compared to telecoms. The reasons for thisdifference, as proposed by the authors, were:

Technology differences and the fact that modularityof design and open interfaces do not yet exist in

rail

Less demand for open interfaces in the railwaysignalling industry

That the telecoms industry taps into a much larger

supplier market, which encourages innovation

It would seem from these factors that the telecomsindustry has many parallels with the industrial


8/8



automation world. For instance, Industrial Automationprovides modularity of design and open interfaces, theopen communications protocols being the best evidenceof this. Furthermore, the Industrial Automation industryhas very large supplier base which provides for more

competition amongst suppliers. This also fosters anincreased focus on research and development to stay

ahead of the competition.

By virtue of the parallels between Telecoms andIndustrial Automation, it could be argued that thereduced implementation phase costs that are beingachieved in the telecoms industry can in fact be realisedin the railway signalling field if the use of distributedarchitectures using industrial automation equipment

were adopted. Doing so would make the TCO of arailway signalling system a more attractive investment tothe stakeholders.

9. CONCLUSION

Distributed architectures, particularly those utilising

industrial automation products and philosophies, are

effective means to provide innovative and cost effectivesolutions for railway signalling systems.

At the same time, these systems can provide increasedsystem functionality, flexibility, reliability, availability, andmaintainability, all with no decrease in the safetycriticality of a railway signalling interlocking.

Moreover, reduced TCO through the adoption of thesesystems and products will provide stakeholders with

more attractive investments.

10. REFERENCES

1. Invensys Rail. Total Cost of Ownership of RailSignalling Systems, Chippenham 2010

ACKNOWLEDGEMENTS

I would like to thank Siemens Ltd for the time andsupport in producing this paper.

AUTHOR

Dwayne Allan

Dwayne started with Queensland Railways as a cadet inthe Signal and Telecommunications department in 1989.He held many roles and eventually progressed to SeniorDesign Engineer before leaving to join Siemens Ltd. in

2006.

At Siemens Ltd., Dwayne now holds the position ofEngineering Manager in the Mobility Division. In thisrole he is accountable for the engineering and projectmanagement of Siemens signalling works. Dwayne isalso responsible for the introduction, application andtechnical support of the complete range of Siemenssignalling products across Australia and New Zealand.

Application of Distributed Architectures of Interlocking in Metropolitano

Documents

Transcript of Application of Distributed Architectures of Interlocking in Metropolitano