SCRRA/Metrolink Interoperable Electronic Train Management ...

Southern California Regional Rail Authority (Metrolink)

SCRRA/Metrolink

Interoperable Electronic Train Management System (I-ETMS®)

Docket Number FRA-2010-0048

Positive Train Control Safety Plan

(PTCSP)

December 30, 2015

VOLUME I – MAIN BODY Version 2.0

(NO REDACTIONS NECESSARY)

This document is the PTC Safety Plan (PTCSP) for the Metrolink PTC system. This Plan is submitted to the Federal Railroad Administration (FRA) for FRA approval pursuant to

49CFR 236, Subpart I, §236.1015, as mandated by the Rail Safety Improvement Act of 2008 (RSIA 08) for PTC system certification.

.

I-ETMS SCRRA/Metrolink PTC Safety Plan VOLUME I

Revision History

Date

Revision Description Author

9/6/13 0.4

Revised to JRST 2.1 template Contains sections 1-10, 12, 13, 21-28, 31-36. Contains Appendices G.1-G.8, Q, X, Y, AA, HH RSC

9/30/13 0.5

Volume I Contains additional Sections 11, 14-20, 27, 29, and 30 and Volume II contains additional appendices D, D.1, D.2, E, F, G.4, G.7, H.1, H.2, O, P.1, T, U, BB, EE, FF, GG, JJ.1, and LL. RSC

6/1/15 0.6

Volume I complete and revised. All appendices complete in Volume II. Executive Summary and Redaction Matrix added to document. Harmonized with the BNSF PTCSP Rev 1.0 and FRA comments on same. RSC

6/26/15 1.0

Pre-release based on current revision of Subpart I regulation and corrections to Rev 0.6 per internal SCRRA review. Confidential version only.

RSC/ SCRRA

6/30/15 1.1 Final edits for release SCRRA

7/2/15 1.3 SSI Markings removed from confidential version RSC/ SCRRA

7/17/15 1.4

Table 11-4 moved to Appendix E. No redactions necessary to main body of PTCSP. Redaction Matrix added to document as Section 37. Version not submitted to FRA

RSC/ SCRRA

7/24/15 1.5 Redaction Matrix updated in Section 37 per track changes shown.

RSC/ SCRRA

9/15/15 1.6

No content changes to main body of PTCSP, only revision level changed. Corrections made to Appendices in Volume II as identified therein.

RSC/ SCRRA

9/17/15 1.7

Redaction Matrix updated in Section 37 per track changes shown. Corrections made to Appendices in Volume II as identified therein.

RSC/ SCRRA

12/30/15 2.0

Corrections based on FRA comments on version 1.7 and guidance from the FRA. Updated to reflect six months of fleetwide, systemwide RSD experience.

RSC/ SCRRA

Version 2.0 ii December 30, 2015


Table of Contents

Executive Summary of PTCSP ..................................................................................... 1

1 Introduction ....................................................................................................... 11 1.1 METROLINK SYSTEM OVERVIEW .......................................................................... 11 1.2 USE OF THE TERMS “I-ETMS” AND “PTC SYSTEM” IN THIS PTCSP ....................... 15 1.3 DOCUMENT OVERVIEW ....................................................................................... 15

Document Section Contents.................................................................. 18 1.3.11.4 PTCSP DRAFTS PREVIOUSLY SHARED WITH FRA ................................................ 50 1.5 UPDATE OF THIS PTCSP .................................................................................... 50 1.6 ACRONYMS AND DEFINITIONS .............................................................................. 50

2 Applicable Documents ..................................................................................... 56

3 Confirmation of FRA Type Designation for Metrolink PTC System [49CFR §236.1015(e)(2)] ................................................................................................. 59

3.1 RELIABLY EXECUTE PTC SYSTEM FUNCTIONS OF 49CFR § 236.1005 .................. 59 3.2 SUFFICIENT DOCUMENTATION TO FULFILL APPENDIX C SAFETY ASSURANCE

PRINCIPLES ....................................................................................................... 59 3.3 JUSTIFICATION OF NON-VITAL CLASSIFICATION OF THE COMMUNICATIONS SEGMENT 60

Introduction ........................................................................................... 61 3.3.1 General Properties of Wired and Wireless Data Communication Systems3.3.2

.............................................................................................................. 61 PTC Design Strategy for Mitigation of Communication System Errors .. 62 3.3.3 Hazard Analysis of PTC Communications Systems .............................. 63 3.3.4 Resulting Lack of Dependence on Error-Free Performance of 3.3.5

Communication System ........................................................................ 67 Conclusion ............................................................................................ 67 3.3.6

4 Type Approval Reference [49CFR §236.1015(b)] ........................................... 68 4.1 TYPE APPROVAL REFERENCED AND UTILIZED IN THIS PTCSP ............................... 68 4.2 PTC PRODUCT VENDORS LIST (PTCPVL) [§236.1015(B)(1)]............................... 68 4.3 PTC SYSTEM VENDOR QUALITY CONTROL SYSTEM [§236.1015(B) (2)] ................. 68 4.4 APPLICABLE LICENSING INFORMATION [§236.1015(B) (3)] ..................................... 69

5 PTCDP Reference and Identification of Any Variances [§236.1015(c)] ........ 71 5.1 PTCDP AND TYPE APPROVAL REFERENCES [§236.1015(C) (1)] ........................... 71 5.2 ANY VARIANCES FROM PTCDP (TYPE APPROVED) [§236.1015(C) (2)(II)] .............. 71

Enter Main Track at Signal in Lieu of Electric Lock Location ................. 72 5.2.1 Malfunctioning Highway Grade Crossing Warning System ................... 72 5.2.2 Clarification of Wayside Status Relay Service (WSRS) ........................ 73 5.2.3 Work Zone Protection ........................................................................... 73 5.2.4 Update of Hazard Risk Index for I-ETMS to AREMA C&S Manual, Part 5.2.5

17.3.5 .................................................................................................... 74 Technique for Passing Non-communicating Signal ............................... 74 5.2.6

5.3 ATTESTING TO COMPLIANCE WITH REFERENCED PTCDP [§236.1015(C)(3)] ......... 75

Version 2.0 iii December 30, 2015


6 Metrolink PTC System Implementation [§236.1013(a), §236.1015(d)] .......... 76 6.1 INFORMATION REQUIRED FOR PTCDP UNDER §236.1013(A) ............................... 76

Incorporate PTCDP by Reference ......................................................... 76 6.1.1 I-ETMS System Safety Integration Descriptions ................................... 76 6.1.2 Final Human Factors Assessment ........................................................ 76 6.1.3

6.2 METROLINK APPLICATION OF I-ETMS .................................................................. 76 Metrolink-Specific Implementation of Functions .................................... 77 6.2.1 Current Functions that have Predefined Changes Leading to Future Vital 6.2.2

Implementation ...................................................................................... 97 6.2.2.1 Generation and Use of Consist Data, Including Total Brake Force 97

Current short term Mitigation Applied .............................................................................................. 97 6.2.2.1.1 Predefined Changes for Vital Mitigation ......................................................................................... 98 6.2.2.1.2

6.2.2.2 Highway Grade Crossing Warning System Malfunction Protection 98

Current Short Term Mitigation Applied ............................................................................................ 99 6.2.2.2.1 Predefined Changes for Vital Mitigation ......................................................................................... 99 6.2.2.2.2

6.2.2.3 Initial Track Selection ................................................................... 99 Current Short Term Mitigation Applied .......................................................................................... 100 6.2.2.3.1 Predefined Changes for Vital Mitigation ....................................................................................... 100 6.2.2.3.2

6.2.2.4 Crew Acknowledge of Electronic Mandatory Directives ............. 101 Current Short Term Mitigation Applied .......................................................................................... 101 6.2.2.4.1 Predefined Changes for Vital Mitigation ....................................................................................... 101 6.2.2.4.2

6.2.2.5 EIC Terminal for Authorization to Enter Work Zone ................... 102 Current Short Term Mitigation Applied .......................................................................................... 102 6.2.2.5.1 Predefined Changes for Vital Mitigation ....................................................................................... 103 6.2.2.5.2

6.2.2.6 I-ETMS “Restricting” State vs “Switching” State ........................ 103 6.2.2.7 Enter Main Track at Signal in Lieu of Electric Lock Location ..... 103

Current Short Term Mitigation Applied .......................................................................................... 103 6.2.2.7.1 Predefined Changes for Vital Mitigation ....................................................................................... 105 6.2.2.7.2

6.2.2.8 Use of “Disengaged” State in Onboard I-ETMS ......................... 105 Current Short Term Mitigation Applied .......................................................................................... 105 6.2.2.8.1 Predefined Changes for Vital Mitigation ....................................................................................... 105 6.2.2.8.2

6.2.2.9 Hazards Attributed to BOS......................................................... 106 Current Short Term Mitigation Applied .......................................................................................... 106 6.2.2.9.1 Predefined Changes for Vital Mitigation ....................................................................................... 106 6.2.2.9.2

Metrolink-Specific Implementation of I-ETMS Architecture ................. 107 6.2.36.2.3.1 Office Segment .......................................................................... 108

Network Management System (NMS) .......................................................................................... 108 6.2.3.1.1 Computer-Aided Dispatching (CAD) ............................................................................................. 108 6.2.3.1.2 Dispatch ............................................................................................................................................ 109 6.2.3.1.3 Metrolink ITCM Network.................................................................................................................. 109 6.2.3.1.4 Wayside Status Relay Service ....................................................................................................... 109 6.2.3.1.5

6.2.3.2 Communication Segment .......................................................... 110 Communications Network ............................................................................................................... 112 6.2.3.2.1 220 MHz Radio Network ................................................................................................................. 113 6.2.3.2.2 802.11 ................................................................................................................................................ 116 6.2.3.2.3 Cellular .............................................................................................................................................. 116 6.2.3.2.4 The Messaging System ................................................................................................................... 116 6.2.3.2.5 Network Management System (NMS) .......................................................................................... 118 6.2.3.2.6

6.2.3.3 Wayside Segment ...................................................................... 118 6.2.3.4 Locomotive Segment ................................................................. 119

Version 2.0 iv December 30, 2015


I-ETMS Train Management Computer .......................................................................................... 121 6.2.3.4.1 Chassis .............................................................................................................................................. 122 6.2.3.4.2 CPU Module ..................................................................................................................................... 123 6.2.3.4.3 Input/Output Concentrator .............................................................................................................. 124 6.2.3.4.4 I-ETMS Brake Interface Module..................................................................................................... 124 6.2.3.4.5 Discrete Input/Output Module ........................................................................................................ 126 6.2.3.4.6 Router/Switch Module ..................................................................................................................... 128 6.2.3.4.7 Cab Display Unit .............................................................................................................................. 128 6.2.3.4.8 Locomotive ID Module ..................................................................................................................... 129 6.2.3.4.9

GPS Receiver ................................................................................................................................... 129 6.2.3.4.10 Locomotive Event Recorder ........................................................................................................... 130 6.2.3.4.11 Train Control Application ................................................................................................................. 131 6.2.3.4.12

Business Applications ......................................................................... 133 6.2.4 Metrolink PTC System Configuration Parameter Selections ............... 133 6.2.5

6.2.5.1 Process for Modification of Configuration Parameters ............... 135 Modification of Railroad Common Configuration Parameters ................................................... 135 6.2.5.1.1 Modification of Metrolink-specific Configuration Parameters ..................................................... 135 6.2.5.1.2

Interoperable Architecture from PTCDP .............................................. 135 6.2.6

7 Final Human Factors Analysis [§236.1013(a)(5)] [§236.1015(d)] ................. 137 7.1 FINAL HUMAN FACTORS ANALYSIS OF CDU ....................................................... 137 7.2 METROLINK ON-BOARD PTC EQUIPMENT LOCATION REVIEW PROCESS ............... 138

Metrolink On–Board PTC Equipment Location Review ....................... 138 7.2.1 Metrolink On-Board PTC Equipment Location Review Findings ......... 139 7.2.2

7.3 OTHER I-ETMS HUMAN INTERFACES AND THEIR ANALYSIS FOR HUMAN FACTORS 141 CAD Operator/Dispatcher interfaces ................................................... 141 7.3.1 Wabtrax Tool for Track Database Configuration ................................. 141 7.3.2

8 Safety Assessment and Application of 49CFR 236, Appendix C [§236.1015(d)(5)] [§236.1015(e)(2)(ii)] [49CFR 236, Appendix C] ................ 142

8.1 SAFETY PROGRAM SCOPE FOR I-ETMS ............................................................ 142 8.2 I-ETMS SYSTEM SAFETY PROGRAM PLAN (SSPP) ............................................ 145 8.3 I-ETMS SYSTEM SAFETY PROCESS .................................................................. 146 8.4 VERIFICATION AND VALIDATION OF I-ETMS ........................................................ 153 8.5 SEGMENT SAFETY REQUIREMENTS COMPLIANCE [49CFR 236 APPENDIX C] ........ 153

System Safety Under Normal Operating Conditions [49CFR 236 8.5.1Appendix C(b)(1)] ................................................................................ 153

Safety Under Systematic Failures [49CFR 236 Appendix C (b)(2)(i)] . 154 8.5.2 Safety Under Conditions of Random Hardware Failures [49CFR 236 8.5.3

Appendix C (b)(2)(ii)] ........................................................................... 155 No Single Point of Failure Shall Result in an Unacceptable Hazard 8.5.4

[49CFR 236 Appendix C (b)(2)(iii)] ...................................................... 156 No Combination of Failures Shall Result in an Unacceptable Hazard 8.5.5

[49CFR Part 236 Appendix C (b)(2)(iv)] .............................................. 156 Common Mode Failures Shall Not Result in an Unacceptable Hazard 8.5.6

[49CFR 236 Appendix C (b)(2)(v)] ...................................................... 156 Adherence to the Closed Loop Principle [49CFR 236 Appendix C (b)(3)]8.5.7

............................................................................................................ 157 Incorporation of Safety Assurance Concepts [49CFR 236 Appendix C 8.5.8

(b)(4)] .................................................................................................. 157

Version 2.0 v December 30, 2015


Incorporation of Human Factors [49CFR 236 Appendix C (b)(5)] ....... 158 8.5.9 System Safety under External Influences [49CFR 236 Appendix C (b)(6)]8.5.10

............................................................................................................ 158 System Safety after Modification [49CFR 236 Appendix C (b)(7)] ...... 158 8.5.11 Acceptable Verification and Validation Standards [49CFR 236 Appendix 8.5.12

C(c)] .................................................................................................... 159 8.6 SAFETY AUDITS ................................................................................................ 159 8.7 SEGMENT ORIENTATION OF VERIFICATION AND VALIDATION ................................. 160 8.8 SYSTEM LEVEL V&V (LEVELS 1, 2, AND 3) ......................................................... 162

Supplier Support for Validation of I-ETMS (WRE) ............................. 162 8.8.18.9 PLATFORM LEVEL VERIFICATION & VALIDATION (LEVELS 4 AND 5) ........................ 163 8.10 I-ETMS PLATFORM VERIFICATION APPROACH .............................................. 163 8.11 I-ETMS WAYSIDE SEGMENT PLATFORM VERIFICATION (WIU VENDORS) ........ 164

WIU Vendor Safety Verification Results .............................................. 164 8.11.1 Locomotive Segment – WRE TMC Platform Safety Verification ......... 165 8.11.2

9 Hazard Log [§236.1015(d)(1)] ......................................................................... 167 9.1 HAZARD LOG DESCRIPTION ............................................................................... 168 9.2 HL ROLE IN THE PTC SAFETY ASSESSMENT ...................................................... 168 9.3 THE I-ETMS HAZARD LOG ................................................................................ 169 9.4 CONCLUSIONS DRAWN FROM HL ANALYSIS ........................................................ 169 9.5 MAINTENANCE OF THE HL ................................................................................. 169 9.6 OPERATING AND SUPPORT CHECKLIST APPLICABLE TO RAILROADS (OSCAR) ...... 170

Purpose ............................................................................................... 170 9.6.1 Scope .................................................................................................. 170 9.6.2

10 Safety Assurance Concepts [§236.1015(d)(2)] [Part 236 Appendix C (b)] . 173

11 Risk Assessment [§236.1015(d)(3), Part 236 Appendix B (as revised)] ..... 174 11.1 RISK ASSESSMENT APPROACH .................................................................... 174

Risk Assessment Objectives ............................................................... 174 11.1.1 Risk Assessment Methodology ........................................................... 175 11.1.2

11.1.2.1 APPENDIX C COMPLIANCE ANALYSIS .................................. 175 11.1.2.2 RAILROAD CAD SYSTEMS IMPACT ASSESSMENT .............. 177 11.1.2.3 RESIDUAL RISK ASSESSMENT .............................................. 177

11.2 49CFR PART 236, APPENDIX C SAFETY PRINCIPLE COMPLIANCE CONCLUSIONS ............................................................................................ 179

11.3 RAILROAD SYSTEMS IMPACT ASSESSMENT ...................................... 181 11.4 RESIDUAL RISK ASSESSMENT CONCLUSIONS ................................................ 182

12 Hazard Mitigation Analysis [§236.1015(d)(4)] ............................................... 183 12.1 SYSTEM PRELIMINARY HAZARD ANALYSIS (PHA) .......................................... 184

Methodology of the PHA ..................................................................... 184 12.1.1 Results from PHA ................................................................................ 186 12.1.2

12.2 LOCOMOTIVE (ONBOARD) SUBSYSTEM HAZARD ANALYSIS (LSSHA) .............. 186 Locomotive SSHA Methodology .......................................................... 187 12.2.1 Results from Locomotive SSHA .......................................................... 187 12.2.2

Version 2.0 vi December 30, 2015


12.3 OFFICE SUBSYSTEM HAZARD ANALYSIS (OSSHA) ........................................ 188 Office SSHA Methodology .................................................................. 188 12.3.1 Results from Office Segment SSHA .................................................... 189 12.3.2

12.4 OPERATING & SUPPORT HAZARD ANALYSIS (O&SHA) .................................. 189 O&SHA Methodology .......................................................................... 190 12.4.1 Results from O&SHA .......................................................................... 191 12.4.2

12.5 SYSTEM FUNCTIONAL FAULT TREE (FFT) ..................................................... 191 Functional Fault Tree Methodology ..................................................... 192 12.5.1 Results from Functional Fault Tree Analysis ....................................... 192 12.5.2

12.6 SEGMENT FAULT TREE ANALYSIS (FTA) ....................................................... 192 Fault Tree Analysis Methodology ........................................................ 193 12.6.1 Results from Fault Tree Analysis ........................................................ 193 12.6.2

12.7 SYSTEM HAZARD ANALYSIS ......................................................................... 193 System Hazard Analysis Methodology ................................................ 194 12.7.1 Results from System Hazard Analysis ................................................ 194 12.7.2

12.8 FAILURE MODES AND EFFECTS ANALYSIS (FMEA) ........................................ 195 FMEA Methodology ............................................................................. 195 12.8.1 Results of FMEA ................................................................................. 196 12.8.2

12.9 PLATFORM ANALYSIS .................................................................................. 196 Platform Analysis Methodology ........................................................... 196 12.9.1 Results from Platform Analysis ........................................................... 196 12.9.2

12.10 TMC ENVIRONMENTAL TESTING RESULTS .................................................... 197 12.11 EMC TESTING RESULTS .............................................................................. 197

13 Verification and Validation Processes [§236.1015(d)(5)] ............................ 199 13.1 MASTER TEST STRATEGY ............................................................................ 200 13.2 VALIDATION AND VERIFICATION OF I-ETMS ................................................... 201 13.3 PTC SYSTEM VALIDATION AND VERIFICATION PROCESSES ............................ 202 13.4 TESTING I-ETMS ........................................................................................ 205

Unit/Component Testing ..................................................................... 205 13.4.1 Laboratory Segment Testing ............................................................... 205 13.4.2 Laboratory Component Integration Testing ......................................... 207 13.4.3 Laboratory Track Database Testing .................................................... 209 13.4.4 Field Track Database & Wayside Input / Output Validation and 13.4.5

Verification .......................................................................................... 209 Track Database Attribute Testing ........................................................ 210 13.4.6 Field Testing of I-ETMS ...................................................................... 211 13.4.7 Revenue Service Demonstration ......................................................... 212 13.4.8

13.5 PTC SYSTEM AND SEGMENT VERIFICATION RESULTS .................................... 213 13.6 PTC SYSTEM RELIABILITY ........................................................................... 215 13.7 INTEROPERABILITY TESTING ......................................................................... 215

14 Metrolink Training Plan [§236.1015(d)(6)] [§236.1041] [§236.1043] [§236.1045] [§236.1047(a),(b) & (d)] [§236.1049] ........................................... 218

14.1 TRAINING AND QUALIFICATION PROGRAM ...................................................... 218 14.2 OFFICE CONTROL PERSONNEL TRAINING ...................................................... 218 14.3 TRAIN DISPATCHER TRAINING ...................................................................... 218

Version 2.0 vii December 30, 2015


14.4 LOCOMOTIVE ENGINEER PERSONNEL TRAINING ............................................. 219 14.5 OFFICE PERSONNEL TRAINING ..................................................................... 219 14.6 SIGNAL PERSONNEL TRAINING ..................................................................... 220 14.7 TELECOMMUNICATIONS PERSONNEL TRAINING .............................................. 220 14.8 MECHANICAL PERSONNEL TRAINING ............................................................. 220 14.9 FIRST LINE SUPERVISOR TRAINING ............................................................... 220 14.10 MOW/ROADWAY WORKER PERSONNEL TRAINING ........................................ 220 14.11 USE OF LOCOMOTIVE SIMULATOR IN TRAINING .............................................. 221 14.12 OPERATING RULES FOR PTC ....................................................................... 221

Books of Rules .................................................................................... 221 14.12.1 PTC Operating Instructions and Crew Record-Keeping ...................... 221 14.12.2 General Order in Effect ....................................................................... 225 14.12.3

15 Procedures, Test Equipment, and Operations and Maintenance Manual [§236.1015(d)(7)] [§236.1039 (all)] .................................................................. 227

15.1 MAINTENANCE PROCEDURES AND PROCESS ................................................. 227 Metrolink Policies ................................................................................ 227 15.1.1 Metrolink-Specific Procedures............................................................. 228 15.1.2 Controlling and Tracking Documents .................................................. 229 15.1.3 Controlling and Tracking Component/Product Modifications ............... 229 15.1.4

15.2 PTC OPERATIONS AND MAINTENANCE MANUALS .......................................... 229 Safety Mitigations Addressed by the O&M Manual Contents .............. 233 15.2.1 Vendor Product O&M Manuals (Sub-manuals to the PTC system O&M 15.2.2

Manual) ............................................................................................... 233 15.3 TEST EQUIPMENT ........................................................................................ 233

16 Warnings and Warning Labels [§236.1015(d)(8)] ......................................... 235 16.1 WARNINGS IN MANUALS .............................................................................. 235 16.2 WARNING LABELS ....................................................................................... 235 16.3 WARNINGS IN VENDOR MANUALS ................................................................. 236

17 Configuration Management and Revision Control Measures, Metrolink [§236.1015(d)(9)] [§236.1023(c)(2)] ................................................................ 237

17.1 CM ACRONYMS, TERMINOLOGIES AND DEFINITIONS ...................................... 237 17.2 INDUSTRY-LEVEL CONFIGURATION MANAGEMENT .......................................... 238 17.3 CONFIGURATION MANAGEMENT INTEGRATION WITH INDUSTRY ........................ 238 17.4 TRACK DATA AND DATABASE MANAGEMENT .................................................. 239 17.5 METROLINK PTC SYSTEM CONFIGURATION MANAGEMENT ............................. 240 17.6 METROLINK REVISION CONTROL MEASURES ................................................. 242 17.7 VENDOR CONFIGURATION MANAGEMENT AND REVISION CONTROL MEASURES 242

18 Initial Implementation Testing Procedures [§236.1015(d)(10)] .................. 243 18.1 SCRRA INFORMATIONAL FILING AND TESTING WAIVERS ............................... 244 18.2 PRE-CERTIFICATION FIELD DEPLOYMENT ...................................................... 244 18.3 POST-CERTIFICATION SEGMENT DEFINITION ................................................. 245 18.4 KEY ELEMENTS OF PTC POST-CERTIFICATION DEPLOYMENT PROCESS .......... 245 18.5 INTEROPERABILITY TESTING ......................................................................... 246

Version 2.0 viii December 30, 2015


19 Post-Implementation Testing (Validation) and Monitoring Procedures [§236.1015(d)(11)] ........................................................................................... 248

19.1 REPLACEMENT OF EXISTING PTC SYSTEM BY NEW PTC SYSTEM .................. 251 19.2 SYSTEM RELIABILITY AND AVAILABILITY TARGETS .......................................... 252 19.3 POST IMPLEMENTATION AND MONITORING ACTIVITIES .................................... 253

20 Records [§236.1015(d)(12)] [§236.1023(b)(1)], [§236.1023(e)] [§236.1037] . 254 20.1 RECORD DESCRIPTION ................................................................................ 255 20.2 DATA RETENTION MANAGEMENT .................................................................. 255

Type Approval, PTCDP, and PTCSP .................................................. 258 20.2.1 Supporting Safety Documentation for PTCDP/PTCSP ....................... 258 20.2.2 Training Records ................................................................................. 258 20.2.3 Inspection & Test Records .................................................................. 259 20.2.4 Hazard Log.......................................................................................... 259 20.2.5 Product Vendor List ............................................................................. 260 20.2.6

20.3 DISCLOSURE OF PTC-RELATED HAZARDOUS CONDITIONS OR SAFETY-RELATED FAILURES ........................................................................................................ 260

21 Safety Analysis of Work Zone Incursion Protection from Human Error [§236.1015(d)(13)] ........................................................................................... 261

21.1 FUNCTIONAL DESCRIPTION .......................................................................... 261 21.2 IDENTIFICATION AND MITIGATION OF HUMAN ERRORS .................................... 262 21.3 METROLINK OPERATING RULES RELATED TO I-ETMS PROTECTION AGAINST

WORK ZONE INCURSION ................................................................................... 263 21.4 METROLINK WORK ZONE CONFIGURATION PARAMETERS ............................... 263

Approaching Active Work Zone ........................................................... 264 21.4.1 Work Zone becomes Active while within Limits (or within calculated 21.4.2

position uncertainty) ............................................................................ 264

22 Alternative Arrangements for Rail At-Grade Diamond Crossings [§236.1005(a)(1)(i)] [§236.1015(d)(14)] <reserved> ...................................... 265

23 Authority and Signal Enforcement Exceptions Not in PTCDP [§236.1005(e)(4)] [§236.1015(d)(15)] .............................................................. 266

23.1 TRAIN STOP SYSTEM (ATS) ........................................................................ 266 23.2 ENTER MAIN TRACK - SIGNAL IN LIEU OF ELECTRIC LOCK .............................. 266

24 Compliance with Stated MTEA [§236.1015(d)(16)] [§236.1019(f)] ............... 268

25 Deviation in Operational Requirements for Enroute Failures [§236.1015(d)(17)] [§236.1015(d)(21)] [§236.1029(c)] ................................... 269

26 Enforcement of Hazard Detectors [§236.1005(a)(4)(v)] [§236.1005(c)(1)] [§236.1005(c)(2)] [§236.1015(d)(18)] ............................................................. 270

26.1 FUNCTION DESCRIPTION FOR INTEGRATED HAZARD DETECTORS .................... 270 26.2 INTEGRATION OF HAZARD DETECTORS ON METROLINK ................................. 271

Version 2.0 ix December 30, 2015


26.3 FUNCTION DESCRIPTION FOR ADDITIONAL NON-INTEGRATED HAZARD DETECTORS ON METROLINK ................................................................................................. 271

27 Emergency and Planned Maintenance Re-Routing Management Plan [§236.1005(g-k)] [§236.1015(d)(19)] [§236.1029] [§236.1033(f)] ................... 272

28 High Speed Service Requirements [§236.1005(c)(3)] [§236.1007] [§236.1015(d)(20)] ........................................................................................... 273

29 Communication and Security Requirements [§236.1015(d)(20)] [§236.1033] 274

29.1 COMMUNICATIONS RESTORATION PLAN ........................................................ 274 29.2 PTC SECURITY PROVISIONS IN I-ETMS ....................................................... 275 29.3 SECURITY MEASURES FOR EMPLOYEES AND VENDORS .................................. 275

30 Identification of Potential Data Errors and their Mitigation [§236.1015(h)] 276 30.1 SOURCES OF POTENTIAL DATA ERRORS ....................................................... 276 30.2 MITIGATIONS FOR POTENTIAL DATA ERROR HAZARDS ................................... 277

31 Third Party Assessment [§236.1017] ............................................................ 278

32 PTC Data Maintained in Locomotive Event Recorder [§229.135(b)(3)(xxv)] [§229.135(b)(4)(xxi)] [§236.1005(d)] ............................................................... 279

33 Process for Reporting Errors and Malfunctions [§236.1023] ...................... 280 33.1 PTCPVL [§236.1023(A)]............................................................................ 280 33.2 CONTRACTUAL ARRANGEMENTS WITH SUPPLIERS OR VENDORS

[§236.1023(B)(1)] ........................................................................................... 280 33.3 USE OF HAZARD LOG FOR TRACKING ............................................................ 280 33.4 PTC SYSTEM VENDOR QUALITY CONTROL SYSTEM [§236.1015(B)] .............. 284

34 Role of Office Automation Systems in the PTC System [§236.1027(a)] <Reserved> ..................................................................................................... 285

35 Novel Technology Employed in Highway Crossing Protection for PTC [§234.275(c)] <Reserved> .............................................................................. 286

36 List of Appendices ......................................................................................... 287

37 Redaction Matrix ............................................................................................. 289

Version 2.0 x December 30, 2015


Table of Figures

Figure 0-1 Organization of System Safety Assessment Process…………………………6 Figure 1-1 System Map ................................................................................................ 12 Figure 5-1 WSRS Architecture ...................................................................................... 73 Figure 5-2 Hazard Risk Index, AREMA C&S Manual, Part 17.3.5 ............................... 74 Figure 6-1 Overview of Metrolink I-ETMS PTC System ............................................... 77 Figure 6-2 WSRS Architecture ................................................................................. 110 Figure 6-3 I-ETMS Communications Network Architecture ........................................ 111 Figure 6-4 I-ETMS Locomotive Segment Communications Architecture ................... 112 Figure 6-5 ITC Messaging System Architecture ................................................... 117 Figure 6-6 I-ETMS Locomotive Segment Configuration ............................................. 120 Figure 6-7 I-ETMS Locomotive Segment Architecture ............................................... 123 Figure 6-8 I-ETMS Cab Display Unit .......................................................................... 129 Figure 6-9 Primary I-ETMS Display Screen - Graphical Elements .............................. 132 Figure 6-10 Primary I-ETMS Display Screen - Textual Elements ................................ 133 Figure 8-1 Scope of I-ETMS System Safety ............................................................... 143 Figure 8-2 – I-ETMS System Safety Assessment Process ......................................... 147 Figure 8-3 – “V Model” Development and Safety Activities ......................................... 148 Figure 8-4 General Platform Architecture ................................................................... 165 Figure 9-1 - Managing Operating & Support Hazards ................................................. 172 Figure 12-1 Organization of Hazard Mitigation Analysis.............................................. 184 Figure 13-1 Metrolink Certification and V&V Flowchart ............................................... 200 Figure 13-2 System Safety Segment Verification Process ......................................... 206 Figure 13-3 Traceability Diagram ............................................................................... 214 Figure 14-1 PTC EVENT REPORT FORM ................................................................ 223 Figure 15-1 Hierarchy of Administrative Documents .................................................. 228 Figure 16-1 Warning Label for PTC WIU .................................................................... 236 Figure 33-1 I-ETMS Hazard Log Management Process ............................................. 282

Table of Tables

Table 1-1 Summary of Section Contents ...................................................................... 18 Table 1-2 49CFR 236, Subpart I Cross-Reference from Regulation to PTCSP ........... 23 Table 1-3 Abbreviations and Acronyms ........................................................................ 50 Table 1-4 Definitions of Safety Terms .......................................................................... 54 Table 3-1 Potential Communications Hazard Events ................................................... 63 Table 3-2 Potential Threats ......................................................................................... 64 Table 3-3 Hazard Impacts vs. Failure Events in Communications ............................... 65 Table 4-1 Metrolink Licenses for PTC .......................................................................... 69 Table 6-1 I-ETMS Functions from the PTCDP ............................................................. 80 Table 8-1 Safety Assessment Process Activities ....................................................... 150 Table 11-1 I-ETMS Functional Decomposition ........................................................... 178 Table 11-2 49CFR Part 236, Appendix C Compliance ............................................... 180 Table 11-3 Railroad Systems Impact Assessment ..................................................... 182 Table 13-1 Field Testing Levels ................................................................................. 212

Version 2.0 xi December 30, 2015


Table 17-1 Acronyms, Terminologies and Definitions ................................................ 237 Table 19-1 NMS Alarm List ........................................................................................ 248 Table 20-1 Retained Documents ................................................................................ 256 Table 21-1 Work Zone related TBCs ......................................................................... 263 Table 37-1 Redaction Matrix ..................................................................................... 290

Version 2.0 xii December 30, 2015


Executive Summary of PTCSP

This document is the Southern California Regional Rail Authority (SCRRA) Positive Train Control Safety Plan (PTCSP) for the SCRRA Positive Train Control system implemented on Metrolink’s service territory. This PTCSP provides the appropriate information and safety analysis to support System Certification for SCRRA’s implementation of their Interoperable Electronic Train Management System (I-ETMS), intended as a vital overlay PTC system as defined in 49CFR §236.1015 (e)(2). The PTCSP describes the Safety Assurance Concepts employed and the results of all Safety Assurance activities in connection with the PTC implementation. The body of work is believed to be a PTC system that is potentially certifiable as safe by the Federal Railroad Administration (FRA). The PTC system vitality is supported by the safety documents contained in the Appendices (e.g., A, G, H, V, HH) and the safety analysis contained in Appendix G. Metrolink’s underlying signal system is a vital system operated through centralized supervisory control using a Computer Aided Dispatch (CAD) system. There is no dark territory (non-signaled) to be equipped with PTC on the Metrolink system. Metrolink trains are operated by a one-person crew in the cab of both locomotives and cab cars. The train conductor is physically located in the passenger coaches of the trains. The Wabtec Railway Electronics Interoperable Electronic Train Management System (I-ETMS®) is used as the core technology and functionality for the SCRRA PTC system. The PTC system has been developed in compliance with requirements and standards defined in response to Rail Safety Improvement Act of 2008 (RSIA08) per reference [3] contained in Section 2 of this document, and through the Interoperable Train Control (“ITC”) industry effort and Association of American Railroads (AAR) Specifications. Although supported by the I-ETMS system design, Metrolink has no intention to utilize energy management systems on its locomotives. The operating description for I-ETMS is provided in the Positive Train Control Development Plan (PTCDP), which received Type Approval from the FRA. The SCRRA implementation of I-ETMS is compliant with the description of the system in the PTCDP in all respects. SCRRA has been actively engaged within the rail industry, and with FRA, in comprehensively reading, interpreting and compiling necessary documentation required under FRA regulations toward implementation of PTC. SCRRA has participated with the I-ETMS system provider Wabtec Railway Electronics (WRE), in establishing the PTCDP for I-ETMS, and has collaboratively worked with the Joint Rail Safety Team (JRST), who held quarterly meetings with the FRA in creating a common template structure for the PTCSP that several Class 1 Railroads have utilized for railroad specific PTCSP FRA filings. SCRRA has also held its own quarterly meetings over the past 5

Version 2.0 1 December 30, 2015


years with FRA to provide developmental status and obtain necessary guidance for the PTC system. As of this submission, SCRRA has completed over 20,000 successful passenger runs in 9 months of Revenue Service Demonstration (RSD) and has operated in RSD for 6 months system-wide and fleet-wide. SCRRA received permission to begin Revenue Service Demonstration in February of 2015, and began RSD operation in March of 2015. SCRRA ramped up RSD operations subdivision by subdivision and by July of 2015 achieved RSD on all scheduled Metrolink-owned passenger trains (165 trips per day, Monday through Friday) on all Metrolink-owned lines. SCRRA has completed installation of PTC equipment on three leased locomotives, and in addition, has arranged to lease 40 additional locomotives for a temporary duration from a Class I railroad. These leased locomotives will be equipped with PTC and will operate in RSD in lieu of some of the PTC equipped cab cars currently in use. SCRRA is preparing to begin passenger operation on a new subdivision, the Perris Valley Line, and is equipping the subdivision with PTC prior to carrying passengers in revenue service. SCRRA has created the position of Deputy Chief Operating Officer of PTC and Engineering to head the PTC effort and has staffed their new operations center to support PTC seven days a week. All training has been completed and all Metrolink owned locomotive and cab cars are equipped. As the workforce changes through normal attrition, new employees receive PTC training as part of their job training. When changes are made to the signal system or any work takes place which affects the PTC system, the PTC changes are coordinated as part of the signal cutover or as part of the modifications to the infrastructure. The PTC changes are implemented when modified track is returned to service. Throughout implementation of I-ETMS as documented within the SCRRA PTCIP, SCRRA has generated specific actions and compiled critical evidence to address the requirements of 49CFR Part 236 Subpart I for PTC. In documenting the body of evidence to support the safety plan, as detailed in the Appendices attached hereto, SCRRA has:

• Referenced applicable industry and safety standards and regulations, as provided in Section 2 of this PTCSP,

• Provided FRA required regulatory submittals. Refer to SIR site contents as previously submitted to FRA under separate cover.

• Described the SCRRA rail environment and application of its PTC system to its subdivisions, see Section 1 of this PTCSP.

• Identified hazards, defined hazard mitigations and performed or sponsored creation of various hazard and safety analyses, as given in Appendix G, to attest to the implementation of I-ETMS as a vital overlay.



• Performed a risk assessment identifying the residual risk remaining with I-ETMS; attesting that it satisfies the level required for a vital overlay PTC system, as described in Appendix F.

• Identified processes and procedures employed to perform functional and safety verification and validation of the implemented PTC system over its useful life cycle. Refer to Section 13 of this PTCSP.

• Provided results of all verification and validation activities performed as submitted to the SIR site under separate cover.

• Identified the means by which SCRRA is addressing special operational scenarios (e.g., Work Zones), as described in Section 21.

• Identified how SCRRA will address impacts to operations in the light of system degraded modes or failures. Refer to Appendix S of this PTCSP.

• Identified how SCRRA is maintaining proper configurations, managing safety related records, as well as changes to PTC system components. This information is found in Section 20 and Appendix P of this PTCSP.

• Provided the planning, curriculum, management of, and results of a PTC Training program, as summarized in Appendix K of this PTCSP.

• Worked closely with its interoperability partners in confirming proper operation in applicable host/tenant scenarios. See RSD-I results submitted to the SIR site under separate cover.

• Indicated and described in advance, those future functions that it intends to implement in the longer term to enhance the level of safety, affording a more positive impact on the SCRRA operational environment. These are provided in Section 6.2.2 of this PTCSP.

In order to gain System Certification, 49CFR §236.1005 requires that all PTC systems reliably prevent train-to-train collisions, overspeed derailments, incursions into work zones, and movements of a train through a misaligned switch. In addition, the regulation also requires that a PTC system integrate all authorities and indications of a wayside or cab signal system and provide appropriate warnings and enforcements for protection of derails or switches entering the main line, highway grade crossing malfunctions, after arrival mandatory directives (where affected), moveable bridges, integrated hazard detectors, and maximum train speed in areas without broken rail protection. In addition to the above requirements, vital overlay PTC systems must show that the PTC system fulfills the safety assurance principles set forth in 49CFR §236 Appendix C. This includes: • System safety under normal operating conditions • System safety under failures



• Closed loop principle • Safety assurance concepts • Human factor engineering principle • System safety under external influences • System safety after modification These safety assurance principles are addressed in the Risk Assessment Appendix F and in Section 8 of this PTCSP. Scope This PTCSP provides analysis, as given in Appendix G, to demonstrate that the PTC system, as a whole, is intended to be a vital overlay. The scope of the safety assessment concentrates on the installed elements of PTC and their interfaces to existing railroad systems and operations. The elements that make up the proposed PTC system consist of four segments: 1. Office Segment – Currently Non-Vital (“predefined changes” will lead to future

vital implementation using the IC3 and an Independent Validation Server (IVS) as described in Section 6.2.2.9.2 of this PTCSP). a. Includes the interfaces to existing Dispatch and Management Information Systems

2. Communications Segment – Non-Vital (justification provided in Section 3.3 herein) 3. Locomotive Segment – Vital

a. Includes the interfaces to existing Brake System & Locomotive Control System

4. Wayside Segment - Vital a. Includes the interfaces to existing Signal System (supported by safety

data contained in Appendix V of this PTCSP). I-ETMS is a locomotive-centric, overlay system that operates through the assimilation and processing of data by the Locomotive Segment. The vital Locomotive Segment continuously accepts, validates, and processes operating data obtained from onboard peripheral devices and from the Office and Wayside Segments. Non-vital elements are validated and combined in such a way as to eliminate single points of failure at a system level and reduce the overall probability of unsafe failure. This locomotive-centric approach provides the Locomotive Segment with the independent capability to detect data errors, data conflicts, and data latency, facilitating its safe operation. The accompanying safety analysis provides the quantitative and qualitative analysis required to show that, given the combination of vital and non-vital segments, the PTC system, evaluated as a whole with the “predefined changes” to be implemented in the future (refer to Section 6.2.2 of this PTCSP), could be interpreted as a vital overlay. Analysis



This PTCSP and the results of system testing show that the functionality of I-ETMS is designed to, and reliably does, prevent:

• Train-to-train collisions

• Overspeed derailments

• Incursions into established work zone limits

• The movement of a train through a main line switch in the improper position

• Encroachment into the site of a highway-rail grade crossing warning system malfunction as required by §234.105, 234.106, and 234.107. The PTC system enforces a mandatory directive associated with the failed crossing warning system.

SCRRA’s lab and field testing as described in Appendices J and M respectively, coupled with more than 20,000 Revenue Service Demonstration runs, separately documented in RSD reports to FRA via the SIR site, show that the PTC system reliably protects against all of these items. Test results show that the system as designed per the I-ETMS requirements properly executes all of these functions. The System Safety Assessment Process shown in Figure 0-1 is the complete process applied during the life cycle of I-ETMS to establish safety objectives and to demonstrate compliance with 49CFR §236 Subpart I. Several analyses of varying scope and intent have been performed on the I-ETMS system to supply the necessary proof that appropriate segments of the system have been designed and implemented according to 49CFR §236, Appendix C, as shown in Figure 1. These analyses, contained in Appendix G, feed into the Hazard Log, Risk Assessment, and Platform Analysis, also contained in the Appendices D, F, and G.8 of this PTCSP, respectively.



Figure 0-1 - Organization of System Safety Assessment Process

Hazard Log The Hazard Log database is a common living document that tracks all hazards associated with I-ETMS throughout the life-cycle of the system. The Hazard Log captures all system hazards, identifies associated risks (initial and residual) and their mitigations, and documents that all required mitigations have been successfully implemented in the system. The hazards are sourced from previous analyses including the Operations & Support Hazard Analysis (O&SHA), Preliminary Hazard Analysis (PHA), and Subsystem Hazard Analyses (SSHA). Other hazards are sourced during the review and testing of I-ETMS. As I-ETMS went through testing and Revenue Service Demonstration, phases, any newly identified hazards and their mitigations and risks were included and maintained in the Hazard Log database. The analysis of hazards and their mitigations identified in the Hazard Log database drove system design, training, maintenance, and warnings. To accommodate SCRRA’s specific implementation of I-ETMS, a tailored Hazard Log, an output from the common Hazard Log database, was developed to include any exceptions unique to SCRRA’s implementation of I-ETMS. These exceptions may include, but are not limited to, unique mitigations, residual risk, or mitigation references.



A database tool called RailRisk is in the process of being employed by SCRRA/Metrolink to track and input hazards from the system operation, currently Extended Revenue Service Demonstration, into the Hazard Log database. Risk Assessment (RA) The Risk Assessment provides an aggregate assessment of the residual risk of the I-ETMS system and determines whether the system has met the requirements of 49CFR §236 Subpart I. Risks associated with PTC system hazards are mitigated through a combination of design and procedural mitigations. The term residual risk is intended to mean the risk for a hazard present after all identified mitigations have been applied. To achieve a fully vital implementation, residual risks must be reduced to a probability of 1E-9 or better for all hazards of the system. The Risk Assessment provides the evaluation of the system hazards in this regard. As with any train control system, I-ETMS has a combination of vital and non-vital functions. Vital functions of I-ETMS include functions such as mandatory directive enforcement and penalty brake interface control. Examples of non-vital functions include PTC warnings provided to the crew and locomotive automatic horn control. Functions intended to be vitally implemented are assessed based on the quantitative MTTHE allocated to the subsystems in the context of the complete system. 49CFR §236, Appendix C compliance was analyzed from available evidence to assess the vital implementation. Non-vitally implemented functions are assessed qualitatively and, where possible, quantitatively, to demonstrate whether such functions are implemented in a manner consistent with 49CFR §236, Appendix C in the Risk Assessment contained in Appendix F of this PTCSP. The procedurally mitigated functions will be upgraded to vital implementation in the future as part of the “predefined changes” described herein in Section 6.2.2. Where human input to safety-critical functions is integral to the current operation of the system, evidence is assessed to determine whether human errors are adequately mitigated by either the I-ETMS system design or by operating rules and procedures. It is anticipated that future vital developments identified herein as “predefined changes” will eliminate the dependence on rules and procedures for safety. A detailed analysis of the human factors analyzed and the mitigation employed for each identified risk is included in Appendix F: I-ETMS Risk Assessment Report, and in Appendix D.1: OSCAR (Operating & Support Checklist Applicable to Railroads) Resolutions for Metrolink. External interfaces to I-ETMS are reviewed within the Risk Assessment in Appendix F to address whether these interfaces negatively impact the safety risk of the system. This specifically includes interface to systems such as Computer-Aided Dispatch (CAD),



Locomotive functions such as brake interfaces, speed determination via tachometers, location determination via GPS, etc., and wayside functions such as switch circuit control and signal illumination. The I-ETMS system is an overlay system, as opposed to a standalone system. Improvements in safety are demonstrated for compliance with 49CFR §236, Appendix C. Where residual risk is improved by the PTC system for the identified hazards, this is described both quantitatively and qualitatively, and where the PTC system provides no additional protection, it is assessed as to whether any new hazards have been introduced. The Risk Assessment asserts and then demonstrates that all required PTC functions of the onboard system are implemented vitally and in accordance with 49CFR §236, Appendix C requirements. Some functions of the PTC system that are used for safety-critical operations but are not implemented vitally are currently subject to additional procedural mitigations (identified through the Operations & Support Hazard Analysis). Future vital developments identified herein as “predefined changes” (See Section 6.2.2) will eliminate the dependence of the system on procedural mitigations. Platform Analysis The overall objective of the Platform Analysis, included as Appendix G.8, is to provide sufficient and comprehensive safety justification to demonstrate that the I-ETMS TMC design complies with the requirements of 49CFR §236 Subpart I, and specifically 49CFR §236, Appendix C regarding safety assurance principles of a segment of a vital overlay PTC system. In particular, 49CFR §236, Appendix C, Section C.3 provides a list of standards that are deemed acceptable for this purpose. IEEE 1483-2000 was selected as the compliance measure for the TMC Platform Analysis since it is widely used by equipment suppliers and represents current North American rail industry best practices for platform-level detailed design and safety analysis. The Platform comprises the specific underlying system functions and resources that the application-level functions of the onboard segment of PTC rely upon to execute those functions safely. These include: a. Location Determination b. Speed Determination c. Fail-Safe Processing of Target Generation and Enforcement d. Fail-Safe Brake Interface Control The Platform Analysis details the design elements employed to meet 49CFR §236 Appendix C requirements for each of these functions and substantiates the level of safety assurance references in the System Hazard Analysis for each of these Platform functions.



Results Summary SCRRA’s extensive testing program of I-ETMS and deployment and operation of the system in Revenue Service Demonstration service provides evidence that the I-ETMS system has been designed consistently with §236.1005 and does reliably execute the functions described therein. The 2727 nominal entries in the Hazard Log result in 1615 line items that are specifically being managed. The remaining 1112 entries are higher level hazards that are decomposed within the Hazard Log into the manageable specific hazards and mitigations or have been eliminated by design. Note that these specific numbers may vary depending on the specific release of the Metrolink Hazard Log, as it is a dynamic document. There are three classes of hazards that remain in the 1-C Residual Risk category, as defined in the AREMA Risk Categorization Table. See reference [22] for details.

• After Arrival Authority – I-ETMS utilizes a two button press (two separate buttons) to allow the crew to occupy the limits of their authority. This requires the crew to acknowledge that they have talked to each train and received verbal acknowledgment that each train has passed their location in addition to a final acknowledgment that all trains identified in the track warrant are past the current location. Future vital developments identified herein as “predefined changes” (See Section 6.2.2) will eliminate the dependence on procedural mitigations. SCRRA PTC territory is exclusively CTC. After Arrival Authority for trains is not used on Metrolink.

• Initial track Position – I-ETMS requires that the crew enter its initial position based on GPS location applied against the track database. Crews are presented with a list of possible solutions and “Unmapped Track”. Crews must establish initial position prior to departure from their initial terminal. Future vital developments identified herein as “predefined changes” (See Section 6.2.2.3) will eliminate the dependence on procedural mitigations for track selection..

• Work Zone Permissions – I-ETMS utilizes a two button press (separate buttons) to allow a crew access into the Work Zone. This requires the crew to acknowledge that they have talked to and received permission from the EIC and that the crew has verified the information. Future vital developments identified herein as “predefined changes” (See Section 6.2.2.5) will eliminate the dependence on procedural mitigations.

There are four classes of hazards that remain in the AREMA [22] 1-D Residual Risk category:

• Sensor Inputs – Individual Sensor Inputs are received and validated by the onboard system, thereby justifying the 1-D classification. Dissimilar sensors are used to create vital data. This process is detailed in the Platform Analysis.



• Highway Grade Crossing Warning System (HGCWS) Malfunction – I-ETMS utilizes a two button press (separate buttons) to proceed through an established bulletin placed over a HGCWS malfunction. This requires the crew to verify that the crossing is protected and that the proper number of flaggers are present and protecting the crossing. Future vital developments identified herein as “predefined changes” (See Section 6.2.2.2) will eliminate the dependence on procedural mitigations.

• Switch Position – Under failure conditions, crews are required to enter the Switch Position for non-communicating switches to maintain navigational needs. Exposure limits the crew input to a 1-D Residual Risk.

• Crew Editing of Consist – Metrolink configures I-ETMS such that crews are allowed to edit Consist data. Metrolink’s operating rules and training policies dictate that all consist changes must be entered by the crew and confirmed by the dispatcher. Allowing the crew to edit the Consist data only with dispatcher confirmation justifies the Residual Risk of 1-D for the hazards associated with Consist data. Future vital developments identified herein as “predefined changes” (See Section 6.2.2.1) will eliminate the dependence on procedural mitigations.

The Platform Analysis substantiates the vital implementation of the safety-critical Platform functions through evidence of compliance with 49CFR §236, Appendix C safety principles, and the Mean Time to Hazardous Event (MTTHE) performance achieved by the implementation of each function through the application of safety assurance concepts in the hardware and software design of the system. Through the Risk Assessment, those functions currently implemented with supplemental rules and procedures (termed non-vital functions) of the PTC system still have design mitigations that deliver improved safety by providing increased detection and correction of random failures such as corrupted or dropped messages. For those system functions unchanged by the PTC system, the qualitative assessment shows that the failure rates associated with those functions have been improved or made no worse by PTC implementation. The Risk Assessment also shows that the implementation of PTC functions, based on multiple sources of evidence contained in the PTCSP (System and Subsystem Hazard Analysis, Platform Analysis, Operational & Support Hazard Analysis, etc.), are consistent with 49CFR §236, Appendix C safety principles, and achieve as a minimum Undesirable MTTHE rates that can be made Acceptable with the explicit agreement of the stakeholders, as defined in the AREMA C&S Manual Part 17.3.5. The path for mitigating these undesirable MTTHE rates is explained in the “predefined changes” in Section 6.2.2 of this PTCSP.



1 Introduction

This PTC Safety Plan (PTCSP) is submitted pursuant to 49CFR 236, Subpart I, §236.1015 by Metrolink to meet the PTCSP requirements specified in Subpart I of 49CFR, Part 236 [6]. The Metrolink/SCRRA system is intended to be a “Vital Overlay” PTC system, employing fail-safe design as necessary to achieve the required level of safety.

1.1 Metrolink System Overview SCRRA is a Joint Powers Authority (JPA), created in 1991, and consisting of the five county transportation planning agencies of the Los Angeles County Metropolitan Transportation Authority (MTA), the Orange County Transportation Authority (OCTA), the Riverside County Transportation Commission (RCTC), San Bernardino Associated Governments (SANBAG) and the Ventura County Transportation Commission (VCTC). The goal in establishing SCRRA was to reduce the congestion on highways and improve mobility throughout the Southern California region. In October 1992, the commuter rail service known as Metrolink was established. The SCRRA, also referred to herein as Metrolink or Authority, provides commuter rail service to a five county area in Southern California. The commuter rail service operates on a network of over 249 route miles that are owned and operated by SCRRA and operates as tenant over 135 route miles that are owned and operated by the BNSF Railway (BNSF) and by the Union Pacific Railroad (UPRR). SCRRA is a host railroad for freight operations by the BNSF and UPRR, and for intercity passenger service conducted by Amtrak. SCRRA operates as a tenant into San Diego County on over 20 miles of the North County Transit District (NCTD). Refer to Figure 1-1 for an overview of the SCRRA service area. The Metrolink fleet includes diesel locomotives, trailer cars, and cab cars operating in a push-pull configuration. Metrolink’s operations are typically a push pull commuter railroad with short 4 to 6 coach car trains, one or two locomotives and a single locomotive engineer in the controlling compartment. All SCRRA locomotives and all operational cab cars are equipped for PTC operations. Three additional long term lease locomotives have been fully equipped for PTC operations and placed in service in December 2015. Metrolink is also in the process of incorporating forty (40) locomotive units leased from the BNSF into its operating fleet to temporarily replace cab cars that are being separately evaluated for crashworthiness. These lease locomotives are being modified to operate with PTC prior to entering revenue operations and will be placed into service on Metrolink during the 1st quarter of 2016.



Figure 1-1 System Map

SCRRA achieved its goal of placing PTC into Revenue Service Demonstration in the Los Angeles Basin by the summer of 2015. This is ahead of the December 31, 2015 deadline that was previously mandated by the Rail Safety Improvement Act of 2008. PTC implementation encompasses the core routes on the San Gabriel, Ventura, Valley, River, Orange and Olive Subdivisions that are owned and operated by SCRRA. Achieving this ambitious goal required working closely with the UPRR, BNSF, Amtrak, and the Federal Railroad Administration (FRA). The Metrolink host territory features mixed traffic including Metrolink, Union Pacific freight, BNSF freight and Amtrak intercity rail traffic. Metrolink tenant operations occur on the BNSF and UPRR freight system territory and NCTD commuter rail. While Metrolink is a commuter rail operation, there is significant freight rail activity over the SCRRA owned trackage, including a significant volume of transcontinental freight traffic originating and terminating at the Ports of Los Angeles and Long Beach and numerous yards and industrial leads. Additionally SCRRA operates as a host to and maintains approximately 75 miles of the Amtrak California Division of Rail Pacific Surfliner Corridor. This is the second busiest Amtrak inter-city corridor in the United States.



Metrolink host subdivisions, and other railroad subdivisions where it is a tenant, are all equipped with centralized traffic control and governed under GCOR railroad rules. There are no cab signals on the territory where Metrolink operates. As of the present, the ATS previously installed is still in service, but Metrolink will apply to FRA for its removal in the future. Active ATS is in service on approximately 50 miles of SCRRA where timetable speeds are up to 90MPH. Passive ATS inductors have been installed throughout the property where speed reductions are greater than 20 MPH. Metrolink does not currently operate at speeds greater than 79 MPH and its passenger tenants do not operate at speeds above 90 mph. There is no dark territory (non-signaled) on the Metrolink system. Metrolink operates with written mandatory directives (General Track Bulletins). There is no intention at this time to request electronic-only delivery of mandatory directives. Metrolink trains are operated by a one-person crew (Engineer) in the cab of locomotives and cab cars. The train conductor is located in the passenger compartments of the trains. Metrolink PTC is being deployed under the leadership of the Deputy Chief Operating Officer, PTC & Engineering, who is responsible for the entire system installation, testing, RSD, and eventual full revenue service. The Deputy Chief Operating Officer, PTC & Engineering is supported by a staff of organizational experts and technical experts from SCRRA who are charged with implementing the specific segments and overall system. SCRRA contracted with Parsons as a Vendor Integrator (V/I) for the supply and installation of the majority of PTC system components, and with Wabtec directly for the remaining PTC components. SCRRA itself was the integrator for the CAD system installation. The Metrolink PTC system is configured on the Wabtec I-ETMS® platform which is the same on-board system being installed on several Class I, and smaller, railroads, and includes those locomotives that are regularly interchanged between railroad properties. The PTC system on Metrolink is an interoperable Overlay system which is understood to be compliant with the recommended standards from the Interoperable Train Control (ITC) committee and its working groups. In most cases, these standards are codified under the Association of American Railroads (AAR) Standards and Specifications. The order in which Metrolink installed PTC on its subdivisions is:

1. San Gabriel 2. Ventura (including Montalvo) 3. Valley 4. Olive and Orange 5. River 6. Perris Valley (in progress for completion 1st half of 2016) 7. Short Way (scheduled to be acquired from BNSF in calendar year 2016). 8. Redlands (first mile) (future)



The interface to the PTC System begins at the Dispatch Center. As a first order of business necessary to support PTC operations, the Metrolink PTC program included the procurement, installation and commissioning of a replacement CAD system originally located in the existing Metrolink Operations Center (MOC). This facility also housed the back office system for PTC. Under a separate SCRRA project, a new Dispatching and Operations Center (DOC) has been designed and constructed in close proximity to the MOC. This new facility, equipped with the new CAD and PTC Back Office Server (BOS) systems, is designated as the primary Dispatch Center for SCRRA operations. The MOC has been re-configured as a first tier backup facility as well as the PTC system test laboratory. Metrolink is using licensed radio spectrum in the 220-MHz band for the PTC system. This spectrum is pooled with that of the BNSF and UPRR (through arrangements with PTC 220, LLC). The result from sharing RF infrastructure is an interoperable fixed radio system that serves the BNSF, UP, Amtrak, and Metrolink railroads that operate under PTC in the LA Basin. As a companion system, commercial and/or private “Cellular telephone” data radios are installed on trains with complementary fixed end connections between the “Cellular” service provider and the ground-based Metrolink network. Such an arrangement allows PTC RF communication between trains and the remainder of the PTC system in the event of failure, or as optimization of message distribution of all or part of the 220 MHz radio network. Each railroad operating in the LA Basin has made such arrangements with one or more cellular carriers to augment the radio communications should there be a problem with the 220 MHz network, or a need to transfer large amounts of data without unduly loading the radio network. In order to provide for projected long term growth and protect the PTC communications needs of the railroad, SCRRA is proactively pursuing acquisition and licensing of spectrum, from the secondary market. This 1 MHz of spectrum is located in the AMTS A band from 218.5 to 219.0 MHz and from 219.5 to 220.0 MHz. Metrolink utilizes microprocessor based vital wayside controllers manufactured by General Electric Transportation Systems (GETS) (now Alstom Transportation) for nearly all wayside signaling applications. Six relay based control points existed on Metrolink at the start of the PTC project on SCRRA. Three have been converted to full microprocessor control. The remaining three were converted to a hybrid – partial vital microprocessor with integrated WIU modules and partial vital relay control. GETS has provided a family of upgraded PTC compatible modules that serve as Wayside Interface Units (WIUs) to facilitate PTC interconnections. The installation of these modules and upgrades to existing equipment was undertaken separately from the large scale Vendor/Integrator (V/I) contracted work, in order to be in place to support the installation of the Back Office Server and communications infrastructure in a timely manner. These modules have been installed and placed into service on a schedule to facilitate PTC installation and commissioning on each



subdivision. The safety case for the GETS WIU can be found in Appendix V of this PTCSP. SCRRA completed an extensive mapping and surveying effort on the Metrolink property. SCRRA also provided the V/I with Geographic Information System (GIS) mapping of the Metrolink host service territory at a sub-meter resolution. This information was used for the on-board database programming. A Main Track Exclusion Addendum (MTEA) has been submitted and executed for the LA Union Station and is described in Section 24 of this PTCSP.

1.2 Use of the Terms “I-ETMS” and “PTC System” in this PTCSP

The term “I-ETMS®” is a trademarked name for the PTC system components developed by Wabtec Railway Electronics (WRE). However, throughout this document, the terms “I-ETMS” and “PTC system” are used interchangeably to refer to the I-ETMS®-based PTC system implemented by Metrolink that is the subject of this PTCSP. Although supported by the I-ETMS system design, Metrolink has no intention to utilize energy management systems on its locomotives.

1.3 Document Overview This Section 1 provides an overview of the SCRRA’s PTC Safety Plan for the implementation of a PTC system in accordance with the mandate of the RSIA08, and the requirements of the final regulations primarily consisting of 49CFR 236, Subpart I. This document consists of 37 main sections and 40 main appendices containing documents that are referenced by the PTCSP sections and support the safety case and analysis. The Appendices provide reference material and additional explanatory information required in order to fully demonstrate the SCRRA PTC System’s compliance with the FRA regulations. Tables 1-1 and 1-2 as included in this section provide a full listing of all the sections and a cross reference to all of the FRA regulations addressed by the PTCSP. This PTCSP contains examples of the operating, conceptual, design, implementation, verification and validation (V&V), and testing documentation that demonstrate the PTC system reliably executes the functions set forth in FRA §236.1005.

49CFR 236, Subpart I, §236.1005(a) establishes the requirements for PTC systems required to be installed under Subpart I. Each PTC system is required to:

1. Reliably and functionally prevent:

a. Train-to-train collisions - including collisions between trains operating over at-grade crossings of rail lines where the risk associated with such collisions is unacceptable in accordance with the table in 49CFR 236, Subpart I, §236.1005(a)(1)(i).



b. Overspeed derailments, including derailments related to railroad civil engineering speed restrictions, slow orders, and excessive speeds over switches and through turnouts.

c. Incursions into established work zone limits without first receiving appropriate authority and verification from the dispatcher or roadway worker in charge, as applicable and in accordance with Part 214.

d. Movement of a train through a main line switch in the improper position, as further described in paragraph (e) of 49CFR 236, Subpart I, §236.1005.

2. Include safety-critical integration of all authorities and indications of a wayside or cab signal system, or other similar appliance, method, device, or system of equivalent safety, in a manner by which the PTC system provides associated warning and enforcement to the extent, and except as, described and justified in the associated PTCDP or PTCSP.

3. Provide an appropriate warning or enforcement when:

a. A derail or switch protecting access to the main line required by 49CFR 236, Subpart I, §236.1007, or otherwise provided for in the applicable PTCSP, is not in its derailing or protecting position, respectively;

b. A mandatory directive is issued associated with a highway-rail grade crossing warning system malfunction as required by §§234.105, 234.106, or 234.107;

c. An after-arrival mandatory directive has been issued and the train or trains to be waited on has not yet passed the location of the receiving train;

d. Any movable bridge within the route ahead is not in a position to allow permissive indication for a train movement pursuant to §236.312; and

e. A hazard detector integrated into the PTC system that is required by §236.1005(c), or otherwise provided for in the applicable PTCSP, detects an unsafe condition or transmits an alarm.

4. Limit the speed of passenger and freight trains to 59 miles per hour and 49 miles per hour, respectively, in areas without broken rail detection or equivalent safeguards. Metrolink has no such areas in its PTC Territory.

This PTCSP contains the operating, conceptual, design, implementation, Verification & Validation (V&V), and testing evidence that Metrolink’s implementation of I-ETMS meets the functional requirements of 49CFR 236, Subpart I, §236.1005(a) and the additional PTC safety criteria as required by the 49CFR 236, Subpart I, and will perform these functions on an interoperable basis.



This PTCSP is intended to provide a high degree of confidence to FRA that the following actions have been taken in the design and delivery of I-ETMS per 49CFR 236, Subpart I requirements, and fulfills the safety assurance principles set forth in Appendix C of Part 236:

1. Industry-recognized standards have been utilized in the design and safety analysis.

2. Quantitative and qualitative data have been obtained using accepted methods associated with risk estimates; and were subjected to realistic cases of sensitivity analysis.

3. Proven design practices providing safe operation in previous applications have been incorporated. This includes earlier ETMS operations and BNSF FRA-certified I-ETMS operations.

4. Extensive analysis using multiple safety techniques has resulted in a complete list of faults to be mitigated, and the mitigations have been tracked through design, integration, V&V, system testing, and RSD.

5. Quantitative results have been utilized, where applicable.

6. Validation of the PTC System has included sufficient experiments and tests to identify uncovered faults in its operation, and all identified faults have been effectively addressed.

This PTCSP also includes the safety analyses and other documentation that support the conclusion that the SCRRA/Metrolink PTC system is safe and meets the PTC safety criteria required by the FRA and industry best practice. The SCRRA/Metrolink PTC system is intended to meet the requirements of 49CFR §236.1015(e)(2) for vital overlay PTC systems. The railroad, its consultants, and the PTC Vendor/Integrator team have accumulated the information herein to demonstrate that all of the four regulation-stated mishap hazards are prevented by the implementation of the PTC system. The I-ETMS® system concept has specific segments which provide vital or safety-critical implementation of functions, as listed below.

1. Locomotive Onboard segment - vital 2. Wayside Segment - vital 3. Back Office Server (BOS) segment – safety-critical

These segments are specifically described and their contributions to preventing the hazards stated in the FRA regulation §236.1005 are identified as part of the Hazard Analysis contained in Appendix G. The BOS segment is the subject of a predefined change to incorporate additional processing (See Section 6.2.2.9.2) which will support a claim of vital implementation.



Further, this document shows that the PTC system meets the requirements set forth in FRA §236.1007 paragraph (a) and §236.0(c)(1) for high-speed service. Where SCRRA or Amtrak passenger trains are operated in excess of 60 mph, but not greater than 90 mph, and/or BNSF or UPRR freight trains are operated in excess of 50 mph, the Metrolink PTC system provides, as it’s foundation, all of the safety-critical functional attributes of a block signal system meeting the FRA requirements, including appropriate fouling circuits and broken rail detection or equivalent safeguards. There are no plans to operate passenger trains at speeds greater than 90 MPH.

Document Section Contents 1.3.1

This PTCSP:

1. Directly follows the structure of 49CFR 236, Subpart I, §236.1015(d), beginning with PTCSP Section 9.

2. Incorporates by reference the Type Approved I-ETMS PTCDP under FRA-granted Type Approval: FRA-TA-2011-02;

3. Provides specific responses to all regulatory requirements for a PTCSP.

A summary of each of the sections of this PTCSP and their content is provided in Table 1-1.

Table 1-1 Summary of Section Contents

Section Summary of Section

Section 1 Introduction

Section 2 Applicable documents

Section 3 FRA Type Designation for the Metrolink PTC system intending to confirm the vital overlay designation and stating that the required features are met and / or are demonstrated in the PTCSP.

Section 4 Type Approval Reference

Section 5 PTCDP reference and identification of any variances as well as an attestation of compliance with the referenced PTCDP

Section 6 Description of Metrolink PTC system implementation and functions -

Section 7 Final human factors analysis as required by 49CFR 236 Subpart I §236.1013 (a)(5) and 49CFR 236 Subpart I §236.1015(d)




Section 8

Description of the safety assessment and whether these processes address the safety principles described in Appendix C to this part directly, using other safety criteria, or not at all as required by 49CFR 236 Subpart I §236.1015(d)(5), 49CFR 236 Appendix C, and §236.1015(e) as appropriate.

Section 9

Hazard log consisting of a comprehensive description of all safety-relevant hazards not previously addressed by the vendor to be addressed during the life cycle of the PTC system, including maximum threshold limits for each hazard as required by 49CFR 236 Subpart I §236.1015(d)(1).

Section 10

Safety Assurance Concepts describes the concepts that are used in the product design and an explanation of the design principles and assumptions as required by 49CFR §236.1015(d) (2) and 49CFR 236, Appendix C (b).

Section 11 Risk assessment of the as-built PTC system described as required by 49CFR 236 Subpart I §236.1015(d)(3) and Part 236 Appendix B (as revised.)

Section 12 Hazard mitigation analysis, including a complete and comprehensive description of each hazard and the mitigation techniques used as required by 49CFR 236 Subpart I §236.1015(d)(4).

Section 13 Description of the Verification and Validation processes applied to the PTC system and their results as required by 49CFR 236 Subpart I §236.1015(d)(5).

Section 14

Description of the railroad’s training plan for railroad and contractor employees and supervisors necessary to ensure safe and proper installation, implementation, operation, maintenance, repair, inspection, testing, and modification of the PTC system as required by 49CFR 236 Subpart I §236.1015(d)(6).

Section 15

Description of the specific procedures and test equipment necessary to ensure the safe and proper installation, implementation, operation, maintenance, repair, inspection, testing, and modification of the PTC system on the railroad and establish safety-critical hazards are appropriately mitigated. These procedures, including calibration requirements, shall be consistent with or explain deviations from the equipment manufacturer’s recommendations as required by 49CFR 236 Subpart I §236.1015(d)(7).




Section 16

Description of each warning to be placed in the Operations and Maintenance Manual identified in §236.919, and of all warning labels required to be placed on equipment as necessary to ensure safety as required by 49CFR 236 Subpart I §236.1015(d)(8).

Section 17 Description of the configuration or revision control measures designed to ensure that the railroad or its contractor does not adversely affect the safety functional requirements and that safety-critical hazard mitigation processes are not compromised as a result of any such change as required by 49CFR 236 Subpart I §236.1015(d)(9).

Section 18 Description of all initial implementation testing procedures necessary to establish that safety-functional requirements are met and safety-critical hazards are appropriately mitigated as required by 49CFR 236 Subpart I §236.1015(d)(10).

Section 19 Description of all post-implementation testing (validation) and monitoring procedures, including the intervals necessary to establish that safety-related functional requirements, safety-critical hazard mitigation processes, and safety-critical tolerances are not compromised over time, through use, or after maintenance (adjustment, repair, or replacement) is performed as required by 49CFR 236 Subpart I §236.1015(d)(11).

Section 20 Description of each record necessary to ensure the safety of the system that is associated with periodic maintenance, inspections, tests, adjustments, repairs, or replacements, and the system's resulting conditions, including records of component failures resulting in safety-relevant hazards (see § 236.1037) as required by 49CFR 236 Subpart I §236.1015(d)(12).

Section 21 Safety analysis to determine whether, when the system is in operation, any risk remains of an unintended incursion into a roadway work zone due to human error. If the analysis reveals any such risk, the PTCDP and PTCSP describe how that risk will be mitigated as required by 49CFR 236 Subpart I §236.1015(d)(13).

Section 22 More detailed description of any alternative arrangements as already provided under §236.1005(a)(1)(i) as required by 49CFR 236 Subpart I §236.1015(d)(14).

Section 23 Description of how the PTC system will enforce authorities and signal indications, unless already completely provided for in the PTCDP as required by 49CFR 236 Subpart I §236.1015(d)(15).




Section 24 Explanation of compliant MTEAs in practice for Metrolink at each MTEA location, per 49CFR 236 Subpart I, §236.1015(d)(16).

Section 25 Description of any deviation in operational requirements for en route failures as specified under §236.1029(c), if applicable and unless already completely provided for in the PTCDP as required by 49CFR 236 Subpart I §236.1015(d)(17).

Section 26 Description of how the PTC system integrates and will appropriately and timely enforce all integrated hazard detectors in accordance with § 236.1005(c) as required by § 236.1015(d)(18).

The description includes:

1. How hazard detectors integrated into the Metrolink signal or train control system on or after October 16, 2008 are integrated into Metrolink’s PTC system and are appropriately and timely enforced in accordance with 49CFR §236.1005(c)(1); and

2. How Metrolink’s PTC system provides for receipt and presentation of warnings from any additional hazard detectors to the locomotive engineer and other train crew members using the PTC data network, onboard displays, and audible alerts in accordance with 49CFR §236.1005(c)(2). The action taken by the system and the crew members is also described as applicable.

Section 27 Emergency and planned maintenance temporary rerouting plan indicating how operations on the subject PTC system will take advantage of the benefits provided under §236.1005(g) - (k) as required by 49CFR 236 Subpart I §236.1015(d)(19).

Section 28 Necessary requirements for operations over 90 MPH as required by 49CFR 236, Subpart I, §236.1005(c)(3), 49CFR 236, Subpart I, §236.1007(a), 49CFR 236, Subpart I, §236.1007(b), and 49CFR 236, Subpart I, §236.1015(d)(20)

Section 29 Communication and Security Requirements as required by 49CFR §236.1033

Section 30 Description of potential data errors and each risks mitigation as required by 49CFR §236.1015(h).




Section 31 Third party assessment is addressed based on the criteria set forth in 49CFR §236.913.

Section 32 PTC data maintained in locomotive event recorder per 49CFR §229.135.

Section 33 Process for Reporting Errors and Malfunctions per 49CFR §236.1023.

Section 34 Role of Office Automation Systems in the PTC system per 49CFR §236.1027(a).

Section 35 Novel technology employed in highway crossing protection for the PTC system per 49CFR §234.275(c).

Section 36 Listing of all Appendices

Section 37 Redaction Matrix for data in Appendices

As the correlation between this PTCSP document and the clauses in 49CFR 236, Subpart I is not always one-to-one, a cross-reference between the applicable Subpart I requirement and the relevant PTCSP Section, subsection, or Appendix is provided in Table 1-2.

Any change(s) to the Metrolink PTC system, or its PTC Implementation Plan (PTCIP), PTCDP, or PTCSP (this document) will only be made if SCRRA files a Request for Amendment (RFA) with the FRA to obtain authorization for the change(s), and then satisfactorily completes the changes.



Table 1-2 49CFR 236, Subpart I Cross-Reference from Regulation to PTCSP

Regulatory Reference Summary of Regulatory Requirement

Description of Regulatory Requirement PTCSP Section / Chapter Reference

§229.135(b)(3)(xxv)

Event Recorders format, content and proposed duration for retention of data

Refers to safety-critical train control data, with which the engineer is required to comply. The format, content and proposed duration for retention of such data shall be specified in the PTCSP. The format, content, and proposed duration for retention of such data shall be specified in the product safety plan or PTC Safety Plan submitted for the train control system under subparts H or I, respectively, of part 236 of this chapter, subject to FRA approval under this paragraph. If it can be calibrated against other data required by this part, such train control data may, at the election of the railroad, be retained in a separate certified crashworthy memory module.

32 Appendix X

§229.135(b)(4)(xxi)

Event Recorders format, content and proposed duration for retention of data

Refers to safety-critical train control data, with which the engineer is required to comply. The format, content and proposed duration for retention of such data shall be specified in the PTCSP.

32 Appendix X





§234.275(c)

Plan justification - must explain how the performance objective sought…

PTCDP or PTCSP must explain how the new and novel highway crossing protection performance objective sought to be addressed by each of the particular requirements of this subpart is met by the product, why the objective is not relevant to the product’s design, or how the safety requirements are satisfied using alternative means.

35 Appendix AA

§236.0(e)

RR may apply for approval of discontinuance or modification of a signal or train control system

…a railroad may apply for approval of discontinuance or material modification of a signal or train control system in connection with a request for approval of a Positive Train Control Development Plan (PTCDP) or Positive Train Control Safety Plan (PTCSP) as provided in subpart I….

ANY ACTION IS EXTERNAL TO

PTCSP

§236.1001(c)(2)

Subpart doesn’t exempt RR from A-H compliance unless in approved PTCSP

… subpart does not exempt a railroad from compliance with…subparts A through H … or parts 233, 234, and 235 …, unless the applicable PTCSP, as defined under § 236.1003 and approved by FRA under § 236.1015, provides for such an exception per § 236.1013.

Part 236 applicability is contained in

PTCDP which is included in Appendix

B of this PTCSP

§236.1005(a)(1)

PTC system prevents hazards Demonstrate that the PTC system will reliably and functionally prevent stated hazards

3, 6, 13 Appendix EE Appendix D Appendix J Appendix N Appendix FF





§236.1005(a)(1)(i)

Alternative arrangements to prevent train-to-train collisions

Specify alternative arrangement described in §236.1005(a)(1)(i) refers to rail to rail at grade crossings providing an equivalent level of safety in regards to train-to-train collisions, if applicable.

22

§236.1005(a)(2)

Include safety-critical integration of authorities and indications from wayside or cab

Include safety-critical integration of all authorities and indications of a wayside or cab signal system, or other similar appliance, method, device, or system of equivalent safety, in a manner by which the PTC system shall provide associated warning and enforcement to the extent, and except as, described and justified in the FRA approved PTCDP or PTCSP, as applicable;

3, 6 Appendix GG

PTCDP, Appendix

B, Section 11

§236.1005(a)(4)(i)

Derail or switch protecting access to the main line

A derail or switch protecting access to the main line required by § 236.1007, or otherwise provided for in the applicable PTCSP, is not in its derailing or protecting position, respectively;

3, 6 Appendix GG

The PTCSP for Metrolink does not need to address 236.1007 as no

high-speed operation over 90 mph is included.

§236.1005(a)(4)(v)

Hazard detection detects unsafe condition

A hazard detector integrated into the PTC system that is required by paragraph (c) of this section, or otherwise provided for in the applicable PTCSP, detects an unsafe condition or transmits an alarm;

26 Appendix Q





§236.1005(c)(1) Hazard detector integrated into a signal or train control system

Describes the appropriate and timely enforcement of warnings of integrated hazard detectors

26 Appendix Q

§236.1005(c)(2)

Additional non-integrated hazard detectors

Specifies actions to be taken by the system and crewmembers based on the receipt and presentation to the locomotive engineer and train crew of warnings generated as the result of any additional non-integrated hazard detectors.

26 Appendix Q

§236.1005(c)(3)

Hazard analysis for any new service conducted over 90mph

Describe the hazard analysis for operations over 90 miles an hour, to include hazards based on specific routes, the basis for decisions concerning hazard detectors and the manner in which such hazard detectors will be interfaced with the PTC system.

28 (Metrolink has no

operations over 90 mph)

§236.1005(d)(i), (ii)

Event recorder operation (Concerning the items of locomotive data to be archived to the FRA Event Recorder or an equivalent crash-hardened memory module, regardless of its configuration). Lead locomotive operating PTC must be equipped with an operative event recorder that shall record safety-critical train control data routed to the locomotive engineer’s display with which the engineer is required to comply, specifically including text messages conveying mandatory directives and maximum authorized speed.

32 Appendix X





§236.1005(d)(1)(iii)

Event recorders - How info will be displayed, examples, retention

Include examples of how the captured data will be displayed during playback along with the format, content, and data retention duration requirements specified in the PTCSP submitted and approved pursuant to this paragraph.

32 Appendix X

§236.1005(e)(3)

Switch position detection A PTC system required by this subpart shall be designed, installed, and maintained to perform the switch position detection and enforcement described in paragraphs (e)(1) and (e)(2) of this section, except as provided for and justified in the applicable, FRA approved PTCDP or PTCSP.

Contained in PTCDP/ Included in

Appendix B

§236.1005(e)(4)

Exceptions to the switch protection

Circuits or electronic equivalent shall be arranged so that any movement authorities less restrictive than those prescribed in paragraphs (e) (1) and (e)(2) of this section can only be provided when each switch, movable-point frog, or derail in the route governed is in proper position, and shall be in accordance with subparts A through G of this part, unless it is otherwise provided in a PTCSP approved under this subpart.

23

§236.1005(g) – (k)

Emergency and planned maintenance re-routing plan

Describes requirements for re-routing of trains based on PTC territory and the operation under planned maintenance or emergency conditions

27 Appendix R





§236.1006(a)

Each train operating on PTC track shall be controlled by equipped locomotive in accordance with PTCSP

Except as provided in paragraph (b) of this section, each locomotive, locomotive consist, or train on any track segment equipped with a PTC system shall be controlled by a locomotive equipped with an onboard PTC apparatus that is fully operative and functioning in accordance with the applicable PTCSP approved under this subpart.

3, 25

§236.1007(b)

Operations over 90 MPH Operations conducted for passenger trains at greater than 90 mph.



§236.1007(b)(1)

High Speed Rail Establishes that the system was designed and will be operated to meet the fail-safe operation criteria described in Appendix C for trains operating at over 90 mph.



§236.1007(c)

HSR operations over 125mph … A host railroad that conducts a freight or passenger operation at more than 125 miles per hour shall have an approved PTCSP accompanied by a document (‘‘HSR–125’’)…


operations at 125 + MPH)

§236.1007(c)(1)

HSR level of safety from operations over 5 yrs. prior to SP submission

…the system will be operated at a level of safety comparable to that achieved over the 5-year period prior to the submission of the PTCSP by other train control systems that perform PTC functions required by this subpart...







§236.1007(d)

HSR operations over 150mph …a host railroad that conducts a freight or passenger operation at more than 150 miles per hour, which is governed by a Rule of Particular Applicability, shall have an approved PTCSP accompanied by a HSR–125 developed as part of an overall system safety plan approved by the Associate Administrator



§236.1007(e)

Exemption from SP on HSR A railroad providing existing high-speed passenger service may request in its PTCSP that the Associate Administrator excuse compliance with one or more requirements of this section upon a showing that the subject service has been conducted with a high level of safety. (Trains operating at speeds over 150 mph)



§236.1009(d)(1)

Reference to PTCDP A PTC System Certification for a PTC system may be obtained by submitting an acceptable PTCSP. If the PTC system is the subject of a Type Approval, the safety case elements contained in the PTCDP may be incorporated by reference into the PTCSP, subject to finalization of the human factors analysis contained in the PTCDP.

5 Appendix B

§236.1009(d)(2)

PTCSP document overview Each requirement under §236.1015 shall be supported by information and analysis to establish the requirements of this subpart have been met.

(using this table, refer to the complete

PTCSP document that contains

sections responding to all parts of §236.1015)





§236.1015(a)

Must File PTCSP Before placing a PTC system … in service, the host railroad must submit to FRA a PTCSP and receive a PTC System Certification.

This PTCSP document is

submitted to FRA.

§236.1015(b) PTCSP may utilize Type Approval

Type Approval Reference 4.1 5.1

Appendix B

§236.1015(b)(1) PTCPVL Maintains a continually updated PTCPVL

pursuant to §236.1023 4

33.1 Appendix MM

§236.1015(b)(2) Shows supplier has appropriate Safety measures

Demonstrate Supplier has Quality Control System 4

§236.1015(b)(3) Provides applicable licensing info

Applicable Licensing Information 4 Appendix Y

§236.1015(c)(1) include PTCDP or Type Approval

PTCDP or TA incorporation 5 Appendix B

§236.1015(c)(2)(i) Document any variances from PTCDP

Variances in Operating conditions from description in PTCDP 5

§236.1015(c)(2)(ii) Or attest there are none Attestation of no variances in operating conditions from PTCDP 5

§236.1015(c)(3)

Attest system was built in accordance with DP and achieves level of safety

Attest that the system was otherwise built in accordance with the applicable PTCDP and PTCSP and achieves the level of safety represented therein.

5





§236.1015(d)

Include same info as in PTCDP, must include final human factors analysis

A PTCSP shall include the same information required for a PTCDP under §236.1013(a). If a PTCDP has been filed and approved prior to filing of the PTCSP, PTCSP may incorporate the PTCDP by reference, with the exception that a final human factors analysis shall be provided.

6 7

Appendix C

§236.1015(d)(1)

Hazard log A HL consisting of a comprehensive description of all safety-relevant hazards not previously addressed by the vendor to be addressed during the life cycle of the PTC system, including maximum threshold limits for each hazard (for unidentified hazards, the threshold shall be exceeded at one occurrence).

9 33

Appendix D

§236.1015(d)(2)

SACs A description of the safety assurance concepts used in the product design, including an explanation of the design principles and assumptions.

10 Appendix A





§236.1015(d)(3)

Risk assessment A risk assessment of the as-built PTC system described; Per 236.1015(e)(2) Vital overlay. A PTC system proposed on a newly constructed track or as an overlay on the existing method of operation and is built in accordance with the safety assurance principles set forth in Appendix C of this part must, to the satisfaction of the Associate Administrator, be shown to: (i) Reliably execute the functions set forth in § 236.1005; and (ii) Have sufficient documentation to demonstrate that the PTC system, as built, fulfills the safety assurance principles set forth in Appendix C of this part. The supporting risk assessment may be abbreviated as that term is used in subpart H of this part.

11 Appendix F

§236.1015(d)(4)

Hazard mitigation analysis A hazard mitigation analysis, including a complete and comprehensive description of each hazard and the mitigation techniques used;

12 Appendix F Appendix G

§236.1015(d)(5)

V&V description A complete description of the safety assessment and Verification and Validation processes applied to the PTC system, their results, and whether these processes address the safety principles described in Appendix C to this part directly, using other safety criteria, or not at all.

8 13

Appendix J Appendix N





§236.1015(d)(6)

Training plan A complete description of the railroad’s training plan for railroad and contractor employees and supervisors necessary to ensure safe and proper installation, implementation, operation, maintenance, repair, inspection, testing, and modification of the PTC system;

14 Appendix K

§236.1015(d)(7)

Test procedures for equipment installs, repair, operations, etc…

A complete description of the specific procedures and test equipment necessary to ensure the safe and proper installation, implementation, operation, maintenance, repair, inspection, testing, and modification of the PTC system on the railroad and establish safety-critical hazards are appropriately mitigated. These procedures, including calibration requirements, shall be consistent with or explain deviations from the equipment manufacturer’s recommendations.

15 Appendix L

§236.1015(d)(8)

Additional warnings A complete description of each warning to be placed in the Operations and Maintenance Manual identified in §236.919, and of all warning labels required to be placed on equipment as necessary to ensure safety.

16 Appendix BB





§236.1015(d)(9)

Configuration control A complete description of the configuration or revision control measures designed to ensure that the railroad or its contractor does not adversely affect the safety functional requirements and that safety-critical hazard mitigation processes are not compromised as a result of any such change;

17 Appendix O Appendix P

§236.1015(d)(10)

Initial implementation procedures

A complete description of all initial implementation-testing procedures necessary to establish that safety-functional requirements are met and safety-critical hazards are appropriately mitigated.

18 Appendix U

§236.1015(d)(11)

Post implementation procedures A complete description of all post-implementation testing (validation) and monitoring procedures, including the intervals necessary to establish that safety-related functional requirements, safety-critical hazard mitigation processes, and safety-critical tolerances are not compromised over time, through use, or after maintenance (adjustment, repair, or replacement) is performed;

19 Appendix W

§236.1015(d)(12)

Description of records to ensure system safety

A complete description of each record necessary to ensure the safety of the system that is associated with periodic maintenance, inspections, tests, adjustments, repairs, or replacements, and the system’s resulting conditions, including records of component failures resulting in safety-relevant hazards (see §236.1037)

20 Appendix L Appendix P





§236.1015(d)(13)

Safety Analysis A safety analysis to determine whether, when the system is in operation, any risk remains of an unintended incursion into a roadway work zone due to human error. If the analysis reveals any such risk, the PTCDP and PTCSP shall describe how that risk will be mitigated;

21 Appendix F

§236.1015(d)(14) Description of alternate arrangements made in 236.1005(a)(1)(i)

A more detailed description of any alternative arrangements as already provided under §236.1005(a) (1)(i).

22

§236.1015(d)(15)

PTC enforcement of authorities A complete description of how the PTC system will enforce authorities and signal indications, unless already completely provided for in the PTCDP;

23

§236.1015(d)(16) How does system comply with 236.1019(f)

A description of how the PTCSP complies with §236.1019(f), if applicable; 24

§236.1015(d)(17)

Deviation of op procedures for en route failures

A description of any deviation in operational requirements for en route failures as specified under §236.1029(c), if applicable and unless already completely provided for in the PTCDP;

25

§236.1015(d)(18)

Enforcement of Integrated hazard detectors

A complete description of how the PTC system will appropriately and timely enforce all integrated hazard detectors in accordance with § 236.1005(c);

26 Appendix Q





§236.1015(d)(19)

Emergency re-routing plan An emergency and planned maintenance temporary rerouting plan indicating how operations on the subject PTC system will take advantage of the benefits provided under §236.1005(g) – (k);

27 Appendix R

§236.1015(d)(20) High Speed Rail and Communications Security Documents

The documents and information required under §236.1007 and §236.1033. 28

29

§236.1015(d)(21) Locations for Repair of Failed PTC Apparatus

Identify where exchange or repair of failed PTC apparatus will take place 25

§236.1015(e)(2)(i)

Reliably execute functions in 236.1005

Reliably perform the functions stated in §236.1005 when employing a vital overlay PTC system

3 Appendix J Appendix N

Appendix GG

§236.1015(e)(2)(ii)

Sufficient documentation to demonstrate as built fulfills SACs

Compliance required with Appendix C, risk assessment may be abbreviated as defined in Subpart H.

8 10 11

Appendix A Appendix F





§236.1015(f)

Adequate data regarding safety impacts of proposed changes

The FRA may consider reliability and availability data in determining if the PTCSP adequately complies with section §236.1015(d). In any case, where the PTCSP lacks adequate data regarding safety impacts of the proposed changes, the Associate Administrator may request the necessary data from the applicant. If the requested data is not provided, the Associate Administrator may find that potential hazards could or will arise.

13.6 Appendix FF

§236.1015(g)

PTC system replacing an existing PTC system provides same level of safety as old version

When replacing existing certified PTC system: PTCSP establishes with a high degree of confidence that the new system will provide a level of safety not less than the level of safety provided by the system to be replaced.

N/A

§236.1015(h)

Potential data error identification and mitigation

Potential Data Errors: PTCSP must include a careful identification of each of the risks and a discussion of each applicable mitigation. In an appropriate case, such as a case in which the residual risk after mitigation is substantial or the underlying method of operation will be significantly altered, the Associate Administrator may require submission of a quantitative risk assessment addressing these potential errors.

30 Appendix D Appendix F





§236.1017(a)

Supported by independent 3rd party assessment

The PTCSP must be supported by an independent third-party assessment when the Associate Administrator concludes that it is necessary…

31

§236.1019(f)

MTEA, RR must certify that no changes have been made to PTCIP previously approved

Main Line Track Exceptions: No PTCSP—filed after the approval of a PTCIP with an MTEA—shall be approved by FRA unless it attests that no changes, except for those included in an FRA approved RFA, have been made to the information in the PTCIP and MTEA required by paragraph (b) or (c) of this section.

24

§236.1021(a)(1)

No changes as defined by this section to a PTCSP shall be made unless:

No changes, as defined by this section, to a PTC system, PTCIP, PTCDP, or PTCSP, shall be made unless the railroad files a request for amendment (‘‘RFA’’), and per §236.1021(a)(2) the RFA is approved by the Associate Administrator.

1.5

§236.1023(a) PTCPVL PTCPVL 4

33 Appendix MM

§236.1023(b)(1)

All contractual relationships with hardware and software vendors

Specify all contractual arrangements with hardware and software suppliers or vendors for immediate notification between the parties of any and all safety-critical software failures, upgrades, patches, or revisions, as well as any hardware repairs, replacements, or modifications for their PTC system, subsystems, or components.

33.2 Appendix P





§236.1023(c)(1)

Procedures for actions when notified of safety critical failure

Specify the railroad’s process and procedures for action upon their receipt of notification of safety-critical failure, as well as receipt of a safety-critical upgrade, patch, revision, repair, replacement, or modification.

Appendix P

§236.1023(c)(2)

Configuration management to ensure safety isn’t compromised as a result of a change

Identify configuration/revision control measures that are designed to ensure the safety-functional requirements and the safety-critical hazard mitigation processes are not compromised because of any change and that such a change can be audited.

17 Appendix P

§236.1023(e)

After in service, RR shall maintain database of all safety-relevant hazards

After PTC is in service, a database of safety-relevant hazards occurring in the system is to be maintained. If occurrence of a hazard exceeds a threshold limit, reporting shall be performed as per this regulation.

20 33

Appendix L Appendix P

§236.1023(e)(3)

Take prompt counter measures to reduce the number of safety-relevant hazards…

…take prompt counter measures to reduce or eliminate the frequency of the safety-relevant hazards below the threshold identified in the PTCSP.

20 Appendix L Appendix P





§236.1023(j)

When safety-critical PTC system fails to perform, RR shall take appropriate action

When any safety-critical PTC system, subsystem, or component fails to perform its intended function, the cause shall be determined and the faulty product adjusted, repaired, or replaced without undue delay. Until corrective action is completed, a railroad shall take appropriate action to ensure safety and reliability as specified within its PTCSP.

20 33

Appendix L Appendix P

§236.1027(a)

Role of Office Automation Systems

Any office automation system that performs safety-critical functions or directly controls the movements of a train in a PTC system is subject to the requirements of Subpart I

34

§236.1027(c)(4)

Primary train control systems cannot be integrated with locomotive electric system unless included in the PTCDP and PTCSP

Primary train control systems cannot be integrated with locomotive electronic systems unless the complete integrated systems…Are included in the approved and applicable PTCDP and PTCSP.

Metrolink locomotive electronic systems are independent

from the train control and I-ETMS PTC

systems.

§236.1029

Specify actions to ensure proper logging and correction of failures

Any failures in PTC equipment must be identified, logged, corrected, and normal service restored without undue delay. Actions to accomplish this are to be specified in the PTCSP.

20 25

Appendix L Appendix P Appendix W

§236.1029(a)

En route failures When any safety-critical PTC System component fails to perform its intended function,….,a railroad shall take appropriate action as specified in its PTCSP.

25 Appendix L Appendix R Appendix S





§236.1029(c)

Deviation of op procedures for en route failures

In order for a train equipped with PTC traversing a track segment equipped with PTC to deviate from the operating limitations contained in paragraph (b) of this section, the deviation must be described and justified in the FRA approved PTCDP or PTCSP, or the Order of Particular Applicability, as applicable.

25 Appendix L Appendix R Appendix S

§236.1031(d)

Previous approval or recognition of a train control system may be credited towards safety case

Previous approval or recognition of a train control system, together with an established service history, may,… be credited toward satisfaction of the safety case requirements… for the PTCSP with respect to all functionalities and implementations contemplated by the approval or recognition.

N/A – New PTC System

§236.1031(e)

Previously approved PTC system differing significantly

To the extent that the PTC system proposed for implementation under this subpart is different in significant detail from the system previously approved or recognized, the changes shall be fully analyzed in the PTCDP or PTCSP, as would be the case absent prior approval or recognition.

5.2

§236.1033(e)(2) Security information to protect data

All wireless communications must be protected by cryptographic means to assure message integrity and authentication.

29





§236.1033(f)

Service restoration and mitigation plan

Each railroad, or its vendor or supplier, shall have a prioritized service restoration and mitigation plan for scheduled and unscheduled interruptions of service. This plan shall be included in the PTCDP or PTCSP as required by §§ 236.1013 or 236.1015, as applicable.

25 27 29

Appendix EE

§236.1037(a)(1)

RR must maintain current copy of FRA approved Type Approval and PTCDP and SP it holds

Identified PTC-related records shall be maintained by the railroad as per regulation at designated location(s) on the railroad. Occurrence of hazards and incidents must be reported and corrective action taken.

20 Appendix L

§236.1037(a)(2)

Adequate documentation that PTCSP and PTCDP meet safety requirements

Each railroad with a PTC system… shall maintain at a designated office on the railroad: …Adequate documentation to demonstrate that the PTCSP and PTCDP meet the safety requirements of this subpart, including the risk assessment

20 Appendix L

§236.1037(b) Inspection results from tests specified in PTCSP and PTCDP

Results of inspections and tests specified in the PTCSP and PTCDP must be recorded pursuant to §236.110.

20 Appendix L

§236.1037(d)

After in service, RR shall maintain database of all safety-relevant hazards

After the PTC system is placed in service, the railroad shall maintain a database of all safety-relevant hazards as set forth in the PTCSP and PTCDP and those that had not been previously identified in either document. If the frequency of the safety-relevant hazards exceeds the threshold, set forth in either of these documents…

20 33

Appendix L





§236.1037(d)(2)

Take prompt counter measures to reduce the number of safety-relevant hazards…

Take prompt countermeasures to reduce the frequency of each safety-relevant hazard to below the threshold set forth in the PTCSP and PTCDP

20 Appendix L

§236.1037(d)(3)

Provide final report when inconsistency is resolved to Director, Office of Safety…

Provide a final report when the inconsistency is resolved … on the results of the analysis and countermeasures taken to reduce the frequency of the safety-relevant hazard(s) below the threshold set forth in the PTCSP and PTCDP.

20 Appendix L

§236.1039(a)

RR shall catalog and maintain all documents as specified in the PTCDP and PTCSP

All documents specified in the PTCDP and PTCSP related to operations and maintenance shall be located in one manual readily available to personnel required to perform such tasks.

15 20

Appendix L

§236.1039(c)

Operations and maintenance manual for hardware and software handling

Hardware software and firmware revisions must be documented …according to the railroad’s configuration management control plan and any additional …measures specified in the PTCDP and PTCSP

15 20

Appendix L

§236.1039(d) Operations and maintenance manual for safety critical components

Safety critical components …handled… in accordance with the procedures specified in the PTCDP and PTCSP

15 20

Appendix L

§236.1041(a)

Training program for PTC personnel

Employers shall establish and implement training and qualification programs for PTC systems…meet the minimum requirements set forth in the PTCDP and PTCSP in §236.1039 through §236.1045…

14 Appendix K





§236.1041(b)

Competencies Employer’s program must provide training for persons who perform the functions described in paragraph (a) of this section to ensure that they have the necessary knowledge and skills to complete their duties related to operation and maintenance of the PTC system.

14 Appendix K

§236.1043(a) Training Structure and Delivery The Employer shall, at a minimum…identify the specific goals of the training program…

14 Appendix K

§236.1043(a)(7) Require periodic refresher training as specified in PTCDP and PTCSP

Require periodic refresher training and evaluation at intervals specified in the PTCDP and PTCSP that includes …

14 Appendix K

§236.1043(b)

Training Records Employer shall retain records which designate persons who are qualified under this section until new designations are recorded or for at least one year after such persons leave applicable service. These records shall be kept in a designated location and be available for inspection and replication by FRA and FRA-certified State inspectors.

14 20

Appendix K Appendix L

§236.1045(a)

Training Specific to Office control Personnel

Any person responsible for issuing or communicating mandatory directives in territory where PTC systems are or will be in use shall be trained in the following areas, as applicable…Instructions concerning the interface between the computer-aided dispatching system and the train control system…

14 Appendix K





§236.1047(a)

Training for operating personnel Training provided under this subpart for any locomotive engineer or other person who participates in the operation of a train in train control territory shall be defined in the PTCDP as well as the PTCSP. The following elements shall be addressed: (1) Familiarization with train control equipment onboard the locomotive and the functioning of that equipment as part of the system and in relation to other onboard systems under that person’s control; (2) Any actions required of the onboard personnel to enable, or enter data to, the system, such as consist data, and the role of that function in the safe operation of the train; (3) Sequencing of interventions by the system, including pre-enforcement notification, enforcement notification, penalty application initiation and post-penalty application procedures; (4) Railroad operating rules and testing (part 217) applicable to the train control system, including provisions for movement and protection of any unequipped trains, or trains with failed or cut-out train control onboard systems and other on-track equipment; (5) Means to detect deviations from proper functioning of onboard train control equipment and instructions regarding the actions to be taken with respect to control of the train and notification of designated railroad personnel; (6) Information needed to prevent unintentional interference with the proper functioning of onboard train control equipment.

14 Appendix K

§236.1047(b)

Locomotive Engineer Training Training required for a locomotive engineer, together with required records

14 Appendix K





§236.1047(c)

Full automatic operation Special requirements in the event a train control system is used to effect full automatic operation of the train.

N/A

This PTCSP does not include provision

for full automatic operation

§236.1047(d)

Conductor Training Training required for a conductor, together with required records

14 Appendix K

There is no PTC training other than

PTC overview training for conductors.

Conductors on Metrolink trains have no additional duties that are PTC related

and are not stationed in the locomotive or

controlling cab.

§236.1049 Training specific to Roadway Workers

Training requirements specific to roadway workers

14 Appendix K

Appendix B(a) Risk metrics described The risk metric for the proposed product

must describe…risk … over the designated life cycle of the product.

11 Appendix F





Appendix B(b)

State reasons for departure of safety principals followed

The risk assessment … must account not only for the risks associated with each subsystem…but also for the risks associated with interactions between subsystems

11 Appendix F

Appendix B(d)(e)(f)

Risk assessment characteristics Subsystem parameters subsystem assessment

The enumerated system characteristics, relevant parameters for systems and subsystems, and assessment of processor-based subsystems and components must be defined as part of a risk assessment per regulation.

11 Appendix F

Appendix C(b)

Safety principals must be followed or explained in PTCSP

What safety principles must be followed during product development? The designer shall address each of the following safety considerations principles when designing and demonstrating the safety of products covered by subpart H or I of this part. In the event that any of these principles are not followed, the PSP or PTCDP or PTCSP shall state both the reason(s) for departure and the alternative(s) utilized to mitigate or eliminate the hazards associated with the design principle not followed.

8 10 13

Appendix C(b)(1)

System safety normal ops The system (all its elements including hardware and software) must be designed to assure safe operation with no hazardous events under normal anticipated operating conditions…

8 10 13





Appendix C(b)(2)(i) System safety under failure It must be shown how the product is

designed to eliminate or mitigate unsafe systematic failures…

8 10 13

Appendix C(b)(2)(ii) System safety under failure The product must be shown to operate

safely under conditions of random hardware failures.

8 10 13

Appendix C(b)(2)(iii) System safety under failure There shall be no single point failures in the

product that can result in hazards categorized as unacceptable or undesirable

8 10 13

Appendix C(b)(2)(iv)

System safety under failure If one non-self-revealing failure combined with a second failure can cause a hazard that is categorized as unacceptable or undesirable, then the second failure must be detected and the product must achieve a known safe state that eliminates the possibility of false activation of any physical appliance.

8 10 13

Appendix C(b)(2)(v)

System safety under failure If a common mode failure exists, then any analysis performed under this appendix cannot rely on the assumption that failures are independent

8 10 13

Appendix C(b)(3)

Closed Loop System design adhering to the closed loop principle requires that all conditions necessary for the existence of any permissive state or action be verified to be present before the permissive state or action can be initiated.

8 10 13





Appendix C(b)(4)

SACs The product design must include one or more of the following Safety Assurance Concepts as described in IEEE–1483 standard …

8 10 13

Appendix A

Appendix C(b)(4)(i-v)

SACs listed Design diversity and self-checking concept, Checked redundancy concept, N-version programming concept, Numerical assurance concept, Intrinsic fail-safe design concept.

8 10 13

Appendix A

Appendix C(b)(5)

Human factors engineering The product design must sufficiently incorporate human factors engineering that is appropriate to the complexity of the product…

8 10 13

Appendix C(b)(6)(i-iii) System safety under external influences

The product must be shown to operate safely when subjected to different external influences …

8 10 13

Appendix C(b)(7)

System safety after modification Safety must be ensured following modifications to the hardware or software, or both. Etc.

8 10 13

Appendix L

Appendix C(c) Acceptable standards for Verification and Validation

Specific standards must be met for Verification and Validation

8 Appendix H Appendix I



1.4 PTCSP Drafts Previously Shared with FRA

This PTCSP document has been developed with input from FRA, and draft materials have been shared with FRA to expedite discussion and final PTCSP review. All changes resulting from resolution of comments on prior submittals are incorporated in this version of the PTCSP.

1.5 Update of This PTCSP

Metrolink has an internal change management process which works through their Change Control Board to identify and implement changes throughout the system. As part of the change management process, changes are evaluated to determine whether they may impact other documents including the PTCSP. This PTCSP will be updated only in accordance with §236.1021(a).

1.6 Acronyms and Definitions

This section includes definitions of all common acronyms, abbreviations, and terms required to interpret the PTC Safety Plan. Table 1-3 contains a list of abbreviations and acronyms used in this document.

Table 1-3 Abbreviations and Acronyms

Acronym Meaning AAR Association of American Railroads ABS Automatic Block Signal System AEI Automatic Equipment Identification AMQP Advanced Messaging Queuing Protocol Amtrak National Railroad Passenger Corporation AREMA American Railway Engineering and Maintenance-of Way Association ATCS Advanced Train Control System ATS Automatic Train Stop AVPN AT&T Virtual Private Network BNSF BNSF Railway BOS Back Office Server CAF Change Authorization Form (Wabtec I-ETMS) CAD Computer Aided Dispatch CDR Critical Design Review CDRL Contract Deliverable Requirements List CDU Cab Display Unit (locomotive onboard) CFR Code of Federal Regulations CHMM Crash Hardened Memory Module CI Configurable Item CMF Central Maintenance Facility ConOps Concept of Operations



Acronym Meaning COT Current Of Traffic COTS Commercial Off the Shelf CRC Cyclic Redundancy Check CTC Centralized Traffic Control DIO Digital Input / Output (module) DOC Dispatching and Operations Center DOD Department of Defense DOP Dilution of Precision DT Double Track DTC Direct Traffic Control EBI Electronic Brake Interface EEPROM Electrically Erasable Programmable Read Only Memory EIC Employee in Charge (work crew) EMF Eastern Maintenance Facility EMP Edge Message Protocol EMT Enter Main Track FAA Federal Aviation Administration FAT Factory Acceptance Testing FFT Functional Fault Tree FIT Field Integration Test FIT-I Field Integration Test – Interoperable FMEA Failure Modes and Effects Analysis FQT Field Qualification Test FQT-I Field Qualification Test – Interoperable FRA Federal Railroad Administration FTA Fault Tree Analysis GCOR General Code of Operating Rules GE General Electric GETS General Electric Transportation Systems (now Alstom) GIS Geographic Information System GPS Global Positioning System HFA Human Factors Analysis HGCWS Highway Grade Crossing Warning System HL Hazard Log HMAC Hash Message Authentication Code HMI Human Machine Interface IC3 Individual and Composite CRC Calculator ICD Interface Control Document IEEE Institute of Electrical and Electronic Engineers I-ETMS® Interoperable Electronic Train Management System ( by Wabtec) I-ETMS I-ETMS®-based PTC system implemented by Metrolink that is the

subject of this PTCSP



Acronym Meaning IOC Input Output Concentrator (module) ITC Interoperable Train Control ITCM Interoperable Train Control Messaging IVS Independent Validation Server JRST Joint Rail Safety Team LA Los Angeles (California) LIEE Laboratory Integration End to End LIEE-I Laboratory Integration End to End – Interoperable LINN Laboratory Integration Nearest Neighbor LMR Locomotive Message Redirector LMS Locomotive Messaging Server LRU Lowest Replaceable Unit LSI Locomotive Systems Integration LSSHA Locomotive Subsystem Hazard Analysis MHz Megahertz MIS Management Information System MOC Metrolink Operations Center MPLS Multi-Protocol Label Switching MST Modify Stop Target MTBF Mean Time Between Failures MTEA Mainline Track Exclusion Addendum MTS Master Test Strategy MTTHE Mean Time to Hazardous Event NCTD North County Transit District (San Diego, CA) NMS Network Management System NYAB New York Air Brake OBS On Board System O & M Operation & Maintenance O&SHA Operation and Support Hazard Analysis OMM Operation and Maintenance Manual OSCAR Operating and Support Checklist Applicable to Railroads OSSHA Office Subsystem Hazard Analysis OTE On-Track Equipment PHA Preliminary Hazard Analysis PMP Project Management Plan PSA Platform Safety Analysis PSP Product Safety Plan (per FRA Subpart H) PSS Pass Signal at Stop PTC Positive Train Control PTCIP PTC Implementation Plan PTCDP PTC Development Plan PTCPVL PTC Product Vendors List



Acronym Meaning PTCSP PTC Safety Plan RA Risk Assessment RAM Reliability, Availability, and Maintainability RFA Request for Amendment RSD Revenue Service Demonstration RSIA08 Rail Safety Improvement Act of 2008 RSC Rail Safety Consulting RSM Router/Switch Module SAC Safety Assurance Concept SCIL Safety-Critical Items List (same as Hazard Log) SCRRA Southern California Regional Rail Authority SEMP Systems Engineering Management Plan SHA System Hazard Analysis SSHA Subsystem Hazard Analysis SSID System Safety Integration Document SSPP System Safety Program Plan Subpart H 49CFR 236 Subpart H Subpart I 49CFR 236 Subpart I TDMA Time Division Multiple Access TMC Train Management Computer TSR Temporary Speed Restriction TWC Track Warrant Control UPRR Union Pacific Railroad V&V Verification & Validation VDD Version Description Document VSWR Voltage Standing Wave Ratio WIU Wayside Interface Unit WRE Wabtec Railway Electronics WSRS Wayside Status Relay Service



Table 1-4 contains a list of definitions of safety terms used in this document.

Table 1-4 Definitions of Safety Terms

Term Definition Closed Loop Principle

System design adhering to the closed loop principle requires that all conditions necessary for the existence of any permissive state or action be verified to be present before the permissive state or action can be initiated. Likewise, the requisite conditions shall be verified to be continuously present for the permissive state or action to be maintained. This is in contrast to allowing a permissive state or action to be initiated or maintained in the absence of detected failures. In addition, closed loop design requires that failure to perform a logical operation, or absence of a logical input, output or decision shall not cause an unsafe condition, i.e. system safety does not depend upon the occurrence of an action or logical decision.

Fail-Safe A design philosophy applied to safety-critical systems such that the results of hardware failures or the effect of software error either shall prohibit the system from assuming or maintaining an unsafe state or shall cause the system to assume a state known to be safe. (IEEE-1483)

Host railroad

A railroad that has effective operating control over a segment of track.

Interoper- ability

The ability of a controlling locomotive to communicate with and respond to the PTC railroad’s positive train control system, including uninterrupted movements over property boundaries.

Metrolink LA Basin Regional Commuter Rail under the control of SCRRA. Safety-critical

A term applied to a system or function, the correct performance of which is critical to safety of personnel and/or equipment; also, a term applied to a system or function, the incorrect performance of which may result in an unacceptable risk of a hazard. (IEEE-1483)

Safety Validation

A structured and managed set of activities, including analysis and test, which show that the system, as specified and implemented, performs the intended functions and that those functions result in overall safe operation. Validation answers the question, “Did we build the right system?” (IEEE-1483)

Safety Verification

A structured and managed set of activities, including analysis and test, which show that the system, including its subsystems, interfaces and components, as designed and implemented, meets the allocated system safety goals and requirements. Verification answers the question, “Did we build the system right?” (IEEE-1483)

Tenant railroad

A railroad, other than a host railroad, operating on track upon which a PTC system is required.



Term Definition Vital Function

A function in a safety-critical system that is required to be implemented in a fail-safe manner. Note: Vital functions are a subset of safety-critical functions. (IEEE-1483)



2 Applicable Documents

The documents listed in this section either are referenced specifically from within this PTCSP or are listed as general resources to provide more information regarding a particular system safety subject. These referenced documents are not considered part of this PTCSP. Documents that form an integral part of this PTCSP are contained in Appendices A – NN.

Documentation on this list may be obtained from the standards body where appropriate, or from the publisher of the document.

[1] MIL-STD 882C, System Safety Program Requirements, 19 January 1993 with Notice 1, 19 January 1996.

[2] IEEE Standard 1483-2000, “Standard for the Verification of Vital Functions in Processor-based Systems Used in Rail Transit Control.”

[3] Congress of the United States. Rail Safety Improvement Act of 2008. Public Law 110–432. October 16, 2008.

[4] Federal Railroad Administration, US Department of Transportation. 49CFR Parts 228, 235, 236A thru 236G, Federal Railroad Administration, Rules, Standards, and Instructions for Railroad Systems.

[5] Federal Railroad Administration, US Department of Transportation. 49CFR 236 Subpart H, Standards for Development and Use of Processor-Based Signal and Train Control Systems; Final Rule, Docket Number FRA-2001-10160, 7 March 2005.

[6] Federal Railroad Administration, US Department of Transportation. 49CFR Parts 229, 234, 235, 236 Subpart I, “Positive Train Control Systems; Final Rule,” Docket No. FRA-2008-0132, Notice No. 3, 15 January 2010.

[7] 49CFR §234.211, “Grade Crossing Signal System Safety,” Subpart D, “Maintenance, Inspection, and Testing Maintenance Standards”, “Security of Warning System Apparatus” – 5 December 2005.

[8] 49CFR §229.135, “Railroad Locomotive Safety Standards,” “Event Recorders” – 15 January 2010.

[9] IEEE STD 1362-1998, “IEEE Guide for Information Technology—System Definition—Concept of Operations (ConOps) Document -Description”, IEEE Computer Society/Software & Systems Engineering Standards Committee, 22 December 1998.

[10] FRA-2006-23687-0017, “BNSF Railway – Product Safety Plan” Version 2.1; 12 October 2006.



[11] AAR Standard S-9362 “ITC Wayside-Locomotive ICD”.

[12] AAR Standard S-9501 “PTC Data Management Architecture”.

[13] AAR Standard S-9202 “ITC WIU Requirements”.

[14] AAR Standard S-9555 “Railroad Use of IEEE 802.1X and DHCP Services in Support of 802.11 Interoperability” V1.1 .

[15] <Reserved.>

[16] AAR Standard Set Section K-VI – “Railway Data Management and Communications”, ed. 2014.

[17] I-ETMS System Safety Plan, Wabtec Railway Electronics. 1/2011.

[18] <Reserved>

[19] AAR Standard S-9053 and S-9054 Positive Train Control ITC System Requirements, Level 0 and Level 1 V1.0 08/2014 .

[20] ARP-4761, Aerospace Recommended Practice, “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment”, December 1996.

[21] IEEE Standard 829-2008, “Standard for Software Test Documentation.”

[22] AREMA C&S Manual, particularly section 17.3.5.D.

[23] NUREG-0492 Fault Tree Handbook, January 1981.

[24] SCRRA Informational Filing and Testing Waivers for pre-certification PTC Testing per 49CFR 236.1035.

[25] I-ETMS Security Implementation Guide, Wabtec, Revision 1.2, 2/17/2012.

[26] FIPS-198, The Keyed-Hash Message Authentication Code (HMAC), National Institute of Standards and Technology, July 2008.

[27] NIST 800-107-2009, Recommendation for Applications Using Approved Hash Algorithms, National Institute of Standards and Technology, 2009.

[28] “METROLINK Timetable” Current Version.

[29] “GCOR - General Code of Operating Rules” 7th edition, effective date April 1, 2015

[30] SCRRA PTC Implementation Plan, Revision 1.7, April 30, 2014, as approved by FRA.



[31] Methodology for Initial Assessment of Spectrum Requirements and Required Numbers of Base Stations in a Multi-railroad, Dense Traffic Area, FRA Technology Grant No. FR-TEC-0004-11-01-00, report dated September 10, 2012.

[32] SCRRA Revenue Service Demonstration Application Version 2.0, 30 November 2014, as conditionally approved by FRA in letter to SCRRA dated February 13, 2015.

Note: For undated references, the most current edition applies.



3 Confirmation of FRA Type Designation for Metrolink PTC System [49CFR §236.1015(e)(2)]

I-ETMS has been specified and implemented with the intent of being a Vital Overlay PTC system on Metrolink as defined by 49CFR §236.1015(e). This PTCSP demonstrates the degree to which I-ETMS meets the FRA criteria set forth for a Vital Overlay PTC system:

1. This PTCSP shows that I-ETMS reliably executes the requirements for PTC systems set forth in 49CFR §236.1005.

2. This PTCSP, when combined with the PTCDP, demonstrates that I-ETMS has sufficient documentation to fulfill the safety assurance criteria and processes set forth in 49CFR 236, Appendix C.

3. This PTCSP contains a risk assessment of the as-built I-ETMS system as required by 49CFR §236.1015(d)(3).

3.1 Reliably Execute PTC System Functions of 49CFR § 236.1005 RSIA08, Sec. 104 requires the implementation of a Positive Train Control system “designed to prevent train-to-train collisions, overspeed derailments, incursions into established work zone limits, and the movement of a train through a switch left in the wrong position.” The Federal Railroad Administration’s regulation under 49CFR § 236.1005 further expands on the requirements of a PTC system.

3.2 Sufficient Documentation to Fulfill Appendix C Safety Assurance Principles Metrolink’s Safety Plan for I-ETMS includes analysis, documentation and expected results described in several standards for safety critical processor system development. Metrolink and its safety consultants relied on the best practices and standards of the Institute of Electrical and Electronics Engineers (IEEE), Department of Defense (DOD), Federal Aviation Administration (FAA), and American Railway Engineering and Maintenance-of-Way Association (AREMA) to ensure a disciplined and structured approach was applied to assessing the safety of this system. The standards for safety critical processor systems each call for specific documentation that:

Establishes system safety is both planned and integrated into the development of the system

Provides for managerial oversight to be applied to the development of the system and the resolution of any conflicts in development

Establishes safety requirements that are valid, clear, traceable feasible to implement, and verifiable

Identifies and documents potential hazards



Assesses risk of the system’s design and implementation Verifies, validates and documents risk reduction through certain

mitigations, and Provides for life cycle management of the system in operation to

insure its safe operation and the continued risk reduction from its application

Specifically, the I-ETMS PTC system was assessed relative to the allocation of safety-critical functions to one or more of the four defined segments of the system (Locomotive, Office, Wayside, and Communications). In addition to a quantitative assessment for Mean Time to Hazardous Event (MTTHE), qualitative assessment of these functions against 49CFR 236, Subpart I, Appendix C compliance was performed against the safety principles listed in paragraph (b) of that Appendix. Where human input to safety-critical functions is integral to the operation of the system, evidence was assessed to determine whether human errors are adequately mitigated either by the I-ETMS system design or by operating rules and procedures. External interfaces to I-ETMS were also addressed to determine whether these interfaces negatively affect the safety risk of the system. The documentation necessary to fulfill 49CFR 236, Appendix C Safety Assurance Principles is contained in the following documents, all included within this PTCSP:

Section 8 of this PTCSP I-ETMS Risk Assessment (RA) Appendix F I-ETMS Locomotive Segment Subsystem Hazard Analysis

(LSSHA) Appendix G.2 I-ETMS Office Segment Subsystem Hazard Analysis (OSSHA)

Appendix G.3 I-ETMS Operating and Support Hazard Analysis (O&SHA)

Appendix G.4 I-ETMS Platform Safety Analysis (PSA) Appendix G.8 I-ETMS System Hazard Analysis (SHA) Appendix G.9 I-ETMS Safety Assurance Concepts (SAC) Document Appendix A I-ETMS Hazard Log (HL) Appendix D

3.3 Justification of Non-vital Classification of the Communications Segment Metrolink asserts that all communications paths and networks used for PTC purposes are inherently non-vital, and that the I-ETMS PTC system compensates for this condition by providing end-to-end data protection sufficient to ensure that only correct receipt of the data transmitted will be used in the system under plausible error scenarios. This will occur regardless of the errors that can be introduced from the several communication linkages that are used to transmit a message, being either wired or wireless in nature.



As stated in I-ETMS PTCDP v.3 Section 6.4, the PTC system has been designed so that the communication segment is not critical for safety. Information is protected by Cyclic Redundancy Check (CRC) and the Locomotive Segment accounts for any loss of information by defaulting to the most restrictive state. I-ETMS uses a keyed Hash Message Authentication Code (HMAC) to provide cryptographic message integrity and authentication as required by 49CFR 236 Subpart I §236.1033 (a). HMAC is applied by I-ETMS to safety critical data in messages between the Locomotive, Wayside, and Office segments. This provides a high level of security through the detection of latent, corrupted/manipulated, or “spoofed” messages. Authentication and validation between the locomotive and other segments occurs when the HMAC included in the message (from the WIU or BOS) matches the HMAC independently calculated by the Locomotive Segment. I-ETMS discards any messages that do not pass HMAC validation. In addition, data exchanges between Locomotive, Wayside and Back office are protected with a 32 bit CRC, encrypted with hashing codes for authentication, encoded with data to verify source, validated for timeliness, and the information within is range checked.

Introduction 3.3.1Data communication systems cannot be depended upon to provide error-free transmission of data due to the many forms of interference and noise which may corrupt the content of data messages passed through them. One means of mitigating these errors is to provide a means of end-to-end message error detection as part of the design of the system which uses such communications paths and networks. End-to-end message security is found in I-ETMS where HMAC and CRC are employed for safety critical data messages. The result is that message protection applied in a safety-critical manner will relieve the system from relying on a certain level of correctness supported by the communications medium itself.

General Properties of Wired and Wireless Data Communication Systems 3.3.2Data communication systems provide a means of connecting other devices which must transfer data between or among them. A data transmitting device is connected to a data receiving device by a communication medium. In safety-critical systems, the received data must be a correct representation of the transmitted data for its proper use and the continuation of safe operation of the overall system. Data communication systems are significantly affected by error-causing sources that are not controllable by the design. These sources are often characterized as noise, transients, interference, or delay. The effect is that the data being transmitted is corrupted or delayed such that, when received at the destination, it no longer timely



represents the data originally introduced at the origin. To avoid attempting to provide an error-free path in light of these common corrupting sources, protections must be built into the overall system at the originating and receiving devices to eliminate the PTC system use of data which is not determined to be identical at transmitting and receiving locations.

PTC Design Strategy for Mitigation of Communication System Errors 3.3.31. Noise (corruption) protection and response. A scheme is needed for protection against a message being decoded and used when one or more bits of the message is corrupted. Such scheme must be able to protect the message under the worst case bit error rate for the set of datacomm channels that are used to carry the message. The data exchanges between onboard and WIU in the I-ETMS system are protected by CRC or HMAC codes appended to the message. The 32 bit CRC provides protection against errors which cause up to 32 bits to be corrupted. The radio channels being used have an estimated worst case bit error rate (BER) of 2%, and this is within the detection range of the 32-bit CRC code being used in I-ETMS. Other message protections can be added per the protocols used for transmission, but these are not considered as necessary for fully protecting the safety-critical payload. Only the directly applied I-ETMS “vital” CRC used for data protection is necessary for the vital data. 2. Protection against loss of data and response I-ETMS messaging methods each include the detection of loss of a received message within a time window, which is configurable in system settings. This detection is provided in the Office, Onboard, and Wayside segments which communicate over the Communications Segment. The detection method is to compare the calculated CRC with the transmitted CRC and determine if they are the same. If the same 32 bit CRC is received, the message is judged to be uncorrupted by the receiver from any given source in the communications segment. This process declares a message to be missing if not received in a timely manner. 3. Out of sequence message protection Each I-ETMS message contains a sequence number which is unique, and applied by the sending device. This sequence number is included in the vitally protected payload of the message. Sequence numbers increment for each transmitted message, so that receipt of the message with a non-incrementing sequence number is out of sequence and therefore not considered valid by the receiving device. The incremented values are consecutive and have a maximum value, after which the next sequence number begins with the first number of the sequence again. The



universe of sequence numbers is large, therefore the repeating cycles are long and not likely to be a limiting issue for a message’s proper receipt. 4, Stale data receipt protection Each I-ETMS message is time stamped at the sending device or segment. The time is included in the vitally protected payload of the message. The vitally protected payload is data in a message protected by a means of error detection upon receipt having an unsafe failure rate of 1E-9 or better. Since time is synchronized across the I-ETMS system using GPS clock(s), the delivery time interval can be calculated. To detect a stale message, the time of receipt is compared against the time sent, and this time difference cannot be greater than a preconfigured parameter or “time slot” called TBC175 (set to 14 seconds for interoperability), ensuring that the message is timely received.

Hazard Analysis of PTC Communications Systems 3.3.4This section supporting the non-vital status of the communications segment includes:

• A more detailed definition of the scope boundary of the PTC Communications Segment as it is being implemented

• A listing of the potential failures and errors that the Communications Segment can be readily exposed to

• A listing of the impacts of such failures as they could lead to threats to the PTC system

• An expanded discussion relative to each potential threat and the protection built into the PTC system to prevent such threats from being realized as hazardous events

Events in communications that could potentially lead to system hazards impacting PTC safety can be considered those that could occur while managing network capabilities over the life cycle (i.e., install, test, modify, repair, replace, …) or due to those introduced by the external environment such as physical environmental influences and interferences, or human user’s interacting with the operating system. A summary of a typical set of potential hazard events are provided in Table 3-1 below.

Table 3-1 Potential Communications Hazard Events

Potential Hazard Events (Communications Segment)

Attributable to Occurrences During

Network Activities over the Life Cycle (Normal

Condition)

Attributable to External Influences (including

Authorized/Unauthorized Users)

Equipment (HW/SW) Systematic Design Errors X

Channel Cross-talk X X



Potential Hazard Events (Communications Segment)

Attributable to Occurrences During

Network Activities over the Life Cycle (Normal

Condition)

Attributable to External Influences (including

Authorized/Unauthorized Users)

Equipment Damage (connections broken) X X Improper install of Antennas X

Cabling Errors X Random HW failures and degraded

performance X X Use of incorrect Tools and Instruments X

Incorrect HW/SW Repair or Replacement, Modification X X Electromagnetic or other Interference X Climate Effects (e.g., Sunspots, Lightning) X Excessive Loading on system transmissions (i.e. User loading) X Unauthorized access X

The next step in analyzing the impact of failure events that occur within the Communications Segment rests with the threat to safety that could be attributed to each failure occurrence. Table 3-2 illustrates a series of potential threats that need to be considered within the PTC system in order to preserve the overall level of system safety.

Table 3-2 Potential Threats

Potential Threats as a result of Communications Segment Failures Description

Communication Message Repetition Multiple copies of the same message are transmitted

Communication Message Deletion Message is not transmitted at all

Communication Message Insertion Spurious message is transmitted in place of proper message

Communication Message Re-sequencing Message is assigned an erroneous sequence number in place of the proper sequence number

Communication Message Data Corruption Content of the message is corrupted in transit

Communication Message Delay Message is not sent in the reserved time for transmission

Communication Message Spoofing Unsafe messages meeting security parameters are injected into the transmission medium maliciously



The following Table 3-3 presents a correlation of the failure events and their impacts as seen to be threats to the PTC system.

Table 3-3 Hazard Impacts vs. Failure Events in Communications

Potential Hazard Impacts (Communications Segment) >>>>

Msg Repetition

Msg Deletion

Msg Insertion

Msg Re- sequencing

Msg Corrup-tion

Msg Delay

Msg Spoofing

Failure Events Equipment (HW/SW) Systematic Design Errors

X X X X X X X

Channel Cross-talk X X X X Equipment Damage (connections broken) X X X Improper install of Antennas X X Cabling Errors X X X X X Random HW failures and degraded performance

X X X X X X X

Use of incorrect Tools and Instruments X X X X X X X

Incorrect HW/SW Repair or Replacement, Modification

X X X X X X X

Electromagnetic or other Interference X X

Climate Effects (e.g., Sunspots, Lightning) X X Excessive Loading on system transmissions (i.e. User loading) X X

Unauthorized access X X X X X X X

It is seen from Table 3-3 that various communication failures can potentially cause the listed system hazard events. The hazards are mitigated by specific characteristics of the I-ETMS system design as detailed below. The result is that the analysis shows no unaddressed hazards require the communication segment to provide a mitigation. Message Repetition – mitigated by sequence numbering which detects repeated messages (those that have a non-incremented sequence number) and ignores the repeated message. Vitality is managed by the I-ETMS Locomotive Segment TMC software which confirms proper message sequencing, timeliness and duplication detection of received messages.



Message Deletion – mitigation by the receiver detecting a lack of message in a given time slot for receipt. Action is to treat the message as missing and take a safe action. Message currency detection and restrictive actions taken are managed by the I-ETMS Locomotive Segment TMC vital software. Message Insertion – an inserted message will usually not have the proper sequencing but if it does, the content of the message, including addressing and CRC serve as mitigations for accepting the message erroneously. Vitality is managed by I-ETMS Locomotive Segment TMC software which confirms sequencing, timeliness and lack of duplication of received messages. Message Re-sequencing – a message with the wrong sequencing will be rejected by the receiver and treated as a lack of proper message, thereby mitigating the hazard. Vitality is managed by I-ETMS Locomotive Segment TMC software which confirms sequencing, timeliness and lack of duplication of received messages. Message Corruption – any corruption up to the limit of detection of the CRC applied to the message, which is 32 bits or 2E-32 probability of being undetected will be mitigated and the corrupted message rejected by the lack of match between transmitted CRC and receiver calculated CRC. Detection of corrupted received messages is performed by the vital received message decoding process within the I-ETMS Locomotive Segment TMC. Message Delay – a time slot is reserved for receipt of a message. Messages which are delayed beyond the slot reserved will conflict with the following message causing a corrupted message which is detected by the CRC applied by the receiver. Vital message processing performed by the Locomotive Segment TMC software detects message contents that have exceeded a “time to live” resulting in rejection of old, stale or delayed message content. Message Spoofing – Message spoofing is a hazard which is difficult to mitigate because a malicious source can generate a valid message including addressing, sequencing, and CRC protection. However, such spoofed message must be injected at the proper time to replace another message with the exact same parameters and data which cannot be detected after receipt as being incorrect for the current situation and therefore rejected by the post-processing of the message. Such probability is sufficiently low that the message will be rejected on receipt. Any collision between the spoofed message and a proper message will corrupt both messages and therefore be detected. Vital message processing by the Locomotive Segment TMC software is designed to detect and reject instances of message repetition, deletion, Insertion, re-sequencing, corruption and delay; where several of these failures would need to occur on a simultaneous and continual basis in order for a spoofed message reception to be erroneously accepted as correct.



Therefore this hazard analysis shows that the hazard from an undetected erroneous message is negligible when the mitigations at the receiver are considered. The vital software within the Locomotive Segment TMC uses triplex processors which incorporate the ability to detect and reject invalid messages (as revealed above) that are transported over, received and processed via the Communications Segment

Resulting Lack of Dependence on Error-Free Performance of 3.3.5Communication System

The provision of error detection coding as part of the transmitted message reduces the probability of corruption being undetected and is proportional to the strength of the error detection code and inversely proportional to the length of the data payload being transmitted. The I-ETMS PTC system uses the CRC and HMAC error detection codes.

Conclusion 3.3.6Due to the protections for data being communicated that are built into the transmitting and receiving devices, it is concluded that there is no safety-critical dependence on performance of the Communications Segment of an I-ETMS PTC system. Conformance of the Communication Segment with 49CFR 236, Appendix C is therefore not required to be shown for this segment. Errors and other corruption introduced into the communications network or path have no specific impacts on the correct transmission and reception of the intended data that cannot be detected and mitigated by the devices at either end of the communications path. Therefore, the I-ETMS PTC system can operate using the available PTC system communication media without being concerned about the data errors caused by the communications media itself.



4 Type Approval Reference [49CFR §236.1015(b)]

This section identifies the Type Approval that has been issued to I-ETMS, and establishes that Metrolink has met the requirements of §236.1015(b) to reference and utilize this Type Approval in this PTCSP by:

1. Maintaining a continually updated PTCPVL pursuant to §236.1023;

2. Showing that the supplier from which they are procuring the PTC system has established and can maintain a quality control system for PTC system design and manufacturing acceptable to the Associate Administrator. The quality control system must include the process for the product supplier or vendor to promptly and thoroughly report any safety-relevant failure and previously unidentified hazards to each railroad using the product; and

3. Providing the applicable licensing information.

4.1 Type Approval Referenced and Utilized in This PTCSP

The following Type Approval has been issued by the Associate Administrator for the I-ETMS system and is utilized in this PTCSP in accordance with 49CFR 236, Subpart I: FRA-TA-2011-02. This was submitted as “Interoperable Electronic Train Management System (I-ETMS®) Positive Train Control Development Plan (PTCDP)”.

The Type Approval is contained in Appendix B of this PTCSP.

4.2 PTC Product Vendors List (PTCPVL) [§236.1015(b)(1)]

Metrolink maintains a continually updated PTCPVL pursuant to §236.1023 as required by 49CFR §236.1015(b)(1). The PTCPVL is further described in Section 33.1 of this PTCSP and is shown complete in Appendix MM of this PTCSP.

4.3 PTC System Vendor Quality Control System [§236.1015(b) (2)]

The suppliers from whom Metrolink procured its PTC system have established and maintain a quality control system for PTC system design and manufacturing. As discussed in Section 8.6, safety audits have been conducted on behalf of SCRRA. SCRRA’s expectation is that the Associate Administrator will find the vendor quality control systems to be acceptable. The quality control system includes the process for the suppliers to promptly and thoroughly report any safety-relevant failure and previously unidentified hazards to each railroad using the product.



4.4 Applicable Licensing Information [§236.1015(b) (3)]

Contractual agreements have been established with the suppliers of safety-critical hardware and software of the system components for immediate notification of any and all safety-critical software upgrades, patches, or revisions for their safety-critical processor-based signal and train control system. These licenses are identified in Table 4-1.

Also included in this notification are the reasons for such a change and any interim remediation for an identified hazard that can affect the intended purpose of the safety-critical processor-based signal and train control system. A ll contractual agreements with suppliers of safety-critical hardware and software have the following contractual language (or similar):

1. Upon receipt of a report of any safety-critical failure to their Product, Vendor shall promptly notify Metrolink and all other railroads that are using that Product, whether or not Metrolink or any other railroads have experienced the reported failure of that safety-critical system, subsystem, or component.

2. The notification from Vendor to Metrolink or any other railroad shall include explanation from the Vendor of the reasons for such notification, the circumstances associated with the failure, and recommended mitigation actions to be taken pending determination of the root cause and final corrective actions

3. All failure occurrences of a safety critical nature associated with vendor equipment that could lead to a system hazard, requires that the vendor communicate the identified issue and its expected resolution actions and schedule to Metrolink without undue delay after discovery.

Table 4-1 Metrolink Licenses for PTC

Vendor Product Form of License Wabtec TMDS License & Maint Support I-ETMS License & Maint Support Wabtrax Software License & Maint Support MeteorComm Radio technology License & Maint Support Lilee Comms equipment License & Maint Support Maint Support Corys Train simulator License & Maint Support GETS WIU and accessories License & Maint Support RHEL/MRG Linux License & Maint Support Cisco Routers License Oracle Linux License & Maint Support CalAmp Radios License Maint Support Mentum Radio modeling software License & Maint Support Crystal Software License PTC 220 LLC Frequencies Lease ITC/I-ETMS I-ETMS Governance Fujitsu SONET Communications License



Vendor Product Form of License ATT Cellular technology AVPN includting maint.

support Verizon Cellular Technology IP Data lines PIP MPLS Fed. MPLS Sprint Cellular Technology Fed. MPLS Various Mtn Top Sites Lease Solarwinds Network Management

System License & Maint Support

OmniStar GPS reference service License per hy-rail (3)

Note that I-ETMS as a system is not protected by trademark.

An AVPN license is an AT&T Virtual Private Network license.

A governance license means that ITC/AAR maintains control over the contents of I-ETMS systems using its various committees and teams to standardize certain behaviors of the system.

MPLS is Multi-Protocol Label Switching.

Fed. is Federated. A Federated MPLS is a network conforming to the AAR/ITC standardized communications requirements for PTC.



5 PTCDP Reference and Identification of Any Variances [§236.1015(c)]

As required by 49CFR §236.1015(c), this section:

• Includes by reference the FRA approved PTCDP and the FRA issued Type Approval,

• Documents each variance, including the significance of each variance between the Metrolink PTC system and its applicable operating conditions as described in the PTCDP from that as described in this PTCSP, and attests that there are no other such variances, or

• Attests that there are no variances between the PTC system and its applicable operating conditions as described in the applicable PTCDP from that as described in this PTCSP, and

• Attests that the Metrolink PTC system is otherwise built in accordance with the referenced PTCDP and this PTCSP and achieves the level of safety represented herein.

5.1 PTCDP and Type Approval References [§236.1015(c) (1)]

I-ETMS provides the core technology and functionality for the Metrolink PTC system. The I-ETMS PTCDP, “Interoperable Electronic Train Management System Positive Train Control Development Plan (I-ETMS® PTCDP),” is hereby incorporated in this PTCSP by reference per 49CFR 236, Subpart I, §236.1015(d). The required final human factors analysis is provided in Section 7 of this PTCSP. The Type Approval and PTCDP are provided in Appendix B of this PTCSP.

5.2 Any Variances from PTCDP (Type Approved) [§236.1015(c) (2)(ii)]

This PTCSP is being submitted for System Certification per the current I-ETMS PTCDP which is Type Approved. Metrolink is documenting the following functions of the I-ETMS system which have been revised in the current Type Approved PTCDP and are used on the I-ETMS System being deployed by Metrolink for System Certification. Metrolink attests that there are no variances to the approved PTCDP. However, Metrolink has utilized several PTC functionalities, blended with the existing dispatching system, to facilitate operations. These are addressed below.

In addition to identifying recent developments reflected in the latest version of the Type Approved PTCDP, this PTCSP includes future implementations of PTC functions with full PTC control to improve the performance of all functions. The predefined changes so identified are found under Section 6.2.2 of this PTCSP.



Enter Main Track at Signal in Lieu of Electric Lock Location 5.2.1

Additional acknowledgements to Enter Main Track at Signal in Lieu of Electric Lock locations have been added to the PTCDP in section 5.6.5.2.6. These additional acknowledgements promote situational awareness and help to mitigate the hazard of the crew Entering Main Track without the Signal in Lieu of the Electric Lock being cleared for their movement. Refer to Appendix K: Metrolink Training Plan; Attachment “Operating Crew Training Course” for further details.

For this function, Metrolink is already using a PTC-governed solution. The dispatcher issues permission to enter main track from the CAD system. After receiving permission, the train crew member aligns the switch. The signal in lieu of an electric lock is monitored, and if the signal displays Approach or Restricting, the train is allowed to proceed. If the signal does not display Approach or Restricting, then the onboard system makes the train wait ten minutes before being allowed to proceed at Restricted Speed.

As elaboration of this function as currently implemented, refer to section 5.6.5.2.6 in the referenced PTCDP. The predefined changes for vital implementation are identified in Section 6.2.2 of this PTCSP.

Malfunctioning Highway Grade Crossing Warning System 5.2.2

Additional acknowledgements for the protection of Malfunctioning Highway Grade Crossing Warning Systems have been added to the PTCDP. These additional acknowledgements promote situational awareness and help to mitigate the hazard of the train crew erroneously acknowledging that a crossing is protected. These prompts require the locomotive engineer to indicate whether the crossing is protected or not. Once the locomotive engineer indicates that the crossing is protected, additional prompting is presented requiring the locomotive engineer to indicate the number of properly equipped flaggers present at the crossing.

As elaboration of the function as currently implemented refer to section 5.6.8 in the PTCDP. The predefined changes for vital implementation are identified in Section 6.2.2 of this PTCSP.



Clarification of Wayside Status Relay Service (WSRS) 5.2.3

Figure 5-1 WSRS Architecture

The WSRS, which is part of the Communications segment, enhances functionality by providing the mechanism for the forwarding of wayside status messages to the locomotive via the Office Segment. Wayside locations are configured to forward their WIU Status messages to the WSRS, through the Messaging System. The arrangement is shown in Figure 5-1. A Locomotive Message Redirector (LMR) application runs on each Locomotive Messaging Server (LMS). This application monitors all message traffic entering the LMS. Once it detects Beacon On of WIU Status messages, the LMR sends a copy of this message to the WSRS via the Messaging System. Once a Beacon On or WIU Status message is received by a locomotive, the WSRS immediately forwards the status of the wayside in question to the locomotive. The locomotive also is dynamically subscribed to that wayside and will receive any subsequent updates to the WIU Status for that wayside.

Work Zone Protection 5.2.4

An additional acknowledgment to confirm that verbal permission to proceed through a work zone has been added to I-ETMS in the latest PTCDP. This additional acknowledgement is intended to promote situational awareness and to help mitigate unintentional acknowledgment by the train crew.



As elaboration of the function as currently implemented, refer to section 5.6.7 in the PTCDP. The predefined changes for vital implementation are identified in Section 6.2.2 of this PTCSP.

Update of Hazard Risk Index for I-ETMS to AREMA C&S Manual, Part 5.2.517.3.5

The Hazard Risk Index is used for establishing a required level of integrity based on predicted severity of identified hazards. The Hazard Risk Index used for I-ETMS is shown in Figure 5-2 - Hazard Risk Index, taken from the AREMA C&S Manual, Part 17.3.5, as also specified in the current Type Approved PTCDP V3 as Figure 21.

The suggested criteria in Figure 5-2 imply that certain SCRRA official(s) must determine whether a task is acceptable by review. With regard to the SCRRA system, such review would be performed by a team of high-level SCRRA management convened by the Deputy Chief Operating Officer, PTC & Engineering, or a higher level official. The team consensus would determine the acceptability of the item with a relevant residual risk stated as the Hazard Risk Index.

Figure 5-2 Hazard Risk Index, AREMA C&S Manual, Part 17.3.5

Technique for Passing Non-communicating Signal 5.2.6

By utilizing the back office initiated functionality that is available for Pass Signal at Stop (PSS), Metrolink has addressed the operating condition when a wayside PTC signal is



not communicating, and it is being treated by the On-board segment as a Stop Signal. There are occasions when an absolute signal in the field is displaying a proceed indication, yet the train is held at stop by the on-board segment due to a failure in the communications system. Given the constraints of the Metrolink dispatching practices, there is no way for the train to get past the signal other than cutting out PTC, or placing the signal to Stop and issuing a Pass Signal at Stop (PSS) command. Neither of these options is acceptable. Cutting out PTC removes the safety overlay. Placing a signal at stop removes the protection of the signal system after expiration of the locking time, and is therefore not a desirable condition. In order to move the train past a controlled wayside signal that is displaying a proceed indication, but being treated by the on-board segment as a Stop signal, the Modify Stop Target (MST) process was created in the dispatch system. When a train crew reports an absolute signal is displaying a proceed indication but the train is prevented by the PTC system from passing the signal, the dispatcher pulls down a menu and initiates the MST function. The MST message is transmitted to the train where it is interpreted in the same manner as the PSS message, thereby triggering display of a message prompt on the CDU to which the train engineer is required to respond in order to allow the train to proceed at Restricted Speed past the wayside signal to the next signal. In the case of an intermediate signal, if it is not communicating, regardless of the indication displayed, it is treated as if it is at its most restrictive state – Restricted Proceed and movements must be made at restricted speed

5.3 Attesting to Compliance with Referenced PTCDP [§236.1015(c)(3)]

Metrolink attests that the PTC system was built in accordance with the current PTCDP and this PTCSP, and achieves the level of safety represented herein.



6 Metrolink PTC System Implementation [§236.1013(a), §236.1015(d)]

This section of the PTCSP includes the same information required for a PTCDP under §236.1013(a) as required by §236.1015(d). The PTCDP associated with Metrolink’s PTC system has been filed and type approved prior to the filing of this PTCSP and is incorporated by reference. A final human factors analysis as required by 49CFR 236 §236.1015(d) is also included in this PTCSP. The additional elements required by 49CFR §236.1015(d)(1) through §236.1015(d)(21) are provided in Section 8 through Section 29 of this PTCSP.

This section also provides a description of Metrolink’s application of I-ETMS to its operating environment.

6.1 Information Required for PTCDP Under §236.1013(a) Incorporate PTCDP by Reference 6.1.1

The I-ETMS PTCDP, “Interoperable Electronic Train Management System Positive Train Control Development Plan (I-ETMS® PTCDP),” has been filed and approved prior to filing this PTCSP, and is hereby incorporated in this PTCSP by reference per 49CFR §236.1015(d). The PTCDP is contained in Appendix B of this PTCSP along with the Type Approval document.

I-ETMS System Safety Integration Descriptions 6.1.2

The referenced PTCDP describes the manner in which the PTC system architecture satisfies safety requirements. An additional document, the “System Safety Integration Document (SSID)”, provides further detail on the system functions and the specific safety requirements allocated to each safety-critical function. The SSID is provided in Appendix GG of this PTCSP.

Final Human Factors Assessment 6.1.3

Pursuant to 49CFR §236.1015(d), a final human factors analysis is discussed in Section 7 and provided in Appendix C of this PTCSP.

6.2 Metrolink Application of I-ETMS The following subsections describe Metrolink’s specific application of the I-ETMS in fulfillment of 49CFR 236, Subpart I, §236.1015(d) requirement to include 1013(a) information. I-ETMS is a system that increases the safety of the railroad by providing situational awareness and eliminating unsafe train operations. I-ETMS warns the crew about predicted violation of movement authority limits, signal indications, speed limits, work zones, and monitored switch alignments, and applies a full-service brake application to



preempt violation by a locomotive of its authority, non-compliance with speed limits or signal indications, or operation through a misaligned switch. I-ETMS system is comprised of four primary subsystem segments: • The back office segment • The locomotive segment • The wayside segment • Communication segment Figure 6-1 provides a simplified overview of the interconnected system and the segments of I-ETMS that comprise the Metrolink PTC. Note that the communication segment is based on a “ring” topology for the backbone, with a variety of backbone switch nodes connected to the fixed field locations of communications equipment.

Figure 6-1 Overview of Metrolink I-ETMS PTC System

Metrolink-Specific Implementation of Functions 6.2.1

Table 6-1 lists the I-ETMS functions described in the referenced PTCDP, identifies the applicable System Safety Integration Document (SSID) references, provides summaries of the functions as described in the PTCDP, identifies the segments responsible for that function, and describes how the functions are performed within the Metrolink operating environment. The SSID references identify where a detailed discussion of the safety requirements associated with each function can be found. The specific implementation details capture any railroad-specific implementation of that function on the Metrolink’s



property. The SSID Document itself is contained in Appendix GG of this PTCSP. Tenant locomotives will operate on a common I-ETMS platform with Metrolink’s system and accordingly will behave the same as host locomotives for all interoperable functions. Where Metrolink has qualified the function with specific implementation details in the table, the function implementation is further defined in the subsections that follow.

The designation of each function as “safety critical” or “non-safety critical” was included in the PTCDP in table 6 (section 5.2.1). The designation was determined by review of the hazard analysis contained in Appendix G of this PTCSP and the risk assessment contained in Section 11 of this PTCSP.

All I-ETMS requirements are assigned a safety integrity level of safety critical, safety related or non-safety related. Some of the safety-critical requirements are assumed to be implemented using vital design criteria. These 3 levels, and the associated criteria, are defined in AREMA C&S Manual 17.3.5.D [22], part of which is repeated here for convenience.

“a. Products or systems that identify at least one hazard that could lead directly to a mishap are Safety Critical.

b. Products or systems which do not lead directly to a mishap but which may significantly increase the overall risk of a mishap are Safety Related.

c. Products or systems that have no safety implications are Non-Safety Related.”

Some functions in the table are identified as “safety critical.” The assessment of the safety criticality of PTC functions was performed in compliance with the definition of safety critical provided by 49CFR 236 Subpart I, which states, “As applied to a function, a system, or any portion thereof, means the correct performance of which is essential to safety of personnel or equipment, or both; or the incorrect performance of which could cause a hazardous condition, or allow a hazardous condition which was intended to be prevented by the function or system to exist.” AREMA C&S Manual 17.3.5.D (2011) [22] was also used in classifying these functions.

Table 6-1 discusses functionality introduced by the I-ETMS system. The underlying wayside signaling system, including the integrated WIU module inside the vital microprocessor has been demonstrated as Subpart A through G compliant, for instance application programs for vital microprocessor programs have equations which will not allow signals to display an indication more permissive than the most restrictive indication displayed at a location, nor will they allow switches to be powered or approach circuits to be energized until minimum conditions are satisfied and a minimal time expires.

Additional detail on the classification process is provided in the “System Safety Program Plan” included in Appendix HH of this PTCSP. The functions which did not conform to the FRA and AREMA definition of “Safety Critical” were then designated as “Non-Safety-Critical”. Review of the “non-safety-critical” functions was then performed by



Wabtec and several railroads, who were not able to identify any aspects of these functions for which incorrect performance would result in an unacceptable risk.

Additionally, the System Safety Integration Document in Appendix GG of this PTCSP includes a description of each function, and the associated safety considerations.



Table 6-1 I-ETMS Functions from the PTCDP

PTCDP Function1 SSID Reference Functional Description Metrolink Specific

Implementation PTC System Segment(s)

Power Up and Diagnostics (Safety Critical)

Section 2.0 • I-ETMS Power Up and Diagnostics functionality includes internal system tests executed to ensure the system is functioning as intended and ready to proceed to Initialization.

• Common with SSID document

Locomotive, wayside, office,

Initialization (Safety Critical)

Section 3.0 • Initialization occurs when a train crew arrives onboard or at the start of an I-ETMS equipped train's trip over an I-ETMS track segment.

• Initialization with multiple railroads, if required, occurs during the Initialization process.

• The I-ETMS Initialization process includes software version and configuration file verification, crew authorization, consist verification, Train ID verification, identification of intended route of a train based upon Train ID, and an I-ETMS Departure Test, if required.

• Authentication Service

Locomotive

Train Consist (Safety Critical)

Section 7.0 Train consist information is displayed to the crew for viewing and modification prior to confirmation of accuracy.

• Initialization • Crew updates

Locomotive

File Download (Safety Critical)

Section 5.0 Software, Configuration, and Track Files are capable of being downloaded from the Office Segment to the Locomotive Segment.

• Common with SSID - Mobile Device Manager (MDM) as a functional component of the BOS

Locomotive, Office

1 Functions are listed in Section 5.1, Table 4 of the referenced PTCDP.





Departure Test (Safety Critical)

Section 4.0 The I-ETMS Departure Test includes the execution of a series of tests, including a penalty brake application, to ensure the system is operational prior to departure.


Locomotive

I-ETMS System Synchronization (Safety Critical)

Section 6.0 • Synchronization of data between the Office Segment and the dispatching system is managed with a message exchange protocol between systems to minimize synchronization problems and ensure detection of those synchronization problems that occur. Upon occurrence of a message exchange protocol violation or other anomaly, that leaves the dispatching system or Office Segment incapable of positively assuring all data is synchronized, the Office Segment downgrades from its most permissive explicit control-operating mode to a more restrictive non-explicit control-operating mode.

• I-ETMS detects data discrepancies between the Office Segment and the Locomotive Segment through “heartbeat” messaging protocol. Detection of an anomaly causes I-ETMS to attempt to resynchronize data and to disengage if the data anomaly could impact the train at its current location.

• A configurable time tolerance threshold is set to allow for detection of a data synchronization failure between a Wayside Segment device and the Locomotive Segment. Failure to receive an update within the threshold period causes I-ETMS to assume the wayside device is in its most restrictive state. The configurable variable is identified in Appendix LL of this PTCSP. A lso see PTCDP sections 5.5.6 and 5.5.7


Office, locomotive, wayside





Location Determination & Navigation (Safety Critical)

Section 8.0 • The I-ETMS Location Determination function resolves a train’s location to mapped track.

• I-ETMS Location Determination function provides a means of selecting the train’s location when multiple track solutions may be available.

• The I-ETMS Navigation function calculates the train’s route when moving.

• I-ETMS provides defined system and display behavior to safely handle situations where the Locomotive Segment is unable to locate the train on surveyed track.


Locomotive





Warning and Braking Calculation (Safety Critical)

Section 9.0 • The Locomotive Segment continuously monitors train speed and proximity to speed restrictions or authority limits (considered zero-speed restrictions) in advance of the train.

• The Locomotive Segment establishes a train’s route and authorized speed profile.

• The Locomotive Segment uses train data and track profile data from the track data base to establish a known to be conservative braking curve based on current train configuration, an “if brakes were applied now” brake profile. Data from brake testing is used to confirm the algorithm.

• The Locomotive Segment accounts for any acceleration or deceleration and calculates an “if brakes were applied in N seconds2 brake profile which is combined with the predicted distance traveled in those N seconds to provide the warning distance.


Locomotive

2 The nominal value of “N” is determined by several common configurable parameters defined by the industry, the current settings of which are listed here: Train Type Predictor Curve Nominal

Warning Time Value in seconds

Range

Freight and Intermodal TBC132 75 0-180 Passenger, High-Speed Passenger, and Tilt Train

TBC257 30 0-180

Commuter TBC258 30 0-180





Territory Entrance Protection (Safety Critical)

Section 15.0 • I-ETMS provides warning and enforcement protection at an entrance to territory where I-ETMS is in effect. • Territory Entrance protection

requires that I-ETMS be initialized and fully active in advance of approaching the territory boundary at a distance sufficient to allow stopping at the boundary from the train’s current speed.


Locomotive

Protection of Movement Authority provided by Mandatory Directive in ABS or Non-ABS Territory (Safety Critical)

Section 12.1 • I-ETMS protects train and engine movement in accordance with movement authority held by the train or engine and enforces on-track authority limits and any restrictive conditions imposed upon the authority.

• The text of a movement authority is displayed by the Locomotive Segment upon request.

• Movement authority provided by mandatory directive is delivered to the Locomotive Segment while the train or engine is enroute or after Initialization.

• Metrolink has no TWC territory (non CTC) which is equipped with PTC.

Office, locomotive

Temporary Speed Restriction Protection (Safety Critical)

Section 11.2 • Predictive enforcement of Temporary Speed Restrictions (TSR) by I-ETMS accounts for all attributes of a TSR including time in effect and applicability to entire train or head-end only.

• The text of a TSR is displayed by the Locomotive Segment upon request.

• TSR data is delivered to the Locomotive Segment while the train or engine is enroute or after Initialization.

Form A Track Bulletin delivered via General Track Bulletin or by en-route form

Office, locomotive





Work Zones Protection (Safety Critical)

Section 11.3 • I-ETMS predictively protects temporal and spatial work zone limits with warning and ultimately enforcement upon failure to obtain permission before entering or moving within the limits of the work zone.

• I-ETMS reactively enforces unauthorized train or engine movements within the limits of active work zones.

• The presence and location of the work zone are continuously displayed to the train crew, even after the train crew has indicated authority to enter its limits.

• The text of a Work Zone bulletin is displayed by the Locomotive Segment upon request.

• Work Zone data is delivered to the Locomotive Segment while the train or engine is enroute or after Initialization.

• Form B Track Bulletin delivered via general Track Bulletin. • Train crew

acknowledges receipt of verbal permission to enter the Work Zone.

• Train crew confirms receipt of verbal permission to enter the Work Zone.

• Common with SSID document.

Office, locomotive





Advisory or Cautionary Notices Protection (Safety Critical)

Section 11.4 • Advisory or Cautionary Notices contain non-enforceable textual data provided by the dispatching system to advise train and engine crew members of changes in operating rules or practices, changes to the physical track structure or hazards that may exist along the wayside.

• Advisory or Cautionary Notices are displayable by the Locomotive Segment upon request.

• Advisory or Cautionary Notices are delivered to the Locomotive Segment while the train or engine is enroute or after Initialization.

• Common with SSID document, except Metrolink uses Form C.

Office, locomotive





Protection of Notice of Highway Crossing Warning System Malfunction (Safety Critical)

Section 11.5 • I-ETMS protects the limits of a rail-highway crossing upon receipt of a mandatory directive that is associated with a failure or false activation of the crossing warning system. • As each train approaches and is

within Stopping distance for the speed traveled the highway crossing, a specific manual input indicating that flagging protection has been established may be provided, causing I-ETMS to allow that train to move through the crossing in accordance with the restrictions prescribed by the applicable operating rules. The restriction remains in effect for each subsequent train approaching the highway crossing.

• The text of a Notice of Highway Crossing Warning System Malfunction by Mandatory Directive is displayed by the Locomotive Segment upon request.

• Notice of Highway Crossing Warning System Malfunction is delivered to the Locomotive Segment while the train or engine is enroute or after Initialization.

• Form X Track Bulletin delivered via General Track Bulletin or by en-route form. (GCOR 6.32.2)

• Train crew acknowledges that the crossing is protected.

• Train crew confirms the number of flaggers providing protection as 0, 1, or 2.

• Common with SSID document.

Office, locomotive





Protection of Notice of Track Out of Service (Safety Critical)

Section 11.6 • I-ETMS predictively protects the limits of an out of service track until the track is restored to service and the corresponding Notice of Track Out of Service Bulletin is voided and delivered to the Locomotive Segment.

• The text of a Notice of Track Out of Service Bulletin is displayed by the Locomotive Segment upon request.

• Notice of Track Out of Service is delivered to the Locomotive Segment either while the train or engine is en-route or after Initialization.

Form O Track Bulletin delivered via General Track Bulletin or by en-route form.

Office, locomotive

Critical Alert Protection (Safety Critical)

Section 11.7 I-ETMS protects any enforceable limits contained in Critical Alert notifications. Wayside detectors that are integrated with the signal system are enforced per FRA regulations. Defect detectors with voice radio broadcast are for on-board defects, such as dragging equipment, hot boxes, etc., and are not termed critical alerts • The text of Critical Alerts is displayed

by the Locomotive Segment upon request.

• Critical Alert notifications may include enforceable limits or text only and are delivered to the Locomotive Segment while the train or engine is enroute or after initialization. When enforceable limits are included in the critical alert, I-ETMS will enforce them as specified. When no enforceable limits are included, the text of the critical alert may be displayed, but no enforceable conditions are specified.


Office, locomotive, wayside





Permanent & Equipment Speed Enforcement (Safety Critical)

Section 19.0 • I-ETMS provides enforcement of the following defined speed limits: o permanent speed limits,

including turnout speed restrictions, as defined in the Timetable [28] or Special Instructions; and

o Consist, equipment, or lading speed restrictions as delivered during Initialization or entered directly by the train crew.

• I-ETMS predictively enforces permanent speed restrictions in advance of the train, with a warning consisting of a visual alert accompanied at the start by a momentary 3 audible alert prior to enforcement. The alert will indicate that the train will not be in compliance with the upcoming PSR.

• I-ETMS reactively enforces over speed conditions by providing audible and visual alerts (no specific duration)4 during an over speed event until the enforcement threshold is reached or train speed is reduced to comply with the speed limit.


Locomotive

3 The momentary audible alert at the start of predictive warning is two beeps defined as follows: 1. When sounding a beep sequence, the on-board segment shall sound a 2900 Hz tone for 90 ms followed by a 20 ms gap, followed by a 2900 Hz tone for 60

ms. 2. When sounding a multiple beep sequence, the on-board segment shall separate each beep sequence by a 240 ms gap. Note that the audible alert is NOT sounded continuously during the enforcement.





Wayside Signal Indication Enforcement (Safety Critical)

Section 13.0 • I-ETMS predictively enforces signal indications requiring a stop, and signal indications requiring reduced or restricted speed with a warning consisting of a visual alert accompanied at the start by a momentary audible alert prior to enforcement

• The Wayside Segment will beacon switch and signal data to the Locomotive Segment peer-to-peer.

• Metrolink aspects are mapped to signal enforcement groups

Wayside, locomotive

4 The audible and visual alerts serve to remind the operator to manage the train accordingly. Regardless of the operator response to those alerts, the system will act safely to prevent an over speed event, so “sufficient duration” doesn’t really play into the safety case. For predictive enforcements, the nominal duration is determined via the table answered in the footnote above





Switch Protection (Safety Critical)

Section 17.0 • In non-signaled territory, I-ETMS protects equipped train movement over monitored switches [switches that interface directly to a Wayside Interface Unit (WIU) device] by enforcing a stop before the train moves over a switch whose position is unknown or improperly lined for the movement to be made. In some cases, hand-operated switches in non-signaled territory will be interconnected with track circuits. When a track circuit indicates the conditions in the block are not favorable, all switches are assumed to be in improper position for train movement and enforcement of Restricted Speed throughout the block is provided accordingly.

• In signaled territory, I-ETMS provides protection for monitored switches whose alignment is unknown, and for monitored switches whose alignment is inconsistent with the train's current authority.

• The Wayside Segment will beacon switch and signal data to the Locomotive Segment peer-to-peer.

• Common with SSID document. SCRRA has no non-signaled territory.

Wayside, locomotive

Track Circuit Enforcement (Safety Critical)

Section 18.0 I-ETMS predictively enforces the limits of track circuits, which indicate a condition such as a broken rail or occupancy by another train. I-ETMS reactively enforces restricted speed within the limits of a track circuit indicating such a condition.

Used for switch protection in dark territory – not Applicable for SCRRA/Metrolink territory where all territory is signaled.

Wayside, locomotive





Reverse Movement Enforcement (Safety Critical)

Section 16.0 For a train making a reverse movement, I-ETMS provides enforcement of signal indications, authority limits, and permanent or temporary speed restrictions in accordance with the applicable Metrolink operating rules from GCOR [29]. See also PTCDP section 5.6.5.5.


Locomotive

Restricted State Enforcement (Safety Critical)

Section 20.0 Restricted State is a Locomotive operational state to allow the train to primarily perform switching work on a controlled track in a practical manner under restricted speed enforcement without requiring the system to be completely disengaged or cut-out.

• Metrolink does not use the Restricted State.

Locomotive

Notification of Authority Violation by another Train (Non-Safety Critical)

None • Violation report of authority violation is sent to the Office Segment.

• Office Segment forwards the violation report to all Locomotives whose clearance includes the subdivision/district where the violation report originated. These are called “violated” trains.

• Locomotive Segment warning to the violated train is provided for violations detected behind the violated train.

• Locomotive Segment warning and braking are provided to the violated train for violations ahead of the violated train.

• Functional description to be followed as shown.

There is no PTC mechanism to respond to the failure of another train in I-ETMS, therefore it is not safety critical to the currently referenced train.

Locomotive, communication, office





Crew Authority Requests (Non-Safety Critical)

Section 12.1.8

• Crew may request new, rollup, time extension, and release of authority limits.

Common with SSID document

• If the crew requests an authority, it is not a safety critical function

• If the crew fails to request an authority, it does not exist and will not be executed.


Cut-Out State (Non-Safety Critical)

None • In the event of a critical failure, the Locomotive Segment is able to be electrically isolated until repaired or replaced. Therefore it will not provide any control of operation of the train.

• Common with description at left.

Locomotive

Territory Exit (Non-Safety Critical)

None • I-ETMS provides notification at exit from territory where I-ETMS is in effect.


Locomotive

Horn Activation (Non-Safety Critical)

None • The Locomotive Segment provides automatic horn activation in the event that a locomotive engineer fails to sound the horn in approach to a public highway grade crossing when required.

• Metrolink has selected the configuration parameter to provide continuous blast (not sequenced). Sequenced operation not used.

Locomotive





Parking Brake (Non-Safety Critical)

None • The I-ETMS parking brake function provides a means, which may be used in addition to other methods required by rule or law, to secure the locomotive and train from unintended movement.

• When the parking brake function is invoked, the locomotive is monitored for movement and when nominal locomotive movement is detected for a period in excess of a threshold time, the Locomotive Segment commands a full-service penalty brake application.

This functionality has been tested on Metrolink trains and is operational. • The parking brake

failure may cause an enforcement but such is not guaranteed from a safety perspective.

Locomotive





Train Handling and Energy Management Assistance (Non-Safety Critical)

None • Through an optional interface with Energy Management software suites (e.g. NYAB LEADER® or GE’s Trip Optimizer™), the I-ETMS system supports the display of an operating profile for fuel efficient operation of the train based upon terrain, train dynamics, speed restrictions, and the train’s authority limits.

• In prompting mode, the Locomotive Segment displays Energy Management information locomotive control setting prompts in designated sections of the display but takes no further action.

• In cruise-control mode, the I-ETMS Locomotive displays Energy Management information in designated sections of the display and executes the locomotive control settings provided by EM in a manner that is independent from and in no way preempts the train control and enforcement functions provided by I-ETMS

• Train Handling and Energy Management Assistance is a non-interoperable function.

See also PTCDP sections 5.6.14 and 5.6.16.

• Metrolink does not utilize these functions in its I-ETMS PTC system

N/A

Logging (Non-Safety Critical)

None • The Office and Locomotive Segments log data into memory and support log retrieval for analysis or playback.

• An external event recorder as required by §236.1005(d) is included.


Locomotive





File Upload (Non-Safety Critical)

None • Locomotive Segment log files are uploaded to the Office Segment.



Train Operation Exception Reporting (Non-Safety Critical)

None • The Locomotive Segment monitors train speed, location, and locomotive control settings in order to detect exceptions to train handling as defined by a railroad’s air brake and train handling rules.

• Train handling exceptions are configurable and are specific to a railroad’s air brake and train handling rules.


Metrolink’s rules for train handling are contained in the GCOR rules referenced by this PTCSP.

Locomotive

Switch Position Awareness (Non-Safety Critical)

Section 17.0 • The Office Segment monitors WIU status reports and relays switch position to the dispatching system.

• The Office Segment will assume a wayside device is in its most restrictive state when a data refresh does not occur within a defined tolerance.

See also PTCDP Section 5.6.11.1.

• Metrolink does not utilize this function in its I-ETMS PTC system

N/A

Crew Logoff (Non-Safety Critical)

None • The crew logs off at the end of an I-ETMS equipped train’s trip over an I-ETMS track segment.

• The Crew Logoff function discards employee ID and PIN, clearance number, and Train ID at the end of an I-ETMS equipped train’s trip.

• The Locomotive system state is set to Cut Out, which sends notification to the Office Segment indicating the Locomotive is no longer controlling a train.





Current Functions that have Predefined Changes Leading to Future Vital 6.2.2Implementation

This section provides a description of current functions and certain predefined changes that will be made in the near future on the Metrolink PTC system, which will migrate to and evolve into a completely vital system. For each of these functions, Metrolink understands FRA’s position that the I-ETMS PTC system functionality should provide additional mitigations to reduce reliance on crew manual interface to implement PTC functionality. Along with a reference to the description of the function, each section describes the short term mitigations currently in place and the future vital mitigations planned. These functions are currently implemented in a manner that requires the use of railroad rules and procedures to address the mitigation of hazards. The hazards may occur in Metrolink’s implementation of I-ETMS in operating scenarios that the I-ETMS design does not currently address in a crew-independent manner. Each of the development efforts to achieve vital performance for Metrolink’s I-ETMS are the “predefined changes” highlighted in this section. The predefined change descriptions identify concepts, functional opportunities, and a general timeline for implementation.

6.2.2.1 Generation and Use of Consist Data, Including Total Brake Force As indicated previously, Metrolink will initially rely on the Train Crew to independently confirm consist data. Metrolink is instituting an Office calculation of total brake force based on consist data provided by Metrolink business systems to the Metrolink locomotives. However, if the crew or dispatcher modifies the consist to improve accuracy, total brake force calculations are then calculated by the onboard TMC.

Current short term Mitigation Applied 6.2.2.1.1Metrolink is reaffirming the safety-critical nature of consist confirmation by the train crew through its PTC training program and institution of a new PTC Operating Rule which requires that “Crewmembers must ensure the PTC system has the current consist prior to departing a location where the train consist is changed.” Metrolink believes the crew’s attention to this duty is the best current means to assure that the most accurate consist data is retained by the onboard segment of the locomotive. The train crew (Engineer) has been trained to designate the passenger train consist for the railroad. Additionally, Metrolink utilizes the input of the mechanical department in building train consists for departure, and Operations Service & Support employees to reconcile any variances between expected train consists at departure to the actual train consist. Metrolink is a commuter operation, and the maximum length train in daily operation is typically one locomotive, up to five coaches and one cab car. The Conductor walks the length of the train as a course of his duties, and the locomotive engineer walks the length of the train at each turn. Train crews report consist changes on the road via phone or radio to the dispatcher and through PTC. With these many checks and



balances, the crew serves as the closest resource to the physical consist and is the last of several verification sources.

Predefined Changes for Vital Mitigation 6.2.2.1.2Advances in end-of train monitoring are capable of providing the GPS location of the rear of the train. On reasonably straight track, the train length can be approximated onboard by comparing the PTC GPS location of the head of train with the calculated End of Train (EOT) GPS location. While this does not corroborate the train’s weight, it does validate or allow automatic correction of the train length input from the railroad’s business systems by the onboard PTC. Metrolink has a limited need for this information because consists are limited in number and car length is consistent across the fleet. Future applications of in-line weight scales on the mainline could obtain the train consist by weight, once the train passes over such scales, with the electronic readout to be received by the train through the PTC communications system. The input of weight from railroad business systems could then be validated or automatically corrected by the onboard PTC. Metrolink has a limited need for this information because there is a known weight assumed for a passenger vehicle that can be assumed in braking calculations. For enroute consist changes, Metrolink is developing train work order functionality that can take greater advantage of consist updates through real-time communication of consist pick-ups or set-offs employing new or available technology through line of road devices to further support PTC. Consist changes enroute are infrequent on Metrolink. This functionality will provide the crew the expected work, including data concerning the cars ordered for pick-up and set-off. This will allow the consist of the train to remain accurate even after any switching or set-off moves are conducted from the mainline. Again this is an unusual situation for Metrolink since the consists in revenue service are consistent across the fleet.

The milestone schedule for this development is as follows:

A milestone schedule is dependent on the industry development and implementation of EOT systems with GPS capabilities as well as the development of in-line weigh scales for mainline use. The schedule for these developments is currently under study by the participating railroads. The resulting schedule is due in 2016.

6.2.2.2 Highway Grade Crossing Warning System Malfunction Protection

Metrolink’s current PTC implementation for the protection of Highway Grade Crossing Warning System Malfunctions is shown in Section 5.2.2 as well as in Section 11.5 of the SSID in Appendix GG of this PTCSP. It is dependent on both PTC protection of a zero speed TSR and manual release of the TSR when the grade crossing is properly protected according to the Metrolink Timetable instructions [28] and GCOR.



Current Short Term Mitigation Applied 6.2.2.2.1

Protection of Highway Grade Crossing Warning System Malfunctions currently works as described in Section 5.2.2. The current mitigations applied to the hazard of the train crew erroneously indicating that flagging protection is present at a bulletined crossing device with a malfunction are:

• Metrolink has training materials that instruct the train crew to perform the correct operations that indicate appropriate flag protection at a Malfunctioning Highway Grade Crossing Warning System, as relayed by a Mandatory Directive for a zero speed TSR (see OSCAR022 in Appendix D.1 of this PTCSP).

• A first button selection by the train crew confirms that the train is within three miles of the crossing and the crossing is protected. A second, and different, button selection by the train crew is required to confirm that the number of flaggers providing protection is sufficient to meet the operating rules.

• With the two separate button presses both established in the PTC system, the zero speed TSR can be lifted for the train to proceed through the crossing per rule.

Predefined Changes for Vital Mitigation 6.2.2.2.2

Metrolink understands the need for the PTC system to be the entity responsible for the setting of a TSR for a failed crossing, or removal of a crossing system malfunction warning due to the crossing being protected by flagger(s). Metrolink will continue to work with other railroads and suppliers to create an industry or individual solution where the protection of a malfunctioning crossing is vitally confirmed and the restriction lifted directly by the PTC system, instead of through the train crew user.

If personnel assigned to the malfunctioning crossing protection (flaggers or their supervisor(s)) are provided with the EIC terminals under development for work zone protection, they could use such terminals to release the zero speed TSR that PTC sets for the train. This potential solution will be investigated.


No milestones have been established due to the lack of a vital technical solution at this time.

6.2.2.3 Initial Track Selection A description of the currently implemented Initial Track Selection function is described in Section 8.3.1 of the SSID in Appendix GG of this PTCSP. This SSID text is summarized below:

“8.3.1 Initial Position



At initialization, all valid GPS inputs are used to create a superset of track solutions on subdivisions identified in the Subdivision/District list as received from the railroad. The track solution list is presented to the crew in order of increasing Cross Track Error. Crew selection of track becomes the initial position of the locomotive and route is established. Protection of authority and open switches will be based on route from this location.”

Current Short Term Mitigation Applied 6.2.2.3.1The crew currently is the primary source of selection of one of several parallel tracks where PTC cannot absolutely determine the initial position of the train due to GPS resolution that is insufficient to provide this data. There is a reasonable probability that the crew may select the wrong initial track. Until another node in the PTC system is encountered by the train, there is no mechanism for determining what track is actually being used by the train. The current Metrolink mitigation applied to the hazard of the train crew selecting the wrong track location in response to initial track location prompts includes rules and procedures for selecting the correct track, supported by requisite training in establishing correct selection of the track occupied by the locomotive in multiple track territory. This training helps ensure that the train crew selects the proper track from the valid track options that are presented as being in proximity to the current GPS position (OSCAR035 in Appendix D.1 of this PTCSP). Further short-term mitigation has been placed in service to reduce the possibility of incorrect track selection by the train crew. When the initial track selection is made, it is compared to the position of the train ID in CAD. If the track selection does not match the position in CAD, the dispatcher is notified and instructed to contact the train crew.

Predefined Changes for Vital Mitigation 6.2.2.3.2Metrolink understands the need for the PTC system to be the entity responsible for the determination of which track the train occupies in all situations. Metrolink will participate in creating an industry solution where the PTC system can automatically determine what track the train is on in all situations. One of the mitigations being considered is a more accurate GPS solution that would provide a higher resolution train position, accurate to approximately 2 feet, eliminating the need for manual track selection by directly determining the track that is occupied by the train among several parallel tracks, even at the minimum track-to-track spacing.


No milestones have yet been established because this solution requires a change in the GPS receiver onboard to detect the GPS III signal broadcast by sources controlled by parties external to the rail industry. It is not yet known when a receiver with sufficient GPS resolution and at an affordable price for multiple track determination will be available to the railroads.



6.2.2.4 Crew Acknowledge of Electronic Mandatory Directives Currently, the I-ETMS system transmits a PTC generated confirming data version of the mandatory directive along with the primary dispatcher-transmitted verbal/written mandatory directive. This message is used by the PTC system onboard to assist with train control by the Engineer. It is planned, as part of the Back Office Segment improvement, to use the Individual and Composite CRC Calculator (IC3) methodology and ICD improvement between BOS and TMC to transmit the electronic version of the mandatory directives as the primary source. Since the TMC will be able to safely enforce these future directives without additional crew acknowledgement, the acknowledgement will be deleted from the future operating methods, and will be reflected in the Metrolink operating rules in effect at the time of the change. A description of the Mandatory Directive issuance process is described in Sections 11 and 12 of the SSID in Appendix GG of this PTCSP. Reference is also made to the Metrolink OSCAR document (e.g., OSCAR005) located in Appendix D.1.

Current Short Term Mitigation Applied 6.2.2.4.1The current mitigation applied to the hazards of electronic Mandatory Directives (MD) being corrupted during the construction of the message for normalization by the Back Office, and the hazard of the Back Office Server erroneously associating a Mandatory Directive with an incorrect train is:

• Given that I-ETMS is an overlay system, train crews are still responsible for confirming Mandatory Directive information verbally, with the dispatcher as well as by observing the onboard PTC system displayed data version of the MD. Specific training materials were developed to instruct personnel on reviewing Mandatory Directives and addressing irregular situations. Training shows the personnel what items are included on the Mandatory Directives menu, how the information should be displayed, and ensures that personnel understand that the intent of the review/update process is unchanged. Also included in the training and procedures are the methods necessary to compare the verbally or printed Mandatory Directives with the electronic format received onboard.

Current practice on Metrolink is to continue to utilize both electronically transmitted Mandatory Directives and paper or voice radio transmitted MDs which are compared by the train crew onboard.

Predefined Changes for Vital Mitigation 6.2.2.4.2Metrolink understands the need for additional mitigations for the hazards mentioned above. Metrolink has worked through the ITC development process to identify a mitigation for these hazards that would remove the system’s dependence on the current procedural mitigation. The Individual and Composite CRC Calculator (IC3), currently in development, is an independent process used to verify the data used for normalization and train association of Mandatory Directives generating two independently created CRCs for comparison by the onboard. When introduced, this will verify the correctness



of the mandatory directive data being sent electronically. The IC3 is described under Section 6.2.2.9.2 of this PTCSP.


The IC3 is under development by the I-ETMS supplier and will be delivered to Metrolink in 2016.

6.2.2.5 EIC Terminal for Authorization to Enter Work Zone Metrolink understands FRA’s requirement that the PTC system accomplish this Work Zone authorization functionality without allowing the train crew to erroneously remove or eliminate any needed warning or enforcement, as noted by the FRA in its August 26, 2011 letter granting Type Approval to the I-ETMS, “Unless roadway workers are utilizing an EIC terminal which allows the EIC to control access of the train into and through the work zone, I-ETMS acknowledgment by the engineer of a verbal authority from the EIC requires an acknowledgment, followed by a confirmation of the acknowledgment, before the locomotive is allowed to proceed into the work zone.” Existing Metrolink EIC Field Remote Terminals will continue to route messages to the Dispatching and Operations Center and not directly to the train. The process will remain much the same as described in Section 21.4 of this PTCSP, however, the verbal exchange with the train Engineer will take place. Metrolink’s current PTC implementation for the protection of Work Zones is shown in Section 5.2.4 - Work Zone Protection, as well as in Section 11.3 of the SSID located in Appendix GG of this PTCSP.

Current Short Term Mitigation Applied 6.2.2.5.1Work Zone enforcement currently works as described in Section 5.2.4 – Work Zone Protection. The current mitigations applied to the hazard of the train crew erroneously proceeding without proper Employee In Charge (EIC) permission into a Work Zone, or moving within a Work Zone without establishing permission with the EIC are:

• Metrolink has training materials to instruct personnel of the correct operation for entering an active Work Zone and resuming movement within an active Work Zone. The training ensures that the train crew not only receives verbal permission from the EIC to enter the active Work Zone per current operating rules, but it also instructs the train crew on how to acknowledge the receipt of permission to enter the active Work Zone via the CDU. (OSCAR010 – Appendix D.1 of this PTCSP).

• A first button selection (soft key) is required to acknowledge that the crew has received verbal permission from the EIC to enter the work zone.



• A second, separate, button selection by the train crew is required to confirm that permission to proceed through the Work Zone at a designated speed transmitted by the EIC has been received verbally by the train crew.

Predefined Changes for Vital Mitigation 6.2.2.5.2Metrolink understands the need for the PTC system to be the entity responsible for allowing access through a Work Zone. Metrolink is working through the ITC development process to develop an industry solution where the entrance and speed permissible through a Work Zone is electronically conveyed to the onboard from the EIC through the EIC application, thereby mitigating the risk from human error in this process. The EIC application, as embodied in a hand-held computer device, is currently in initial development by PTC suppliers. At a future date, Metrolink may request approval for an electronic-only message exchange involving the PTC EIC terminal under development. The permission to enter a work zone would be routed to the BOS and then relayed to the locomotive, or handled as a communication between EIC terminal and Locomotive PTC directly.


The development of the EIC terminal needed for this process is ongoing. The EIC terminal is expected to be available to the industry for this application by the end of 2016. This is based on preliminary information from the TTCI development project.

6.2.2.6 I-ETMS “Restricting” State vs “Switching” State I-ETMS has previously included a “Switching state” Switching state has been deleted from the current software version of the I-ETMS system onboard segment and has been replaced with a “Restricting” state, as explained in the Type Approved PTCDP (See Appendix B of this PTCSP). “Restricting” state limits the train to restricted speed with enforcement, once the Engineer has pressed the soft key to enable the state. Restricted speed is enforced for the entire time the Restricting state is in effect. This feature is not used by Metrolink, so no predefined changes for this functionality are deemed necessary.

6.2.2.7 Enter Main Track at Signal in Lieu of Electric Lock Location Authority to Enter the Main Track (EMT) is granted by the train dispatcher to authorize a train or engine that has previously cleared the main track to re-enter the Main (or other controlled) tracks in CTC territory at a location between block signals and then to proceed in one direction. This authority must be received by the train crew or PTC system onboard and acknowledged.

Current Short Term Mitigation Applied 6.2.2.7.1Authority to Enter the Main Track (EMT) is granted by the train dispatcher to authorize a train or engine that has previously cleared the main track to re-enter the Main (or other controlled) tracks in CTC or COT territory at a location between block signals and proceed in one direction. I-ETMS currently enforces such authorities and provides a



combination of two methods for handling them. These methods are used by some railroads but Metrolink already uses the “predefined change” identified in Section 6.2.2.7.2 below and avoids these current short term mitigations altogether. The first method is utilized when entry to the main track is authorized by the train dispatcher and conveyed both through verbal/written means and secondarily from the dispatching system to the Office Segment. The EMT in electronic form is processed by I-ETMS and delivered to the train as described in Section 5.6.5.2.6. This process ensures that an electronic version of the EMT is made available to the Locomotive Segment, which then displays the received EMT to the crew for reference and comparison with the manually received version. The second method is utilized as a confirmation of the supplemental electronic delivery of the EMT as above, or under communications failure conditions,. After stopping within a preconfigured threshold distance of the clearance point of switch at the entry location for a preconfigured period of time, a manual (soft key) input may be made by the train Engineer on the Locomotive CDU indicating that the train is authorized to enter the main track either because EMT has been received from the train dispatcher in verbal or written form . After the EMT has been indicated by the locomotive engineer, I-ETMS continues to display and enforce a stop at the main track switch clearance point because the position of the unmonitored switch is unknown. Upon the train being stopped within a configurable threshold distance from the switch, the Locomotive Segment will display a soft key prompt for the locomotive engineer to indicate when the switch is properly positioned for their movement. Once the switch is properly positioned and the locomotive engineer has indicated same, the stop target is removed and I-ETMS will allow the train to enter the main track and move at restricted speed. The process is now complete for operations at locations with electric locks or where an electric lock or signal in lieu of same is not required or installed. At a location where a signal in lieu of electric lock is present and the signal is unmonitored, I-ETMS continues to display and enforce a stop at the main track switch clearance point because the indication displayed by the signal is unknown. The onboard system provides a soft key prompt for the locomotive engineer to indicate whether or not the signal in lieu of electric lock has cleared. If the locomotive engineer presses the soft key indicating the signal has cleared, the Locomotive Segment then authorizes and allows the train to enter the main track and proceed prepared to stop at the next signal. If the locomotive engineer presses the soft key indicating the signal has not cleared, the Locomotive Segment begins a timer and displays a countdown. The duration of this timer is specified in the track database on a per-location basis and may be set commensurate with time locking requirements specific to each location. At expiration of this timer, I-ETMS then allows the train to enter the main track and move at restricted speed. The process is now complete for operations at locations with signal in lieu of electric lock.



Predefined Changes for Vital Mitigation 6.2.2.7.2Metrolink is already using a “long term solution” to the EMT delivery requirement, and avoids the “short term mitigation” above. The dispatcher issues permission to enter main track from CAD. After receiving the verbal and supplementary electronic permission, the train crew member aligns the switch. The signal in lieu of an electric lock is monitored, and if the signal displays Approach or Restricting, the train is allowed to proceed. If the signal does not display Approach or Restricting, then the train is required to wait ten minutes before being allowed to proceed at Restricted Speed by Rule. This ten minute wait is enforced by the on-board.

6.2.2.8 Use of “Disengaged” State in Onboard I-ETMS “Disengaged” State is entered by the onboard segment upon the I-ETMS determining that:

• The Locomotive Segment has determined the train is not located in PTC territory;

• The Locomotive Segment is unable to positively determine the train’s location;

• The Locomotive Segment has detected a possible discrepancy between its internal data stores and data in the office.

This state keeps PTC powered up, but not in control of the train. The disengaged state means that the Locomotive Segment has initialized but will not provide predictive or reactive enforcement. The disengaged state allows the locomotive to be moved subject to operating restrictions.

Current Short Term Mitigation Applied 6.2.2.8.1Failure of the Locomotive Segment to receive a valid heartbeat within a threshold time tolerance, or a mismatch between the code calculated by the Locomotive Segment and that received in the heartbeat from the Office Segment causes the Locomotive Segment to prompt the locomotive engineer to acknowledge that the system will transition to the “Disengaged” state. The system will stay in the “Disengaged” state until such time as data synchronization is positively re-established.


The design solution for future operation in the “Disengaged” state is to provide a civil permanent speed restriction when the locomotive is placed in “Disengaged” state. This is a TMC modification that will be developed by Wabtec.


Wabtec is currently working on this modification and it is expected to be available in the first half of 2016.



6.2.2.9 Hazards Attributed to BOS The existing Back Office Server (BOS) for the I-ETMS system is designed using safety-critical design techniques but does not achieve fully vital performance. There are three hazards identified associated with the existing BOS design:

1. The BOS normalization process may cause the data related to a mandatory directive as received by the on-board segment to differ from what was sent by CAD.

2. The BOS may not associate the data related to a mandatory directive with the correct train(s).

3. The BOS may not transmit the data related to a mandatory directive when required.

These hazards are not fully mitigated in a vital manner by the current BOS design, leading to the need for both short term mitigations and a “predefined change” for a vital implementation of the Office Segment of I-ETMS.

Current Short Term Mitigation Applied 6.2.2.9.1In the current I-ETMS design, no safety-critical functions have been allocated solely to the BOS. The Office Segment data delivery function is considered non-vital in the overall architecture as the vital Locomotive Segment protects itself from potential hazards caused by data delivery failures. The Locomotive Segment also provides a vital range check on data received from the BOS. The Office Segment provides a non-vital check of the reasonableness and integrity of data received from external sources such as CAD and provides delivery of data to the Locomotive Segment through the Communication Segment.


A JRST review of present BOS functionality has identified continuing potential hazards as documented in the “Selected I-ETMS Hazards Related to Non-Vital BOS Implementation” document, which is contained in Appendix G.3.a of this PTCSP. The hazards identified are associated with how the I-ETMS system transforms and transfers data related to the mandatory directive to the on-board after it is received from CAD.

• The BOS normalization process may cause mandatory directive data received by on-board to differ from what was sent by CAD.

• The BOS may not associate a mandatory directive with the correct train(s).

The proposed vital implementation solution is to create an independent process used to verify BOS normalization and train association of mandatory directive data. The process generates data used by the Locomotive Segment to verify that the BOS has delivered correct mandatory directive data to the correct trains. The process, named Individual and Composite CRC Calculator (IC3), independently creates two types of CRCs used for comparison by on-board: Individual MD CRCs and the IC3 Composite



CRC. The first CRC will be used to verify that mandatory directive data is correct when received by the Locomotive Segment. The second CRC will be used to ensure the Locomotive Segment has the correct set of mandatory directives. Individual MD CRCs are used within I-ETMS to verify that mandatory directive data is correct when received by the onboard system. The IC3 Composite CRC is used within the I-ETMS onboard system to ensure the on-board system has the correct set of mandatory directives as transmitted from the CAD system to the PTC system.


The IC3 is under development by the I-ETMS supplier and will be made available to I-ETMS users including Metrolink in 2016. Metrolink will be implementing the IC3 as soon as it is made available to the railroads.

To further enhance the safety of the I-ETMS PTC system deployed on Metrolink, a processor subsystem called the Independent Validation Server (IVS) is under development by the I-ETMS supplier, to be added to the PTC Office Segment interfacing with the BOS, and with the separate CAD system. The IVS is an next-step evolution of the IC3 as it would perform the IC3 functions as part of its mission. The IVS subsystem is to be designed with appropriate Safety Assurance Concepts per IEEE-1483 [2] guidelines so that it would be classified as a vital component of the PTC system once implemented. The key purpose of the IVS is to provide vital protection of Mandatory Directives received from the CAD system. The key objective of the IVS is to increase the overall office segment safety to a probability of a hazardous event being 1 in 10-9 (IE-9) which is the industry accepted value for a vital component. The IVS would accomplish this through its internal design,

The IVS would be used to check all office segment logical products to eliminate common failure modes that may exist in commonly used or similar safety-critical functions. The IVS would bridge the gap with PTC operations that may currently exist in a non-vital form. In addition, the IVS would provide a future platform to execute other safety-critical operations that may eventually migrate to the back office, or to absorb the functions of other components of the Back Office.


No milestones beyond initial definition have been generated by the supplier. The initial definition milestone is due to the railroads by early 2016.

Metrolink-Specific Implementation of I-ETMS Architecture 6.2.3

The following sections provide additional details about the Metrolink incorporation of I-ETMS, as defined in the referenced PTCDP, into its specific existing operating environment and railroad infrastructure.



6.2.3.1 Office Segment The Back Office PTC segment is a compilation of software functions and associated processor hardware collectively called the Back Office Server (BOS) that provides validated and security protected input to On-board PTC Systems. The back office segment is comprised of the BOS servers and associated application interfaces to other Office systems, such as to the independent Computer Aided Dispatch (CAD). It interfaces with other railroad back office, locomotive, and communication segments. The back office segment accepts mandatory directives and other information generated by the CAD system and serves it to the locomotive segment via the communication network. The back office segment serves as a conduit for information conveyed to the locomotive segment where the system’s vitality resides. In the current implementation, as previously stated in Section 6.2.2, the current ultimate protection against BOS errors is by procedures and rules. Future vital implementation will provide vital BOS protection against errors by the I-ETMS system through the IC3 development. The BOS is the repository of the track geometry and wayside signaling configuration database and the permanent speed restriction database. The BOS is the primary data interface for all trains and work crews operating within SCRRA territory. The SCRRA Back Office Server is the data interface with the Amtrak, BNSF Railway, and Union Pacific Railroad (UPRR) tenant locomotives. The Back Office also communicates and coordinates bulletins, track authorities, temporary speed restrictions, limits of movement authorities, work zone limits, stop and protect orders on highway-rail grade crossings, and other specialized data that may be transmitted between the wayside and the train.

Network Management System (NMS) 6.2.3.1.1The primary goal of the Network Management System (NMS) is to monitor the health and status of the PTC network elements and provide alerts to conditions that impact system performance. The NMS is not part of the vital operation of the I-ETMS system and instead serves as an automated monitoring and support method for system reliability and maintainability. This subsystem of the PTC structure is described in Section 6.2.3.2.6 as part of the Communications Segment. There are no direct functions of the NMS that support the safe operation of the PTC system, and therefore no safety-critical requirements are allocated to the NMS.

Computer-Aided Dispatching (CAD) 6.2.3.1.2The CAD system (external to PTC) provides the following functions:

• Maintains Train data (e.g., Consist, Train route/position, Train Sheet, etc.) for a given Train

• Provides a FRA record of Train operations by maintaining and updating Train Sheet records (Crew, Units, Consist, etc.)



• Provides the interface between the Dispatcher and Train Sheet information that is used to update the PTC Server

• Provides updated Train Data and General Track Bulletin (GTB) information

While the locomotive/train is Active, the CAD system will supply Train Sheet updates to the PTC BOS. The PTC BOS continuously and automatically “pushes” the updated information it receives from the CAD system to the Locomotive thereby ensuring system synchronization. This information is validated by the Locomotive Segment before being used, therefore the CAD is not considered part of the safety-critical PTC system.

Dispatch 6.2.3.1.3The CAD system is responsible for providing conflict resolving logic during generation of track authorities for review and approval by the Train Dispatcher. It provides the interface between the Dispatcher and the PTC BOS. Dispatch ensures that the PTC BOS is kept current on any new or additional Movement Authorities. Authorities (i.e., Track and Time, Permission to Pass Stop Signal, and Authority to Enter Main Track) are sent from the Dispatch system directly to the PTC BOS; Speed Restrictions associated with Highway Grade Crossing System malfunctions are sent from the CAD. The BOS translates these Authorities and Restrictions from Dispatch into defined, PTC-compatible message sets which are communicated through the Interoperable Train Control Messaging (ITCM) network to PTC-equipped Locomotives, as required.

Metrolink ITCM Network 6.2.3.1.4The Interoperable Train Control Messaging (ITCM) network provides the pathway (i.e., application gateway, wireless network, radios, etc.) used to communicate between the PTC BOS and PTC-equipped Locomotives. ITCM is defined by AAR standards found in the [16] of this PTCSP.

Wayside Status Relay Service 6.2.3.1.5The Wayside Status Relay Service (WSRS), as shown in Figure 6-2 - WSRS Architecture, provides an alternate path to the peer-to-peer wayside status message provided over 220MHz radio. WSRS also provides the mechanism for the forwarding of wayside status messages to the locomotive via the Office Segment. Waysides are configured to forward their WIU Status messages to the WSRS, through the Messaging System. A Locomotive Message Redirector (LMR) application runs on each Locomotive Messaging Server (LMS). This application monitors all message traffic entering the LMS. Once it detects Beacon On of WIU Status messages, the LMR sends a copy of this message to the WSRS via the Messaging System. Once a Beacon On or WIU Status message is received from a locomotive, the WSRS immediately forwards the status of the wayside in question to the locomotive. The locomotive also is dynamically subscribed to that wayside and receives any subsequent updates to the WIU Status for that wayside.



Figure 6-2 WSRS Architecture

6.2.3.2 Communication Segment The Communications Segment consists of hardware and software components that interface with and provide connectivity between the operational PTC subsystem segments. The Communications segment does not have any safety-critical requirements for performance, as discussed in Section 3.3 of this PTCSP, and is not expected to be fail-safe under any circumstance. As stated in I-ETMS PTCDP v.3 Section 6.4, the PTC system has been designed so that the Communications Segment is not critical for safety. Information is protected by CRC and the Locomotive Segment accounts for any loss of information by defaulting to the most restrictive state. I-ETMS application functions connect to the Communications Segment via a standard interface and communicate with each other using protocols that are independent of any particular communications network. The Edge Message Protocol (EMP) and Advanced Message Queuing Protocol (AMQP) are supported. The ground based system uses SCRRA’s existing backhaul network comprised of SONET rings, Gigabit Ethernet rings, and Microwave rings. The 220 MHz radios are not part of ITCM even though they utilize the ITCNet protocol. They are part of their own communications subsystem described herein as 220 MHz radio, but the term “220 MHz radio” is synonymous with ITCR.



The Communication Segment consists of a messaging system and multiple wired and wireless networks as depicted in Figure 6-3 and Figure 6-4 below, through which messages are exchanged between the Locomotive, Wayside, and Office Segments. Figure 6-3 shows the overall communication design architecture whereas Figure 6-4 is the locomotive segment portion of the communication architecture. The deployment of multiple wireless networks is used to maximize capacity, throughput, and to alleviate coverage issues as well as to allow seamless routing across the prescribed path. The following communications networks are part of the Communications segment: • Wireless Networks

o 220MHz Private narrowband radio network (Interoperable standard) o Broadband – Wi-Fi network infrastructure deployed by railroads (IEEE802.11) o Cellular and satellite – Private wireless data networks

• Ground based network and onboard network - ITC Messaging System (ITCM)

Figure 6-3 I-ETMS Communications Network Architecture

EMP

IP Networks

RailroadProprietary

Single Supplier Proprietary AAR StandardOpen Standard

* * * Legend

220 MHz Radio Hardware

220 MHz Radio Software

Messaging System

Messaging System Protocol

Wayside SegmentOffice Segment Locomotive

Segment

EMP

EMP

EMP



Figure 6-4 I-ETMS Locomotive Segment Communications Architecture

Locomotive

ITCM

220 MHz Radio802.11 Radio Cell Radio 1

Business Applications

Cell Radio 2

I-ETMS Onboard Application

Communications Network 6.2.3.2.1The SCRRA PTC is designed as locomotive-centric, with the Communications Network performing the supporting role of delivering the relevant PTC messages and commands between the BOS, the Wayside Segment, and the locomotive. In order to maximize the efficiency with which this is executed, the Communications Network uses an architecture based on Time Division Multiple Access (TDMA) in the PTC 220 MHz band. Communication via the 220 MHz spectrum has been analyzed by the participating railroads and is judged sufficient to allow the PTC systems to operate effectively together at track speed and provides the intended performance of train control. Additionally, there is a network of 802.11 (Wi-Fi) base stations at designated locations such as layover areas, yards, terminals and maintenance facilities to facilitate communications between the BOS and onboard systems for initialization and database updates. Neither of these networks are used for EIC terminal components at the present stage of PTC deployment. An RF path is provided by the Communications Network for essential PTC communications using PTC 220MHz radios and/or the 802.11x network, for each locomotive and cab car; Base Station; and WIU. Each locomotive and cab car is equipped with one PTC 220 MHz digital TDMA radio, which has a built-in GPS receiver clock interface. Additionally, each locomotive and cab car is equipped with an 802.11



(Wi-Fi) radio for database initializations and separate GPS and Differential GPS. Differential GPS is used when available. The I-ETMS design allows for different levels of minimum position accuracy obtained with differential correction versus without differential. GPS/DGPS is also used for location/position determination in conjunction with the tachometer. All Base Stations are equipped with PTC 220 MHz digital TDMA radios, each of which have a built-in GPS receiver clock interface. A PTC 220 MHz digital TDMA radio with built-in GPS receiver clock interface is also used at all wayside signal WIUs. The PTC radios conform to the ITC/AAR specifications for the 220 MHz PTC radio.

220 MHz Radio Network 6.2.3.2.2

The 220 MHz narrowband radio is an industry-standard radio implementation specified and designed by the ITC committee. The frequency band of the radio is: Upper – 222 MHz; Lower – 217.6 MHz. The 220 MHz band-plan divides the spectrum in 5 kHz slices and the ITC-designed radio aggregates those 5 – 5 kHz channels together to achieve a 25 kHz channel needed to support data requirements for train control messages. This channel aggregation scheme (as allowed under 47 CFR 90.733 (d)) is used to achieve spectral efficiency, the primary goal of narrow banding.

The system was designed with 80% utilization of available channels. The number of wayside locations drives the capacity, not the amount of rail traffic, so an additional 20% is typically available for growth of the wayside infrastructure.

While the 220 MHz path can be used for large file transfers, Metrolink additionally uses IEEE 802.11x and 3G cellular services for high-bandwidth requirements. The maximum physical data rate that can be supported in a 25 KHz ITC channel is 32 kilobits per second (kbps). Refer to MeteorComm’s “ITCR 220 MHz Network Design Guidelines” document, Revision 1.3 that is included in the list of available documents in Appendix L. Data rates for other industry standard communication methods can be found from each standard: IEEE 802.11a: Maximum Throughput is 54Mbps and typical 3G data rates are around 2Mbps or higher depending on which technology is in use by the service provider. The 220 MHz network supports communications between all I-ETMS segments.

Metrolink is seeking to acquire additional spectrum bandwidth to supplement the spectrum owned and managed by PTC220, LLC. Acquisition of this additional spectrum will provide for long-term growth and expansion of the spectrum to other future uses, i.e., communication between EIC Terminal and locomotives associated with work zones or Highway Crossing malfunctions.

MeteorComm, LLC, has developed functional specifications for standard radio and protocol implementation intended to support I-ETMS and other business applications. Metrolink utilizes the 220 MHz spectrum owned and managed by PTC220, LLC. Additional wireless networks may be added at any time, but the 220 MHz PTC data radio system must be deployed to achieve interoperability in the Communications



Segment with the other railroads in Metrolink’s host/tenant relationships. Future possible upgrades to the standard for ITC interoperable radios may cause this relationship to be changed.

While not a condition of interoperability, Metrolink also supports the use of interoperable 802.11 capabilities in accordance with AAR Specification [14]. Metrolink has also chosen to subscribe to commercial cell in the Communications Segment. These non-interoperable wireless networks augment the 220 MHz PTC data radio system and as such do not need to support stringent network performance characteristics. Since Commercial cell licenses are given on a contract basis, the cell system may not respond to trains from tenant carriers, so the cellular connection is not interoperable by the FRA definition. Where they are used, these auxiliary communications simply add capacity, throughput, and limited local backup capabilities to the local 220 MHz PTC data radio system.

The 220 MHz radio has been designed with a combination of TDMA and CSMA channel access methods intended to maximize efficiency and throughput. The Wayside to Locomotive link is especially time sensitive, requiring frequent status updates. The Wayside RF link uses a fixed TDMA scheme where each Wayside is assigned a unique “time slot” facilitating an efficient use of the channel.

The RF link between the Office and Locomotive uses a dynamically assigned TDMA time slot provisioned by the base station upon request from the locomotive radio. Once an I-ETMS train is fully initialized and on line-of-road, at a minimum, the Locomotive must receive a periodic “heartbeat” message from the Office Segment within a threshold tolerance in order to remain in the Active state. This heartbeat message is used by the Locomotive Segment to ensure that locomotive data is synchronized with the Office Segment.

The period of the heartbeat varies based on the distance of the locomotive from the subdivision for which the data is being synchronized. The period is defined by the following common configuration parameters: Description Parameter Common

Value Range

Fast poll rate: The rate for subdivisions within TBC56 miles

TBC55 3 minutes 1-3

Medium poll rate: The rate for subdivisions between TBC56 and TBC97 miles

TBC96 10 minutes

3-20

Slow poll rate: The rate for subdivisions farther than TBC97

TBC146 60 minutes

20-60

Fast poll distance TBC56 50 miles 50-50 Medium poll distance TBC97 100 miles 50-100

The wayside signal system’s PTC communications interface is comprised of a PTC 220 MHz radio, a 220 MHz antenna, and a GPS antenna. The PTC 220 MHz radio uses a digital TDMA air-interface for the communication of vital data between the BOS and



radio Base Stations and from Base Stations to the locomotive/cab-car PTC 220 MHz radios. A TDMA network based on a cellular fixed site architecture is employed for all PTC 220 MHz radio communications. Wayside PTC 220 MHz radios use an Ethernet interface to the Wayside Interface Unit (WIU) in all necessary locations. The wiring connections between the PTC radio and the Signal system WIU complete the Wayside PTC functionality. WIU messages are formatted to implement EMP Class D per AAR Standards.

In order to minimize system latency, the 220 MHz spectrum used by the radio links must be properly managed to maximize efficiency and throughput. To meet these goals, the ITC member roads formed PTC220, LLC, a holding company for the 220 MHz spectrum charged with the efficient deployment of 220 MHz spectrum nationwide. PTC220, LLC is responsible for managing frequency coordination, frequency reuse, interference mitigation, and coordinating 220 MHz build out plans. In the 220 MHz spectrum, both frequency and timeslots are managed by PTC220, LLC and its contractor TTCI with radio planning tools, not with the railroad administrative network management system (NMS).

To provide the strategic support for the nationwide deployment of the 220 MHz spectrum, others have developed management tools that are used in specific geographic locations to assess channel loading issues. To that end, the freight railroads agreed to set a channel utilization metric threshold of 80%. This metric will be used to provide guidance as to when congestion limits may begin to adversely impact RF network performance. PTC220 is owned by the Class I’s. All railroads are using the PTC220 network, they abide by the rules set out by LLC, including Metrolink.

Metrolink’s Vendor Integrator performed extensive modeling of the 220 MHz radio system prior to designing and installing it. An industry group undertook an effort to model one of the most dense US freight corridors consisting of one base covering 30 miles of triple-track territory occupied by 21 trains and interfacing with 25 waysides. This approximates one Metrolink base site, so the comparison is useful to Metrolink operation.

The modeling indicated channel loading to be approximately 6.8 kbps. The most current bandwidth capacity estimates for the 220 MHz radio is a 14 kbps offered load. In the current load models, assuming there are no limitations due to radio development and refinement of the I-ETMS application, the estimated worst-case scenario indicates that PTC traffic will fit within the channel. If there is any significant increase in channel loading, more 220 MHz channels will have to be licensed by the appropriate party. In that regard, Metrolink is pursuing acquisition of additional spectrum as a mid-term to long term contingency for channel capacity constraints.

In areas where there are overlapping 220 MHz radio base stations belonging to different railroads, the PTC data radio system provides the opportunity for users to share base stations. In the LA Basin, the Communications system for Metrolink, BNSF and UPRR was designed to work cooperatively. Incoming radio traffic received on a base stations operated by a “foreign” railroad can simply be forwarded through an interconnected



back office, to the appropriate back office servers for processing. This functionality helps in managing deployment costs where sharing takes place and can also support redundant base station coverage yielding improved reliability.

802.11 6.2.3.2.3While not a condition of interoperability, Metrolink also uses 802.11 capabilities in accordance with AAR Specification S-9555 “Railroad Use of 802.1X and DHCP Services in Support of 802.11 Interoperability”. The usage of 802.11 communications is primarily used while in railroad yard facilities to support the file transfer requirements of initialization of the I-ETMS application during system initialization.

Cellular 6.2.3.2.4Metrolink also subscribes to commercial cellular as a part of the Communications Segment. This non-interoperable wireless network augments the 220 MHz PTC data radio system and as such does not need to support stringent network performance characteristics. Where used, these auxiliary communications simply add capacity, throughput, and limited local backup capabilities to the local 220 MHz PTC data radio system. Locomotives are equipped with cell modems from AT&T and Verizon. Wayside locations are equipped with one of two cell modems from Verizon or AT&T. Cell modems allow two additional paths of communication where 220 MHz may have a coverage issue but are not used as the primary path.

The Messaging System 6.2.3.2.5

The messaging system is designed to allow applications in the back offices, locomotives, and waysides to communicate with each other in an interoperable fashion across railroad boundaries. The messaging system, known as the Interoperable Train Control Messaging or ITCM, is a messaging solution based upon open source software that has been customized to meet the requirements of I-ETMS. The architecture consists of redundant, scalable back office servers with messaging clients on remote assets, such as locomotives and wayside equipment. The ITCM is a loosely coupled, asynchronous message delivery system. Wayside, Locomotive, and Office applications communicate by simply addressing messages to one another and handing them off to the ITCM for delivery; without being concerned about how messages are routed through the system.

The messaging system insulates the I-ETMS application from the underlying communications networks of the Communications Segment. It manages access to the available wireless networks to ensure that available bandwidth is used efficiently and that I-ETMS message traffic has first priority. The messaging system also supports transfer of messages between railroad offices and allows deployment of shared wireless infrastructure. Messaging functions provided by the Communications Segment include the following:

• Asynchronous, connectionless message transfer; • Quality of Service based network nodes selection and bandwidth management; • Message Queuing;



• Message Routing; • Translation of application protocols to Communications Segment transport

protocols; • Mobility; • Multiple RF paths and supporting protocol adapters.

Messaging system requirements are identified in the AAR ITC Messaging (ITCM) Specifications [16]. The messaging system allows both mandatory and optional attributes. Mandatory and optional attributes are applicable both at the message level and the system configuration level, but the optional attributes may not be allowed to interfere with interoperability. These requirements include a standard interface for access to the messaging system by I-ETMS or any other compliant application.

Figure 6-5 ITC Messaging System Architecture

Figure 6-5 depicts the ITC Messaging System architecture, including the component functions of the messaging system. Items in blue rectangles are routing components of the messaging system; items shown in orange rectangles are specifically related to the Metrolink radio communications RF network, vs. the Metrolink Ground Based Network



or other network. Green is used for applications connected to the communication messaging system.

Network Management System (NMS) 6.2.3.2.6To properly manage the complex distributed network related to the PTC System, SCRRA implemented a Network Management System (NMS) which is able to monitor and manage the various network components of the dispatching system in conjunction with the Code Field Network management system. The NMS is not part of the system safety case and instead serves to enhance reliability and maintainability of the I-ETMS PTC system. The NMS is not a part of the PTC communication network, it is an administrative tool. No PTC functionality is dependent or carried on the NMS. It is useful for remote diagnostics. The NMS also integrates the monitoring functions of all of the following communication based systems:

• PTC BOS • PTC Communications Network • Highway Crossing Monitoring System • Regional Transportation network • Passenger messaging system,

In addition the NMS:

• Links to UPRR and BNSF adjacent territories, • Interfaces with SCRRA’s existing database systems • Will monitor future IP based subsystems.

The NMS features a real time network topology map customized for the Metrolink system, indicating the communication sites, status, and backbone connections. As part of the Network Management System, SCRRA will be installing a SCADA system for the purpose of monitoring site alarm conditions in the same manner as the NMS.

6.2.3.3 Wayside Segment The wayside segment consists of signaling appliances located in the field whose status relates to the PTC onboard system operations, along with the WIUs used to monitor and report their status to the PTC system via radio or alternative communications means. These appliances include interlocking controllers, signal controllers, switch circuit controllers, track circuits, and other field devices. The locomotive segment utilizes the status of wayside devices along the route of a train during the calculation of its targets. The GE WIU/Interlocking Controller product utilizes the Checked Redundancy and Intrinsic Failsafe Design safety concepts to implement functions identified as safety critical. The critical assumptions for these safety concepts are identified in IEEE 1483-2000 [2]. The implementation of these safety concepts fulfills the dependencies identified by the standard. In addition, the design separates safety-critical and non-safety critical functions. The GE Transportation Systems Safety Process and V&V Process ensure the proper implementation of these safety concepts.



The ElectroLogIXS and VHLC products were developed prior to the enactment of 49CFR 236 Subpart H, and as a result the existing (non-PTC) functionality of these controllers is considered grandfathered with respect to that Part. The ElectroLogIXS and VHLC safety cases for the grandfathered functionality qualitatively demonstrates that Catastrophic hazards are mitigated such that their occurrence is Improbable (<1E-9/hour per AREMA [22]). Thus it is assumed that the legacy functionality has a hazard rate less than 1E-9. This assumption is validated by the extensive operating history of the ElectroLogIXS and VHLC platforms in railroad installations, where similar designed equipment has been used in over 1000 locations for up to 2 decades. To ensure the addition of PTC functionality had no material impact on safety, Hazard Rate and MTTHE figures were calculated for the added functionality. The worst case hazard rate contribution of the added PTC functionality was calculated to be 7.02E-17. This was calculated by the ElectroLogIXS PTC Communications FTA, which is a part of the ElectroLogIXS Safety Case found in Appendix V of this PTCSP. This contribution is considered negligible and as a result the Hazard Rate for each legacy ElectroLogIXS or VHLC vital function is assumed to be less than 1E-9 (Improbable per AREMA). A specific MTTHE for each ElectroLogIXS or VHLC vital function is not available for the reasons stated above. However, the MTTHE of the logic controller itself can be assumed to be greater than 1E9 hours from the stated “Grandfathered” compliance with Part 236 subparts A through G. The Wayside Segment WIU Component safety is supported by the Safety Case and “Grandfathering” letter from FRA provided in Appendix V of this PTCSP.

6.2.3.4 Locomotive Segment SCRRA has implemented a PTC system with a distributed architecture. The SCRRA PTC System is locomotive-centric. The Locomotive Segment Figure 6-6 on SCRRA is considered vital when performing all safety critical functions.



Figure 6-6 I-ETMS Locomotive Segment Configuration

The Locomotive Segment refers to a set of independent onboard hardware, software, and devices that interface with locomotive control equipment and includes a train management Computer (TMC), a Cab Display Unit (CDU), a locomotive ID module, a GPS receiver, and a brake cut out switch. The Locomotive Segment is responsible for computing and enforcing the train’s authorized operating limits. The Locomotive Segment accepts movement authorities, mandatory directives, train consist data, and other information from the back office segment. Switch position and signal indications are directly transmitted from the Wayside Segment to the locomotive. Wayside status is contained in the message to the locomotive which uses information regarding switch position to navigate route, and uses the information conveyed in the signal indication as part of the process for locating the target in advance of the train. The Locomotive Segment provides the status information and position report to the Back Office Segment and acknowledgement messages received from the Back Office Segment. SCRRA’s fleet has of 52 locomotives, consisting of 22 F59PH, 14 F59PHI, one (1) F40PH and 15 MP36PH; and 236 multi-level cars consisting of 57 cab cars and 179



coach cars. All of SCRRA’s locomotive fleet and cab cars have been equipped for PTC operations. Additional locomotives on short 1 to 3 year leases, equipped for PTC, will augment this fleet in 2016 as currently planned. The On-board PTC System communicates with other PTC components via the 220 MHz Radio Frequencies (RF) network providing the following bidirectional links:

• locomotive to back office • locomotive directly to wayside signaling equipment.

The On-board PTC System also communicates with the PTC BOS to obtain data downloads and initializations via the 802.11x wireless data network when available at a layover, yard or maintenance facility. SCRRA locomotives and cab cars are also equipped with two diverse cellular phone network access capabilities, as are the locomotives of the known host/tenant Freight Railroads. The cellular capability is designed as a backup only to the primary 220 MHz radio connections used by Metrolink’s PTC. The On-board PTC System is a compilation of software functions and associated hardware that provides train operations information to the train operator and enforces safety critical restrictions in the event of train operator failure to correctly respond to the train operations information. Each Onboard package consists of an on-board Train Management Computer, 220 MHz radio, dual GPS receivers, Wi-Fi Module, a Cab Display Unit (CDU), processors, event recorder, interface to trainline and other train subsystems, antennas, and other associated hardware and software provided on each SCRRA locomotive and on each SCRRA cab car. It is noted that Metrolink has only one crew member (the locomotive Engineer) assigned to perform duties in the locomotive or controlling cab car, hence a single display (CDU) is installed to display the PTC information in the cab. The conductor of Metrolink trains is generally located in the passenger compartment of the train, and receives PTC and other operating information as needed from the engineer by two-way voice radio. Since most SCRRA cabs have room for only one train Engineer or operator, and SCRRA operates with a one-person crew, only one PTC display screen is provided in SCRRA cabs and cab cars. Therefore, when multiple active crew members are assigned to the control cab, these crew members must be made aware of the information provided by the PTC display screen. They must position themselves where they can observe the CDU display from a jump seat or standing position as appropriate to observe the display.

I-ETMS Train Management Computer 6.2.3.4.1

The I-ETMS Train Management Computer (TMC) is a modular hardware unit that includes redundant train control processors, optional business application processors, serial interfaces, discrete interfaces, and the penalty brake interface. Software running



on the processor modules is used to perform all train control functions such as determining current position, calculating braking distance, managing restrictions, managing off-board communications, and communicating with the CDU. The architecture of the TMC is shown in Figure 6-7.

The minimum train control configuration requires at least 2 CPU modules, 1 I-ETMS Brake Interface (EBI), 1 Input Output Concentrator (IOC), 1 Discrete Input Module (DIO), and 1 Router/Switch Module (RSM). There is no priority in bus access. The system is based on an Ethernet communications architecture where each slot has a unique ID configuration that allows a board to determine which slot it is installed in. The system will detect a configuration failure if the board is in the wrong slot. Please see Section 3.4.1.1 of the I-ETMS PTCDP which includes additional detail regarding the board slots. The three empty slots do not affect the TMC operation.

There is no difference in normal operation between 2 and 3 train control processor configurations; the 2 processor configuration has less availability than the 3 processor configuration. Agreement of 2 slices is needed to hold off the application of penalty brakes. The difference between two and three slices is in PTC system redundancy for SCRRA, where the onboard TMC allows 1 slice to fail and have the TMC still function as a vital 2-of-2 application.

The Locomotive Segment architecture is shown in The specific modules within the I-ETMS system vary depending upon the specific locomotives deployed. I-ETMS hardware is configurable to accommodate various locomotive types. Each locomotive type is equipped with the appropriate wiring harness and will obtain specific information from a Loco ID embedded in the wiring harness. Details on each hardware module within the TMC are included in the following sections.

Chassis 6.2.3.4.2

The I-ETMS chassis is designed to fit either in a Locomotive Systems Integration (LSI) rack, or onto a mounting bracket that may be mounted directly to an available interior bulkhead in the locomotive thus providing maximum flexibility for installing in space-constrained locations.

The chassis integrates each of the I-ETMS modules into a cohesive unit by allowing the internal modules to be configurable to account for a wide variety of locomotive chassis. Each of slots 1, 2, and 3 provide a direct connection from the CPU to the enforcement module through the chassis backplane. The chassis is designed to accommodate up to ten (10) modules, which can include the following:

• CPU – Standard Processor Module (3 are used for 2 out of 3 Metrolink train control)

• IOC – Input Output Concentrator

• EBI – I-ETMS Brake Interface



• DIO – Discrete Input Module

• RSM – Router/Switch Module

The base includes card guides and a backplane for interfacing with any of the up to ten (10) supported modules. The matching I/O connector for each module is part of the cable assembly and is installed as needed. For example, if only boards for CPUs, IOCs, and Enforcement module are required, there would only be cables to those slots. This allows for flexible growth as new functions and interfaces are added. If more inputs are required than are on a single I/O card, a second card may be installed. External wiring harnesses, designated for the specific locomotive, will be required to interface to the additional I/O card.

Figure 6-7 I-ETMS Locomotive Segment Architecture

CPU Module 6.2.3.4.3The I-ETMS Central Processing Unit (CPU) is a standard module that is used for both train control and business application. Train control application software operates on CPU modules that are separate from a CPU module designated for a business application. The majority of system-level I/O are handled by other modules within the chassis (Section 6.2.3.4.4 - Input/Output Concentrator and Section 6.2.3.4.6 - Discrete Input/Output Module) and the data from those modules is conveyed to the processors via Ethernet. Train control and business CPU modules utilize a 400 MHz CPU with 256MB RAM and 512MB Compact Flash memory. Train control processors utilize



LynxOS 178 operating system while business application processors use QNX. The operating system on the business processor can be changed if an application requires it. In addition to Ethernet, the processors also have RS 232 serial ports and USB connectivity, used for development purposes only, for interfacing to other devices. Each train control CPU uses a dedicated serial port for independent communication of braking commands to the EBI through the TMC internal backplane.

Input/Output Concentrator 6.2.3.4.4The Input/Output (IOC) is a module for use within the I-ETMS chassis and provides for consolidation of a number of functions. The IOC microcontroller consolidates communications to two HDLC ports and 3 asynchronous serial ports. The interface allows bridging between the system Ethernet and system-level serial interfaces. The serial interfaces of the IOC are connected to a GPS receiver, the locomotive event recorder, and to the locomotive control computer (e.g. ICE or IFC). These serial interfaces provide data required for the train control computer calculations such as GPS position, speed, brake system pressures, and throttle control settings (may vary by locomotive). Finally, the IOC provides the system level interface to the locomotive ID configuration data module within the chassis.

I-ETMS Brake Interface Module 6.2.3.4.5The I-ETMS Electronic Brake Interface (EBI) Module, for use within the chassis, provides a vital interface to the locomotive brake system for penalty and a non-vital interface to the locomotive brake system for emergency brake applications. It also provides an interface to the locomotive horn system to allow the system to render horn activation. The EBI Module interfaces to the triple-redundant processor architecture through dedicated communication buses. Aspects of the fail-safe design are described below.

Penalty Brake Interface: The penalty brake interface for the EBI Module is Class II Vital Hardware as defined by AREMA 17.3.3.E. Some characteristics of this interface are as follows:

• No single point of failure in the enforcement circuit will prevent the ability to command a penalty brake application.

• The penalty brake module is continuously tested to verify I-ETMS’s enforcement capability without causing a brake application.

• If the Locomotive Segment loses power, a penalty brake application will occur in a fail-safe manner.

The Locomotive Segment provides penalty brake enforcement by supplying an isolated, two wire, 32V differential signal to the locomotive’s air brake system. This interface may be through an input to the locomotive’s air brake computer or through an interface to the magnet valve P2A circuit on locomotives without an air brake computer.



An explicit penalty brake application occurs when two of the three operational train control processors agree to apply the brakes (or actively fail to hold off penalty application). If one processor is in a failed state, only one of the two remaining functional processors needs to request a brake application for it to occur. If more than one processor is faulty, the penalty brake is automatically applied in a fail-safe manner.

In the event of a fault in the Locomotive Segment where the penalty brake is applied and cannot be released, the manual “Cut-Out” switch provided with the I-ETMS system may be used to isolate I-ETMS from the locomotive’s air brake system, allowing recovery of the air. This switch will be used only under equipment failure conditions and its state is monitored through a connection to the EBI.

If the position of the switch changes from “Cut-In” to the “Cut-Out” state or from “Cut-Out” to the “Cut-In” state, the change is reported to the rest of the Locomotive Segment and is logged onboard and in the Office Segment. When the physical I-ETMS cutout switch is changed to Cutout, the I-ETMS system no longer has a connection to the braking system and will change the logical state to Cutout. To protect against a false Cutout indication the onboard system will trigger a brake application upon the switch change to Cutout. For changes from Cutout to Cut-in, the system will remain in the logical Cutout state and require an Initialization to get back to the controlling state. Prior Departure Tests are voided when the I-ETMS Cutout Switch is changed to cutout, so the new initialization (cut-in) will require a Departure Test to ensure the I-ETMS connection to the brake system is working.

Emergency Brake Interface: Another aspect of the EBI Module is the ability to command an emergency brake application (non-vital implementation). This is accomplished through a magnet valve connection to the brake pipe. An emergency brake application will only be invoked when the Locomotive Segment determines that a previously invoked full-service penalty brake application was not sufficient to prevent a violation of authority limits. Invoking of the emergency brake application is limited to conditions which require predictive enforcement. For example, in the event of a revoked authority, if the revoked authority is one in which the train is NOT currently located, its revocation may or may not result in a predictive enforcement (including potential emergency enforcement), depending upon the proximity of the train to the authority limit and its predicted braking distance. Emergency enforcement brake applications will be rare and only occur upon gross mismatch between predicted and actual train braking performance. A “gross mismatch” is defined as any distance beyond the speed target. Some characteristics of this emergency brake interface are as follows:

• If the system loses power, an emergency brake application will NOT occur.

• An explicit emergency brake application occurs when a penalty brake application has first been invoked, the reduction in brake pipe pressure has been detected at the rear of the train or sufficient time has elapsed to permit the brake pipe reduction to reach the rear of the train, and two of the three operational train control processors agree to apply the emergency brake.



• If one processor is in a failed state, the two remaining processors both need to request a brake application for it to occur. If more than one processor is faulty, then the I-ETMS system has already gone into a full service braking state. Since this braking event due to two faulted processors is not a predictive enforcing event, the emergency brake cannot be commanded from the I-ETMS system.

Justification for the non-vital implementation of the emergency brake is provided in Appendix NN of this PTCSP.

Horn Interface: The Locomotive Segment provides automatic horn activation in the event that the locomotive engineer fails to sound the horn while in approach to a rail-highway crossing at grade when required. The automatic horn activation is resident in all installations of I-ETMS, but is configurable by the individual railroads. A railroad may configure the horn function in one of two manners: continuous or sequenced. Metrolink does not use the sequenced horn functionality. In addition, to accommodate quiet zones, each crossing may be designated as a quiet zone within the track database in accordance with the conditions of approved quiet zones. When the locomotive engineer actuates the horn, the Locomotive Segment ceases its actuation. Some characteristics of the horn interface are as follows:

• No single point of failure in the horn interface circuitry will prevent the ability for a locomotive engineer to sound the locomotive horn.

• Based on pre-configured data values stored in memory in the #subdiv file, the system may command the locomotive horn to be sounded as a continuous blast.

The horn is sounded when commanded by the locomotive engineer, or when any one of the three operational train control processors determines the need to sound the horn. Discrete logic that accounts for the faulted status of each processor determines which of the three processors is capable of controlling the sounding of the horn to prevent multiple processors sounding the horn simultaneously.

Discrete Input/Output Module 6.2.3.4.6The Discrete Input/Output (DIO) Module used within the I-ETMS chassis provides a consolidation of digital and analog inputs from both high voltage signals and low voltage transducers. The module accepts discrete inputs from multiple high voltage sensors, broken into discrete groups for situations where isolated returns are required. The module also accepts analog inputs from a high-voltage traction motor current sensor and low-voltage sensors for signals such as brake pipe pressure, brake cylinder pressure, and equalizing reservoir pressure. Speed from the locomotive axle alternator is also measured through the DIO module. At a system level, the DIO module provides locomotive operational data for non-electronic models (e.g. SD40, GP38, etc.) and also provides a redundant data source for locomotives with an electronic control system.



Signals read from external interfaces are considered “raw” signals. The I-ETMS application software processes raw signal (or sets of raw signals) by “validating” and “conditioning” them to produce a PTC signal to be used by the system. PTC signals can be used to generate other PTC signals. The PTC signal generation process is as follows:

• Signal Validation – performed on each raw signal by interface handling function

• Read raw signal from sensor

• Validate signal (signal presence, signal in proper format, signal within proper range, etc.)

• Submit raw signal and associated validity

• Capture required raw signal and validity (1 to n raw signals required to generate particular PTC signal)

• Capture required PTC signal and validity (1 to n PTC signals required to generate particular PTC signal). See Section 3.1 of the Platform Analysis which is contained in Appendix G.8. 1 to “n” raw signals is based upon the signal and the train configuration. A series of checks is implemented to assess the validity of the signal. Each type of signal may have different checks.

• Perform signal conditioning process to generate a PTC signal.

The locomotive configuration determines which raw and PTC signals the PTC signal conditioning process uses. Raw sensor signals no longer have a priority associated with them, instead, each raw sensor signal will have a source identifier (Loco Date, LIG, Discrete Sensor, etc.) associated with it. The conditioning process for each PTC signal can determine, based on the configuration, which of these raw sensor signals to use when formulating the PTC signal. The I-ETMS on-board segment supports the following standards including raw sensor signals:

• LSI (Locomotive Standards Integration)

• ACP (Asynchronous Communication Protocol)

• LIG (Locomotive Interface Gateway)

• TMC-DIO for locomotives with no electronic control system



Metrolink locomotives and cab cars are all configured to use the TMC-DIO configuration. See the I-ETMS® TMC Platform Safety Analysis in Appendix G.8 for additional detail.

Router/Switch Module 6.2.3.4.7The Router/Switch Module (RSM) provides the communication backbone for all modules within the chassis and for a number of components outside of it. The RSM is an Ethernet switch providing a dedicated, internal switchport for each of the other 9 slots within the chassis (the 5th slot holds this module). The RSM Ethernet switch also provides five external switchports for networking other systems with the TMC. Train control processing takes priority over any business application. Priority for the I-ETMS application is ensured by separating business applications onto a separate CPU processor (Slot 4). This prevents any processing conflicts with the I-ETMS application. Metrolink does not implement any business applications in the TMC. The external switchports terminate at connectors on the front of the RSM to support connection to devices such as the Cab Display Unit (CDU), PTC Crash Hardened Memory Module (CHMM), maintenance laptop, or communication systems.

Cab Display Unit 6.2.3.4.8Metrolink has installed Cab Display Units (CDUs) as described below: The crew interface to the Locomotive Segment is provided by one Cab Display Unit (CDU). The CDU contains a 640x480 LCD monitor with a series of eight function keys located along the bottom or top of the display for use as soft-keys. The CDU is based upon a PC-class processor and interfaces to the processor modules through an Ethernet link. The PC-class processor is an AMD 500 MHz Geode LX800 with 512 MB flash memory and runs a Linux 3.0 Kernel Series OS. Audible alerts are generated through a single, external Sonalert® device. Illumination of the CDU is provided by an internal fluorescent backlight with dimming control. Crews have been trained on the procedures to use in the event a backlight failure occurs. The Wabtec CDU is shown in Figure 6-8. I-ETMS has been designed to accommodate two CDUs, the second of which is non-interactive. CDU-Non Interactive has the same dimensions and physical appearance as the CDU-Interactive. The existence and location of the CDU will vary by class of locomotive per the mounting location survey and human factors described in Section 7 of this PTCSP. It is noted that Metrolink has only one crew member (the locomotive Engineer) assigned to perform duties in the locomotive, hence a single display (CDU) is installed to display the PTC information in the controlling compartment of the locomotive or cab car.



Figure 6-8 I-ETMS Cab Display Unit

Locomotive ID Module 6.2.3.4.9The Locomotive ID Module is a single-wire, serial Electrically Erasable Programmable Read Only Memory (EEPROM) device embedded within the locomotive wiring. This device, which interfaces directly to the TMC, is used to store installation/configuration information on the locomotive. This allows the TMC unit to be replaced on the locomotive without losing the installation/configuration data associated with the locomotive.

GPS Receiver 6.2.3.4.10The Locomotive Segment utilizes one (or more) external GPS receivers to determine location and to drive the train control navigation algorithms. The standard receiver used in this system provides 3m (95%) accuracy when WAAS correction information is available through the satellite system. This GPS accuracy level, when used along with navigational aids such as switch position, provides the 2m overall position accuracy required by FRA for I-ETMS to determine on-track position. Initial track selection when parallel tracks are available is handled by a separate process. GPS data is provided by a receiver connected through TMC IOC serial ports. If two receivers are utilized by a railroad, additional checks on data are performed which allow the system to operate in the absence of one receiver for greater fault tolerance. The Metrolink GPS Receivers are Wabtec P/N 28914P NSM-04, and two (2) units are used for all locomotive model types including cab cars. Position and speed information from each receiver will first be validated against previous position and speed information to discard erratic reports. The basis for



evaluating speed reports will be to use a maximum acceleration or deceleration rate for the train (based upon worst case train weight, number of locomotives, and braking force) and to compare currently reported speed against prior reports. If the reports differ by more than the allowable acceleration limits, speed will be considered invalid within that report. The same principle will be used for position where a maximum positional change will be considered valid based upon the same acceleration or deceleration limits, as defined for the relevant locomotive unit. After the first validation check has been completed, valid results from each receiver are independently evaluated based upon GPS NMEA Quality and Dilution of Precision (DOP) values from each receiver. The solution with the best DOP will be selected to yield the PTC GPS Speed, Latitude, Longitude, Altitude, and Heading signals. Number of satellites, HDOP, and Quality values will be reported from the GPS receiver selected. Altitude and direction information is not used by the Locomotive Segment, but that data is provided to Energy Management. Energy Management is not used by Metrolink. Those signals from each receiver will be averaged over an interval of 5 seconds and if the standard deviation of those samples exceeds 10ft for altitude or 5 degrees for heading, the signal for that receiver is considered invalid. Only 1 valid GPS signal is required to determine the locomotive’s location. If a valid GPS signal is lost to the TMC, the system is capable of dead reckoning with decreasing accuracy of position resolution as distance is accumulated. The I-ETMS on-board segment accumulates position uncertainty at a rate of 4.01 meters per mile traveled while dead reckoning. When the position uncertainty reaches a threshold defined by TBC201, a common parameter for all railroads using I-ETMS with a current value of 50 meters and a range of 1-57 meters, the on-board segment state will declare the locomotive track location and direction of movement unknown. If the current on-board segment state is Active, it will degrade from Active to Disengaged after notification to the crew. After being disengaged, the PTC system no longer enforces penalty conditions but limits the train’s speed as described elsewhere in this PTCSP document. The engineer is presented with a prompt indicating that the train is in the “Disengaged” state and penalty braking will occur in 30 seconds if the prompt is not acknowledged by the engineer.

Locomotive Event Recorder 6.2.3.4.11The Locomotive Segment obtains some status information by monitoring the locomotive data sent to an existing I-ETMS compatible locomotive event recorder including indications from the locomotive train line for the discrete and pneumatic pressure values. The Metrolink PTC system features an additional Wabtec PTC Event Recorder which is synchronized with the standard locomotive FRA event recorder to record both PTC and locomotive parameters as required by the Subpart I regulation noted below, Synchronization is achieved through:



1) Customized software installed on both the Standard Locomotive Recorder (Bach-Simpson) and the new PTC Event Recorder, and

2) Additional Legacy Link cable connecting the two recorders.

3) All recorded data (ERS and PTC sources) preserve the original timestamp from the source data and adds a common timestamp from the battery-powered Wabtec PTC Event Recorder’s Real Time clock.

4) Synchronization of all data streams are performed in the Wabtec Data Analysis Software (DAS III). By default, DAS III use the PTC system time as the basis of displaying data source. Both the internal timestamp, as well as the timestamp of the data source are displayed.

Standards defined in §229.135 and §236.1005(d)(2) provide the requirements for event recorders, including requirements for crashworthy event recorder memory modules for locomotives originally ordered on or after October 1, 2006, and placed in service after October 1, 2009. I-ETMS is also capable of supporting an open standard recorder. Data logging and recording of I-ETMS PTC operations has been tested with the Wabtec PTC Data Recorders, currently in use on all Metrolink locomotives and cab cars. PTC data supplied by the TMC to the PTC Data Recorder has been downloaded via Wabtec’s Data Analysis Program (III) tool and the data verified and validated. Data from the TMC to the PTC Data Recorder are verified and validated by:

1) A laptop computer which connects to either the PTC Recorder port J2 or the TMC port J2 via an RJ45-M12 Ethernet cable.

2) Performing data downloads via a web page interface on the laptop, as detailed in WPN 24-11-18278, PTC Recorder Download Guide for Metrolink.

3) Performing Data Recording system installation and validation, and recording results for each vehicle, according to Wabtec Document FMA-274

The crash hardened memory module is connected to the Ethernet Switch physically located in the TMC.

Train Control Application 6.2.3.4.12The Locomotive Segment continuously computes both safe braking and warning distance curves to provide both predictive and reactive warnings and enforcement. Braking and warning curves are calculated based upon train and track characteristics and locomotive control settings. Curves are compared to authorized speed profiles generated from authority and speed limit data. The train’s current authority limits are derived from applicable signal indications and/or movement authority provided by the railroad dispatching systems. Permanent speed restrictions are established from the I-ETMS track database. Temporary Speed Restrictions (TSR’s), provided by the railroad dispatching systems, may impose additional enforceable restrictions on the train.



Predictive warnings provide the opportunity to respond to signal indications requiring a stop or reduction in speed, overspeed conditions, improperly lined switches, or work zones in advance of the train. If sufficient action is taken to properly control movement of the train, the warning is cleared. Failure to take sufficient action to control train movement in response to a warning, will result in a full-service penalty brake application when the train reaches the calculated safe braking distance to the restriction. Once a penalty brake application is initiated, a PTC equipped train must come to a complete stop before the brakes may be released. Reactive warnings may provide the opportunity to respond to the warning and properly control train movement. Under certain conditions, such as revoked authority, signal changing to red, switch going out of correspondence, etc., reactive enforcement braking may be initiated without prior warning. This is described in the PTCDP, which is located in Appendix B of this PTCSP. The CDU provides a series of graphical and textual displays as shown in Figure 6-9 - Primary I-ETMS Display Screen - Graphical Elements and Figure 6-10 - Primary I-ETMS Display Screen - Textual Elements. Note these two figures do not represent actual displays; displayed elements have been enabled to show placement. A description of the HMI standards implemented for I-ETMS can be found in AAR specification S-9070.

Figure 6-9 Primary I-ETMS Display Screen - Graphical Elements



Figure 6-10 Primary I-ETMS Display Screen - Textual Elements

Current speed, locomotive ID, and system state are always visible along the top edge of the display, even when warning or enforcement messages are displayed. In the event of an I-ETMS warning or enforcement, any non-safety critical data becomes subordinate and full display attention is given to data pertinent to the safety critical event and I-ETMS functions. I-ETMS stores log information to an external recorder in accordance with §229.135 as required.

Business Applications 6.2.4Metrolink’s I-ETMS PTC system does not employ the use of I-ETMS “Business Applications”. There is no information displayed on Metrolink’s CDU with regards to “Business Applications”.

Metrolink PTC System Configuration Parameter Selections 6.2.5I-ETMS Configurable Items are found in Appendix LL of this PTCSP. This contains a complete list of the configurable items available in the I-ETMS system and explains each configurable item and provides the ITC governed Common parameter values. Metrolink document SCRRA-PTC_GDE-0101 METROLINK Specific Parameter Guide Rev 1.1, which is included in Appendix LL.3, provides the values assigned by Metrolink to the Railroad selectable parameters. This configuration guide provides configuration details for the On-board segment of the I-ETMS™ system. Each section details the name of a configuration file and the type of



information needed for that file. The user guide contains a comprehensive list of configuration files required to operate the On-board segment. Detailed examples of the format for a particular configuration file are provided when possible. The parameter configuration document in Appendix LL is arranged into 3 sections. Section 1 of the document gives the introduction to the topic of parameter selection. Section 2 of the document describes certain configurable items that are common to all interoperable I-ETMS railroads. These settings are expected to be included identically in the file structures of every railroad that needs to interoperate, including Metrolink. Obviously, any change to the selections of these configuration items must be agreeable to all interoperating railroads and then be updated across the entire locomotive fleets of all affected railroads. Section 3 of the document describes configurable items for the I-ETMS On-board that are set to Metrolink preferences, tailored for operation per Metrolink rules and procedures, as well as for the communication infrastructure and protocols in place. The current railroad common and Metrolink-specific selections for these sets of configurable items are given in Appendix LL. These selections are subject to change and are part of the Configuration Managed variables in the design of the Metrolink I-ETMS PTC System. In the configuration parameter table the following columns are defined as follows: Owning Railroad: The railroad that owns or leases the locomotive on which the I-ETMS on-board segment is installed. Operating Railroad: The railroad that dispatches the track at a particular location. This railroad is identified in the track data for the subdivision / district. Employing Railroad: The railroad that employs the person operating the I-ETMS on-board segment. The valid range is determined by Wabtec. The railroad configurable filesets include:

• params_SCAX.cfg

• params_THE_SCAX.cfg

• BOSPolygon_SCAX.cfg

• params_comm_SCAX.cfg



6.2.5.1 Process for Modification of Configuration Parameters

Modification of Railroad Common Configuration Parameters 6.2.5.1.1Any modification of railroad-common Configuration Parameters must be proposed to the ITC and then, if approved, incorporated in all railroad units affected by the change throughout the industry. Such changes should only be proposed where safety or proper operation of PTC are jeopardized. These changes will only take effect when broadcasted to all railroads by the ITC or other governing industry body, and not before. The changes to the railroad Common Configurable Parameters are introduced when a change to the Wabtec I-ETMS system occurs for all deploying railroads, and these changes are tested by SCRRA on Metrolink before implementation. In addition, a local Control board shall be formed for the southern California railroad’s (BNSF, UPRR, Amtrak, NCTD, and SCRRA) and convened to jointly analyze the common changes recommended by the ITC for impacts on the Southern California operating area. The local control board may recommend changes in the course of action specified by ITC. The industry configurable parameter configurations are referenced in Appendix LL.2 of this PTCSP.

Modification of Metrolink-specific Configuration Parameters 6.2.5.1.2The changing of any of the Metrolink-specific configuration parameters is handled through the Metrolink Configuration Management process defined by the Configuration Management Plan (CMP) (see Section 17 and Appendix P). Changes to these railroad-specific parameters are a form of Deployment Management, requiring that a change request be provided to the Metrolink Change Control Board and the appropriate process to be followed to implement the railroad-specific change in parameter(s). Note that coordination with the ITC is not necessary for railroad-specific parameter changes, so when the CCB determines the change to be appropriate, it can be implemented. This is done through variable data changes in the affected equipment and documented for future reference. These changes do not affect the existing version of the hardware or software deployed on Metrolink. The Metrolink Configurable Parameters are discussed in Appendix LL.3 of this PTCSP.

Interoperable Architecture from PTCDP 6.2.6The Metrolink PTC System is interoperable with the PTC systems that are being deployed in Southern California by the UPRR, Amtrak, NCTD, and BNSF. Interoperability refers to the ability of trains to cross property boundaries under PTC at territory speed without stopping to acquire authorities. Interoperability includes reliable communication from Back Office to Train, Train to Back Office, Back Office to EIC, EIC to Back Office, Train to Wayside and from Wayside to Train. The Metrolink PTC System also provides networked communications with the BOS or Back Office of the interoperable railroads according to negotiated protocols. Metrolink’s PTC, as well as the UPRR’s, Amtrak’s, NCTD’s, and BNSF’s PTC systems, are compliant with the existing Standards and Specifications developed by the Interoperable Train Control (ITC) Committee for the Association of American Railroads



(AAR). [11] [12] [13] [14] [16]. The Metrolink PTC system is able to share common product engineering with BNSF’s and UPRR’s I-ETMS PTC systems and is able to communicate with the systems on both of the freight railroad’s properties. The SCRRA/Metrolink PTC System is interoperable as:

• Both Host and Tenant with the UPRR and BNSF; • Host to the tenant Amtrak; • Tenant on NCTD.

All SCRRA trains and SCRRA tenant trains are equipped with on-board equipment that is interoperable with UPRR and BNSF. The UPRR, in conjunction with others, has developed an AAR standard practice protocol for Interoperability between properties across the extended North American railroad infrastructure.

Since UPRR and BNSF are both host and tenant with SCRRA, the Metrolink PTC System considers those parts of the message assigned by the AAR Standard Practice as the standard and conforms to this convention. Enhancements added to the SCRRA/Metrolink PTC System are found in a different portion of the message than those which are considered fixed assignments on the AAR standard message string.

The SCRRA message enhancements are not considered as changes to the standard I-ETMS system and are used for Metrolink-specific monitoring only. Their inclusion is a territory-specific addition to the system which ultimately does not affect the safety of the AAR standard message(s). The message context is interoperable communication between all segments and railroads.



7 Final Human Factors Analysis [§236.1013(a)(5)] [§236.1015(d)]

This section describes the Final Human Factors Analysis as required by 49CFR §236.1015(d) that builds on the preliminary human factors analysis contained in the referenced PTCDP in accordance with 49CFR §236.1013(a)(5).

7.1 Final Human Factors Analysis of CDU SCRRA includes the final Human Factors Analysis of the I-ETMS® Cab Display Unit (CDU) that was conducted by an independent third party expert contractor, Daedalus, in Appendix C.1 of this document. The work is based on the Preliminary Human Factors Analysis, as identified in the “Interoperable Electronic Train Management System (I-ETMS®) Positive Train Control Development Plan (PTCDP)” in compliance with §236.1013(a). The final human factors analysis has been performed in compliance with §236.1015(d). The primary objective of the Final Human Factors Analysis (HFA) Report is to perform a Heuristic Evaluation and Cognitive Walkthrough of the user interactions with I-ETMS. The comparison is contained in the Final HFA document in Appendix C.1 of this PTCSP, and applies to all railroads that are deploying I-ETMS. Actions are as noted in the comments and responses that are included in the report. In addition, an evaluation was done on the Daedalus analysis report to identify if there were any material impacts on the results resulting from a passenger locomotive application rather than a freight application. The primary difference between the applications in regards to the human factors analysis for Metrolink is that Metrolink operates with a single Engineer in the cab versus an Engineer/Conductor pair as in current typical freight applications. Since there are no material differences in the CDU screens between the two, and the Daedalus analysis of the screens contained no concerns that were mitigated by having a conductor present, the conclusions drawn are applicable to either application. The more applicable comparison is centered around the cognitive workload of the Engineer. The cognitive workload assessment is contained in Sections 9, 10 and 11 of the report in Appendix C.1 of this PTCSP. There were three subsections in Section 10 of the report that identified situations where the cognitive workload of the Engineer could be increased. Section 10.6.1.3 discussed the situation in which the Engineer’s cognitive workload could be increased by having electronic-only-delivery of Mandatory Directives received enroute. The report cites having the Conductor available as a potential mitigation to this increased workload. Metrolink has no plans to implement electronic-only-delivery of Mandatory directives and will reevaluate this issue if it ever decides to pursue implementation. Section 10.6.1.5 discussed the situation where cognitive workload could be increased when electronic-only-delivery is implemented and the Engineer had to review new information received and decide to reject or accept it. The report cites having the Conductor available as a potential mitigation to this increased workload. Metrolink has



no plans to implement electronic-only-delivery of Mandatory directives and will reevaluate this issue if it ever decides to pursue implementation. Section 10.9 concludes that the cognitive workload of the Engineer is likely to be increased in interacting with the Energy Management banner. Metrolink has no plans to implement the Energy Management function of I-ETMS and will reevaluate this issue if it ever decides to pursue implementation. In conclusion, an evaluation of the Daedalus Human Factors Analysis report found no instances where the absence of a Conductor in the Cab or the operation in a Metrolink passenger locomotive environment adversely impacts the conclusions of the analysis.

7.2 Metrolink On-Board PTC Equipment Location Review Process The Human Factors Analysis for the I-ETMS® CDU is supplemented by an ergonomic analysis of the placement and orientation of the on-board PTC CDU display in the PTC-equipped locomotives and cab cars, and its effect on operations within the Cab environment. Staff, including locomotive Engineers, participated in mock-up and prototype surveys to ensure that the PTC equipment is convenient for use, and that any displaced devices have been moved to suitable locations based on human factors and their criticality to safe train operation. The primary purpose of this review was to gather feedback on the proposed placement of the PTC Cab Display Unit prior to installation and to help ensure good human factor standards are taken into account. A plan and a checklist were developed for the reviews and considered in the placement of the equipment during installation. It is noted that Metrolink has only one crew member (the locomotive Engineer) assigned to perform duties in the locomotive, hence a single display (CDU) is installed to display the PTC information in the cab.

Metrolink On–Board PTC Equipment Location Review 7.2.1Three types of Metrolink controlling equipment (H-R Cab Car, MP36 PH-3C Locomotive, and F59PH Locomotive) were used in the analysis. One of the remaining two types of Metrolink locomotives (F59PHI Locomotive) is a sub-set of the F59PH unit type and the analysis performed for the F59PH was directly applicable. The remaining locomotive unit (F40PH) is a single unit in the Metrolink fleet and was, therefore, not separately part of the formal analysis but equipped based upon the general findings of the analysis performed on the other like units. The reviews focused on inputs from the personnel whose daily work responsibility includes operation of the vehicles and several of their supervisors. The reviewer group was broken into several small groups and the review was facilitated by SCRRA and V/I personnel. Each group was given a presentation of the PTC system to provide an introduction to:

• the PTC and system overview, • the crew interface navigation, • the procedure for the mock up review, • a walkthrough of each of the three mock ups



Upon completion of each session a general re-cap discussion followed the actual review and comments. The training presentation, “Positive Train Control On-Board Mock Up Review”, is contained in Appendix C.2. The consensus review comments of each review group, and a report of the mock-up reviews is documented in “Mock-up Review Report: H-R cab car, MP36 PH-3C Locomotive and F59PH Locomotive” and is contained in Appendix C.2 of this document. Based on the consensus of the review comments, modifications to the on-board layouts were developed, and reflected in Appendix C.2 of this document. Another round of reviews was performed to verify the suitability of location of CDUs and other re-located devices and indicators. The final step in the cab layout human factors study was to perform reviews in the actual cab environment after a pilot/prototype installation of the PTC equipment in each cab type. Consensus on the suitability of location of the PTC cab equipment allowed the remainder of the fleet to be updated.

Metrolink On-Board PTC Equipment Location Review Findings 7.2.2A report on all of the analyses and the results is documented in “Human Factors/Ergonomic Evaluation of CDU Placement” and is contained in Appendix C. The report includes any Operator concerns with the CDU and any relocated devices. The process used to determine the layout of each cab type and the associated modifications made are also summarized. The remainder of this section highlights the key points contained in the “Human Factors/Ergonomic Evaluation of CDU Placement”. In January 2012, SCRRA and its PTC Vendor/Integrator completed the multi-step human factors/ergonomic (HF/E) review of the PTC Cab Display Unit (CDU) placement in each of the cab types in the operating fleet. The review was undertaken as part of SCRRA Contract No. H1636-10, Positive Train Control (PTC) System, and in conformance with 49CFR 236 Appendix E which requires the railroads to conduct human factors/ergonomic analysis in terms of CDU location and its usability. With the completion of the CDU placement review with the train Operators, the HF/E requirements of 49CFR 236, Appendix E were satisfied, and the Vendor/Integrator (V/I) possessed sufficient information to complete the design of each cab in the areas affected by the installation of the PTC equipment. For the SCRRA applications, the CDU is housed at the same general position in the forward left portion of the desk console within acceptable limits for hand reach and viewing. The report provides a summary of the sessions conducted with the SCRRA Operators in preparation for the implementation of PTC. The report focuses on the concerns identified by the Operators in relationship to the new on-board PTC equipment installed in each cab and to the existing cab components that were relocated to accommodate the PTC equipment installed. In introducing the locomotive Engineers to



the changes, the review process, transitioned from mock-ups using cut-outs to represent hardware to the pilot installations using actual hardware. The multi-step review process followed by SCRRA was structured as a human centered approach that actively involved the Engineers, Road Foremen and Supervisors. The same core group of Engineers was present for each session of the review process. The iterative approach allowed the design team to evaluate the Engineers’ comments and to study different equipment placement scenarios in order to evaluate the usability needs of the Engineers and the placement of the on-board system components. The process utilized three (3) different mock-ups and five (5) pilot installations, one for each of the cab types in the SCRRA fleet of vehicles that are equipped with an on-board PTC system. There were three (3) sessions conducted and the sessions are summarized as follows: Session 1: Review of Mock ups at Central Maintenance Facility (CMF) with SCRRA personnel and road foremen at CMF. Review of Mock-ups at CMF with SCRRA/Amtrak Operators. Review of Mock-up with SCRRA, PTG, Wabtec and Hyundai-Rotem (H-R) to review the changes required for PTC installation and coordinate efforts to allow H-R to evaluate changes. Session 2: Review at Keller Yard by multiple SCRRA/Amtrak Engineers and road foremen of pilot installation for the F59PH locomotive and the prototype installation for the H-R cab car. At this time, the CDU for the H-R cab car was mounted on a cantilevered support arm. Session 3: Review at Keller Yard by one (1) SCRRA road foreman of pilot installation for the F40PH locomotive, MP39PH locomotive, and the prototype installation for the H-R cab car. At this time the console in the H-R cab area had been modified to accept the CDU, to enhance its access and to allow visibility through the center windshield. Review at Keller Yard by multiple SCRRA road foremen of the pilot installation for F40PH locomotive, MP39PH locomotive, and the prototype installation for the H-R cab car. Review at Keller Yard by multiple SCRRA/Amtrak Engineers with the equipment configured the same as presented on December 19, 2011. Review at Keller Yard by one (1) SCRRA/Amtrak Engineer with the equipment configured the same as presented on December 19, 2011. For the on-board PTC equipment, the HF/E exercise focused on the usability aspects of the cab display unit (CDU) as related to the PTC specific tasks being performed by the Operators. As a secondary objective, the feasibility of locating the PTC equipment that requires interaction with the Engineer in the same relative location in all cab types was examined. Having the equipment in the same relative location allows the Engineer to maintain the same eye reference to recognize and react in the same manner to PTC



stimuli, regardless of the particular cab being used to control the train. The review process successfully satisfied both objectives. The scope of the report is limited to the HF/E examination of the CDU in the various operating cabs in terms of visibility and access, and the relocation of any displaced equipment. The human machine interfaces (HMI) dealing with design aspects such as screen colors, location and format of information displayed, functions associated with operation of hard and soft keys, are controlled by the Association of American Railroads (AAR) – Interoperable Train Control (ITC) group and were not considered within the CDU location report.

7.3 Other I-ETMS Human Interfaces and Their Analysis for Human Factors CAD Operator/Dispatcher interfaces 7.3.1

There are no Human Interfaces with the CAD system that are either new or unique to the PTC system and therefore there is no need to have an HFA performed as part of this PTCSP. For example, when delivering an authority to a train, the train dispatcher is required to use CAD's "read and repeat" function. The PTC enhancement to CAD, working transparently in the background, sends the output of the transaction to the BOS which sends it to the on-board. The field signaling polices the dispatcher requests with vital signal logic. PTC polices with On-Board, BOS, and wayside devices. Dispatcher is not part of vitality. He/she is the action requester in the process.

Wabtrax Tool for Track Database Configuration 7.3.2The Wabtrax software tool is a tool utilized by the developers of the subdiv database files and has a user interface designed for expert programmers to input the specific data that forms the downloadable database used by the BOS and the I-ETMS on-board TMC unit. The human interface is intended for users with substantial software experience and has not been tailored for the general I-ETMS user population. Therefore, a Human Factors Analysis of this user interface is not needed in this PTCSP.



8 Safety Assessment and Application of 49CFR 236, Appendix C [§236.1015(d)(5)] [§236.1015(e)(2)(ii)] [49CFR 236, Appendix C]

As required by 49CFR §236.1015(d)(5), this section of the PTCSP provides a complete description of the safety assessment and Verification and Validation processes applied to Metrolink’s PTC system, the results of those processes, and whether these processes address the application of the safety principles described in 49CFR 236, Appendix C directly, using other safety criteria, or not at all.

This body of work describes a program which efficiently, effectively, and critically evaluated the system. Safety critical components, like those employed in I-ETMS, require a level of rigor and discipline that must be adhered to throughout the build process from requirements to implementation and support. This section of the PTCSP addresses several means by which Metrolink PTC system was assessed.

The goal of the system safety process, Verification and Validation, and compliance with 49CFR 236, Appendix C is to ensure that the development, functionality, architecture, installation, implementation, inspection, testing, operation, maintenance, repair, and modification of I-ETMS will achieve and maintain an acceptable level of system safety.

8.1 Safety Program Scope for I-ETMS

The system safety program and the applied safety assessments for I-ETMS concentrate on the installed elements of PTC and the interfaces to the existing railroad systems and operations. Because the system is a level of control overlaid on existing operations, only the additions and changes that are directly attributed to PTC are included in the safety case. Figure 8-1 depicts the I-ETMS system safety scope.



Figure 8-1 Scope of I-ETMS System Safety

As shown in Figure 8-1 and described in detail in the I-ETMS® PTCDP, I-ETMS consists of four segments: the Office Segment, the Locomotive Segment, the Wayside Segment, and the Communications Segment. These I-ETMS segments support interfaces with generally three types of existing systems, which are external to the PTC system and considered under the V&V process umbrella:

1. The CAD or Dispatching system and other railroad Management Information Systems (MIS)

a. Metrolink does not have any interfaces between MIS systems and the PTC.

2. The brake system and other locomotive control equipment a. Interface to the locomotive brake control system is safety

analyzed at the boundary of PTC, exercised throughout V&V testing, and periodically checked for ability to control during I-ETMS Departure Tests.

b. Other locomotive control equipment such as Energy Management is analyzed and confirmed to have no adverse impacts to safety. Metrolink does not employ any energy management systems onboard.

3. The existing, traditional field equipment, where applicable



a. Interfaces to existing field equipment are managed using Metrolink established processes and procedures.

b. Verification and validation for PTC functionality and safety operation via I-ETMS field integration and qualification testing per the Metrolink adopted Master Test Strategy reviewed and approved by the FRA, which is included in Appendix H.1.

I-ETMS utilizes messaging to send information to and receive information from these external systems. The messaging requirements are addressed in [16] of this PTCSP. Each I-ETMS segment manages its external interfaces so that their functions are not compromised by the messaging system. The relevant I-ETMS segment (Onboard, wayside or office):

1. Checks the receipt of messages by the intended recipient.

2. Ensures the timeliness of messages processed.

3. Ensures the completeness of information contained in messages.

4. Assures message content is not corrupted to and from these external systems.

Codes are embedded in each data message that allows the receiver to authenticate the sender of each message and detect any data errors introduced while in transit. The receiver discards any data message in which data errors are detected or for which the sender cannot be authenticated. Section 5.5.6 of the referenced PTCDP provides further details on this behavior. Section 9.6 of the referenced PTCDP further describes communication security. The “System Safety Integration Document” included in Appendix GG of this PTCSP also provides descriptions of how the PTC application verifies messages. In addition, at initial terminal or upon receipt as duties will allow, the train crew will be expected to compare the voiced/printed bulletin against the electronic bulletin to ensure that the data has been received. The reviewable electronic data is a text field sent from the issuing railroad system and does not contain enforceable data. Ability to review the text data insures the bulletin has been received by the Locomotive Segment. Operating procedures have been established for train crews to report discrepancies in bulletins to the dispatcher and take no action that violates the worst case limits of the questionable bulletin. These procedures are contained in the current version of the Metrolink Timetable [28]. Correctness of received data is also inferred by monitoring the PTC map display which is constructed from enforceable data, looking for agreement with the dispatcher-transmitted message. When future “predefined changes” are implemented in the PTC system, crew validation of the message contents will be enhanced by the electronically transmitted bulletin, but not necessary, with the PTC system ensuring the full vitality of the process.



Train crews have been trained to monitor the PTC display for information conflicting with expectations and respond with established railroad operating procedures. For specific hazards and their mitigations, refer to the Hazard Log provided in Appendix D of this PTCSP and the training plans listed as an available document in Appendix K of this PTCSP. Some interfaces are defined as standard, and these are defined by requirement and interface control documents (ICDs) issued by the AAR or others (see Section 2 of this PTCSP). Other interfaces are railroad-specific, as in the interface to the customized CAD system. These interfaces are defined in the requirement and interface control documents specific to Metrolink. The standard ICDs released by the AAR are available through the AAR. Metrolink’s railroad-specific ICDs are managed and controlled through Metrolink’s configuration management process and are available from Metrolink upon request. The communications systems and networks used for both internal and external PTC messaging to support I-ETMS are part of the Communication Segment. No safety-critical requirements have been allocated to the Communication Segment, as discussed in Section 3.3 of this PTCSP. In order to protect data that is being transmitted and detect transmission errors; the vital onboard and wayside subsystems assure fail-safe behavior in the event of communications-related faults. The PTC safety program demonstrates that the arrays of data used or generated by the system are protected against plausible corruption and errors that appear at the interface point, as well as within the system itself. Reference sections 5.5.6, 5.5.7, and 9.6 of the Type Approved PTCDP as well as the “System Safety Integration Document” in the Appendix GG of this PTCSP for more details on the system behavior for data security and integrity that protects against message corruption and errors. Additionally, the vital nature of the existing field equipment, where installed, is verified and validated by field equipment vendors. The WIU interaction with the existing field equipment is tested according to the Wayside Verification and Validation Plan provided in Appendix JJ of this PTCSP. This plan describes how proper operation of the WIU input and outputs are validated and verified. Disarrangement testing was conducted during WIU installation. Existing microprocessor locations were upgraded with integrated WIU modules. As part of the upgrade, new application programs were installed and in the majority of cases a full signal cutover was performed. In a few locations, only strategic changes were made to the application program and a commensurate amount of testing was performed. Testing was done as normal signal testing and appropriate records compiled and maintained as required by procedures and regulation.

8.2 I-ETMS System Safety Program Plan (SSPP) I-ETMS has been designed to provide a set of PTC functionalities that can be applied by freight and passenger railroads on an interoperable basis. In order to manage the safety case of the core I-ETMS system, a System Safety Program Plan (SSPP) was established by Wabtec Railway Electronics (WRE). Metrolink reviewed and approved



the SSPP jointly with other I-ETMS implementing railroads. This SSPP provides general guidance for all safety activities as well as identification of deliverables that have been provided to, or required from, implementers of I-ETMS. The SSPP includes:

1. Overall purpose, scope and objectives 2. System safety program control – schedule, identification of

deliverables, and organization 3. Processes for executing hazard and failure analyses, hazard log,

etc., 4. Support for peripheral process actions such as audits, defect

notification, investigation support and configuration management

The I-ETMS System Safety Program Plan is provided in Appendix HH of this PTCSP.

8.3 I-ETMS System Safety Process

The System Safety Assessment Process is the complete process applied during the life cycle of I-ETMS to establish safety objectives and to demonstrate compliance with 49CFR 236, Subpart I, and other safety requirements. The safety assessment process, as shown in Figure 8-2, provided a methodology for assurance that all relevant failure conditions were identified and that the combinations of those identified failures were considered. If an identified failure mode was designed out (meaning no longer part of the design), it would no longer be considered relevant. A system hazard must be applicable to the failure mode, and related to the design as implemented.

As shown in Figure 8-2, the system requirements feed the Preliminary Hazard Analysis (PHA), whose results drive the Functional Fault Tree (FFT) and are recorded in the Hazard Log (HL). The system requirements also feed the FFT, along with the system architecture and the Hazard Risk Index results. The FFT terminal events drive the SSHA for each segment. From the SSHA, safety requirements for hardware and software are generated as mitigations, and the design of the segment hardware and software is executed.

The hardware and software designs of each segment are analyzed and verified in the Fault Tree Analysis (FTA) for the segment, and the FTA results are recorded in the Hazard Log. The hardware designs, which contain fail-safe requirements, are verified in the FMEA, which also feeds the FTA and therefore the Hazard Log. A System Hazard Analysis (SHA) also verifies the system design requirements and feeds the Hazard Log as well. Separate safety Verification processes also are performed on the Hardware and Software designs.

The V&V process is described more fully in the section 13.2, “Verification and Validation of I-ETMS”. In order to build a comprehensive and hierarchical set of safety requirements the following activities were performed:



1. All hazards associated with the implementation of a PTC Overlay System scope were thoroughly considered and documented at system and subsystem levels

2. All functional faults, as well as the effect of human error on safe operation that could contribute to system hazards, have been documented

3. All relevant failure conditions and human error that could lead to functional faults were identified, including consideration of combinations of identified failures.

Figure 8-2 – I-ETMS System Safety Assessment Process

The process began with the conceptual design for the PTC system from which many safety requirements for I-ETMS were derived, based on the predecessor Electronic Train Management System (ETMS®) that was developed by WRE.

As the system design evolved to incorporate other railroad operational requirements, changes were made and the modified design was reassessed. Current Metrolink operating practices and governing regulations, with safety as their drivers, influenced many decisions and assumptions made regarding the design of the system. Those decisions were based on the knowledge of operations, technical, and signal and train control function experts from Metrolink and other ITC member railroads, safety engineers, designers, and developers from Vendor companies, or other regulatory requirements for safe rail operations. The process for developing I-ETMS was iterative



in nature, with the system building upon itself in complexity and functionality. The safety assessment process culminated with the verification that the design meets the safety requirements.

The relationship between engineering and safety program activities is summarized in the traditional “V Model” depicted in Figure 8-3.

Figure 8-3 – “V Model” Development and Safety Activities

For I-ETMS, there are five identified “levels” of system composition representing two element areas. The system level “applied” functionality and those that address the execution of the computing platform to manage interfaces and perform processing executive functions and algorithms and safety critical processing:

SYSTEM ELEMENTS

Level Description Element Area V&V Level 1 System level which encompasses the entire

PTC implementation known as I-ETMS System

Application Focused V&V

Level 2 Decomposes the PTC system into four segments: the Locomotive, Office, Wayside and Communications Segments

System

Level 3 Identifies components that comprise a segment

System

PMP / SEMP

REQUIREMENTS ANALYSIS

FUNCTIONAL ANALYSIS

SYNTHESIS ( DESIGN )

IMPLEMENTATION

ACCEPTANCE

VERIFICATION AND

VALIDATION

INTEGRATION

SPECIALITY ENGINEERING

SYSTEMS ENGINEERING

SAFETY ENGINEERING

SSPP

PHA , FFT

SAC

SSHA FMEA

SAFETY FUNCTION CODE VALIDATION SAFETY FUNCTION UNIT TEST

FINAL MITIGATION ARTIFACTS

SEGMENT & SYSTEM SAFETY

REQUIREMENT V & V

COMPONENT & SEGMENT MTTHE &

RA

SYSTEM MTTHE & RA

OPERATIONAL SAFETY TEST

SAFETY REQUIREMENT DESIGN REVIEW

SAFETY ENGINEERING

SHA / FTA



PLATFORM ELEMENTS

Level Description Element Area V&V Level 4 Identifies the modules (HW and SW) that make Platform

Core Product Design V&V

up subsystem components Level 5 Identifies the elements that comprise a Platform

module* *modules generally refer to product components that are considered replaceable units such as electronic assemblies comprised of printed circuit cards.

The split between hardware and software is generally specified during the transition from the segment level to the module level. Segments are a mix of hardware and software. Components may be comprised of hardware, software, or both. Modules are either hardware or software.

Regarding verification and validation activities performed, there are two areas of concentration with a transition at Level 3. A t Level 3 and above, verification and validation is performed on the I-ETMS PTC system functionalities. Below Level 3, verification is mainly concerned with the platform at an equipment design level (e.g., I-ETMS core safety critical equipment design which includes printed circuit cards, embedded software and design of interfaces to peripheral locomotive equipment.) V&V activities at the platform level emphasize review of effects of random hardware failures and errors in software development producing evidence that is intended to satisfy compliance to Part 236, Appendix C principles. This is in contrast to concentrating on the system above Level 3, where V&V activities are focused on ensuring I-ETMS safety critical functionality performs as intended for its application of PTC.

In general, the safety process for I-ETMS has been a set of four major activities repeated for each level of the development effort: hazard identification, assessment, mitigation, and verification. These activities were integrated with the development activities of requirements analysis, functional analysis, and synthesis or design of the system. Ensuring that the mitigation strategies are correctly applied in the next developmental layer or “level” is the goal of safety validation. These four main activities decompose into multiple processes, deliverables, and implementations. Table 8-1 identifies activities used to assess the safety of the I-ETMS positive train control system.



Table 8-1 Safety Assessment Process Activities

Activity Description Process, Deliverable or Implementation

Hazard Identification

Anticipate and identify the effects of failures on the system

Safety engineers and project team resources brainstorm possible failure scenarios Informal hazard analysis processes identify and document hazards via design white papers, tests, meetings, reviews, discussions, individual’s idea, etc. Development resources create failure prevention checklists: software error checklists, etc. Preliminary Hazard Assessments Subsystem Hazard Analyses Fault Tree Analyses Reference to AREMA Quality standards for safety critical or safety related systems Document and track hazards in Hazard Log




Hazard Assessment

Assign a qualitative or quantitative severity and probability of occurrence to any identified hazard causing an undesirable event.

Hazard Risk Index Execute system software development plan Compare actual defect rates from lab testing to predicted defect rate as indicator of system safety state Subsystem Hazard Analyses Fault Tree Analyses

Hazard Mitigation

Reduce the risk posed by hazards

Safety engineers and project team resources develop safety requirements Identify Safety Assurance Concepts that will be utilized in the system Develop mitigation strategies for unacceptable identified hazards to include design changes or addition of requirements Establish traceability between hazard, mitigation, requirements, safety assurance concepts, and implementation Perform critical design review, design for minimal risk Document and track mitigations in Hazard Log Failure Mode and Effects Analysis

Hazard Verification & Validation

Ensure the safety requirements are implemented and provide the desired mitigation while not producing any new hazards

Hardware implementation review Safety engineers and project team resources perform design and code peer reviews Failure Mode and Effects Analysis Verification of Safety Assurance Concept dependencies and assumptions Institute and implement a formal testing program




Design and execute tests for all requirements, specifically safety critical requirements System Hazard Assessment Risk Assessment

After hazards were identified, JRST member roads and WRE convened discussions to assess hazards and apply the Initial Hazard Risk Index and later, the Expected Residual Risk Index. The Initial Hazard Risk Index is the potential hazard risk before any mitigation is applied, as a combination of severity and frequency of occurrence per MIL-STD-882C. The Expected Residual Risk Index is the hazard risk expected to remain after completion of mitigation, represented as a combination of the severity of the consequences and probability of occurrence per MIL-STD-882C.

After mitigations are incorporated per the analysis, the Residual Risk Index is determined based on the mitigations. This Residual Risk Index for the I-ETMS hazards reflects that sufficient hazard mitigation has been applied to allow the system to be safely deployed.

For further details on the Hazard Analysis, please refer to the following Appendices of this PTCSP: Preliminary Hazard Analysis (PHA): Appendix G.1 Locomotive Segment Subsystem Hazard Analysis (LSSHA): Appendix G.2 Office Segment Subsystem Hazard Analysis (OSSHA): Appendix G.3 Functional Fault Tree (FFT): Appendix G.5 Fault Tree Analysis (FTA): Appendix G.6 Failure Mode and Effects Analysis (FMEA): Appendix G.7 System Hazard Analysis (SHA): Appendix G.9 Hazard Log (HL): Appendix D

The safety processes employed in the development, design, test and implementation of I-ETMS assure safe operations that exhibit no hazardous events under normal operating conditions as well as under failures, while accounting for human factor impacts, external influencing, and procedures and policies related to maintenance, repair, and modification of the system. All requirements were verified and validated via test, analysis, inspection, or demonstration to ensure the system operates safely. Testing included failure mode testing. The processes as described above and in the related appendices identify and categorize the conceivable hazards that may lead to an unsafe condition. Any and all hazards that were deemed unacceptable through the hazard analysis process were eliminated by the design of I-ETMS, or mitigated to an acceptable level as detailed in the Hazard Log.



8.4 Verification and Validation of I-ETMS

Verification and Validation (V&V) of I-ETMS is covered in detail in Section 13. V&V are critical processes in the safety assessment of the PTC System. V&V for I-ETMS required extensive planning and coordination among railroads and vendors and served as a comprehensive analysis and test of the system software and hardware to determine that it performs its intended function, to ensure that it does not perform unintended functions, and to measure its quality and reliability.

8.5 Segment Safety Requirements Compliance [49CFR 236 Appendix C]

As defined in the Preamble to Part 236, Subpart I, and 49CFR 236, Appendix C provides safety criteria and processes for the design of safe systems, or fail-safe, or vital signaling systems that by definition must exclude any hazards associated with human errors.

I-ETMS has been designed using established system safety engineering principles per the referenced standards and processes shown in Section 2 of this PTCSP, to assure that all system components perform safely under normal operating conditions and under failure conditions, while accounting for human factors impacts and external influences.

As currently designed, the I-ETMS system contains two sub-systems that are designed using fail-safe principles and objectives, the I-ETMS onboard Train Management Computer (TMC) and the Wayside Interface Unit (WIU). The WIU subsystem safety compliance with 49CFR 236, Appendix C is demonstrated in the documents in Appendix V of this PTCSP. The remainder of this section 8.5 focuses on the 49CFR 236, Appendix C compliance of the TMC component of the onboard segment. The Communication Segment does not present any safety-critical hazards and is not analyzed for fail-safety. Refer to the discussion in Section 3.3 of this PTCSP. The Office Segment is currently designated as non-vital pending predefined changes for a vital implementation as described in Section 6.2.2.9.2. The entire PTC system using I-ETMS design is intended as a vital overlay based on the architecture described herein.

System Safety Under Normal Operating Conditions [49CFR 236 8.5.1Appendix C(b)(1)]

The TMC has been designed to assure safe operation with no hazardous events under the operating conditions identified in the referenced PTCDP. Furthermore, Safety Verification, as defined in IEEE 1483-2000, provides evidence that all safety-critical TMC sub-system functional applications perform properly in the absence of faults and failures. The I-ETMS System Safety Program Plan located in Appendix HH of this PTCSP describes the implementation of this safety verification process for the TMC.

Safety Verification requires:

1. Identification of all primary application level safety-related faults associated with functions performed by the TMC.



2. Validation that TMC applications level software requirements contain the functional safety requirements necessary to mitigate each potential fault.

3. Verification that the TMC application level software has met each of the functional safety requirements.

4. Factory and/or field safety verification testing (procedures and results) demonstrate that the TMC correctly interfaces with the other I-ETMS sub-systems, and that the functions the TMC performs result in safe train operations.

Evidence that each of the Safety Verification requirements listed above have been met can be found in the following documentation corresponding to 1-4 above:

1. Identification of faults is performed via the I-ETMS system Functional Fault Tree (FFT) and segment Fault Tree Analysis (FTA) that are contained in Appendix G of this PTCSP.

2. Each fault appearing in the FFT or FTA is traced to a Hazard Log (HL) entry. The HL contains all required mitigations of the safety faults and the mitigations are each covered by one or more segment or component software requirements. The specific requirements by number are identified in the HL, which is contained in Appendix D of this PTCSP.

3. Verification is achieved by performance of integration level safety tests conducted in both lab and field environments. Examples of Lab Test results are addressed in Appendix J of this PTCSP and examples of field test results for safety validation are addressed in Appendix N of this PTCSP.

4. The remainder of the safety V&V including plans, use cases, test cases, and test procedures are discussed in Appendix M of this PTCSP. Examples of the actual data showing the verification testing and results is addressed in Appendix N of this PTCSP.

Safety Under Systematic Failures [49CFR 236 Appendix C (b)(2)(i)] 8.5.2

The product is designed in a manner to eliminate or mitigate unsafe systematic failures that could be attributed to human error. These systematic errors and/or failures in the development of the TMC are primarily prevented by employing an adequate and comprehensive safety assurance development process for both hardware and software. The safety assurance development process ensures the following product areas are designed and implemented without error or failure:

1. Safety-critical TMC platform Class II hardware required to implement vital functions

2. Safety-critical TMC platform software required to assure fail-safe implementation of application level functions



3. Application level functional software

4. Track Map and database

Descriptions of the safety assurance development and V&V processes can be found in Section 8.2 with test results addressed in Appendix M and Appendix JJ of this PTCSP. The processes described provide evidence that the TMC development process ensures that systematic errors are not incorporated into the TMC hardware and software in the product development areas listed above. An outside agency audited both the planning and process documents and concluded they were adequate and comprehensive. A second audit was conducted to ensure the plans and processes identified were being followed. Examples of the V&V data and results are addressed in Appendix N and Appendix KK of this PTCSP.

Safety Under Conditions of Random Hardware Failures [49CFR 236 8.5.3Appendix C (b)(2)(ii)]

The TMC subsystem development has been such that there is no single point of failure that can lead to a hazardous condition and assures that the system will operate safely under conditions of random hardware failures. Safe operation under conditions of random hardware failures within discrete Class II hardware of the TMC platform is verified in the Failure Modes and Effect Analysis (FMEA) located in Appendix G.7 of this PTCSP, in which the effects of each failure mode of each component is analyzed to assure it does not result in an unsafe failure. Failure effects are also categorized as self-revealing or non-self-revealing (latent). Latent failures are analyzed in combination with other latent failures and with self-revealing failures to verify that no combination of such failures will produce an unsafe condition.

Safe operation under conditions of random hardware failures within non-discrete Class II hardware (including components such as CPU or memory), is protected by attributes of the Safety Assurance Concepts (SACs) used to implement the TMC subsystem. These attributes and verification of their correct and comprehensive implementation in the TMC platform are addressed in Appendix N of this PTCSP.

The overall TMC subsystem development addresses safe operation in the presence of transient failures. WRE’s TMC requirements document provides the requirements that result in safe system operation or state in the event of a failure. The determination of safe system operation after failure and frequency of attempted restarts is addressed in the I-ETMS System Reliability Analysis performed by Parsons. After beginning system-wide RSD, a Reliability Analysis was begun based on actual system performance. This report provides an analysis of reliability including restarts. Refer to Appendix FF of this PTCSP.



No Single Point of Failure Shall Result in an Unacceptable Hazard 8.5.4[49CFR 236 Appendix C (b)(2)(iii)]

The TMC Failure Modes and Effects Analysis (FMEA) analyzes the entire TMC on a component-by-component basis. In the results of the FMEA, there are no single points of failure, which result in an unacceptable or undesirable failure of the TMC. An unacceptable failure is a failure, which has a Hazard Risk Index per MIL-STD-882C, Appendix A, 30.5.2 that is classified as “Unacceptable.” An undesirable failure is also as defined per MIL-STD-882C.

For several points of system failure which are currently traced to mitigation by rule and/or procedure, there remains an undesirable level of risk for failure, although not an unacceptable risk, per MIL-STD-882C. The “predefined changes” proposed herein for future vital implementation will reduce the residual risk of these points of failure to a level that is “acceptable with review”, which will fully satisfy the regulatory requirements.

No Combination of Failures Shall Result in an Unacceptable Hazard 8.5.5[49CFR Part 236 Appendix C (b)(2)(iv)]

The TMC Failure Modes and Effects Analysis (FMEA) analyzes the TMC Brake Control Module on a component-by-component basis. In the results of the FMEA, there are no combinations of failures, which result in an unacceptable or undesirable failure of the TMC. An unacceptable failure is a failure, which has a hazard risk index per MIL-STD-882C, Appendix A, 30.5.2 that is classified as “Unacceptable.” An undesirable failure is also as defined per MIL-STD-882C.

As required by Part 236, Appendix C (b)(2)(iv), the TMC Platform Safety Analysis has performed hardware and software analyses of the design for combinational failures that could lead to an unsafe situation. As a result, it can be concluded that there are no combinations of failures found, originating within the on board platform, that could lead to an unsafe condition.

Common Mode Failures Shall Not Result in an Unacceptable Hazard 8.5.6[49CFR 236 Appendix C (b)(2)(v)]

As defined in 49CFR 236 Appendix C, common mode failures are those in which two or more subsystems or components intended to compensate one another to perform the same function all fail by the same mode and result in an unsafe condition. 49CFR 236, Appendix C compliance is gained by the use of tests and analysis conducted at the component level including verification of the SAC implementation and the existence of mitigation of any common mode faults. The tests and results are summarized in Appendix N of this PTCSP. Details of the procedures and results are contained in Appendix I and Appendix J of this PTCSP respectively.

FMEAs performed on safety-critical components (e.g., TMC, Wayside Interface Units, Electronic (Penalty) Brake Interface) revealed no instances in which common mode failures result in an unacceptable failure. A n unacceptable failure is a failure which has



a hazard risk index per MIL-STD-882C, Appendix A, 30.5.2 that is classified as “Unacceptable”. In addition to the FMEA results, the I-ETMS Risk Assessment included as Appendix F of this PTCSP contains system-level discussion of common mode faults and assessment of mitigations, based on FFTs, SSHAs, etc. The I-ETMS Risk Assessment also did not identify any instances in which common mode failures result in an unacceptable failure.

Adherence to the Closed Loop Principle [49CFR 236 Appendix C (b)(3)] 8.5.7

The TMC is designed using the closed loop principle as defined in 49CFR 236, Appendix C to ensure that all conditions necessary for the permissive state or action can be verified to be present before the permissive state or action is initiated or maintained. This design principle is required in two areas:

1. In the assurance of the fail-safe behavior within the TMC platform design

2. In the TMC application level functional design

Within the TMC fail-safe platform, permissive outputs in the form of discrete hardware states or vitally protected serial messages must be demonstrated to be allowed only if all safety-related activities verifying the absence of unsafe hardware failures have been successfully performed.

The Platform Analysis contained in Appendix G.8 of this PTCSP provides a verification of the vital portions of the TMC and their impacts on system safety.

In the TMC applications level functional design the closed loop principle must be incorporated such that for the penalty brake to remain withheld, all safety-related aspects of the current state of the train (including parameters such as train speed, location and location accuracy within valid authority limits) must be verified to be acceptable. Evidence includes identification of potential TMC functional faults (FFT), incorporation of design requirements to prevent occurrence of those faults, and demonstration that the software implementing the application level safety-critical functions have met those requirements.

All identified faults in the application level functional and software design are contained in the HL. The HL also contains all mitigations needed and component requirements, which satisfy the mitigation needs.

Incorporation of Safety Assurance Concepts [49CFR 236 Appendix C 8.5.8(b)(4)]

49CFR 236, Appendix C requires that the product design must include one of more Safety Assurance Concepts (SACs), as described in the IEEE 1483 standard, to ensure failures are detected and the product is placed in a safe state. The TMC design incorporates at least two of the SACs described in the IEEE 1483 standard, Checked Redundancy and Intrinsic Fail-Safety. The design also uses two secondary SACs, Diversity and Self-Checking.



The SACs used in the design of the TMC are also identified in Section 10 of this PTCSP.

Incorporation of Human Factors [49CFR 236 Appendix C (b)(5)] 8.5.9

49CFR 236, Appendix C requires that the design of the product sufficiently incorporate human factors engineering that is appropriate to the complexity of the product. This includes the educational, mental, and physical capabilities of the intended operators and maintainers. Human factors have been incorporated into the design of the I-ETMS system. The human factors study can be found in Appendix C of this PTCSP.

System Safety under External Influences [49CFR 236 Appendix C 8.5.10(b)(6)]

The TMC is designed to operate safely when subjected to different external influences such as, electrical interference, abnormal inputs, electromagnetic interference, electrostatic discharges, mechanical influences, and/or climatic changes.

Immunity to external influences not related to human operator inputs is addressed in the design requirements for the TMC subsystem. Environment tests were carried out on the TMC and results are included in Appendix G.10 of this PTCSP. All external influences on TMC safety that must be accommodated were examined. Other influences are identified in the hazard analysis and summarized in the HL. The HL is contained in Appendix D of this PTCSP.

The SACs listed in Section 10 also identify protections provided against random errors by nature of the SACs themselves, and describe how they are implemented.

Compliance with external influences related to human operator inputs is demonstrated in documents related to:

1. Human Factor Analysis and HMI analysis for the onboard CDU.

2. Identification and mitigation of functional faults, via the FFT and subsequent related analysis in the O&SHA.

The Final Human Factors Assessment is described in Section 7 and the document for the Human Factor Analysis is in Appendix C of this PTCSP.

System Safety after Modification [49CFR 236 Appendix C (b)(7)] 8.5.11

49CFR 236, Appendix C requires that policies and procedures must be in place to ensure that safety is not compromised following modification to the hardware or software, or both. Modifications must follow the concept, design, implementation and test processes and principles as documented in the PSP of the original product. It also states that regression testing must be comprehensive and documented to include all scenarios, which are affected by the change made.



Procedures are in place that must be followed to maintain system safety after modifications to the hardware or software, or both. These procedures are described in Section 15 and the segment specific documents are listed in Appendix L of this PTCSP.

Also required is a complete description of the specific procedures and test equipment necessary to ensure the safe and proper installation, implementation, operation, maintenance, repair, inspection, testing, and modification of the PTC system on the railroad and establish that safety-critical hazards are appropriately mitigated.

Procedures are in place for the items listed in the above paragraph and a discussion of those procedures and tools are found in Section 15. The complete list of procedures and equipment are addressed in Appendix L of this PTCSP.

Acceptable Verification and Validation Standards [49CFR 236 8.5.12Appendix C(c)]

The Verification and Validation procedures to support the achievement of the applicable requirements in 49CFR 236, Subpart I for processor-based and train control systems are described in Section 13 and the complete documents are addressed in Appendix H and Appendix I of this PTCSP. The wayside Verification and Validation Plan is addressed in Appendix JJ of this PTCSP.

8.6 Safety Audits

PTC system safety and the veracity of the associated system safety assessments have been a primary consideration throughout the specification, development, test, and deployment of Metrolink PTC system. To that end, Metrolink has taken several important, additional steps to assure that (a) the PTC system safety analyses and risk assessments are accurate and unbiased; and (b) the system will operate safely.

1. CMMI Institute Certification. The Parsons engineering team for the Metrolink PTC has been certified to a Capability Maturity of Level 2 per the CMMI standards. In-depth audits of the development and software processes of the Parsons group are part of the CMMI Certification process. The CMMI certification for the Metrolink Parsons engineering group is contained in Appendix Z.1 of this PTCSP.

2. Safety Audits: The processes used by WRE to develop the vital onboard component of I-ETMS were audited by Turner Engineering Corporation of Venice, CA. The results of the Turner audits are summarized in Appendix Z of this PTCSP. Turner Engineering has no connection with any of the I-ETMS suppliers and acts as an independent auditor of the safety of I-ETMS.

3. Outside Review of Safety Artifacts: The safety artifacts produced by WRE for I-ETMS were thoroughly reviewed by two companies who have expertise in rail safety and positive train control safety assessments: Rail Safety Consulting (RSC) and Battelle Memorial Institute. These firms are not associated with any



vendor of I-ETMS components or systems and are independent from suppliers of any kind. Safety documents intended to be components of the I-ETMS PTCSP were separately evaluated for completeness, correctness and adherence to industry standards and best practices by RSC and Battelle. Feedback from the Outside Reviewers was used to revise and improve this PTCSP and its component documents.

4. Outside Risk Assessment of I-ETMS: The risk assessment for I-ETMS was conducted by Battelle Memorial Institute. Battelle is an independent organization, not associated with any of Metrolink’s PTC system suppliers. This outside risk assessment provides Metrolink with the expectation that the vital overlay safety performance standard for the I-ETMS system will be verified upon deployment. The risk assessment is discussed further in Section 11 of this PTCSP, and is included as Appendix F of this PTCSP.

8.7 Segment Orientation of Verification and Validation Verification and verification tasks are performed to address PTC functionality that traverses all technical segments of Wayside, Locomotive, Office and Communications. System level V&V is utilized to address safety and functional requirements as allocated to each segment. For the Communications Segment, there are no safety requirements allocated, only functional, as part of inter-segment data exchanges. That is, there are no design related safety assurance concepts required or utilized by the Communications Segment to mitigate failures that could lead to a hazardous condition. Data communication systems cannot be depended upon to provide error-free transmission of data due to the many forms of interference and noise which may corrupt the content of data messages passed through them. One means of mitigating these errors is to provide end-to-end data message integrity checks and security (e.g., HMACs and CRCs) as part of the design of the system (i.e., provided for in the Wayside, Locomotive and Office Segments) which uses such communications paths and networks. This is implemented in the I-ETMS system design. The result is that this level of message protection applied in a safety-critical manner within the other PTC segments, will relieve the system from relying on a specific level of correctness in the communications medium itself. This does not relieve the Communications Segment as a whole from providing sufficient communications link performance to support the overall system availability requirements but the system MTTHE for trains operating in the Active state is not directly impacted by the Communications Segment performance. System Level V&V of the Office Segment, in addition to I-ETMS PTC functions, addresses safety critical functionality involving intersegment exchanges of safety critical information via HMACs, CRCs, and is managed within Initialization and polling processes. The BOS has no safety requirements allocated exclusively to it. However, hazards initially identified within the BOS, regarding corruption of data in the data



transformation process between CAD and BOS, as well as a potential for association of Mandatory Directives (e.g., authorities or bulletins) to the incorrect Locomotive Segment, resulted in procedural mitigations that are necessary to detect these hazards. This realization came about in assessing the Office Segment design compliance to safety principles of 49CFR 236 Subpart I, Appendix C; namely addressing the potential for single point of failures that could result in an unsafe condition. This has led to I-ETMS developmental changes regarding the addition of the IC3 processing and IVS to place the Office Segment in better alignment with Appendix C. One of the Pre-Defined changes identified in Section 6.2.2, the addition of the Individual and Composite CRC Calculator (IC3) capability, mitigates these hazards associated with the BOS through the incorporation of the Safety Assurance Concept of Diversity, into the Office Segment. In mitigating these hazards, simple preliminary analysis indicates this change effectively reduces the safety risk associated with the hazards to an acceptable level. Office Segment V&V addresses both methods of MD confirmation (i.e., procedural and design related) as part of the System Level V&V process, with regression testing performed in close coordination with the release of the IC3 capability. Simple preliminary analysis identifies 54 hazards assessed with a Residual Risk Index (from the Hazard Risk Index in PTCDP) of I-D (1x10-8) which IC3 is to address. To summarize, these are of the following types:

• BOS message MD handling errors

• BOS to LS communication errors

• BOS train ID association errors

Implementation of IC3 moves them from a Residual Risk Index of I-D to I-E. A simple preliminary fault analysis shows that these hazards were previously mitigated to 1x10-8 (I-D) by using the following MTTHE figures:

• Receipt of unsafe MD (1x10-5) and

• Crew Review of Electronic with Verbal Confirmation (1x10-3)

With IC3, these are expected to be mitigated to 1x10-10 (I-E), based on the existing BOS error rate (1x10-5) and assuming that IC3 has same error rate as BOS (1x10-5) and they are “AND”ed for hazard mitigation. Attached in Appendix DD is document WCR-DZN-1305 IC3 Design Summary v1.0, which explains the mitigation of potential data errors related to BOS processing of mandatory directives. The majority of safety critical and functional requirements for I-ETMS are allocated between the Locomotive and Wayside Segments where safety functions are carried out



by safety critical designed platforms to be verified to be in compliance with Subpart I Appendix C principles. System level V&V addresses the I-ETMS applied functionalities, while platform analyses have been performed by PTC equipment suppliers to demonstrate proper functionality and compliance with Part 236 Appendix C principles through their individual platform level V&V processes. The V/I contractor (Parsons) used COTS components where possible and performed incoming inspection V&V on these items. The V/I also used components from Wabtec and the SCRRA, in the case of the WIU’s from GE Transportation Systems, which have internal V&V systems conforming to the requirements of Part 236 Appendix C.

The safety assurance processes covering System and Platform Level V&V are described below.

8.8 System Level V&V (Levels 1, 2, and 3)

System Level V&V has been performed by Metrolink in assuring I-ETMS functionality performs properly at the system layer as applied in all operational scenarios for its railroad. V&V activities have been performed at Lab, Field Integration and Field Qualification test stages as documented in the Master Test Strategy (MTS) and Metrolink also utilized the results of Segment Level testing performed by PTC vendors who have provided subsystem components.

The system level I-ETMS V&V Process is summarized in Section 13, with the comprehensive MTS addressed in Appendix H.1. The Metrolink results of the System Level V&V process are provided in Section 18 with the associated Appendices illustrating lab and field V&V test results and confirmation that all safety requirements have been tested via a requirements traceability process.

The MTS describes V&V activities that have been executed by Metrolink in the test lab and field environments including confirmation of the Track Database. These System Level V&V activities occur upon receipt of I-ETMS equipment from component vendors and full V&V at the I-ETMS product/component level.

Supplier Support for Validation of I-ETMS (WRE) 8.8.1

In validating the I-ETMS PTC functionality, WRE produced system level use cases, test cases and test results associated with internal V&V activities performed. The results of the validation activities and the associated hardware and software releases have been provided to Metrolink as input to the System Level V&V process. Metrolink performed separate and independent segment level lab tests as a means to insure adherence to railroad functionality requirements. The processes identified for this segment level testing are included in the Metrolink Master Test Strategy covered in Section 13 of this PTCSP.



8.9 Platform Level Verification & Validation (Levels 4 and 5)

I-ETMS component vendors of safety critical equipment provided the necessary V&V documentation to support the safety case for use in the I-ETMS application. Each vendor has described how it has successfully demonstrated it has met safety critical requirements and achieved an acceptable level of safety risk through concept, functional and implementation verification and validation activities for their respective subsystem or platform level components. SCRRA and its V/I contractor have reviewed this material and found it to be acceptable for safety.

Vendors other than Wabtec who provided safety critical components to be used with I-ETMS (i.e., functions such as WIUs) provided conclusions and results of V&V activities as part of product safety cases which have been separately shown to be compliant to § 236 Subparts A through G or more recently certified under Subpart H, for new processor based vital products. Relevant product safety cases are referenced in Appendix V of this PTCSP.

8.10 I-ETMS Platform Verification Approach In I-ETMS, vital system design functionality is primarily concentrated within the safety critical elements of the office computing platform, the onboard computing platform, wayside interface unit processing and associated interfaces. The overall goal of the I-ETMS platform safety analyses is to provide safety justification to demonstrate that the I-ETMS design (as implemented) and its safety critical interfaces, comply with the requirements of 49CFR 236, Subpart I, Appendix C regarding safety assurance principles for vital overlay PTC systems as identified in § 236.1015(e)(2). The key objectives of a vendor’s platform safety analysis are to:

Identify the low level safety-critical platform functions being executed by the processors and interface devices highlighting software and hardware circuitry responsible for its low level execution.

Identify relevant failures that could occur within platform hardware, firmware, operating system software and interfaces that could adversely impact safety of the I-ETMS platform functions.

Confirm through an independent means that safety requirements associated with detailed design are complete and correct.

Demonstrate through conceptual, functional and implementation analysis and test activities aligned with a safety verification standard per Part 236 Subpart I Appendix C paragraph (c), that all failures have been considered, that design mitigations have been conceived and implemented supporting safety targets and rendering the impact of all failures to be of acceptable risk.



Provide qualitative and quantitative substantiation for the I-ETMS System Hazard Analysis unsafe failure rates associated with platform functions and safety critical devices as applicable.

Provide confirmation and justification that Safety Assurance Concepts and Techniques (SAC/SATs) have been properly implemented and address all relevant failures.

Provide summary conclusions with regard to the specific I-ETMS product analyzed, with relevant limitations or conditions on safety identified.

Demonstrate through a body of safety evidence that Part 236 Subpart I Appendix C principles have been comprehensively addressed including summary conclusions on how each Appendix C principle has been satisfied.

A platform analysis of the Communications Segment and Office Segment was not conducted.

8.11 I-ETMS Wayside Segment Platform Verification (WIU Vendors) Metrolink has collaborated with other railroads implementing I-ETMS to compile an aggregate set of safety case reference materials for Wayside Interface Units (WIU) that are considered for use on railroads deploying I-ETMS. The information compiled is intended to demonstrate that the WIUs highlighted can be shown to be compliant with safety requirements established in FRA Regulations identified under 49CFR 236 Subparts A through G, 49CFR 236 Subpart H or 49CFR 236 Subpart I as applicable to each vendor’s specific product offering. The WIU vendor safety materials for Metrolink WIUs are compiled within Appendix V, the Wayside Interface Unit Safety Case of this PTCSP.

WIU Vendor Safety Verification Results 8.11.1The WIUs used on the Metrolink I-ETMS implementation are provided by GE Transportation Systems (now Alstom Transportation). These devices were verified by the internal safety program defined by GE and documented under Appendix V of this PTCSP. Safety evidence provided within this information includes:

• the identification of hazards that are applicable to the Wayside Segment and attributable to WIU functionality as defined under I-ETMS;

• prescribed hazard mitigation requirements to be implemented by vendors and railroads;

• confirmation from the vendor of its adherence to requirements of AAR Standards S-9202 associated with WIU functionality;

• the quantitative level of safety (risk) associated with each WIU product as identified by the vendor; and

• the comprehensive references to safety documentation created for each WIU product, reflecting its conforming to requirements of Subparts H & I including compliance with the principles of Appendix C.



Based on the information summarized in Appendix V, Metrolink considers the WIU safety evidence provided to satisfy the requirements for V&V of the WIU Vendor platforms to be used on the Wayside Segment; that they have been designed and safety verified within a framework of rail industry standards, and have satisfied FRA requirements (i.e., Appendix C principles) to support use of the WIU in a Vital Overlay PTC Implementation. WIUs being used within the current implementation of I-ETMS by Metrolink are described in Section 6.

Locomotive Segment – WRE TMC Platform Safety Verification 8.11.2

WRE provided an I-ETMS Platform Safety Analysis (PSA) in Appendix G.8 of this PTCSP that illustrates verification of the safe implementation of the primary on-board Locomotive Segment I-ETMS components; namely the Train Management Computer (TMC), the Computer Display Unit and associated radio, network and communications and sensor interfaces.

As all on-board core I-ETMS processing is performed via direction from the TMC, the PSA covered each core platform function’s architecture, generally illustrated in Figure 8-4, General Platform Architecture.

Figure 8-4 General Platform Architecture



The PSA justified, through rigorous verification activities, the probability of unsafe failure associated with the full class of TMC Processing failures/errors that could be anticipated. The PSA addressed the safety effectiveness of the I-ETMS SACs as implemented, including confirmation that all factors upon which safety of the TMC platform depends have been fully addressed, including but not limited to:

failures of lower level sensors interfaced with the TMC that could individually lead to unsafe events.

considerations for impacts on safety of the operating system and

commercial software components used.

correctness and completeness of the algorithms used for such things as speed determination, location determination, braking, and target generation.

analysis and justification that software implemented in a Checked Redundant manner is of acceptably low risk to be considered error free.

failures identified using failure analyses of TMC and peripheral hardware including failures of memory, failures occurring during data transfers, failures of components used in intrinsically safe circuitry, failures in voting circuitry between triplex processors ensuring no single point failures, combination of non-revealing failures nor common mode failures can lead to an unsafe condition.

The WRE Platform Safety Analysis is included in Appendix G.8 of this PTCSP.



9 Hazard Log [§236.1015(d)(1)]

This section contains a Hazard Log consisting of a comprehensive description of all safety-relevant hazards not previously addressed by the vendor or supplier to be addressed during the life-cycle of the PTC system, including maximum threshold limits for each hazard (for unidentified hazards, the threshold shall be exceeded at one occurrence.) The I-ETMS Hazard Log contains all hazards identified at all phases of the I-ETMS lifecycle.

Mitigations to hazards identified in the Hazard Log are summarized in the Safety Requirements Document (Appendix D.2 of this PTCSP). The Safety Requirements (SAFs) are high level safety requirements that decompose into the system design.

The I-ETMS Hazard Log also contains the Operating and Support Checklist Applicable to Railroads (OSCARs) and their relation to individual hazards. These OSCARs provide the traceability of those hazards whose mitigations are training or procedural and the material that addresses these mitigations. This tracing is shown in the OSCAR Document in Appendix D.1 of this PTCSP, and is summarized in Section 9.6 below.

The section describes the purpose of the I-ETMS Hazard Log (HL), identifies how the HL fits into the overall safety assessment, describes how system hazards are represented in the HL, describes how the HL is maintained, and presents the conclusions drawn from the HL as required by 49CFR §236.1015(d)(1).

There is a Common Core Hazard Log that represents the comprehensive collection of all PTC related hazards associated with I-ETMS. The hazard log was created using Wabtec’s standard practices which were developed into a formalized Work Instruction. The common hazard log has been reviewed and assessed for applicability by the JRST acting in support of the ITC committee.

To accommodate an individual railroad’s potential need for unique customization of a Common Core Hazard Log field, a hazard log database was constructed. Therefore an exceptions table can be used to record the alterations to specific fields of a specific hazard ID relevant to a specific railroad for post-processing and data replacement in the Railroad Specific Hazard Log. Refer to the discussion of the “RailRisk” database system that is provided in Section 33 of this PTCSP.

These exceptions do not change the content of the Common Core Hazard Log, and the exceptions table is not required to be used by a railroad. A formal trace is then established from the hazard ID to the Exception table. Metrolink has used the exceptions table form (see the form in Appendix D) to develop a Metrolink-specific Hazard Log which specifically represents the I-ETMS functionality deployed by Metrolink on its territory.

Post-processing of the Exceptions table against the Common Core Hazard Log replaces the cells specified within the Exceptions table and produces a separate



Railroad-Specific Hazard Log without affecting the Common Core Hazard Log database.

9.1 Hazard Log Description

The HL is a table used to track all hazards associated with I-ETMS through to their successful mitigation. The hazard log is a living document that is updated throughout the life of the program. Its purpose is to capture all system hazards, identify associated risks, list mitigations, and document that all required mitigations have been successfully implemented in the system and / or the system’s operating environment.

The HL provides a single point of reference for all hazards that were identified throughout the life cycle of the PTC System. The hazards were derived from a review of I-ETMS functionality, operating methods, and the various hazard analyses. Source analyses documents include the PHA, FFT, and O&SHA. Other hazards entered in the HL were identified from requirements definition, design reviews, system V&V and testing. The HL captures:

• System level hazards – hazards that impact the entire PTC system.

• Segment level hazards – hazards that impact one or more segments, but not all segments within the system.

• Component hazards – hazards that impact a given component within a segment.

• Hazards related to the integration of I-ETMS within the Metrolink operating environment.

9.2 HL Role in the PTC Safety Assessment

The HL is used as the central depository for all hazards identified over the life of the system, regardless of the method used to initially identify the hazard. Potential hazards are generally identified through one of three means:

1. As part of the structured safety analysis process associated with the development of the system functionality such as generation of the Preliminary Hazard Analysis, Functional Fault Tree, or other tools.

2. As part of a review of the system functional requirements to understand how a human will likely interact with the system and how human errors may lead to hazards. This process is performed through development of the O&SHA.

3. Through ad-hoc discovery, such as general knowledge of similar systems, or lessons learned.

Regardless of which method was used to identify the hazard, the HL is the tool to track each hazard to its successful mitigation.



The HL can be thought of as a chronological history of a hazard. It starts with a reference to the source of the hazard identification, continues to a description of potential causes of the hazard, includes an initial assessment of the risk associated with the hazard, identifies mitigations required to reduce the risk to acceptable levels, and concludes with references to evidence indicating that the mitigations have been successfully implemented.

9.3 The I-ETMS Hazard Log

The hazard log captures PTC system hazards, including hazards identified for system level functionality, as well as WIU, Office, Locomotive, and Communication segment hazards. There is a single hazard log that includes the complete set of hazards across all railroads. The I-ETMS Hazard Log captures and tracks hazards common to each railroad implementing I-ETMS, as well as, I-ETMS hazards unique to one or more railroads. The HL also identifies the common mitigation(s), as well as, any railroad-specific mitigations.

The HL is provided in Appendix D of this PTCSP. The Appendix provides details for each hazard, and includes a description of all of the columns of the HL and a detailed overview of the hazard log development and maintenance process. The HL accurately represents the hazards and mitigations associated with Metrolink’s implementation of I-ETMS. The process for maintenance of the common hazard log is described in Section 9.5 of this PTCSP.

9.4 Conclusions Drawn from HL Analysis

Based on the mitigations listed in the Hazard Log, requirements have been established for the I-ETMS system as well as supporting programs such as training, maintenance, development of warning labels and other non-system mitigations as demonstrated in the Hazard Log found in Appendix D of this PTCSP. The Hazard Log is a living document that will be maintained through the life of the Metrolink PTC system. The Hazard Log included in this PTCSP in Appendix D is a snapshot of the Hazard Log at the time of publication of this document. Changes to the I-ETMS Hazard Log will be managed through the Industry Configuration Management Process (Appendix O of this PTCSP).

9.5 Maintenance of the HL

The HL is maintained throughout the life of the system. As new hazards were identified as part of the development and deployment process, they were entered into the HL and mitigation requirements were developed and implemented. As the I-ETMS system evolves over its life cycle, the need may arise to update the HL as new hazards are identified or alternate mitigations are implemented. This periodic maintenance of the HL is anticipated to be of limited occurrence and will generally result from one of two primary activities. A new hazard or mitigation may pertain to all I-ETMS implementers, possibly introduced through enhancements made to the system, and will be captured through updates to the HL. Alternatively, upgrades of I-ETMS may result in identification of new railroad-specific hazard and implementation of the associated



mitigations. Because the HL is intended to be used throughout the life cycle of the PTC system, the I-ETMS Hazard Log will be updated under either of these circumstances.

Metrolink assumes responsibility for maintenance of the hazard log associated with its PTC system. However, Wabtec has been designated as the central repository of the I-ETMS Hazard Log. Metrolink will participate along with other industry I-ETMS stakeholders to identify, review, and approve changes to the Hazard Log. Any railroad involved in the I-ETMS stakeholder group is able to propose a hazard to be placed in the hazard log at any time in the PTC system life cycle, including development, test, and revenue service operation. The hazard will be assessed and assigned an appropriate mitigation through industry activities.

See Section 17 of this PTCSP for an expanded description of the configuration management processes applicable to the I-ETMS Hazard Log.

9.6 Operating and Support Checklist Applicable to Railroads (OSCAR) The OSCAR document provides a comprehensive framework for the implementation verification of the operating and support hazard mitigations associated with the deployment of I-ETMS specific to Metrolink. It should be noted that the OSCAR review encompasses only those operating and support hazards associated with the I-ETMS as a vital overlay and does not address those associated with the pre-PTC Metrolink Methods of Operation except where installing PTC has changed a specific Method of Operation.

Purpose 9.6.1The Operating and Support Checklist Applicable to Railroads (OSCAR) methodology provides:

• Identification of the relevant hazards associated with the vital overlay PTC system through the creation of an Operating and Support Hazard Analysis (O&SHA) or through a similar analysis,

• Highlighting of mitigation requirements in the form of rules and/or procedural amendments, supplemental training, or documentation materials, that are identified within the I-ETMS Hazard Log and O&SHA and,

• Final confirmation that mitigations are in force as defined.

The overriding purpose of the OSCAR Verification process is to compile all operating and support related hazards as identified within the I-ETMS Hazard Log for Metrolink into one document and to use a “checklist” type approach to insure that all hazards have been properly mitigated. Such a process allows those hazard log entries to be closed and references the mitigation evidence contained in this PTCSP.

Scope 9.6.2As illustrated in Figure 9-1, operating and support hazards are identified throughout the concept and design evolution of I-ETMS. Relevant hazards have been recorded by



WRE as part of Preliminary Hazard Analysis (PHA), System/Subsystem Hazard Analyses (SSHA), Functional Fault Tree Analysis (FFT), etc. The identification of I-ETMS operating and support hazards can either be derived as a byproduct of functional hazard analyses above or, depending on the nature of the system, with a specific Operating and Support Hazard Analysis (O&SHA). Operating and support hazards that were initially identified and entered into the I-ETMS Hazard Log (HL) by WRE have been further refined and updated based on the creation of an I-ETMS O&SHA associated with the I-ETMS release for Metrolink. Refer to Figure 9-1. Those O&SHA hazards have been transferred to the HL. As hazards have been identified, required mitigations in the form of training, rules and/or procedures have been implemented and documentation materials have been indicated for each. In the process of defining the mitigations required, they have been categorized (an OSCAR ID) according to the operating or support function to which they relate, to facilitate a greater emphasis on each class of hazard and mitigation. With the completion of the definition of operating and support hazards, all OSCAR categories have been defined. The Scope of the OSCAR Verification Document is to analyze each OSCAR Category with its associated list of mitigation requirements, and confirm that the required mitigations have been instituted in order to close the relevant I-ETMS Hazard Log entries. Proof of confirmation is a reference to materials supporting the I-ETMS PTCSP for Metrolink. While not directly linked, it is envisioned that commonalities likely exist between the PTC Training Programs required per FRA 49CFR 236 Subpart I and the training mitigations identified by this operating and support analysis effort.



Figure 9-1 - Managing Operating & Support Hazards



10 Safety Assurance Concepts [§236.1015(d)(2)] [Part 236 Appendix C (b)]

This section describes the safety assurance concepts that are used in the product design and an explanation of the design principles and assumptions as required by 49CFR §236.1015(d)(2) and 49CFR 236, Appendix C (b).

Safety Assurance Concepts (SACs) are a formalization of the various techniques which assure safety in the design of hardware and software for processor-based train control systems such as I-ETMS. The recognized SACs include Checked Redundancy, Diversity & Self-Checking, N-Version Programming, Numerical Assurance, and Intrinsically Fail-Safe Hardware design. System designs use one or more of these concepts to assure that the component and its operation will be based on design techniques that reduce the risk from mis-operation to a negligible level. The Safety Assurance Concepts document is provided in Appendix A of this PTCSP. The document describes the SACs used in the safety-critical components of I-ETMS and how the stated SACs are implemented to perform safety functions in a safety-critical manner. 49CFR 236, Appendix C requires that the product design must include one or more Safety Assurance Concepts (SACs) described in the IEEE 1483 standard [2] to ensure failures are detected and the product is placed in a safe state. As an example, the TMC design incorporates at least two of the SACs described in the IEEE 1483 standard, Checked Redundancy and Diversity and Self-Checking. All other safety-critical components of the I-ETMS system also use appropriate Safety Assurance Concepts, as noted in the SAC document located in Appendix A of this PTCSP.



11 Risk Assessment [§236.1015(d)(3), Part 236 Appendix B (as revised)]

This section of the PTCSP provides a Risk Assessment (RA) of the as-built Metrolink PTC system described in the referenced PTCDP and this PTCSP as required by 49CFR §236.1015(d)(3). The risk assessment meets the requirements of Part 236 Appendix B (as revised.)

11.1 Risk Assessment Approach

The Metrolink I-ETMS system, intended to perform as a Vital Overlay PTC system, is assessed relative to the allocation of safety-critical functions across the four defined segments of the system (Locomotive, Office, Wayside, and Communications). Safety-critical functions are divided into two groups depending on the minimum required Mean Time to Hazardous Event (MTTHE) specified for a given function: 1) those implemented with a level of safety assurance considered vital (MTTHE >= 109 hours), and 2) those I-ETMS segments currently implemented with some human intervention with a non-vital level of safety assurance (MTTHE < 109 hours).

Vitally implemented functions are assessed based on the quantitative MTTHE allocated to the vendor-provided subsystems in the context of the complete system. 49CFR 236, Appendix C compliance will be assessed from available evidence against the safety principles listed in paragraph (b) of the Appendix.

Where human input to safety-critical functions is integral to the operation of the system, evidence is assessed to determine whether human errors are adequately mitigated by either the I-ETMS system design or by operating rules and procedures. These procedural mitigations are to be eliminated by “Predefined Changes” to achieve a fully vital system mitigation in the future as discussed in Section 6.2.2 of this PTCSP.

External interfaces to I-ETMS are addressed within the Risk Assessment to address whether these interfaces negatively impact the safety risk of the system. This specifically includes systems such as Computer-Aided Dispatch (CAD), locomotive functions such as brake interfaces, speed determination via tachometers, location determination via GPS, etc.

Risk Assessment Objectives 11.1.1

The objectives of the RA methodology employed for the I-ETMS are:



• Provide a clear and unambiguous view into the assessment of risks associated with safety-critical functions implemented in fail-safe and non-fail-safe components and subsystems.

• Provide a clear assessment of the compliance of all safety-critical system components/subsystems with 49CFR 236, Appendix C for purposes of substantiating Vital Overlay status.

• Assess whether any changes to CAD system capability associated with I-ETMS system deployment have safety impacts through a qualitative analysis.

Risk Assessment Methodology 11.1.2The methodology for the I-ETMS Risk Assessment was developed with input and review from the Joint Rail Safety Team and presented to FRA for comment. FRA comments relative to applicability of certain elements of the regulation resulted in the methodology that is reflected in this report. This section will summarize the specific assessment methodology applied, divided into its three major components:

1) Appendix C Compliance Assessment 2) CAD System Assessment 3) Residual Risk Assessment

Each of these components is described in additional detail under the dedicated subsections that follow.

A distinction is made in the Risk Assessment between PTC functions required by §236.1005 while in normal railroad operations and those same functions in degraded operating modes due to non-safety critical system failures. For failures that are within the scope of the PTC system, but are limited to failures relevant to degraded operating modes only, any associated probability of unsafe failure is de-rated by the MTBF of the failure precipitating the degraded mode. For example, a failure related to a locomotive engineer manually entering an erroneous switch position is conditioned by the failure rate(s) of PTC system equipment that would require manual entry rather than normal electronic conveyance of switch position through a Wayside Interface Unit.

11.1.2.1 APPENDIX C COMPLIANCE ANALYSIS From both the regulation and specific guidance provided by FRA, it is understood that the Vital Overlay PTC system, as built, must fulfill the safety principles in 49CFR 236 Appendix C, with the preamble to the Final Rule stating “FRA cannot overemphasize that vital overlay system designs must be fully designed to address the factors contained in Appendix C.” For each safety-critical functions provided by I-ETMS, the following safety principles are addressed:

1. System safety under normal operating conditions



2. System safety under failures 3. Closed loop principle 4. Safety assurance concepts 5. Human factor engineering principle 6. System safety under external influences 7. System safety after modifications

The risk assessment documents and analyzes the 49CFR 236, Appendix C principles applied within the I-ETMS system, both within and between individual components/subsystems. Within individual components/subsystems that are allocated vital functions, 49CFR 236, Appendix C compliance is demonstrated at that level for those functions. For example, the Locomotive Segment may utilize Checked Redundancy for a 2-out-of-3 vital processing architecture (among other Safety Assurance Concepts applied) in the Train Management Computer (TMC). As part of substantiating the designation of Vital Overlay PTC system, evidence is reviewable for 49CFR 236, Appendix C compliance verification for non-vitally implemented safety-critical functions as well. Some safety-critical but not vitally-implemented functions involve 49CFR 236, Appendix C compliance demonstrated at the system-level such as closed-loop processing with Design Diversity.

The safety evidence provided by the suppliers/developers of each safety-critical component/subsystem is analyzed in the Risk Assessment in Appendix F of this PTCSP to determine whether the applicable 49CFR 236, Appendix C safety criteria were met at the component/subsystem level. For safety-critical functions involving specific interaction between components the I-ETMS system requirements are also reviewed to verify that functionality necessary for 49CFR 236, Appendix C compliance is accurately represented. Particular attention is given to all cases where the MTTHE target(s) for a component/subsystem are based on the dependent factors of a safety assurance concept to verify evidence of proper implementation.

Some new or novel WIU products may require certification or approval under 49CFR 236, Subpart H Product Safety Plans. This risk assessment includes the MTTHE contributions from these units by reference, with the understanding that the Risk Assessment conclusion for each railroad will be contingent on FRA approval of any in-process Product Safety Plans for those new or novel WIU’s. As of the present time, no such WIU devices are employed by Metrolink/SCRRA.

For safety-critical I-ETMS WIUs having “grandfathered” status under 49CFR 236, subparts A-G, Metrolink is assuming this status extends to the requirement for 49CFR 236, Appendix C compliance at the product level and no additional evidence is included in this risk assessment. However, MTTHE targets for any components in this category are provided by those suppliers and the data provided is considered valid for purposes of this assessment, as the device/product has been accepted by the industry as having an overall MTTHE of at least 1x109 hours by definition.



11.1.2.2 RAILROAD CAD SYSTEMS IMPACT ASSESSMENT While the railroad CAD/dispatch systems system is not an I-ETMS component, it interacts with the I-ETMS system to support safety-critical functions. The Risk Assessment includes a qualitative assessment of the existing CAD system operation and the safety impacts of CAD system modifications, including new interfaces to the PTC system, in the proposed condition. The assessment determines whether any additional hazards are created and whether the risk level associated with CAD system functions in railroad operations relevant to PTC is changed.

This qualitative assessment examines the differences, if any, between the human interactions in the dispatch function in the previous and proposed conditions for the various methods of operation. It also includes an interface hazard assessment to determine the adequacy of mitigations of all hazards associated with new interfaces between the CAD/ office systems and the I-ETMS Office Segment.

11.1.2.3 RESIDUAL RISK ASSESSMENT Within the scope of the I-ETMS PTC system, an assessment is conducted based on a set of hazardous events that have been identified as applicable to railroad operations utilizing PTC. Hazardous events are often analyzed and developed in a hierarchical fashion, from top-level hazardous events such as ‘Collision’ or ‘Derailment’, but comparison at such a high level would be insufficient for this assessment. Functional Fault Tree (FFT) Analysis is utilized to decompose and identify the hazardous events that contribute to the top-level hazardous events at a level that correlates to the system segments/components being assessed.

Wabtec Railway Electronics (WRE), as the Locomotive Segment supplier and system developer, is providing the system-level I-ETMS FFT that is assessed and utilized for characterizing the system hazardous events and MTTHE values. The I-ETMS Functional Fault Tree also has input from other suppliers/developers. Multiple Wayside Interface Unit (WIU) vendors, for example, contribute subsystems to the overall Wayside segment implementation, and their MTTHE contributions are assessed as part of this Risk Assessment. Also, multiple vendors (including WRE) are developing Back Office Server (BOS) systems for the Office Segment that are included in the risk assessment. Safety-critical components being deployed for I-ETMS railroads encompass the scope of the RA.

Quantitative hazard rate data for use in the FFT’s is produced from multiple sources:

• For vitally implemented functions in the I-ETMS case, vendor supplied hazard rates are used with sufficient safety background information to validate that all FFT assumptions are satisfied. These hazard rates are supported by lower-level quantitative analysis (Platform Analysis, Failure Mode and Effects Analysis, Fault Tree Analysis, etc.) and evidence is reviewable.

• For non-vitally implemented safety-critical functions in the I-ETMS case, vendor supplied hazard rates may be used where available and a qualitative safety analysis is available, or where a quantitative reliability analysis utilizing hardware



MTBF’s has been performed. In any cases where neither is available, Battelle performed a risk analysis of the function and assigned a probability category (per AREMA Part 17.3.5) for use in the FFT.

The system functions as defined in the PTCDP are partitioned by safety criticality as shown in Table 11-1. The System Hazard Analysis (SHA) was reviewed to assess the System Functional Fault Tree (FFT) representation of each safety critical function. The safety-critical functions of the I-ETMS system as listed in the PTCDP [contained in Appendix B of this PTCSP] have been decomposed into the following categories. These categories are used for parsing the supplier FFT’s to assess the residual risk of the hazards associated with each safety-critical functional area.

Table 11-1 I-ETMS Functional Decomposition

Function #

System Function (Based on I-ETMS PTCDP Section 5, Table 6)

Safety Critical / Non-Safety Critical

1 Power Up and Diagnostics Safety Critical 2 Initialization Safety Critical 3 Consist Safety Critical 4 File Download Safety Critical* 5 Departure Test Safety Critical 6 I-ETMS System Synchronization Safety Critical 7 Location Determination & Navigation Safety Critical 8 Warning and Braking Calculation Safety Critical 9 Territory Entrance Protection Safety Critical

10 Protection of Movement Authority provided by Mandatory Directives

Safety Critical

11 Temporary Speed Restriction Protection Safety Critical 12 Work Zones Protection Safety Critical 13 Advisory or Cautionary Notices Protection Safety Critical 14 Protection of Notice of Highway Crossing Warning System

Malfunction Safety Critical

15 Protection of Notice of Track Out of Service Safety Critical 16 Critical Alert Protection Safety Critical 17 Permanent & Equipment Speed Enforcement Safety Critical 18 Wayside Signal Indication Enforcement Safety Critical 19 Switch Protection Safety Critical 20 Track Circuit Enforcement Safety Critical 21 Cab Signal Indication Enforcement Safety Critical 22 Reverse Movement Enforcement Safety Critical 23 Restricted State Enforcement Safety Critical **



Function #

System Function (Based on I-ETMS PTCDP Section 5, Table 6)

Safety Critical / Non-Safety Critical

24 Notification of Authority Violation by another Train Non-Safety Critical 25 Crew Authority Requests Non-Safety Critical 26 Cut-Out State Non-Safety Critical 27 Territory Exit Non-Safety Critical 28 Horn Activation Non-Safety Critical 29 Parking Brake Non-Safety Critical 30 Train Handling and Energy Management Assistance Non-Safety Critical 31 Logging Non-Safety Critical 32 File Upload Non-Safety Critical 33 Train Operation Exception Reporting Non-Safety Critical 34 Switch Position Awareness Non-Safety Critical 35 Crew Logoff Non-Safety Critical

* determined Non-Safety Critical after analysis, ** functionality not used by Metrolink

The FFT’s are parsed to assess the accuracy of representation of the relationship between the unsafe failures associated with each function and the functional and safety requirements of the system. The potential terminal faults identified in the FFT are categorized into the following groups:

1. Faults associated with PTC subsystem functions that are implemented vitally and have a quantitative MTTHE derived from techniques in compliance with 49CFR 236, Appendix C.

2. Faults associated with PTC subsystem functions that are implemented non-vitally and the residual risk for these faults will be handled qualitatively. The quantitative MTTHE derived from hardware FMEA calculations based on component Mean-Time-Between-Failure (MTBF) and/or qualitative assignment based on expert judgment according to the failure probability categories of AREMA C&S Manual, Part 17.3.5.

3. Faults associated with human errors associated with operations and maintenance of the PTC system. The subset of these faults that are unchanged from existing railroad operations are clearly identified to justify where these faults do not increase the safety risk over existing, acceptably safe operations.

4. For each function, a qualitative sensitivity analysis is conducted to determine the relative variance in risk from the various terminal faults contributing to the potential hazardous events of the function.

11.2 49CFR Part 236, APPENDIX C SAFETY PRINCIPLE COMPLIANCE CONCLUSIONS The identified safety critical functions were examined for compliance with the safety principles of 49CFR 236, Appendix C. Compliance was assessed based on adequate treatment of the safety principles of 49CFR 236, Appendix C as listed in section 11.1.2.1.



I-ETMS was found to be substantially in compliance with Appendix C safety principles for most safety critical functions. A limited number of functions were found to be conditionally compliant due to the need for additional clarification. Some functions were found to be partially compliant due to some components of the function appearing to lack compliance with one or more safety principles. Due to ongoing software development activities and requirements changes (e.g. CAF process) that could affect the baseline configuration presented for System Certification, additional revisions to software versions are anticipated and cannot be distinctly identified herein. In addition, Predefined Changes will be implemented in the future that will generate full compliance for all of the I-ETMS system functions. See the functional listing in Table 11-2.

Table 11-2 49CFR Part 236, Appendix C Compliance

Function #

System Function Assessment Notes

1 Power Up and Diagnostics Compliant

2 Initialization Compliant

3 Consist Partially Compliant Predefined change for closed loop consist verification in future

I-ETMS revision “predefined change”

4 File Download N/A

5 Departure Test Compliant

6 I-ETMS System Synchronization

Conditionally Compliant

Full compliance dependent on finalization of OSCAR

mitigations 7 Location Determination &

Navigation Partially Compliant Predefined change will replace

crew entry of initial position with automated process in the future

8 Warning and Braking Calculation

Compliant Full compliance determined by assessment of Platform Analysis

9 Territory Entrance Protection Compliant

10 Protection of Movement Authority provided by Mandatory Directives

Compliant

11 Temporary Speed Restriction Protection

Compliant

12 Work Zones Protection Conditionally Compliant

Predefined change will utilize EIC terminal for additional

protection in the future. 13 Advisory or Cautionary Notices

Protection Compliant

14 Protection of Notice of Highway Crossing Warning System Malfunction

Conditionally Compliant

Predefined change will provide protection of malfunctioning

crossing in the future 15 Protection of Notice of Track

Out of Service Compliant

16 Critical Alert Protection Compliant



Function #

System Function Assessment Notes

17 Permanent & Equipment Speed Enforcement

Compliant

18 Wayside Signal Indication Enforcement

Compliant

19 Switch Protection Compliant

20 Track Circuit Enforcement Compliant

21 Cab Signal Indication Enforcement

Compliant Not applicable to Metrolink

22 Reverse Movement Enforcement

Compliant

11.3 RAILROAD SYSTEMS IMPACT ASSESSMENT A qualitative assessment of the general pre-PTC CAD system operation and the safety impacts of CAD system modifications was performed, including new interfaces to the PTC system, with the deployment of I-ETMS. While the CAD system is not an I-ETMS system, it interacts with the I-ETMS system to support safety critical and non-safety critical functions.

This component of the assessment examined the interfaces and functions added to these railroad systems to support the operation of the PTC system. The assessment included the safety assumptions made by the PTC system concerning the operation of these railroad systems, and assessed any change risk level associated with CAD system functions in railroad operations relevant to PTC.

While specific railroad CAD and business systems implementations are tailored to each railroad, the general dispatch-related functions common to all railroads are assessed here. The qualitative results of this assessment are summarized in Table 11-3: As an example, Metrolink does not employ any direct interfaces to business system implementations as part of CAD or PTC itself. The Metrolink CAD system and PTC operations utilize standard features of the I-ETMS system. Most of these are common with the BNSF and UPRR use of the I-ETMS system controls and operation. There are no “unique” PTC functions of the Metrolink CAD which affect the PTC system itself.



Table 11-3 Railroad Systems Impact Assessment

Railroad Systems Function Assessment Notes

Identification of Locomotive/Train Consist

No Safety Impacts* * With assumption that all reviewable safety critical consist data is confirmed by the train crew.

Train Crew Assignments No Safety Impacts None

Train Route Planning No Safety Impacts None

Bulletin Management No Safety Impacts None

Authority Management No Safety Impacts None

Train Route Monitoring No Safety Impacts None

Trip Termination No Safety Impacts None

* Metrolink has a very limited set of consist variations, minimizing this risk.

11.4 Residual Risk Assessment Conclusions A table contained in Appendix E provides a listing of the worst-case unsafe failure rate and MTTHE for each safety critical function of the I-ETMS PTC system. The results by function represent worst-case contributions per function based in many cases on the use of optional functions or specific configurable operational capabilities.



12 Hazard Mitigation Analysis [§236.1015(d)(4)]

This section of the PTCSP describes the Metrolink PTC system hazard mitigation analysis, including a complete and comprehensive description of each hazard and the mitigation techniques used to minimize its frequency and risk as required by 49CFR §236.1015(d)(4). The resultant analyses are located in Appendix G of this PTCSP.

The organization of the Hazard Mitigation Analysis is shown in Figure 12-1. This figure shows that qualitative Hazard Analyses are collected and summarized in the Hazard Log (Section 9). Mitigations for hazards are also identified and associated with applicable hazards. Safety conclusions are drawn from the work completed in the Hazard Log. Mitigations that trace from the Hazard Log as safety requirements and training requirements are contained in both the Safety Requirements document and in the Operation and Support Checklist Applicable to Railroads (OSCAR) document, respectively.

The Functional Fault Tree (FFT) and Fault Tree Analysis (FTA) are used as the basic inputs to the System Hazard Analysis (SHA), which reflects the total I-ETMS system implementation. The SHA feeds the Risk Assessment (RA), from which other safety conclusions are drawn. The Hazard Log is also reflected in the SHA. The Failure Modes and Effects Analysis (FMEA) provides input for the Platform Analysis, from which conclusions about the component level safety of the processor boards is determined. These also support the SHA. All of these analyses create the input which defines the risk assessment process and results in conclusions about system risk as defined by the regulation.



Figure 12-1 Organization of Hazard Mitigation Analysis

12.1 System Preliminary Hazard Analysis (PHA)

A Preliminary Hazard Analysis (PHA) was developed to identify system level hazards associated with implementation and their causes from system faults and/or human errors. The PHA includes preliminary hazards related to all aspects of the PTC system, including hazards that could potentially be introduced by CAD. The resulting artifact of this activity is the PHA document contained in Appendix G.1 of this PTCSP.

Methodology of the PHA 12.1.1

System hazards were reviewed among PTC vendors and railroads to establish that the set was complete. The PHA is a tabular analysis that was developed by the system vendor (WRE) per the guidelines provided by both MIL-STD-882C [1] and ARP-4761 [20] for a PHA document. Using the known functions and objectives, each preliminary PTC system hazard was identified and documented in the PHA. After review, the set of hazards, causative faults, and Initial Risk Index were transferred to the Hazard Log for determining mitigations and then referenced to system requirements for I-ETMS. Procedural requirements were also developed to provide additional controlling measures wherever required to reduce the risk associated with a given hazard to an acceptable level. The relationship to the HL ensured that all PHA hazards were tracked throughout the development process, and fully resolved.



The PHA identifies the safety critical areas, assesses the inherent safety of the system, provides an Initial Risk assessment of the hazards, and aids in the identification of effective hazard controls and required actions. The PHA was conducted by analyzing the system for all hazards that can directly cause mishaps (e.g., collision, derailment, injury, or damage), per MIL-STD-882C. The PHA includes hazards that expand from the Level 0 Requirements and correlates them to applicable PHA hazard entries to result in a complete system level PHA.

The PHA document contains the following material:

1. Section 1 – Introduction to the PHA:

a. Defines the purpose and scope

b. Identifies referenced documents

c. Provides definitions for key elements and acronyms

d. Provides an organizational overview of the description document

2. Section 2 – Analysis Process:

a. Describes the methodology used to develop the PHA

b. Lists the PHA table column definitions

3. PHA Results Table:

a. Contains the system level preliminary hazards

b. These hazards are entered as defined by Section 2

The results from the PHA are used as an initial source to develop more detailed hazard analyses, specifically the Functional Fault Tree (FFT) and the Subsystem Hazard Analysis (SSHA). These similar analyses break the system faults down into causative segment faults or component faults within the I-ETMS system. Human error faults from the PHA are further developed to contributing causes in the Operations & Support Hazard Analysis, or O&SHA.

Because it is a one-time analysis, the PHA was “frozen” once completed and reviewed, and any further activity is addressed through the Hazard Log as identified.

As a result of performing the PHA activity, the following actions were executed as part of the ongoing Metrolink safety program for this PTCSP:

1. Created SSHA and FFT analyses using PHA results as input.

2. Developed appropriate system mitigations in the Hazard Log and linked mitigations to L0, L1, or L2 requirements or to procedural requirements.



The PHA generates system level results. Any system level hazards unique to Metrolink’s PTC system are also included in the PHA.

The following documents were referenced or used in support of the PHA:

1. I-ETMS System Safety Program Plan, Wabtec Railway Electronics. 1/2011 [17]

2. I-ETMS PTCDP Rev 3.0 as Type Approved by FRA, provided in Appendix B of this PTCSP.

3. Positive Train Control ITC System Requirements Level 0 and Level 1” [19]

4. U.S. Department of Defense Military Standard (MIL-STD) 882C, “System Safety Program Requirements”, 19 January 1993 [1]

5. ARP-4761, Aerospace Recommended Practice, “Guidelines And Methods For Conducting The Safety Assessment Process On Civil Airborne Systems And Equipment”, December 1996 [20]

Results from PHA 12.1.2

Metrolink has the following results from the PHA:

1. Hazards from human error are more prevalent than hazards from PTC equipment failure.

2. System level hazards are easily decomposed into subsystem faults.

12.2 Locomotive (Onboard) Subsystem Hazard Analysis (LSSHA) The Locomotive Segment Subsystem Hazard Analysis (LSSHA) is conducted to identify hazards associated with failures of the locomotive subsystem and their effects. The Locomotive Segment SSHA includes consideration of component failure modes, critical human error inputs, and hazards resulting from functional relationships between components and equipment of the locomotive subsystem. It is to identify safety critical areas, assess the inherent safety of the system, and aid in the identification of beneficial hazard controls and appropriate next steps. This SSHA document presents the completed Locomotive Segment SSHA table, describes the methodology used to create the Locomotive SSHA, and defines the table columns. The scope of this analysis is limited to functionality of the Locomotive Segment as defined by the “I-ETMS On-board Segment Requirement Specification”. The office SSHA is contained in the following section. The WIUs are Part 236 A-G compliant and need no SSHA. The Locomotive Segment refers to a set of independent onboard hardware, software, and devices that interface with locomotive control equipment (e.g. air brakes, train line) and includes a Train Management Computer (TMC), a Cab Display Unit (CDU), a Locomotive ID module, a GPS receiver, and a brake Cut-Out



switch. The Locomotive Segment does not include the Communications Segment components. The Locomotive SSHA is contained in Appendix G.2 of this PTCSP.

Locomotive SSHA Methodology 12.2.1The process for conducting the Locomotive Segment SSHA is comparable to the process for conducting the Preliminary Hazard Assessment (PHA). The SSHA is conducted by analyzing the Locomotive Segment subsystem for all hazards that can cause mishaps (e.g., collision, derailment, injury, or damage). The SSHA includes hazards that expand from Level 1 Requirements and correlates them to applicable SSHA hazard entries resulting in a complete Locomotive Segment SSHA. Hazards are decomposed into a complete list of causes. In some cases, identified causes are assessed and recognized as potential hazards to be included in the SSHA analysis as well. In those cases, another separate SSHA line entry, with a new Hazard ID, is included. For cross reference, the SSHA Hazard ID of the newly identified hazard is listed alongside the originating case within the cause column. All hazards identified in the Locomotive SSHA will be subsequently entered into the Hazard Log (HL) for hazard mitigation identification and to track that adequate control of the potential hazard is implemented. Although the process for conducting the PHA and SSHA are similar they are conducted at different levels. The PHA evaluates the hazards associated with the system whereas the SSHA evaluates one of the subsystems. Multiple SSHA analyses may be performed to address different subsystems. As a general rule, the PHA’s sources of error will appear as a top level hazard within the SSHA analyses. This correlation will be made in the Hazard Log. Performing the analyses independently provides a check and balance between the analyses.

Results from Locomotive SSHA 12.2.2The initial draft of the Locomotive Segment SSHA was created based on a top down refinement of the hazards identified within the PHA as assessed against the I-ETMS on board subsystem design as it evolved. Based on performance of a series of functional design and operating and support verification activities involving the onboard I-ETMS components, the Locomotive Segment SSHA has been further updated to reflect the final set of hazards and mitigation requirements which have been incorporated into the I-ETMS Hazard Log. As a result, hazard identification associated with the Locomotive Segment equipment is considered complete.

1. All hazard mitigations in the form of design related safety requirements and those safety requirements related to operating and support documentation, operating rules/procedures and training, as applicable to the onboard subsystem, have been captured.

2. Evidence has been provided, that confirms that the mitigations to I-ETMS on board subsystem hazards have been incorporated into the I-ETMS design as well as supporting rules, procedures, documentation and training programs, therefore justifying closure of SSHA related Hazard Log entries.



3. Due to use of CRC Codes, communication failures that cause hazards are considered improbable. A SYNC Error that results from a CRC mismatch results in the on-board system starting a countdown to going disengaged. If the crew acknowledges the message, the system goes disengaged and no penalty stop is initiated. stopping the train. Security measures are designed and implemented in the system such as use of device/user authentication, use of hardware keys with passwords, access logs, etc. Good security practices are also used by Metrolink, such as restricting physical access to communications equipment to authorized personnel only. See the Metrolink Security Planning described in Appendix CC of this PTCSP.

12.3 Office Subsystem Hazard Analysis (OSSHA) The Office Segment Subsystem Hazard Analysis (OSSHA) is conducted to identify hazards associated with failures of the office subsystem and their effects. The Office Segment SSHA includes consideration of component failure modes, critical human error inputs, and hazards resulting from functional relationships between components and equipment of the office subsystem. It is used to identify safety critical areas, assess the inherent safety of the system, and aid in the identification of beneficial hazard controls and appropriate next steps. The SSHA document presents the completed Office Segment SSHA table, describes the methodology used to create the Office SSHA, and defines the table columns. The scope of this analysis is limited to functionality of the Office Segment as defined by the “I-ETMS Back Office Segment Requirement Specification”. The Office Segment accepts mandatory directives and other information generated by the railroad’s dispatching system and other railroad information systems, and provides it to the Locomotive Segment. The interface between the Office Segment and railroad dispatching and railroad information systems may be proprietary to a particular railroad. However, the Office Segment normalizes the operating data provided by a particular railroad’s dispatching and information systems for exchange over an interoperable interface with the Locomotive Segment, making the SSHA a document for application of I-ETMS to Metrolink and other railroads. The Office SSHA is contained in Appendix G.3 of this PTCSP.

Office SSHA Methodology 12.3.1The process for conducting the Office Segment SSHA is comparable to the process for conducting the Preliminary Hazard Assessment (PHA). The SSHA is conducted by analyzing the Office Segment subsystem for all hazards that can cause mishaps (e.g., collision, derailment, injury, or damage). The SSHA includes hazards that expand from Level 1 Requirements and correlates them to applicable SSHA hazard entries to result in a complete Office Segment SSHA. Hazards are decomposed into a complete list of causes. In some cases identified causes are assessed and recognized as potential hazards to be included in the SSHA analysis as well. In those cases, another separate SSHA line entry, with a new Hazard ID, is included. For cross reference, the SSHA Hazard ID of the newly identified hazard



is listed alongside the originating case within the cause column. All hazards identified in the Office SSHA will be subsequently entered into the Hazard Log (HL) for hazard mitigation identification and to track that adequate control of the potential hazard is implemented. Although the process for conducting the PHA and SSHA are similar they are conducted at different levels. The PHA evaluates the hazards associated with the system whereas the SSHA evaluates one of the subsystems. Multiple SSHA analyses may be performed to address different subsystems. As a general rule, the PHA’s sources of error will appear as a top level hazard within the SSHA analyses. This correlation will be made in the Hazard Log. Performing the analyses independently provides a check and balance between the analyses.

Results from Office Segment SSHA 12.3.2The results from the Office SSHA indicate that there are certain hazards which are not currently mitigated by the PTC System itself and therefore rely on procedural mitigations as would be performed by the train Engineer or other personnel. These hazards affect operation under PTC failure conditions or per Track Warrant or Direct Traffic Control (DTC) only.

1. Track Warrant/Track Authority, Track and Time/Track Permit, Enter main Track, and Pass Signal at Stop are all types of Form Based Authority which currently rely on procedural mitigations by the train Engineer following rules and procedures. The “predefined changes” to the I-ETMS system will eliminate these in the future.

2. Failure to provide for conveyance of Mandatory Directives either in conjunction with the existing verbal conveyance process or in a standalone manner to supplant the verbal process presents a hazard which is minimized by operator action onboard the train per rules and procedures.

3. Erroneous data encompasses erred, missing, and stale data. This is detectable by the operator by comparison with verbal or written transmission of the same data. Fixed safety-critical data in memory is protected by CRC codes. Fixed message data is protected by CRC codes which have a high probability of detecting errors in transmission and eventually declaring communications as failed should multiple detected errors occur. Therefore, communication failures directly causing hazards are considered improbable.

12.4 Operating & Support Hazard Analysis (O&SHA) The overall goal of an Operating and Support Hazard Analysis (O&SHA), as generally depicted by industry standards (e.g., MIL STD 882C), is to capture hazards associated with operational and support tasks performed by personnel for a given system and to evaluate the adequacy of procedures put in place to direct the activity of executing the tasks, to mitigate the identified hazards. Generally this would entail a review of procedures and tasks associated with system production, deployment, installation,



assembly, test, operation, maintenance, service, storage, transportation, modification, decommissioning and disposal as well as considerations of the human interactions anticipated. The O&SHA is contained in Appendix G.4 of this PTCSP.

O&SHA Methodology 12.4.1For I-ETMS, Metrolink’s goal was to adapt the general methodology of an O&SHA and apply it to the context of the I-ETMS PTC deployment thereby aligning the analysis and the anticipated results with the requirements of 49CFR 236 Subpart I and related I-ETMS PTCSP safety documents produced by the Joint Rail Safety Team (JRST) and Wabtec Railway Electronics (WRE). The Metrolink I-ETMS O&SHA analysis identifies all O&SHA related hazards, level of risk and proposed mitigations as safety requirements. O&SHA references are carried forward into the I-ETMS Hazard Log located in Appendix D of this PTCSP, where mitigations of O&SHA identified hazards are to be tracked and closed. The O&SHA analysis is considered a component of the I-ETMS Risk Assessment and is used therein. The O&SHA is contained in Appendix G.4 of this PTCSP. The purpose of the I-ETMS O&SHA is to identify tasks carried out by Metrolink employees during the implementation and post implementation of the I-ETMS PTC system, that can lead to a hazardous situation either through incorrect execution of a task, through the following of a task procedure that does not adequately mitigate the incorrect execution by railroad personnel, or by failure to execute a task when needed. It is important to note that the O&SHA is intended to address only those tasks and procedures that are incremental to the railroad’s operation through the deployment of the I-ETMS. It is assumed that operating rules, and support tasks already in place to support the underlying Methods of Operation are addressed by other SCRRA rules, procedures, practices and training. An O&SHA for the entire railroad system is outside the scope of the PTC development and deployment. As an example, it is anticipated that some level of maintenance and support activities related to wayside interface units, will likely be incorporated into existing wayside maintenance procedures and are treated similar to other vital signaling components. As such, current tasks associated with repair/replacement and configuration are intended to be managed in the same manner as if they were performed prior to implementation of PTC and therefore will not be described in detail in this O&SHA. Only reviews of PTC specific tasks are to be considered within the detailed analysis. The O&SHA, then, is focused on activities associated with installing, maintaining, repairing, modifying, inspecting, and testing of safety-critical elements of the railroad’s I-ETMS PTC systems, as applicable. This analysis addresses potential hazards that could occur within each of the relevant technical segments of Wayside, Communications, Office and Locomotive Segments.



The O&SHA is a standalone document that provides necessary background of the effort as it applies to Metrolink’s I-ETMS implementation and includes an appended table of hazards as findings of the analysis with associated risks and mitigations. O&SHA entries are then transferred to the I-ETMS Hazard Log as safety requirements identifying Metrolink hazards. The resulting mitigations were confirmed during V&V processes and the OSCAR analysis.

Results from O&SHA 12.4.2The performance of an O&SHA resulted in recommendations for changes or improvements to operating procedures, safety critical aspects of the system not previously considered through other hazard analysis efforts, procedure updates, development of warning or caution entries to system manuals and focused training for personnel whose work tasks are associated with each of the four I-ETMS Segments.

1. As with the current underlying Method of Operation, under the operation of the I-ETMS system, the train crew is required to read, repeat, and fully understand Authorities and Bulletin Items and their limits or instructions.

2. Overall I-ETMS system safety depends in a large part on the correctness and completeness of the contents of the database files that represent Railroad configurable items, Train Consist, Track Database/Subdiv files, etc. Track Database V&V is discussed in Section 13.4 of this PTCSP. Fixed data files in memory are protected by CRC codes that detect corruption of the files.

3. Rigorous change and configuration management of track database and equipment configuration files is a key safety requirement for I-ETMS systems.

4. Training, Operation and Maintenance manual documentation must highlight safety critical impacts of adjustments, settings, and maintaining proper equipment configuration during and after maintenance or repair. Staff assigned to these activities must be trained in their safe process using appropriate support and documentation. The SCRRA I-ETMS Training Plan, training materials, and training records are discussed in Section 14 and Appendix K. PTC training of Metrolink PTC personnel has been ongoing and is presently complete for current employees. New employees receive PTC related training as part of their job training. As with all training, the training programs evolve with the addition of new features, changes in operation or lessons learned.

12.5 System Functional Fault Tree (FFT) The Functional Fault Trees (FFT) are system level fault trees that examine hazards of the I-ETMS system potentially caused by the Office Segment, Locomotive Segment, Communication Segment, Wayside Segment, Track Database, related external elements, and human error. The FFT decomposes to the segment levels and identifies external elements that may impact the system segments. Additional decomposition of identified Locomotive Segment and Office Segment level terminal events are completed in the subsystem



Fault Tree Analyses (FTA) described in Section 12.6 of this PTCSP. The equivalent analyses of the Wayside WIU component are contained in Appendix V of this PTCSP. The Communications Segment is not decomposed because communication hazards are assigned to other segments for mitigation. Decomposition of identified external events is not included in the FFT or the FTA. Examples of identified external elements include: Computer Aided Dispatching (CAD), Cab Signal Aspect Systems, and items identified as not part of the I-ETMS implementation. The Functional Fault Tree is contained in Appendix G.5 of this PTCSP.

Functional Fault Tree Methodology 12.5.1Wabtec uses the CAFTA® tool to generate the functional fault tree diagrams. The functional fault tree diagrams develop from the top down, beginning with the top events of: Train Collision; Train Derailment; Equipment Damage; and Human Injury or Death. Each top event is logically decomposed into layers of lower, more specific contributing factors and terminate with failures or errors attributable to the Office Segment, Locomotive Segment, Communication Segment, Wayside Segment, related external elements (such as CAD or other Railroad Office system), and human factors.

Results from Functional Fault Tree Analysis 12.5.2The conclusions from performing the Functional Fault Tree Analysis can be summarized as follows:

1. The terminal events from each top level hazard are generally the same and can be treated similarly for mitigation.

2. Failure to detect an incorrect or corrupted incoming message is a major source of the PTC subsystem terminal events and can be found throughout the FFT structure.

3. Communications failure related to the wayside segment to locomotive is a specific major cause of PTC subsystem terminal events within the overall scope of communication error detection failures, however:

4. Due to the vital design of the locomotive segment, the probability of unmitigated communication failures causing hazards is considered improbable. Missed or mismatched communications result in a stopped train.

12.6 Segment Fault Tree Analysis (FTA) The Fault Tree Analysis (FTA) examines hazards of the I-ETMS terminal events identified during the Functional Fault Tree (FFT) analysis and are listed as Terminal Events of the FFT. The FTA decomposes only the Office and Locomotive Segment terminal events identified in the FFT analysis. The equivalent analyses of the Wayside WIU component are contained in Appendix V of this PTCSP. Decomposition of identified external events is not included in the FFT or the FTA. External events are part of a standard FTA or FFT, but they are identified as terminal unanalyzed events. They are identified, but not analyzed, within the scope of PTC analysis.



Examples of identified external elements include: Computer Aided Dispatching (CAD), Cab Signal Aspect Systems, and items identified as not part of the I-ETMS implementation. The Fault Tree Analysis is contained in Appendix G.6 of this PTCSP.

Fault Tree Analysis Methodology 12.6.1Wabtec uses the CAFTA® tool to generate the fault tree analysis diagrams. The fault tree analysis diagrams develop from the top down, beginning with the segment level terminal events identified in the FFT analysis. For this FTA, only the FFT terminal events allocated to the Office Segment and the Locomotive Segment are analyzed. The communications Segment does not indicate a need for such analysis and the fault tree analysis of the Wayside WIU component is referenced in the WIU Safety Case in Appendix V of this PTCSP. Each FFT terminal event becomes a top event in the FTA that is logically decomposed into layers of lower, more specific contributing factors. FTA diagram pagination is established with manual page top settings. To support customer delivery, the fault tree is submitted as a PDF, oriented for printing in landscape mode on 11”x17” size sheets.

Results from Fault Tree Analysis 12.6.2As shown in Figure 12-1, the results from the FTA are incorporated in the System Hazard Analysis and are supplied to the Risk Assessment to reach a final safety conclusion. The Fault Tree Analysis for the Office Segment and the Locomotive Segment have the following specific results:

1. Many terminal events cite processor functional failure. The locomotive segment processors can each make errors in processing of the data, but rely on the probability that no two processors will simultaneously have the same failure.

2. Systematic failure is cited by multiple terminal events. Systematic failure is minimized by a well-defined development and testing process for the design of the hardware and software of the locomotive segment. Since the segments analyzed by FTA are produced by Wabtec, the audits of Wabtec Process for software development are contained in Appendix Z of this PTCSP.

3. Corruption of onboard data is cited by multiple events. Corruption is detected by a CRC code which has a high probability of detecting errors in stored data. The onboard message receipt function therefore, protects against corrupt data being accepted. Thus, Communications Segment failures causing hazards are considered improbable, because they are protected by the messaging scheme using the CRC code.

12.7 System Hazard Analysis The System Hazard Analysis (SHA) is an extension of the FFT and FTA process described above. These system level fault trees examine the hazards of the I-ETMS system potentially caused by the elements of the system as implemented. The fault



trees combine the analysis of the FFT and the FTA so that low level terminal events contribute to system level hazards. Non-safety critical functions have been pruned from the SHA to streamline the analysis. The SHA utilizes failure rates and exposure time for terminal events and directly supports the Risk Assessment by assigning risk categories to events for use in assessing system risk. The System Hazard Analysis is contained in Appendix G.9 of this PTCSP.

System Hazard Analysis Methodology 12.7.1Wabtec uses the CAFTA® tool to generate the functional fault tree diagrams used for the SHA. The SHA fault tree diagrams were taken from the FFT developed and top level events of: Train Collision; Train Derailment; Equipment Damage; and Human Injury or Death. Each top level event is logically decomposed into layers of lower, more specific contributing factors. Where the FFT terminated at the segment level, the SHA incorporates the FTA development. The SHA continues to be reviewed and modified to reflect I-ETMS implementation and for consistency. Non-safety critical elements were pruned from the tree.

Results from System Hazard Analysis 12.7.2The conclusions from performing the System Hazard Analysis can be summarized as follows. Several of these conclusions have already been addressed by such approaches as requiring two independent crew inputs (key presses) to enable functionality. The use of train crew inputs in any form is to be eliminated by the future vital implementation of “predefined changes” discussed in section 6.2.2 of this PTCSP.

1. Terminal events relative to a single key press to pass signal at stop (PSS) at an absolute signal could result in a worst case event of collision. Each signal in the track database is configured to either allow crew input in the PSS scenario or to mandate electronic PSS authority from the railroad’s dispatching system. If the track database is configured to disable crew input, these failure modes are removed. Metrolink requires electronic authority, and if electronic authority is not received, there is a ten minute wait enforced after confirming permission to pass.

2. BOS induced failures that either corrupt or lose authority or bulletin data have been identified to potentially result in worst case events of either collision or derailment. The current system implementation requires procedural verification of verbal/paper data against electronic data received on-board to reduce the probability of occurrence of the top event. Functionality of the IC3 has been defined and designed to eliminate the need for the procedural review in the future.

3. The case where the railroad allows an on-board crew to edit received consist information has been identified to potentially result in a worst case event of derailment. Metrolink’s operational rules do not allow the crew to modify train consist. However, SCRRA does not disable this function because tenant UP allows their crews to modify consist. BNSF currently does not allow their crews to modify consist with dispatcher permission. This event can potentially be



eliminated in the future by disabling the on-board configurable option (CFG14) which presently allows a crew the capability to modify received consist, upon agreement with tenant UPRR.

4. Terminal events relative to a single key press on the CDU to indicate permission to Enter Main Track (EMT) has been received from the Dispatcher could result in a worst case event of collision. This event can be eliminated by disabling the on-board configurable option (CFG13) which allows a crew the capability to use a key press to indicate permission to EMT. This would force an electronic EMT authority to be received from the railroad’s dispatching system. SCRRA requires electronic permission to enter main track. Tests were done on EMT functionality for electric lock, signal in lieu of an electric lock, and for hand operated switch where siding speed is not greater than 30MPH. These tests, as documented, were successful in the field.

12.8 Failure Modes and Effects Analysis (FMEA) The FMEA is contained in Appendix G.7 of this PTCSP as 3 files, each representing a part of the FMEA.

FMEA Methodology 12.8.1The Failure Modes and Effects Analysis (FMEA) is the formalized method of analyzing vital hardware terminal faults as typically identified in the Fault Tree Analysis. Each design element implemented in either Class I or Class II hardware can be reviewed to the "component level" for failure modes and probabilities, and widely used techniques from the literature are applied. This “bottom-up” analysis is part of the Verification of the I-ETMS components. The specifics of this procedure apply to the low level analysis that analyzes individual electronic or electromechanical component failures (e.g., resistor, relay, transistor, etc.). The purpose of the low level FMEA is to show that a circuit has no unsafe modes of failure. As such, it involves highly analyzable discrete hardware components, and does not contain integrated circuits or software. This is because there is a nearly infinite set of failure modes for such complex elements and they are not used in the circuits analyzed by the FMEA method. Safe operation under conditions of random hardware failures within discrete Class II hardware of the TMC platform is verified in the Failure Modes and Effect Analysis (FMEA), in which the effects of each failure mode of each component is analyzed to assure it does not result in an unsafe failure. Failure effects are also categorized as self-revealing or non-self-revealing (latent). Latent failures are analyzed in combination with other latent failures and with self-revealing failures to verify that no combination of such failures will produce an unsafe condition. The TMC FMEA analyzes key circuitry of the TMC on a component-by-component basis.



Results of FMEA 12.8.2The results of the FMEA show that there are no single points of failure which result in an unacceptable failure of the TMC. An unacceptable failure is a failure, which has a hazard risk index per MIL-STD-882C, Appendix A, 30.5.2 that is classified as “Unacceptable.”

12.9 Platform Analysis The TMC Platform Analysis represents a common low-level safety artifact that addresses safety verification of the I-ETMS onboard segment and is independent of any particular I-ETMS PTC application or end user. The objective is to provide sufficient and comprehensive safety justification to demonstrate that the I-ETMS TMC design and its safety critical run-time interfaces within the Locomotive Segment, comply with the requirements of 49CFR 236 Subpart I, and specifically 49CFR 236, Appendix C regarding safety assurance principles for vital overlay PTC systems; as identified in §236.1015 (e)(2)(ii). The Platform Analysis is contained in Appendix G.8 of this PTCSP.

Platform Analysis Methodology 12.9.1As identified within the I-ETMS System Safety Program Plan, the primary elements and general deliverables of Conceptual, Functional and Implementation levels of safety verification are referenced by the Platform Analysis. Safety verification documentation is aligned with industry standards such as IEEE 1483-2000, and it documents the verification activities at the PTC application layer, and on-board computing system (TMC and its supporting interfaces) at the lowest level. The verification includes the identification of platform safety critical functions implemented by hardware and software, the verification methodology, and documentation to support that the TMC and its interfaces meet the safety goals for the system, and substantiates the level of safety assurance (MTTHE) for the platform-related components and functions.

Results from Platform Analysis 12.9.2

The Platform Analysis systematically decomposed I-ETMS functionality into low-level platform functions. A ll functions were evaluated and successfully provide justification that the element is implemented as designed in support of the vital functionality.

Train Control Processing – This analysis documents the use of three independent processing cards that are constructed from independent hardware, utilize a verifiable operating system, and cross channel compare key data to justify a probability of undetectable, erroneous processing of 3E-10. This implementation allows a conservative estimate of each individual processing channel error to be 1E-5, which is readily achievable using processor-based circuitry.

Digital Discrete Inputs – All digital discrete circuits utilize independent DIO input hardware that is electrically isolated from a microcontroller. All digital data is read and packed into a single 1 Hz broadcast message. An assumed failure rate of 1E-5 dominates the failure rate of the input circuitry. Although the microcontroller is common between all discrete circuits, the simplicity of the firmware, external checked redundancy, and continuously varying data makes the undetectable, unsafe failure



modes improbable. Each discrete input can be treated as an independent external to the receiver.

Analog Inputs – Each analog discrete input utilizes independent IOC receiver hardware that is electrically isolated from a microcontroller. Similar to DIO, the assumed failure rate of the microcontroller that defines the failure for an analog input is 1E-5.

Wheel Tach Inputs – The DIO also inputs the Wheel Tach data. Isolated input circuitry has no failures that can result in anything other than no input. The assumed microcontroller again overwhelms the signal input failure rate; 1E-5 is utilized for erroneous wheel tach data. External comparison with differential data allow for high integrity speed and location determination.

GPS Input – The IOC receives and passes GPS data to the train control processors. No alteration of data occurs and validation is left to external processors. Similar to analog input, the assumed failure rate of the IOC microcontroller defines the failure for erroneous GPS data. External comparison with differential data allows for high integrity speed and location determination.

Electronic Brake Interface (EBI) Failure to Enforce – The Platform Analysis analyzes the Class II hardware implementation of the EBI card. The fail-safe aspects of the design have a 3E-8 probability of failing to enforce dominated by 2 of 3 microcontrollers (each conservatively assumed to have MTTHE of 1E5) failing to enforce upon request.

Crew Inputs – A failure rate of 1E-3 is assumed for crew member erroneous key press. More importantly, the independence between multiple key presses is justified even with the use of a common mode CDU processor. Multiple key presses use different keys which must be pressed, encoded, transmitted to the TMC and received correctly, in order, and uncorrupted to be accepted as a confirming entry by the train Engineer. This process means that errors introduced by the CDU must be identical to the proper key presses in timing and order and message content to be possibly accepted by the system. The Engineer would have to make two independent errors in acknowledging the condition in order for the result to be unsafe, which is a probability of 1E-3 “ANDed” with 1E-3.

12.10 TMC Environmental Testing Results The results of environmental testing of the I-ETMS TMC are provided in Appendix G.10 of this PTCSP. The table in this Appendix G.10 shows that all specified environmental tests were passed by the unit under test. Details of the testing and report are available to FRA upon request.

12.11 EMC Testing Results As shown in Appendix G.11 of this PTCSP, Electromagnetic Compatibility testing was performed by an independent laboratory on the I-ETMS Onboard equipment package



including the TMC and the CDU. The results show that the I-ETMS equipment passed all of the designated tests.



13 Verification and Validation Processes [§236.1015(d)(5)]

As required by 49CFR §236.1015(d)(5), this section of the PTCSP provides a complete description of the Verification and Validation processes applied to Metrolink’s PTC system and the results of those processes.

The goal of the system safety process and compliance with 49CFR 236, Appendix C, as detailed in Section 8, along with Verification and Validation, is to ensure that the development, functionality, architecture, installation, implementation, inspection, testing, operation, maintenance, repair, and modification of I-ETMS will achieve and maintain an acceptable level of safety.

The basic process leading to the certification of the Metrolink I-ETMS PTC system is given in Figure 13-1. This flow diagram shows how the components described in this section are related to one another. Completing the process shown in Figure 13-1 will result in the FRA being provided with all material believed necessary for certification.



Figure 13-1 Metrolink Certification and V&V Flowchart

13.1 Master Test Strategy The Master Test Strategy document describes the strategy and approach utilized for testing of the Interoperable Electronic Train Management System (I-ETMS). It contains a high-level description of the testing processes and procedures that were followed, the management of defects encountered during the testing process, the various levels of testing conducted, the entrance criteria to each level of test, the exit criteria from each level of test, and the resource requirements of each level of testing.



The purpose of the testing effort is to demonstrate that the I-ETMS System is in conformance with system requirements and business processes in both a laboratory and a field environment in order to obtain acceptance of the I-ETMS System and to facilitate Positive Train Control Safety Plan (PTCSP) development and acceptance. The Master Test Strategy describes the following levels of test:

• Initial developmental testing that was conducted by each organization supplying a system component or function. The tests are comprised of Unit Test, Integration Test, and Segment Test.

• Laboratory testing includes informal levels Laboratory Integration Nearest Neighbor and Laboratory Integration End to End Tests and formal levels of Laboratory Qualification Segment Test and Laboratory Qualification End to End Test.

• Field testing including Field Integration Test and Field Qualification Test.

The Master Test Strategy can be summarized as follows:

• Provides guidance for the management and technical effort necessary to support the test program.

• Defines the level of testing deemed necessary to achieve the I-ETMS program goals and objectives.

• Provides assurance of a high level of test coverage through requirements traceability.

• Identifies the primary personnel, equipment, and facility resources required to support the test program.

• Does not deal with Revenue Service Demonstration or Extended RSD because this is not part of the V&V program for Metrolink. RSD and ERSD are monitored operations of the system under revenue conditions, not tests executed under controlled conditions as in the V&V process.

13.2 Validation and Verification of I-ETMS

Validation, as defined in Part 236, Subpart H, and subsequently applied to Subpart I by FRA means, “The process of determining whether a product's design requirements fulfill its intended design objectives during its development and life-cycle. The goal of the validation process is to determine ‘whether the correct product was built.”

Verification is defined in Subpart H, and subsequently applied to Subpart I by FRA, as “the process of determining whether the results of a given phase of the development



cycle fulfill the validated requirements established at the start of that phase. The goal of the verification process is to determine ‘whether the product was built correctly.”

I-ETMS safety verification is comprehensive; it included the identification of safety-critical functions and the verification that the identified vital functions have been implemented in a fail-safe manner to the degree required by the system safety goals and applicable train control system regulations.

Validation & Verification (V&V) for I-ETMS was a comprehensive analysis and test of the system software and hardware to determine that it performs its intended function, to ensure that it performs no unintended functions, and to measure its quality and reliability.

13.3 PTC System Validation and Verification Processes

The V&V process for I-ETMS included, but was not limited to, each of the following activities:

• Requirements tracing across multiple specifications, ICD, use case, test case, and statutory and regulatory documents

• Development of the Positive Train Control I-ETMS Master Test Strategy, test scenarios and test cases for I-ETMS

• Tests, analysis, inspection or demonstrations

• Process audits and reviews

• Multiple requirements reviews to assure software requirements were correct, complete, consistent, accurate, readable, and testable, and would satisfy the system requirements

• Identification of safety critical requirements and functions

• Code and peer reviews

• An architecture review

• Critical design review(s) (CDR), including review with FRA

• Verification tests through unit and component integration tests

• Laboratory system integration test, including regression tests

• Field testing

• Track data validation



• Commissioning and operational tests

• Documentation of traceability of hazards to specific mitigation

As part of the due diligence in assessing the quality of the component development and V&V, members of some Class I railroads performed audits and analyses of several of the I-ETMS segments including Locomotive, Back Office and Communications. These audits focused on the Vendor’s key test processes including:

• Defect Management Process

• Test Metrics Reporting Process

• Software Release Process

• Requirements Management Process

• Test Case Development Process

• Test Execution Process

In performing these reviews, railroad experts utilized a variety of testing best practice sources to serve as testing standards and to assist with the audit verification process. The railroad team witnessed testing, inspected documentation, and read and reviewed requirements and design documentation. Several tollgate reviews were utilized to assess progress and recommend improvements where applicable. This information may be available from the performing railroads, who have not distributed the actual documents to the public.

Throughout the development and design processes, requirements and interface control analyses and reviews were conducted by Metrolink and Vendor personnel. Data items were reviewed across the interoperable specification space to assure correctness, completeness, accuracy, readability, testability, and quality.

A critical design review for the Locomotive and Back Office Segments was held in July of 2011, and a similar review was subsequently held with the FRA in October 2011. The goals of the CDR were to review the designs for the Locomotive and Back Office Segments and to ensure the designs met specified requirements for performance and safety. Metrolink was able to identify and discuss open issues concerning the design, as well as, note any potential issues that were recognized through the review process. The CDR was based upon the current specifications and referenced interoperable ICDs at the time of the review. The CDR with the FRA allowed the Agency to gain a more in depth understanding of the design of the system and certain safety related requirements and processes.

The CDR reviewed:

• The I-ETMS development process



• The design for safety

• The locomotive hardware and software

• The back office server and software

• The back office and locomotive interaction

• I-ETMS system testing

The CDR review began in 2011 and evolved to a final revision in 2013. Many of the ITC documents were in draft form in 2011 and the interoperable I-ETMS system installed by Metrolink has evolved along with the industry specifications and will continue to do so. There is no gap between the I-ETMS system installed by Metrolink and the system being installed throughout the industry. A case in point is the PTC data model. When SCRRA began creating the subdiv files, it was per data model Revision P. When the CDR was finalized, Revision R was current. The system is currently operating under Revision S, with a plan in place to convert to Revision T, following the industry adoption of updated information per the process developed by the ITC.

Metrolink’s testing of the I-ETMS system began before the first guidance from ITC was produced for the development of a strategy for testing. However, Metrolink worked closely with BNSF in the development of its test plans. The Positive Train Control I-ETMS Master Test Strategy (MTS) can be found in Appendix H of this PTCSP, along with the Safety verification plans. The MTS was developed to provide a methodology for testing the system. It is an industry guidance document that provides a common language applied to testing I-ETMS, as well as, a framework for completing the multiple layers of testing and the expected success criteria of the test levels. The MTS:

• Provides a methodology to iteratively integrate and test the components and segments of I-ETMS from the lab to the field environment.

• Defines a strategy that may be implemented by railroads deploying I-ETMS to verify the PTC system.

• Provides guidance for the managerial and technical effort necessary to support the test program.

• Defines the level of testing deemed necessary to achieve the I-ETMS program goals and objectives.

• Requires a level of traceability from requirement to test case to result.

• Identifies the primary personnel, equipment, and facility resources required to support the test program.



• Describes a high level defect management process and the requisite categories for managing defects.

The purpose of the testing effort was to validate and verify I-ETMS, as defined in the I-ETMS PTC Development Plan, in both a laboratory and a field environment to assure I-ETMS will achieve and maintain an acceptable level of safety. Testing was performed not only to confirm that the system will perform in the desired manner, but also to verify that it will not permit unsafe conditions. The testing process involved data collection, performance evaluation, and component or system refinement and was broken into several defined steps that required different inputs and outputs. Each of the testing levels is further described in the following sections.

Metrolink did full system performance testing and qualification testing in both lab and field for all of the functionality employed on Metrolink. Metrolink did not test features such as energy management and I-ETMS operation in non-signaled territory which are not applicable on Metrolink.

13.4 Testing I-ETMS Unit/Component Testing 13.4.1

Unit/Component testing is the white box testing of individual PTC components that demonstrates the software executable is operating independently as designed and expected. This was the initial testing performed within the PTC component to demonstrate that the internal units are working as the developer intended and are inherently development team activities. See Section 4.2.4 of the Platform Analysis in Appendix G.8 for additional details.

Laboratory Segment Testing 13.4.2

Subsystem testing, as defined in the MTS as “Segment Testing,” is a testing level that exercised the four segments of the I-ETMS system. Initial unit tests flowed to integration tests, which grew to segment tests. Segment testing was conducted in a controlled laboratory environment. Safety testing of the segments was conducted on the Office, Wayside, and Locomotive Segments. The System Safety Segment Verification process is depicted in Figure 13-2.



Figure 13-2 System Safety Segment Verification Process

Comprehensive Segment test procedures were run following development to check the software code, and then modified during the correction of defects detected as a result of the Vendor(s) or Metrolink testing. Tests were arranged such that system functions were grouped into execution sequences and were designed to include both positive and failure conditions. All tests were performed with simulated external interfaces to control the environment and allow failure cases to be tested safely.

The communications segment was tested during system wide testing. System-wide testing CDRL’s 16-027b-001 though -005, one document for each subdivision, were completed and currently reside with SCRRA and are available on request.

Segment testing was subject to software quality review that involved a Metrolink system test reviewer, who verified that a released version of requirements could be traced to the appropriate test case, test script, and test results and that the results met the defined success criteria. This was part of the Requirements Traceability Matrix which was created and maintained by the V/I contractor (Parsons) throughout the development process of Metrolink PTC.



Segment testing verified that all the segment level requirements for each level of the system were met. SCRRA conducted ITCM, WSRS and Slot-10 test procedures for segment testing and Metrolink’s FRA test reviewer attended one or more of these tests. These test procedures and test results were submitted by the V/I contractor and were approved by SCRRA.

The Communication Segment was also tested by the Vendor to ensure reliability, availability, and performance, but as with the Dispatch system, the Communication Segment was designed to include no safety-critical requirements. The Vendors fully tested the segment contribution by exercising the system requirements, and assessing failure conditions, performance, and security as applicable. This testing was substantially completed outside of the PTC system development by an earlier SCRRA contract for communications work. Metrolink then exercised some set of those Segment tests to verify and validate the product during PTC testing. The Communication Segment testing was performed jointly with Metrolink, BNSF and UPRR testers and equipment. The Segment tests demonstrated conformance with the system requirements.

Communication testing was done as part of the PTC contract requirements, whether the communications elements were installed under the PTC contract or another contract. These results reside with SCRRA and are available on request.

As shown in Figure 13-2, the specific safety verification of the I-ETMS system was performed in parallel with the segment testing, by performing safety-critical test procedures under specific scrutiny of the project leadership and with negative testing included in the process.

Laboratory Component Integration Testing 13.4.3

The second level of testing phases was Laboratory Component Integration Testing. The MTS defines iterative levels of lab testing, adding components to the test layers until the entire system is assembled in the lab environment to verify the compliance of the system functionality and design to the specifications. Laboratory Integration testing is conducted to verify that each segment integrates successfully with the other segments according to requirements and supports the business processes. Metrolink is confident that at the conclusion of field integration testing that every I-ETMS requirement has been tested and the system should function as it is intended in all aspects. Laboratory Integration Testing was a predecessor to Field Integration Testing.

Integration test cases were developed utilizing the resources of vendor use cases, segment specifications, selective ETMS performance test cases, vendor segment tests, and the Railroad’s segment subject matter experts. Each railroad was required to create its railroad specific tests which reflect the I-ETMS configuration of CAD, other Back Office Systems, BOS, Onboard, Messaging and Wayside integration it has deployed.



Each railroad is responsible for determining test cycle content, execution sequences and scheduling based upon its resources and capabilities. It was the responsibility of the Metrolink PTC test team, IT personnel, business Subject Matter Experts, and Vendor test team personnel to establish the required test pre-conditions to ensure that test data necessary to satisfy the conditions of the test cases were available for all testing efforts prior to the start of each test cycle. This integration test case development effort was later leveraged to develop the test cases for field testing, also described herein in Section 13.

Defects for laboratory integration testing were managed by Metrolink in a coordinated fashion throughout the testing effort. In other words, when Metrolink reported a defect in any component of the I-ETMS system, all other ITC participating railroads were made aware of the defect via a shared ITC web portal. However, each railroad was responsible for identifying, publicizing and managing its own defects. As defects were identified and corrected, the Metrolink test team determined which tests needed to be executed again to verify that the defect was corrected. Traceability of test cases to requirements validated these assumptions.

Laboratory testing includes the informal levels Laboratory Integration Nearest Neighbor (LINN) and Laboratory Integration End to End (LIEE) Tests. References to Lab Test Plans and Lab Test Results are included in Appendix I and Appendix J of this PTCSP. LINN testing is the testing of two or more segments which are adjacent to each other. L INN test verified that pairs of segments function together successfully.

Laboratory Integration End to End (LIEE) testing assessed the system in an end-to-end mode. LIEE testing is the highest level of testing of the entire system in the laboratory environment. LIEE testing verified each segment integrated successfully with the other segments as a complete system. For instance, a test was required for verifying the enforcement of an Activation Failure Crossing Tag. This test required the Back Office segment to transmit the Crossing Tag to the Communication segment, the Communication System to communicate the Crossing Tag to the Locomotive segment, and the Locomotive segment to correctly enforce the 0 MPH speed restriction.

LIEE tests the entire system for performance in the laboratory environment. The objective is to verify that the system functions as a whole as described in the requirement specifications and the business processes perform in accordance with use case specifications. More specifically, LIEE was the final validation of the safety requirements of I-ETMS in the laboratory prior to taking the system to the actual operating environment.

LIEE testing focused on the design, development, and execution of the business scenarios critical to the success of the operational aspects of Metrolink. LIEE iteratively progressed as development completed with each segment.

LIEE also included specific tests designed to exercise the requirement for interoperability; that is, “the ability of a controlling locomotive to communicate with and



respond to the PTC railroad’s positive train control system, including uninterrupted movements over property boundaries”.

Throughout the testing phases, Metrolink utilized various test tools developed by the industry, COTS tools, and tools developed by the vendor community to assess components of the I-ETMS system. Some tools simulate and monitor messaging, while others measure compliance with requirements, while others still monitor performance and throughput of the system. The test tools are primarily software based. The tools are not calibrated instruments and are thus not used for measuring. Formal testing was done with the actual TMC, either on a train where it allows a brake application as necessary, or on the hy-rail test vehicle where critical features and WIU statuses were verified.

Laboratory tests were saved within the PTC project records, unlike the Metrolink formal field qualification tests which have been uploaded to the FRA SIR site.

Laboratory Track Database Testing 13.4.4

Laboratory Track Database Testing provided an initial check on a track database. Testers ran all possible routes through the subdivision to ensure track continuity and a preliminary check on grades, curvature, and speed restrictions prior to Field Track Database & Wayside Input / Output V&V. Testing was performed in the lab environment using a real TMC, a simulated GPS, and simulated waysides.

Field Track Database & Wayside Input / Output Validation and 13.4.5Verification

In preparation of the release of a Track Database version, field-testing was performed to validate that database. Several verifications were performed during this V&V activity:

• Verify the position of critical features against their actual physical locations. The critical features are those elements throughout the PTC territory that are all integer mileposts, all station signs used as designated limits, all signals, all switches, all highway-rail grade crossings (each edge of crossing on each track), all permanent speed restrictions (the begin and end limits in the form of signage), all track detection circuits (in dark territory – the begin and end limits), all clearance points for every switch location installed on the Main and Siding tracks, and any inside switches equipped with switch circuit controllers throughout the PTC pilot territory. Critical features include:

o Integer Mileposts

o Signals

o Highway and Pedestrian Crossings

o Switches



o Permanent Speed Restrictions

o Clearance Points

• Verify the navigation through all routes on the subdivision, including Main tracks and Sidings. During this verification, the track names (Main, Main 1, Main 2, Siding, etc.) and speeds were verified as correct.

• At each location equipped with a WIU, all PTC code outputs were verified to the track database.

The difference in the actual position of each of the critical features and the onboard I-ETMS database indicated positions of the same feature do not exceed the mean 95% 2-D All in View 2003 CY GPS Circular Error of Probability distance of approximately 2.2 meters5 (7.2 feet). Successful conformance with this criteria is captured in Test Reports that are maintained in the PTC Project Files.

Details on Metrolink methods for the collection and validation standards can be found in Appendix I of this PTCSP.

Track Database Attribute Testing 13.4.6

Lab track database attribute testing is performed to ensure that track database attributes are set correctly in the track database for the functionality of the PTC system. This testing covers the following for each subdivision:

• Track Line

• Pass Signal Displaying Stop functionality

• Enter Main Track functionality

• Tons per Operative Brake (TOB) Speeds

• Subdivision Linkages and Transitions to PTC Entry

• Device Status Table

Details on Metrolink’s methods for track database attribute testing can be found in Appendix JJ of this PTCSP.

5 2.2 meters = 7.21784777 feet



Field Testing of I-ETMS 13.4.7

Field-testing consists of all tests conducted on rail and includes I-ETMS equipped hy-rail vehicles and locomotives. Upon successful laboratory tests, the system was moved to the actual operating environment on Metrolink I-ETMS pilot test territories. In field-testing, I-ETMS interacted with railroad infrastructure which was, to some extent, not as controlled and predictable as in the laboratory environment. Tests were run to include randomness and variability in test locations, times, and conditions.

Field testing was performed in the physical environment and was affected by actual network timing, so any latencies or coverage gaps in the communications network were exposed. The path from wayside to locomotive varied intentionally based on “best path”. Various paths were disrupted to force the use of alternate paths for test purposes.

The sequence of the field tests and the location where tests were conducted sometimes differed from those used for lab testing and were determined by rail traffic constraints, such as conflicting freight moves or maintenance activities. However, the preconditions for conducting the tests and the test steps, as listed in the individual Test Case(s) were met for all cases and recorded in the Test Reports.

Field tests were conducted in a manner such that the safety of employees, contractors, trains, and the general public was provided for during the execution of each test and precautions were used to mitigate or eliminate the potential for unsafe conditions and/or violations of operating practices or rules. Details of the safety measures taken can be found in the Informational Filing and Testing Waivers [24].

Field tests were divided into four levels of test:

• Field Integration Test (FIT)

• Field Integration Test- Interoperable (FIT-I)

• Field Qualification Test (FQT)

• Field Qualification Test - Interoperable (FQT-I)

These four levels of field testing are described in Table 13-1.



Table 13-1 Field Testing Levels

Test Level Description Field Integration Test (FIT)

FIT is a phase of field testing utilized for informal testing of components or segments of I-ETMS. FIT does not interrupt current train operations. It may include but is not limited to such tests as: Communications Segment field coverage testing, testing the departure test function on a locomotive in a closed track environment, testing the wayside to TMC messaging utilizing a hy-rail, etc.

Field Integration Test – Interoperable

Interoperable testing is the V&V of I-ETMS in a field environment configured to manage a mixture of locomotives, office, wayside, and communications equipment from multiple railroads. FIT-I tests may include but is not limited to such tests as: Wayside Status Relay Service interoperability, one road’s locomotive communicating to another road’s back office, and PTC radio mobility utilizing two roads’ base stations, etc.)

Field Qualification Test (FQT)

Field Qualification Tests began after the Railroad met the requirements of §236.1035 and the related test waiver conditions imposed by the FRA. FQT is the formal testing of the I-ETMS system outside of the laboratory environment, in a field environment with the expressed intent of gaining FRA System Certification. FQT tests were conducted with well-documented and approved test cases, and with FRA participation, as FRA determined necessary.

Field Qualification Test – Interoperable

The testing of I-ETMS interoperability using formal, structured tests of train operations involving multiple railroads.

Test plans and test reports were prepared to ensure the requirements were addressed comprehensively. All documents were reviewed and checked within the PTC project team and provided to FRA prior to and subsequent to testing as appropriate.

The Railroad’s results from Field Qualification Testing can be found in sample Test Reports found in Appendix N of this PTCSP. Prior to completion of FQT on all subdivisions, Metrolink requested approval from FRA to enter the Revenue Service Demonstration phase.

Revenue Service Demonstration 13.4.8

After the successful completion and signoff of Field Qualification Testing and upon receipt of FRA’s approval, Metrolink initiated Revenue Service Demonstration (RSD) runs. RSD runs consisted of revenue service trains with I-ETMS active and enforcing. Details on entry criteria, exit criteria, and the number of runs required during RSD can be found in the Test Waiver (on file at FRA) and in Metrolink’s FRA docket (FRA-2010-



0048) and in the SCRRA Revenue Service Demonstration Application and FRA Approvals in the Docket as noted, as well as the RSD reporting provided to FRA and uploaded to the FRA SIR site. To date, over 20,000 runs under RSD and ERSD have been accomplished, on all of the subdivisions of Metrolink. It is SCRRA’s expectation that ERSD will continue until PTC certification. Anomalies are examined and corrective measures taken as warranted.

13.5 PTC System and Segment Verification Results

The process of V&V activities yielded the following results:

• Traceability links between all relevant design and safety program documents. This includes linking of identified hazards to their specific mitigation at each level of the requirements, design, operational instructions/warnings, and test documentation.

This traceability link information is found in the I-ETMS System Safety Integration Document (SSID.) in Appendix GG. The purpose of this “System Safety Integration Document (SSID)” is to demonstrate that safety has been implemented into the design of the function and the defined requirements correctly implement the I-ETMS® design. The I-ETMS functionality as identified in Section 5.2 of the “I-ETMS PTC Development Plan (PTCDP)” located in Appendix B of this PTCSP has been segmented into the individual sections of this document. Each section provides a functional description including content to demonstrate that safety has been designed into the functional behavior of the system under normal and failure conditions as prescribed by Appendix C of 49CFR 236.

• Complete traceability across all levels of requirements and down through ITC Standard Test Cases. Traceability to SCRRA specific test cases are identified in FIT/FQT test procedures and results in Appendices M and N of this PTCSP. This level of traceability ensures that all requirements are linked together, tested, and traceable back to the requirements of the FRA Final Rule. This traceability is defined in Figure 13-3. Most traceability references are provided both upward and downward as appropriate to the referenced documents.



Figure 13-3 Traceability Diagram

PTC Top Level Requirements & Objectives

Level - 0

Requirements & Objectives

forWayside

Requirements & Objectives for

Radio


Communication


forWayside


Application

Level 0

Level 1

Level 2

Testing

49 CFR 236 Subpart I


Messaging System

Last modified - February 21, 2012

PTC Requirement Tracing Hierarchy


Systems Management

120120 – Tracing Hierarchy PTC.vsd

ITC


forWMS


forLMS


forLDARS


forBack Office


forI-ETMS

End-to-End Test CasesAcronyms

LDARS – Locomotive Data Acquisition & Recording System

LMS – Locomotive Messaging Server

WMS – Wayside Messaging Server

Segment & Nearest

Neighbor Test Cases

• Description of the safety V&V methodologies employed

This description is located in the Safety Assurance Concepts document and the System Safety Program Plan.

• Identification of standards, processes, and other reference documentation (e.g. design documents).

This information can be found in the System Safety Program Plan and the Master Test Strategy.

• Testing methodology, procedures, and test results

Metrolink’s test plan, test procedures, and test results are the documents of record for this information. See Appendix H, Appendix I, and Appendix J of this PTCSP.

Metrolink will make its test procedures and test result artifacts available upon request.



• Description of the specific safety requirement(s) examined in each V&V activity

This description is found in the Safety Requirements Document.

• Cross references to previous hazard analyses, the hazard log, hazard resolution actions, evidence that hazards were resolved (controlled, mitigated or eliminated), and the safety V&V activity that demonstrated compliance with safety requirements.

13.6 PTC System Reliability

Metrolink’s Vendor/Integrator (Parsons) provided a Reliability, Availability, and Maintainability (RAM) assessment of the Metrolink PTC equipment. Refer to the detailed system reliability results addressed in Appendix FF of this PTCSP.

13.7 Interoperability Testing

The term "interoperability" means the ability to control locomotives of the host railroad and tenant railroad to communicate with and respond to the positive train control system, including uninterrupted movements over property boundaries.

From a railroad operating perspective, “interoperability” can also be used as the method to cover any scenario in which the locomotive, railroad control system, and/or train crew are not “employed” by the same entity. Permutations of interoperability scenarios may thus exist in three dimensions.

Because of the I-ETMS architecture, design, and operation, functions that support interoperability are fully and effectively exercised during the testing described above, few, if any, separate tests are required solely to cover the permutations of interoperability. However, Metrolink conducted some specific functionality tests at property boundaries to ensure the robustness of supporting communications and non-PTC back office systems.

Metrolink has shown interoperability through FRA-Sanctioned testing with UPRR and BNSF as both tenant and host through the boundary test procedures with successful results. The Boundary test procedures validated that the On-board application is able to seamlessly handle train movement at the boundary of two adjacent subdivisions which are controlled by two different Railroads and Dispatchers. The V/I contractor submitted both these test procedures and results to SCRRA, and they were approved as executed. Interoperability test procedures and test results have been provided to FRA and are on the SIR site. These documents are also available from Metrolink upon request and addressed in Appendices M and N of this PTCSP.

Metrolink has also successfully conducted interoperability tests of I-ETMS at subdivision boundaries with tenant railroads BNSF and UPRR. As the testing of the interoperability of the PTC system is, by definition, a collaborative process involving two or more railroads, this portion of the testing was conducted as a joint effort with the adjacent



railroad. Metrolink was the host railroad for all tests where the test runs originate on a Metrolink subdivision and the train movement is toward a target that is located on an adjacent railroads subdivision. Metrolink was the host for tests utilizing both Metrolink I-ETMS equipped trains and for tests utilizing other railroad I-ETMS equipped trains.

Likewise, Metrolink collaborated with its adjacent host railroads in conducting their own interoperability tests by providing I-ETMS equipped trains where Metrolink trains operated on the BNSF or UPRR and movement was toward a target located on Metrolink as the tenant railroad. The host railroad is responsible for submitting the Test Plans and making arrangements for tests on its own property.

The Test Plans for interoperability testing included the following information on a form to be determined between Metrolink and its tenant/host railroads, being BNSF, UPRR, Amtrak, and NCTD:

• List of Test Observers

o Date, Name, Title, Organization

• Software Test Matrix

o Date, CDU, TMC, and Track Database version used

Each test case included the following information:

• Test Case #, Title, and Purpose

• Key test participants or observers

o Participants involved in the execution of the tests

• Preconditions

o Items/Process necessary to be in place prior to beginning the test execution

• Success Guarantees

o Expected outcome of the test case

• Setup

o Any other instructions or guidelines deemed necessary to assist in the execution of the test case

• Absolute Block Requirements

o Protection provided to the test train while the test is being performed.



The Test Report was signed by representatives of each of the participating railroads.



14 Metrolink Training Plan [§236.1015(d)(6)] [§236.1041] [§236.1043] [§236.1045] [§236.1047(a),(b) & (d)] [§236.1049]

This section of the PTCSP provides a complete description of the Metrolink’s training plan for railroad and contractor employees, and supervisors necessary to ensure safe and proper installation, implementation, operation, maintenance, repair, inspection, testing, and modification of I-ETMS as required by 49CFR §236.1015(d)(6), 49CFR, Subpart I, § 236.1041, 49CFR, Subpart I, § 236.1043, 49CFR, Subpart I, § 236.1045, 49CFR §236.1047(a), (b), & (d), and 49CFR, Subpart I § 236.1049.

14.1 Training and Qualification Program

Metrolink established and implemented training and qualification programs for all railroad and contractor employees who install, implement, operate, maintain, repair, inspect, test or modify I-ETMS, and their direct supervisors. The programs have been customized for the individual personnel groups based on their roles and responsibilities and comply with 49CFR §236.1041-1049. A description of the training plan is included in Appendix K of this PTCSP.

Familiarization refers to providing an overview of the entire PTC system so that each craft understands what part its specialty plays in the overall operation of PTC. Tools are craft specific. Other than relevant software, there are no PTC specific tools. Mechanical department employees use tools for wiring and piping and laptops for downloading logs as needed. Communications employees use wiring tools, spectrum analyzers, laptops for downloading logs, and the other normal tools of their craft.

14.2 Office Control Personnel Training

The training for office control personnel was required for railroad employees responsible for issuing or communicating mandatory directives in PTC territory, and their supervisors. The training provided direction concerning HMI for dispatching and I-ETMS as they relate to the safe operation of the movement of trains. The training program complies with 49CFR §236.1045. A summary of the training material for the office control personnel is listed in Appendix K of this PTCSP.

14.3 Train Dispatcher Training

This training includes familiarization with the PTC system and the effect of the computer-aided train dispatch on the PTC system. It also includes familiarization with processes used to mitigate exceptions experienced with the system. Training material is addressed in Appendix K of this PTCSP.



14.4 Locomotive Engineer Personnel Training

The training for locomotive engineers and other operating personnel was required for locomotive engineers and any other railroad employee who participates in the operation of a train in I-ETMS territory, and their supervisors. The training provided familiarization with the on-board equipment as well as other operational aspects relating to the safe operation of the train. The training program complies with 49CFR §236.1047.

Metrolink trains are operated under contract by Amtrak personnel, who are trained by Amtrak trainers and road foremen. Using a train the trainer approach, the Amtrak trainers and road foremen completed PTC training both on the on-board system, as detailed in Section 2.2 of the Project Training Plan, and the train simulator, detailed in section 2.5 of the Project Training Plan in Appendix K of this PTCSP. Amtrak trainers and road foremen have been trained, using I-ETMS On Board training materials, developed by Wabtec, and presented by Metrolink/Parsons/Wabtec training staff as appropriate. This training started in the classroom and concluded with training on the PTC equipment using actual PTC-equipped cab cars and locomotives. The Amtrak trainers and road foremen were also trained on the use of the Corys Train Simulator, which includes PTC system functions. Metrolink reviewed the curriculum and audited training classes and found them to be acceptable. Metrolink compliance and PTC staff have also observed and continue to observe Amtrak Crews interacting with PTC on a periodic basis, and the personnel “learning curve” issues have been considerably reduced as demonstrated by the current ERSD results. Training sessions generally included testing. First line supervisors are continually responsible for ensuring the training has been effective and to identify any needs for remedial training for personnel. The Amtrak trainers and road foremen, as trained trainers, then conducted the following training of the individual Amtrak engineers: 1. Classroom portion, using the Wabtec I-ETMS Onboard Training Materials. 2. Simulator portion, using the Corys Train Simulator, which includes PTC functions. 3. Hands-on portion, using PTC-equipped cab cars and locomotives. Train Engineers are provided with a PTC I-ETMS Quick Reference Guide, to be kept with their required paperwork, that explains the basic functions and controls for the PTC system. This supplements the formal training provided to the Engineers. A copy of the Engineer’s I-ETMS Quick Reference Guide is included with the other training materials listed in Appendix K of this PTCSP.

14.5 Office Personnel Training This training included familiarization with the systems that are used to manage and maintain the PTC system. It also included the tools used to manage and troubleshoot the system components and familiarization with the processes used to mitigate



exceptions experienced with the system. This training also included the standards and processes for track database testing and validation in the lab and in the field. Training materials are addressed in Appendix K of this PTCSP.

14.6 Signal Personnel Training This training included familiarization with the systems that are used to maintain the PTC system. It also included the tools, procedures, and guidelines used to maintain and troubleshoot the Wayside Segment system components and familiarization with the processes used to mitigate exceptions experienced with the system. Training materials are addressed in Appendix K of this PTCSP.

14.7 Telecommunications Personnel Training This training included familiarization with the systems that are used to maintain the PTC system. It also included the tools, procedures, and guidelines used to maintain and troubleshoot the Communication Segment system components and familiarization with the processes used to mitigate exceptions experienced with the system. Training materials are addressed in Appendix K of this PTCSP.

14.8 Mechanical Personnel Training This training included familiarization with the systems that are used to maintain the PTC system. It also included the tools, procedures, and guidelines used to maintain and troubleshoot the Locomotive Segment system components and familiarization with the processes used to mitigate exceptions experienced with the system. Training materials and specific training instructions are addressed in Appendix K of this PTCSP.

14.9 First Line Supervisor Training This training included familiarization with the systems that are used to maintain the PTC system. It also included the tools, procedures, and guidelines used to maintain and troubleshoot system components and familiarization with the processes used to mitigate exceptions experienced with the system. Front Line Supervisors attended the same training and accomplished the same qualification requirements as the personnel over whom they have supervisory responsibilities. Training materials are listed in each craft’s training section as shown in the previous sections.

14.10 MOW/Roadway Worker Personnel Training

The training for Maintenance of Way / roadway workers was required for railroad and contract employees who provide protection for themselves or roadway work groups, and their supervisors. The training provided familiarization with I-ETMS, wayside equipment, and an understanding of the protections provided to roadway worker personnel. The training program complies with 49CFR §236.1049. Understanding the critical features and the need to ensure that any changes to the PTC database must be coordinated is the key element of the training. Detailed and very accurate Track Charts were developed which clearly and easily display in a graphic format the location of critical features on all of Metrolink’s host territories. Training materials are listed in Appendix K of this PTCSP.



14.11 Use of Locomotive Simulator in Training The training program for operating crew members included use of a locomotive cab simulator. Descriptions of use of the train cab simulator in the training program are addressed in Appendix K. As new features are introduced to the PTC system, the training simulator will be upgraded coincidental with changes in software on I-ETMS inclusive of functionality and infrastructure modifications. This assures that training using the simulator reflects the current operating state of the PTC system as well as other operating rules and procedures.

14.12 Operating Rules for PTC Books of Rules 14.12.1

The following Rule Books and related documents are to be in possession of all railroad workers, including the Engineer of a Metrolink train, roadway or maintenance worker, or dispatcher as appropriate. “Maintenance Worker” covers all related maintenance crafts: signal, Mechanical, track, structures, etc.

• Amtrak Air Brake and Train Handling Rules and Instructions 1/10/11 • SCRRA On Track Safety Manual • Bombardier Mechanical Department Safety Rules 2006 • SCRRA Maintenance of Way Safety Instructions 2/9/04 • SCRRA Bridge Worker Safety Instructions 2/9/04 • SCRRA Maintenance-of-Way Operating Rules and Instructions 1/1/10 • SCRRA Train Dispatcher’s Manual • SCRRA Positive Train Control Supplemental Instructions for Train

Dispatchers Manual • Metrolink Timetable, current version, plus any general orders • Metrolink Track Charts, current version

PTC Operating Instructions and Crew Record-Keeping 14.12.2The following are the operating instructions for trains equipped with PTC operated by Metrolink. These instructions are provided to train Engineers and related personnel, and were originally provided under GO # 9 dated 11/3/14 and since incorporated in Metrolink System Timetable # 10 dated 10/11/15. The current Timetable and all associated General Orders are available from Metrolink upon request. Training/Qualification All train crews operating where PTC is in effect have been provided classroom training on the system by a qualified instructor, and was also provided with a qualified PTC engineer pilot while operating a locomotive equipped with PTC during their qualification period. Training will continue for new employees and refresher courses will be provided as necessary. Job Safety Briefing



PTC qualified train crews are required to conduct a job safety briefing at the beginning of each tour of duty regarding their PTC equipment and at any time PTC is initialized, re-initialized or cut out enroute. The job safety briefing will include, but is not limited to, the following:

• Verify PTC Status. • Verify the PTC and MCC circuit breakers are in the ON position when the

controlling locomotive is PTC equipped and your train is operating where PTC is in effect.

• Verify that PTC safety devices have not been cut out. (Crew members must not cut out, tamper with, or defeat a safety device without permission from the proper authority).

• Review PTC requirements and functionality. • Crew members need to understand each other's knowledge and experience

with the PTC System. Initializing PTC Prior to initializing PTC a crew member must:

• Verify with the train dispatcher that the lead locomotive is the identifying locomotive.

• Verify that the PTC and MCC circuit breakers are in the ON position.

• Select the "INIT" button to INITIALIZE the system when the PTC screen is illuminated. (Prompts will display advising of the progress of the initialization.)

If initialization fails, the crew must contact train dispatcher and be governed by his/her instructions. After successfully initializing, the crew must confirm that the most current information regarding the train's consist is displayed by the PTC system. Verify the following:

• Total number of locomotives in the consist; • Total number of loaded and empty cars in the train; • Train's trailing tonnage and total length; • Total braking force (ensure value is not zero) and operative brake count; • Lowest of any speed restriction imposed on equipment in the train; and • Form A and B restrictions.

If initialization fails or confirmation that any of the above information is not correct, inform the train dispatcher and be governed by his/her instructions. Enroute Train Consist Changes



After setting out or picking up cars or locomotives, the dispatcher must be notified and the trains consist updated for proper PTC operation. Verify the following:

• Total number of locomotives in the consist; • Total number of loaded and empty cars in the train; • Train's trailing tonnage and total length; • Total braking force (ensure value is not zero) and operative brake count; • Lowest of any speed restriction imposed on equipment in the train; and • Form A and B restrictions.

If confirmation that any of the above information is not correct, the engineer is required to inform the train dispatcher and be governed by his/her instructions. Train Dispatcher Notification The engineer must report the following conditions and occurrences to the train dispatcher:

• Any time PTC indicates train braking in progress; • The train is stopped due to a PTC warning, or; • PTC is suspected of not providing a warning when it should have.

When making a report to the train dispatcher, include the following information:

• Locomotive initials/number; • Time and location of occurrence, and; • Any unusual occurrence, which may have attributed to the problem.

Information provided in the verbal report to the Train Dispatcher must also be submitted on the PTC Event Report, which is Figure 14-1.

Figure 14-1 PTC EVENT REPORT FORM

(See next page)



PTC EVENT REPORT DATE _________ TRAIN ________________ ORIGIN __________ DESTINATION ____________ OPERATING LOCOMOTIVE/CAB CAR ______ LOADS ____ EMPTIES ____ TONS ____ LENGTH ____ EXCEPTIONS OR UNUSUAL EVENTS: EVENT #1: TIME ____ SUBDIV _____________ MILEPOST ______ DIRECTION _______ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ EVENT #2: TIME ____ SUBDIV _____________ MILEPOST ______ DIRECTION _______ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ EVENT #3: TIME ____ SUBDIV _____________ MILEPOST _____ DIRECTION ________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ Engineer Name ___________________________________ Signature ________________________________________



General Order in Effect 14.12.3When PTC was implemented in general revenue service demonstration on Metrolink, the following General Order defined the methods of operation that were in effect. This General Order has now been incorporated in the Metrolink Timetable [28].

General Order No. 9 SECTION M. INSTRUCTIONS RELATING TO POSITIVE TRAIN

CONTROL ITEM 1. POSITIVE TRAIN CONTROL IN EFFECT (Added 11/03/14) Positive Train Control (PTC) is in effect for PTC-equipped trains on all main tracks, controlled sidings and tracks where CTC in effect, exclusive of CP Terminal and the sixteen station tracks at Los Angeles. PTC supplements other methods of operation and will display mandatory directives and other instructions that affect the movement of trains. PTC is designed to monitor train movement and stop the train when it becomes apparent that the train will:

• Move into a section of track for which the train does not hold authority, • Move into a section of track under control of an employee in charge without

permission, OR • Exceed the maximum allowable speed.

PTC does not establish authority or restrictions for train movement. Controlling the train, including proper braking, remains the responsibility of the locomotive engineer. The engineer is required to make movements at the appropriate speed to allow the train to be stopped within ½ the range of vision when operating at Restricted Speed. Since most SCRRA cabs have room for only one train Engineer or operator, and SCRRA operates with a one-person crew, only one PTC display screen is provided in SCRRA cabs and cab cars. Therefore, when multiple active crew members are assigned to the control cab, these crew members must be aware of the information provided by the PTC display screen. ITEM 2. OPERATING IN PTC TERRITORY (Added 11/03/14) When taking charge of an engine equipped with PTC in PTC territory or when entering PTC territory, crew must know that the PTC system is enabled and operative and any required departure test has been performed. A departure test is also required if the previous departure test was more than 24 hours in the past. After successful initialization and before departing, the engineer must compare displayed restrictions and authorities on board PTC with the paper copies of Track Bulletins issued to the train. Any discrepancies must be reported to the Train Dispatcher. Train is not to depart until the Train Dispatcher provides instructions.



Refer to Job Aid PTC-1 for Initialization and Departure Test details. . ITEM 3. PTC FAILURES ENROUTE (Added 11/03/14) The PTC system, or any part of the system, must not be disabled in PTC territory unless authorized by the train dispatcher. The dispatcher may authorize PTC to be cut out when the PTC system has experienced a failure or prohibits a movement that should be allowed. Operation of the train post-PTC failure is to be performed in accordance with GCOR rules or FRA 236.1029 as per the regulation in effect at the time. When PTC fails enroute, or any PTC anomaly is experienced, the Train Dispatcher must be notified immediately and a PTC Event Report must be filed upon completion of tour-of-duty. Refer to Job Aid PTC-1 for Instructions pertaining to the PTC Event Report. ITEM 4. CONSISTENCY OF SIGNAL INDICATIONS (Added 11/03/14) When present, signal indications displayed by the PTC system do not supersede indications displayed by the wayside signals or cab signals. If for any reason the PTC display indicates a signal indication different from the wayside signal or cab signal, the most restrictive indication shall govern the movement and the Train Dispatcher must be notified immediately. ITEM 5. CONSISTENCY OF MAXIMUM AUTHORIZED SPEED (Added 11/03/14) The Maximum Authorized Speed displayed by the PTC system does not supersede speed restrictions established by other means – timetable, special instructions, track bulletins, unforeseen track restrictions, etc. If for any reason the PTC display indicates a speed different from that authorized by other means, the most restrictive speed shall govern the movement and the Train Dispatcher must be notified immediately. ITEM 6. BROKEN OR MISSING SEALS (Added 11/03/14) Do not break the seal on PTC devices unless authorized by the train Dispatcher. Report broken or missing seals to the Train Dispatcher immediately.



15 Procedures, Test Equipment, and Operations and Maintenance Manual [§236.1015(d)(7)] [§236.1039 (all)]

This section provides a complete description of the specific procedures and test equipment used to ensure the safe and proper installation, implementation, operation, maintenance, repair, inspection, testing, and modification of the PTC system on Metrolink and establish safety–critical hazards are appropriately mitigated as required by 49CFR §236.1015(d)(7) and 49CFR 236, Appendix C (b)(7). These procedures, including calibration requirements, are consistent with equipment manufacturer’s recommendations.

This section also ensures that documents specified in this PTCSP, operations and maintenance manuals for hardware / software handling, and operations and maintenance manuals for safety-critical components are properly documented and stored as required by 49CFR §236.1039(a), (c), and (d).

15.1 Maintenance Procedures and Process

Metrolink’s PTC maintenance process includes general policies for dealing with railroad (and PTC) maintenance as well as specific procedures that implement the general maintenance policies for particular equipment or scenarios. Metrolink has integrated the PTC process and procedures into its overall structure and does not have a separate approach to PTC service and maintenance documentation.

Operations and maintenance documentation is structured around Metrolink’s organizations (e.g., Mechanical, Engineering and Information Technology) who are responsible for managing Operations and Maintenance Manual (OMM) activities, as well as archiving and configuration management of OMM processes, policies and procedures.

The OMM addressed in Appendix L of this PTCSP, lists the manuals, which include those test procedures and test equipment necessary to preserve safe I-ETMS operation, covering:

• Acceptance and installation testing,

• Preventative and periodic testing required to maintain equipment in safe working order and,

• Testing required following equipment repair or maintenance actions.

Metrolink Policies 15.1.1

Metrolink has integrated new requirements imposed by PTC into its hierarchy of documented requirements including system-wide policies concerning the implementation of PTC at this time. The primary actions have been to establish



operating procedures and reporting procedures for the use of PTC in Metrolink train operation, as described in this PTCSP and in the operating rules and the current Metrolink Timetable [28]. Figure 15-1 illustrates the hierarchy of administrative documents as they exist under external requirements and within internal Metrolink requirements. If additional system level PTC policies are established in the future, they will be provided as part of a PTCSP revision per an RFA submitted to FRA.

Figure 15-1 Hierarchy of Administrative Documents

Metrolink-Specific Procedures 15.1.2

Railroad (SCRRA/Metrolink) policy covers a range of activities which must be performed to fulfill the purpose and intent of the policy. The instructions and standards for executing these activities form the content of the specific procedures. The specific procedures are executed by Metrolink’s work force to guide and govern the inspection, test, or maintenance activities. The procedures for PTC are collected in the following two documents for convenience:

1. Current Metrolink Timetable as part of its section on PTC. Included in reference documents as [28]. This is used primarily for the direction of train crewmembers.

2. The PTC supplement to the Dispatcher’s Manual which is addressed in Appendix L.

Reguations and

Mandates Industry

Standards and Requirements

SCRRA Policies & Procedures

Train Control Operating Standards

Train Control Standard Operating Procedures (Manuals, Plans)

Train Control Administrative Instructions (Detailed instructions for a procedure)



Testing contained in the O&M Manual (OMM) includes periodic testing and any recommended new installation testing, it does not include system qualification testing or software regression testing since the software regression testing is specific to a particular software release and not part of routine operations and maintenance. The OMM covers all inspections, diagnosis, repair, test (of the repair) and restoration of the equipment. Separate developmental documents cover the upgrade of hardware and software and its testing performed on an off-line environment.

Vendor product maintenance manuals also contain maintenance procedures pertaining to their specific PTC products. These manuals are identified in section 15.2.2. Metrolink deviations from the standard vendor procedures are identified within the specific Metrolink procedures as discussed within this section. These manuals are included by reference in the “master” Metrolink OMM and reside in the same physical and virtual location as the OMM. The OMM is subject to Configuration Management and control as defined in Section 17 of this PTCSP.

Controlling and Tracking Documents 15.1.3

All documents identified in this PTCSP for the installation, maintenance, repair, modification, inspection, and testing of the PTC system are properly cataloged and maintained. These documents are contained within one Operations and Maintenance Manual as required by 49CFR 236, Subpart I, §236.1039(a). This includes documentation for the identification and revision information of all hardware, software, and firmware related to the PTC system as identified in 49CFR 236, Subpart I, §236.1039(c), and 49CFR 236, Subpart I, §236.1039(d). The documentation is controlled through Metrolink Configuration Management processes as identified in this PTCSP under Section 17 and Appendix P.

Controlling and Tracking Component/Product Modifications 15.1.4

Metrolink has an established system for control and tracking of all safety-related products and their modifications. This system is described in Section 17 of this PTCSP. The management methods are adequate to fully control all changes to PTC equipment including hardware, software and firmware of the components of the PTC system. The configuration management system ensures all such changes are documented and implemented consistently throughout the set of equipment deployed at Metrolink.

15.2 PTC Operations and Maintenance Manuals

FRA regulation [§236.1039(a)] requires that a “master” Operation & Maintenance Manual (OMM) exist for the PTC system installed by Metrolink. A copy of the current OMM is located at the Metrolink Office at the PTC records room of the Dispatching and Operations Center (DOC). This master manual provides the overall structure and content for operation and maintenance of the PTC system. It also serves as the index or repository for additional vendor-provided services and operational manual documents. These are referenced in the appropriate sections of the manual as being the source of the specific procedures and processes for dealing with PTC component



level operation and maintenance. The content of the O&M Manual is listed in Appendix L of this PTCSP. Individual documents are available from Metrolink upon request.

The PTC O&M Manual addresses the following PTC areas:

• Locomotive Segment

• Wayside Segment

• Communication Segment

• Office Segment

• System Operation – Human Interfaces

For each PTC segment (On-board, Wayside, BackOffice, and Communications) covered in the PTC O&M Manual, the following information is addressed as a minimum:

1. Installation

2. Maintenance

3. Repair

4. Modification

5. Inspection

6. Testing

The PTC O&M Manual also addresses the key components of the PTC system (and their associated software) identified below:

• Locomotive Segment

o PTC onboard computer (TMC)

o PTC Train Crew display (CDU)

o PTC Locomotive interfaces

o PTC 220 MHz Radio

o GPS Receiver

o Communications manager unit

o Cell and Wi-Fi interfaces



o Tachometer(s)

o Power Supplies

• Wayside Segment

o Wayside Interface Unit (WIU)

o PTC 220 MHz radio

o Wayside Message Server (WMS)

o Communications manager unit

o Cell and Wi-Fi interfaces

o Power Supplies

• Communication Segment

o Railroad Backbone or primary communications infrastructure

o Railroad PTC-specific communication equipment and nodes

o Interface to Cellular Carriers as per Metrolink agreements

o Wi-Fi Hotspots

• Office Segment

o Back Office Server

o Application system interface(s)

o Office Communications Controller

o Communications (Backbone) Segment Interface

o Interface to CAD

• System Operation – Human Interfaces

o PTC CDU Operation

o PTC-Specific Dispatcher Commands/Displays (as applicable)

Other Metrolink subsystems that are used with PTC may have their own O&M manuals. These separate manuals include the following products that are used on Metrolink.



• Interlocking controllers

• CAD system

• Locomotive systems

• Railroad-specific application systems

• Integrated wayside detector systems

• Onboard business application systems (e.g., locomotive status, workflow management, event recorder management, etc.)

The manuals for these subsystems are maintained in the Metrolink Office at the PTC records room of the Dispatching and Operations Center (DOC) as per FRA regulation and Metrolink standards and policies. The PTC O&M Manual refers, as needed, to these manuals as documentation for operation and maintenance of the external subsystems. The PTC O&M Manual is a living document that will be maintained throughout the life of the system.

The PTC Operations & Maintenance Manual (O&M), Appendix L of this PTCSP, lists the documents containing the specific procedures and test equipment used to ensure the safe and proper installation, implementation, operation, maintenance, repair, inspection, testing, and modification of the Locomotive, Communications, Back Office, and Wayside segments of I-ETMS. The PTC O&M Manual also identifies requirements for test equipment (as needed) for the maintenance of I-ETMS to ensure safe operation. The test procedure documentation includes specific safety test procedures, test equipment requirements, description of acceptable safety test results, and appropriate repair, replacement, and/or modification actions required when test results are deemed unacceptable. The types of testing activity included are listed below:

• Qualification testing – {for train Engineers}

• Installation testing - designed to demonstrate that the equipment has been installed correctly.

• Daily testing - intended to determine that the equipment is operational. Primarily done by self-testing along with Departure testing

• Periodic testing - to include as needed due to disarrangement, intended to determine that the equipment and its functionality is maintained as intended. This includes the FRA-required 92 day inspection and testing of rail vehicles.

• Repair and Modification testing – designed to demonstrate that the equipment is functioning correctly after repair or modification



Test procedures address the testing frequency necessary to demonstrate that safety requirements are not compromised over time, through use, or after maintenance is performed.

Safety Mitigations Addressed by the O&M Manual Contents 15.2.1

The PTC O&M Manual provides mitigation for several hazards that are documented in the Hazard Log. (See Section 9 of this PTCSP.) The hazards mitigated by the O&M Manual are of two types:

1. Hazards from PTC equipment that has failed or mis-operates due to operational error or maintenance error.

2. Hazards from human errors in performing Operation or Maintenance that cause unsafe PTC operational conditions.

3. Hazards from PTC equipment that fails to be diagnosed as failed and not subjected to removal from service and repair,

In some cases, the human errors are the actual root causes of PTC equipment mis-operations, and such a relationship is disclosed in the Hazard Log.

The cross-referencing to the section of the O&M Manual that is used as hazard mitigation is contained in the Hazard Log. The Hazard Log is found in Appendix D of this PTCSP.

Vendor Product O&M Manuals (Sub-manuals to the PTC system 15.2.2O&M Manual)

The vendor manuals for products (which are also known as PTC components) are critical to the usefulness of the O&M manual for the PTC system in general. The Metrolink PTC O&M Manual contains these vendor manuals which describe all aspects of the life-cycle of the specific product.

15.3 Test Equipment

The test equipment for service, repair and modification of PTC equipment can be classified in two categories: 1) Standard service and test equipment already in place in the railroad’s service facilities and/or in use by railroad maintenance personnel; and 2) special test equipment required to diagnose and service PTC components. This subsection will deal with any specialized PTC test equipment and all other test equipment necessary to ensure the safe and proper installation, implementation, operation, maintenance, repair, inspection, testing and modification of the PTC system on the railroad and establish safety-critical hazards are appropriately mitigated.



The I-ETMS PTC equipment is designed with a substantial amount of self-diagnostics and fault reporting built into the PTC components themselves. This allows many faults to be quickly identified by directly viewing indicators on the physical modules and following the procedures contained in the O&M Manual for actions to be taken for service restoration. Diagnostics and fault reporting may be as simple as a health light, or may be in the form of error codes. For procedures to utilize the self-diagnostic capabilities, refer to the Operation and Maintenance Manuals for the PTC equipment as listed in Appendix L of this PTCSP.

As discussed in the OMM, the lowest replaceable unit or line replaceable unit (LRU) for a product needing test and repair is often the entire component such as a TMC or 220 MHz radio.

In addition, results from self-test and operating statistics kept by components can be downloaded and viewed by servicing personnel using a computer as needed. Each component of the I-ETMS system provides a substantial amount of data which can be used by maintenance personnel to diagnose transient faults or incidents. All maintenance employees who download data or statistics from PTC equipment are provided with a suitable computer for this purpose by SCRRA.

The Test equipment list is contained in the O&M Manual for Metrolink PTC addressed in Appendix T of this PTCSP.



16 Warnings and Warning Labels [§236.1015(d)(8)]

As required by 49CFR §236.1015(d)(8), this section provides a complete description of any additional warning to be placed in the Operations and Maintenance manual in the same manner specified in §236.919 and all warning labels to be placed on equipment as necessary to ensure safety. Warnings are not included in the system level Operation and Maintenance Manual, but are included in many of the vendor equipment manuals, and these manuals are included in the O&M Manual collection in Appendices K and L of this PTCSP.

16.1 Warnings in Manuals

No warnings are embedded in the text of the Manuals for Wabtec products, as a generic safety warning is provided in the front of the documents. Wabtec warnings are in the document contained in Appendix BB of this PTCSP. Other vendors’ Manuals contain safety warnings, cautions and other safety related information throughout the content. These warnings are given in the document in Appendix BB.

16.2 Warning Labels

As required by 49CFR §236.1015(d)(8), this section provides a complete description of any additional warning to be placed in the Operations and Maintenance manual in the same manner specified in §236.919 and all warning labels to be placed on equipment as necessary to ensure safety.

Warnings have been identified that address safety considerations to be taken in the installation, maintenance, testing, modification and repair for Metrolink’s PTC system components as applicable. Warnings include but are not limited to those associated with unauthorized access, electrical shock hazards, improper usage, testing or operation and issues of configuration management of system stored data.

Warnings associated with installation, operation and maintenance of the I-ETMS PTC system implemented are highlighted in the various vendor Operation and Maintenance Manuals, which are included in Appendices K and L of this PTCSP.

Perhaps the most common PTC specific warning label impacting the wayside segment is the label pertaining to WIUs. There are multiple track locations on the railroad where intermediate signals have identical application programs. One troubleshooting practice often employed by technicians, prior to PTC, is to swap modules between units to identify a faulty module. With an integrated WIU, the processor modules have common hardware and application software, however under PTC application they have unique PTC Map files loaded on them which identify them with specific tracks and signals. The warning label shown in Figure 16-1 is applied to the cabinet of each wayside controller in locations where there are two or more identical controllers.

This is the PTC specific Warning Label which is applied on the wayside equipment.



Figure 16-1 Warning Label for PTC WIU

16.3 Warnings in Vendor Manuals

Documentation reflecting warnings, cautions and other safety related information are included within vendor manuals. The warnings are included in Appendix BB of this PTCSP. A listing of the applicable vendor manuals is included in Appendix L of this PTCSP.



17 Configuration Management and Revision Control Measures, Metrolink [§236.1015(d)(9)] [§236.1023(c)(2)]

This section provides a complete description of the configuration and revision control measures designed to ensure that Metrolink or its contractor does not adversely affect the safety-functional requirements and that configuration or revision changes do not compromise any safety-critical hazard mitigation processes as required by 49CFR §236.1015(d)(9) and that such changes can be audited as required by 49CFR §236.1023(c)(2).

17.1 CM Acronyms, Terminologies and Definitions Table 17-1 below describes meaning of the acronyms and terminologies used in the Configuration Management and Revision Control Measures section.

Table 17-1 Acronyms, Terminologies and Definitions

Acronym or Term Definition

CI Configuration Item – Any I-ETMS System artifact including, but not limited to, hardware, software, firmware, document, or an aggregation of hardware, software, firmware and documents that deliver a Service within the I-ETMS System. It is treated as a single entity which needs to be managed and controlled via configuration management.

CM Configuration Management - A collection of processes that are responsible for maintaining and controlling CIs, information about CIs, and their relationships, which are required to deliver I-ETMS System services. This information is continuously managed throughout the lifecycle of CIs.

CMP Configuration Management Plan – A description of CM policies and procedures employed by entities that participate in I-ETMS System production, support and maintenance.

Baseline A recorded state of CIs at a specific point in time that serves as a basis for future builds, changes, and releases. It is formally agreed upon through CM.

I-ETMS Vendor An entity that supplies, manages, or controls I-ETMS System artifacts and is maintained in the PTC Product Vendor List (PTCPVL) specified in section 31 of this PTCSP.

I-ETMS Railroad A railroad who’s PTC Implementation Plan includes the deployment of the I-ETMS system.



Acronym or Term Definition

I-ETMS Industry Committees

A consortium of participating I-ETMS Railroads partnering together to address common or interoperable aspects of the I-ETMS System. The consortium consists of various committees designed to develop and maintain common or interoperable I-ETMS Configuration Items through effective collaboration and communication between multiple I-ETMS Railroads.

Tenant Railroad A railroad which operates trains on Metrolink track upon which a PTC system is required.

Interchange Railroad

A railroad with interchanged train movement with Metrolink and requires specific coordination of Track Data changes at the interchange points as defined in the Track Database.

Development Change

Additions, modifications or removal of anything that could have an effect on the CIs prior to implementation into an operational train control environment.

Deployment Change

Additions, modifications or removal of anything that could have an effect on the CIs maintained in an operational train control environment.

Track Data Change

Additions, modifications or removal of anything that could have an effect on the contents of the Track Data files.

17.2 Industry-Level Configuration Management

The Industry Configuration Management Plan (CMP) is addressed in Appendix O of this PTCSP. This document serves as the industry guidance for the Metrolink/SCRRA Configuration Management Plan that appears in Appendix P of this document. It is not currently a released standard document such as an AAR Specification, and hence is listed as a “draft” document at this time.

17.3 Configuration Management Integration with Industry The Metrolink Common Configuration Management Plan ties together the railroad’s CM Plan with industry and vendor driven configuration plans. The railroad’s CM objectives are to support implementation of PTC changes, while:

a) Not compromising safety b) Maintaining interoperability c) Maintaining reliability

Metrolink’s Configuration Management Process is used to:

• Identify and document the functional and physical characteristics of the PTC configuration items;



• Audit the Configuration items to verify conformance to specification, standards, and contract requirements. This was the function of the Requirements Traceability Matrix maintained by the V/I contractor during the development of the PTC system for Metrolink. Additional audits performed are recorded in Appendix Z of this PTCSP.

• Control changes to configuration items and their related documentation; and

• Record and report information required to manage PTC configuration items including the status of the proposed changes and the implementation status of proposed changes.

SCRRA Railroad Change Management Process

Development Change

Deployment Change

Emergency Change Track Data Change

Supports management of proposed I-ETMS system changes, both Interoperable & Non-Interoperable, which impact the functional or non-functional behavior of the system.

Supports safe and reliable implementation of approved Interoperable Development Changes into an operational train control environment.

Supports safe and reliable implementation of unplanned changes into an operational train control environment, usually in response to a critical anomaly or defect

Supports safe and reliable implementation of changes to Track Data, utilizing the railroads Track Data Verification and Validation processes.

17.4 Track Data and Database Management

The safe and efficient operation of the SCRRA PTC System is dependent upon maintaining an accurate database of the SCRRA territory for use on each locomotive and cab car. This database contains geographic information of the track structure which includes grades, curves, switch points, turnouts, grade crossings (including

Configuration Management Plan Roles and Responsibilities Metrolink Responsibilities

Vendors Tenant Railroads Industry Committees

Audit Vendor Configuration Management Process and programs

Responsible for CM of their own subsystem

Coordinate with Metrolink directly/Industry Committee

Develops and communicates the Interoperable Deployment Plan

Coordinate with other railroads

Coordinate with Metrolink and other railroads

Support CM of Interoperable CI’s



roadway alignment, roadway widths, status of crossing closures), wayside signal locations, mile marker signs, speed change signs and all other physical features of the property. In addition to the physical characteristics of the property, as identified above, the location and status of other features such as speed limits, quiet zone crossings, changes to signal programs, and any changes to railroad operations are required to remain current in the PTC database. Accuracy of the database is a safety critical cornerstone of PTC. The PTC database is a controlled safety critical record which must be maintained and used during construction and testing, as well as throughout the revenue service life of the PTC system. Effective with the release of Timetable # 8, Metrolink required the following: “any proposed changes to physical features or railroad operations must be reported to the Deputy Chief Operating Officer, PTC & Engineering, with a copy to PTC Document Control, a minimum of 25 days prior to the changes taking effect. The Change Notification Form (See Appendix P of this PTCSP) shall be filled in as applicable and transmitted as indicated on the form.”

17.5 Metrolink PTC System Configuration Management

Parsons, as Metrolink’s Vendor/Integrator (V/I), has established a set of procedures and processes for Configuration Management of the PTC program. The project specific application programs and the accumulated databases, as well as the responsibility for their maintenance will pass from Parsons to Metrolink as a part of the current transition process that takes Metrolink from Parsons customer to system owner. This transition will be completed upon system acceptance by Metrolink/SCRRA. As of the current time, all PTC project documents and SCRRA documents are under Configuration Control within the Metrolink/SCRRA organization and are properly revision managed.

The Configuration Management Program has been established to support the PTC project requirements of the SCRRA/Metrolink Positive Train Control Contract and those set forth by the ITC, American Association of Railroads (AAR), and Federal Railroad Administration (FRA) standards and requirements. During the design and development phase, the vendor/suppliers may request to make modifications to their Commercial Off-the-Shelf (COTS) products using their Configuration Management Programs. The Configuration Management Program is applied to the received product baseline version releases from the vendor/suppliers. These product baselines undergo interface, integration and interoperability testing. Upon successful testing completion, the vendor/supplier product baseline collective will become the operation baseline for the PTC system and additional contract provided stand-alone systems.

The CMP established and maintains integrity and control of the system products. Using Configuration Control and the Engineering Change Management Process, the goal of the CMP is to maintain the integrity of the fully operational and interoperable system. While an individual change to a vendor/supplier’s COTS product baseline may be minimal, the impact of the change on testing, documentation, or interfaces must be ascertained to determine the impact to the PTC system or other stand-alone system. The CMP has been established to prevent; 1) non-traceability, 2) the inability to re-create a PTC system or interface test problem, 3) the inability to restore a previous software version, and 4) surface issues than impede software components ability to



interface due to software error inconsistencies found resident upon the vendor/supplier’s product baseline hardware or software.

The following stand-alone systems are maintained under the SCRRA configuration management program:

• Stand-Alone Computer Aided Dispatch System (CAD) Equipment & Software

• CAD Interfaces), Employee in Charge (EIC) Laptop Component, USGS, Client Workstations, Customer Information System (CIS) Server, CAD Database Server)

• Stand-Alone Network Management System (NMS) Equipment & Software

• Stand-Alone Customer Information System (CIS) Equipment & Software

• Stand-Alone Training Simulators (Union Station)

The following baseline version released PTC systems, PTC system components, and stand-alone system interfaces (for testing, configuration control and asset tracking) fall under the SCRRA configuration management for the PTC system project life cycle, and during the service and warranty period(s), but are in the process of being taken over by Metrolink:

• CAD PTC System Interfaces

• NMS PTC System Interfaces

• CIS PTC System Interfaces

• PTC Communication Network Component (CNC) Interfaces (Base Station Radio,

• Cell Phone Equipment, Global Positioning Equipment (GPS) Equipment, Wi-Fi Equipment

• EIC Laptop Component and PTC Interface(s)

• PTC CAD-BOS (Back Office Server) Equipment & Interfaces

• PTC Back Office Server (BOS) Equipment & Interfaces (BOS Database Server)

• PTC Interoperable Train Control Messaging (ITCM) Server, Equipment &

• Interfaces (BOS-ITCM Servers)

• PTC Train Management Computer (TMC) Interfaces

• PTC Wayside Equipment & Interfaces



• PTC OBS Equipment & Interfaces

• PTC Train Simulator Interface Components (Union Station)

The PTC Project Configuration Management Program is based and built upon the PTC product specifications and incorporates the controls and processes to support the latest revision standards issued by the Interoperable ITC standards, Interoperable Electronic Train Management System (I-ETMS®) requirements, and those PTC requirements and standards provided by the AAR and the FRA. Refer to Appendix O: Industry Configuration management Plan, and Appendix P: Configuration Control and Record Retention, for additional information.

17.6 Metrolink Revision Control Measures

The software release notes are the primary configuration control documents used to track and control versions of software for release to the operational environment. The software release notes contain a summary of features and contents of the software build. The software release notes identify and describe the version of the software CI being delivered, including all changes to the software CI since the issuance of a previous version. Every unique release of the software (including the initial product baseline release) shall be described by software release notes. If multiple forms of the software CI are released at approximately the same time (such as at different sites), each must have a unique version control number and a specific build number. The build number are entered into the configuration management tool sets, including the “Technology Stack” which lists current software versions for the PTC system.

The responsibility for the maintenance of any remaining Parsons created Configuration Management databases will pass from Parsons to Metrolink as a part of the transition process that takes Metrolink from Parsons customer to system owner at project closeout.

17.7 Vendor Configuration Management and Revision Control Measures

Subcontractors are required by contract to have Configuration Management Programs in place during development of their products. A complete CMP plan was required as a deliverable from each subcontractor assigned to this contract. Subcontractors have provided evidence of their adherence to the contract specifications and CMP requirements in the form of status accounting reports reflecting the development of their software, hardware, and COTS configuration item data.

The requirements for the subcontractor may be modified to fit the scope and magnitude of the subcontract task. The Project Manager and/or Vendor/Integrator Leads, are, have been, and shall be in continuous communication with the vendor/suppliers quality representatives, and perform periodic audit activities of the vendor/supplier configuration management activities, review of supplied documents, review of the subsequent and superseded change processes, and perform CMP audits.



18 Initial Implementation Testing Procedures [§236.1015(d)(10)]

This section provides a complete description of all initial implementation testing (FIT/FQT) procedures necessary to establish that safety-functional requirements are met and safety-critical hazards are mitigated appropriately as required by 49CFR §236.1015(d)(10). This testing is part of the PTC Certification process as required by the FRA regulation Subpart I. The procedures are available from Metrolink on request.

Implementation testing began on the San Gabriel Subdivision. San Gabriel was SCRRA’s test track and provided a comprehensive example of all operating scenarios on the railroad, including an interface with tenant railroads UPRR, BNSF, and Amtrak. SCRRA performed upgrade, level and downgrade brake tests on the San Gabriel Subdivision at 79mph. The upgrade and downgrade braking tests were conducted on a ruling grade of 1.91%. In addition, SCRRA performed brake tests on the Valley Subdivision and Orange/Olive Subdivision to ensure train and OBC performance consistency at speeds of 74 mph and 90mph on ruling grades of 2.4% and 1.25% respectively. Test procedures used during the initial implementation field testing cover the following operational areas of the I-ETMS system. Test Cases used in Field Testing have been divided into the following functional categories:

• Initialization

• Form B’s

• Enter Track between Block Signals

• Departure Test

• Crossing & Speed Tags

• Braking and Warning Enforcement

• Track Location

• Signals and Switches

• Next Governing Signal

• Cutting In & Cutting Out

• Navigation

• Track and Time

• Summary Consist



• Territory Entrance & Exit

• Communications

• Synchronization

• Diagnostics

• Electronic Authority to Pass Signal Displaying Stop – PSS

• Form A’s

• Horn Sequencing

18.1 SCRRA Informational Filing and Testing Waivers Prior to the Metrolink PTC certification, system level testing was conducted using FRA regulation waivers per Part 236.1035. [24] The SCRRA PTC system has been deployed in “stages”. The stages of deployment are described in the SCRRA PTCIP. The initial stage consisted of equipping the SCRRA San Gabriel Subdivision for PTC and completing the system testing for approval under an FRA Waiver per Part 236.1035 prior to the FRA certification of the PTC system for deployment [30]. The results from this initial segment/stage have been assembled, reviewed, and are referenced in the PTCSP submittal, and SCRRA now delivers this Final PTCSP with a petition for certification of the PTC system to the FRA. While awaiting the FRA certification of the initial PTC system, all other Metrolink territories (Subdivisions) have been subjected to the same waiver and test process used for the San Gabriel Subdivision. This section identifies the test process and the test results that supported SCRRA placing the initial track segment into PTC revenue service. The process continued subdivision by subdivision until the entire railroad territory was equipped and functioning as an integrated PTC system under Revenue Service Demonstration.

18.2 Pre-Certification Field Deployment Metrolink, per its testing waiver, first conducted pre-certification testing on the San Gabriel subdivision. San Gabriel is SCRRA’s test track and provides a comprehensive example of all operating scenarios on the railroad, including an interface with tenant railroads UPRR, BNSF and Amtrak. SCRRA performed brake tests on the San Gabriel Subdivision on a 1.91% ruling grade at 79mph. In addition, SCRRA performed brake tests on the Valley Subdivision and Orange/Olive Subdivision to ensure train and OBC performance consistency at speeds of 75 mph and 90 mph on ruling grades of 2.4% and 1.25% respectively. Brake test train consists were utilized that closely replicated the likely maximum consist length, weight, and locomotive power. This resulted in a consist with 12 passenger cars loaded with sand bags and two locomotives. Testing on



San Gabriel was followed by testing on the remaining SCRRA subdivisions of Ventura, Valley, Orange/Olive, and River. Testing utilized I-ETMS equipped hy-rail, locomotives and SCRRA passenger cars as appropriate for the specific tests. Tests also utilized the SCRRA wayside WIUs, BOS, and other back office systems as appropriate for the specific test requirements. After the successful completion and signoff of Field Qualification Testing and upon receipt of FRA’s approval, Metrolink initiated Revenue Service Demonstration (RSD) runs. RSD runs consisted of revenue service trains with I-ETMS active and enforcing. Details on entry criteria, exit criteria, and the number of runs required during RSD can be found in the Test Waiver and the RSD Applications, which are both on file at FRA. This sequence of segment testing, qualification testing, and Revenue Demonstration has been followed for each of the remaining Metrolink Subdivisions that are to be PTC equipped as follows: Ventura and Montalvo; Valley; Orange and Olive; and River. The test results from the San Gabriel Subdivision are herein referenced in this Final SCRRA PTCSP and submitted to the FRA for review and certification.

18.3 Post-Certification Segment Definition Each stage of PTC installation for revenue service has been defined as to both the extent of territory and the sequence necessary for minimum impact to railroad operations. These definitions have been defined in the PTC project plan and schedule. The post-certification deployment will employ the following process for equipping any new subsystems of the Metrolink rail system:

1. Baseline Verification Test (BVT) using the V&V process used on San Gabriel, 2. Regression Testing of any differences from the San Gabriel sub, 3. Traceability Matrix, 4. Configuration management of the individual WIU/wayside elements and

modifications to the communications systems to incorporate new subdivisions. 5. Maintenance of #subdiv files using WabTrax and configuration management, 6. Accommodate FRA Participation in post-certification deployment as desired,

Please also refer to the PTCIP and RFA for items 18.3-1, 18.3-2, and 18.3-3. The post certification PTC Processes are bullets within these items.

18.4 Key Elements of PTC Post-Certification Deployment Process The following list summarizes the elements of the process which are to be followed for installing, commissioning, and operating PTC on any new segments of the railroad after certification of this PTCSP. The process does not apply where SCRRA is a tenant on other host railroad properties, nor where it is conducting Revenue Service Demonstration under an approved plan prior to certification. Another railroad’s process will need to be addressed in that railroad’s own PTCSP and is not discussed in this document.



1. Definition of track segment and all PTC fixed control equipment and supporting equipment to be installed in the track segment.

2. Set up of WIUs, radios, and other wayside amenities needed for PTC operation. 3. Definition of all motive power or control (Cab) cars needed for PTC operation on

this track segment, and definition of the status of onboard PTC installation. Sufficient numbers of vehicles equipped with PTC and completely tested and released for revenue service must be available to support the track segment prior to any revenue service initiation.

4. Coordination with the PTC installation and test forces such that the track segment can be “put into service under PTC control” in the least amount of time with the minimum impact on revenue train operation. The use of such techniques as a shadow mode for PTC to ensure reliable communication and data I/O is a potentially important part of this coordination. Resource loading and scheduling must also be handled.

5. Definition of the master track database contents for this segment and the responsibility assignment for mapping and coding the database. Within this task is the requirement for full safety validation of the database (used for the “#subdiv” file).

6. Identification of all operating and supervisory personnel who must be fully trained and prepared for PTC operation, support, and maintenance over the entire PTC track segment. This includes train engineers and conductors who will be expected to operate over this track segment. Prior to completion of track segment deployment, all PTC responsible personnel must be trained and pass the appropriate qualification testing. Note that there is no PTC training other than PTC overview training for conductors. Conductors on Metrolink trains have no additional duties that are PTC related and are not stationed in the locomotive or controlling cab.

7. Complete review of all operating Rules and Special Instructions for the track segment to ensure that they are compatible with and support PTC operation. Verification that timetables and/or General Orders and any other operating and maintenance schedules are set up to accommodate the PTC operation.

8. Generate a detailed test plan for wayside equipment and fixed communication equipment associated with the PTC system in the track segment. Each unit and component must be properly installed and connected to I/O and power as per the drawings and schematics. Each communication device must be shown to properly perform without unexpected errors or deficiencies in transmission.

18.5 Interoperability Testing SCRRA has successfully conducted interoperability tests of I-ETMS at subdivision boundaries with BNSF and UPRR. As the testing of the interoperability of the PTC system is, by definition, a collaborative process involving two or more railroads, this portion of the testing was conducted as a joint effort with the adjacent railroad. SCRRA was the host railroad for all tests where the test runs originate on a SCRRA subdivision and the train movement is toward a target that is located on an adjacent railroads



subdivision. SCRRA was the host for tests utilizing both SCRRA I-ETMS equipped trains and for tests utilizing other railroad I-ETMS equipped trains. Likewise, SCRRA collaborated with adjacent host railroads in conducting their own interoperability tests by providing I-ETMS equipped trains where SCRRA trains operate on the adjacent railroad and movement is toward a target located on a SCRRA subdivision. The host railroad is responsible for submitting the Test Procedures and making arrangements for tests on its own property. The Test Procedures for interoperability testing include the following information:

1. A complete and final description of the system deployed for the interoperable test period. This description includes the identification of all software versions that are deployed during the test period.

2. Identification of all participating railroads and the roles and responsibilities of each railroad participating in the test.

3. Operating Rules and Special Instructions for the Subdivisions within the test areas. This includes any modifications to existing rules. Each railroad has issued Operating Rules and Special Instructions for operation on its own subdivisions during the test period.

4. Data collection plans, that include the following: identification of the system under test; what data was collected; analysis of the data concerning comparison of transmitted authorities; and, data concerning the specific occurrences under which I-ETMS initiates enforcement.

5. Sufficient risk analysis documentation that established with a high degree of confidence that the critical feature nodes of the product for test areas were identified, along with their associated causes, and appropriate mitigations.

The Interoperability Test Report was signed by each of the participating railroads.



19 Post-Implementation Testing (Validation) and Monitoring Procedures [§236.1015(d)(11)]

As required by 49CFR §236.1015(d)(11), this section provides for description of all post-implementation testing (validation) and monitoring procedures, including the intervals necessary to establish that safety-functional requirements, safety-critical hazard mitigation processes, and safety-critical tolerances are not compromised over time, through use, or after maintenance (adjustment, repair, or replacement) is performed. This description is included in the Metrolink Operating & Maintenance Manual found in Appendix L of this PTCSP, which describes the proper maintenance processes and time intervals as needed to maintain safety-critical performance of the system and its components.

The following testing that was mandated (per the approved Metrolink Test Waiver under FRA 236.1035) but is no longer required under post certification operation, will, however, be included in the post-implementation test.

• Operational Methods and Support for Monitoring of operation. • Periodic testing for proper function and response to negative conditions. • Safety Functional requirements reviewed for compliance. • Safety Critical hazard processes examined to determine if new hazards exist. • Safety Critical tolerances not compromised – operation is within expected

bounds. • Testing procedures for maintenance and repair reviewed for consistency with

needs and training provided.

Post-implementation monitoring of the PTC system is performed by the Network Management System (NMS) client to have a real-time picture on the location and status of all reporting Metrolink assets. This real-time monitoring of PTC assets and alarms allows the control center to create trouble tickets with the appropriate craft’s help desks. The NMS alarm system is under development. None of the alarms are implemented at this time. The Network Management System is an administrative tool and not a part of the PTC system architecture. It is currently used for remote diagnostics only. The list of alarms which will be monitored in the future is included in Table 19-1 below.

Table 19-1 NMS Alarm List

Alarm Type Segment of Alarm Locomotive Communication Failure BackOffice

Back Office Mandatory Directive Failure BackOffice Forward Power Out Of Range Base Reverse Power Out Of Range Base

VSWR Out Of Range Base Voltage Out Of Range Base

Detect RF Out Of Range Base



Alarm Type Segment of Alarm Reset Count Over Limit Base

Number Of Satellites Out Of Range Base Software Images Over Limit Base

Invalid ITC Version Base ITC Version Not Last Loaded Base

HRX Connection Down Base STAT Command Excessive Failures Base POS Command Excessive Failures Base REV Command Excessive Failures Base HRX Command Excessive Failures Base APPS Command Excessive Failures Base

SYSMGT Command Excessive Failures Base Time synchronization failure Base

Asset Reboots Base Bad transmitter/antenna condition Base

Radio IP Address/Port not configured Base Ram self-test failure Base

Radio cannot communicate with GPS module Base Transmitter low power Base

Transmitter over temperature Base CIM script failure Base

CIM Script Signature Mismatch Base General SMS Get Status Base

Locomotive Communication Failure Locomotive Low Voltage Problem Locomotive

Locomotive Basic Fault Locomotive Antenna/Co-Ax Problem Locomotive

Excessive Noise Antenna Problem Locomotive Not Reporting Locomotive

Receiver Problem Locomotive Transmitter Problem Locomotive Low Battery Problem Locomotive

GPS Problem Locomotive Locomotive Radio Timed Out Locomotive

Locomotive Initialization Failure Locomotive Low Voltage Problem Locomotive CPU Load High 1 Min Locomotive CPU Load High 5 Min Locomotive

CPU Load High 15 Min Locomotive Memory Low Locomotive

Disk Usage High Locomotive ITCM Message Queue High Locomotive

ITCM Service Stopped Locomotive Ping Failed Locomotive

RMSM Service Timed Out Locomotive



Alarm Type Segment of Alarm SNMP Walk Failed Locomotive

Forward Power Out Of Range Locomotive Reverse Power Out Of Range Locomotive

VSWR Out Of Range Locomotive Voltage Out Of Range Locomotive

Detect RF Out Of Range Locomotive Reset Count Over Limit Locomotive

Number Of Satellites Out Of Range Locomotive Software Images Over Limit Locomotive

Invalid ITC Version Locomotive ITC Version Not Last Loaded Locomotive

HRX Connection Down Locomotive STAT Command Excessive Failures Locomotive POS Command Excessive Failures Locomotive REV Command Excessive Failures Locomotive HRX Command Excessive Failures Locomotive APPS Command Excessive Failures Locomotive

SYSMGT Command Excessive Failures Locomotive Locomotive Fault Locomotive

Time synchronization failure Locomotive Asset Reboots Locomotive

Bad transmitter/antenna condition Locomotive Radio IP Address/Port not configured Locomotive

Ram self-test failure Locomotive Radio cannot communicate with GPS module Locomotive

Transmitter low power Locomotive Transmitter over temperature Locomotive

CIM script failure Locomotive Locomotive Initialization Failure Locomotive CIM Script Signature Mismatch Locomotive

General SMS Get Status Locomotive Ping Failed Wayside

Wayside Timed Out Wayside CPU Load High 1 Min Wayside CPU Load High 5 Min Wayside

CPU Load High 15 Min Wayside Memory Low Wayside

Disk Usage High Wayside ITCM Message Queue High Wayside

ITCM Service Stopped Wayside Ping Failed Wayside

RMSM Service Timed Out Wayside Forward Power Out Of Range Wayside Reverse Power Out Of Range Wayside

VSWR Out Of Range Wayside



Alarm Type Segment of Alarm Voltage Out Of Range Wayside

Detect RF Out Of Range Wayside Reset Count Over Limit Wayside

Number Of Satellites Out Of Range Wayside Software Images Over Limit Wayside

Invalid ITC Version Wayside ITC Version Not Last Loaded Wayside

HRX Connection Down Wayside STAT Command Excessive Failures Wayside POS Command Excessive Failures Wayside REV Command Excessive Failures Wayside HRX Command Excessive Failures Wayside APPS Command Excessive Failures Wayside

Wayside Timed Out Wayside SYSMGT Command Excessive Failures Wayside

WMS Reboot Wayside Time synchronization failure Wayside

Asset Reboots Wayside Bad transmitter/antenna condition Wayside

Radio IP Address/Port not configured Wayside Ram self-test failure Wayside

Radio cannot communicate with GPS module Wayside Tower Light Request Timed Out Wayside

Light Out Wayside Light Out(Dawn) Wayside

Transmitter low power Wayside Transmitter over temperature Wayside

CIM script failure Wayside CIM Script Signature Mismatch Wayside

General SMS Get Status Wayside

19.1 Replacement of Existing PTC System by New PTC System Metrolink installed a new PTC system and was not replacing a current system. If at a later date there is a need to replace the current system Metrolink will use the following concepts. When replacing an existing certified PTC system, a later revision of the PTCSP will establish with a high degree of confidence that the new system will provide a level of safety not less than the level of safety provided by the system to be replaced. To achieve this high degree of confidence, the Safety Plan will need complete review and revision of most sections and appendices. Some key examples of material that will require revision for the new system are listed below:

• System Description • Revision of PTCDP, Type Approval, and/or Type Approval Variance Documents.



• Human Factors Analysis unless User Interfaces remain the same • Safety Hazard Analysis (PHA, FFT, SSHA, etc.) and related Hazard Log • Safety Assurance Concepts • Testing • Training • Operation and Maintenance Manuals • Rules and Procedures related to use of new PTC system • Risk Assessment

19.2 System Reliability and Availability Targets The degree of reliability and availability provided by I-ETMS components is of critical importance to the management of safe train operations. As I-ETMS is being implemented as a Vital Overlay, improvement to overall railroad safety is proportional to the ability of the system to remain in good working order. Reliability and availability goals set within the PTCDP, establish key targets to achieve in order to establish the consistency of system performance as well as impacts of and minimize system downtime. Derived from the initial targets, a tentative baseline has been established, to which evidence of system reliability and availability obtained during initial and post implementation PTC testing can be compared with. Complexity of the system which includes field, on board, and office based components interconnected through various communications equipment and mediums, makes it difficult to set specific targets for all components that comprise the system and are installed across the full Metrolink rail network; without having a peer PTC system previously deployed that can present the necessary information. Following conclusion of Extended Revenue Service Demonstration, which includes all methods of operation and use of various applied PTC technologies, a final baseline assessment of system reliability and availability can be defined and assessed for its appropriateness to Metrolink. Reliability has been compared from design to observations from the ongoing 120 day Reliability and Availability test period during Revenue Service Demonstration. Reference CDRL 22-024 the Reliability Report as included in Appendix FF. PTC reliability data has been shared with FRA during the RSD and ERSD as part of the reporting process required by FRA. The post implementation testing procedures and monitoring timeframes have been established based on experience with processor-based products applied on Metrolink over the past 25-30 years. For individual components, demonstrated mean time between failures (MTBF) of signaling components generally varies within a range spanning two to several years. To address potential degradation of safety critical components, periodic maintenance checks of equipment, occurring on an annual basis, serves to address issues of adjustment or degraded performance before they become safety issues. These somewhat conservative actions are reflected in the preventative maintenance and monitoring guidelines defined in Appendix W of this PTCSP.



Metrolink will continually review failure data from PTC operations to determine if initial targets are in line with demonstrated results and if failure rates experienced are detrimental to rail operations or safety requiring system modifications to improve either reliability or availability. Metrolink will work with suppliers and industry users of I-ETMS to share demonstrated reliability data results and are prepared to amend post implementation activities as warranted.

19.3 Post Implementation and Monitoring Activities The primary post implementation testing activities being performed by Metrolink are included within the Metrolink PTC Operating and Maintenance Manual (OMM). A summary of these activities is included in Appendix W, which includes a description of the proper maintenance steps and time intervals required to maintain the safety critical performance of the system and its components addressing adjustment, repair and equipment replacement scenarios. Metrolink post-implementation testing and monitoring will include:

• Continuous monitoring of system components to confirm equipment continues to operate within acceptable bounds

• Periodic test and/or inspection of equipment including proper responses to out of limits conditions

• Determination if any system component demonstrates improper operation outside of its targeted component reliability limits

• Periodic inspection of equipment assessing any physical degradation to it or to interconnections

• Confirmation of proper component configuration • Confirmation of proper adjustment(s)

The Metrolink OMM, which contains references to all vendor and Metrolink specified troubleshooting, test and commissioning (validation) procedures, including periodic testing requirements, is addressed in Appendix L of this Metrolink PTCSP. A summary from the Metrolink OMM of the preventative maintenance activities planned for each I-ETMS component, as well as the means by which Metrolink is performing PTC system monitoring is included in an appendix to this section, Appendix W of this PTCSP.



20 Records [§236.1015(d)(12)] [§236.1023(b)(1)], [§236.1023(e)] [§236.1037]

This section provides a complete description of each record necessary to ensure the safety of Metrolink PTC system that is associated with periodic maintenance, inspections, tests, adjustments, repairs, or replacements, and the system’s resulting conditions, including records of component failures resulting in safety-relevant hazards as required by 49CFR §236.1015(d)(12). This section also includes Metrolink’s record retention process that ensures compliance with 49CFR §236.1037. This process includes:

1. Retention of:

a. A current copy of each FRA approved Type Approval, if any, PTCDP, and PTCSP that it holds

b. Adequate documentation to demonstrate that the PTCSP and PTCDP meet the safety requirements of Subpart I

c. An Operations and Maintenance Manual pursuant to § 236.1039

d. Training and testing records pursuant to § 236.1043(b)

1. Recording of results of inspections and tests specified in this PTCSP as required by § 236.1015(d)(11)

2. Retention of training records for each contractor providing services related to the testing, maintenance, or operation of Metrolink PTC system per § 236.1039(b)

3. After the PTC system is placed in service:

a. A database will be maintained of all safety-relevant hazards as set forth in this PTCSP and those that had not been previously identified

b. Safety-relevant hazards will be monitored for frequency: If the frequency exceeds the threshold set in this PTCSP, Metrolink reports the inconsistency in writing by mail, facsimile, e-mail, or hand delivery to the Director, Office of Safety Assurance and Compliance, and the FRA. The frequency threshold for hazards is shown by the level of residual risk in the Hazard Log.

c. If failure(s) occur that would change (increase) the residual risk category of the hazard, the frequency deviation will be reported to FRA, along with the FRA required information about the failure, and the event will be transmitted to the vendor and to the other PTC railroads. Causes will be analyzed to



determine the root cause and if necessary additional hazard analysis will be performed on the related hazard to determine any other potential effects.

20.1 Record Description

Metrolink has cataloged and will continue to maintain all documents for the installation, maintenance, repair, modification, inspection, and testing of the PTC system. A complete listing of each document record can be found in Metrolink Operations & Maintenance Manual addressed in Appendix L of this PTCSP. The process by which these records are managed is described in Appendix P of this PTCSP.

20.2 Data Retention Management

Metrolink will retain the following PTC documents and records in accordance with § 236.1037. Table 20-1 displays the retained documents, the requirements, the retention period, and the SCRRA retention policy which governs. The SCRRA record retention policy is addressed in Appendix P.2 of this PTCSP and provides an explanation and table covering all SCRRA documentation including PTC documents.



Table 20-1 Retained Documents

ITEM REQUIRED BY RETENTION PERIOD SCRRA RETENTION POLICY DOCUMENT

System Type Approval, PTCDP, PTCSP

§ 236.1037(a)(1) The life cycle of the system OPS2000

Supporting safety documentation for the PTCDP and PTCSP


Operations & Maintenance Manual pursuant to § 236.1039


Training & testing records pursuant to § 236.1043(b)

§ 236.1037(a)(4) § 236.1037(c) (contractors)

Until new designations of qualification are recorded for the employee or for at least one year after such persons leave applicable service pursuant to § 236.1043(b).

OPS1020

Results of inspections and tests specified in the PTCSP and PTCDP

§ 236.1037(b) In accordance with § 236.110(b) tests made in compliance with § 236.587, 92 days; For tests made in compliance with § 236.917(a):

• Installation and modification tests are to be retained for the life cycle of the equipment tested;

• Periodic tests required for maintenance and repair of the

OPS3000, OPS1011, OPS5000



ITEM REQUIRED BY RETENTION PERIOD SCRRA RETENTION POLICY DOCUMENT

equipment tested must be retained until the next record is filed but in no case less than one year.

All other tests must be retained until the next record is filed but in no case for less than one year.

Hazard log § 236.1037(d) The life cycle of the system OPS2000 PTC Product Vendor List pursuant to § 236.1023(a)

§ 236.1023(a) The life cycle of the system OPS2000



Type Approval, PTCDP, and PTCSP 20.2.1

Metrolink will keep a copy of each Type Approval received for its PTC system and will continue to retain any future Type Approvals received throughout the lifecycle of the PTC system. Currently, Metrolink has no Type Approval Variances. Metrolink has a copy of each submitted PTCDP and PTCSP and will retain throughout the lifecycle of the PTC system. These documents will be kept securely at the Dispatching and Operations Center in either hard, and/or soft, copy form in a secured location where only authorized individuals may access them. Access to electronic soft copy of documentation will be controlled under system access authorization requirement governed by Metrolink IT/CM Policies.

Supporting Safety Documentation for PTCDP/PTCSP 20.2.2

Metrolink has a copy of all of the supporting safety documentation used to justify the PTC system in the PTCDP/PTCSP and will maintain throughout the lifecycle of the system. These documents are kept securely at the Dispatching and Operations Center in either hard, and/or soft, copy form in a secured location where only authorized individuals may access them. Access to electronic soft copy of documentation will be controlled under system access authorization requirement governed by Metrolink CM Policies.

Operations & Maintenance Manual

Metrolink has catalogued and will maintain all documents specified in the referenced PTCDP and this PTCSP for the installation, maintenance, repair, modification, inspection, and testing of the PTC system. Metrolink has collated them into a single Operations and Maintenance Manual that will be maintained throughout the lifecycle of the PTC system. This manual, and all of the subdocuments that comprise it, is readily available, via Metrolink approved means of electronic distribution including, but not necessarily limited to, intranet and CD or DVD, to all personnel who will be required to perform the tasks described in the manual and for inspection by FRA and FRA-certified inspectors.

Training Records 20.2.3

Metrolink will keep a copy of all of the training records which designate persons who are qualified under 49CFR §236.1043 until new designations are recorded or for at least one year after such persons leave applicable service. These documents will be kept securely at the Dispatching and Operations Center in either hard, and/or soft, copy form in a secured location where only authorized individuals may access them. Access to electronic soft copy of documentation will be controlled under system access authorization requirement governed by Metrolink CM Policies.

Records related to employee attendance and certification/qualification for I-ETMS, including employee attendance records and records related to certification for



individuals to perform certain tasks, will be retained after the employee’s employment relationship with Metrolink ends; or longer, if and as Metrolink corporate policy dictates.

Initial and refresher training and qualification records will be maintained in corporate databases designated for training records or an enterprise learning management system, as that technology is utilized. These records shall be available for inspection and replication by FRA and FRA-certified State inspectors at the Dispatching and Operations Center.

Records will include relevant training information such as:

• Name of the employee

• Employee occupational category of subcategory designation

• Training completion dates

• Title of training course completed

• Pass/fail on associated tests if applicable, or date qualified

Inspection & Test Records 20.2.4

Metrolink has catalogued and will continue to maintain a hard or soft copy of all of the required inspection and test records at Metrolink’s Dispatching and Operations Center in a secured location where only authorized individuals may access them. For tests performed in accordance with 49CFR §236.587, records will be kept in either hard, and/or soft, copy form for 92 days. A copy of installation and modification tests will be kept in either hard, and/or soft, copy form throughout the lifecycle of the system.

A copy of periodic tests for maintenance or repair of the equipment will be maintained until the next record is filed, but in no case less than one year. All other tests will be retained in either hard, and/or soft, copy form until the next record is filed but in no case less than one year. All inspection and test records will be available for inspection and replication by FRA and FRA-certified state inspectors.

Hazard Log 20.2.5

The master copy of the generic Hazard Log is being maintained by Wabtec Railroad Electronics on behalf of the participating I-ETMS railroads. This document is kept securely at WRE in Cedar Rapids in soft copy form in IBM RequisitePro in a location where only authorized individuals may access the document and databases.

The management of the Hazard Log on a long-term basis is the subject of a railroad industry study currently underway with leadership provided by the ITC of the Class I railroads and supported by Metrolink. Wabtec is included in this study as it currently maintains the master Hazard Log for all I-ETMS railroads.



Metrolink will keep a copy of the Metrolink-specific Hazard Log throughout the lifecycle of the system. These documents will be kept securely at the Dispatching and Operations Center in either hard, and/or soft, copy form in a location where only authorized individuals may access them. Any additional hazards determined during system operation will be added to the Hazard Log and mitigations provided to maintain the required level of system safety.

As any errors and malfunctions of the system are reported to any component vendors, Wabtec will be notified. Wabtec, Metrolink and other I-ETMS customers will assess the issue’s impact on system safety. As appropriate, certain errors and malfunctions will be logged into the hazard log for mitigation. Any safety-relevant hazards will be monitored for frequency. If the frequency exceeds the threshold set in this PTCSP, Metrolink will report the inconsistency in writing by mail, or e-mail to the FRA Director, Office of Safety Assurance and Compliance.

Product Vendor List 20.2.6

Metrolink currently has and will continue to maintain a copy of the PTCPVL throughout the lifecycle of the system. These documents will be kept securely at the Dispatching and Operations Center in either hard, and/or soft, copy form in a location where only authorized individuals may access them. Section 33.1 describes the PTCPVL.

20.3 Disclosure of PTC-Related Hazardous Conditions or Safety-Related Failures

Metrolink and its PTC suppliers have processes to ensure disclosure of PTC-related hazardous conditions or safety-related failures and take prompt countermeasures to reduce the frequency of each safety-relevant hazard to below the threshold set forth in this PTCSP pursuant to 49CFR §236.1037. Such processes are described in Section 33 of this PTCSP.



21 Safety Analysis of Work Zone Incursion Protection from Human Error [§236.1015(d)(13)]

This section provides a safety analysis to determine whether, when the Metrolink PTC system is in operation, any risk remains of an unintended incursion into a roadway work zone due to human error as required by 49CFR §236.1015(d)(13). This section also describes how any remaining risk is mitigated in the current I-ETMS implementation. See Section 6.2.2.5.2 of this PTCSP for the predefined changes to be implemented by Metrolink in the future for Work Zone Protection.

21.1 Functional Description

The Locomotive Segment enforces train and engine movements while approaching or occupying work zones that have been conveyed via a track bulletin. I-ETMS prevents unauthorized train incursions into the limits of work zones, or unauthorized train movements when operating within the limits of a work zone, by the following three separate functions. First, the Locomotive Segment provides enforcement for the limits of the work zone. Second, I-ETMS will present prompts via the locomotive PTC display terminal as described below, to confirm that verbal permission has been received from the Employee in Charge (EIC) in compliance with Metrolink operating rules for work zones. Third, as an additional level of protection, the visual display of the work zone limits will remain on the PTC display terminal even after the prompts related to the work zone have been acknowledged.

When a train or engine approaches an active work zone within a configured threshold approach distance, or when a work zone is issued for the track currently occupied by a train, the Locomotive Segment prompts for an initial acknowledgment that the train has received verbal permission from the EIC to enter and proceed through the work zone limits. It is followed by a second prompt that provides a confirmation of the first acknowledgement. Until both prompts are acknowledged indicating verbal permission has been received to proceed through the work zone limits, the Locomotive Segment performs predictive warning and enforcement of a stop at the near limit of the work zone. When both prompts are acknowledged, signifying that verbal permission has been received (within the threshold approach distance and prior to application of a predictive enforcement brake application), the Locomotive Segment relieves enforcement of the stop at the near limit, allowing the train or engine to enter and operate through the limits of the work zone.

When a train or engine begins to move after stopping within the limits of an active work zone (having previously entered the limits), the Locomotive Segment provides a work zone warning and prompts requiring acknowledgement that verbal permission has been received from the EIC authorizing continued movement. If acknowledgement is not provided in response to the work zone prompts, the Locomotive Segment invokes a full-service enforcement brake application and stops the train in a fail-safe manner. If the work zone prompts are acknowledged after beginning movement, the Locomotive Segment removes the work zone prompt and permits the train to continue movement



through the work zone. I-ETMS will protect and provide enforcement for a change of direction within the limits of a work zone based on the Metrolink-specific configuration parameters set in accordance with the Metrolink operating rules.

When a train or engine is occupying the limits of a work zone when the work zone becomes active (based on time specified in the work zone track bulletin), the Locomotive Segment displays a work zone warning and prompts requiring an acknowledgement that verbal permission has been received from the EIC to proceed through the limits, as described above. When time limits of a work zone have expired, the Locomotive Segment ceases to enforce train and engine movements through the work zone limits. If a full-service enforcement brake application was invoked due to enforcement of work zone limits just prior to the expiration of the limits, the Locomotive Segment ceases enforcement of the work zone limits after the train comes to a complete stop.

Three functionalities are currently used to protect the work zone. Each has an estimated MTTHE:

(1) Predictive and reactive enforcement of the entry point of the work zone, which has a nominal MTTHE of 1E9 hours,

(2) The requirement for the train crew to provide two acknowledgements of their train’s authorization to enter in order to remove that enforcement which has a nominal MTTHE of 2E6 hours (two independent human errors must occur), and

(3) The continuous display of work zone presence and limits, which has a nominal MTTHE of 1E3 hours (based on a human error in interpreting the display)

These three items provide three types of protection against the risk of an unintended incursion into a work zone in the present I-ETMS design. The most sensitive is the observation of the onboard display (CDU) which can be misunderstood by a single human error. The predefined changes identified in Section 6.2.2 of this PTCSP will provide a vital implementation of the work zone protection that will eliminate the human error potential.

21.2 Identification and Mitigation of Human Errors

The work zone protection function is accomplished through a combination of system functionality and procedure. Human error can be sub-categorized into errors associated with interaction with the Human Machine Interface, in this case the CDU, or failure of procedure. Those facets of the work zone protection function that pertain to human errors are listed in the O&SHA and include those associated with both the train crew and the EIC. Procedural and training requirements are established in the O&SHA to ensure that the resulting operating procedures generated to support protection against work zone incursion mitigate all potential hazards.

The O&SHA also references the human factors analysis used to substantiate that the Human Machine Interface was implemented in a manner to minimize errors in human



interaction. The Hazard Log is used to track these procedural, training, and HMI requirements through to successful mitigation. The assessment of residual risk associated with work zone incursion, as well as all other functions, is analyzed in the risk assessment contained in Appendix F of this PTCSP. These assessments provide a structured method of indicating the system faults or human errors that can lead to a loss of work zone incursion protection.

21.3 Metrolink Operating Rules Related to I-ETMS Protection Against Work Zone Incursion

• At present, there are no proposed changes to the rules protecting establishing work zones due to PTC. PTC will enforce the permissions. There is no proposed change in operations regarding form based authorities, placing of red boards, yellow/red boards, yellow boards, etc. or limits of track and time. Existing communications of work zones and protection thereof, as communicated between the train and the dispatcher will remain as they are today. The PTC system will provide an overlay as a method of enforcement.

• Per the rules, authorities granted by the dispatcher will be enforced on-board the locomotives. The current Metrolink EIC terminals are not part of the PTC process, but instead are used to digitize communications between EIC and the dispatcher as appropriate.

• The EIC Field Remote Terminals are used as an aid to executing work zone incursion protection but are not an essential part of the PTC system, as the EIC Terminal used by Metrolink EIC personnel is not connected directly to the PTC system components, so the EIC terminal has no PTC functionality. The use of the EIC Terminal promotes the roadway protection functionality, but the same level of protection can be obtained without use of the EIC Terminal.

21.4 Metrolink Work Zone Configuration Parameters The following Table 21-1 demonstrates the configurable parameters to be applied by Metrolink to the locomotive approaching a work zone: Refer to the following Section 21.4.1 for discussion of the parameters. Note: TBC refers to a configurable parameter. The numbers after TBC do not refer to properties, but are numerical designators. Some configurable parameters are set by the ITC and some are railroad configurable within an allowable range. Configurable Parameters are shown in Appendix LL of this PTCSP.

Table 21-1 Work Zone related TBCs

TBC Description Current Metrolink Value

Units Range

TBC161 Work Zone Target Receipt of Dataset Enforcement Delay ...

30 seconds 0-180



TBC182 Prompt Display Distance ...

3 miles 2-8

TBC183 Target Display Time ...

60 seconds 0-180

TBC184 Work Zone and Joint Movement Authority Reactive Enforcement Target Enforcement Delay ...

30 seconds 0-180

Approaching Active Work Zone 21.4.1When a train or engine approaches an active work zone, the onboard will place a head-end only zero mph speed target over the limits of the entire work zone, if the work zone bulletin is within TBC183 seconds of becoming active. The limits of the work zone will be displayed to the crew with a blue hash visual display of the work zone’s defined limits along with a red hash from the near end of the work zone limits to the right edge of the CDU screen. When a train or engine approaches an active work zone and is within TBC182 miles from active work zone limits, the onboard system prompts the crew for an indication that verbal permission has been received from the EIC of the work zone to enter and proceed through the limits. A second prompt requests crew confirmation that verbal permission to proceed has been received. Until both prompts are acknowledged on the interactive display indicating that verbal permission has been received to proceed through the work zone limits, the onboard system performs predictive warning and enforcement of a stop at the near limit of the work zone. An enforcement delay has been implemented to ensure a minimum of TBC161 seconds has elapsed since the work zone bulletin was received and TBC249 seconds after the work zone has gone into effect to give the crew opportunity to indicate they have verbal permission to proceed and/or properly handle their train.

Work Zone becomes Active while within Limits (or within 21.4.2calculated position uncertainty)

When a train or engine is occupying the limits of a work zone when the Work Zone becomes active (based on time specified in the work zone track bulletin), the onboard system displays a Work Zone warning, and prompts requiring a multiple crew acknowledgement that verbal permission has been received from the EIC to proceed through the limits, as described above. An enforcement delay of TBC184 seconds has been implemented to give the crew opportunity to indicate they have verbal permission to proceed. If the prompts indicating that verbal permission has been received to proceed through the work zone limits are not acknowledged within the given delay, the onboard PTC system performs a reactive enforcement and stops the train.



22 Alternative Arrangements for Rail At-Grade Diamond Crossings [§236.1005(a)(1)(i)] [§236.1015(d)(14)] <reserved>

This section provides a detailed description, when applicable, of any alternative arrangements as already provided under §236.1005(a)(1)(i) with regard to train-to-train collisions as required by 49CFR §236.1015(d)(14).

There are no alternative arrangements for rail at-grade diamond crossings for Metrolink,



23 Authority and Signal Enforcement Exceptions Not in PTCDP [§236.1005(e)(4)] [§236.1015(d)(15)]

This section provides additional details of the Metrolink PTC system enforcement of authorities and signal indications to supplement the descriptions included in the referenced PTCDP and any exceptions to the switch protection requirements as required by 49CFR 236, Subpart I, §236.1005(e)(4) and 49CFR 236, Subpart I, §236.1015(d)(15). SCRRA does not have any form of authority or signal enforcement that is not already described in the I-ETMS® Type Approval, so no SCRRA action is believed necessary.

23.1 Train Stop System (ATS) Upon deployment of PTC on ATS protected territory, SCRRA will request permission from the FRA to take the train stop system that was installed as a predecessor to PTC at several locations out of service and then remove both the on-board and wayside components. This ATS equipment will remain on the SCRRA locomotives until NCTD PTC is in service or a waiver for the NCTD ATS territory is requested and approved. Wayside ATS components will be removed on Metrolink territory and ATS operation on Metrolink will be discontinued when PTC is put in revenue operation. Recently, SCRRA has submitted a waiver request to not equip temporary lease locomotives with ATS. At the time of this submittal, this waiver is pending before the FRA. Temporary disabling of ATS during testing was addressed in the §236.1035 test waiver as follows: SCRRA utilized intermittent automatic train stops (ATS) on portions of its territory. In order to effectively conduct running tests of I-ETMS it was necessary to temporarily disable the on-board portion of the ATS on the equipment being tested to prevent automatic warning and braking activation that could have interfered with the testing. The instances and instructions for disabling and re-enabling the on-board ATS equipment were detailed in the Test Procedures. Removal of the train stop system is governed by FRA §236.0(e) and §235.7(a)(5).

23.2 Enter Main Track - Signal in Lieu of Electric Lock

At most locations where a signal is used in lieu of an electric lock, the signal providing permission to enter main track will display Approach when block conditions are permissible. At locations where multiple signals in lieu of an electric lock are controlled by a single WIU, the signal will display Restricting.

Where a signal is used in lieu of an electric lock, the WIU at the location controlling the signal in lieu of the electric lock will report the status of the signal. For this function, Metrolink is already using a PTC-governed solution. The dispatcher issues permission



to enter main track from the CAD system. Upon receiving permission to enter main track, the crew will align the derail for movement and the signal will display a Proceed indication, if conditions are met. After receiving permission, the train crew member then aligns the switch. The signal in lieu of an electric lock is monitored, and if the signal displays Approach or Restricting, the train is allowed to proceed. At locations where multiple signals in lieu of an electric lock are controlled by a single WIU, the signal will display Restricting. In addition to the indication displayed by the signal, the operator will be given permission to enter main track as transmitted by PTC electronically and enforced on board the locomotive.

If the signal does not display Approach or Restricting, then the train then must wait ten minutes before being allowed to proceed at Restricted Speed, as described in Section 6.2.2.7.2.



24 Compliance with Stated MTEA [§236.1015(d)(16)] [§236.1019(f)]

This section describes how the Metrolink PTC system complies with 49CFR §236.1019(f) to attest that no changes, except for those included in an FRA approved RFA, have been made to the information in Metrolink’s PTCIP and Main Line Track Exceptions, if applicable, as required by 49CFR §236.1015(d)(16).

A Mainline Track Exclusion Addendum (MTEA) for the LA Union Station has been implemented as stated in Section 13 of the approved SCRRA PTCIP [30]. There are no changes to the MTEA as appended to the PTCIP and no other MTEAs have been proposed or implemented by SCRRA.



25 Deviation in Operational Requirements for Enroute Failures [§236.1015(d)(17)] [§236.1015(d)(21)] [§236.1029(c)]

This section describes any deviations in operational requirements for enroute failures as specified under 49CFR 236, Subpart I, §236.1029(c) that are not completely provided for in the PTCDP as required by 49CFR 236, Subpart I, §236.1015(d)(17). SCRRA operations follow the General Code of Operating Rules [29], and METROLINK current Timetable and Special Instructions [28]. Metrolink does not anticipate any deviations from the FRA requirements for operations during enroute failures, as are stated in regulation Part 236.1029(b). Operation under enroute failure conditions is described in the I-ETMS PTCDP, which is included in Appendix B of this PTCSP. Prior to 12/31/2017, Metrolink may cut out the PTC system with the dispatcher’s concurrence of the cut-out condition. Such conditions include enroute failure. To rectify the situation, Metrolink will make repairs as promptly as possible with minimal impacts on service. As of the statutory PTC implementation date, enroute failures will be handled by FRA regulations in a manner similar to Cab Signal equipment that has failed enroute, but instead governed by the Subpart I PTC regulatory requirements. Locations where Failed Onboard PTC Apparatus will be Exchanged or Repaired Per regulation, §236.1015(d)(21), Metrolink here identifies where failed PTC Onboard Apparatus will be repaired or exchanged. No movements on Metrolink will potentially exceed 500 miles. Name Location Central Maintenance Facility 1555 San Fernando Rd. Los Angeles, CA,

90065 Eastern Maintenance Facility 1945 Bordwell Ave, Colton, CA, 92324 Keller Yard Facility 720 Keller St, Los Angeles, CA 90012

Current operation of PTC on Metrolink permits a failed PTC onboard unit to be cut out and the train to be operated as unequipped for the rest of its normal run. The unit will then be routed to one of the above maintenance facilities for diagnosis and repair. As per the recent public PTC law, by 2018, Metrolink will follow the process required by 236.1029 to bring a failed PTC unit to the facility for servicing. Ideally, component replacement and removal should be able to occur anywhere on the rail so that a mechanic can board a unit and resolve a PTC fault issue if the unit is in the tracks. However, this methodology has not yet been attempted by Metrolink or used during any tests, and should be considered a potential future improvement in operations.



26 Enforcement of Hazard Detectors [§236.1005(a)(4)(v)] [§236.1005(c)(1)] [§236.1005(c)(2)] [§236.1015(d)(18)]

This section provides a complete description of how the Metrolink PTC system appropriately and timely enforces integrated hazard detectors as required by 49CFR §236.1015(d)(18). The description includes:

1. How hazard detectors integrated into the Metrolink signal or train control system on or after October 16, 2008 are integrated into Metrolink’s PTC system and are appropriately and timely enforced in accordance with 49CFR §236.1005(c)(1); and

2. How Metrolink’s PTC system provides for receipt and presentation of warnings from any additional hazard detectors to the locomotive engineer and other train crew members using the PTC data network, onboard displays, and audible alerts in accordance with 49CFR §236.1005(c)(2). The action taken by the system and the crew members is also described as applicable.

§236.1005(c)(3) is addressed in Section 28.

26.1 Function Description for Integrated Hazard Detectors I-ETMS provides protection against conditions monitored by hazard detectors, either when integrated into a signal system or in a stand-alone configuration. When integrated with a signal system, hazardous conditions monitored by the detector are manifested through the generation of more restrictive signal indications. These signal indications are communicated to the onboard and enforced in the same manner as other signal indications. Hazard detectors, not integrated with the signal system and directly monitored by a WIU, communicate directly with the Locomotive Segment. Similar to monitored switches, the location of each standalone hazard detector is identified through an entry in the track data base and validated as part of the track database validation process. A locomotive approaching a communicating hazard detector must stop, or proceed at restricted speed, so long as a valid “permissive” wayside status message from the device has not been received. Failure to receive wayside status messages within an acceptable age tolerance, results in the generation of an enforcement target consistent with the most restrictive conditions conveyable for that device. The functional discussion above applies to the integration of hazard detectors as supported by the I-ETMS PTC system. Specifics about the integration of hazard detectors in the Metrolink I-ETMS deployment, are described in Appendix Q of this PTCSP. The following items may be addressed in specific deployments of each hazard detector:

• Type of hazard detectors used (stand-alone and/or integrated)



• The duration allowed before an enforcement target is established for a detector not communicating its status.

• The most restrictive condition associated with the activation of the detector, e.g. enforcement of the train.

• Procedure for the dispatcher to allow a train to pass a known false hazard detection.

26.2 Integration Of Hazard Detectors On Metrolink The functional discussion above applies to the integration of hazard detectors as supported by the I-ETMS PTC system. Specifics about the integration of hazard detectors in Metrolink I-ETMS deployment are described in this section and in Appendix Q of this PTCSP. Hazard detectors on Metrolink (consisting of high water and slide detectors) are monitored by the signal system and will be enforced by the protecting signal displaying Stop or Stop and Proceed and the Stop or Stop and Proceed indication being vitally enforced by the PTC system. As with other “stop” aspects displayed on the CDU for the train crew, either a warning of impending enforcement will be given, or a reactive enforcement will be initiated by I-ETMS, depending on the time available vs. the need to enforce per stop aspect detected by the onboard I-ETMS. If time for warning is available, the crew will be shown the time left to stop the train on the CDU, as it would for approach to any signal displaying “stop”. Examples of Hazard Detector Integration drawings for FRA reference are given in Appendix Q of this PTCSP. Appendix Q provides typical circuitry showing how a hazard detector is enforced based on the aspect of the governing signal as is generated by the signal system and transmitted via the WIU to the PTC system.

26.3 Function Description for Additional Non-Integrated Hazard Detectors on Metrolink

I-ETMS, as currently designed, does not specify any actions to be taken by the system and/or crewmembers based on the receipt and presentation to the locomotive engineer and train crew of alarms or other warnings generated as the result of any additional non-integrated hazard detectors. Responses to non-integrated hazard detectors are covered by current Metrolink railroad Rules and procedures independent of PTC.



27 Emergency and Planned Maintenance Re-Routing Management Plan [§236.1005(g-k)] [§236.1015(d)(19)] [§236.1029] [§236.1033(f)]

This section provides the emergency and planned maintenance temporary rerouting plan, including an indication of how operations on the Metrolink PTC system takes advantage of the benefits provided under 49CFR §236.1005(g) – (k) as required by 49CFR §236.1015(d)(19) and the service restoration and mitigation plan defined under 49CFR §236.1033(f).

An Emergency and Planned Maintenance Rerouting Plan is not applicable on SCRRA territory. Re-routing of trains is not technically feasible. All passenger main lines are PTC equipped. Revenue passenger trains and freight trains will not be routed onto a SCRRA non-PTC-equipped subdivision in event of a line closure. Once PTC is fully implemented by tenant railroads, trains that are not PTC-equipped will not be operated on SCRRA territory, except for those with enroute failures.



28 High Speed Service Requirements [§236.1005(c)(3)] [§236.1007] [§236.1015(d)(20)]

This section contains the documents and information required for high-speed service under 49CFR §236.1007 as required by 49CFR §236.1015(d)(20).

I-ETMS is designed and developed to support operating speeds prevalent on North American heavy-rail freight and passenger roads, including up to 70 mph for freight trains and up to 110 mph for passenger trains. These requirements have been derived from customer operations and are reflected in the requirements surrounding braking calculations. Field tests have validated operation within these limits. As required by 49CFR §236.1007(a), I-ETMS is intended to be a vital overlay that works in concert with the safety-critical functional attributes of a block signal system, including appropriate fouling circuits and broken rail detection (or equivalent safeguards.) Refer to Section 6 and Appendix GG of this PTCSP.

SCRRA provides below an explanation for freight operations at or over 50 mph and passenger operations at or over 60 mph under the conditions described in §236.1007(a). Amtrak is a tenant passenger operation supported on the host tracks of Metrolink. SCRRA meets the individual safety requirements for passenger train operations at or exceeding 60 mph as per §236.1007, and the compliance is stated below. SCRRA does not have any trains operating or planned to be operating over 90 MPH at the time of submittal. Tenant railroads operating on SCRRA trackage are not operating and do not plan to operate trains over 90 MPH. Further, it is herein demonstrated that the PTC system meets the requirements set forth in FRA §236.1007 paragraph (a) for high-speed service. 236.1007 paragraph (a) states:

(a) A PTC railroad that conducts a passenger operation at or greater than 60 miles per hour or a freight operation at or greater than 50 miles per hour shall have installed a PTC system including or working in concert with technology that includes all of the safety-critical functional attributes of a block signal system meeting the requirements of this part, including appropriate fouling circuits and broken rail detection (or equivalent safeguards).

Where any Metrolink passenger trains are operated at, or in excess of, 60 mph, but not greater than 90 mph, or tenant freight trains at, or in excess of, 50 mph, the Metrolink PTC system is overlaid on a block signal system that includes all of the safety-critical functional attributes meeting the requirements of FRA Part 236, including appropriate fouling circuits and broken rail detection. If SCRRA decides in the future to operate its trains at greater than 90 mph, a sufficient explanation of the additional safety measures provided per FRA regulation will be distinctly identified in a future revision of this PTCSP.



29 Communication and Security Requirements [§236.1015(d)(20)] [§236.1033]

This section contains the documents and information required for communications and security requirements under 49CFR §236.1033 as required by 49CFR §236.1015(d) (20).

29.1 Communications Restoration Plan SCRRA references it’s plan for coping with communications systems outages and faults while providing safe PTC operation. Appendix S of this PTCSP contains the SCRRA PTC Communication Restoration Plan for safety-critical PTC/PTC communications, both internally and with tenant and adjacent railroads. Appendix CC of this PTCSP contains additional information on fallback where available. Failed communications will be repaired as soon as possible. On-board communications failures may be mitigated by alternate path communications, otherwise operation will be governed as Failure enroute. Wayside communication failures may be mitigated by alternate path communications. Repairs will be effected as soon as possible. Until the repairs are effected, operation will be in a non-PTC mode.

The security design of the Communications Segment is built in accordance with the requirements of 49CFR §236.1033. The items listed below provide details of the security approach and techniques used in the ITC System to ensure that Metrolink and/ or its contractors comply with 49CFR §236.1033. This information is provided in the order in which the requirements are listed in §236.1033.

1. All PTC communications between the office, wayside, and onboard components compute and insert a MacTag to ensure the integrity of the message as well as authenticate the sender.

2. The storage of the symmetric key material in non-volatile memory is encrypted.

a. The onboard I-ETMS application uses AES-128 CBC as specified in FIPS Publication 197 to store the track database files that contain the symmetric keys for waysides and locomotives.

b. The detailed description of how the back office systems store and / or retrieve symmetric keys can be found in the Metrolink Security Management Plan in Appendix CC of this PTCSP.

c. The detailed description of the functionality / process for entering the symmetric keys into the WIUs can be found in the Metrolink Security Management Plan in Appendix CC of this PTCSP.



29.2 PTC Security Provisions in I-ETMS PTC Security describes the security dealings associated with the protection of I-ETMS. Security measures have been designed to limit unauthorized access to and prevent tampering or overriding the safety functions of the system. The security measures address train-borne, wayside, and centrally located train control subsystems and/or components as applicable. Each of the system segments is protected utilizing physical security measures, operational procedures, and security policies, railroad-specific security tools, I-ETMS security design and implementation details, as well as test results for conformance testing in accordance with a master test strategy.

• ITCM Message Security o The message security provided between major subsystems of the PTC

system – preserving the safety-critical data without introducing errors or failing to detect errors. Refer to the ITCM Messaging description in [16].

• Network Security o ASA Firewall and Revision Control

The Cisco Adaptive Security Appliances (ASA) 5500 Series integrates multiple full-featured, high-performance security services, including application-aware firewall, SSL and IPsec VPN, antivirus, anti-spam, anti-phishing, and web filtering services.

These technologies deliver highly effective network- and application-layer security, user-based access control, worm mitigation, malware protection, and secure remote user and site connectivity.

• Application Security (BOS, CAD and OBS) o HMAC Authentication o Custom software authentication

See also Section 9.6 of the referenced I-ETMS PTCDP.

29.3 Security Measures for Employees and Vendors Metrolink/SCRRA has a documented plan for securing the system and its sensitive information using a series of non-disclosure and other agreements with employees, vendors, and suppliers. This is a formal SCRRA policy which is found in Appendix CC of this PTCSP.



30 Identification of Potential Data Errors and their Mitigation [§236.1015(h)]

This section identifies each of the risks for potential data errors and provides a discussion of each risk’s applicable mitigation as required by 49CFR §236.1015(h).

For Metrolink, the data errors considered are those that can be introduced into the system but not directly detected and mitigated by the I-ETMS design during normal operations. Below are sources of potential data errors, general mitigations put in place to address hazards that could result from errors in data, and pointers to Metrolink documentation addressed within this PTCSP to confirm mitigations are instituted. To the greatest extent possible, I-ETMS functionality has been designed to mitigate data errors but some elements of PTC-related information consumed by I-ETMS are subject to errors not directly detectable by PTC system design-instituted functions. In these cases, verification of data and settings, as well as confirmation of data correctness and completeness, is performed through closed loop, V&V processes and procedures to confirm data errors cannot lead to unsafe operation.

30.1 Sources of Potential Data Errors

PTC system data errors are accounted for in the Metrolink I-ETMS Hazard Log in Appendix D of this PTCSP. The System/Segment Affected column of the Hazard Log refers to the source of the potential hazard.

• Identification of the sources of potential data errors for Metrolink:

• Incorrect consist information entered by dispatcher • Channel noise and interference cause corruption of data. • Error detection schemes fail to detect data corruption. (applies to both

data messages and fixed database and program content protected by corruption detection schemes)

• Track database validated with critical feature data errors undetected. • Transmission of mandatory directives by I-ETMS containing data

errors • Transmission of mandatory directives by voice leads to data errors. • BOS corrupts message contents for locomotive or CAD undetected. • External sources provide erred data to PTC system • Systematic error in calculation of safety-critical data values by

locomotive or WIU software design.

• Identification of the HL entries associated with the potential data errors:



The Hazard Log contains the entries which reflect data errors occurring in the above and similar scenarios. Refer to the Hazard Log itself which is contained in Appendix D of this PTCSP for reviewing the hazards from data errors. Procedural sources of data errors are further examined in the OSCAR Verification document for Metrolink contained in Appendix D.1 of this PTCSP.

• Residual risks associated with these potential data errors are found in the Risk Assessment of the Metrolink I-ETMS system. See section 11 for more information.

• Future I-ETMS Mitigations:

The provision of the IC3 processor in combination with the existing BOS can help mitigate data errors attributed to the data in electronic authorities and databases maintained by the BOS (e.g., track database for locomotive downloading). The "electronic authorities" supplement but do not replace the other forms of verbal or paper authorities issued by the Train Dispatcher.

30.2 Mitigations for Potential Data Error Hazards

Mitigations instituted to address data errors that could lead to hazardous events are indicated within the Metrolink I-ETMS Hazard Log for each of the classes of data described previously. For those data errors not mitigated through design, but confirmed through V&V activities, the following general mitigation reference (OSCAR #) and method (Training) are included, as applicable, within the Hazard Log. All OSCAR references generally include the mitigations to be instituted as Policies, Procedures, Rules, or Training as is applicable to the Metrolink railroad.



31 Third Party Assessment [§236.1017]

Pursuant to 49CFR §236.1017, the Associate Administrator has not concluded that an independent third-party assessment of the Metrolink PTC system is necessary based on the criteria set forth in 49CFR §236.913.



32 PTC Data Maintained in Locomotive Event Recorder [§229.135(b)(3)(xxv)] [§229.135(b)(4)(xxi)] [§236.1005(d)]

As required by §229.135(b)(3)(xxv) and §229.135(b)(4)(xxi), this section specifies the format, content, and proposed duration for event recorder storage and retention of the safety-critical train control data routed to the locomotive engineer’s display with which the Engineer is required to comply, specifically including text messages conveying mandatory directives and maximum authorize speed. This section also specifies whether the PTC data is stored in a separate certified crash worthy memory module and is calibrated against other data required to be stored by §229.135.

The PTC data to be recorded consists of the following types:

• All Mandatory Directives that have been electronically delivered to the train.

• Maximum Authorized Speed.

• Warnings presented to the crew, including countdown to braking enforcement.

• Warnings indicating that enforcement is in effect.

• Current system state.

The PTC data is recorded in addition to all other FRA-required data. The safety-critical train status and PTC data are stored in on or more event recorders with “crash hardened” memory modules (CHMM) in accordance with 49CFR §229.135 (b)(3)(xxv) and (b)(4)(xxi) and 49CFR §236.1005(d). When multiple event recorders with CHMM are employed, the PTC data must be calibrated against other FRA required data.

The safety-critical train control and PTC data being captured in an onboard Event Recorder and/or PTC Event Recorder is described in Appendix X of this PTCSP. The duration of data storage meets FRA minimum requirements but is dependent upon many variables, including the actions of the train during the time period and the size of the CHR installed.

The data will be used as defined by Metrolink procedures for incident tracking and analysis, leading to the necessary staff interactions with the crewmembers, dispatchers, inspectors, or maintainers as necessary to promote safety in operations. Refer to the “PTC System Anomaly Analysis Procedure” document for the process of reporting these data. This document is located in Appendix W and is being used by Metrolink/SCRRA.



33 Process for Reporting Errors and Malfunctions [§236.1023]

33.1 PTCPVL [§236.1023(a)] Metrolink has selected current vendors for its major equipment for the I-ETMS PTC system it is installing. These vendors were selected for furnishing appropriate types of equipment, but are subject to change as procurement conditions evolve. The PTCPVL as of the date of issue of this PTCSP is contained in Appendix MM of this PTCSP. This Appendix shows the name, address, and contact information for each vendor, along with the types of PTC equipment supplied by the vendor. Appendix MM contents may be revised upon notice to FRA, but an RFA and full PTCSP revision are not expected to be submitted by Metrolink for changes to the supplier listing in the PTCPVL. Changes to the PTCPVL will be managed through the Metrolink PTC Configuration Management Plan, as addressed in Appendix P.1 of this PTCSP.

33.2 Contractual Arrangements with Suppliers or Vendors [§236.1023(b)(1)]

Contractual arrangements have been established with the suppliers of safety-critical hardware and software of the system components for immediate notification of all safety-critical software upgrades, patches, or revisions for their safety-critical processor-based signal and train control system. Also included in this notification are the reasons for such a change and any interim remediation for an identified hazard that can affect the intended purpose of the safety-critical processor-based signal and train control system. All contractual agreements with suppliers of safety-critical hardware and software have the following contractual language (or similar):

1. Upon receipt of a report of any safety-critical failure to their Product, Seller shall promptly notify Metrolink and all other railroads that are using that Product, whether or not Metrolink or any other railroads have experiences the reported failure of that safety-critical system, subsystem, or component.

2. The notification from Seller to Metrolink or any other railroad will include explanation from the Seller of the reasons for such notification, the circumstances associated with the failure, and recommended mitigation actions to be taken pending determination of the root cause and final corrective actions.

33.3 Use of Hazard Log for Tracking It is Metrolink’s intention to utilize a common Hazard Log view, jointly, with collaborating railroads that are using the I-ETMS system as a means to capture and resolve subsequent system related hazards industry wide. Because this document is shared, the Hazard Log is a Configurable Item (CI) under the governance of Industry Configuration Management. For details on the Configuration Management process for industry CIs see Appendix O. The communication of safety relevant failures, defective conditions, or previously unidentified hazards is shown in Figure 33-1 below. SCRRA is able to enter items in the Wabtec system directly for common items, and also will



maintain any SCRRA specific hazard items in the SCRRA specific Hazard Log. To date, no SCRRA specific hazards have been identified during the ERSD operation.



Figure 33-1 I-ETMS Hazard Log Management Process



Steps 1a/1b through Step 5 involves the identification, notification, and triage of safety relevant failures, defective conditions, or previously unidentified hazards. The notification of safety relevant failures, defective conditions, or previously unidentified hazards varies depending on whether or not the defect is identified by a railroad or by a vendor. In either case, the railroad is responsible for notifying the FRA that a safety relevant failure, defective condition, or previously unidentified hazard has been discovered and the vendor is responsible for notifying the FRA of the list of railroads that are potentially impacted by that defect. Steps 6 and 7 deal with hazard mitigation identification. Once mitigation for the defect is found, the affected railroads must agree that the mitigation is appropriate and sufficient. After the mitigation is accepted, Steps 8 and 9 go through the Industry Configuration Management Process as described in Appendix O of this PTCSP. When notified of a potential safety-critical defect, Metrolink’s PTC Team conducts safety reviews to understand the root cause, logs the defect in the database of safety-relevant hazards, analyzes the hazard against the common I-ETMS Hazard Log to determine if the hazard has been previously identified and manages the required notifications and safety case updates. The safety analysis tasks in this process are led by the PTC Team, and conducted by the Metrolink subject matter experts, including safety staff responsible for the PTC safety case. The process is supported by Metrolink’s use of the RailRiskTM PTC Incident Reporting System (www.railrisk.com). RailRiskTM is a common database and analysis process used by the majority of the I-ETMS users to provide an industry wide approach to evaluate and resolve safety-relevant hazards. It supports the analyses required to identify notification requirements and perform safety case updates. Since there have been no Metrolink unique hazards identified, the Metrolink Hazard Log is merely a subset of the common I-ETMS Hazard Log with hazards associated with functions not used by Metrolink eliminated. This assists in configuration control since any analyses or required hazard log modifications can be done to the I-ETMS Hazard Log and then an updated version of the Metrolink subset can be extracted. Required notifications will include applicable information, such as PTC system name and model; identification of the part, component, or system involved, including the part number as applicable; the nature of the failure, malfunctions, or defective condition; any mitigation taken to ensure the safety of the train operation, railroad employees, and the public; and the estimated time to correct the failure. Metrolink will submit notifications to vendors through their designated points of contact and will transmit the required notifications to FRA in a manner and form acceptable to the Associate Administrator and by the most expeditious method available. When Metrolink identifies any PTC failure that results in a more favorable aspect than intended or other condition hazardous to the movement of a train, Metrolink will comply


http://www.railrisk.com/


with the reporting requirements of 49CFR 233. When required, these reporting requirements are fulfilled in addition to the other PTC-specific notification requirements of 49CFR 236.1023.

33.4 PTC System Vendor Quality Control System [§236.1015(b)] Each Metrolink PTC equipment vendor as listed in the PTCPVL has been determined to have and follow an appropriate quality control system. Vendors who deviate from an acceptable quality control system will be eliminated from the PTCPVL and replaced by others. Only two equipment vendors provide safety-critical equipment to Metrolink:

1. Wabtec Railway Electronics

2. Alstom Transportation (formerly GE Transportation Systems)

These vendors have been vetted by SCRRA procurement to have appropriate quality systems in place, particularly ISO 9001 equivalent quality management systems. It is the task of SCRRA procurement to periodically refresh the contact with vendor quality groups to determine if the vendor’s quality system remains acceptable to SCRRA. Other equipment supplied to Metrolink as part of the PTC system is not generally considered safety critical by function and must meet applicable AAR or AREMA standards for quality and performance.



34 Role of Office Automation Systems in the PTC System [§236.1027(a)] <Reserved>

The current design of the Dispatch system (including CAD) for Metrolink is independent of the BOS of the I-ETMS PTC system. There is no role of the Dispatch system in PTC office automation as per the I-ETMS design, and no description of the role of PTC Office Automation Systems is necessary in the PTCSP. The Dispatch system does not have new or modified commands that pertain exclusively to PTC operation. Existing actions and procedures are utilized by the dispatchers for train movement control. Therefore, the PTC operation remains primarily transparent to the dispatching function. The only PTC functions that can impact the dispatching function are the display of certain PTC alarms to the dispatcher. The process for interpreting these alarms is part of the Operating & Maintenance Manual and the training course provided to the dispatchers. Metrolink has included all the impacts to CAD from PTC in the “PTC Supplement to the Train Dispatcher’s Manual” which is addressed in Appendix L of this PTCSP. The CAD system provides its own conflict checking for dispatcher requests, which is vetted on a daily basis during normal operation. The PTC system also verifies CAD transmissions to PTC using the BOS Transformation Check process.



35 Novel Technology Employed in Highway Crossing Protection for PTC [§234.275(c)] <Reserved>

This section explains how the new and novel highway crossing protection performance objective is met by this product, why the objective is not relevant to this product’s design, or how the safety requirements are satisfied using alternative means as required by 49CFR 236, Subpart I, §234.275(c).

Highway-railway grade crossing warning systems will not be modified to provide safety-critical data to I-ETMS and, accordingly, 49CFR §234.275(c) is not applicable to Metrolink I-ETMS.

The Metrolink I-ETMS does not include any PTC-controlled crossing subsystems and PTC does not interface to any existing crossing subsystems.

Note that I-ETMS does provide protection for highway grade crossing system malfunctions through the enforcement of mandatory directives issued by the dispatcher for Activation Failures and False/Partial Activation.



36 List of Appendices

Several appendices to this document contain confidential information that constitutes trade secrets and other proprietary information that is exempt from the mandatory disclosure requirements of the Freedom of information Act (5 U.S.C. § 552) (FOIA). A Redaction Matrix has been included with the Delta and Confidential versions of the Appendices document. This Matrix provides justification for the information that has been redacted from the documents. Test Plans and Reports have been previously submitted to the FRA via the Secure Information Repository (SIR) and are marked as Available Upon Request. Additionally, relatively small segments of the Appendices contain information that qualifies as Sensitive Security Information (SSI) under 49CFR Parts 15 and 1520. These SSI documents have been on an individual page basis with the required conspicuous markings and warnings.

Appendix A Safety Assurance Concepts Appendix B Type Approval For I-ETMS and PTCDP Appendix C Final Human Factor Analysis Appendix D I-ETMS Hazard Log Appendix E MTTHE Calculations Appendix F Risk Assessment Final Report Appendix G Safety Analysis Documentation Appendix H Safety Verification Appendix I Lab Safety Verification Test Procedures Appendix J Lab Safety Verification Test Results Appendix K Metrolink Training Plan Appendix L Metrolink Operations and Maintenance Manual Appendix M PTC System Implementation Field Functionality Test Plans and

Procedures Appendix N PTC System Field Functionality Test Results Appendix O Industry Configuration Management Plan Appendix P Configuration Control and Record Retention Appendix Q Integration of Hazard Detectors Appendix R Management Plan for Emergency/Maintenance Rerouting of Trains

on PTC Territory <reserved> Appendix S Communication Restoration Plan Appendix T Test Equipment for PTC (included in Appendix L) Appendix U Initial Implementation Test Procedures Appendix V WIU Safety Case Appendix W Post-Implementation Safety Testing and Monitoring Plans and

Processes Appendix X PTC Data Captured in Event Recorder (I-ETMS Logging –

Recording Data Dictionary) Appendix Y Licensing Information <Reserved>



Appendix Z Safety Audits Appendix AA Novel Technology Employed in Highway Crossing Protection for

PTC <reserved> Appendix BB Warnings and Warning Labels Appendix CC Metrolink Security Management Plan Appendix DD Protection of Wireless Communications Appendix EE Service Restoration Plan Appendix FF Parsons System Reliability Study Appendix GG System Safety Integration Document Appendix HH System Safety Program Plan Appendix II <Reserved> Appendix JJ Track Database Verification and Validation Plan Appendix KK Track Database Verification and Validation Reports <Reserved> Appendix LL I-ETMS Configurable Items (RR Common & Specific) Appendix MM PTC Product Vendor List Appendix NN Justification for Non-Vital Emergency Brake Control



37 Redaction Matrix

This matrix, shown as Table 37-1 provides justification for the redaction of documentation from public disclosure as provided in the Metrolink PTCSP Appendices submitted to FRA. The redacted documents will be supplied with the public version of this PTCSP. The following Redaction Codes are used for justification for the redaction of information from the Appendices: 5 U.S.C. §552 (b)(4) CI

• This code refers to the Commercial or Financial Information prong of FOIA Exemption 4.

5 U.S.C. §552 (b)(4) CH

• This redaction code refers to the Competitive Harm prong of FOIA Exemption 4.

49CFR §15 & §1520 SSI

• This redaction code refers to records containing Sensitive Security Information that is controlled under 49CFR Parts 15 and 1520.



Table 37-1 Redaction Matrix

Appendix

Redacted Sections Redaction Code

Redaction Justification

Appendix A - Safety Assurance Concepts WCR-SAF-1365; Rev. H; 10/14/2015

Safety Assurance Techniques identified in Table 1

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH

This appendix contains third party proprietary information subject to protection under Intellectual Property and other laws. This redaction consists of information that directly identifies designs, principles, or techniques that have been established by the vendor. Release of this information would constitute the exchange of vendor trade secret information and could be used to reverse engineer to create an understanding of the design that makes the system unique to the vendor. This appendix also contains information whose disclosure to competition would place the vendor at an unfair business disadvantage.

Appendix B - Type Approval Letters For I-ETMS and I-ETMS PTCDP

None n/a n/a – These are public documents

Appendix C - Final Human Factor Analysis HEADING ONLY n/a n/a

Appendix C.1 - Final Human Factor Analysis of CDU for I-ETMS I-ETMS Positive Train Control Human Factors Evaluation; with Railroad Responses; V.1.4; 11/26/2013

Entire Document per distribution agreement with JRST

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH

This appendix contains third party proprietary information subject to protection under Intellectual Property and other laws. This redaction consists of information that directly identifies designs, principles, or techniques that have been established by the vendor. Release of this information would constitute the exchange of vendor trade secret information and could be used to reverse engineer to create an understanding of the design that makes the system unique to the vendor. This appendix also contains information whose disclosure to competition



Appendix



would place the vendor at an unfair business disadvantage.

Appendix C.2 - Final Human Factor Analysis of CDU Mounting for Metrolink Metrolink Human Factors/Ergonomic Evaluation of CDU Placement; Rev. 1; February 21, 2012

None n/a n/a

Appendix D - I-ETMS Hazard Log HEADING ONLY n/a n/a

Appendix D.a - I-ETMS Hazard Log, Hazard Log Rev J

None n/a n/a

Appendix D.b - Hazard Log Table 35a6.Metrolink

Hazard Description, Hazard Source Faults or Errors, Required Mitigation, Expected Residual Risk Index, Mitigation Reference, Mitigation Method, and Mitigation Verification Reference columns.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix D.1.a OSCAR_LIST/ I-ETMS Operating & Support Hazard Mitigation Review Tabulation

None n/a n/a

Appendix D.1.b - Metrolink OSCAR Verification Document

None n/a n/a

Appendix D.2.a Safety Requirements Safety Requirement 5 U.S.C. §552 This appendix contains third party proprietary



Appendix



Document WCR-SAF- 1366; Rev. J; 10/15/2015

Descriptions, Safety Requirement Text, OSCAR Requirement Text, and all Safety Requirement associations with implementing system requirements as listed in the tables and appendices included in the document.

(b)(4) CI 5 U.S.C. §552 (b)(4) CH

information subject to protection under Intellectual Property and other laws. This redaction consists of information that directly identifies designs, principles, or techniques that have been established by the vendor. Release of this information would constitute the exchange of vendor trade secret information and could be used to reverse engineer to create an understanding of the design that makes the system unique to the vendor. This appendix also contains information whose disclosure to competition would place the vendor at an unfair business disadvantage.

Appendix D.2.b - Safety Requirements Document Appendix RP1.0030 Dated 09/06/2013

Safety Requirement Descriptions, Safety Requirement Text, OSCAR Requirement Text, and all Safety Requirement associations with implementing system requirements as listed in the tables and appendices included in the document.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix D.3 I-ETMS Safety Critical Requirement Verification and Validation Report, Rev 1.0; 10/23/2015

Internal Configuration Management description Section 4

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH

This appendix contains third party proprietary information subject to protection under Intellectual Property and other laws. This redaction consists of information that directly identifies designs, principles, or techniques that have been established by the vendor. Release of this information would constitute the exchange of vendor trade secret



Appendix



information and could be used to reverse engineer to create an understanding of the design that makes the system unique to the vendor. This appendix also contains information whose disclosure to competition would place the vendor at an unfair business disadvantage.

Appendix E - MTTHE Calculations Entire Appendix 5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix F - Risk Assessment Final Report Revision 1.2; 11/12/2015

Document content that specifically identifies or reveals design details of the system.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH

This appendix contains third party proprietary information subject to protection under Intellectual Property and other laws. This redaction consists of information that directly identifies designs, principles, or techniques that have been established by the vendor. Release of this information would constitute the exchange of vendor trade secret information and could be used to reverse engineer to create an understanding of the design that makes the system unique to the vendor. This appendix also contains information whose disclosure to competition would place the vendor at an unfair business



Appendix



disadvantage.

Appendix G - Safety Analysis Documentation

HEADING ONLY n/a n/a

Appendix G.1 - I-ETMS Preliminary Hazard Analysis (PHA), I-ETMS Preliminary Hazard Assessment (PHA); Rev K; August 17, 2013

Hazard Source Faults or Errors column entries for PHA items that pertain specifically to segment level failures.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix G.2 - Locomotive Segment Subsystem Hazard Analysis (LSSHA), I-ETMS Locomotive Segment Subsystem Hazard Analysis (LSSHA); WCR-SAF-1356; Rev. M; 10/28/2015

All Hazard Source Faults or Errors and those Hazard Descriptions that pertain specifically to segment level failures.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix G.3 - Office Segment Subsystem Hazard Analysis (OSSHA), I-ETMS Office

All Hazard Source Faults or Errors and those

5 U.S.C. §552 (b)(4) CI

This appendix contains third party proprietary information subject to protection under



Appendix



Segment Subsystem Hazard Analysis (OSSHA); WCR-SAF-1456; Rev. E; 10/28/2015

Hazard Descriptions that pertain specifically to segment level failures.

5 U.S.C. §552 (b)(4) CH

Intellectual Property and other laws. This redaction consists of information that directly identifies designs, principles, or techniques that have been established by the vendor. Release of this information would constitute the exchange of vendor trade secret information and could be used to reverse engineer to create an understanding of the design that makes the system unique to the vendor. This appendix also contains information whose disclosure to competition would place the vendor at an unfair business disadvantage.

Appendix G.4 – O&SHA: Metrolink I-ETMS PTC System Operating and Support Hazard Analysis, Operating & Support Hazard Analysis (O&SHA); Revision 2.0

“Requirements Description” 5 U.S.C. §552

(b)(4) CH

These sections contain information pertaining to SCRRA’s operational and support tasks performed by SCRRA personnel and contractors. The information contained within this appendix has intrinsic commercial value as it represents the output and description of SCRRA’s analysis. Release of such information would constitute the exchange of trade secret information and could result in a competitive disadvantage to SCRRA.

Appendix G.5 – FFT: Functional Fault Tree, I-ETMS Functional Fault Trees (FFT); Rev D; June 15, 2011

Probabilities and all segment level detail on pages 1-313.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH

This appendix contains third party proprietary information subject to protection under Intellectual Property and other laws. This redaction consists of information that directly identifies designs, principles, or techniques that have been established by the vendor. Release of this information would constitute the exchange of vendor trade secret information and could be used to reverse engineer to create an understanding of the design that makes the system unique to the vendor.



Appendix



Appendix G.6 – FTA: Fault Tree Analysis –, I-ETMS Fault Tree Analysis (FTA); Rev C; June 17, 2011

Basic event description tables and majority of Appendix A material, all related to segment level failure analysis.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix G.7 – FMEA: HEADING ONLY

Appendix G.7.a EBI-300 Piece Part FMEA FMEA Detail TMC-04; WCR-SAF- 1356; Rev. F; 10/16/2015

Category, Function, Sub Function, Sub Function Effect, Function Effect, Potential Effect, Failure Rate, Failure Occurrence %, Failure Rate, and Current System Function Failure Control/Detection columns

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix G.7.b Failure Mode Table, FMEA Failure Mode Distribution TMC-04; WCR-SAF-1356; Rev. F; 10/16/2015

Component Failure Mode Distribution Column

5 U.S.C. §552 (b)(4) CH

This appendix contains third party proprietary information subject to protection under Intellectual Property and other laws. This confidential information is the compilation of vendor work product whose disclosure to competition would place the vendor at an unfair business disadvantage.



Appendix



Appendix G.7.c EBI-300 FMEA Summary, FMEA Summary TMC-04; WCR-SAF- 1356; Rev. F; 10/16/2015

Category, Function, Sub Function, Sub Function Effect, Function Effect, Potential Effect, Failure Rate, Failure Occurrence %, Failure Rate, and Current System Function Failure Control/Detection columns

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix G.8 – Platform Analysis: I-ETMS® TMC Platform Safety Analysis, I-ETMS TMC Platform Safety Analysis (PSA); WCR-SAF-1356; Rev. F; 11/10/2015

Document content that specifically identifies or reveals design details of the system.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix G.9 – System SHA All probabilities, basic event descriptions, and related analysis.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH

This appendix contains third party proprietary information subject to protection under Intellectual Property and other laws. This redaction consists of information that directly identifies designs, principles, or techniques that have been established by the vendor. Release of this information would constitute



Appendix



the exchange of vendor trade secret information and could be used to reverse engineer to create an understanding of the design that makes the system unique to the vendor.

Appendix G.10 – Environmental Tests: I-ETMS TMC Summary of EQT

Environmental Test Parameters

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix G.11 - I-ETMS Electromagnetic Interference Test Summary (EMI)

Specific hardware requirements.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH




Appendix



Appendix H - Safety Verification HEADING ONLY n/a n/a

Appendix H.1 – I-ETMS Master Test Strategy, RP-9457 I-ETMS Master Test Strategy, Adopted 2012

None n/a n/a

Appendix H.2.a - Safety Verification Plan, I-ETMS Locomotive Segment Software Verification and Validation Plan; Revision 1.2; 08/28/2014

Document content that specifically identifies or reveals design details of the system. This includes detailed description and format of data.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix H.2.b I-ETMS TMDS Use Cases I-ETMS TMDS Use Cases; Rev. 1.9; 11/17/2014

All sections except introduction that contain proprietary information.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix H.2.c CAD-BOS-TMC Test Report, Test Results: CAD-BOS-TMC End-to-End Tests; Revision 02-01;

None n/a n/a



Appendix



06/18/2015

Appendix I - Lab Safety Verification Test Plans and Procedures:


Appendix I.1 Sample Lab Test Procedure Book 1 ML.INT53 – Verify Initialization Sequence With Success – Without Departure Test

All documents in their entirety.

49CFR §15 & §1520 SSI

Test processes reveal specific prompt and response sequences and methodologies. This information could be used to compromise system integrity, or “spoof” the system should security be breached, and is considered Sensitive Security Information.

Appendix I.2 Sample Lab Test Procedure Book 2 ML.SGL3 – Absolute Stop Enforcement

All documents in their entirety.

49CFR §15 & §1520 SSI


Appendix I.3 Lab Safety Verification Test Procedures - references other documents available on request from SCRRA

None n/a n/a

Appendix J - Lab Safety Verification Test Results:


Appendix J.1 Sample Lab Test Report Book 1 ML.INT19 – Verify Locomotive Movement During Crew Logon Process – Employee ID Screen

Entire Document 49CFR §15 & §1520 SSI

Test processes and results reveal specific prompt and response sequences and methodologies. This information could be used to compromise system integrity, or “spoof” the system should security be breached, and is considered Sensitive Security Information

Appendix J.2 Sample Lab Test Report Book 2 ML.SGL3 – Dark Intermediate


Test processes and results reveal specific prompt and response sequences and methodologies. This information could be



Appendix



Within T&T Enforcement used to compromise system integrity, or “spoof” the system should security be breached, and is considered Sensitive Security Information

Appendix J.3 Lab Safety Verification Test Reports - references other documents available on request from SCRRA

None n/a n/a

Appendix K - Metrolink Training Plan HEADING ONLY n/a n/a

Appendix K.1 - Metrolink Positive Train Control System Training Plan, Metrolink I-ETMS PTC Training Plan; Rev. 3.0; Dec, 15, 2015

None

n/a n/a

Appendix K.2 – PTC Training Material – references other training documents available on request from SCRRA

None n/a n/a

Appendix L - Metrolink Operations and Maintenance Manual: - documents comprising the OMM are available on request from SCRRA.

None n/a n/a

Appendix M - PTC System Implementation Field Functionality Test Plans and Procedures


Appendix M.1 - Approved FIT-FQT Test Procedures, Book 1





Appendix



Appendix M.2 Approved FIT-FQT Test Procedures, Book 2


Test processes reveal specific prompt and response sequences and methodologies. This information could be used to compromise system integrity, or “spoof” the system should security be breached and is considered Sensitive Security Information, and is considered Sensitive Security Information.

Appendix N – PTC System Field Functionality Test Results:


Appendix N.1 I-ETMS FIT/FQT Test Procedures Book 1 of 2; MP36 Locomotive; ML-DPT13


Test processes and results reveal specific prompt and response sequences and methodologies. This information could be used to compromise system integrity, or “spoof” the system should security be breached, and is considered Sensitive Security Information.

Appendix N.2 I-ETMS FIT/FQT Test Procedures Book 2 of 2; Rotem Cab Car; ML-SGL18


Test processes and results reveal specific prompt and response sequences and methodologies. This information could be used to compromise system integrity, or “spoof” the system should security be breached, and is considered Sensitive Security Information.

Appendix O - Industry Configuration Management Plan: ITC Industry PTCSP CM Draft V2.3; 07/13/2015

None n/a n/a

Appendix P - Configuration Control and Record Retention




Appendix



Appendix P.1 Metrolink Positive Train Control Configuration & Change Management; Version 1.1; May 23, 2014

-

None n/a n/a

Appendix P.2.a - Metrolink Record Retention Policy: SCRRA Administrative Policies and Procedures manual No. ADM-4; Revision 1; 12/01/07

None n/a n/a

Appendix P.2.b Attachment A; SCRRA Records Retention Schedule; Rev. 6; 09/30/09

None n/a n/a

Appendix Q – Integration of Hazard Detectors: Signal Circuit Plan; CP Las Posas – CP Madera; VN 426-432; Sheets 5&6

None n/a n/a

Appendix R - Management Plan for Emergency/Maintenance Rerouting of Trains on PTC Territory <reserved>

None n/a n/a

Appendix S - Communication Service Restoration Plan

None n/a n/a

Appendix T - Test Equipment for PTC:

<Reserved>

None n/a n/a

Appendix U - Initial Implementation Test Procedures: <Reserved>

None n/a n/a

Appendix V - WIU Safety Case: HEADING ONLY n/a n/a



Appendix



Appendix V.1 -EC4 Product Safety Management & MTTHE; Document 083140-160; Revision A02; July 3, 2014

None n/a n/a

Appendix V.2 EL1A Product Safety Management & MTTHE; Document 083141-160; Revision A02; July 3, 2014

None n/a n/a

Appendix V.3 ElectroLogIXS Product Safety Management & MTTHE; Document 082806-908; Revision A02; July 3, 2014

None n/a n/a

Appendix V.4 ElectroLogIXS FRA 236 Exclusion Letter; May 12, 2006

None n/a n/a

Appendix W - Post-Implementation Safety Testing and Monitoring Plans and Processes


Appendix W.1 I-ETMS On-board System Inspection, Test, and Maintenance Recommendations; Document ID: WCR-MAN-1056; January 18, 2013

None n/a n/a

Appendix W.2 PTC System Anomaly Analysis Procedure; SCRRA-PTC-PROC-0100; 12/08/2015

None n/a n/a

Appendix X - PTC Data Captured in Event Recorder: I-ETMS Logging/Recording Data Dictionary; Document No. WCR-SYR-1057; Revision 1.6; 5.9.2014

Document content that specifically identifies or reveals design details of the system. This includes detailed description and format of data records and

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH

This appendix contains third party proprietary information subject to protection under Intellectual Property and other laws. This redaction consists of information that directly identifies designs, principles, or techniques that have been established by the vendor.



Appendix



requirements for records to be logged and recorded.

Release of this information would constitute the exchange of vendor trade secret information and could be used to reverse engineer to create an understanding of the design that makes the system unique to the vendor. This appendix also contains information whose disclosure to competition would place the vendor at an unfair business disadvantage.

Appendix Y - Licensing Information <reserved>

N/A n/a n/a

Appendix Z - Safety Audits:


Appendix Z.1 Turner Engineering Corporation (Tenco) Software Development Process Audit; May 14, 2014

None n/a n/a

Appendix Z.2 CMMI Institute Appraisal Results of PARSONS PTC program; June 24, 2014

None n/a n/a

Appendix Z.3 Parsons-Metrolink PTC System Subcontractor Audit Log;

None n/a n/a

Appendix AA - Novel Technology Employed in Highway Crossing Protection for PTC <reserved>

None n/a n/a

Appendix BB - Warning Labels: Warnings and Warning Labels [§236.1015(d)(8)]

None n/a n/a

Appendix CC - Metrolink Security HEADING ONLY n/a n/a



Appendix



Management Plan:

Appendix CC.1 SCRRA PTC System Security Framework

All documents in their entirety

49CFR §15 & §1520 SSI

This appendix contains specific information pertaining to the PTC security methods and procedures. This in conjunction with other data could potentially enable manipulation of safety critical systems and is considered Sensitive Security Information.

Appendix CC.2 PTC Security Clearance Plan; Rev. 0.2; June 1, 2015


49CFR §15 & §1520 SSI


Appendix CC.3 Metrolink PTC System Security Concepts (SSC); Revision 1.0; April, 2015


49CFR §15 & §1520 SSI


Appendix DD - Protection of Wireless Communications: Individual and Composite CRC Calculator (IC3) Design Summary; Doc. No. WCR-DZN-1305, Revision 1.0; 2/19/2015


5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH




Appendix



Appendix EE - Service Restoration Plan None n/a n/a

Appendix FF - Parsons System Reliability Study: Reliability Report – July 2015; Rev 0; 10/2/2015

None n/a n/a

Appendix GG - System Safety Integration Document System Safety Integration Document (SSID); Revision F; 12/29/2014

Document describes proprietary concepts in all sections– and is redacted in its entirety.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix HH - System Safety Program Plan I-ETMS System Safety Program Plan (SSPP); WCR-SAF-1357; Rev I; 10/28/2015

Document content that provides information regarding vendor-specific system safety assessment processes, techniques, and artifacts.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH




Appendix



Appendix II - Interoperable Train Control Messaging Requirements <Reserved>

None n/a n/a

Appendix JJ – Track Database V&V Plans: Metrolink Track Database Development, Verification and Validation Procedure; Version 0.3; May 23, 2012



Appendix KK -Track Database V&V Reports


Appendix KK.1 San Gabriel Subdivision Signal (WIU) V&V Track Verify Report



Appendix KK.2 San Gabriel Subdivision Signal (WIU) V&V Test Report



Appendix KK.3 – references other verification documents available on request from SCRRA

n/a n/a n/a

Appendix LL – Configurable Parameters HEADING ONLY n/a n/a

Appendix LL.1 I-ETMS Configurable Parameter Assessment; Rev 1.5; 9/24/2015

Entire Document 5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH

This appendix contains third party proprietary information subject to protection under Intellectual Property and other laws. This redaction consists of information that directly identifies designs, principles, or techniques that have been established by the vendor. Release of this information would constitute the exchange of vendor trade secret



Appendix



information and could be used to reverse engineer to create an understanding of the design that makes the system unique to the vendor. This appendix also contains information whose disclosure to competition would place the vendor at an unfair business disadvantage.

Appendix LL.2 I-ETMS Parameters Configuration Guide; SCRRA-PTC-GDE-0101 Rev 1.14; 8/20/2015

Entire Document 5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH


Appendix LL.3 –Metrolink Specific I-ETMS Parameter Configuration Guide System; Rev 1.0; 12/7/2015

Configuration parameters refer to proprietary design information and are redacted.

5 U.S.C. §552 (b)(4) CI 5 U.S.C. §552 (b)(4) CH

This appendix contains third party proprietary information subject to protection under Intellectual Property and other laws. This redaction consists of information that directly identifies designs, principles, or techniques that have been established by the vendor. Release of this information would constitute the exchange of vendor trade secret information and could be used to reverse engineer to create an understanding of the design that makes the system unique to the vendor. This appendix also contains information whose disclosure to competition would place the vendor at an unfair business



Appendix



disadvantage. Appendix MM - PTC Product Vendor List (PTCPVL)

None n/a n/a

Appendix NN - Justification for Non-Vital Emergency Brake Justification of Non-Vital Implementation of Emergency Brake; Doc. No. WCR-SAF-1236; Revision B;

None n/a n/a

END OF DOCUMENT


SCRRA/Metrolink Interoperable Electronic Train Management ...

Documents

Transcript of SCRRA/Metrolink Interoperable Electronic Train Management ...