SimSig:Disruption Management
| SimSig Sessions | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| On Our Lines plays SimSig | |||||||||
 | |||||||||
| Upcoming Sessions | |||||||||
| |||||||||
Just like the real railway things do not always go a planned during our SimSig Sessions with various faults, failures and other disruptive incidents occurring during sessions. As our regular Saturday sessions are intended to provide a level of emersion and realism to operations that is accessible to new and experienced SimSig users alike we have created a disruption management and messaging system that is based of Network Rail and Train Operating Company (TOC) practice. This page is intended to be a guide to both those carrying our Signaller and Controller roles as to how we manage disruption on our SimSig sessions as well as to provide a small insight to those interested in how the railways manage disruption. This system has been drawn up by a couple of our discord members who have worked on the railway and is not an exact carbon copy of how things are done on the mainline railway but has been adapted to our needs.
Service Control
SimSig allows for the host of a simulation to act as a Service Controller, enabling them to edit or create timetables and even tell trains to run to another timetable mid game. During our Saturday sessions we aim to have dedicated controllers who will not be signalling trains and will instead respond to disruptive incidents and draw up a service recovery plan, during ad hoc sessions depending on the number of players there may be a dedicated service controller or the host of the simulation may simply carry out this role alongside signalling trains.
Due to the way that SimSig works the host of a simulation is the only one able to make edits to the running scheduals of train services however on Saturday sessions depending on numbers there may be assistant controllers who will watch out of delays and assist the principle controllers in deciding what action should be taken. Controllers like hosts are for formal games are usually appointed by invitation based on their contributions to previous simulations and after demonstrating a suitable level of ability, those intrested in being considered for helping out with control should add their names to the Community section of the SimSig Sessions page.
Incident Levels
Most TOCs use 4 incident levels for grading incidents on the railway to help staff understand the severity of the event in question. The trigger points for incidents vary from TOC to TOC however below is a basic explanation based on a suburban TOCs operating practice. The level of an incident is determined by service control staff and is communicated out to all impacted staff via verbal and written messages.
All levels above Code Green can be applied on a network wide or line of route basis. For example, a Code Red could be declared on all lines in the West Midlands due to major signalling issues at Birmingham New Street or it could be declared just for the Cross-City line due to a significant train fault.
Code Green
Code Green incidents have a low impact on the running of the railway and cause minor delays of upto around 5 minutes for a limited number of services. Code Green incidents are normally isolated events that impact one line of route or a small number of trains. A Code Green incident may result in a limited number of alterations to services but the normal expectation wouldbe that the vast majority of Code Green incidents will resolve themselves through timetabled recovery times.
A Code Green would be declared by service control if one of the following criteria are met:
- An isolated incident delaying up to 2 trains by less than 5 minutes
- An incident not affecting services (e.g. overnight) but with ethe potential to impact train services resuming in the morning
- An incident that was previously classed as YELLOW or RED where service has resumed too normal
Code Yellow
Code Yellow incidents are more serious than Code Green and have a more noticeable impact on the running of railway services. A Code Yellow incident is one which is expected to cause delays of between 5 and 20 minutes to a number of trains and which has the possibility of causing disruption to a wider section of the railway.
Below are listed the criteria on which control will judge if an incident is to be categorised as a Code Yellow
Off-Peak Period
- An incident expected to delay less than 15 trains by less than 15 minutes
Peak
- Incident expected to delay less than 10 trains by less than 5 minutes
- 3 or more alterations/cancellations on the same route due to a single incident
Suburban Line
- More than 3 services running more than 15 mins late
Long Distance Line
- More than 3 services running between 5 and 25 minutes late
Code Red
Code Red incidents are serious events which cause significant delay to train services or impact a large area of the railway. A Code Red incident is generally one which is expected to cause multiple suburban services to be delayed by over 15 minutes and long-distance services by over 30 minutes. A Code Red incident will result in significant levels of service alterations and cancellations, Code Red incidents are the most disruptive events that will occur randomly in our SimSig sessions.
Below are listed the criteria on which control will judge if an incident is to be categorised as a Code Red
Off-Peak period
- Incident expected to delay 15 or more trains by 15 minutes or more
Peak Period
- Incident expected to delay 10 or more trains by 5 minutes
- Any closure of 1 or more lines (e.g. UMSL or UMFL) on a core route
Suburban
- More than 5 services running more than 15 minutes late
- Consistent alterations/cancellations to services on one line
Long Distance Lines
- More than 5 services running more than 25 minutes late
- Consistent alterations/cancellations on one line
Code Black
Code Black incidents are infrequent incidents that cause widespread delays and result in the unavailability of extensive parts of the network such as the closure of a major terminal station for a prolonged period. In the real railway a Code Black may often result in a TOC issuing an instruction for customers not to travel as the network has been rendered unusable. Due to the level of disruption involved generally if a simulation descends to a point that the level of disruption would warrant a Code Black declaration the session will be ended.
Code Blue
Code blue incidents fall outside of the standard disruption tier system and are simply events on the railway that staff need to be aware of as they have the potential to cause disruption themselves, may impact the severity of disruption should it occur or may change the appropriate response to any disruption that occurs. Examples of Code Blue incidents are things like a severe weather warning, a major sports event or widespread loss of on train facilities such as toilets.
Disruption messages
Communication is key to the effective management of disruption. There is no point in Control declaring a code red and deciding on various cancellations and service changes if these are not communicated to those carrying out signalling roles. Just as the real railway uses systems such as GSM-R and Tyrell to communicate information to staff about incident response we too use verbal and written communication methods to distribute information. For our written communications we use two levels of messages for information flow from control to others involved in the simulation, these being Holding Messages and Core Messages. While the names of these messages are the same as used by the real railways and their functions are similar to actual railway practice their use has been adapted slightly to our needs.
Holding Message
A Holding Message is typically issued by control immediately after they receive information of a potential delay and will contain the available information about an incident/disruption, an initial assessment of which code of disruption the incident is expected to fall under, the impact likely on services and the initial action being taken.
Core Message
A jargon free message issued by control during a major incident/disruption which gives a more detailed update on the nature of an ongoing incident and the impact to services. A Core Message is typically issued at regular intervals for an ongoing incident as well as when there is an update on the development of an incident.
Core messages include information in the following categories
- Incident
- Impact
- Details
- Service Alterations
Example Messages:
Below are examples of the formating for Holding and Core Messages as used during our SimSig sessions.
HOLDING MESSAGE: Disruption due to a train fault at Aston
Due to a train fault at Aston the Birmingham bound line is currently blocked. Services on the Cross City Line are expected to be delayed by up to 30 minutes. Services between Litchfield TV and Gravely Hill are currently being held in platforms where possible and control will issue further service alterations once more is known about the impact of this incident.
CORE MESSAGE: CODE RED Disruption due to a train fault at Aston
Incident:
2N07 has a fault at Aston and is expected to be delayed by approximately 30 minutes
Impact:
Services are unable to run between Perry Bar & Birmingham New Street via Aston and between Litchfield TV and Birmingham New Street via Aston
Details:
Due to a fault on train 2N07 at Aston the line towards Birmingham New Street via Duddeston is blocked. Services through the area are expected to be delayed by approximately 30 minutes. Currently 2R07, 2N09, 2R09, 2A00 and 2N11 are trapped behind 2N07. Services booked to run via Aston are likely to be delayed by up to 30 minutes and have their calling patterns changed or be cancelled or diverted at short notices.
Service Alterations:
- 2N07 terminate at Birmingham New Street and form right time form 2N08 to Litchfield TV
- 2N09 run non-stop Birmingham New Street to Longbridge
- 2R09 to run as booked to Redditch