System Criticality

The plugin System Criticality contains a snippet and a script template to extract the necessary data to calculate the system criticality.

System criticality

System Criticality is used to identify, in the event of a malfunction or failure, which critical signals cause the greatest overall system delay. This can be useful to the infrastructure manager to understand on which signals to focus the attention for a better maintenance or for their improvement, if possible.

An incident is simulated, for a train combination, starting point of the incident, and the duration of the incident.

Quick start

1. Install or enable the plugin System Criticality.
2. Right-click the icon of a Scripted Simulation project, New, Other..., System Criticality script.
3. Customize the script.
   • triggerTrainNumbers: train numbers that will trigger the incidents, grouped in one or more train groups. Or the string 'all' to use all the trains as triggers.
   • durations: list of stop durations
   • scenarioTemplate: (optional) template that defines the name of the simulation scenarios. Must be a single-quoted string. The available variables are duration, trainGroup, triggerTrainNumber, triggerMarkerName.
   • RollingStock, Timetable and Microthe projects that are used for the simulation.
   • incidentTemplate and incidentConfigare the incident template and its configuration respectively. You can omit them if you want to use the predefined incident: an emergency braking performance of 125%
   • In the default slot, import other snippets if needed and configure other characteristics of the script. advanced
4. From the project properties, enable the necessary outputs for the study.
5. From the editor of micro models, select Incident marker from the palette, and insert a marker at each point where you want to start the emergency braking. As Action, select Trigger. As Train position, select Head. Assign unique names to each marker.
6. Execute the simulation.

How it works

This is the template of the script:

snippet('lib/SystemCriticality',
    // snippet configuration
    triggerTrainNumbers: [
        'trainGroup1': [ 'train1', 'train2', ],
        'trainGroup2': [ 'train3', 'train4', ],
        'trainGroup3': [ 'train5', 'train6', ],
        'trainGroup4': [ 'train7', 'train8', ],
    ],
    durations: [ 10.minutes ],
    rollingStock: 'RollingStock',
    timetable:'Timetable',
    micro: 'Micro',
    scenarioTemplate: 'SC_${duration}_${trainGroup}_${triggerTrainNumber}_${triggerMarkerName}',
    incidentTemplate: 'genericTrackCircuitReleaseTime',
    incidentConfig: { config, triggerMarkerName, triggerTrainNumber, duration ->
        config.markerName = triggerMarkerName
        config.triggerTrainExpression = triggerTrainNumber
        config.trackCircuitReleaseTime = duration.seconds
    }    
) {
    // include other plugins
    snippet('lib/TimeSignalAtRed')
    // log file script
    withLog()
}

All the logic is contained in the lib/SystemCriticality.snippet snippet, the body of the script contains only the configuration.

During the build phase each trigger train is simulated independently, and all their passes are registered on the incident marker. The file .dist produced by the build contains a map: train group -> train number trigger -> set of marker names.

During the run, the script executes a simulation for each combination of the train trigger, incident marker crossed by it, and the stop duration. The name of each simulation is defined by the scenarioTemplate argument.

The type of incident and its configuration can be changed thanks to the incidentTemplate (name of the incident template) and incidentConfig parameters, a closure that takes as arguments:

• config: the object that contains the configuration of the incident. Its type depends on the chosen incident template.
• triggerMarkerName: Name of the maker crossed by the train.
• triggerTrainNumber: Train trigger number that causes the incident.
• duration: Duration chosen from the durations list passed to the snippet.

Tutorials

Examples

Emergency braking

In the following example, the train brakes as soon as it passes the marker, at 125% performance, till it stops, and then waits for the chosen duration before departing.

snippet('lib/SystemCriticality',
    // ... other snippet parameters go here ...
    incidentTemplate: 'genericEmergencyBraking',
    incidentConfig: { config, triggerMarkerName, triggerTrainNumber, duration ->
        config.markerName = triggerMarkerName
        config.triggerTrainExpression = triggerTrainNumber
        config.triggerTrainWaitTime = duration.seconds
        config.triggerTrainBrakingPerformance = 125
        config.triggerTrainTargetSpeed = 0
    }    
) {
    // ... default slot goes here ...
}

Track circuit not released

In the following example, the track circuit after the marker is not released after the train passes. The trains that follow will not be able to reserve it and thus will stop at a signal with a stop aspect.

snippet('lib/SystemCriticality',
    // ... other snippet parameters go here ...
    incidentTemplate: 'genericTrackCircuitReleaseTime',
    incidentConfig: { config, triggerMarkerName, triggerTrainNumber, duration ->
        config.markerName = triggerMarkerName
        config.triggerTrainExpression = triggerTrainNumber
        config.trackCircuitReleaseTime = duration.seconds
    }    
) {
    // ... default slot goes here ...
}

In depth guide