SUBSET-113 v1.1.0

ERTMS/ETCS Class 1
Report from UNISIG Hazard Log
REF
SUBSET-113 1.1.0 2009-04-21
ISSUE : DATE :
Company
ALSTOM ANSALDO BOMBARDIER INVENSYS SIEMENS THALES
Technical Approval
Management approval
This document has been developed and released by UNISIG SUBSET-113 1.1.0 Report from UNISIG Hazard Log Page 1/40
1.
MODIFICATION HISTORY
Issue Number Date Section Number Modification / Description See HAZLOG_v0.0.13 All Document created from Dag Ribbing HAZLOG_v0.0.13. Changes marked compared to this document. Clarified text about omitted hazards after comments from RAMS group Updates after agreed changes during RAMSmeeting 2008-02-06/07 - Updated after review by UNISIG Super Group - Tracing from H0014 to CR477 added - Minor language corrections Dag Ribbing Author
0.0.1 0.0.12 0.0.13 2007-12-17
0.0.14 2008-01-13 0.0.15 2008-02-07 0.0.16 2008-04-02
4.7, 4.9, 4.10, 4.11
4.18, 4.19, 4.20, 4.21
Dag Ribbing
Dag Ribbing
1.0.0 2008-10-14
- Changes agreed during RAMS-meetings plus some minor corrections. Corresponding to HAZLOG_v1.0.0. Proposal on how to answer SG comments, agreed in RAMS-meeting and partly in SG-meeting Added H0022-H0029 from Hazard Log v1.0.6 Corresponding to HAZLOG_V1.0.6
Dag Ribbing
1.0.1 2008-12-16
Dag Ribbing
1.0.6 2008-12-18
Dag Ribbing
1.0.7 2009-01-15 1.0.8
Minor update after comments from Thales and Siemens - Another example added in the description of H0019
This document has been developed and released by UNISIG
Dag Ribbing
Dag Ribbing
SUBSET-113 1.1.0
Page 2/40
2009-02-25
- Updated after comments from Hans Kast - Updates during joint RAMS-SG meeting 200902-17 - A few clarifications agreed in RAMS WP
1.0.9 2009-04-15
- A few updates after comments from Philippe Prieels - H0029 updated according to proposal from Thales
Dag Ribbing
1.1.0 2009-04-21
- Grammatical corrections after RAMS-meeting 2009-04-21
Dag Ribbing
2.
TABLE OF CONTENTS
1. MODIFICATION HISTORY ................................................................................................................ 2 2. TABLE OF CONTENTS .................................................................................................................... 4 3. INTRODUCTION ............................................................................................................................. 6 3.1 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 Background and Purpose.................................................................................................. 6 ETCS-H0001..................................................................................................................... 7 ETCS-H0002..................................................................................................................... 8 ETCS-H0003..................................................................................................................... 9 ETCS-H0004................................................................................................................... 11 ETCS-H0005................................................................................................................... 12 ETCS-H0006................................................................................................................... 13 ETCS-H0007................................................................................................................... 14 ETCS-H0008................................................................................................................... 15 ETCS-H0009................................................................................................................... 16 ETCS-H0010 ............................................................................................................... 17 ETCS-H0011 ............................................................................................................... 18 ETCS-H0012 ............................................................................................................... 19 ETCS-H0013 ............................................................................................................... 20 ETCS-H0014 ............................................................................................................... 21 ETCS-H0015 ............................................................................................................... 23 ETCS-H0016 ............................................................................................................... 24 ETCS-H0017 ............................................................................................................... 25 ETCS-H0018 ............................................................................................................... 26 ETCS-H0019 ............................................................................................................... 27 ETCS-H0020 ............................................................................................................... 28 ETCS-H0021 ............................................................................................................... 29 ETCS-H0022 ............................................................................................................... 30 ETCS-H0023 ............................................................................................................... 31 ETCS-H0024 ............................................................................................................... 33 ETCS-H0025 ............................................................................................................... 35 ETCS-H0026 ............................................................................................................... 36 ETCS-H0027 ............................................................................................................... 37 ETCS-H0028 ............................................................................................................... 38
4. REPORT FROM HAZARD LOG ......................................................................................................... 7
4.29
ETCS-H0029 ............................................................................................................... 39
3.
3.1
3.1.1.1
INTRODUCTION
Background and Purpose
The UNISIG hazard log is a list of scenarios possibly leading to the ETCS core hazard as defined in SUBSET-091. In this sense, the issues are causes in the definition of EN 50129. The causes originate from discussions in the UNISIG RAMS WP. Therefore, the log is not intended to be an exhaustive list of causes for hazards of an ETCS system, but merely a list of things for applications not to forget when doing their hazard analysis. The present document is a report from the UNISIG hazard log, intended to export safety relevant issues to application projects. To not impair interoperability of ETCS, no solution has been allocated to ETCS Onboard.
3.1.1.2
3.1.1.3
3.1.1.4
4.
4.1
REPORT FROM HAZARD LOG

ETCS-H0001
Hazard headline Hazard description
Possible overrun of Supervised Location due to ETCS Onboard not meeting odometer performance requirement ETCS Onboard will allow a train to pass the End of Authority (EoA) in release speed (given by trackside) with a distance equal to the odometer over-reading error before it trips the train, ref Subset-026 section 3.13.8. Moreover, in release speed monitoring, the monitoring of Supervised Location (SvL) is not active. Therefore, a hazardous situation could arise if: The driver doesn't respect the EoA, AND There is no balise group with order to trip the train in connection with the EoA, AND The trip initiated when the min safe front end (or antenna position in Level 1) passes EoA, is not enough to stop the train before SvL. This could happen if the odometer over-reading error is larger than expected during engineering of EoA and SvL: the ETCS Onboard performs worse than the accuracy requirement for position measured onboard in SUBSET-041, section 5.3.1.1, OR there has been no reset of confidence interval due to missing of the relocation balise group close to EoA .
Hazard ID Mitigation proposed by RAMS-group
ETCS-H0001 The combined probability of these events is judged as sufficiently low. However, the wayside engineering must do its most in order to help the train to avoid this hazard. For example, a relocation balise group could be placed close to the EoA, in order to minimise the probability of the onboard performing worse than the accuracy requirements. TRACKSIDE
Mitigation alloscated to TRACKSIDE / EXTERNAL
4.2
ETCS-H0002
Loss of a Position report indicating change from FS/OS mode to SR mode The loss of a Position Report indicating a mode change from FS/OS to SR may be hazardous. In this situation the RBC will rely on an old position report and furthermore is not aware of the mode change of the ETCS Onboard to the mode SR. If the train then moves in SR, the RBC will try to send an updated MA (because it thinks the ETCS Onboard is in FS/OS mode), without having updated position information. If the RBC doesnt have any additional position information from e.g. interlocking, it will then generate an MA under wrong conditions and possibly associate the ETCS Onboard with the wrong route (set for another train at the original position of SR train). The MA will be sent to the ETCS Onboard in SR, which is already waiting for a new MA, because the aim from the operational point of view is to leave the SR mode as soon as possible. ETCS specifications do not provide any measure, like acknowledgement, for systematically recognition of the dangerous loss of Position Report(s) in this situation or to avoid the generation and sending of MA by RBC without confirmation of the safety relevant mode change.
Hazard ID Mitigation proposed by RAMS-group Mitigation allocated to TRACKSIDE / EXTERNAL
ETCS-H0002 Allocation of an MA to the correct train is task of the RBC. How to do this, depends largely on the infrastructure and has to be handled project specific. TRACKSIDE
4.3
ETCS-H0003
Onboard start of mission position report after movement towards LRBG Current situation : A train in SH continues to supervise its location even when running backward. In the same way, train continues to supervise its location after change of cabin.
Such a train may then change of track without crossing over new Balise Group(s) or missing existing one. During Start of Mission (SoM), the ETCS Onboard sends then a valid SoM Position Report that could be ambiguous to the RBC and in worst case relate to an LRBG that may be on another track. As the Position Report is valid, the RBC could consider the train in a wrong place and could deliver a wrong MA. See below examples. 1) Movement in SH
Train enters SH mode after passing BG A. ETCS Onboard supervises its location related to BG A. When in SH, train runs backward and changes track (from the upper to the lower track, see figure). When the train arrives in position X, ETCS Onboard performs Start of Mission connecting to the RBC and giving its valid position report with BG A as LRBG. As the position report is valid, RBC could think that the train is in position Y. If a route is set in front of Y position, RBC may send an MA for the upper track to the train, which is actually intended for the lower track.
SOM SH BG A SOM X Y
2)
Change of cabin
Train enters SH mode after passing BG A. ETCS Onboard supervises its location related to BG A. When in SH, train runs up to position Z and then the driver changes cabin (from the right to the left cabin, see figure). Then, two things can happen: or ETCS Onboard enters SR mode (SH SL SR) SB SR or SH SB + NL SR or SH SB + ETCS Onboard enters SH mode (SH SL SH) SB SH or SH SB + NL SH or SH SB +
The train runs then up to position X. When the train arrives in position X, ETCS Onboard performs Start a Mission connecting to the RBC and giving its valid position report with BG A as LRBG. As the position report is valid, RBC could think hat the train is in position Y.
If a route is set in front of Y position, RBC may send an MA to the train, which is actually intended for the lower track.
SOM SH BG A X Y SOM Z
ETCS-H0003 Either: 1. 2. Trackside engineering shall ensure that a valid position reported by a train during SoM can be trusted, i.e. is unambiguous, OR RBC shall evaluate position reports in SoM in a way that takes into account the possibility of a position ambiguity.
Solution 1 might be difficult to implement on some infrastructures. Solution 2 is systematic but likely to lead to a loss of performance. Mitigation allocated to TRACKSIDE / EXTERNAL TRACKSIDE
4.4
ETCS-H0004
Violation of Mission Profile assumptions The mission profile in SUBSET-091 is the foundation for the derivation of the Tolerable Hazard Rates. However, the mission profile can just be an assumption, as it is impossible to cover all future applications in a reasonably conservative way. If an infrastructure owner has an application which significantly differs from the assumed mission profile, there is subsequently a risk that THRETCS will not be met, although all other requirements in SUBSET-091 are fulfilled. An analysis of the impact of the deviations must then be made. One uncertainty that has been identified is the rate of staff responsible movements in the analysis of the Balise Detect function in SUBSET-088, Annex A. This rate is assumed to be 1-2 per hour. However, if using the End Section Timer, this rate could be considerably higher. When a train is given an MA to a station and the last section is attached with an End Section Timer, the timer is likely to elapse when the train stops at the station. In Level 1, the driver is unable to proceed with ETCS Onboard in Full Supervision mode. To move the train, he must somehow override the MA, either by pressing Override EoA or by going through the Start of Mission procedures. Any of these means that ETCS Onboard will end up in Staff Responsible mode, moving forward looking for the main balise group where it can receive an MA / link chain. An in-fill will not solve the problem, since this MA / link chain is only valid from the next main balise group (e.g. a starter signal) and onwards. In Level 2, the ETCS Onboard can request an MA / link chain from the RBC. Whether this is valid from the starter signal only, or also up the starter signal (under the train) depends on interlocking principles. However, if it is from the starter signal only, other Level 2 functions might be used, such as Track Ahead Free.
Hazard ID Mitigation proposed by RAMS-group Mitigation allocated to TRACKSIDE / EXTERNAL
ETCS-H0004 If deviating from the Mission Profile given in SUBSET-091, a specific analysis has to be made. TRACKSIDE
4.5
ETCS-H0005
Missing National Values more restrictive than Default Values In certain degraded situations defined in Subset-026, section 3.18.2.5, ETCS Onboard shall use Default Values instead of National Values. If these Default Values are less restrictive than the National Values, an unsafe supervision might result. Furthermore, note that the safe ceiling speed in Unfitted will be according to the National Values. Therefore, if passing a border in an unfitted area without border balises, the old National Values will still apply.
ETCS-H0005 If an infrastructure uses National Values more restrictive than the Default Values as defined in Subset-026, chapter 3, annex 3.2, the National Values must be repeated in appropriate balise groups or radio messages. Which balise groups or radio messages this apply to must be analysed in a specific application, however typical examples can be balise groups after stations etc. TRACKSIDE
Mitigation allocated to TRACKSIDE / EXTERNAL
4.6
4.6.1.1
ETCS-H0006
Intentionally left empty. Hazard solved within ETCS specifications and needs no further action by application projects.
4.7
4.7.1.1
ETCS-H0007
4.8
ETCS-H0008
Potentially unsafe calculation of release speed transmitted by trackside When calculating the release speed (if not calculated onboard), some assumptions have to be made on the train; minimum deceleration, time between emergency brake control and effective braking. If these assumptions are not fulfilled by a train, this train may not be able to stop before the danger point.
ETCS-H0008 Release speed can be calculated either offline by trackside (by the infrastructure owner) or online by the ETCS Onboard. If calculating release speed trackside, assumptions about braking properties (deceleration, delay time etc.) are made. These minimum braking properties must be respected by each train in order for the release speed to protect the supervised location. Therefore, each infrastructure owner must make sure that only trains with braking properties better than or equal to the assumed, enter the infrastructure, or do it with applicable restrictions; or to conclude that the residual risk is acceptable. Note: When a section timer has expired, the release speed for the new EOA/LOA is set to the national value. Therefore, the national value for release speed must be lower or equal to the lowest value of release speed associated to any section of the national area.
TRACKSIDE and EXTERNAL
4.9
4.9.1.1
ETCS-H0009
4.10
4.10.1.1
ETCS-H0010
4.11
4.11.1.1
ETCS-H0011
4.12
ETCS-H0012
Expired section timers not restarted in ETCS Onboard when the train goes backwards Subset-026 requires to stop MA section timer when the min safe front end of the train has passed the section time-out stop location (D_SECTIONTIMERSTOPLOC) (see 3.8.4.2.3). It does not require starting this timer again if the train crosses backwards this location. It means that once the section time-out stop location is passed, the related section remains "locked" for the train, from ETCS Onboard point of view. The interlocking, depending on its implementation, may revoke the no longer occupied route (maybe delayed by a route release timer), however the MA in the ETCS Onboard remains valid. This may result in an unsafe situation.
ETCS-H0012 This has to be solved in trackside project specific analysis. One possible solution is that when the train has crossed the MA section time-out stop location (D_SECTIONTIMERSTOPLOC), the interlocking shall always consider the section as locked, even if after that the train moves backwards and then no more occupies this section. Another solution can be to allow backward movement only a distance not longer than the distance between the track circuit joint and the section time-out stop location.
TRACKSIDE and EXTERNAL
4.13
4.13.1.1
ETCS-H0013
4.14
ETCS-H0014
Ignoring BTM antenna test alarms because of suspected Big Metal Mass (BMM) As proposed by CR477 and according to SUBSET-026 v2.3.0: 3.15.7.2: Big metal object in the track, exceeding the limits for big metal masses as defined in Subset-036, section 6.5.2 Metal Masses in the Track may trigger an alarm reporting a malfunction for the onboard balise transmission function. 3.15.7.2: In Levels 0/STM, the alarms which may be triggered by metal masses shall be ignored for a defined distance (see A3.1). If the alarm persists for a longer distance the ERTMS/ETCS on-board equipment shall trigger a safety reaction. Furthermore, there is a packet 67 defined in SUBSET-026 chapter 7 (v2.3.0), that defines areas for which the integrity check alarms of balise transmission shall be ignored. This is a change compared to v2.2.2 where the balise transmission was simply switched off in such areas. The problem with these functions are: 1) Level 1/2 (announced BMM): With the above change in packet 67 functionality, it is now possibly to place balises in areas with BMM. In these areas, the integrity check alarm of the balise transmission equipment shall be ignored, which means that the balise transmission might not be able to fulfill the integrity target (ETCS_OB07 in SUBSET-091). There might be an increased probability for not reading or detecting balises in packet 67 areas. 2) Level 0/STM: When ignoring the balise transmission alarms defined in SRS 3.15.7, the balise transmission might have degraded safety integrity. Care must be taken by an application so that the applicable safety targets for Level 0/STM are still fulfilled.
ETCS-H0014 1) Level 1/2 (announced BMM): It shall not be allowed to have balise groups carrying information that are safety critical to miss, in a packet 67 area. Examples of critical balise groups can be found in ETCS_TR07 in SUBSET-091, but the analysis is application specific. Note that when defining a packet67-area relative to balises mentioned in the above paragraph, a certain margin must be considered since the supervision of the packet67-area is done with odometer confidence interval according to Subset026, paragraph 3.12.1.2.1.2. 2) Level 0/STM: Each application must analyze which Eurobalises they have in Level 0/STM areas and make sure that the safety integrity requirements defined for the corresponding system function in Level 0/STM (outside the scope of SUBSET091) is fulfilled, also considering the possibly degraded safety integrity for the balise detect function when ignoring an antenna test alarm. For example, the two balise groups announcing a Temporary Speed Restriction could be separated with more than D_Metal to protect against ignored balise
SUBSET-113 1.1.0
Page 21/40
transmission failures. The same goes for Level Transmission announcements balise groups. Mitigation allocated to TRACKSIDE / EXTERNAL TRACKSIDE
4.15
4.15.1.1
ETCS-H0015
Intentionally left empty. Hazard is controlled in ETCS to an acceptable risk level and needs no further action by application projects.
4.16
ETCS-H0016
Expired MA and Level Transition Order from RBC Becomes Valid (Entry inside Level 2 Area) Situation: 1. A train with ETCS Onboard is inside a mixed (including Level 2) area running in any other level. Route is set to continue in Level 2 area. The ETCS Onboard has established a communication session to RBC. All preconditions for the announcement of level transition and sending of MA are fulfilled; RBC announces a level transition and sends an MA. The safe connection to ETCS Onboard is interrupted. The protected route is revoked by the interlocking. The RBC is not able to revoke the level transition announcement or granted MA because of the interrupted radio connection. New route, which differs from the previous one, is set in the interlocking. Communication session a. b. c. 7. is still maintained is terminated is terminated and a new communication session is established
2. 3. 4.
5. 6.
The location of the announced level transition is reached and the ETCS Onboard switches to Level 2, whereby the expired (=wrong) MA becomes valid.
Depending on the time stamp of the last received message from RBC, the following can happen : 1) [case 6a) from above]: If the train passes the level transition position with maintained communication session, the train switches to Level 2 and activates the radio link supervision function. After expiration of T_NVCONTACT, the defined safe reaction M_NVCONTACT is activated. [case 6b) from above]: If the train passes the level transition position without communication session, the train switches to Level 2 and activates the radio link supervision function. After expiration of T_NVCONTACT, the safe reaction M_NVCONTACT is activated. [case 6c) from above]: If: - a new communication session is established (e.g. triggered by a balise group) before reaching the level transition position announced during the last communication session, but - no new MA or Level Transition Order is given by the RBC (e.g. some condition for generating MA is not fulfilled), there is a risk for having a wrong MA (received during the first communication session) used by the ETCS Onboard. --> safety issue, potential collision or derailment, in degraded situation, where route revocation and communication interruption come together. Hazard ID Mitigation proposed by RAMS-group Mitigation allocated to TRACKSIDE / EXTERNAL ETCS-H0016 Each trackside project must analyse the scenario and implement necessary measures. Such measures could include MA section timers and/or probabilistic evaluation of the scenario. TRACKSIDE
2)
3)
4.17
4.17.1.1
ETCS-H0017
4.18
ETCS-H0018
Implementation of CR782 CR 782 was raised in order to close gaps in the current SRS regards the specification of the confidence interval of the train, especially in relation to relocation of supervision information, i.e., transferring supervision information to a new reference location. However, CR 782 may induce a safety risk, since it is neither IN nor OUT in SUBSET108 v1.2.0: A) Since it is not OUT it could mean that some supplier of onboard equipment would implement it and thereby disregard some odometer uncertainty in a specific situation (see document CR 782, UNISIG Position regards ERA Solution, case b). B) Since it is not IN it could mean that the trackside solution proposed as barrier to the problem mentioned in A) above would not be implemented.
CR782_UNISIG position_v3_Clean.doc
ETCS-H0018 If implementing CR782, each specific application safety analysis shall identify if the use of odometric margins as specified in CR782 may require additional safety provisions to be handled by the ETCS System Design / infrastructure owner. TRACKSIDE
4.19
ETCS-H0019
Radio message acknowledged by ETCS Onboard but not used According to the rules in Subset-026, chapter 4.8, the information in a radio message can be rejected by the ETCS Onboard. Even in cases where a radio message is rejected according to these rules, the ETCS Onboard will acknowledge the reception of the message to the RBC, if requested, based on e.g. message consistency and direction validity. This may lead to unsafe situations, since the RBC might falsely believe that the ETCS Onboard really uses the acknowledged message. An example of an unsafe situation is if the driver has changed train data which doesnt invalidate the Movement Authority but still require an acknowledgement from the RBC (e.g. train length, train running number). The ETCS Onboard will then reject any new MA until it has received the acknowledgement from the RBC. If the RBC sends a shortened MA during this time the time can be long if the acknowledgement is lost the ETCS Onboard will acknowledge the reception of the shortened MA (if the RBC has required) but reject the information. The old long MA will be used instead. Another example of a hazardous situation is given in the attachment:
CR729_example.doc
ETCS-H0019 The trackside shall analyse if the rules in Subset-026 chapter 4.8 will really allow the ETCS Onboard to accept the information when sending more restrictive information and take any needed safety measures if not. TRACKSIDE
4.20
ETCS-H0020
Overlap/End Section timer in ETCS Onboard less restrictive than trackside See requirements 3.8.4.4, 3.8.4.5, 3.8.5.1 Consider the scenario below: 1. 2. 3. 4. RBC sends MA to ETCS Onboard, containing overlap and overlap/end section timer Train with the ETCS Onboard passes onboard overlap/end section timer start location; timer starts onboard Train with the ETCS Onboard enters the interlocking overlap/end section timer start location (normally entry to end section); timer starts in interlocking RBC repeats MA from step 1 (MA is equal to the first one, or if referred to another LRBG the absolute position of EoA, SvL and overlap/end section timer start location is equal to the first one) ETCS Onboard restarts the overlap/end section timer Since the overlap/end section timer in the interlocking was started (step 3) before the overlap/end section timer in the ETCS onboard (step 5), it expires first. The signalman can therefore revoke the overlap/end section at a time when the ETCS Onboard still considers it as valid.
5. 6.
Regarding step 5: According to SRS 3.8.5.1 A new MA shall always replace the one previously received and as a consequence the ETCS Onboard shall manage accordingly the Section timers (see also SRS 3.8.4.2.1). However it is not specifically required to restart overlap/end section timer (see also Subset-026, 3.8.4.4 and 7.5.1.150). Hazard ID Mitigation proposed by RAMS-group ETCS-H0020 The trackside application project shall mitigate this hazard. It has several ways of doing so, for example: a) by confirming that the situation will not occur in this specific application, or b) by not repeating (as described in point 4 above) MAs once the RBC knows the train has passed the overlap/end section timer start location (this might however be impossible from operability / safety needs, and also impossible with semicontinuous infill devices in Level 1), or c) by following up the value of the interlocking overlap/end section timer in the RBC, taking into account the delay times for transmission of messages interlockingRBC-onboard and transmitting to the train the actual value. Mitigation allocated to TRACKSIDE / EXTERNAL TRACKSIDE
4.21
ETCS-H0021
Rolling backward past balise group If, after having received a L1 MA in FS from a balise group the train moves backwards upstream the BG which gave the MA, the train might end up in rear of the Signal and the BG that gave the MA. The signal might then be switched to stop (e.g. for operational reason). If the driver then tries to violate the stop signal with ETCS mode still Full Supervision, the BG will be ignored because it is not part of the link chain. Thus, the ETCS onboard will not trip the train. The scenario is not hazardous in Level 2. See also CR639.
ETCS-H0021 The hazardous scenario can be mitigated with the use of MA timer. However, this is not mandatory. Therefore, if not using MA timers, the scenario must be analysed in a specific application, to find sufficient arguments for safety. This could include evaluation of the scenario probability or operational rules.
TRACKSIDE
4.22
ETCS-H0022
Supervision Gap In NRBC Handover There are two independent entities in the ETCS, here the ETCS Onboard and the ACC RBC, that take their own decisions on the moment of crossing the RBC border. The ETCS Onboard decides that it has reached the announced RBC transition location with its max safe front end (see Subset-026, 3.15.1.4.2), and switches to the ACC RBC; no more messages will be accepted from the HOV, i.e. only a disconnection order shall be accepted from the Handing Over RBC. See Subset-026, 3.15.1.3.5. In some situations (see below), there is a supervision gap, where neither the HOV nor the ACC RBC are able to revoke the MA on-board. In case of a route degraded or revoked, there is no way of giving the related information to the on-board. 1. 2. 3. 4. The ACC does not know the train's location until the BBG is reported by the ETCS Onboard because it has no information about the balise groups in the HOV area. The ETCS Onboard misses the BBG (only relevant when BBG is passed before max safe front end reaches the announced RBC transition location). The train position report indicating the activation of the ACCs responsibility is lost (both position reports to HOV and to ACC are lost in radio channel). The ETCS Onboard switches the responsibility to the ACC after it has established radio connection to the ACC, e.g. one mobile case
H0022 The following figures refer to the situations described in the hazard description: 1. 2. 3. There must be an overlap in the knowledge of balise engineering in the area where RBC transition can take place No hazard, because ETCS Onboard still listens to HOV The ACC shall send MA revocations to the HOV (as RRI), and additionally to the ETCS Onboard. Note: Redundancy of train position reports when train has passed BBG and when announced RBC transition location is reached with max safe front end; minimizes the gap but does not close it. 4. The HOV informs the ACC of its responsibility by Announcement message on the NRBC interface. Furthermore, according to 3.16.3.4.1.2, up to the moment the ETCS onboard considers ACC to be responsible, it supervises T_NVCONTACT against messages from the HOV, also when it has disconnected HOV. The safe setting of T_NVCONTACT mitigates this hazardous situation.
TRACKSIDE, regarding 1 and 3.
4.23
ETCS-H0023
Use of estimated frontend for TAF window in RBC, leading to driver granting the wrong TAF Subset-026 specifies that the estimated frontend shall be used in order to supervise the TAF window by the ETCS Onboard. But using the estimated frontend for the delivery of TAF requests at the Trackside level can lead to hazardous situation. Indeed, in the following situation :
Estimated frontend
TAF
The estimated frontend could be beyond the real train position in such a way that if RBC provides TAF request based on the estimated frontend, the TAF window that the onboard will receive is not related to the current section (i.e. the one occupied by the train). This could lead to hazardous situation in the following case :
MA (FS)
Estimated frontend
TAF
LRBG
Section 1
Section 2
The driver of the train X grants the TAF, because he sees that the rest of section 1 is free of obstacles. The RBC will associate the received TAF granting to the TAF request it sent (i.e. the TAF request related to section 2) and therefore, will think that this section 2 is occupied by the train X only and that no other train is present on this section, while the train Y is physically occupying this section too. The RBC could therefore send to the train X a FS Movement Authority starting from the LRBG and including the section 2 occupied by the train Y. Note that in case of mixed level area (Level 0/Level 1 + Level 2), the train Y could be in Level 0/Level 1 and therefore, is unknown by the RBC.
H0023 A trackside application safety analysis can with regards to a specific track layout consider this hazard as sufficiently improbable. If not, the RBC should check that the min safe front end is within the TAF section, before sending the TAF request, or to export a requirement on operational rule saying that TAF can only be granted if the driver confirms the id of the marker board.
SUBSET-113 1.1.0
Page 31/40
Note: If the RBC uses the min safe front end for TAF request, this is not directly a contradiction to Subset-026, but will go outside the general statement in section 3.6.4.1 that if nothing is specified, estimated position shall be used. Mitigation allocated to TRACKSIDE / EXTERNAL TRACKSIDE / EXTERNAL
4.24
ETCS-H0024
No Mode Profile applied after rejected MA shortening Following UNISIG SRS 4.8.3, in level 2/3 mode FS/OS, if a Co-operative Shortening of MA is received together with a mode profile, and if a Conditional Emergency Stop is currently in application on-board (not yet revoked), the "Co-operative shortening of MA" passes the filter on level whereas the mode profile is rejected due to exception [5] where : Exception [5] is: "the movement authority and, if received together with this movement authority, the mode profile shall be rejected if emergency stop(s) have been received and are not yet revoked or deleted onboard (see mode transitions)." The following hazardous scenario may apply : 1) The train is in level 2, mode OS : a MA (to EOA 1) and a mode profile On-Sight are currently supervised on-board :
Mode profile On-Sight EOA 1
Level 2, mode OS
2)
The RBC sends a Conditional Emergency Stop (to EOA 2) which is accepted and applied on-board :
Mode profile On-Sight CES EOA 2
Level 2, mode OS
3)
The RBC sends a Co-operative Shortening of MA (to EOA 3), which also contains the mode profile On-Sight (the same as the one currently supervised on-board) : According to SRS 4.8.3, the Co-operative Shortening of MA is accepted. According to SRS 4.8.3, the mode profile is rejected because a CES is in application (not yet revoked). According to the indication point location of the shorter MA (refer to SRS 3.8.6.1b), the Co-operative Shortening of MA is granted by the ETCS Onboard and the shorter MA is stored on-board;
Mode profile On-Sight Request to shorten MA EOA 3
Level 2, mode FS
Indication point associated to EOA 3
Nevertheless, according to SRS 3.12.4.3, as the associated mode profile has been filtered, the one currently supervised on-board should be deleted. As a consequence, the train could switch to Full Supervision mode in an On-Sight area. Hazard ID Mitigation proposed by RAMS-group Mitigation allocated to H0024 Until CR854 is implemented, the solution should be done by the RBC by e.g. not sending Co-operative shortening of MA while there is a CES in application in ETCS Onboard TRACKSIDE
TRACKSIDE / EXTERNAL
4.25
ETCS-H0025
MA shortening extends MA already in ETCS Onboard There is no specific requirement in Subset-026 about the reception of an MA shortening longer than the current EoA (refer to Subset-026 3.8.6.1b) in the following cases: cooperative shortening of MA or new MA provided without gradient and speed profiles. The ETCS Onboard could therefore accept this new EoA (e.g. corresponds to an MA extension instead of a MA shortening), with more permissive speed and gradient profiles corresponding to the open profiles of the last received MA. This could result in potentially dangerous situation in the following scenario : 1) 2) Train has received an MA with open speed and gradient profile, i.e. the profile is longer than the current EoA. The RBC sends to the train an extension of the current MA but: The ETCS Onboard does not receive it (e.g. radio communication failure) AND, the RBC either does not request the acknowledgement of the MA or may request it but does not take it into account; OR the ETCS Onboard rejects it (e.g. CES already in application). 3) The RBC sends afterwards an MA shortening based on the previously sent MA extension.
Note: This is not a problem if the speed and gradient profile received in 1) ends at the current EoA, since the longer MA received in 3) does not contain the speed and gradient profile. As a result, the ETCS Onboard will have an MA without profile, and will thereby according to Subset-026 3.7.2.3, not accept the new MA.
H0025 As the SRS authorises an ETCS Onboard to accept and use an MA shortening that is not shorter than the current MA, the RBC should not use open profiles in combination with cooperative shortening of MA (defined in SRS 3.8.6) or new MA provided without gradient and speed profiles. TRACKSIDE
4.26
ETCS-H0026
Override in SB possible in levels 0 and STM. Following CR 659 (DC of Subset-108 1.2.0), override in SB only possible in level 2/3. If not implemented in ETCS Onboard, override may be possible in other levels. In particular, SR mode could be entered spuriously in level 0 or STM. In level STM, mode SR, the STM may stop to supervise the train movements.
Mitigation proposal by author Hazard ID Mitigation proposed by RAMS-group
The ERTMS Application Project shall ensure that the SR mode is not entered when running in Level 0 or STM. H0026 If not implementing CR 659, the override when being in SB mode in Levels 0 and STM should be forbidden in e.g. driver manual or export the constraint to operational procedures. EXTERNAL
4.27
4.27.1.1
ETCS-H0027
4.28
ETCS-H0028
Acknowledgement of Train Data validates invalid MA The Acknowledgement of Train Data, as sent by the RBC, may validate a MA on-board that was sent previously by the RBC, under conditions of different train data.
RBC OBU OBU is running in L0/LSTM, in approach to L2 area buffered MA #2 buffered New Train Data L0 / LSTM Update of train data, MA#1 is deleted
MA #1
Ack of New Train Data
accepted Level Transition to L2. Check: MA#2 is valid
Wrong MA is used MA #3 Wrong MA#2 is corrected by MA#3
L2
The remaining risk Train running with the wrong MA (#2) Corrective MA (#3) may be delayed in delivery to on-board, or, due to internal checks, RBC could decide not to send any MA to the train because of the new train data
is difficult to quantify in a generic ETCS environment, mainly because the probabilities involved will be very uncertain when quantified in a generic UNISIG level. Hazard ID Mitigation proposed by RAMS-group H0028 As noted in CR790, the remaining risk can be seen as acceptable providing that the time during which the wrong MA is used, is made sufficiently short (as a proposal for sufficiently short, the accepted value of T_NVCONTACT could be used). The RBC should make sure it is, e.g. to immediately send an updated MA based on the new train data. TRACKSIDE
4.29
ETCS-H0029
RBC cannot trust Train Position Report as on-board event handling is not predictable Subset-026, 3.6.5.1.4, defines a number of events when train position reports have to be sent by the on-board to the RBC. Furthermore, the RBC can request additional position reports for a combination of the possibilities given in 3.6.5.1.5. In summary, there are a number of situations where position reports have to be sent, with a high probability of overlapping each other. The definition given in 3.6.5.1.8, that the reported mode and level shall be consistent, is not sufficient for the RBC to trust in a train position report when it is received. Example follows for a train running within a mixed level operation area. Here is no border balise group sending a LTO to Level:
Balise OBU
TPR(BG0, L1/FS)
RBC Balise Group BG0 is located outside of the area the RBC is responsible for. No action for the RBC.
Train passes Balise Group BG1, that gives L1 MA with OS mode profile. Position Report Processing Time
L1 MA(OS)
TPR(BG1, L1/FS)
Train passes next Positioning Balise Group BG2.
The RBC cannot trust this position report (wrong mode).
MA Processing Time
TPR(BG2, L1/FS)
The RBC still cannot trust this position report (wrong mode). This is the position report the RBC can trust as a basis for LTO and MA (correct mode).
TPR(BG2, L1/OS)
Other possible reasons for additional position reports during MA processing may be a) b) c) Driver interactions Internal triggers, based on the position report parameters Level Transition Order is executed before MA evaluation is completed
With the current definitions of the requirements mentioned above, the RBC cannot trust the Level/Mode reported with the Train Position Report. This may result in an unsafe situation if the RBC because of availability reasons decides to trust the level-mode combinations in e.g. train position report TPR(BG1, L1/FS) or TPR(BG2, L1/FS) in the figure above. The RBC then sends an FS MA when it should be an OS MA. There exists a performance requirement of 1.5 seconds for update of status onboard in Subset-041, paragraph 5.2.1.3. This can be used for limiting the time at risk. Hazard ID ETCS-H0029
Mitigation proposed by RAMS-group
Until ETCS Onboard functionality is changed so that the mode in a position report can be trusted (CR887, not yet part of ERA CR database), the RBC cannot trust a reported mode without taking the processing time of the ETCS Onboard into account. TRACKSIDE

SUBSET-113 v1.1.0

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SUBSET-113 v1.1.0

Загружено:

Авторское право:

Доступные форматы

ERTMS/ETCS Class 1

Report from UNISIG Hazard Log

SUBSET-113 1.1.0 2009-04-21

0.0.1 0.0.12 0.0.13 2007-12-17

0.0.14 2008-01-13 0.0.15 2008-02-07 0.0.16 2008-04-02

4.7, 4.9, 4.10, 4.11

4.18, 4.19, 4.20, 4.21

1.0.7 2009-01-15 1.0.8

Report from UNISIG Hazard Log

- Grammatical corrections after RAMS-meeting 2009-04-21

4. REPORT FROM HAZARD LOG ......................................................................................................... 7

REPORT FROM HAZARD LOG

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Mitigation alloscated to TRACKSIDE / EXTERNAL

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group Mitigation allocated to TRACKSIDE / EXTERNAL

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group Mitigation allocated to TRACKSIDE / EXTERNAL

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Mitigation allocated to TRACKSIDE / EXTERNAL

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Mitigation allocated to TRACKSIDE / EXTERNAL

TRACKSIDE and EXTERNAL

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Mitigation allocated to TRACKSIDE / EXTERNAL

TRACKSIDE and EXTERNAL

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Report from UNISIG Hazard Log

Hazard headline Hazard description

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Mitigation allocated to TRACKSIDE / EXTERNAL

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Mitigation allocated to TRACKSIDE / EXTERNAL

Hazard headline Hazard description

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Mitigation allocated to TRACKSIDE / EXTERNAL

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Mitigation allocated to TRACKSIDE / EXTERNAL

TRACKSIDE, regarding 1 and 3.

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Report from UNISIG Hazard Log

Hazard headline Hazard description

Indication point associated to EOA 3

Hazard headline Hazard description

Hazard ID Mitigation proposed by RAMS-group

Mitigation allocated to TRACKSIDE / EXTERNAL

Hazard headline Hazard description

Mitigation proposal by author Hazard ID Mitigation proposed by RAMS-group

Mitigation allocated to TRACKSIDE / EXTERNAL

Hazard headline Hazard description

Ack of New Train Data

accepted Level Transition to L2. Check: MA#2 is valid