Editing SimSig:Disruption Management

[[File:Liverpool Street Departure Boards (Disrupted).jpg|thumb]]
{{Infobox Sessions|list=yes}}
Just like the real railway things do not always go as planned when playing [[SimSig]] with various faults, failures and other disruptive incidents occurring during a game. As our regular Saturday [[SS:S|SimSig Sessions]] sessions are intended to provide a level of immersion and realism to operations that is accessible to both new and experienced SimSig users alike, we have created a disruption management and messaging system that is based off of Network Rail and Train Operating Company (TOC) practice. This page is intended to be a guide to both those carrying our [[Signaller]] and [[SimSig:Service Controller|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 [[SimSig:Service Controller|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. Communication between Signallers and Service Controllers is available during simulations using our [[SS:ROC|Railway Operating Centre]] webapp which is powered via our [https://discord.com/invite/bSYHkpFBhU Discord server].

Due to the way that SimSig works the host of a simulation is the only one able to make edits to the running schedule of train services. However, on Saturday sessions depending on numbers, there may be assistant controllers who will watch out of delays and assist the principal controllers in deciding what action should be taken. [[SimSig:Service Controller|Controllers]] for formal games, like hosts, are appointed by invitation based on their contributions to previous simulations and after demonstrating a suitable level of ability, those interested in being considered for helping out with Control should add their names to the Community section of the [[SS:S|SimSig Sessions]] page.

== Incident Levels ==
Most TOCs use four incident levels for grading incidents on the railway to help staff understand the event's severity in question. The trigger points for incidents vary from TOC to TOC however, below is an explanation of our system which is derived from a suburban TOCs operating practice. The level of an incident is determined by service control staff and communicated 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 train fault.

=== Code Green ===
Code Green incidents have a low impact on the running of the railway and cause minor delays of up to around 5 minutes for a limited number of services. Code Green incidents are 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 would be 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 two trains by less than 5 minutes.
* An incident not affecting services (e.g. overnight) but with the potential to impact train services resuming in the morning.
* An incident that was previously classed as YELLOW or RED where service has resumed to normal.
[[File:TCF Example.png|thumb|563x563px|SimSig display showing a Track Circuit Failure (TCF) on the loop at Haywards Heath. The failure can been seen as the red line in the loop not associated with a train. In this case the failure can be worked around and would have minimal impact on trains. This would be a Code Green incident.]]

=== 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'''
* An incident expected to delay less than fifteen trains by less than 15 minutes.
'''Peak'''
* Incident expected to delay less than ten trains by less than 5 minutes.
* Three or more alterations/cancellations on the same route due to a single incident.
'''Suburban lines'''
* More than three services running more than 15 mins late.
'''Long Distance line'''
* More than three 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'''
* Incident expected to delay fifteen or more trains by 15 minutes or more.
'''Peak'''
* Incident expected to delay ten or more trains by 5 minutes.
* Any closure of one or more lines (e.g. UMSL or UMFL) on a core route.
'''Suburban lines'''
* More than five services running more than 15 minutes late.
* Consistent alterations/cancellations to services on one line.
'''Long-Distance lines'''
* More than five 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 the 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 the incident response, we too use verbal and written communication methods to distribute information. For our verbal communications we use our [[SS:ROC|Railway Operating Centre]] webapp designed for the purpose. 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 an 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
{{SimSig Sessions}}
[[Category:SimSig]]