SimSig:Disruption Management: Difference between revisions

From Bradshaw, the companion guide to On Our Lines
No edit summary
(→‎Service Control: updated info)
Line 6: Line 6:
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.  
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 however on Saturday sessions depending on numbers there may be opportunities for others to act as assistant controllers and those interested in being involved with service control should speak to [[User:Jarley|Jarley]].
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|SimSig Sessions]] page.


== Incident Levels ==
== Incident Levels ==

Revision as of 11:47, 4 February 2021

SimSig Sessions
On Our Lines plays SimSig
Upcoming Sessions
2 - Saturday 6 April 2024 Return of the Eastern Magi - East Coast Mainline
3 - Saturday 4 May 2024 Western Region
4 - Saturday 1 June 2024 Southern Region (TBASC)
5 - Saturday 6 July 2024 West Midlands
6 - Saturday 3 August 2024 To be announced
7 - Saturday 7 September 2024 To be announced
8 - Saturday 5 October 2024 To be announced
9 - Saturday 2 November 2024 To be announced
10 - Saturday 7 December 2024 To be announced
11 - Friday 27 December 2024 Christmas Session - to be announced

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:

  1. 2N07 terminate at Birmingham New Street and form right time form 2N08 to Litchfield TV
  2. 2N09 run non-stop Birmingham New Street to Longbridge
  3. 2R09 to run as booked to Redditch

SimSig/Sessions/List