49 C.F.R. Appendix C to Part 236—Safety Assurance Criteria and Processes
Title 49 - Transportation
(a) What is the purpose of this appendix? This appendix seeks to promote full disclosure of safety risk to facilitate minimizing or eliminating elements of risk where practicable by providing minimum criteria and processes for safety analyses conducted in support of PSPs. The analysis required by this appendix is intended to minimize the probability of failure to an acceptable level, helping to optimize the safety of the product within the limitations of the available engineering science, cost, and other constraints. FRA uses the criteria and processes set forth in this appendix to evaluate analyses, assumptions, and conclusions provided in RSPP and PSP documents. An analysis performed under this appendix must: (1) Address each area of paragraph (b) of this appendix, explaining how such objectives are addressed or why they are not relevant, and (2) Employ a validation and verification process pursuant to paragraph (c) of this appendix. (b) What categories of safety elements must be addressed? The designer shall address each of the following safety considerations when designing and demonstrating the safety of products covered by subpart H of this part. In the event that any of these principles are not followed, the PSP 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. (1) Normal operation. The system (including all hardware and software) must demonstrate safe operation with no hardware failures under normal anticipated operating conditions with proper inputs and within the expected range of environmental conditions. All safety-critical functions must be performed properly under these normal conditions. Absence of specific operator actions or procedures will not prevent the system from operating safely. There must be no hazards that are categorized as unacceptable or undesirable. Hazards categorized as unacceptable must be eliminated by design. (2) Systematic failure. It must be shown how the product is designed to mitigate or eliminate unsafe systematic failures—those conditions which can be attributed to human error that could occur at various stages throughout product development. This includes unsafe errors in the software due to human error in the software specification, design or coding phases, or both; human errors that could impact hardware design; unsafe conditions that could occur because of an improperly designed human-machine interface; installation and maintenance errors; and errors associated with making modifications. (3) Random failure. (i) The product must be shown to operate safely under conditions of random hardware failure. This includes single as well as multiple hardware failures, particularly in instances where one or more failures could occur, remain undetected (latent) and react in combination with a subsequent failure at a later time to cause an unsafe operating situation. In instances involving a latent failure, a subsequent failure is similar to there being a single failure. In the event of a transient failure, and if so designed, the system should restart itself if it is safe to do so. Frequency of attempted restarts must be considered in the hazard analysis required by §236.907(a)(8). (ii) There shall be no single point failures in the product that can result in hazards categorized as unacceptable or undesirable. Occurrence of credible single point failures that can result in hazards must be detected and the product must achieve a known safe state before falsely activating any physical appliance. (iii) 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 before falsely activating any physical appliance. (4) Common Mode failure. Another concern of multiple failure involves common mode failures 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 unsafe conditions. This is of particular concern in instances in which two or more elements (hardware or software, or both) are used in combination to ensure safety. If a common mode failure exists, then any analysis performed under this appendix cannot rely on the assumption that failures are independent. Examples include: the use of redundancy in which two or more elements perform a given function in parallel and when one (hardware or software) element checks/monitors another element (of hardware or software) to help ensure its safe operation. Common mode failure relates to independence, which must be ensured in these instances. When dealing with the effects of hardware failure, the designer shall address the effects of the failure not only on other hardware, but also on the execution of the software, since hardware failures can greatly affect how the software operates. (5) External influences. The product must be shown to operate safely when subjected to different external influences, including: (i) Electrical influences such as power supply anomalies/transients, abnormal/improper input conditions (e.g., outside of normal range inputs relative to amplitude and frequency, unusual combinations of inputs) including those related to a human operator, and others such as electromagnetic interference or electrostatic discharges, or both; (ii) Mechanical influences such as vibration and shock; and (iii) Climatic conditions such as temperature and humidity. (6) Modifications. Safety must be ensured following modifications to the hardware or software, or both. All or some of the concerns identified in this paragraph may be applicable depending upon the nature and extent of the modifications. (7) Software. Software faults must not cause hazards categorized as unacceptable or undesirable. (8) Closed Loop Principle. The product design must require positive action to be taken in a prescribed manner to either begin product operation or continue product operation. (9) Human Factors Engineering: The product design must sufficiently incorporate human factors engineering that is appropriate to the complexity of the product; the educational, mental, and physical capabilities of the intended operators and maintainers; the degree of required human interaction with the component; and the environment in which the product will be used. (c) What standards are acceptable for verification and validation? (1) The standards employed for verification or validation, or both, of products subject to this subpart must be sufficient to support achievement of the applicable requirements of subpart H of this part. (2) U.S. Department of Defense Military Standard (MIL-STD) 882C, “System Safety Program Requirements” (January 19, 1993), is recognized as providing appropriate risk analysis processes for incorporation into verification and validation standards. (3) The following standards designed for application to processor-based signal and train control systems are recognized as acceptable with respect to applicable elements of safety analysis required by subpart H of this part. The latest versions of the standards listed below should be used unless otherwise provided. (i) IEEE 1483–2000, Standard for the Verification of Vital Functions in Processor-Based Systems Used in Rail Transit Control. (ii) CENELEC Standards as follows: (A) EN50126: 1999, Railway Applications: Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS); (B) EN50128 (May 2001), Railway Applications: Software for Railway Control and Protection Systems; (C) EN50129: 2003, Railway Applications: Communications, Signaling, and Processing Systems-Safety Related Electronic Systems for Signaling; and (D) EN50155:2001/A1:2002, Railway Applications: Electronic Equipment Used in Rolling Stock. (iii) ATCS Specification 140, Recommended Practices for Safety and Systems Assurance. (iv) ATCS Specification 130, Software Quality Assurance. (v) AAR-AREMA 2005 Communications and Signal Manual of Recommended Practices, Part 17. (vi) Safety of High Speed Ground Transportation Systems. Analytical Methodology for Safety Validation of Computer Controlled Subsystems. Volume II: Development of a Safety Validation Methodology. Final Report September 1995. Author: Jonathan F. Luedeke, Battelle. DOT/FRA/ORD–95/10.2. (vii) IEC 61508 (International Electrotechnical Commission), Functional Safety of Electrical/Electronic/Programmable/Electronic Safety (E/E/P/ES) Related Systems, Parts 1–7 as follows: (A) IEC 61508–1 (1998–12) Part 1: General requirements and IEC 61508–1 Corr. (1999–05) Corrigendum 1-Part 1:General Requirements. (B) IEC 61508–2 (2000–05) Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems. (C) IEC 61508–3 (1998–12) Part 3: Software requirements and IEC 61508–3 Corr.1(1999–04) Corrigendum 1-Part3: Software requirements. (D) IEC 61508–4 (1998–12) Part 4: Definitions and abbreviations and IEC 61508–4 Corr.1(1999–04) Corrigendum 1-Part 4: Definitions and abbreviations. (E) IEC 61508–5 (1998–12) Part 5: Examples of methods for the determination of safety integrity levels and IEC 61508–5 Corr.1 (1999–04) Corrigendum 1 Part 5: Examples of methods for determination of safety integrity levels. (F) IEC 61508–6 (2000–04) Part 6: Guidelines on the applications of IEC 61508–2 and –3. (G) IEC 61508–7 (2000–03) Part 7: Overview of techniques and measures. (4) Use of unpublished standards, including proprietary standards, is authorized to the extent that such standards are shown to achieve the requirements of this part. However, any such standards shall be available for inspection and replication by FRA and for public examination in any public proceeding before the FRA to which they are relevant. [70 FR 11106, Mar. 7, 2005]
Title 49: Transportation
PART 236—RULES, STANDARDS, AND INSTRUCTIONS GOVERNING THE INSTALLATION, INSPECTION, MAINTENANCE, AND REPAIR OF SIGNAL AND TRAIN CONTROL SYSTEMS, DEVICES, AND APPLIANCES
Subpart H—Standards for Processor-Based Signal and Train Control Systems
Appendix C to Part 236—Safety Assurance Criteria and Processes
