Jump to content

Collingwood IECC - Creating a Prototypical IECC for a Model Railway


Recommended Posts

753755273_WelcometoCollingwoodIECC.jpg.707624bc2909193df958de231607b2a2.jpg

 

I think I’ve put it in the most suitable place as it could relate to a layout topic, computer control topic and signalling topic.

 

This is the start of a series of posts where I describe how I created a prototypical Integrated Electronic Control Centre using JMRI Panel Pro to control my new (under construction, kind of) layout, Collingwood.

 

Before I start I would like to say thank you to Dan Smart, my boss, who has used JMRI Panel Pro to create a Western Region NX Panel and gave me a lot of support. Also, thanks goes to Kevin Marsh, who unknowingly helped me through inspiration from his own JMRI based IECC.

 

Part 1 – The Real Thing

 

Before I launch into how I created an IECC Workstation, I should explain what an IECC actually is, although I know that there will be quite a few people who know what an IECC is (please correct me if I’m wrong!).

 

IECCs, or Integrated Electronic Control Centres, first appeared in 1989 at London Liverpool Street having been developed by BR Research, and has so far spread far and wide, with IECC installations at York, Yorker (Glasgow), Marylebone, Tyneside, Slough, Ashford (Kent), Swindon (since been moved to TVSC), Sandhills (Liverpool), Upminster, Edinburgh and Thames Valley Signalling Centre (TVSC, Didcot).

 

Many think that IECC refers to a single building, but actually a signalling centre can contain several IECCs, for instance Thames Valley Signalling Centre contains 9 IECCs that control Paddington out to Bristol spread across 12 workstations.

 

The term doesn’t specify an Interlocking type, as in theory it is possible to connect an IECC to a relay interlocking, but most use either a Solid State Interlocking (SSI) or a Computer Based Interlocking (CBI).

 

1889727162_Figure14B.JPG.0a8032619cd2e713ba5f962d06c61763.JPG

 

839575830_Figure14A.JPG.426d18a92fda4cc9068413e414fd85c9.JPG

 

 

Above: The Smartlock (Top) for the Paddington Area and Westlock (Bottom for the Didcot Area at Thames Valley Signalling Centre in Didcot. (C) Simon Paley

 

Technically IECC is a product name used by Resonate (formally Delta Rail) to describe their VDU Control system, there are a number of other products which have the look and feel of an IECC, such as WestCAD (Siemens) or MCS (General Electric). Currently true IECC comes in 2 varients, IECC Classic and IECC Scalable.

 

IECC Classic refers to the original form of IECCs that use fixed CRT type monitors and Trackerballs, on this type the area under the signallers control is fixed and can’t be changed. Whereas IECC Scaleable refers to a set up that uses modern flat screen monitors and a proper computer mouse, however, the major difference is that it is possible to display the entire area under control of the whole signalling centre, with the signaller then able zoom in to / move around the area under their control. The main advantage behind Scalable is that when a very large area is under possession with little movements, it is possible to display it on a single workstation to be worked by a single signaller and then split it between several signallers in normal service.

 

527388321_Figure12.JPG.78849e31e2ffdce1606a0a2494017946.JPG

 

 

Above: The Workstations at Three Bridges ROC, whilst these aren't technically IECCs, they look and work almost the same way, (C) Simon Paley

 

Most IECC installations show three different displays:

 

·         A Detailed Display – This is the display that the signaller actually uses to control the railway and shows all the details required.

·         An Overview Display – This shows a less detailed and general overview of the railway under the signallers control.

·          General Purpose Display - This is where any Interlocking, Train Describer or Automatic Route Setting messages and alarms are displayed.

 

The basic IECC consists of just the interlocking and control system (workstation), however in the vast majority of cases, there are multiple sub systems that use information outputted by the IECC. These include the Train Describer Sub-System, the Automatic Route Setting Sub-System, the TRUST / TOPS Sub-System and the Customer Information Sub-System to name but a few. Together these not only drive the signalling, but also staff and passenger information systems.

 

Now you know the basics of what an IECC is, I can go on to talk about re-creating it in the model world...

 

Simon

Edited by St. Simon
  • Like 2
  • Informative/Useful 4
Link to post
Share on other sites

Part 2 – The Architecture for Collingwood IECC

 

The only way to create a totally authentic and prototypical IECC for a model is either go out to Resonate / Siemens and buy a real IECC and Westlock (but don’t expect to get much change out of a several hundred thousand pounds) or create custom software from scratch. I have neither the time, money nor skill to do either of those. So, I have had to find a different solution.

 

There are plenty of computer packages available for modellers to create control panels to connect with a layout, but most of these have one or more of three problems; they are costly, aren’t customisable to the extend I need and don’t have the ability to perform UK like Interlocking and Control functions.

 

There is one exception, JMRI Panel Pro.

 

Before I go on, I must say I have no involvement in the development of JMRI, being purely a user of the system.

 

JMRI Panel Pro is a free, Java-based computer system developed using the ‘Open Source’ software development system, whereby developers are given the source code to build upon and to improve the system rather than a single team develop it on their own.

 

The Key to Panel Pro in my scenario is the ability to develop your own panels using any graphics you want to suite your purpose and is infinitely configurable (well, maybe not infinitely, but far beyond any commercial software package like Train Controller), both in terms of presentation and operation.

 

Also, you can create a number of panels in one file to do a number of different things, so for me I’ve created two Panels:

 

Collingwood IECC

 

 

847876003_CollingwoodIECCFInal.jpg.96e8d0692d6286249779b53477d1155c.jpg

 

This is the main signalling panel where routes can be selected, this will be used by the signaller and will also be on display to the public at an exhibition

 

Collingwood Technician & Train Describer Panel

 

537939328_TrainDescriberPanel.jpg.1594147384b38760b11ec8873c5ba4cf.jpg

 

 

 

As the name suggests, this allows me to act as the Box Technical Officer, where I can simulate failures such as Lamp Failures, Loss of Point Detection and Track Circuits Failing. I can also use it to interpose anything I want into any of the Train Describer Berths as well as initiate the Automatic Route Setting. This will also be visible to the Signaller.

 

I will go into the creation and operation of each in further posts.

 

Much like the real thing, I have split my version of an IECC into different ‘Sub Systems’:

 

·         Interlocking: This will actually control the points and signals on the layout

·         Train Describer Sub-System: This deals with the Train Describers (funnily enough!)

·         Automatic Route Setting Sub-System: This takes info from the Train Describer Sub-System and uses to automatically generate route requests to the Interlocking

 

Again, I’ll explain those in future posts

 

Another advantage for me is that it can connected to loads of different layout control systems. In my case with Collingwood, I’m using MERG CBUS for the signalling control on the layout, as this relative cheap and more flexible than if I was to use, say, Digitrax to interface with the layout.

 

In the next post, I'll describe how I created the Graphics for the Panels.

 

Simon

 

Edited by St. Simon
EDIT: New Panel image and CIS boards removed
  • Like 4
  • Informative/Useful 1
  • Craftsmanship/clever 3
Link to post
Share on other sites

  • 2 months later...
  • 2 months later...

Part 3 – The Symbols and Graphics

 

This was probably the trickiest bit of the whole thing for me, as there was very little information on how to actually make a panel in JMRI that actually looks and functions like an IECC (or any other signalling panel for that matter).

 

I eventually found the way to do it was to create the panel in the ‘Control Panel’ editor of JMRI. Whilst this seems very obvious, there are several editors for panels in JMRI (‘Control Panel’, ‘Panel’, ‘Layout’ and ‘Switchboard’) and the all have different things that they can and can’t do. I found that the ‘Control Panel’ editor allowed me to use graphics files and associated them with interval event states to animate the panel. Also, the ‘Control Panel’ editor seemed to be the only editor that allowed me to make the back ground black.

 

Once I had found this out, I had to draw all the graphics. I use a graphics package called ‘Serif Draw Plus’, which I had from when I did product design in A-Level, however, if you are skilled at Paint, then you should be able to create the necessary graphics. I first drew out the panel as a whole to see what it would look like and how I would carve it up to use in JMRI.

 

To make sure I had the right symbols, I used the (now withdrawn) Railway Group Standard Guidance Note GK/GN/0525 ‘Guidance Note: Signalling Control Centres’. This contains the majority of symbols for not only IECCs but also NX Panels and Lever Frames. I have changed a couple of the symbols slightly, most notable the route setting components (now on that later) and the Train Ready to Start (TRTS) indication, which I have changed from white to light blue, just because it looks a bit better. The graphics I’ve drawn aren’t to any sort of scale, just proportion to look right compared with the standard, although I’d wish I’d drawn them slightly smaller to make it fit nice only a single screen!

 

Then I had to understand the various states and colours everything had to be in various scenarios, for plain line track sections, there are three basic states:

 

 

1933732389_PlainLineStates.jpeg.86ee21302e26179c03232b94d402f573.jpeg

The three basic states of plain line track, in this case an overlap track

 

For track sections with points in them it gets a little harder, they technically have eight states associated with them, but due to the way that I built the panel in JMRI, I’m only showing the seven below. For my panel, the two states that show whether the points are lying Normal or Reverse when no route is set are combined to just show that no route is set over the points without the showing which way there are lying:

 

761608581_PointsState.jpeg.c1f0f997ef71d0d3931e6cfcf14f1566.jpeg

 

 

The seven states of track sections with points used on Collingwood IECC. Points OFC means that the point position is not detected and therefore ‘Out of Correspondence’, the blue section flashes on and off in this state.

 

Signal Indications also have multiple states:

 

1678626923_SignalStates.jpeg.970f0c3e904310a2b3c478836c88dae1.jpeg

 

Once I had overall image, I then could start carving it up into the graphics for use on the actual panel. But before I go into this, I must describe how the panel is animated with JMRI and I must say that this probably isn’t the best way of doing it, or the most efficient way, but it worked for me.

 

The way I’ve built the panel is that all the panel icons are internal JMRI objects, so all the buttons (route setting, point position buttons etc.) are internal sensors whilst all the indications (signal indications, track indications etc) are internal lights.  The reason I choose this method is that the standard objects that JMRI provides aren’t flexible enough, doing it the way I did it allowed me much greater flexibility.

 

Now, with JMRI, lights can only be ‘on’ or ‘off’, i.e. they can’t show multiple states such as red yellow or green for signals or grey, white or red for track indications. So, effectively each different colour for each symbol is a separate internal light.  To make all the colours for a particular symbol show up in the same place, I have to use the layer feature of the ‘control panel’ editor to stock the graphics on top of each other.

 

However, this causes a problem in that the graphics on top will block the graphics below. For example to make a signal indication with three aspects, I have to make the yellow and green aspect sit on top of the red aspect. To ensure that the correct aspect is visible at the correct time, I actually create a graphic which is a black square (I’ll explain a why a square in a minute) which has a see through hole in the middle when the internal light state for the aspect is ‘off’ and a coloured circle when the internal light state for the aspect if ‘on’.

 

Aspects.jpeg.359825cce069f16197f6823c7233e07c.jpeg

 

Above can be seen how the signal aspect graphics are constructed individually

 

This principle is also used to get the multiple states of track circuits, however, working out which bits have to be see through when in which state on pointwork can be quite confusing.

 

The only problem with this method of animating the panel is that the JMRI only provides 10 layers. For most symbols this is no problem, but where you have two sets of points in a single track section, then you end up using all ten, which can cause layering problems if you want to add other animated objects on top of it.

 

If you have managed to work all this out so far, you can start carving up your overall image into individual graphics. One word of warning on this, it seems that the ‘Control Panel’ editor doesn’t display shapes which aren’t square or rectangular nice, it creates a fine white line around the edges of circles or diagonal lines which stand out on the black screen. To overcome this, I surround which symbol with a black square or rectangular, however, in some cases I couldn’t do this as it would mean block out symbols, so I have ended up with some not very nice white lines on the panel:

 

1008739479_WhiteLines.jpeg.b4482db5f168ae846f5aa4d32e755950.jpeg

 

When carving up the panel for symbols, I had to think about symbols where different parts are animated in different ways and chop them up individually to make them work. For instance, on a signal indication, the actual aspect component and post are animated differently, so the post has to flash white when a route is in the process of being selected whilst the aspect stays a steady colour. Therefore, the post and aspect are two separate internal lights and have two separate graphic sets.

 

To work in JMRI, the I export the graphics as a GIF at the highest resolution and then place them in the icons folder in the JMRI directories folder on the computer.

 

To actually place the symbols on the panel in JMRI and associate them with the internal light they are connected to, you use the ‘Item Palette’ tool in the ‘Add Item’ drop down menu:

 

1 – Open ‘Item Palette’ window:

 

2042383804_Step1.jpeg.01c48cbea87dc8e73bb22746fcc8457e.jpeg

 

 

2 – Select the internal object you wish to associate the graphic with:

 

1916336193_Step2.jpeg.1391203cbf42606a6ae16db898f1a0bb.jpeg

 

 

3 – Go to ‘New Icon Set’ at the bottom of the window, a new window will open. You will be prompted to name your icon set.

 

1838025820_Step4.jpeg.4bf07ce28072394b950da6358d08bd90.jpeg

 

4 – Browse for your icons in the folder in the lower left-hand half of the window and open up the folder:

 

1838025820_Step4.jpeg.4bf07ce28072394b950da6358d08bd90.jpeg

 

 

5 – Select the graphic you want to use for each state and drag it to state you want it to apply to in the top half of the window (this will override any existing graphics used for that state). Note: I only use the ‘on’ or ‘off’ states in my panel, but all states must have a graphic associated with them, so I put the same graphic for my ‘inactive’ state into unused states as well.

 

 

995330781_Step5.jpeg.b14c62a4907955944c9a514d10e53bf6.jpeg

 

6 – Once all the states have been filled, click ‘Add New Icon Set. This will take you make to the place object window.

 

949993943_Step6.jpeg.c64068b83fc069939e678d51d0a01e98.jpeg

 

 

7 – Simply drag and drop the graphic now displayed at the bottom of the window onto the panel.

 

1864101492_Step7.jpeg.9339fc6c560c389c6abf9d7f21c48d7f.jpeg

 

 

8 – Fine tune the position using the positioning window and define the layer. Also, remember to disable all the elements which you don’t want to do something when clicked.

 

261235327_Step8.jpeg.c34f82e74b2d883ea03e9bc5976aabe6.jpeg

 

 

9 – Once you are happy with the position, click the ‘lock’ button to stop from being moved accidentally.  If layering object on top of each other, remember to note down the X and Y co-ordinates before locking it!

 

1588554203_Step9.jpeg.36d68763be86c9eb0796cfb590a0f542.jpeg

 

 

10 – Now you can move onto the next object.

 

One quirk of the control panel editor is that once you use more than one layer on the panel, to move an object on a lower layer, you must press and hold the shift key whilst you move it.

 

Basic text, such as track circuit, point and line names, can be placed using the text tab in the place object window, these don’t require graphics to be created.

 

That is pretty much how I made the panel look good, next I'll show how I made it work...

 

Simon

Step 3.jpeg

Edited by St. Simon
  • Like 3
  • Informative/Useful 1
  • Craftsmanship/clever 1
Link to post
Share on other sites

Part 4: The difference between real life and the model

 

Before I explain the ins and outs of the actual operation of the panel, I just wanted to discuss the difference between how a real IECC and my version operate is manly how the signaller interacts with the panel.

 

There are three main operations that a signaller carries out on an IECC (or any panel); setting routes, cancelling routes and changing point positions. There are two ways that a signaller carries out these actions, either through using the trackerball / mouse or using the keyboard (by typing in the action to be taken).

 

On my version, the signaller can only set a route using the mouse (I’m planning to use a tracker ball mouse in the future). This is simply because the only way to code the use of the keyboard in JMRI easily is to write a Jython script. This in turn adds complexity and I don’t really need it, plus it needs all the operators to remember the all the actions!

 

To set a route on an IECC, the signaller clicks on the signal post at the entrance signal to start selecting the route and then clicks on the signal post at the exit signal to complete the selection. On my version, I decided to use a slightly different method, instead I have created ‘selection triangles’ on which the signaller clicks to set routes, most triangles are white whilst there are also red triangles where a signal is an exit for a call-on route (as can be seen ringed below).

 

1590039636_PanelButtons.jpg.7eccdcb9f1e5e4aef444fb42718d479d.jpg

 

The reason for this is so I don’t have to create ‘invisible’ click area for the signalling, which just makes it a little easier to use.

 

Now, to cancel routes using the mouse / trackerball on a real IECC, the signaller ‘right clicks’ on the entrance signal to select a drop down menu and selects ‘cancel route’. However, as JMRI doesn’t support the use of right click drop down menus other than for the core functionality for the software, I have to use a different method. Instead, I use a long click (longer than 3 seconds) on the selection triangle at the start of the route (which is the method that Kev Marsh of the Swindon Panel Society uses for his IECC). This does involve some additional logic, but it works.

 

The biggest difference is how point positions are determined, on most panels and IECC, the points have one of three positions, Normal, Reverse and Centre. The Normal and Reverse Positions are the positions that actually allow the signaller to swing the points back and forth, whilst the centre position is where the point position is controlled by the route setting. On an IECC, there are either three position buttons on the trackball, or a right click drop down menu when using a mouse.

 

Obviously in JMRI, neither of these is really possible, so I’ve just got a Normal and Reverse buttons on the panel with both buttons being ‘inactive’ being equivalent to the ‘Centre’ position:

 

1941560498_PointButtons.jpg.656b1b329df372c8f586b57b98d9f54d.jpg

 

Finally, there is one big difference between my IECC and the real thing; it is not safety critical and doesn’t need to be. Technically an IECC in real life is not safety critical, as it is the control system that produces requests for the interlocking and then receives indications back (and therefore only SIL-2), it is in fact the Interlocking that is safety critical (SIL-4). However, I’m using IECC as a ‘cover-all’ term including the interlocking, so my IECC doesn’t need to be safety critical as it is only controlling model trains!

 

Simon

Edited by St. Simon
  • Like 2
  • Informative/Useful 1
Link to post
Share on other sites

Part 5 – Interlocking Basics

 

Behind the IECC panel in JMRI, I have had to code the interlocking logic to control the signals and points on the layout and to ensure the signaller receives the correct indications. To help explain what I did I need to first describe the basics of the interlocking and how it is split up.

 

First, what actually is an interlocking?

 

Well, the RSSB defines ‘Interlocking’ as:

 

A general term applied to the setting and releasing of Signals and Points to prevent unsafe conditions arising; also the equipment which performs this function.

 

I’m afraid to say that a lot of modellers apply the term ‘interlocking’ too broadly. I’ve seen many many layout articles in magazines state that the layout has points and signals interlocked. This means that the signals show the correct aspects for the point positions. This isn’t true interlocking, this is interlinking.

 

An interlocking not only prevents conflicting routes from being set and ensures that the points are set in the right position before allowing a signal to clear (where most model railways stop their interlocking), it also prevents any points from being moved if a route is set over them and prevents a route from being released until it is safe to do so.

 

For route relay, solid state or computer-based interlockings, there are three ‘levels’ to an interlocking. These are the ‘route setting’ level, ‘aspect control’ level and ‘route release’ level to an interlocking. Most signal engineers will only talk about the ‘route’ and ‘aspect’ level, but it can be easier to understand if the route release logic is regarded as a separate level.

 

These ‘levels’ are only used to define what checks are made at each point in the interlocking process rather than being physically separate parts of the interlocking, the most basic of checks for each level is:

 

  •  ‘Route Setting’ Level – This is where checks are made to ensures that points are set in, or are free to move to, the correct position for the route as well as that any opposing routes are not set and that there is no train within that route. This also applies the sectional route locking, which I’ll explain later. It does NOT check the occupation of track circuits (unless it is a call-on or warning route).

 

  • ‘Aspect Control’ Level – This checks that the exit signal is lit, the points within the route are set locked and detected in the required position, all the track circuits in the route / overlap are clear and determines the aspect to be shown for the correct aspect sequence. It also deals with AWS and TPWS outputs as well as the signal ‘stick’ function, which I will explain in a future post.

 

  • ‘Route Release’ Level – This checks that when a signaller requests that a route is cancelled, assuming the signal has cleared, whether a train was on approach to the signal, has come to stand prior to the signal or has entered the route safely and then goes through the various stages to safely release the route.

 

Within these levels, it could be said that the interlocking is split into multiple different sub-processes, which is also how I have set up my logix within JMRI and how future posts will pan out as:

 

1)      Push Button Interlocking

2)      Route Calling

3)      Point Calling

4)      Route Locking

5)      Aspect Controls

6)      Route Release

7)      Indications

 

NOTE: I will not be going in to the full logic behind each of these as they are based on real-life relay interlocking circuits and therefore to preserve the security of these circuit, I’ll only be going into the principles.

Edited by St. Simon
  • Like 2
  • Informative/Useful 1
Link to post
Share on other sites

Part 6 – Coding the Logix in JMRI

 

How the interlocking is coded into JMRI is the same whatever level is being coded, so I’ll run through it here before going into all the principles.

 

I use the ‘Logix’ functionality in JMRI with all the individual relays within the interlocking circuits being replicated as internal sensors.

 

Each of the sub-processes listed in part 5 have been coded is a separate ‘logix’ within the logix table, to add a new ‘logix’ to the table, click the ‘Add’ button at the bottom of the window, you’ll have to name the logix to anything you like:

 

2065270099_LogixTable.jpg.7d50bd72e30510b74a4f8ba8f229bf72.jpg

 

Each of the interlocking circuits within each sub-process is coded as a separate ‘condition’, each condition is added using the ‘new conditional’ button with the logix window, again naming the condition anything you like:

 

433546180_AddConditional.jpg.09b93f2fd96121a5b89fd20155269c67.jpg

 

The conditional window has three main parts, first of all is the part which provides the logical statement:

 

77761875_LogicalStatement.jpg.0f9b83e43bc3037a282801a9c1278c94.jpg

 

This is only displayed if the ‘logical operator’ drop down menu (circled in red) is in ‘Mixed’, I would recommend this as it provides a small level of assurance that everything is correct. The logical statement is effectively the ‘if’ statement in the logic. It expresses the variables as ‘R1’, ‘R2’, ‘R3’ and so on and then ‘and’ / ‘or’ to describe the relationship between the variables. If you wish to describe a statement where either of two sets of multiple variables can be used, then that’s where the brackets come in. Knowing where brackets have to be used and when to use them is the key to interlocking in JMRI and what makes the Logix function within JMRI so powerful.

 

The next part is where the variable ‘R1’ etc are defined:

 

Statements.jpg.7686bfd98f33c3fd08e210efa295ef1d.jpg

 

The variables are added using the ‘Add Variables’ button, which opens up a ‘Edit Variable’ Window and a ‘Pick List’ Window. The ‘Edit Variable’ window gives drop downs from where you can select the type of input, a sensor in the case below, and the state which you want it to be in when you want the logical state to me true. You can either type the name of the sensor you want to use or drag it from the pick list:

 

Variables.jpg.d5e7d42bf254653138e7b2b99b91e2fc.jpg

 

Finally, there is the action part, this is where the actions to be taken in regard to the state of the logical statement:

 

Actions.jpg.8b786f64ea5f6cdba19971056762c2f7.jpg

 

The actions are edited using a similar window to the ‘Edit Variable’ Window above. Most logical statements will have at least two actions, one action if the logical statement is true and one action if the logical statement, however there can be less or more. The thing to note is that each action can only control one object (sensor, light etc.), so if you want two separate things to happen when the logical statement changes between states, then 4 actions would be needed.

 

Where an action applies to a sensor, then the application of the action can be delayed by a time, measured in second.

 

NOTE: For the Signalling Engineers out there that want to use the Logix for interlocking, if you want to simulate slow to pick or slow to drop relay, then the delay function does this (just don’t forget to cancel the timers when the relay drops or picks!). Also, to simulate latched functions, create two conditions, one for the pick path and one for the drop path, and only apply actions for when the logical statement is true.

 

Simon

Edited by St. Simon
  • Like 2
  • Informative/Useful 1
Link to post
Share on other sites

Part 7: Push Button Interlocking

 

 

I’m afraid that this part won’t have many pretty pictures as the concepts are hard to show using stationary images and I can’t film the use of the panel easily, so it will be 99% words!

 

The push button interlocking is the mainstay of an NX Panel rather than a VDU control system, however, as I’m effectively using digital buttons, I’m replicating the circuitry.

 

The Push Button Interlocking (PBI), also known as a Push Button Ring, is provided on the majority of panels, however is really only key when a single panel is being worked by several signallers who may be setting routes simultaneously. If there are several signallers working a single panel, then there is a danger that signaller ‘B’ could accidently finishing setting a route before signaller ‘A’ got the chance to themselves. This could mean that trains are wrong routed or potentially intentionally moves being carried out.

 

To perform this function, all the route setting push buttons within the panel are connected in such a way that pushing one of them effectively prevents any of the buttons being ‘recognised’ by the Push Button Interlocking during the time that the first panel button is pressed, therefore only the push button pushed by signaller ‘A’ would be recognised. The PBI also proves that buttons have returned to their ‘un-pushed’ state before any allowing any other buttons to be recognised.

 

Obviously, this does has one disadvantage when the panel is as big as Three Bridges ASC:

 

449743677_Figure9.JPG.a204f2543299751f4a32e83c9f413908.JPG

 

 

The disadvantage is that if all the route setting buttons are connected together, then one signaller pushing a button at one end of the panel will prevent a signaller at the other end pressing a button which they might legitimately be able to as there is no conflict between the two. To allow this, each panel is broken up to several separated areas rather than all the buttons connect together.

 

Now, this isn’t a problem on a VDU control system as each workstation is only worked by a single signaller at a time, however as I’m replicating a SW67 relay interlocking in digital form, the functionality comes ‘free’ as part of the circuitry which solves other problems.

 

Where a signal is both the entrance to one route from the signal and the exit of a route to the signal, almost all ‘push-push’ NX panels use a single momentary push button to perform both the entrance button and exit button function. Therefore the PBI must also recognise whether a single button push means that the signaller is starting to set a route (using the button as an entrance) or is completing the setting of a route (using the button as an exit).

 

To overcome this, the circuitry relies on three facts:

  1. Setting a route always begins with an entrance button
  2. Setting a route only takes two button presses (forget alternative route buttons for the moment)
  3. Setting a route always ends with an exit button.

This means that when a signaller wants to set a route, the first button pushed by the signaller is recognised by the PBI as an entrance button (regardless of whether the button is actually an entrance button or not). If the button being pushed is actually an entrance button, a relay is picked to tell the PBI this (if not, the button press is ignored). Once the PBI ‘knows’ an entrance button is pushed, then it will recognise the next button push as an exit button (again, regardless of whether the button is an exit button or not). Again, if the second button really is an exit button, the PBI is told by a relay and then it returns to its normal state ready to recognise an entrance button, otherwise the button push is ignored.

 

Although this explanation makes it sound like it, the PBI does NOT actually work out whether the signaller has set a legitimate route or not, this is part of the route setting level of the interlocking, which will feature in part 8.

 

There is another problem that a PBI must tackle; there is the possibility that the signaller may start to set a route but never finish setting it, they may change their mind or get distracted for instance, however with the above circuitry, the PBI will ‘store’ the entrance request until another button is pushed that could later on lead to a route being set that wasn’t intended to be set.

 

The way to prevent this in the PBI is ‘timing out’ requests. Once a legitimate entrance button is pushed, a timing device is started, if a legitimate exit for that signal whose entrance button has been pushed is not selected with a given time period (5 seconds in the case of my IECC), then the entrance button request is forgotten by the PBI. Technically, the timing out of the entrance request still happens even if a legitimate exit is selected, but by that time, the route is locked within the route setting level of the interlocking and no longer needs a push button input.

 

During this timing process, the signal post symbol on an IECC flashes white.

 

Next will come the ‘route calling’ sub-process, I promise more pictures!

 

Simon

Edited by St. Simon
  • Like 3
Link to post
Share on other sites

Hope your going to have 3 MPM’s and plenty of spare bent staples, ahem I mean security fuses.

 

Dont use 9 tiles wall boxes for attaching the nodes to the network.

 

Make sure your SDS does not go on fire!

 

Your techs terminal needs to be an original ‘cypher’ terminal, with tapes!
 

is your interlocking going to have the ‘Newton’ modification when you cold start it?

  • Funny 1
Link to post
Share on other sites

  • 1 month later...

Part 8: Route Calling

 

The route calling sub-process, along with the point calling sub-process, is where the bulk of the interlocking to prevent conflicting routes being set is performed.

 

To start the route calling, we must first define the routes that we are calling. The generic definition of a route is as below, taken directly from my book:

 

A ‘route’ in signalling doesn’t mean the same as in the ‘normal’ world. A signalling route is made up of the not only the physical path of the train, but also a type of route. There are five types or ‘classes’ of route, the following definitions are taken from Railway Group Standard GK/GN0802 ‘Glossary of Signalling Terms’ (Rail Standards and Safety Board, 2004):

 

‘Main’ Route = Route from one main signal to the next that allows running movements. It requires the section and overlap to be clear.

‘Warner Route’ = Route from one main signal to another using a restricted overlap and where the ‘exit’ signal is at red.

‘Call-On’ Route = A route that is provided to permit a train movement into a section known to be occupied.

‘Shunt’ Route = A route used for low-speed non-passenger movements.

‘PoSA’ Route = A route for use during lineside signalling failures to instruct the driver to enter a Signal Section and proceed at such a speed that the train can be stopped short of any obstruction.

 

For the purposes of explaining the processes, I’m going to use two routes from Collingwood, both have the same path as highlighted below, from CD811 to CD813:

 

1534485058_RouteDefinition-Plan.JPG.0e7ec329eab17ad07ebf2d293dfb1d1a.JPG

 

Extract of the panel showing the path of routes CD811 A(M) and CD811 A(C).  The green is shown as the route, with the yellow is the overlap

 

One route is a Main Class route (CD811 A(M)) and one is a Call-On Class route (CD811 A(C)), the difference between the two in the route calling process will become clear.

 

In an interlocking, each route has two states; ‘Normal’ and ‘Reverse’, these terms effectively mean ‘not set’ and ‘set’ respectively, but I’ll try to keep to the proper terminology.

 

The first thing for the route calling process to check when trying to get a route ‘reverse’ is that the signaller has chosen a legitimate route. For this, it checks that the correct entrance and exit buttons for the route have been pushed (the Push Button Interlocking described in Part 7 has already ensured that they have been pushed in the right order)

 

For both of the above routes the start point is CD811, whilst the end point is different. As I explained in Part 4, there are two exit buttons at CD813, one for the main route and one for the Call-On Route. Therefore, to begin to set the main route, the signaller must select the correct two buttons on the panel.

 

Simultaneously, the interlocking must also check 5 other sets of conditions:

 

  • Any points in the route are already set or free to move to the required position
  • All opposing routes to the one being set are ‘Normal’
  • There are no trains still traversing any of those opposing routes
  • Berth track of exit signal occupied (for Call-On routes only)
  • Huddersfield Controls Satisfied

 

‘Points Set or Free to Move’

 

The first bullet point is the one that checks that no conflicting routes are set. Many modellers thing that to prevent conflicting routes being set, the route being set must directly check all the conflicting routes to see if they are set. The reality is that the interlocking only checks whether the points are set or free to move to the required position, as any conflicting routes would require the same points in a different position, thus this means the conflicting routes are checked in-directly.

 

As part of the point set or free to move check, each point needs have two positions defined in the interlocking, these are ‘Normal’ and ‘Reverse’ (note how these terms crop up everywhere and can mean slightly different things). These two terms simply describe the position the points are in (i.e. set to the left or right) to make it easier to understand than ‘left hand switch closed’ or ‘right hand switch closed’ and are defined by the signaller designer of the Scheme plan. There’s no reason why they couldn’t be referred to as ‘Fred’ and ‘Bob’, but we like the ‘Normal and ‘Reverse’ terms.

 

The only place that shows how the points look in their ‘Normal’ and ‘Reverse’ Position is the scheme (or signalling) plan. It is only the ‘Normal’ position which is shown on the plan, with the continuous line of a point being the wheeled path when the point is in the ‘Normal’ Position. The ‘Normal’ position for the points at Collingwood Junction are highlighted as yellow lines below:

 

1371137908_NormalPath.JPG.ea293f57f51e12f754ad654c65e9d8cb.JPG

Scheme Plan extract highlighting the 'Normal' Positions of points at Collingwood Junction

 

From this, both CD811 A(M) and CD811 A(C) routes require 590 and 591 points in their ‘Normal’ position and 595 points in their ‘Reverse’ position.

 

If any of these are locked in the opposite position to that required, the route can’t be set.

 

‘Opposing Routes Normal’

 

This check ensures that no opposing routes are set to prevent head on conflicts

 

Opposing routes can be quite difficult to explain, so hopefully this will make sense. There are two types of opposing routes; directly opposing routes and in-directly opposing routes.

 

Directly opposing routes are ones that require the same points in the same position as the route trying to be set. For example, if there was a route from CD814 up onto the Down Netley:

 

1283095901_OpposingRoute-Example.JPG.511bf363ad1f2ce7a841f118b284591b.JPG

 

Example of a directly opposing route to CD811 A(M) / A(C).

 

This would be directly opposing route as it would require 590 & 591 points ‘Normal’ and 595 points ‘Reverse’, the same as for CD811 A(M) and CD811 A(C) Routes.

 

In-directly opposing routes are ones where not all points are required in the same position as the route trying to be set, but there is opportunity for it to become a directly opposing route as a train traverses a route. For example, if there was a route from CD812 onto the Down Netley via 591 points reverse:

 

2045333101_InDirectOpposingRoute-Example.JPG.e37ec151279c4e2d7932bb83f7c75f8e.JPG

 

Example of an indirectly opposing route to CD811 A(M) / A(C).

 

On the face of it, this route would not be directly opposing because to set the route it would require 591 points ‘Reverse’ and 595 points ‘Normal’, which is different to what CD811 A(M) and CD811 A(C) requires (591 points ‘Normal’ and 595 points ‘Reverse’). However, if the route from CD812 was set and a train had fully passed 591A points (ignoring the train detection for the moment, just imagine there was a track circuit joint where the black arrow is), it would be possible that the route can be cancelled and the 591 points would no longer be locked reverse (i.e. free to move to the ‘Normal’ position). At this point, the route from CD812 would become directly opposing as 595 would still be locked ‘Reverse’ and 591 is free to move ‘Normal’, which satisfies the conditions for CD811 A(M) or CD811 A(C) to set.

 

Therefore, the interlocking would have to check if the route from CD812 is set as part of the opposing routes normal checks.

 

Now, neither of the two example routes above exist on the layout, and in fact, there are no directly or indirectly opposing routes to CD811 A(M) or CD811 A(C).

 

However, you may have spotted that there are some routes which the interlocking has to check whether they are set or not. These are the routes from CD810 and CD812 up to CD822 (CD810 B(M) and CD812 B(M) respectively), which cross the diamond crossing side on to CD811 A(M) and CD811 A(C) routes.

 

1501766705_CD810CD812.jpg.1d6e3720d539ebb419ab544268bf138c.jpg

 

Other routes which have to be checked in the route controls of CD811 A(M) and CD811 A(C).

 

These are quite clearly conflicting routes, but they can’t necessarily be checked through point position. I say can’t necessarily be checked as it would be possible to check whether 594 points are set or free to move to ‘Normal’ (away from the diamond crossing), therefore checking whether CD810 A(M) and CD812 B(M) are set or not. However, this would mean that 594 points could be swung unnecessarily, which causes increased wear and maintenance. So, in my case, I’ve opted to check whether these routes are set or not.

 

‘Opposing routes free of trains’

 

Now, all routes are cancelled after a train has entered them, either manually by the signaller or by Train Operated Route Release (see part 12). This can lead to the problem that an opposing route is not set, thereby satisfying the above checks mentioned above and allowing the interlocking to set the requested route, but there is a train still in that route (possibly leading to a head-on collision).

 

To prevent this, not only must the interlocking check if an opposing route is set, but it also must check that there are no trains still traversing the opposing route after it has been cancelled.

 

Now, the obvious way of doing this is to check the occupancy of the track circuits within the route. The problem with this is that a track circuit failure would prevent a route being set, this means that neither points or the route would be locked automatically, meaning the interlocking would be done solely by the human signaller, not something we like doing.  Also, operation of a track circuit (and the way that the UK uses axle counters) does not differentiate the direction of a train, so to use just the occupation of the track circuit could mean that you couldn’t ‘overset’ a route. This is where a route can be set, despite there being another train (travelling in the same direction as the route being set) in the route, this removes the wait for a train to travel the whole route before a another is set. Therefore, most route calling is not dependent on track circuit occupation (see below for exceptions!).

 

So, instead, the interlocking checks the sectional route locking (see part 10), if the opposing sectional route locking is maintained, then that must mean a train is still traversing the opposing route, if the locking is not maintained, then the route is free of trains.

 

Berth Track of Exit Signal Occupied

 

This check is only made for Call-On routes and is one of two occasions where route setting is dependent on track circuit occupation.

 

By definition, a Call-On route is used to allow two trains to occupy the same section, meaning that if there is not another train in the route, there is no point to setting a Call-On Route. So, to prevent confusion on the part of the driver and to stop unnecessarily slow movements taking place, the interlocking checks if another train is in the route, by checking the occupation of track circuits, before allowing the Call-On route to set.

 

As trains rarely stop in the middle of the route before a Call-On move is used to bring another train in, it is the Berth Track Circuit (the track circuit immediately on approach to any signal) of the exit signal which is check for occupation.

 

1213445129_BerthTrack.jpg.8e64448786d70839400ae69765aa2d3e.jpg

 

Panel extract highlighting the Berth Track Circuit for CD813 Signal (XN), which is check for occupancy when setting CD811 A(C) route.

 

Huddersfield Controls

 

These checks are only made on Call-On Routes, Shunt routes which read up to a Main Aspect and Main Routes which have Call-On (or Shunt) routes up to the entrance signal. This is the other occasion where route setting is dependent on track circuit occupation

 

Huddersfield Controls are in response to an accident at Stratford, where a train running on a Call-On Route into an occupied platform (for platform sharing) collided with the rear end of the other train in the platform that was departing in the same direction. The driver of the train that was calling on had seen the proceed aspect of the platform starting signal and had applied power, not realising that the signal wasn’t for them and that there was a train in front.  So, to overcome this sort of problem, controls where added to the route controls for the routes mentioned above:

 

1 – If a Main route was set, then the route could not be set for any Call-On or Shunt routes up to the entrance signal of the Main route until the Main route was cancelled.

 

2 – If a Call-On route or Shunt Route up to a main aspect was set, then the route from that main aspect couldn’t be set until the Call-on or shunt route was cancelled, and it had been proved that any train traversing those routes were at a stand.

 

The first installation of these controls was at Huddersfield, hence the name.

 

In the case of CD811 A(C) route, control number 1 is applied; the interlocking simply checks that CD813 A(M) route is not set, if it is, then the Call-On route can not be set until CD813 A(M) is cancelled.

 

Just for completeness, if I was trying to set CD813 A(M), then not only would have to check if CD811 A(C) is not set, but it would also have check two other things:

 

1089275403_SectionalLockingTime.jpg.43aa6d19ea77635cb2bcb127a9a3f7b2.jpg

 

Panel Extract highlighting the different checks to be made for Huddersfield Controls

 

The reason for checking of track circuit occupation on approach to CD813 is like it is, is as follows. In this case, the Call-On route is being used to couple trains together in the Platform at Collingwood. If the occupation of the Berth Track of CD813 (XN Track) was checked, then the train already in the platform waiting would satisfy the controls rather than proving the second train to be at a stand. So, the next track back (XM) is checked as well to see if it is unoccupied for time, this proves that the second train has fully entered the platform and has been brought to a stand.

 

Next up, point calling, and as ever, if you have questions, please ask!

 

Simon

Edited by St. Simon
  • Like 2
Link to post
Share on other sites

Part 9: Point Calling

 

This is the sub-process that checks whether a set of points is free to move or locked in a position and then moves the points accordingly. Sorry, no pictures again!

 

As described previously, points can be called to a position by one of two methods; Automatically as part of the route setting operation (see part 8) or by the signaller using individual points switches (also known as keys). It is important to note that once enacted, neither method can be used to overrule the over, i.e. the route setting can’t call a set of points to the ‘Reverse’ position if the points switch has already called them to the ‘Normal’ position and vice versa.

 

There is a third method of calling the points, and that is to take control of the points at the lineside and physically wind the motor over. This would have the effect of overriding the commands by the route setting and signaller, but that isn’t needed on a model!

 

Within the interlocking, a set of points normally has two states:

 

  • Locked ‘Normal’
  • Locked ‘Reverse’

 

These two states do not mean that the points have moved to that position, nor do they mean that the points are physically locked. In this process ‘Locked’ means that the points have been requested to move to that position and that they can’t be commanded to the opposite position until that request has been removed. The reporting of the physical locking of the points is done through the detection controls within the aspect level of the interlocking.

 

The points are almost always locked in one position or the other in the interlocking, the only time they are unlocked is when they are commanded to move between position. The actual process of commanding a point between positions is quite complex. To command a point to move from its ‘Normal’ position to its reverse position, the interlocking must check that that the points can be unlocked from their ‘Locked ‘Normal’’ state and that it can apply the ‘Locked ‘Reverse’’ state.

 

Both checks initially have common things that must be satisfied:

 

1. All track circuits over the points are unoccupied (no train stood on the points)

2. There is no sectional route locking being maintained over the points in either direction (no train approaching)

3. All routes which require the points ‘Normal’ are not set (i.e. are Normal)

4. A route requiring the points ‘Reverse’ has been set or that the individual points switch is in the ‘Reverse’ Position

 

Then to unlock the points from their Locked ‘Normal’ state, the interlocking must check:

 

5. The points had previously been in their Locked ‘Normal’ state

6. The individual points switch had been in the centre position before the command was requested.

 

Then to change the state of the points to Locked ‘Reverse’, the interlocking must check

 

7. The points have been unlocked from their Locked ‘Normal’ State

 

Then, to command the points from the ‘Reverse’ position to the ‘Normal’ position, steps 1 & 2 are the same and you substitute ‘Normal’ for ‘Reverse’ in steps 3 – 7.

 

If then all routes are released and the point switch switched to the centre position, nothing will happen, the points will remain locked in their last position until a route is called, or a point switch switched. It is in this state that the points are ‘free to move’

 

There can also be Swinging Overlap Controls and Time of Operation controls added to the point calling sub-processes, but these are hugely complex, so I have left them off the layout, but I will explain the concepts in simple terms:

 

Swinging Overlap Controls – Where a set of points is used to ‘swing’ an overlap away from a conflict to enable a route to be set through the ‘preferred’ overlap, then the interlocking must also check that the new overlap is valid and safe.

 

Time of Operation Controls – Used within Swinging Overlaps, where the point is very close to the signal for which applies for. These controls prevent the point moving unless there is sufficient time to unlock, move and re-lock the point prior to a train getting to the signal (to prevent derailing a train if it SPADs and the point is moved to late).

 

Now that I've talked so much about 'Route Locking', I better explain it, in the next part....

 

Simon

  • Like 2
Link to post
Share on other sites

  • 2 weeks later...

Part 10: Route Locking

 

In the last few posts, I have mentioned ‘Sectional Route Locking’ a fair amount, so it is now time to explain it.

 

Sectional Route Locking is the thing that binds all the processes of the interlocking together, it is the most powerful ‘tool’ in the interlocking, without it you are either in a whole heap of pain or you end up having to make the same checks in each of the interlocking processes.

 

That makes it sound very complex, but the beauty of it is how elegantly simply it is.

 

The concept behind ‘Sectional Route Locking’ is to make sure that the route ahead of the train is locked and can’t be used until the train has fully passed through each section in the route, even if the route has been released.

 

Each track circuit has route locking applied to it individually. If a track circuit has signalled routes over it in either direction, then that track circuit has two separate route locking circuits. If the track circuit is also part of an overlap, it has a separate overlap route locking circuit (and this in turn can be have extra circuits if the track is an overlap for signals in different directions). For instance, ‘LB’ Track Circuit on Collingwood is an example of this:

 

740947894_LBTC.JPG.ab19171d39c28d07f160d1e915c973bb.JPG

Panel Extract showing LB Track Circuit

 

This track has routes over it in both directions and also forms an overlap for signals in both directions, so would have four circuits:

 

‘UP’ Route Locking

‘DOWN’ Route Locking

‘UP Overlap’ Route Locking

‘DOWN Overlap’ Route Locking

 

Each of these have different individual conditions that apply the route locking, although they are all applied in the same way.

 

The sectional route locking in a route is applied by ‘cascading’ the locking down the route in the direction of travel, with setting of the route triggering it at the start of the route.

 

1656590880_RouteDefinition-Panel.jpg.d946251dd9cceecf1f37cb0aa6242e3c.jpg

Extract of the panel showing the path of routes CD811 A(M). The green is shown as the route, with the yellow is the overlap

 

So, taking CD811 A(M) route again as an example, the route being set (up to the end of the part 8),  would apply the down direction sectional route locking for ‘XQ’ Track Circuit. The application of the down direction sectional route locking for ‘XQ’ Track Circuit would then cause the down direction sectional route locking for ‘XK’ Track Circuit to be applied. The application of the down direction sectional route locking for ‘XK’ Track Circuit would cause the down directional sectional route locking for ‘XL’ Track Circuit to be applied. This would carry on until the locking reached CD813 Signal, at this point the application of down direction route locking on ‘XN’ Track would cause the down direction overlap route locking to be applied to ‘XP’ track

 

I hope you followed that…

 

If you have (and have read the part 9), you might have noticed a problem with that that needs addressing. This is that at the same time the route locking is being applied, the points are being called into the correct position. Now, as part of the point calling, the interlocking checks that the route locking for the track circuit over the points has been applied. Therefore, the route locking being applied (which is almost instantaneously) will prevent the points actually being moved (as this would lock up the points before they’ve had chance to unlock). To stop this, the sectional route locking for a track circuit containing points is not applied until it is the points have been called.

 

So, in our case, the sectional route locking for ‘XL’ track is not applied until 591 & 595 points have been correctly called, which can be seen here:

 

417370842_RouteLockingApplying.jpg.caa1fe507fdec0937cf40429b7c201db.jpg

Panel Extract showing the route locking (shown by the white track sections) cascading through the route

 

Once all the sectional route locking has been applied, it cannot be removed until the route has been released and, if a train has entered the route, a train has passed fully through the track circuit. This is shown below, the route has been released (the post of CD811 is grey), but a train is still in the route and the route locking is preserved in front of it:

 

1448905453_RouteLockingRemoving.jpg.c2a2d94a4f4f75afcf3c9d811ec95d0b.jpg

Panel Extract showing how route locking (white track sections) is preserved in front of a train (red track sections) once the route has been released

 

 

The exception to the above ‘rule’ is when removing the overlap sectional route locking.

 

The concept of an overlap is to provide a clear area ahead of the exit signal that is proved free of trains in case of a train driver misjudges their braking and overshoots the exit signal when it is at red. Therefore, it is legitimate to say that if a train can be proved to be fully under control and will not overshoot a red signal when approaching it, then an overlap is no longer needed (indeed, this is the argument for not providing overlaps in many ‘in-cab’ signalling systems).

 

This argument can be used to remove the overlap route locking. The locking can be removed once it has been proved that the train has been brought to a stand on the berth track circuit. This is done by timing the occupancy of the berth track circuit, once the time has elapsed with the overlap track unoccupied and the berth track circuit occupied, then the locking can be removed.

 

The timing of track proves the train has been brought to a stand and is based on the length of the berth track assuming a certain braking rate (the concept being that if a train hasn’t occupied the overlap within the time, then the train must be at a stand, or very close to it).

 

Also, it would be worth noting that the overlap route locking would still be applied and removed in the same way even if a route has set over it. i.e, the overlap route locking for ‘XP’ track would still be applied and removed even if the route from CD813 was set.

 

So, that’s route locking, simple but very effective.

 

Next up, Aspect Controls.

 

Simon

Edited by St. Simon
  • Like 1
Link to post
Share on other sites

Part 11: Aspect Controls

 

The Aspect controls within an interlocking probably carries out the most individual checks and functions within any of the interlocking sub processes, however, they are all fairly basic.

 

Aspect controls perform two roles, the first is to make sure that it is safe for a signal to actually show a proceed aspect, and the second is to ensure that the signal displays the correct aspect in comparison with the signal ahead.

 

The first function carries out a series of checks before allowing the signal to show a proceed aspect.

 

Assuming that a route is actually set, the aspect controls first check that the exit signal is showing an aspect, if it isn’t, then the entrance signal will not pull ‘OFF’, as below:

 

2106279013_LampOut.jpg.5519e7e87a251b1d576fa0dd106befcf.jpg

 

Panel extract showing CD811 at Red when CD813 is not showing an aspect (shown by the grey circle).

 

If the exit signal is lit, the aspect controls check that either the exit signal is ‘OFF’ or that its TPWS equipment, if fitted, is transmitting. The idea behind this is that if the exit signal is ‘ON’, and then subsequently the lamp goes out after a train has passed the entrance signal, the TPWS will be capable of stopping the train (assuming the TPWS equipment on the train is working correctly). It must be remembered that the trackside TPWS equipment is not in itself fail safe (i.e. it won’t work correctly if there is no power), so it must be proven that it is working before a train can be allowed to approach it.

 

The next check is to ensure that the points have actually reached the position that they were asked to be in. If the points aren’t detected in the position that they are required to be in, then the signal won’t pull ‘OFF’, as below:

 

1494590943_PointDetection.jpg.cf70fb1ee094941949a579da1d357f8e.jpg

 

Panel Extract showing that CD811 won’t pull ‘OFF’ when 590 points are ‘out of correspondence’, i.e. not detected, shown by the blue blocks, which flash on the panel.

 

The final check for non-junction signals that the interlocking performs before showing a proceed aspect is that the route is clear of trains, by checking the occupancy of the track circuits. Once all track circuits, including any ‘foul’ track circuits, the signal can show a proceed aspect (apart from if it has a form of approach control, which I’ll tackle in a minute). In most cases, if any of these track circuits subsequently goes occupied, then the signal will go back to danger. However, there are situations where this is not the case.

 

These are situations are in the case of ‘Last Wheel Replacement’ and ‘Delayed Replacement’:

 

Last Wheel Replacement – This is where the signal doesn’t go back to danger until the entire train has passed the signal. This is used mostly on shunt signals (but can be used on Main Aspect Signals) where a train has to propel past the signal, as if the normal ‘First Wheel replacement’ is used, the driver would see the signal go back to danger in front of him, something they don’t take too kindly to! This control is provided by preventing the signal returning to danger until the berth track circuit is unoccupied.

 

585301789_LastWheel.jpg.2992355f692a9f32cd3f51ed1000ab9e.jpg

 

Panel extract showing the last wheel replacement o CD810 A(M) route

 

Delayed Replacement – This is very similar to Last Wheel Replacement, but the signal returns to danger when a train reaches a certain point in the route (usually the 2nd or 3rd track circuit) rather than once the whole train has passed the signal. This is usually used where a TPWS TSS loop is too close to the normal replacement joint, which would cause a train going past the signal to ‘trip’ itself. It is also used where a train has to stop beyond a platform starting signal to ensure the correct portion of the train is on the platform. The delayed replacement is used to allow the guard / platform staff to see the platform starter is ‘OFF’ despite the front of the train being ahead of it.

 

There is one more check that must be made for a signal which has route indicators, it must be ensured that the junction indicator has been lit correctly and that enough of it is visible to the driver so that the indication is clear and legible.

 

The aspect controls second role is to ensure the correct aspect sequence is displayed. This is all nice and simple, so I won’t go into detail about aspect sequences or junction signalling types, as you can read about it in my book, but I’ll outline the controls in the interlocking.

 

On Collingwood, it is only CD810, CD811, CD812 and CD821 which require aspect sequence controls, as these are three aspect signals. The controls for these are very simple, once the interlocking has determined the signal can clear, it then checks whether the signal ahead is off. If it is, then the signal can clear up to a green aspect, but if the exit signal is ‘on’, then the signal will only to a single yellow.

 

The aspect sequence controls also deal with Banner Repeaters. On Collingwood, CD810 has a splitting banner, with two heads, one for each of CD810s two routes. The aspect controls control which head shows ‘OFF’ depending on which route is set, the logic for each head being route set and signal ‘OFF’. Additionally, the Banner is ‘replaced’ when the ‘EB’ Track circuit is occupied, this isn’t technically needed unless there is a permissive move towards the banner, but I thought it would add extra interest.

 

Banners.jpeg.8fbceb75a6c03f87424edaa944ece889.jpeg

 

Panel extracts showing the three states of CD810BR.

 

Once the signal has returned to danger, the aspect controls then apply the ‘stick’ function. This is where the signal is prevented from clearing to a proceed aspect again once a train has passed through the route. The function is applied once both the berth ad first track circuit are occupied, however, it can be overridden if an Automatic Working facility is provided.

 

Until the stick function is applied, the route can’t be released…

 

Simon

Edited by St. Simon
  • Like 2
  • Informative/Useful 1
Link to post
Share on other sites

Part 12: Route Release

 

This is the point at which most model railway ‘interlockings’ stop at, but in reality, the safe release of a route is just as crucial as the safe setting of a route.

 

Originally, with mechanical interlockings, the release of the route was controlled by the signaller; once the signal was put back to danger at the discretion of the signaller (obviously based on the rules), there was nothing mechanically or electrically stopping the signaller immediately pulling point levers.

 

Unfortunately, signallers aren’t always fully reliable, so there have since been controls added to interlockings, including mechanical, to ensure that it is completely safe for a route to fully release before doing so.

 

Once the signaller requests a route release from the interlocking by cancelling the route (in my case a long click on the entrance signal button, but in reality it would be via a drop down menu on an IECC and by pulling the entrance button on an NX Panel), the signal will return to danger straight away, but the route won’t immediately release as it will be ‘approach locked’.

 

Approach Locking is where the route is locked until it is proven that an approaching train is fully at a stand before the route is fully released, unless one of two things is proven:

 

  • The train has entered the route;
  • No train was actually approaching the signal (known as Comprehensive Approach Locking)

 

Comprehensive Approach Locking (CAL) isn’t used on all routes, it is provided at the request of operations rather than as standard. CAL checks whether a train is actually approaching the route, it does this by checking whether the previous signal had actually showed a proceed aspect up to the signal being checked. CAL then checks all the track circuits between signal being checked and the previous signal to see whether they are occupied. Of course, a train may be somewhere between the previous signal and the signal being checked, but is actually being routed to a different signal, so some track circuits will have to be ‘conditioned’ out by the lie of points.

 

CD822.jpg.3ba70233963294d9f8c34e01e5d1f937.jpg

 

 

For instance, in the case of CD822 above, the Comprehensive Approach Locking must:

 

Always check if ‘LA’ and ‘XK’ Track Circuits are unoccupied

Check if ‘EE’ and ‘EC’ Track Circuits are unoccupied only if 594 points are ‘reverse’

Check if ‘WY’ Track Circuit are unoccupied only if 591 points are ‘normal’

If CD810 and CD812 signals have remained ‘ON’

 

If these checks are satisfied, then the approach locking can be removed.

 

If the signal was part of a four aspect sequence, then the track circuit checks would extend back to the next signal on approach, the first caution signal, but only if the signal between it and the signal being checked was ‘OFF’.

 

If the CAL checks aren’t satisfied, or is not provided, then the only other way approach locking can be removed immediately upon a release being requested is through proving that a train has entered the route. This is carried out by the sequential operation of the berth and first track circuits in the route, the sequential operation of the track circuits prevent a failure of a single track circuit causing a premature route release.

 

If it can’t be proved that a train has entered the route and that one may be approaching the signal, the only way to release the approach locking is to prove the train has come to stand. Once again, this is done by a timer, however, this is a simple timer rather than based on berth track occupied. The timer can be 30, 120, 180 or 240 seconds depending on the type of signal (plain, terminal starting signal, junction etc.).

 

There is one problem with this setup, and this is that it relies on the signaller manually cancelling the route. Now, if the signaller doesn’t notice that the route requires cancelling, there could be undue delay as without cancelling a route, points etc remain locked and other routes can’t be set.

 

To overcome this problem, Train Operated Route Release (TORR) can be fitted. This is basically where the progress of a train through the route is ‘tracked’ by the interlocking and once the interlocking is happy that a train has fully entered the route, then the interlocking itself can request a route release. This is done by sequential operation of the second and third track circuits.

 

Once the approach locking has been removed, the routes are released, which starts the release of the section route locking behind a train, which in turn release the locking of points and allows other routes to be set.

 

That effectively covers how the interlocking that an IECC controls works in terms of controlling routes and signals. Collingwood has an extra interlocking component, the level crossing.

 

Simon

Edited by St. Simon
  • Like 2
Link to post
Share on other sites

  • 2 weeks later...

Part 13: Level Crossing

 

On the layout, I’ve included a Level Crossing on the plan to add some interest and audience interaction to the layout and this is controlled by the interlocking and IECC.

 

The Level Crossing type is a Manually Controlled Barrier – On Call (MCB-OC) Crossing. These are fairly uncommon and are used where the rail traffic over the crossing is far in excess of the road traffic that uses it, meaning that it operates very differently to other types of crossing.

 

1992104240_LevelCrossing.jpg.2b4d84a2d568d7ca842ce4f152a5e6f5.jpg

 

Panel Extract showing the panel controls and indications for Collingwood MCB-OC.

 

Normally, the crossing barriers are closed to road traffic rather than open to road traffic as per all other level crossings. If a road user wants to cross the crossing, they push a button provided next to the crossing. The initiates a request to the signaller to raise the barriers, at which point the signaller can request the barriers to be raised.

 

The interlock must check that there any routes over the crossing (in this case CD813 A(M) and CD816 A(M)) are normal, the route sectional locking for the track circuits up to and over the crossing (‘XP’ and ‘EZ’) is not applied and that those track circuits are unoccupied. Once these checks have been complete the barriers can open.

 

The barriers will remain up until the signaller lowers them, either manually using a ‘LOWER’ button on the panel or by setting a route over the crossing. If neither of these happen within two minutes of the barriers being raised, then the signaller is reminded to lower the barriers by an audible warning.

As the barriers are lowering, the Road Traffic Light ‘Wig Wags’ are illuminated and run through the standard light sequence, once the barriers down, the lights extinguish, this is the only time the road lights are illuminated. It should be noted that Road Lights are only used with MCB-OCs by exception technically, but it does seem that every one that has been installed has been provided with them.

 

Before a signal that reads over the crossing can be cleared, the signaller must confirm that the crossing is clear of people and cars. This would be done via a CCTV camera on the real thing, but this isn’t required on the model. Once the signaller has confirmed the crossing is clear, they tell the interlocking via the ‘Crossing Clear’ button. To avoid delays in clearing signals, an audible reminder is given to the signaller to push the button once the barriers are lowered.

 

On the model, I have only coded the initiation of the road light and barrier sequences rather than the whole thing, I plan to use commercial units to do this bit (to save outputs), although I am looking for a unit that provides prototypical road light sequences and allows for both barrier down and barrier up commands separately.

 

This completes the run-down of all the interlocking functions of Collingwood IECC, but there are other parts that make it up, which I will go into further detail:

  • Indications and Alarms
  • Train Describers
  • Automatic Route Setting.

Simon

  • Like 3
Link to post
Share on other sites

Part 14: Misc Indications & Alarms

 

There are many additional indications and alarms that can be added to panels to provide the signaller with additional information on the state of the railway. Some of these are applicable to all panels and some are only applicable to IECCs (or VDU based control systems).

 

‘Slot’

 

The first I want to show may actually be more of an interlocking function, but I’ll let you figure that out.

 

Slot.jpeg.a9e385533d1c8281887978a834a02129.jpeg

 

Panel Extract highlighting the Fiddle Yard Slot indications for CD814 and CD822.

 

As I have a single line leading into one of the fiddle yards on the layout, I have to make sure that that there isn’t a train coming out of the fiddle yard as I try and send one in. In reality this would be done through the opposing locking mentioned in part 8, but I don’t have interlocking in the fiddle yards (it is only a cassette fiddle yard). So instead I’m going to have a direction switch in the fiddle yard to indicate to allow the fiddle yard operator to control the comings and goings.

 

This direction switch will have two positions, one for accepting trains into the fiddle yard and one for letting trains out of the fiddle yard. The switch being in the first position is indicated on the panel as a Slot for CD814 and CD822 (it’s not actually a slot really, but I thought it was a nice thing to see), the switch is also cut into the route calling logic so that a route can’t be set unless the fiddle yard accepts it.

 

Direction Arrows

 

Talking of directions, the next indication on the panel is the line direction arrows.

 

Where a line has signalled routes in either direction, such as the Down Portsmouth between CD821 and CD814 below, direction indication arrows are illuminated to indicate to the signaller in which direction the route over the line is set:

 

51668246_DirectionArrows.jpg.0eab4359b0a43207ed1179010840c5a1.jpg

 

Panel extracts showing the direction arrows for the Down Portsmouth Line illuminated when a route is set in either direction.

 

TRTS

 

Continuing towards Portsmouth, the next set of indications are the ‘Train Ready to Start’, or TRTS, indications:

 

TRTS.jpg.4c0278e4f94eb91c3481681280993b18.jpg

 

Panel extract showing the TRTS Plunger indications, in reality they flash to draw the signallers attention to them.

 

These are plungers which are provided to tell the signaller that, funnily enough, a train is ready to start. These are primarily to prevent a route being set before a train is ready so that other routes are not locked out for longer than necessary. There are activated by a momentary plunger, and then the indication flashes until the signal a proceed aspect. There is also an audible alarm that sounds momentarily.

 

If you’ve read the symbol standards, you may have noticed that in reality TRTS indications are just a white circle, however, I’ve chosen light blue with the letters TRTS as it provides another colour to make the panel ‘prettier’ and gives the audience slightly more information on what is happening.

 

Ground Frame Indications

 

You may have spotted the indications for the Ground Frame (I’ve actually changed it to a Ground Switch Panel, but I haven’t updated the panel yet!) on the panel:

 

1769751976_GroundFrame.jpeg.2027be398089a4d32fd405897acabc71.jpeg

 

Panel extract highlighting the indications for the yard acceptance switch (1) and whether the GSP is released or not (2).

 

Indication number ‘1’ is for the acceptance switch on the Ground Switch Panel, with a solid green circle indicating that the switch is in ‘accept’, that means the yard shunter is ready to accept a train into the yard. Like the ‘Slot’ earlier in the post, this is cut into the aspect controls for the position light aspect on CD814.

 

The indications labelled as ‘2’ are the indications for whether the Ground Switch Panel is ‘Normal’ (i.e. 590 points are free for a route to be set into or out of the yard) or ‘Released’ (i.e. the yard is being signalled independently by the shunter using the Ground Switch Panel.

 

Restoration Reminders

 

Whilst we are looking at 590 points, it would be a good time to talk about Restoration Reminders.

 

Restoration Reminders tend to be employed where points are used to provide trapping protection. They are used to remind the signallers to restore points to their normal position so that the trapping protection isn’t lost for a significant amount of time. You can get points that self-restore to normal behind a train, however the logic and safety checks are very complex, so a reminder is easier and prevents points constantly swinging.

 

There is no standard on what restoration reminders look like on an IECC, so I’ve added some text in blue text beneath the points in question and an added an audible alarm. The reminder is shown when the points are reverse and no route is set over them in either direction:

 

675068648_RestorationReminder.jpeg.d5744e22a79d6833b9b8f5f7e94c9362.jpeg

 

Panel extract showing the Restoration Reminder active for 590 points which provide trapping protection for the yard.

 

SPAD Alarms

 

These alarms are almost exclusively provided on IECC or VDU controls systems. They are technically part of the Automatic Route Setting Sub-System, but they are more suited to be talked about here.

 

In Mechanical or Route Setting Panel boxes, the only way that a SPAD is normally detected is through the observation of it by the signaller. Some panels have SPAD indicators provided, but these require lots of additional circuitry in the interlocking and additional equipment on the track.

 

For VDU based boxes, the control system can monitor the operation of track circuits and can detect when a train passes a signal at danger without changes to the interlocking nor additional equipment. Not only does the system alert the signaller to a SPAD having taken place, it will also tell the signaller which train has passed which signal at danger:

 

624792924_SPADAlarm.jpeg.51c07a9bc4e304460c4a23803c0a7509.jpeg

 

Panel extract showing a SPAD of CD810. Note that the red boxes are not there on the panel, they are only added to this image to highlight the indications.

 

There is also an audible alarm which sounds to make sure the signaller is fully aware of it. There is some debate as to what the alarm sounds like in reality, the common consensus is that it is one of the major alert sounds from Star Trek, but I have used an ATP in-cab failure alarm sound.

 

A SPAD will cause cause the ‘Signal Group Replacement Control’ to operate which puts all signals back to danger (the signaller can also activate this control manually).

 

The alarm is activated when the berth and first track circuits in a route are both occupied after the berth track occupied and the first track clear, but only if the signal has remained ‘ON’ the whole time and that the operation of the track circuits are not part of a legitimately signalled moved.

 

As an aside, you’ll have noticed that Collingwood is provided with SPAD Indicators, these are active when a SPAD has taken place of CD810, CD811 or CD812. There is an additional bit of logic whereby the SPAD indicator can be ‘inhibited’ if a train needs to be talked past one of these signals. The train driver pushes a inhibit button (in reality at the signal being passed, but on the model there will be button mounted on the rear of the layout), and this inhibits the SPAD indicators at the lineside and on the panel for 1 minute.

 

Other IECC Indications and Alarms

 

There are other indications that are provided on IECC as part of the ARS Sub-System, these relate to alarms which alter the signaller to usual situations regarding the operation of track circuits, such as failing occupied when clear or clear when occupied or when track circuits don’t operate in the correct sequence. However, I haven’t added this in to my IECC as it would be a lot of logic!

 

Simon

  • Informative/Useful 1
Link to post
Share on other sites

Part 15: Train Describers

 

I’ve talked about mis-routing of trains a couple of times in this thread, but of course, how can you mis-route a train without knowing what train is coming? Well, that’s where the train describer comes in.

 

History

 

Train Describers do what they say on the tin, they describe the trains under the signallers control. Despite appearing to most to be a new invention, they are actually quite an old concept. Technically, there have been ‘Train Describers’ since the invention of block working, as the Train Register and Block Bells perform a train description function. However, with the increase of trains and routes along which they could run, keeping track of trains through Bell Codes and the Train Register became harder and harder, so a system was invented which would evolve into what most signaller would say are true ‘Train Describers’.

 

The first visual train describer was the Walker instrument, which moved an arrow around a clock face like display to point at a train description as set by a similar ‘transmitting’ instrument at the sending end. The Bluebell Railway has one at Sheffield Park for communicating between the Shed and Signal Box, and can be seen in this video (1:28:00 to 1:28:28):

 

https://www.youtube.com/watch?v=KEbpCwUAY3Q 

 

This instrument only served as a visual reminder of the Bell Codes & Train Register and could only show one train at a time and could only show a finite range of pre-determined train descriptions.

 

These restrictions were partially removed when the Magazine type train describer was developed. This was an instrument which still listed a finite range of pre-determined descriptions (such as Class 1 Main, Class 2 Branch, Class 3 etc.), however it was capable of showing multiple trains at once and order in which they will arrive at the box and able to update itself once the first the train had passed the signal box (although I’m not sure whether the update was triggered by the signaller or automatically).

 

These methods of Train Description (or very similar), combined with the trains themselves display their description through lamp codes and reporting numbers, were all that was available until the introduction of the Alpha Numeric Headcodes by British Railways in the 1960’s.

 

Previously, the Train Descriptions were provided in words, which were practically useless if you wanted to move the Train Description in sync with a train in real time (not only because of the difficulty in simply moving words around, but also the difficulty in make the words large enough to read without make them too large to use on a panel). The introduction of the short 4-character headcodes made this a possibility, partially because they could be made small enough to use on a panel but large enough to read from a distance but also, using a small range of choice for each character, you could have over 20,000 different combinations (in theory).

 

These Alpha-numeric train describer displays have gone through various technical evolutions, including mechanical ‘stencils’, filament lamp matrix’s, Cathode Ray Tube displays, LCD displays, but most nowadays are LED segment or spot displays (for physical panels) or VDU displays (for IECCs and Mechanical Boxes) and all have a near identical appearance.

 

There are some pictures posted by ‘Marsh Lane’ in my Collingwood layout thread here: 

 

Headcodes

 

I’m only going to explain the basics of headcodes, as I’ll explain the Collingwood specific headcodes in the ARS section later on.

 

A modern 4-character headcode comprises three segments:

 

Headcodes.png.2e6ad85c0618a55d06d3162ee94529f7.png

 

The classes of train have changed fairly significantly throughout the ages, but the current list is here:

 

1215843615_TrainClasses.jpg.7f55c6782b0b7ce9ffc14a857d376fb4.jpg

 

The above is rather generic across the network, so the difference between an Express & Ordinary Passenger Train varies between NR routes and regions. Also, Class 9 trains are increasing being used, for instance most Pendolino workings under the ‘VHF’ service pattern are Class 9’s, as are most Overground Trains on the Southern Region and the current Crossrail services on the Western are Class 9’s.

 

Like train classes, the destination character has changed significantly, they no longer solely mean the destination regions (as most explanations of headcodes give), the meaning of letters are now specified as part of the working timetable books, with the regional meanings of letters only applying to inter-regional trains (i.e. cross country passenger and freight services). There are a couple of universal letters that apply everywhere, with ‘X’ trains being an out of gauge, exceptional load or royal trains, whilst ‘Z’ trains being excursion, specials, military or royal trains

 

The individual service number isn’t necessary unique to one train per day. The basic rule is that the whole headcode has to be unique within in the a.m. or p.m. 12-hour period and unique within at least the workstation area for that 12-hour period. So, in theory there could be two different services leaving Paddington, say, with the same 1A01 headcode within 24 hours, but one will have to be between 00:00 and 12:00 and other departing between 12:00 and 00:00.

 

Train Description Stepping

 

Each signal displayed on a panel or IECC screen has what is termed a train describer ‘berth’ (again, notice multiple uses for the same word!). Additional berths can be provided within platforms, yards and at the fringes of panels to provide additional information (such as the headcodes of multiple trains within a terminus station or yard, or which trains are approaching the signallers control area). There are also ‘invisible’ berths that are used to stored headcodes, but don’t need to be seen by the signaller.

 

The system mostly works automatically without input from the signaller, but the signaller does have the option to ‘interpose’ any 4-letter code into any visible berth when they see fit. It is almost a tradition that a goodbye message is put into the train describer when panels or signal boxes close, but more humorous messages can be seen from time to time.

 

At the beginning of a train’s journey, its headcode is entered into the berth of the signal at which it’s standing. This is mostly done manually by the signaller but can also be done automatically when the Train Driver enters their headcode and starting signal into the GSM-R radio (if there is a connection between the GSM-R terminal and Train Describer sub-system at the control centre). It is also possible for a route being set or a TRTS plunger being pushed to trigger something called ‘Automatic Code Insertion’ (ACI), whereby when the Train Describer sub-system looks up the timetable (which is uploaded to it every day) to determine the headcode to input based on the time of day.

 

From there on, as a train travels along a route, the headcode is ‘stepped’ from berth to berth along the set route automatically. This is done when the train occupies the first track circuit in a route after the signal showed a proceed aspect, the destination berth being determined by the route from the signal. The TD doesn’t ‘step’ unless the signal has cleared first.

 

959510605_DescriberStep.jpg.2db8be8d012ee0059c63dceaada246a2.jpg

 

Panel Extract showing the Train Description ‘Stepping’ from CD810 to CD808 as the train passes CD810.

 

Where a train turns back within its journey, for instance the Cross-Country trains that reverse at Reading, the headcode can be ‘rippled’ between signals. This can be done by the ‘turn back route’ being set, or a TRTS plunger being, just like the ACI mentioned above:

 

1310776617_TRTSStep.jpg.6a6052cdf649ac5f1826e60d8ace7072.jpg

 

Panel Extract showing the a Train Description ‘Rippling’ between the Bay TD Berth and the CD812 TD Berth when the TRTS Plunger is pushed.

 

Train Describers on Collingwood IECC

 

For Collingwood, I have used the ‘Memory Variable’ function within JMRI, with each signal having a berth, I also have four ‘Last Sent’ berths for each fiddle yard and the aggregate terminal, as well as three ‘invisible’ berths for each fiddle yard so that I can stack an outgoing train without it showing on the main panel:

 

CD_Train_Describers.jpg.a0078dd220c11b036379ec696b6f2acf.jpg

 

Panel Extract showing all the visible Train Description berths with ‘-T3-‘ (for an engineering possession) interposed into them.

 

The advantage of using memories for the TD in JMRI is that they become invisible when there is no value in them. On a physical panel, the TD berth for signal is just a black rectangle when there is no headcode to display, whereas on an IECC, the berth disappears when there is no headcode, so you can see the track beneath.

 

Below is a basic diagram of how the headcodes step from berth to berth on Collingwood:

 

1376230435_TDSteos.jpg.44e69f782a2155a202ebf98909cdc12a.jpg

 

Block diagram showing how headcodes are stepped around the panel.

 

I also have the ability to ‘interpose’ any code into any of the berths via the train describer / fault panel:

 

974914828_TrainDescriberPanel.jpg.b3ff272bc7db5cad00f67ee1a939c992.jpg

 

Collingwood Train Describer Panel.

 

Simon

Link to post
Share on other sites

Part 16: Automatic Route Setting

 

The final component of Collingwood IECC is the Automatic Route Setting System, and probably the bit I have found the most interesting to create.

 

Despite what some signallers will say to you, Automatic Route Setting (ARS) is not a system to replace the signaller, in fact it is illegal for a signaller to leave a workstation & leave the ARS in charge. ARS is, amongst other things, actually a system to reduce a signaller’s workload by being used to set routes for the mundane moves and services to leave the signaller to concentrate on other tasks (such as dealing with faults, line blocks, telephones etc.). ARS has four basic core functions to it:

 

1.       Automatic setting of routes as required by the timetable and to prevent cautionary aspects being presented to a train unnecessarily

2.       Automatic detection and resolution of current and future train routing conflicts

3.       Automatic prioritisation of services to minimise train delay

4.       Selection of pre-defined contingency plans in the event of unplanned disruption.

 

ARS was originally a BR research invention during the 1980s, it was first installed and interfaced with the NX Panel and RRI at Three Bridges Area Signalling Centre (although only used occasionally before being disconnected).

 

IMG_0945.JPG.af9c8f420b80513d475f3b4c3da48642.JPG

 

 

The original ARS equipment that has been disconnected at Three Bridges ASC

 

However, the system has been extremely successfully when used with SSI and CBI interlockings and is probably the most advanced system of its kind in the world.

 

The whole system is based around the working timetable, obviously this contains all the trains for 24 hours, their headcodes, the timing locations through which they pass and any operations they carry out (such as station stops, reversals, run rounds etc.). This timetable is stored within the ARS (it is updated every day for the next 24 hours), and is referred back to by the system when in operation.

 

ARS is not used for all trains, there are certain trains that are always route manually (these are site specific rather than a general type of train), equally ARS is not used for all signalled routes, again ARS exempted routes are site specific, but are tend to be routes that require the signaller to intervene (such as where a route requires verbal acceptance into a yard or depot).

 

It is important to note that I have fixed headcodes on Collingwood for each service patterns rather than for each individual service, just to make the logic and programming easier. I.e. All Waterloo – Portsmouth workings are ‘1T17’ and all Portsmouth to Southampton workings are ‘2E25’ etc. All the headcodes and workings I’m using on the layout are over in the layout thread: 

 

 

I will only explain the functions of ARS that I have coded, these being the first and third core functions (even then, not comprehensively).

 

Automatic prioritisation of services to minimise train delay

 

I’m going to explain this function and how I’ve implemented on Collingwood first, as how I’ve implemented underpins the setting of routes and headcodes.

 

In reality, the way that ARS chooses between trains when there’s a conflict when setting routes is decided on a number of factors (in no particular order, and not limited to):

 

·         The delay to an individual train

·         The delay that an individual train will cause to other trains

·         Train Class

·         Business Priorities

·         Maximum Waiting Times

·         Passenger Flows

 

From these, the train regulation algorithms within ARS work out which train gets priority. It is very complex and is site specific, so that the ARS in TVSC at Didcot will prioritise trains in a different way than the ARS at York IECC etc.

 

ARS uses the 4 character alpha-numeric headcode to evaluate priority, whereas JMRI can’t evaluate a memory value that includes a letter, so I have to use a different method.

 

Instead, I have added invisible memories for each train describer berth where, what I call, ‘Weighting Factor’ numeric values that can be used in JMRI Logix are stored. Each Headcode has a unique 4 digit ‘Weighting Factor’ with the ‘1000s’ being based on train class, the ‘100s’ being based on route that it will take through the layout, the ‘10s’ being the operator of the service and the ‘1s’ being just an individual number:

 

 

1657590854_WeightingFactors.JPG.d5319b66576f809f061ab6649bfc03c8.JPG

 

Extract of my ARS spreadsheet, at the top are a route key and TD berths to be checked for conflicts, whilst at the bottom are the ‘Weighting Factor’ modifiers

 

So that the ‘Weighting Factor’ of a train for Collingwood is calculated thus:

 

                Weighting Factor = Train Class Weighting Modifier + Route Weighting Modifier + Operator Weighting Modifier + Individual Identifier.

 

It took a little while to figure out the ‘system’ of calculating the weighting factor so that it could be used efficiently as well as allowing a new train to be added without re-programming everything, whilst allow unique values to every train.

 

You’ll notice that each route and operator has a unique weighting modifier, but the train class have common weighting modifier, so that a Class 3 and a Class 5 train are given the same priority (based solely on their train class), as does a Class 7 and a Class 8 train.

 

When the ARS looks to set a route, it will check if any ‘conflicting’ berths to that route have a higher ‘Weighting Factor’ and if it doesn’t, then the route can be set, otherwise it will wait until a time when the route requested has the highest ‘Weighting Factor’.

 

The ‘Weighting Factor’ is stepped between berths exactly like the visible headcodes in both ARS and manual route setting modes, and is also used to trigger the station announcements.

 

Automatic setting of routes as required by the timetable

 

On the real railway, when a headcode is entered into the train describer berth at the trains starting point, ARS looks up the headcode in its timetable and determines the routes that need to be set by analysing the timing locations. The system will then set these routes at the time required by the timetable to ensure that the train is presented with clear aspects as much as possible.

 

On Collingwood, it is slightly different. To ensure that I can keep operational flexibility on the model, I don’t want to operate with a sequence or timetable (I have done before on layouts and it doesn’t work 100% all the time!), so I have to have another ‘system’ for looking up headcodes.

 

I’m going to use RFID Tags attached to the stock, with RFID readers mounted on the layout ‘entry’ tracks from each of the fiddle yards. I then plan to pass the RFID Tag I.D. number presented from the reader to a Memory that is useable in Logix (this will require a simple script to be written, so if you know about this sort of thing, please PM me!).

 

The problem I then have is that multiple trains can be running under the same headcode or that a single train can run under several headcodes. To resolve that I have first written up a spreadsheet where I’ve mapped all the stock against all the possible headcodes based on which Fiddle Yard they are coming from:

 

671782796_ARSMatrix.JPG.e5f1da4735eacec358b6b03a403d1f59.JPG

 

 

Extract of my ARS spreadsheet showing headcodes and their ‘Weighting Factor’ mapped against the rolling stock

 

I was initially intending to write a script so that I could use the excel spreadsheet to input the appropriate headcode, but it is all too complex for me, so I’ve hard coded all the combinations into the logic. Where a single train has multiple headcodes associated with it, the logic only inputs the first headcode if it isn’t already in use on the layout (this is through comparing the unique ‘Weighting Factor’ to the others on the layout), if it is, then it picks the second headcode, if that isn’t in use, then it picks the third headcode.

 

Once a Headcode and ‘Weighting Factor’ is selected, this is inputted into the relevant memories. The ARS will then use the ‘Weighting Factor’ value to select the routes to be set, based on the 2nd digit. For instance, if a ‘Weighting Factor’ in the x6xx range is inputted, the ARS will look to set the route from Southampton all the way through the layout to Portsmouth.

 

Once the ARS knows which routes to set and has determined that a train has priority other others, it can look at setting the routes. However, it will only do this if the routes is free and that the signal will clear to a green aspect, this is because one of the benefits of ARS is that using it means that routes are set early enough to give the best aspects possible (i.e. green aspects). Therefore if when it is time for the route to be set the signal will only clear to a single yellow, then the benefit of setting it automatically is lost.

 

To check that the route is free and the signal will show green, the ARS sub-system will look up the state of the point locking, and track circuits independently of the interlocking (although it is a non-safety critical check and therefore can’t be used to ‘back up’ the interlocking).

 

To automatically set the route in JMRI, I have basically coded an automatic simulation of me pressing the entrance and exit triangles using timer sensor actions, if you watch the panel in ARS mode, you’ll actually see the pressing of the triangles as ARS sets the route.

 

Other ARS features on Collingwood

 

On a VDU system, the distinction between a train being routed using ARS and a train being routed by the signaller is display by different coloured text in the train describer, with blue headcodes being manually routed trains and pink headcodes being trains routed using ARS:

 

206730794_TDColours.jpg.b9897cd070f6021caa20ec752af86b1f.jpg

Panel Extract showing the difference between a manually routed and ARS routed train on the Train Describer,

 

 

In reality, there are also Yellow headcodes used for un-timetabled trains or those running on a contingency plan, but as I don’t have a timetable or contingency plan, I haven’t added the yellow headcodes.

 

Another feature in ARS you may have spotted in previous posts is the ARS ‘Sub Areas’. ‘Sub Areas’ divide the signallers control area up into areas whereby the signaller can stop or allow ARS to route trains through. This means that you don’t have to turn off ARS for a whole control area if you wish to only turn it off for a small area of railway (for instance when there’s a fault). Signalled routes can be in more than one ARS ‘Sub Area’, and the ARS must ensure that all ’Sub Areas’ through which a route passes are turned on before routing a train.

 

 

2015763019_SubAreas.jpg.9c15e6dd747256bb4b48f73917376327.jpg

Panel Extract showing both ARS 'Sub Areas' enabled.

 

On Collingwood, I have two ‘Sub Areas’, called the Up and Down Direction ‘Sub Areas’, the split is long the middle of the layout, as seen by the dotted / dashed line in the scheme plan here:

 

Scheme Plan v2.pdf

 

Therefore, when setting the route from CD811 to CD813, the ARS checks that both ‘Sub Areas’ are active when setting the route.

 

Also, when there is a SPAD, the ‘Sub Area’ within which the SPAD has taken place is automatically disabled and has to be re-enabled by the signaller once the SPAD has cleared:

 

264995660_ARSSPAD.jpg.2e1c160143007731a108f2bfd1545f89.jpg

 

 

Panel extract showing that the Up Direction ‘Sub Area’ is disabled when a SPAD of CD810 takes place.

 

That’s pretty much everything on the IECC that I want to cover, once the layout is built and working I will do a video showing everything working on the panel and on the layout, just prove it does actually work (it’s hard for me to video it just on the screen).

 

I will also update this thread with any new features I add on or improvements I make to it.

 

If you have any questions about any of the topics in this thread, please do I ask and I’ll answer them to the best of my ability.

 

Simon

 

Edited by St. Simon
  • Like 3
Link to post
Share on other sites

13 hours ago, St. Simon said:

ARS was originally a BR research invention during the 1980s, it was first installed and interfaced with the NX Panel and RRI at Three Bridges Area Signalling Centre (although only used occasionally before being disconnected).

However, the system has been extremely successfully when used with SSI and CBI interlockings and is probably the most advanced system of its kind in the world.

 

LU was using a form of ARS (the “Programme Machine”) as far back as the late 1950s on the Northern Line, interfacing with power lever frames. The timetable information was held on rolls of plastic film with holes punched in it (or not) to represent ones and zeros. The Programme Machines have now all been superseded by more modern technology :)

  • Agree 2
Link to post
Share on other sites

5 hours ago, Titanius Anglesmith said:

 

LU was using a form of ARS (the “Programme Machine”) as far back as the late 1950s on the Northern Line, interfacing with power lever frames. The timetable information was held on rolls of plastic film with holes punched in it (or not) to represent ones and zeros. The Programme Machines have now all been superseded by more modern technology :)

 

Yes, LU probably invented ARS as a concept first, but ARS as a name of a specific product was first coined by BR (I think, I took the words out of an IRSE text box).

 

I have seen the programming machines that LU have, and they are an amazing bit of kit, given the date of their introduction.

 

Simon

  • Like 1
Link to post
Share on other sites

  • RMweb Gold

BTW Simon I think you'll find that BR experiments with ARS started long before BR Research started sticking its nose into signalling.  Years ago there was an experimental installation. reported by 'Modern Railways' much earlier at Reading involving Platforms 4A &4B (and possibly even pre-dating the addition of 4B?)

  • Informative/Useful 1
Link to post
Share on other sites

The comment about the advanced nature of BRR's ARS is probably still true. Back in 1998 when the specifications for the Taiwan High Speed Rail system were being prepared, the team included a requirement for ARS functionality within the signalling system. When reviewed by a very competent Frenchman who had been in charge of the French side of the CTRL link, he observed that such functionality was indeed desirable but didn't believe it was yet available. He was very surprised when told by the UK signal engineers working on the project that it had been a standard feature in IECC installations for quite some time.

 

The Japanese, who won the contract, couldn't get their heads around the requirement at all.

 

In the mid 90's BRR's signal section was developing the Control Centre of the Future, the functionality of which is only now becoming part of NR's 'Digital Railway' aspirations with ARS broadened considerably in scope. Personally I dislike the digital railway description. as Oldudders commented once, a semaphore signalled railway is truly digital: the peg is 'on' or 'off'. The advantage of modern CBTC systems is that control can be more or less analogue with updated movement authorities sent out every other second or so. A degree of precision hitherto unobtainable.

  • Like 1
  • Agree 1
Link to post
Share on other sites

  • 1 year later...
On 04/11/2021 at 23:47, jamespetts said:

This is a fascinating topic and I have just spent a considerable time reading all the posts. I shall very much look forward to the video. Sadly, it seems as though your book has sold out.


Hi,

 

Thanks, there’s some changes I’m thinking about making to add in some more stuff, such as some Axle Counter sections reset / restore, plus some modern control changes I might play around with, possibly on a separate panel (I really want to do proper ETCS!) If there is anything anyone would like me to cover, please ask!

 

Yes, the layout is getting closer to completion, so I hope a video will happen sometime in the new year.

 

I don’t believe the book has sold out at at Crowood directly: https://www.crowood.com/products/colour-light-signalling-for-model-railways-by-simon-paley?_pos=1&_psq=colour light&_ss=e&_v=1.0

 

However I have noticed it is not in stock elsewhere, I suspect this is because retailers have sold their initial stock and don’t have the sales to support getting more stock, you might be able to order it special for you from a retailer.

 

Simon

  • Like 2
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...