Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

ARCH.025 Create foundation for safety risk model

SM-5635 - Populate Confluence page for activity definition: ARCH.025 Create foundation for safety risk state model Finished

GoalIdentify a stable set of "Accidents", "Hazards" and "Safe Control Measures" each with an with an empty cutset as a starting point for Risk Control Management for the execution of risk analyses on Operational Layer
Requirements met by this process step

CSM-SMS guidance 1.1 b), 3.1.1.1 a),

CSM-RA (402/2013) §2.5,

EN 50126-1:2017 §7.4

EN 50126-2:2017 §5

Inputs

AMOD-128 Safety compliance strategy

AMOD-129 Relevant safety legislation/regulations

(for Accidents:)

[EU] DIRECTIVE (EU) 2016/798 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL (of 11 May 2016 on railway safety) 

[EU2] DIRECTIVE 2004/49/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL (of 29 April 2004 on railway safety) 

[UIC] UIC SAFETY DB (https://safetydb.uic.org/

[BEU] Bundesstelle für Eisenbahnunfalluntersuchung - BEU (https://www.eisenbahn-unfalluntersuchung.de

[RiL] Ril 423.0101A01 Definition der gefährlichen Ereignisse im Bahnbetrieb 4230101A01

(for Hazards)

EN62267_BB1.pdf (Bahnanwendungen - Automatischer städtischer schienengebundener Personennahverkehr)

Railway applications, IEC 62290-1: Urban Guided Transport Management and Command/Control Systems, Part 1: System Principles and Fundamental Concepts, Date: 2004, IEC 62290-1_2004.pdf

Railway applications, IEC 62290-2: Urban Guided Transport Management and Command/Control  Systems, Part 2: Functional Requirements Specification, Date: 13.01.2009, IEC 62290-2_2009.pdf

IEEE 1474.1 Standard for Communications- Based Train Control (CBTC), Performance and Functional Requirements, Date: 25.02.2005, IEEE 1474.1-2004.pdf

IEEE 1474.2 Standard for Communications- Based Train Control (CBTC), Performance and Functional Requirements, Date: 12.12.2003, IEEE 1474.2-2003.pdf

IEC 61508-1: Railway applications, Functional safety of electrical/electronic/programmable electronic safety-related systems –  Part 1: General requirements, Ed. 2.0, 2010-04, IEC_61508-1_2010.pdf

MODSafe Project: MODSafe Hompage - Documentlist
Especially, D4.2 "Analysis of Common Safety Requirements Allocation for MODSafe continuous Safety Measures and Functions" and  D2.1 "First List of Hazards, Preliminary Hazard Analysis (PHA)"

NeuPro.71_Risikoanalyse_V2.0.pdf 

SafetyFunctions_VDE V 0831-103.PDF

UNISIG SPecification: Subset-088, SUBSET-088 v3.5.4.zip, and Subset-091 (baseline v3.6.0R02), SUBSET-091_v360.pdf

TeSIP; s. SIRF/TeSIP (EBA, Sicherheitsregelung Fahrzeuge)

TSI's (e.g. TSI Loc&Pas, §4.2.5.5.8): see List of TSI's (ERA Homepage)

TSI-1300-2014, update from 2019, Persons with Disabilities and with Reduced Mobility TSI, https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:02014R1300-20190616&from=EN

TSI-1302-2014, update from 10.03.2020, Rolling Stock - Locomotives and Passengers TSI https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:02014R1302-20200311&from=EN

TSI-0321-2013, update from 11.03.2020, Rolling Stock - Freight Wagons TSIhttp://data.europa.eu/eli/reg/2013/321/2020-03-11

TSI, Guide for the application of the TSI OPE (Operations), 28/06/2019, guide_on_application_of_ope_tsi_2019_en.pdf

TSI, Operation and Traffic Management, IMPLEMENTING REGULATION (EU) 2019/773, 16 May 2019;  s.  TSI Operation and Traffic Management 

Other inputs, e.g. projects like Shift2Rail, X2Rail

Outputs

(for Accidents)

stable set of "Accidents" with an empty cutset

(for hazards)

stable set of generic "Hazards" related to the set of identified "Accidents"

AMOD-109 Accident hazard record

Methodologystate the methodology as a list of instructions; this information forms the Description field of a ticket for this process to be done, so it must be sufficient for someone to follow the process, even if they have not done it before.
Tools and non-human resources

list of all tools (physical and software) needed for this process, plus any non-obvious resources that need to be planned for (such as access to particular non-DBB individuals, operational areas, site visits...)

Cardinality

state how many times this process step is expected to be carried out - e.g.

  • one-off
  • once per <model element>
  • once per baseline

etc.

Completion criteria

state the conditions that must be TRUE before this process step can be considered complete.

These should be inserted in the Acceptance Criteria of a Jira ticket for this process step to be done.

Design reviewLink to the corresponding design review where the completion of this activity is evaluated.
Step done by (Responsible)

Identify the role that is responsible for organising this process step and producing the output;

This is the Assignee in Jira.

Provides input to/assists (Contributes)

Identify the roles that assist in the work or provide input information

Uses outputs (Informed)

Identify the roles and/or process areas that make use of this information outside of the ARCH process area;