(a) Except as provided in paragraph (b) of this section, this part applies to all railroads and any person as defined in paragraph (f) of this section.

(b) This part does not apply to—

(1) A railroad that operates only on track inside an installation that is not part of the general railroad system of transportation; or

(2) Rapid transit operations in an urban area that are not connected to the general railroad system of transportation.

(c)(1) Prior to January 17, 2012, where a passenger train is operated at a speed of 60 or more miles per hour, or a freight train is operated at a speed of 50 or more miles per hour—

(i) A block signal system complying with the provisions of this part shall be installed; or

(ii) A manual block system shall be placed permanently in effect that shall conform to the following conditions:

(A) A passenger train shall not be admitted to a block occupied by another train except when absolutely necessary and then only by operating at restricted speed;

(B) No train shall be admitted to a block occupied by a passenger train except when absolutely necessary and then only by operating at restricted speed;

(C) No train shall be admitted to a block occupied by an opposing train except when absolutely necessary and then only while one train is stopped and the other is operating at restricted speed; and

(D) A freight train, including a work train, may be authorized to follow a freight train, including a work train, into a block and then only when the following train is operating at restricted speed.

(2) On and after January 17, 2012, where a passenger train is permitted to operate at a speed of 60 or more miles per hour, or a freight train is permitted to operate at a speed of 50 or more miles per hour, a block signal system complying with the provisions of this part shall be installed, unless an FRA approved PTC system meeting the requirements of this part for the subject speed and other operating conditions is installed.

(d)(1) Prior to December 31, 2015, where any train is permitted to operate at a speed of 80 or more miles per hour, an automatic cab signal, automatic train stop, or automatic train control system complying with the provisions of this part shall be installed, unless an FRA approved PTC system meeting the requirements of this part for the subject speed and other operating conditions, is installed.

(2) On and after December 31, 2015, where any train is permitted to operate at a speed of 80 or more miles per hour, a PTC system complying with the provisions of subpart I shall be installed and operational, unless FRA approval to continue to operate with an automatic cab signal, automatic train stop, or automatic train control system complying with the provisions of this part has been justified to, and approved by, the Associate Administrator.

(3) Subpart H of this part sets forth requirements for voluntary installation of PTC systems, and subpart I of this part sets forth requirements for mandated installation of PTC systems, each under conditions specified in their respective subpart.

(e) Nothing in this section authorizes the discontinuance of a block signal system, interlocking, traffic control system, automatic cab signal, automatic train stop or automatic train control system, or PTC system, without approval by the FRA under part 235 of this title. However, 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 of this part.

(f) Any person (an entity of any type covered under 1 U.S.C. 1, including but not limited to the following: a railroad; a manager, supervisor, official, or other employee or agent of a railroad; any owner, manufacturer, lessor, or lessee of railroad equipment, track, or facilities; any independent contractor providing goods or services to a railroad; and any employee of such owner, manufacturer, lessor, lessee, or independent contractor) who violates any requirement of this part or causes the violation of any such requirement is subject to a civil penalty of at least $1,086 and not more than $35,516 per violation, except that: Penalties may be assessed against individuals only for willful violations, and, where a grossly negligent violation or a pattern of repeated violations has created an imminent hazard of death or injury to persons, or has caused death or injury, a penalty not to exceed $142,063 per violation may be assessed. Each day a violation continues shall constitute a separate offense. See FRA's website at www.fra.dot.gov for a statement of agency civil penalty policy.

(g) A person may also be subject to criminal penalties for knowingly and wilfully making a false entry in a record or report required to be made under this part, filing a false record or report, or violating any of the provisions of 49 U.S.C. 21311.

(h) The requirements of subpart H of this part apply to safety-critical processor-based signal and train control systems, including subsystems and components thereof, developed under the terms and conditions of that subpart.

[49 FR 3382, Jan. 26, 1984] Editorial Note:For Federal Register citations affecting § 236.0, see the List of CFR Sections Affected, which appears in the Finding Aids section of the printed volume and at www.govinfo.gov.

The safety-critical performance of each product for which risk assessment is required under this part must be assessed in accordance with the following minimum criteria or other criteria if demonstrated to the Associate Administrator for Safety to be equally suitable:

(a) How are risk metrics to be expressed? The risk metric for the proposed product must describe with a high degree of confidence the accumulated risk of a train control system that operates over the designated life-cycle of the product. Each risk metric for the proposed product must be expressed with an upper bound, as estimated with a sensitivity analysis, and the risk value selected must be demonstrated to have a high degree of confidence.

(b) How does the risk assessment handle interaction risks for interconnected subsystems/components? The risk assessment of each safety-critical system (product) must account not only for the risks associated with each subsystem or component, but also for the risks associated with interactions (interfaces) between such subsystems.

(c) What is the main principle in computing risk for the previous and current conditions? The risk for the previous condition must be computed using the same metrics as for the new system being proposed. A full risk assessment must consider the entire railroad environment where the product is being applied, and show all aspects of the previous condition that are affected by the installation of the product, considering all faults, operating errors, exposure scenarios, and consequences that are related as described in this part. For the full risk assessment, the total societal cost of the potential numbers of accidents assessed for both previous and new system conditions must be computed for comparison. An abbreviated risk assessment must, as a minimum, clearly compute the MTTHE for all of the hazardous events identified for both previous and current conditions. The comparison between MTTHE for both conditions is to determine whether the product implementation meets the safety criteria as required by subpart H or subpart I of this part as applicable.

(d) What major system characteristics must be included when relevant to risk assessment? Each risk calculation must consider the total signaling and train control system and method of operation, as subjected to a list of hazards to be mitigated by the signaling and train control system. The methodology requirements must include the following major characteristics, when they are relevant to the product being considered:

(1) Track plan infrastructure, switches, rail crossings at grade and highway-rail grade crossings as applicable;

(2) Train movement density for freight, work, and passenger trains where applicable and computed over a time span of not less than 12 months;

(3) Train movement operational rules, as enforced by the dispatcher, roadway worker/Employee in Charge, and train crew behaviors;

(4) Wayside subsystems and components;

(5) Onboard subsystems and components;

(6) Consist contents such as hazardous material, oversize loads; and

(7) Operating speeds if the provisions of part 236 cite additional requirements for certain type of train control systems to be used at such speeds for freight and passenger trains.

(e) What other relevant parameters must be determined for the subsystems and components? In order to derive the frequency of hazardous events (or MTTHE) applicable for a product, subsystem or component included in the risk assessment, the railroad may use various techniques, such as reliability and availability calculations for subsystems and components, Fault Tree Analysis (FTA) of the subsystems, and results of the application of safety design principles as noted in Appendix C to this part. The MTTHE is to be derived for both fail-safe and non-fail-safe subsystems or components. The lower bounds of the MTTF or MTBF determined from the system sensitivity analysis, which account for all necessary and well justified assumptions, may be used to represent the estimate of MTTHE for the associated non-fail-safe subsystem or component in the risk assessment.

(f) How are processor-based subsystems/components assessed? (1) An MTTHE value must be calculated for each processor-based subsystem or component, or both, indicating the safety-critical behavior of the integrated hardware/software subsystem or component, or both. The human factor impact must be included in the assessment, whenever applicable, to provide the integrated MTTHE value. The MTTHE calculation must consider the rates of failures caused by permanent, transient, and intermittent faults accounting for the fault coverage of the integrated hardware/software subsystem or component, phased-interval maintenance, and restoration of the detected failures.

(2) Software fault/failure analysis must be based on the assessment of the design and implementation of all safety-related software including the application code, its operating/executive program, COTS software, and associated device drivers, as well as historical performance data, analytical methods and experimental safety-critical performance testing performed on the subsystem or component. The software assessment process must demonstrate through repeatable predictive results that all software defects have been identified and corrected by process with a high degree of confidence.

(g) How are non-processor-based subsystems/components assessed? (1) The safety-critical behavior of all non-processor-based components, which are part of a processor-based system or subsystem, must be quantified with an MTTHE metric. The MTTHE assessment methodology must consider failures caused by permanent, transient, and intermittent faults, phase-interval maintenance and restoration of operation after failures and the effect of fault coverage of each non-processor-based subsystem or component.

(2) MTTHE compliance verification and validation must be based on the assessment of the design for adequacy by a documented verification and validation process, historical performance data, analytical methods and experimental safety-critical performance testing performed on the subsystem or component. The non-processor-based quantification compliance must be demonstrated to have a high degree of confidence.

(h) What assumptions must be documented for risk assessment? (1) The railroad shall document any assumptions regarding the derivation of risk metrics used. For example, for the full risk assessment, all assumptions made about each value of the parameters used in the calculation of total cost of accidents should be documented. For abbreviated risk assessment, all assumptions made for MTHHE derivation using existing reliability and availability data on the current system components should be documented. The railroad shall document these assumptions in such a form as to permit later comparisons with in-service experience.

(2) The railroad shall document any assumptions regarding human performance. The documentation shall be in such a form as to facilitate later comparisons with in-service experience.

(3) The railroad shall document any assumptions regarding software defects. These assumptions shall be in a form that permit the railroad to project the likelihood of detecting an in-service software defect. These assumptions shall be documented in such a form as to permit later comparisons with in-service experience.

(4) The railroad shall document all of the identified safety-critical fault paths to a mishap as predicted by the safety analysis methodology. The documentation shall be in such a form as to facilitate later comparisons with in-service faults.

[75 FR 2717, Jan. 15, 2010]

(a) What is the purpose of this appendix? This appendix provides safety criteria and processes that the designer must use to develop and validate the product that meets safety requirements of this part. FRA uses the criteria and processes set forth in this appendix to evaluate the validity of safety targets and the results of system safety analyses provided in the RSPP, PSP, PTCIP, PTCDP, and PTCSP documents as appropriate. An analysis performed under this appendix must:

(1) Address each of the safety principles of paragraph (b) of this appendix, or explain why they are not relevant, and

(2) Employ a validation and verification process pursuant to paragraph (c) of this appendix.

(b) 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.

(1) System safety under normal operating conditions. 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 with proper inputs and within the expected range of environmental conditions. All safety-critical functions must be performed properly under these normal conditions. The system shall operate safely even in the absence of prescribed operator actions or procedures. The designer must identify and categorize all hazards that may lead to unsafe system operation. Hazards categorized as unacceptable, which are determined by hazard analysis, must be eliminated by design. Best effort shall also be made by the designer to eliminate by design the hazards categorized as undesirable. Those undesirable hazards that cannot be eliminated should be mitigated to the acceptable level as required by this part.

(2) System safety under failures.

(i) It must be shown how the product is designed to eliminate or mitigate 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; 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.

(ii) The product must be shown to operate safely under conditions of random hardware failures. This includes single hardware failures as well as multiple hardware failures that may occur at different times but 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).

(iii) 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 that eliminates the possibility of false activation of any physical appliance.

(iv) 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.

(v) Another concern of multiple failures 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.

(3) 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.

(4) Safety assurance concepts. The product design must include one or more of the following Safety Assurance Concepts as described in IEEE-1483 standard to ensure that failures are detected and the product is placed in a safe state. One or more different principles may be applied to each individual subsystem or component, depending on the safety design objectives of that part of the product.

(i) Design diversity and self-checking concept. This concept requires that all critical functions be performed in diverse ways, using diverse software operations and/or diverse hardware channels, and that critical hardware be tested with Self-Checking routines. Permissive outputs are allowed only if the results of the diverse operations correspond, and the Self-Checking process reveals no failures in either execution of software or in any monitored input or output hardware. If the diverse operations do not agree or if the checking reveals critical failures, safety-critical functions and outputs must default to a known safe state.

(ii) Checked redundancy concept. The Checked Redundancy concept requires implementation of two or more identical, independent hardware units, each executing identical software and performing identical functions. A means is to be provided to periodically compare vital parameters and results of the independent redundant units, requiring agreement of all compared parameters to assert or maintain a permissive output. If the units do not agree, safety-critical functions and outputs must default to a known safe state.

(iii) N-version programming concept. This concept requires a processor-based product to use at least two software programs performing identical functions and executing concurrently in a cycle. The software programs must be written by independent teams, using different tools. The multiple independently written software programs comprise a redundant system, and may be executed either on separate hardware units (which may or may not be identical) or within one hardware unit. A means is to be provided to compare the results and output states of the multiple redundant software systems. If the system results do not agree, then the safety-critical functions and outputs must default to a known safe state.

(iv) Numerical assurance concept. This concept requires that the state of each vital parameter of the product or system be uniquely represented by a large encoded numerical value, such that permissive results are calculated by pseudo-randomly combining the representative numerical values of each of the critical constituent parameters of a permissive decision. Vital algorithms must be entirely represented by data structures containing numerical values with verified characteristics, and no vital decisions are to be made in the executing software, only by the numerical representations themselves. In the event of critical failures, the safety-critical functions and outputs must default to a known safe state.

(v) Intrinsic fail-safe design concept. Intrinsically fail-safe hardware circuits or systems are those that employ discrete mechanical and/or electrical components. The fail-safe operation for a product or subsystem designed using this principle concept requires a verification that the effect of every relevant failure mode of each component, and relevant combinations of component failure modes, be considered, analyzed, and documented. This is typically performed by a comprehensive failure modes and effects analysis (FMEA) which must show no residual unmitigated failures. In the event of critical failures, the safety-critical functions and outputs must default to a known safe state.

(5) Human factor engineering principle. 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.

(6) System safety under 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.

(7) System safety after 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. Such modifications must follow all of the concept, design, implementation and test processes and principles as documented in the PSP for the original product. Regression testing must be comprehensive and documented to include all scenarios which are affected by the change made, and the operating modes of the changed product during normal and failure state (fallback) operation.

(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 and subpart I 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 and subpart I of this part. The latest versions of the standards listed below should be used unless otherwise provided.

(i) IEEE standards as follows:

(A) IEEE 1483-2000, Standard for the Verification of Vital Functions in Processor-Based Systems Used in Rail Transit Control.

(B) IEEE 1474.2-2003, Standard for user interface requirements in communications based train control (CBTC) systems.

(C) IEEE 1474.1-2004, Standard for Communications-Based Train Control (CBTC) Performance and Functional Requirements.

(ii) CENELEC Standards as follows:

(A) EN50129: 2003, Railway Applications: Communications, Signaling, and Processing Systems-Safety Related Electronic Systems for Signaling; and

(B) EN50155:2001/A1:2002, Railway Applications: Electronic Equipment Used in Rolling Stock.

(iii) ATCS Specification 200 Communications Systems Architecture.

(iv) ATCS Specification 250 Message Formats.

(v) AREMA 2009 Communications and Signal Manual of Recommended Practices, Part 16, Part 17, 21, and 23.

(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—Part 3: 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.

(H) IEC 62278: 2002, Railway Applications: Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS);

(I) IEC 62279: 2002 Railway Applications: Software for Railway Control and Protection Systems;

(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.

(5) The various standards provided in this paragraph are for illustrative purposes only. Copies of these standards can be obtained in accordance with the following:

(i) U.S. government standards and technical publications may be obtained by contacting the federal National Technical Information Service, 5301 Shawnee Rd, Alexandria, VA 22312.

(ii) U.S. National Standards may be obtained by contacting the American National Standards Institute, 25 West 43rd Street, 4 Floor, New York, NY 10036.

(iii) IEC Standards may be obtained by contacting the International Electrotechnical Commission, 3, rue de Varembé, P.O. Box 131 CH—1211, GENEVA, 20, Switzerland.

(iv) CENLEC Standards may be obtained by contacting any of one the national standards bodies that make up the European Committee for Electrotechnical Standardization.

(v) IEEE standards may be obtained by contacting the IEEE Publications Office, 10662 Los Vaqueros Circle, P.O. Box 3014, Los Alamitos, CA 90720-1264.

(vi) AREMA standards may be obtained from the American Railway Engineering and Maintenance-of-Way Association, 10003 Derekwood Lane, Suite 210, Lanham, MD 20706.

[75 FR 2718, Jan. 15, 2010]

(a) This appendix provides minimum requirements for independent third-party assessment of product safety verification and validation pursuant to subpart H or subpart I of this part. The goal of this assessment is to provide an independent evaluation of the product manufacturer's utilization of safety design practices during the product's development and testing phases, as required by any mutually agreed upon controlling documents and standards and the applicable railroad's:

(1) Railroad Safety Program Plan (RSPP) and Product Safety Plan (PSP) for processor based systems developed under subpart H or,

(2) PTC Product Development Plan (PTCDP) and PTC Safety Plan (PTCSP) for PTC systems developed under subpart I.

(b) The supplier may request advice and assistance of the reviewer concerning the actions identified in paragraphs (c) through (g) of this appendix. However, the reviewer shall not engage in any design efforts associated with the product, the products subsystems, or the products components, in order to preserve the reviewer's independence and maintain the supplier's proprietary right to the product.

(c) The supplier shall provide the reviewer access to any and all documentation that the reviewer requests and attendance at any design review or walkthrough that the reviewer determines as necessary to complete and accomplish the third party assessment. The reviewer may be accompanied by representatives of FRA as necessary, in FRA's judgment, for FRA to monitor the assessment.

(d) The reviewer shall evaluate the product with respect to safety and comment on the adequacy of the processes which the supplier applies to the design and development of the product. At a minimum, the reviewer shall compare the supplier processes with acceptable validation and verification methodology and employ any other such tests or comparisons if they have been agreed to previously with FRA. Based on these analyses, the reviewer shall identify and document any significant safety vulnerabilities which are not adequately mitigated by the supplier's (or user's) processes. Finally, the reviewer shall evaluate and document the adequacy of the railroad's

(1) RSPP, the PSP, and any other documents pertinent to a product being developed under subpart H of this part; or

(2) PTCDP and PTCSP for systems being developed under subpart I of this part.

(e) The reviewer shall analyze the Hazard Log and/or any other hazard analysis documents for comprehensiveness and compliance with applicable railroad, vendor, supplier, industry, national, and international standards.

(f) The reviewer shall analyze all Fault Tree Analyses (FTA), Failure Mode and Effects Criticality Analysis (FMECA), and other hazard analyses for completeness, correctness, and compliance with applicable railroad, vendor, supplier, industry, national and international standards.

(g) The reviewer shall randomly select various safety-critical software, and hardware modules, if directed by FRA, for audit to verify whether the requirements of the applicable railroad, vendor, supplier, industry, national, and international standards were followed. The number of modules audited must be determined as a representative number sufficient to provide confidence that all unaudited modules were developed in compliance with the applicable railroad, vendor, supplier, industry, national, and international standards.

(h) The reviewer shall evaluate and comment on the plan for installation and test procedures of the product for revenue service.

(i) The reviewer shall prepare a final report of the assessment. The report shall be submitted to the railroad prior to the commencement of installation testing and contain at least the following information:

(1) Reviewer's evaluation of the adequacy of the PSP in the case of products developed under subpart H, or PTCSP for products developed under subpart I of this part, including the supplier's MTTHE and risk estimates for the product, and the supplier's confidence interval in these estimates;

(2) Product vulnerabilities, potentially hazardous failure modes, or potentially hazardous operating circumstances which the reviewer felt were not adequately identified, tracked, mitigated, and corrected by either the vendor or supplier or the railroad;

(3) A clear statement of position for all parties involved for each product vulnerability cited by the reviewer;

(4) Identification of any documentation or information sought by the reviewer that was denied, incomplete, or inadequate;

(5) A listing of each applicable vendor, supplier, industry, national, or international standard, procedure or process which was not properly followed;

(6) Identification of the software verification and validation procedures, as well as the hardware verification validation procedures if deemed appropriate by FRA, for the product's safety-critical applications, and the reviewer's evaluation of the adequacy of these procedures;

(7) Methods employed by the product manufacturer to develop safety-critical software;

(8) If deemed applicable by FRA, the methods employed by the product manufacturer to develop safety-critical hardware by generally acceptable techniques;

(9) Method by which the supplier or railroad addresses comprehensiveness of the product design which considers the safety elements listed in paragraph (b) of appendix C to this part.

[75 FR 2720, Jan. 15, 2010]

(a) This appendix provides human factors design criteria applicable to both subpart H and subpart I of this part. HMI design criteria will minimize negative safety effects by causing designers to consider human factors in the development of HMIs. The product design should sufficiently incorporate human factors engineering that is appropriate to the complexity of the product; the gender, 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.

(b) As used in this section, “designer” means anyone who specifies requirements for—or designs a system or subsystem, or both, for—a product subject to subpart H or subpart I of this part, and “operator” means any human who is intended to receive information from, provide information to, or perform repairs or maintenance on a safety-critical product subject to subpart H or I of this part.

(c) Human factors issues the designers must consider with regard to the general function of a system include:

(1) Reduced situational awareness and over-reliance. HMI design must give an operator active functions to perform, feedback on the results of the operator's actions, and information on the automatic functions of the system as well as its performance. The operator must be “in-the-loop.” Designers must consider at a minimum the following methods of maintaining an active role for human operators:

(i) The system must require an operator to initiate action to operate the train and require an operator to remain “in-the-loop” for at least 30 minutes at a time;

(ii) The system must provide timely feedback to an operator regarding the system's automated actions, the reasons for such actions, and the effects of the operator's manual actions on the system;

(iii) The system must warn operators in advance when it requires an operator to take action;

(iv) HMI design must equalize an operator's workload; and

(v) HMI design must not distract from the operator's safety related duties.

(2) Expectation of predictability and consistency in product behavior and communications. HMI design must accommodate an operator's expectation of logical and consistent relationships between actions and results. Similar objects must behave consistently when an operator performs the same action upon them.

(3) End user limited ability to process information. HMI design must therefore minimize an operator's information processing load. To minimize information processing load, the designer must:

(i) Present integrated information that directly supports the variety and types of decisions that an operator makes;

(ii) Provide information in a format or representation that minimizes the time required to understand and act; and

(iii) Conduct utility tests of decision aids to establish clear benefits such as processing time saved or improved quality of decisions.

(4) End user limited memory. HMI design must therefore minimize an operator's information processing load.

(i) To minimize short-term memory load, the designer shall integrate data or information from multiple sources into a single format or representation (“chunking”) and design so that three or fewer “chunks” of information need to be remembered at any one time.

(ii) To minimize long-term memory load, the designer shall design to support recognition memory, design memory aids to minimize the amount of information that must be recalled from unaided memory when making critical decisions, and promote active processing of the information.

(d) Design systems that anticipate possible user errors and include capabilities to catch errors before they propagate through the system;

(1) Conduct cognitive task analyses prior to designing the system to better understand the information processing requirements of operators when making critical decisions; and

(2) Present information that accurately represents or predicts system states.

(e) When creating displays and controls, the designer must consider user ergonomics and shall:

(1) Locate displays as close as possible to the controls that affect them;

(2) Locate displays and controls based on an operator's position;

(3) Arrange controls to minimize the need for the operator to change position;

(4) Arrange controls according to their expected order of use;

(5) Group similar controls together;

(6) Design for high stimulus-response compatibility (geometric and conceptual);

(7) Design safety-critical controls to require more than one positive action to activate (e.g., auto stick shift requires two movements to go into reverse);

(8) Design controls to allow easy recovery from error; and

(9) Design display and controls to reflect specific gender and physical limitations of the intended operators.

(f) The designer shall also address information management. To that end, HMI design shall:

(1) Display information in a manner which emphasizes its relative importance;

(2) Comply with the ANSI/HFS 100-1988 standard;

(3) Utilize a display luminance that has a difference of at least 35cd/m2 between the foreground and background (the displays should be capable of a minimum contrast 3:1 with 7:1 preferred, and controls should be provided to adjust the brightness level and contrast level);

(4) Display only the information necessary to the user;

(5) Where text is needed, use short, simple sentences or phrases with wording that an operator will understand and appropriate to the educational and cognitive capabilities of the intended operator;

(6) Use complete words where possible; where abbreviations are necessary, choose a commonly accepted abbreviation or consistent method and select commonly used terms and words that the operator will understand;

(7) Adopt a consistent format for all display screens by placing each design element in a consistent and specified location;

(8) Display critical information in the center of the operator's field of view by placing items that need to be found quickly in the upper left hand corner and items which are not time-critical in the lower right hand corner of the field of view;

(9) Group items that belong together;

(10) Design all visual displays to meet human performance criteria under monochrome conditions and add color only if it will help the user in performing a task, and use color coding as a redundant coding technique;

(11) Limit the number of colors over a group of displays to no more than seven;

(12) Design warnings to match the level of risk or danger with the alerting nature of the signal; and

(13) With respect to information entry, avoid full QWERTY keyboards for data entry.

(g) With respect to problem management, the HMI designer shall ensure that the:

(1) HMI design must enhance an operator's situation awareness;

(2) HMI design must support response selection and scheduling; and

(3) HMI design must support contingency planning.

(h) Ensure that electronics equipment radio frequency emissions are compliant with appropriate Federal Communications Commission regulations. The FCC rules and regulations are codified in Title 47 of the Code of Federal Regulations (CFR).

(1) Electronics equipment must have appropriate FCC Equipment Authorizations. The following documentation is applicable to obtaining FCC Equipment Authorization:

(i) OET Bulletin Number 61 (October, 1992 Supersedes May, 1987 issue) FCC Equipment Authorization Program for Radio Frequency Devices. This document provides an overview of the equipment authorization program to control radio interference from radio transmitters and certain other electronic products and an overview of how to obtain an equipment authorization.

(ii) OET Bulletin 63: (October 1993) Understanding The FCC Part 15 Regulations for Low Power, Non-Licensed Transmitters. This document provides a basic understanding of the FCC regulations for low power, unlicensed transmitters, and includes answers to some commonly-asked questions. This edition of the bulletin does not contain information concerning personal communication services (PCS) transmitters operating under Part 15, Subpart D of the rules.

(iii) 47 Code of Federal Regulations Parts 0 to 19. The FCC rules and regulations governing PCS transmitters may be found in 47 CFR, Parts 0 to 19.

(iv) OET Bulletin 62 (December 1993) Understanding The FCC Regulations for Computers and other Digital Devices. This document has been prepared to provide a basic understanding of the FCC regulations for digital (computing) devices, and includes answers to some commonly-asked questions.

(2) Designers must comply with FCC requirements for Maximum Permissible Exposure limits for field strength and power density for the transmitters operating at frequencies of 300 kHz to 100 GHz and specific absorption rate (SAR) limits for devices operating within close proximity to the body. The Commission's requirements are detailed in parts 1 and 2 of the FCC's Rules and Regulations (47 CFR 1.1307(b), 1.1310, 2.1091, 2.1093). The following documentation is applicable to demonstrating whether proposed or existing transmitting facilities, operations or devices comply with limits for human exposure to radiofrequency RF fields adopted by the FCC:

(i) OET Bulletin No. 65 (Edition 97-01, August 1997), “Evaluating Compliance With FCC Guidelines For Human Exposure To Radiofrequency Electromagnetic Fields”,

(ii) OET Bulletin No 65 Supplement A, (Edition 97-01, August 1997), OET Bulletin No 65 Supplement B (Edition 97-01, August 1997) and

(iii) OET Bulletin No 65 Supplement C (Edition 01-01, June 2001).

(3) The bulletin and supplements offer guidelines and suggestions for evaluating compliance. However, they are not intended to establish mandatory procedures. Other methods and procedures may be acceptable if based on sound engineering practice.

[75 FR 2720, Feb. 15, 2010]

(a) This appendix provides minimum requirements for mandatory independent third-party assessment of PTC system safety verification and validation pursuant to subpart H or I of this part. The goal of this assessment is to provide an independent evaluation of the PTC system manufacturer's utilization of safety design practices during the PTC system's development and testing phases, as required by the applicable PSP, PTCDP, and PTCSP, the applicable requirements of subpart H or I of this part, and any other previously agreed-upon controlling documents or standards.

(b) The supplier may request advice and assistance of the independent third-party reviewer concerning the actions identified in paragraphs (c) through (g) of this appendix. However, the reviewer should not engage in design efforts in order to preserve the reviewer's independence and maintain the supplier's proprietary right to the PTC system.

(c) The supplier shall provide the reviewer access to any and all documentation that the reviewer requests and attendance at any design review or walkthrough that the reviewer determines as necessary to complete and accomplish the third party assessment. The reviewer may be accompanied by representatives of FRA as necessary, in FRA's judgment, for FRA to monitor the assessment.

(d) The reviewer shall evaluate with respect to safety and comment on the adequacy of the processes which the supplier applies to the design and development of the PTC system. At a minimum, the reviewer shall evaluate the supplier design and development process regarding the use of an appropriate design methodology. The reviewer may use the comparison processes and test procedures that have been previously agreed to with FRA. Based on these analyses, the reviewer shall identify and document any significant safety vulnerabilities which are not adequately mitigated by the supplier's (or user's) processes. Finally, the reviewer shall evaluate the adequacy of the railroad's applicable PSP or PTCSP, and any other documents pertinent to the PTC system being assessed.

(e) The reviewer shall analyze the Hazard Log and/or any other hazard analysis documents for comprehensiveness and compliance with railroad, vendor, supplier, industry, national, or international standards.

(f) The reviewer shall analyze all Fault Tree Analyses (FTA), Failure Mode and Effects Criticality Analysis (FMECA), and other hazard analyses for completeness, correctness, and compliance with railroad, vendor, supplier, industry, national, or international standards.

(g) The reviewer shall randomly select various safety-critical software modules, as well as safety-critical hardware components if required by FRA for audit to verify whether the railroad, vendor, supplier, industry, national, or international standards were followed. The number of modules audited must be determined as a representative number sufficient to provide confidence that all unaudited modules were developed in compliance with railroad, vendor, supplier, industry, national, or international standards

(h) The reviewer shall evaluate and comment on the plan for installation and test procedures of the PTC system for revenue service.

(i) The reviewer shall prepare a final report of the assessment. The report shall be submitted to the railroad prior to the commencement of installation testing and contain at least the following information:

(1) Reviewer's evaluation of the adequacy of the PSP or PTCSP including the supplier's MTTHE and risk estimates for the PTC system, and the supplier's confidence interval in these estimates;

(2) PTC system vulnerabilities, potentially hazardous failure modes, or potentially hazardous operating circumstances which the reviewer felt were not adequately identified, tracked or mitigated;

(3) A clear statement of position for all parties involved for each PTC system vulnerability cited by the reviewer;

(4) Identification of any documentation or information sought by the reviewer that was denied, incomplete, or inadequate;

(5) A listing of each applicable vendor, supplier, industry, national or international standard, process, or procedure which was not properly followed;

(6) Identification of the hardware and software verification and validation procedures for the PTC system's safety-critical applications, and the reviewer's evaluation of the adequacy of these procedures;

(7) Methods employed by PTC system manufacturer to develop safety-critical software; and

(8) If directed by FRA, methods employed by PTC system manufacturer to develop safety-critical hardware.

[75 FR 2721, Jan. 15, 2010]