wp2 – d2.2 consistency analysis and final hazard … id: del_d2.2_tud_wp2_100430_v1.1 restricted 7...

European Commission Seventh Framework programme

MODSafe Modular Urban Transport Safety and Security Analysis

WP2 – D2.2 Consistency Analysis and

Final Hazard Analysis Reviewed by: WP10 Members Authors: TU Dresden Document ID: DEL_D2.2_TUD_WP2_100430_V1.1 Date: 2010-04-30 Contract No: 218606

Document ID: DEL_D2.2_TUD_WP2_100430_V1.1

Restricted 2 of 25

Contract No. 218606 Document type DEL Version V1.1 Status Final Draft Date 30042010 WP WP 2 Lead Author Astrid Schindelhauer TUD Contributors WP2 partners Reviewer WP10 Members Description Deliverable D2.2 Version 1.1 Document ID DEL_D2.2_TUD_WP2_100430_V1.1

Dissemination level RE Distribution WP10 Document History:

Version Date Author Modification [very short description] V0.1 25.01.2010 A. Schindelhauer Draft of D2.2 to WP2 members V0.2 02.02.2010 A. Schindelhauer Draft of D2.2 to WP10 members V0.3 09.03.2010 A. Schindelhauer,

A. Naundorf Respect comments on V0.2

V0.4 23.03.2010 A. Schindelhauer, A. Naundorf

Respect comments on V0.3





Approval:

Authority Name/Partner Date Visa EB members WP responsible Coordinator


Restricted 3 of 25

Table of contents

1. Summary of this Document....................................................................................5 1.1 References ................................................................................................................5 1.2 Terms and Abbreviations...........................................................................................6

1.2.1 Terms..................................................................................................................6 1.2.2 Abbreviations ......................................................................................................6

2. Introduction..............................................................................................................8 2.1 Aim of Task 2.2 Consistency of the Final Hazard Analysis .......................................9 2.2 Link to other MODSafe WPs .....................................................................................9 2.3 Input...........................................................................................................................9

3. Adaption of generic hazard analysis ...................................................................10 3.1 Grade of Automation in Urban Guided Transportation ............................................10 3.2 Allocation of Safety measures to Grades of Automation .........................................12 3.3 Degraded operation and failure mode of components ............................................13 3.4 Revelation of hazards occurring in system transition states....................................14

4. The MODSafe Safety Model ..................................................................................16 5. Methods and Procedures to check for consistency of Hazard Analysis .........18 5.1 MODSafe Process Proposal....................................................................................18 5.2 Application of process – Example: ZC failure..........................................................20

6. Conclusion .............................................................................................................25 Annex D2.2_Annex_Hazard_ Analysis_100430_v8


Restricted 4 of 25

List of figures Figure 1 MODURBAN boundaries /7/ ......................................................................................8 Figure 2 PHA of D2.1 with safety measures (Excerpt /2/)......................................................13 Figure 3 PHA of D2.2 with assignment of realizations to GOA (Excerpt /3/)..........................13 Figure 4 Methodology to define degraded conditions and failure modes /7/..........................14 Figure 5 System transition state and hazard prevention ........................................................15 Figure 6 MODSafe Safety Model ...........................................................................................16 Figure 7 MODSafe Safety Model elements split up into work packages................................17 Figure 8 Procedure to check for consistency of PHA.............................................................19 Figure 9 Event diagram caused by zone control failure – 1st step..........................................21 Figure 10 Hazards associated with failure of zone controller (1) ...........................................21 Figure 11 Hazards associated with failure of zone controller (2) ...........................................22 Figure 12 Hazards associated with failure of zone controller (3) ...........................................22 Figure 13 Hazards associated with failure of zone controller (4) ...........................................23 Figure 14 Hazards associated with failure of zone controller (5) ...........................................23

List of tables Table 1 – Grades of Automation, MODURBAN D80 /7/.........................................................12 Table 2 - Allocation Hazards associated with failure of zone controller - hazards in PHA .....24


Restricted 5 of 25

1. Summary of this Document This Deliverable describes the procedure on how to ensure that the Hazard List of D2.1 is nearly complete and consistent. It examines in particular the handling of hazards occurring on driverless and unattended train operation modes (GOA3 & GOA4) as well as hazards occurring during degraded train operation.

1.1 References

Reference-ID Document title, identifier and version /1/ DEL_D2.1_TUD_WP2_091021_V2 /2/ D2.1_Annex_Hazard_Analysis_091102_v3 /3/ D2.2_Annex_Hazard_ Analysis_100427_v8 /4/ DEL_MODSYSTEM_WP23_D127annex_TUD_080328 /5/ DEL_MODSYSTEM_WP23_D86_TUD_060914 /6/ DEL_MODURBAN-D129_RATP_WP20_090317_V27 MODURBAN GLOSSARY /7/ DEL_MODSYSTEM-D80_BVG_WP21_090317_V2-5 /8/ DEL_MODSYSTEM-D85_UNIFE_WP22_090515_V10-Final /9/ EN 50126, CENELEC, Railway applications - Specification and demonstration of

reliability, availability, maintainability and safety (RAMS), 1999 /10/ EN 50129 CENELEC, Railway applications - Communications, signalling and

processing systems - Safety related electronic systems for signalling; 2003 /11/ IEC 62290-1 Railway applications - Urban Guided Transport Management and

Command/Control Systems; Part 1: System Principles and Fundamental Concepts /12/ IEC 62267 -Railway applications - Automated Urban Guideway Transport (AUGT) –

Safety requirements Furthermore, the following standards shall be respected: EN 50128 Railway applications – Communication, signalling and processing systems – Software for railway control and protection systems 2001 EN 50125-1 Railway applications – Environmental conditions for equipment – Part 1: equipment on board rolling stock 1999 EN 50125-3 Railway applications – Environmental conditions for equipment – Part 3: equipment for signalling and telecommunications 2003 EN 50121-3-2 Railway applications – Electromagnetic compatibility - Part 3-2: Rolling stock – Apparatus 2000 EN 50121-4 Railway applications - Electromagnetic compatibility - Part 4: Emission and immunity of the signalling and telecommunications apparatus 2000 EN 50238 Railway applications – Compatibility between rolling stock and train detection systems 2003


Restricted 6 of 25

1.2 Terms and Abbreviations

1.2.1 Terms

Term Description Source Automatic Train Protection (ATP)

The functionality which maintains the safety of train movement.

MODURBAN D85, UGTMS

Failure A deviation from the specified performance of a system. A failure is the consequence of a fault or error in the system.

EN 50129

Hazard A condition that could lead to an accident. EN 50129 Grade of automation (GOA)

Automation level of train operation, in which Urban Guided Transport can be operated, resulting from sharing responsibility for given basic functions of transport management between operations staff and system

MODURBAN D80

Movement authority Permission for a train to run safely to a specific location within the constraints of the infrastructure and within other applicable constraints

MODURBAN D80

Movement Authority Limit (MAL)

Location to which the train is permitted to proceed by a movement authority.

MODURBAN D80

Operations Control Centre (OCC)

Centre from which the traffic (and optionally additional functions) of one or several lines is supervised and managed.

MODURBAN D80

Train separation Means of keeping successive trains apart at a safe braking distance. The safe braking distance is the minimum distance in which a train can be guaranteed to be brought to rest

MODURBAN D80, D85 UGTMS

Urban Guided Transport (UGT)

Urban Guided Transport (UGT) is defined as a public transportation system in an urban environment with self-propelled vehicles operated on a guideway.

MODURBAN D80

1.2.2 Abbreviations

Abbreviation Explanation ATP Automated Train Protection AUGT Automated Urban Guideway Transport CCTV Closed Circuit Television CE Clearance Envelope DTO Driverless train operation (GOA3) EU European Union FMEA Failure Mode and Effects Analysis GOA Grade of Automation HMI Human-Machine Interface HVAC Heating, Ventilating and Air Conditioning IL Interlocking MA Movement Authority


Restricted 7 of 25

MAL Movement Authority Limit NTO Non-automated Train Operation (GOA1) OCC Operations Control Centre PHA Preliminary Hazard Analysis PSD Platform Screen Door RATP Régie Autonome des Transports Parisiens (Autonomous

Paris Transport Authority) SIL Safety Integrity Level STO Semi automated train operation (GOA2) UGT Urban Guided Transport UGTMS Urban Guided Transport Management System UTO Unattended train operation (GOA4) TOS On-sight Train Operation (GOA0) ZC Zone Controller


Restricted 8 of 25

2. Introduction Within the whole MODSafe project, one of the first activities is the “Hazard and Risk Analysis” of WP2. Its objective is a proposal of an agreed and harmonized Urban Guided Transport Hazards and Risk Analysis. The work package 2 is parted into three tasks:

• Task 2.1: Provision of a First List of Hazards/Preliminary Hazards Analysis • Task 2.2: Consistency of the Final Hazards Analysis • Task 2.3: MODSafe Risk Analysis

These tasks result in three deliverables, the second one being this document. The first task has produced a First List of Hazards, appended as Annex on the first Deliverable D2.1 /1/, /2/ . The PHA in D2.1 lists hazards without having a specific system in mind. This Deliverable D2.2 is built on this preliminary hazard list. Its main objective is to complete the analysis in such a way, that no residual or even exotic combination of possible hazards in a guided urban transport system will be neglected. D2.2 and hazard analysis deal with the global urban guided transport system including train, traction power system, track, station equipment, passenger information system, communication system, control/command and supervision of train movement system, etc. The Figure below shows the whole UGT system to be considered. (defined in MODURBAN D80 ‘Comprehensive operational, functional and performance requirements’ /7/ ).

Figure 1 MODURBAN boundaries /7/


Restricted 9 of 25

It examines in particular hazards occurring on grades of automation GOA3 & GOA4 (driverless and unattended train operation) as well as hazards occurring during degraded operation.

2.1 Aim of Task 2.2 Consistency of the Final Hazard Analysis

The question is how to ensure that the hazard analysis is nearly complete and consistent. Therefore, several methods and procedures are examined. The aim is to find a procedure to reveal hazards that are not covered by urban rail transport hazards analysis so far. Thus, the D2.2 leaves the generic level of the D2.1 and looks on concrete networks and operation modes. Comments of the MODSafe Consortium on the D2.1 and its Annex dealing with realisation aspects are now taken into account. The focus is on system hazards evoked by failure of system equipment. The leading question is whether the transition of normal operation state to degraded operation state (due to failure of equipment) leads to uncovered hazards. Obviously, the WP2 cannot check all failure modes and possible hazards in all grades of automation and for all existing operating systems. Instead, a method will be presented on how to check the hazard analysis for consistency and is applied on an example.

2.2 Link to other MODSafe WPs

This Deliverable 2.2 is associated with the following work packages:

• WP3 “Hazard Control and Safety Response Analysis” • WP4 “Common Safety Requirements” • WP5 “Functional and Object oriented Safety Model” • WP6 “Safety Life Cycle Responsibilities”

The Task 2.1 and Task 2.2 require no input from other MODSafe work packages, but the Tasks 2.1 to 2.3 are built each on top of the other. The WPs dealing with security hazards shall be considered in order to check for consistency:

• WP8 “Level of sophistication & relevant technology of security surveillance systems” • WP9 “Global approach for Integrated security needs”

2.3 Input

This deliverable is based on the D2.1 /1/ and its Annex /2/. Contributions are made by WP2 members. Furthermore the Standard IEC 62267 /12/ and Deliverables of the EU-funded Project MODURBAN (/4/ /5/ /6/ /7/ /8/) have been put into consideration.


Restricted 10 of 25

3. Adaption of generic hazard analysis The first list of hazards developed in D2.1 is the initial point for this deliverable. The hazard list orders generic hazards that are applicable on each operation system. In Europe, there is a diverse landscape of operation systems, with different operation modes, realizations of safety and other functions and with different conditions concerning e.g. passenger traffic, topology and other environmental influences. The MODSafe WP2 cannot respect every unique operation system, but needs to concentrate on an agreed intersection of systems and its linked hazard analysis. Therefore the generic level of the first list of hazard is left. Remarks from MODSafe partners that were made on D2.1 to complete the hazards list but are not of generic nature are now taken into account. These remarks respect hazard scenarios which refer to specific operation systems (e.g. typical third rail hazards …) Furthermore, the consistency Analysis of WP2 will concentrate on hazards that have high importance in advanced and modern operation systems. Based on the “Grades of Automation” defined within the MODURBAN D80 /7/ , these are hazards occurring in Driverless Train Operation (DTO, GOA3) and unattended train operation (UTO, GOA4). The intention of WP2 is to generate a common Hazard analysis, applicable for any system. Within the Hazard list, there should not be a distinction between different GOA. The frequency/probability of specific hazard occurrence may vary according to the GOA of the system. The implementations of safety measures that cover the hazards depend on the GOA of a System. (will be done in Task 2.3)

3.1 Grade of Automation in Urban Guided Transportation

In modern urban guided railway systems the responsibilities of operation staff and the realizations of procedures are more and more replaced by technical dependencies and systems. In this context the procedures get more complex and the requirements on involved components increase. The EU-funded UGTMS –Project (2002-2004) developed a standard for Urban Guided Transport Management and Command/Control Systems where basic functions of train operations are linked to different system operation categories, so-called Grades of Automation (GOA) which are cited in IEC 62290-1 /11/. MODURBAN refined these GOAs as follows /7/: Grade of automation 0 (GOA0): On-sight Train Operation TOS At this grade of automation the driver has full responsibility and no system is applied to supervise his activities. Grade of automation 1a (GOA1a): Non-automated Train Operation (NTO) with intermittent supervision At this grade of automation the driver is in the front cabin of the train observing the guideway operating the train and stopping the train in case of a hazardous situation. Acceleration and braking are done by the driver in accordance with wayside signals. The system provides wayside information (signals), enforces respect of movement authority and optionally supervises intermittently the respect of the permitted speed. Safe departure of the train from the station, including door closing, is the responsibility of the operation staff.


Restricted 11 of 25

Grade of automation 1b (GOA1b): “Non-automated Train Operation (NTO) with continuous supervision” At this grade of automation the driver is in the front cabin of the train observing the guideway operating the train and stopping the train in case of a hazardous situation. Acceleration and braking are done by the driver in accordance with wayside signals or cab-signal. The system supervises the activities of the driver enforcing signal respect and continuous respect of speed. Safe departure of the train from the station, including door closing, is the responsibility of the operation staff. Grade of automation 2 (GOA2): Semi-automated Train Operation STO At this grade of automation the system is operating the train; the driver is in the front cabin of the train observing the guideway and stopping the train in case of a hazardous situation. Acceleration and braking are automated and the speed is supervised continuously by the system. Safe departure of the train from the station is the responsibility of the operation staff (door opening and closing may be done automatically). Grade of automation 3 (GOA3): Driverless Train Operation DTO At this grade of automation the system is operating the train; there is no driver in a front cabin of the train. Suitable measures are needed to ensure the clearance of the guideway and to stop the train in case of a hazardous situation. For adding and withdrawing trains to/from revenue service, to handle irregular situations and for service aspects operation staff is onboard. Safe departure of the train from the station, including door closing, can be the responsibility of the operation staff or may be done automatically. At GOA3 or higher, it is not possible to operate the system without OCC. Grade of automation 4 (GOA4): Unattended Train Operation UTO At this grade of automation the system is operating the train; no operation staff is onboard at all and suitable measures are needed to ensure the clearance of the guideway, to stop the train in case of a hazardous situation, to control adding and withdrawing trains to/from revenue service and to handle irregular situations remotely. Mandatory basic functions of train operation Table 1 shows the mandatory minimum basic functional requirements for a given GOA on a line or network:


Restricted 12 of 25

Table 1 – Grades of Automation, MODURBAN D80 /7/

3.2 Allocation of Safety measures to Grades of Automation

The PHA of task 2.1 provides already columns filled with safety measures that cover the hazards (see Figure 2, /2/). These safety measures are named in a very generic manner to be consistent with the generic approach of the PHA. The safety measures are provisional and shall be refined by the input of other MODSafe work packages (i.e. safety measures identified in WP3).


Restricted 13 of 25

Figure 2 PHA of D2.1 with safety measures (Excerpt /2/)

In general, the safety measures can be allocated to different categories:

• Initial measures: correct initial design and installation of components and systems • Maintenance measures: inspections, preventive and corrective maintenance • Establishment of procedures for hazardous situations, education and training of staff • Measures to provide safety during system operation, especially train movement and

passenger exchange The focus on the Task 2.2 is on the hazards occurring due to system operation, e.g. failures of functions that provide safe system operation. According to the allocation of responsibilities and realizations of the basic functions per Grades of Automation these safety measures in the PHA are examined. Analogous to the scheme in Table 1, the realizations of the generic safety measures are roughly assigned to responsibilities of staff and realizations by technical systems (Figure 3).

Figure 3 PHA of D2.2 with assignment of realizations to GOA (Excerpt /3/)

3.3 Degraded operation and failure mode of components

Hazardous situations occur in most cases due to failure or error of components that results in series of hazardous events. The nominal operation mode is lost if some components or parts of the system turn in failure mode. A predefined degraded operation enables to keep up a


Restricted 14 of 25

restricted operation. According to MODURBAN D80 /7/, the degraded conditions and failure modes at the system level are defined as follows:

Figure 4 Methodology to define degraded conditions and failure modes /7/

Nominal conditions The Nominal Condition corresponds to the condition of use where each element of the external context of the System fulfils its own functions. Degraded Conditions The Degraded Condition corresponds to the condition of use where at least one element of the external context of the System does not fulfil one of its functions. Failure mode In a failure mode, the System does not fulfil one of its own functions, whether its external context is in nominal or degraded condition. Hence the terms "condition" and "degraded" are only used regarding the context external to the System, the terms "mode" and "failure" deal with the working of the System itself.

3.4 Revelation of hazards occurring in system transition states

When there is a failure of a function or a constituent of the system, the degraded operation is performed through another authorized driving mode (see subclause 5.5 of D80 /7/). If several GOAs are implemented on a given line, the failure of a function or a constituent of the system can be managed through the relevant GOA. The degraded mode of system components depends on the realization of this component, i.e. the objects that perform the required functions. The generic approach of the PHA in Task 2.1 covers hazards occurring during system operation regardless of the operation mode. Besides this, the intermittent state for components and the system should be respected. The transition of the system from one operation state into another or the failure of a component without the change of system operation mode should be examined in detail. The aim is to reveal hazards, which are not yet covered by the MODSafe hazard analysis so far.


Restricted 15 of 25

Figure 5 System transition state and hazard prevention

For the examination of failures of components a Failure Mode and Effects Analysis (FMEA) is applicable. FMEAs of components indicate possible hazards linked to the failure of a system component. Applied to the MODSafe task 2.2, FMEAs of components can be a check for the consistency of the hazard analysis by keeping known operation states and focussing on transitions states of the system (see clause 5).


Restricted 16 of 25

4. The MODSafe Safety Model The Hazard Analysis aims to give advice to different issues, concerning the hazards in normal and degraded operation, the severity of related accidents and safety functions that cover the hazards. The Adaption of the MODSafe WP2 Hazard Analysis is embedded in a Safety Model that combines the work of WP2, WP4 and WP5. While WP2 provides a Hazard Analysis, WP4 assesses safety requirements concerning safety functions that cover the hazards. WP5 will then associate the safety requirements concerning functions to objects according to different operation modes (see Figure 6).

Figure 6 MODSafe Safety Model

In doing so, the leading questions are:

• To what Hazards are Passengers exposed in Normal Operation? • What may be the Severities in related Accidents? • What „Safety“ function covers the Hazard in a GOA? • How do we get a Safety Requirement on this Function? • Does the Safety Requirement reduce the Risk of the Hazard to an acceptable level? • How can we associate the Safety Requirements to the Objects of a Function? • To provide Safety in Degraded Operation, do we need new functions?

The Safety Model starts with the identification of hazards within undisturbed system operation. To each hazard, a related accident category is determined and the severity of this accident is evaluated. Furthermore, generic functions are determined that cover the hazard. Realizations of this safety function can be matched to different Grades of Automation in order to facilitate the application of the hazard analysis to a specific operation system. The WP4 provides a list of common safety requirement definitions. Associated with this is the question whether the resulting reduction of risk is acceptable or whether further measures are required. Although the safety requirements are traditionally linked to functions, the realizations of this function (i.e. the objects that perform the function) determine the ability to


Restricted 17 of 25

reduce a risk by their attributes (e.g failures of mechanical or logical components, wearing, etc.). Moreover, it has to be checked for each system, whether new functions or related objects are required, if the operation mode of a system is changed. The following Figure 7 illustrates the split of the Safety Model elements into the work packages WP2, WP4 and WP5:

Figure 7 MODSafe Safety Model elements split up into work packages

The contribution of the Task 2.2 to the Safety Model is to reveal further hazards, e.g. arised from combinations of several failures. The following clause deals with methods and procedures how to fulfil this objective.


Restricted 18 of 25

5. Methods and Procedures to check for consistency of Hazard Analysis The check for consistency of a Hazard Analysis is not supported by an agreed method. Hazard analyses from different operation systems can be checked in order to compare the records. As the structure of analyses are often diverse and have different focus, a cross check can reveal missing hazards. Nevertheless, the achievement of consistency can only be reviewed on a random basis. Several methods and procedures are in use to reveal hazards. Within this clause the state of the art of check for consistency used by operators participating in WP2 are presented. These methods are checked for their ability to support an agreed procedure to check existing hazard analysis for consistency. A common approach for hazard analysis is a top-down analysis. In doing so, the hazard analysis covers usually the normal operation mode as well as the degraded operation of a system. For further refinements, a FMEA can be considered. The objects of the FMEA are mostly at the lowest level of the hazard analysis, e.g. specific components. The effect analysis is organized in such a way that the effects of the failure mode results either in superior hazards or presents an extension for the initially hazard analysis (bottom-up). The London Underground Ltd. (LU) as well as the Régie Autonome des Transports Parisiens (RATP) use FMEAs to reveal hazards which are not yet considered in the PHA.

5.1 MODSafe Process Proposal

The performance of FMEA for each component of a urban guided transport system is not applicable within the task 2.2. The WP2 cannot provide a complete check of consistency for the whole PHA suitable for any transport system. Instead, this deliverable provides an approach, how the PHA can be checked for further hazards. The procedure is based on FMEA, but leads to analyse failure mode on a higher level, which is more suitable for the generic approach of MODSafe. A more detailed FMEA is only practical for the examination of a specific transport system otherwise the differences on the level of components are too significant. Figure 8 illustrates a procedure how to check the PHA for consistency:


Restricted 19 of 25

Figure 8 Procedure to check for consistency of PHA

• The check starts with the FMEA of a System function, e.g. a safety functions, that

covers hazards within the hazard analysis. • This function is associated with objects that perform this function. • If the function towards the associated object fails, further objects change their state

as consequence. • This status change is not automatically synonymous with a change of operation mode

but may still result in unavailability of further functions within the system. It has to be examined carefully which components are affected by the failure of the function in order to determine the significance of the failure. For the original failure and its subsequent failures a consequence analysis is to be performed.

• An event diagram is proposed in order to compare the hazardous consequences with the hazards in the PHA. The event diagram does not distinguish between positive or restrictive events.

• This procedure is to be repeated until a new stable mode of affected objects and functions is reached, and no further series of reactions are evoked. This stable mode can be an inferior Grade of Automation as far as implemented or a different degraded operation.

• If a hazardous interim event or a situation occur, which is not yet considered in the PHA, the PHA has to be updated. The event diagram itself does not deal with risk estimation (e.g. frequency, severity). This is to be estimated within the hazard and risk analysis

Subsequently, additional failures of functions and objects can be induced at any step of the FMEA. The procedure is then repeated until all involved components reached again a stable state.


Restricted 20 of 25

Within the analysis priorities should be set in order to prevent a too detailed analysis concerning insignificant side issues.

5.2 Application of process – Example: ZC failure

Within this Work package, the application of the procedure can only be presented exemplarily. According to the previous clause, the procedure to reveal further hazards is applied to component failures. As mentioned clause 3, the consistency analysis will concentrate on hazards occurring in Driverless Train Operation (DTO, GOA3) and unattended train operation (UTO, GOA4). The basic functions in these GOAs are mainly realised by technical systems. This should be kept in mind by analysing the consequences of component failures. Zone Controllers failure (GOA4) The Zone Controllers (ZC) are wayside equipment located in technical rooms. A Zone Controller manages trains on a portion or the totality of the line. A zone is a geographical area. A ZC performs the following functions /8/:

• interlocking functions or interfaces with external interlocking (IL). • reports train and wayside data to the OCC • transmission of Movement Authority (MA) to trains. • interfaces with platform door controller or intruding passenger protection system, if

any. • interfaces with Data Storage Unit

The zone controller (ZC) ensures safe separation of trains prevents from e.g. “Undetected train/vehicle” (see 1.3.1.2 and subsequent hazards /2/). According to MODURBAN D80 /7/ and D85 /8/, safe train separation “means of keeping successive trains apart at a safe braking distance. The safe braking distance is the minimum distance in which a train can be guaranteed to be brought to rest.” The following event diagrams illustrate the subsequent events and procedures that are caused by the ZC failure. Figure 9 shows the events that are mainly associated with the ZC failure as consequence. The focus is on shut down of wayside power device, the alerting of the OCC and the stop of train operations. Associated with this are evacuation procedures:


Restricted 21 of 25

Figure 9 Event diagram caused by zone control failure – 1st step

The next step is to associate hazards with these events. These hazards should be checked with the items in the PHA. If necessary, the PHA should be updated. For clarity reasons, the association of hazards to the event diagram is split into several figures with different accident category as possible consequences (see Figure 10 to Figure 14). Table 2 compares the hazards determined in the consistency analysis with the entries in the PHA.

Figure 10 Hazards associated with failure of zone controller (1)


Restricted 22 of 25




Restricted 23 of 25




Restricted 24 of 25

Table 2 - Allocation Hazards associated with failure of zone controller - hazards in PHA Hazards associated with failure of zone controller

Related hazard in PHA

Figure 10 Hazards associated with failure of zone controller (1) Train presence signal failure 1.3.1.2.1.2 Train presence signal failure (wayside) Insufficient worst case safety distance

1.1.1.2.2.1 Insufficient worst case safety distance

Figure 11 Hazards associated with failure of zone controller (2) Wrong alignment; Small doorway 3.1.1. Incorrect train alignment 8.1.5 Inappropriate emergency egress Insufficient lightings 8.1.6.8 Insufficient lighting on walkway 8.9.1.4 Insufficient lighting Insufficient Staff; Wrong orientation

1.3.1.3.2.3 Train detection information processing / communication failure

8.1.2 OCC failure: Communication system failure / Stress, work overload for staff / Insufficient rules or procedures regarding emergency cases and evacuation / Disregard of evacuation and emergency procedures

Figure 12 Hazards associated with failure of zone controller (3) Insufficient training; overspeed, Insufficient Sight

1.1.1.1.1.4 Wrong speed command

Figure 13 Hazards associated with failure of zone controller (4) Failed shutdown of third rail; Bridging from other sectors by train

8.4.2 Power shutdown failure: Incorrect cut-off of power supply rail during evacuation (wrong section is cut-off) , misunderstanding, communication problems

Figure 14 Hazards associated with failure of zone controller (5) Remaining passengers in tunnel 8.1.3 Undetected passengers by evacuation Early restorage, Re-powering 8.4.2 Power shutdown failure: Reinjection of

braking current while track section was cut-off power (during passenger evacuation)

8.4.1 Persons too close to equipment for power supply

Early train restart 8.9.1.5 Train movement during evacuation


Restricted 25 of 25

6. Conclusion The method of a FMEA on a high system level is suitable to track hazardous situations in case of failure of functions. The approach of PHA as a generic analysis includes already a hazard analysis for degraded modes. Instead, the interval between the failure of a component and the achievement of a new stable state is more interesting to check for further hazards. The technical equipment of modern transport systems supports the operating staffs very well by performing safe operation. As the dependencies and connections within a guided transport system are complex, the difficulty is to keep all possible failure evolutions in mind. These evolutions may happen simultaneously or sequentially. The objective of the procedure is to reach stable system states. Besides the transition of the system into a new system state the re-initialization of the system after emergency and evacuation cases represents a challenge. The Hazard Analysis of task 2.2 represents the data base for the later Consequence and Risk Analysis in task 2.3. The results from this Deliverable in combination with results from WP4 and WP5 will lead to a comprehensive Safety Model.

wp2 – d2.2 consistency analysis and final hazard … id: del_d2.2_tud_wp2_100430_v1.1 restricted 7...

Documents