Standards for Development and Use of Processor-Based Signal and Train Control Systems

DEPARTMENT OF TRANSPORTATION

Federal Railroad Administration

49 CFR Parts 209, 234, and 236

[Docket No. FRA-2001-10160]

RIN 2130-AA94

Standards for Development and Use of Processor-Based Signal and Train Control Systems

AGENCY:

Federal Railroad Administration (FRA), Department of Transportation (DOT).

ACTION:

Final rule.

SUMMARY:

FRA is issuing a performance standard for the development and use of processor-based signal and train control systems. The rule also covers systems which interact with highway-rail grade-crossing warning systems. The rule establishes requirements for notifying FRA prior to installation and for training and recordkeeping. FRA is issuing these standards to promote the safe operation of trains on railroads using processor-based signal and train control equipment.

DATES:

This rule is effective June 6, 2005. The incorporation by reference of a certain publication listed in the rule is approved by the Director of the Federal Register as of June 6, 2005.

ADDRESSES:

Except for good cause shown, any petition for reconsideration of any part of this rule must be submitted not later than May 6, 2005. Any petition for reconsideration should reference FRA Docket No. FRA-2001-10160 and be submitted in triplicate to the Docket Clerk, Office of Chief Counsel, FRA, 1120 Vermont Avenue, NW., Mail Stop 10, Washington, DC 20590. Petitions, received by the FRA Docket Clerk will be sent to the DOT Docket Management System (DMS) located on the Plaza level of the Nassif Building at the Department of Transportation. You can review public dockets, including any petitions for reconsideration received there between the hours of 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays. You can also review any petition for reconsideration on-line at the DMS Web site at

http://dms.dot.gov.

Please note that anyone is able to search the electronic form of all submissions into any of FRA's dockets by the name of the individual making the submission (or signing the submission, if submitted on behalf of an association, business, labor union, etc.). You may review DOT's complete Privacy Act Statement in the

Federal Register

published on April 11, 2000 (volume 65, number 70; pages 19477-78), or you may visit

http://dms.dot.gov.

FOR FURTHER INFORMATION CONTACT:

Tom McFarlin, Staff Director, Signal and Train Control Division, Office of Safety, FRA, 1120 Vermont Avenue, NW., Mail Stop 25, Washington, DC 20590 (telephone: 202-493-6203); or Melissa Porter, Office of Chief Counsel, FRA, 1120 Vermont Avenue, NW., Mail Stop 10, Washington, DC 20590 (telephone: 202-493-6034).

SUPPLEMENTARY INFORMATION:

Table of Contents for Supplementary Information

I. Introduction

II. Statutory Background

III. Regulatory Background

IV. RSAC

A. Overview

B. The PTC Working Group

V. Discussion of Alternatives Considered and the Rationale for the Option Selected

A. Performance Standards vs. Prescriptive Standards

B. Evaluation of Performance-Based Approach

C. Advantages of a Performance Standard; Consideration of Disadvantages

D. Analysis of Risk Associated With Train Control Technologies

E. Choice of Type of Performance Standard

F. Options for Demonstrating Compliance With the Performance Standard

VI. Proceedings to Date

VII. Comments and Conclusions on General Issues

A. Background and RSAC Process

B. The Performance-Based Approach

C. The Performance Standard—What Will Be the “Base Case” for Comparison?”

D. How Does This Rule Affect Locomotive Electronics and Train Control?

VIII. Section-by-Section Analysis

IX. Regulatory Impact

A. Executive Order 12866 and DOT Regulatory Policies and Procedures

B. Anticipated Costs and Benefits

C. Regulatory Flexibility Act

D. Paperwork Reduction Act

E. Environmental Impact

F. Federalism Implications

G. Compliance with the Unfunded Mandates Reform Act of 1995

List of Subjects

I. Introduction

FRA is issuing a performance standard for processor-based signal and train control systems. FRA began the process of developing a rule in 1997 when its Railroad Safety Advisory Committee (RSAC) was tasked with developing a proposed rule for FRA's consideration. RSAC made consensus recommendations to FRA on a proposed rule; FRA agreed to these recommendations and published them as a notice of proposed rulemaking (NPRM) on August 10, 2001 (66 FR 42352). FRA received quite a few public comments on the NPRM. This notice responds to comments on the NPRM and issues the final rule. The standards grew out of the proposed rule requiring that processor-based signal and train control systems meet or exceed the safety level of the traditional signal systems they replace. The preamble discusses the statutory background, the regulatory background, the RSAC proceedings, the alternatives considered and the rationale for the option selected, the proceedings to date, as well as the comments and conclusions on general issues. Other comments and resolutions are discussed within the corresponding section-by-section analysis.

II. Statutory Background

FRA has broad statutory authority to regulate all areas of railroad safety. 49 U.S.C. 20103(a); 49 CFR 1.49. The Federal Railroad Safety Act of 1970, Public Law 91-458, contained this broad grant of authority and supplemented the older rail safety laws then in existence. The older safety laws had been enacted in a piecemeal approach and addressed specific fields of railroad safety. For instance, the Signal Inspection Act, 49 U.S.C. 26 (recodified at 49 U.S.C. 20502

et seq.

(1994)), has governed the installation and removal of signal equipment since its enactment August 26, 1937. Until July 5, 1994, the Federal railroad safety statutes existed as separate acts found primarily in Title 45 of the United States Code. On that date all of the acts were repealed and their provisions were recodified into Title 49 Chapters 201-213.

Pursuant to its general statutory rulemaking authority, FRA promulgates and enforces rules as part of a comprehensive regulatory program to address the safety of railroad track, signal systems, railroad communications, rolling stock, operating practices, passenger train emergency preparedness, alcohol and drug testing, locomotive engineer certification, and workplace safety. In the area of railroad signal and train control systems, FRA has issued regulations, found at 49 CFR part 236 (“part 236”), addressing topics such as the security of signal apparatus housings against unauthorized entry (49 CFR 236.3), location of roadway signals (49 CFR 236.21), and the testing of relays (49 CFR 236.106). Hereafter all references to parts and sections shall be parts and sections located in Title 49 of the Code of Federal Regulations.

FRA continually reviews its regulations and revises them as needed to keep up with emerging technology. FRA's need to review its regulatory

scheme with respect to emerging technology in the signal and train control arena was acknowledged by Congress in Section 11 of the Rail Safety Enforcement and Review Act (RSERA) (Pub. L. 102-365, Sep. 3, 1992), entitled “Railroad Radio Communications.” Section 11(a) of RSERA mandated that the Secretary conduct a safety inquiry to assess, among other areas,

(6) The status of advanced train control systems that are being developed, and the implications of such systems for effective railroad communications; and

(7) The need for minimum Federal standards to ensure that such systems provide for positive train separation and are compatible nationwide.

106 Stat. 980. Section 11(b) required the Secretary to

submit to Congress within 4 months after the completion of such inquiry a report on the results of the inquiry along with an identification of appropriate regulatory action and specific plans for taking such action.

Id.

FRA conducted the inquiry required by RSERA and submitted a comprehensive Report to Congress on July 8, 1994, entitled

Railroad Communications and Train Control

(1994 PTC Report). A copy of this 1994 PTC Report is in the docket of this rulemaking. As part of the 1994 PTC Report, FRA called for implementation of an action plan to deploy PTC systems. The report forecast substantial benefits of advanced train control technology to support a variety of business and safety purposes, but noted that an immediate regulatory mandate for PTC could not be currently justified based upon normal cost/benefit principles relying on direct safety benefits. The report outlined an aggressive Action Plan implementing a public/private sector partnership to explore technology potential, deploy systems for demonstration, and structure a regulatory framework to support emerging PTC initiatives.

Since 1994, the Congress has appropriated and FRA has committed approximately $40 million through the Next Generation High Speed Rail Program and the Research and Development Program to support development, testing and deployment of PTC prototype systems in Illinois, Alaska, and the Eastern railroads' on-board electronic platforms. As called for in the Action Plan, the FRA also launched an effort to structure an appropriate regulatory framework for facilitating implementation of PTC technology and for evaluating future safety needs and opportunities. For such a task, FRA desired input from the developers, prospective purchasers and operators of this new technology. Thus, in September of 1997, the Federal Railroad Administrator asked RSAC to address several issues involving PTC, including the development of performance standards for PTC systems. RSAC's involvement in this rulemaking will be discussed later in the preamble.

Since the issuance of FRA's 1994 PTC Report, Congress has twice requested the Secretary of Transportation to submit additional reports on PTC; first in 1994, and more recently in 2003. In 1994, Congress directed the Secretary to submit a progress report.

The Secretary of Transportation shall submit a report to the Congress on the development, deployment, and demonstration of positive train control systems by December 31, 1995.

49 U.S.C. 20150. On May 17, 2000, FRA submitted a letter report responding to Section 20150 (2000 PTC Report). A copy of the 2000 PTC Report is in the docket of this rulemaking. The report noted the progress being made toward the deployment of PTC systems but concluded that deployment on the entire national rail system cannot be justified on safety grounds alone. FRA indicated that it would continue to encourage railroads to deploy PTC voluntarily. The report noted that RSAC, at FRA's request, had begun to address the PTC issue, and had issued a report to FRA in September 1999 (1999 RSAC Report) entitled

Implementation of Positive Train Control Systems

that detailed current PTC system projects, estimated accidents preventable by PTC systems, and estimated the costs and benefits of PTC systems as applied to the major railroads.

The 1999 RSAC Report confirmed the core PTC safety functions described in the 1994 PTC Report (prevent train-to-train collisions; enforce speed restrictions and temporary slow orders; and provide protection for roadway workers and their equipment operating under specific authorities). It also referred to additional safety functions that might be included in some PTC architecture (

e.g.

, warning of on-track equipment operating outside the limits of authority; enforcement of hazard detection warnings; and a future capability for generating data for transfer to highway users to enhance warning at highway-rail grade crossings).

The 1999 RSAC Report found that railroad safety benefits of PTC could not support the investments necessary to deploy the system. The report estimated that PTC deployment on the Class 1 railroads would cost about $1.2 billion to equip the lines with a level 1 type PTC system (address core PTC functions only), and about $7.8 billion to equip the lines with a level 4 type PTC system (increased functionality addressing additional safety monitoring systems and enhanced traffic management capabilities). These costs are total discounted life cycle costs, including procurement, installation, and maintenance, over 20 years. The 20 year total discounted benefits from avoided accidents ranged from about $500 million for a level 1 PTC system, to about $850 million for a level 4 PTC system. The Committee was not able to reach conclusions regarding the non-safety benefits of PTC-related technologies.

As part of the FRA appropriations for fiscal year 2003, Congress requested FRA to update cost/benefit numbers contained in the 2000 PTC Report to Congress. The Conference Report on the Consolidated Appropriations Resolution, 2003 (Pub. L. 108-7) provided in pertinent part as follows:

Positive train control.

—The conferees direct FRA to submit an updated economic analysis of the costs and benefits of positive train control and related systems that takes into account advances in technology and system savings to carriers and shippers as well as other cost savings related to prioritized deployment of these systems, as proposed by the Senate. This analysis must be submitted as a letter report to the House and Senate Committees on Appropriations by October 1, 2003.

H.R. Rep. No. 108-10, 108th Cong. 1st Sess. 1286-7. FRA submitted the requested PTC letter report to Congress on August 18, 2004 and a copy of the report is in the docket of this rulemaking. The report indicates that substantial public benefits would likely flow from the installation of PTC systems on the railroad system, although the total amount of these benefits is subject to debate. The report reaffirmed the conclusions reached in the 1994 and 2000 PTC Reports that the safety benefits of PTC systems are relatively small in comparison to the huge costs of installing the PTC systems.

In light of the cost/benefit numbers, an immediate regulatory mandate for PTC could not be currently justified based upon normal cost/benefit principles relying on direct railroad safety benefits. FRA has, therefore, chosen to issue a final rule that establishes a performance standard for processor-based train control systems, but does not require that they be installed. PTC systems can enhance the

safety of railroad operations; the rule will help facilitate the establishment of such systems.

III. Regulatory Background

Part 236 was last amended in 1984. At that time, signal and train control functions were performed principally through use of electrical circuits employing relays as the means of effecting system logic. This approach had proven itself capable of supporting a very high level of safety for over half a century. However, electronic controls were emerging on the scene, and several sections of the regulations were amended to take a more technology-neutral approach to the required functions (

see

§§ 236.8, 236.51, 236.101, 236.205, 236.311, 236.813a). This approach has fostered introduction of new, more cost effective technology while providing FRA with strong enforcement powers over systems that fail to work as intended in the field.

Since that time, FRA has worked with railroads and suppliers to apply the principles embodied in the regulations to emerging technology and to identify and remedy initial weaknesses in some of the new products. As a result, thousands of interlocking controllers and other electronic applications are embedded in traditional signal systems. Further technological advances may provide additional opportunities to increase safety levels and achieve economic benefits as well. For instance, implementation of innovative PTC systems may employ new ways of detecting trains, establishing secure routes, and processing information. This presents a far greater challenge to both signal and train control system developers and FRA. This challenge involves retaining a corporate memory of the intricate logic associated with railway signaling, while daring to use whole new approaches to implement that logic—at the same time stretching the technology to address risk reduction opportunities that previously were not available. For FRA, the challenge is to continue to be prepared to make safety-based decisions regarding this new technology, without impairing the development of this field. Providing general standards for the development and implementation of products utilizing this new technology is necessary to facilitate realization of the potential of electronic control systems and for safety and efficiency.

FRA has already used its safety authority to grant waivers and issue orders to support innovation in the field of train control technology. FRA has granted test waivers for the Union Pacific Railroad Company (UP)/Burlington Northern and Santa Fe Railway Company (BNSF) Positive Train Separation (PTS) project in the Pacific Northwest, the National Railroad Passenger Corporation (Amtrak) Incremental Train Control System (ITCS) in the State of Michigan, the CSX Transportation, Inc. (CSXT) Communication-Based Train Management (CBTM) project in South Carolina and Georgia, and the Alaska Railroad PTC project. On September 19, 1996 FRA granted conditional revenue demonstration authority for ITCS. In 1998, FRA issued a final order for the installation of the Advanced Civil Speed Enforcement System (ACSES) on the Northeast Corridor (63 FR 39343, Aug. 21, 1998). See also 64 FR 54410, Oct. 6, 1999 (delaying effective date of such order).

Although FRA expects to continue its support for these current projects, the need for controlling principles in this area has become patently obvious. This rulemaking has provided a forum for identifying and codifying those principles.

IV. RSAC

A. Overview

In March 1996, FRA established the RSAC, which provides a forum for consensual rulemaking and program development. The Committee includes representation from all of the agency's major customer groups, including railroads, labor organizations, suppliers and manufacturers, and other interested parties. A list of member groups follows:

American Association of Private Railroad Car Owners (AARPCO)

American Association of State Highway & Transportation Officials (AASHTO)

American Public Transportation Association (APTA)

American Short Line and Regional Railroad Association (ASLRRA)

American Train Dispatchers Department/Brotherhood of Locomotive Engineers (ATDD/BLE)

Amtrak

Association of American Railroads (AAR)

Association of Railway Museums (ARM)

Association of State Rail Safety Managers (ASRSM)

Brotherhood of Locomotive Engineers (BLE)

Brotherhood of Maintenance of Way Employees (BMWE)

Brotherhood of Railroad Signalmen (BRS)

Federal Transit Administration (FTA)*

High Speed Ground Transportation Association

Hotel Employees & Restaurant Employees International Union

International Association of Machinists and Aerospace Workers

International Brotherhood of Boilermakers and Blacksmiths

International Brotherhood of Electrical Workers (IBEW)

Labor Council for Latin American Advancement (LCLAA)*

League of Railway Industry Women*

National Association of Railroad Passengers (NARP)

National Association of Railway Business Women*

National Conference of Firemen & Oilers

National Railroad Construction and Maintenance Association

National Transportation Safety Board (NTSB)*

Railway Progress Institute (RPI)

Safe Travel America

Secretaria de Communicaciones y Transporte*

Sheet Metal Workers International Association

Tourist Railway Association Inc.

Transport Canada*

Transport Workers Union of America (TWUA)

Transportation Communications International Union/BRC (TCIU/BRC)

United Transportation Union (UTU)

*Indicates associate membership.

When appropriate, FRA assigns a task to RSAC, and after consideration and debate, RSAC may accept or reject the task. If accepted, RSAC establishes a working group that possesses the appropriate expertise and representation of interests to develop recommendation] to FRA for action on the task. These recommendations are developed by consensus. The working group may establish one or more task forces or other subgroups to develop facts and options on a particular aspect of a given task. The task force or other subgroup reports for the working group. If a working group comes to consensus on recommendations for action, the package is presented to the RSAC for a vote. If the proposal is accepted by a simple majority of the RSAC, the proposal is formally recommended to FRA. FRA then determines what action to take on the recommendation. Because FRA staff has played an active role at the working group and subgroup levels in discussing the issues and options and in drafting the language of the consensus proposal and because the RSAC recommendation constitutes the consensus of some of the industry's leading experts on a given subject, FRA is often favorably inclined toward the RSAC recommendation. However, FRA is in no way bound to follow the recommendation and the agency exercises its independent judgement on whether the recommended rule achieves the agency's regulatory goal, is soundly supported, and is in accordance with policy and legal requirements. Often, FRA varies in some respects from the RSAC recommendation in developing the actual regulatory proposal. If the working group is unable to reach consensus on recommendations for

action, FRA moves ahead to resolve the issue through traditional rulemaking proceedings.

B. The PTC Working Group

On September 30, 1997, the RSAC accepted a task (No. 97-6) entitled “Standards for New Train Control Systems.” The purpose of this task was defined as follows: “To facilitate the implementation of software based signal and operating systems by discussing potential revisions to the Rules, Standards and Instructions (Part 236) to address processor-based technology and communication-based operating architectures.” The task called for the formation of a working group to include consideration of the following:

• Disarrangement of microprocessor-based interlockings;

• Performance standards for PTC systems at various levels of functionalities (safety-related capabilities); and

• Procedures for introduction and validation of new systems.

RSAC also accepted two other tasks related to PTC, task Nos. 97-4 and 97-5. These tasks dealt primarily with issues related to the feasibility of implementation of PTC technology.

FRA gratefully acknowledges the participation and leadership of representatives of the following organizations who served on the PTC Working Group (hereafter Working Group):

AAR, including members from

BNSF

Canadian National

Consolidated Rail Corporation

CSX

Metra

Norfolk Southern Railway Company

UP

AASHTO

Amtrak

APTA

ASLRRA

ATDD/BLE

BLE

BMWE

BRS

FRA

High Speed Ground Transportation Association

IBEW

RPI

UTU

Staff from the National Transportation Safety Board and the Federal Transit Administration also participated in an advisory capacity.

In order to efficiently accomplish the three tasks assigned to it involving PTC issues, the Working Group empowered two task forces to work concurrently: The Data and Implementation Task Force, which handled tasks 97-4 and 97-5, and the Standards Task Force, which handled task 97-6.

The Data and Implementation Task Force finalized a report on the future of PTC systems and presented it, with the approval of RSAC, to the Administrator in September of 1999. Report of the Railroad Safety Advisory Committee to the Federal Railroad Administrator, “Implementation of Positive Train Control Systems” (September 8, 1999).

The Working Group also employed several teams, comprised of representatives from RSAC member organizations, who provided invaluable assistance. An Operating Rules Team was charged with working to ensure that appropriate railroad operating rules are part of any PTC implementation process, and a Human Factors Team was charged with evaluating human factor aspects of PTC systems. Members of these teams serve on both the PTC Standards Task Force and the Data and Implementation Task Force, and additional team members were drawn from the railroad community.

FRA staff and staff from the Volpe National Transportation Systems Center (the Volpe Center) worked with the Working Group and its subgroups. FRA responded to a consensus request from the Standards Task Force by contracting for assistance from the Center for Safety-Critical Systems at the University of Virginia.

The NPRM describes the role the Standards Task Force played in developing its recommendations to the Working Group and RSAC, which were in turn recommended to FRA by RSAC and formed the basis for the proposed rule. The Standards Task Force ceased to meet and exist after publication of the NPRM. References to the Standards Task Force and Working Group are reiterated here to provide a historical perspective regarding development of the RSAC recommendations on which the NPRM was based. These points are discussed to show the origin of certain issues and the course of discussion on these issues at the Task Force and Working Group levels. We believe this helps illuminate the factors FRA weighed in making its regulatory decisions at the NPRM stage, and the logic behind those decisions, most of which are still embodied in this final rule.

V. Discussion of Alternatives Considered and the Rationale for the Option Selected

As previously noted, RSAC recommended to FRA that it adopt the proposed rule recommended to RSAC by the Working Group. FRA concluded that the recommended proposed rule would satisfy its regulatory goals and issued an NPRM that tracked the RSAC recommendation on all major issues. Subsequent to the publication of the NPRM and the close of the comment period, informative discussions were had at the RSAC Working Group meetings regarding issues and concerns raised by written comments. These discussions contributed greatly to FRA's knowledge and understanding of the relevant subject matter, but, as discussed below, RSAC was ultimately unable to reach consensus on recommendations regarding the final rule.

In this final rule, FRA has carried forward the basic principles and structure and in many cases the language of the proposed rule with few or no changes, as initially recommended by the RSAC at the NPRM stage. The text of the final rule is substantially different from the NPRM in only a few ways. First, FRA is adding a provision delineating the responsibilities of railroads and suppliers regarding software hazards; second, FRA is providing alternatives for the abbreviated risk assessment; third, FRA is providing criteria for adjustment to the base case where changes are planned in the subject operation's speed and density; fourth, FRA is adding a provision as notice that entities may be subject to criminal penalties in accordance with 49 U.S.C. 21311; and last, FRA is adding an appendix with a schedule of civil penalties. In addition, minor edits for improved clarity and consistency have been added. Each of these substantive changes will be addressed in the section-by-section analysis of the rule text to which it applies. However, given the failure of RSAC to reach consensus at the final rule stage, FRA has determined the contents of the final rule, without the benefit of a formal RSAC recommendation, based on the agency's best judgment (informed, in many cases, by the excellent discussion of the issues within the Working Group).

A. Performance Standards vs. Prescriptive Standards

During early discussions in the advisory process, FRA noted that the existing “Rules, Standards and Instructions” (part 236) take a performance-oriented approach at the functional level, although—by virtue of the historical context in which they were initially prepared—they most often reference older technology. During the last decade and a half, this performance-oriented approach to specified functions has permitted the growth of electronic systems within signal and train control

systems without substantial regulatory change (albeit with growing ambiguity concerning the application of individual provisions to novel technical approaches). Wishing to maintain historical continuity and hasten preparation of a proposed and ultimately a final rule, FRA offered for consideration an initial redraft of part 236 that attempted a more technology-neutral approach to performance at the functional level, while also addressing PTC functions, as a possible starting point for the group's work.

Carrier representatives found the FRA draft to be unduly constricting, and asked thatthe group pursue higher-level performance standards. Supplier and labor representatives agreed to this approach, and FRA endeavored to support the Standards Task Force in pursuing it.

The group heard from representatives of the Research and Special Programs Administration, Federal Highway Administration's Office of Motor Carrier Safety (now Federal Motor Carrier Safety Administration), and APTA. FRA distributed a guidance document entitled “Performance Standards: A Practical Guide to the Use of Performance Standards as a Regulatory Alternative,” (Project on Alternative Regulatory Approaches, September 1981), a copy of which has been placed in the docket of this rulemaking.

In brief overview, the term “performance standard” has been variously applied to describe many different forms of regulatory approaches that avoid design specifications and other prescriptive requirements, such as mandates that actions be taken in a particular sequence, or in a particular manner, by the regulated entity. At the most permissive extreme, a performance standard for a railroad operating system might specify an “acceptable” level of safety performance (

e.g.

, number of fatalities per million train miles) and avoid any intervening action unless and until the performance of the regulated entity fell below that level. FRA believes that this type of approach would represent an abandonment of the agency's responsibility to promote safety, since it would necessarily assume optimum performance by the regulated entity (a condition not realized in practice) and would prevent helpful intervention until unacceptable consequences had already occurred. FRA has not sought to pursue this approach.

The least permissive performance standards include such approaches as requiring that a metal skin on the front of a locomotive have penetration resistance equivalent to that of a given thickness of a specified steel. In this example, the choice of material is left to the designer, but the options are not extensive. See,

e.g.

, § 238.209.

In the middle range of permissiveness, a performance standard might address acceptable performance parameters for a particular, mandated device, in lieu of a fixed physical description. For instance, FRA requirements for railroad tank cars carrying flammable compressed gas require the application of high temperature thermal protection that can be accomplished using a variety of materials, together with pressure relief valve capacity requirements adequate to permit safe evacuation and burn-off of the car's contents prior to catastrophic failure of the vessel in a fire environment (part 179, Appendix B (qualification test procedure)). This combination of regulatory requirements has been highly effective in preventing loss of life from violent detonation of tank cars involved in derailments (although compliance issues have been presented by disintegration of insulation blankets that could not be readily detected under the outer jacket of a car).

Some of the safety statutes administered by FRA contain performance-based criteria. For instance, the Signal Inspection Act, as codified at 49 U.S.C. 20502(b), states:

A railroad carrier may allow a signal system to be used on its railroad line only when the system, including its controlling and operating appurtenances * * * may be operated safely without unnecessary risk of personal injury.

However, recognizing the need to make a practical application of this broad statement, the law also requires that the system “has been inspected and can meet any test prescribed under this chapter.” What could otherwise be deemed a very broad performance standard is thus made more specific in practice.

B. Evaluation of Perfomance-Based Approach

The NPRM identified a variety of considerations relevant to whether, and in what form, performance standards should be employed in this and other settings. After review of the public comments on the NPRM, FRA is satisfied that, as a general matter, the performance standard contained in the final rule should be suitable for this context. That is—

• The standard is stated as a practical goal;

• It will be enforceable;

• It will be usable by small entities;

• It can be shown to yield safety that is equivalent to that required under the existing Rules, Standards and Instructions (RS&I) issued by FRA's predecessor the Interstate Commerce Commission (ICC) and carried forward by FRA in part 236;

• Its cost is reasonable;

• It provides means of determining compliance before safety is endangered; and

• As adapted in this final rule, analytical techniques needed to verify compliance are available.

This last point bears further mention. FRA expressed concern in the NPRM that a risk assessment technique, the Axiomatic Safety-Critical Assurance Process(ASACP), intended to provide an important toolset to establish compliance with the performance standard was still under development. Although that continued to be the case as FRA was preparing this final rule and submitting it for review and clearance, FRA has made appropriate changes to this final rule emphasizing FRA's conclusion that more than one type of risk assessment is acceptable.

FRA had also identified several desirable criteria with respect to promulgating a performance standard specifically for processor-based signal and train control technologies: Simplicity, relevancy, reliability, cost, and objectivity.

Simplicity:

Although nothing about producing a safety-critical signal or train control system is inherently simple, the final rule is relatively simple and provides the railroads with a great deal of flexibility.

Relevancy:

Like the NPRM, the final rule focuses on the safety-relevant characteristics of systems and emphasizes all relevant aspects of product performance.

Reliability:

This criterion could also be referred to as precision. That is, the standard should be reliable in that the test applied should yield similar results each time it is applied to the same subject matters. This criterion remains a concern in relation to the functioning of the final rule, but FRA has determined that the challenges presented should be manageable.

Cost:

FRA pointed out in the NPRM that demonstrating compliance with the standard should not be unduly expensive. In reviewing the comments and making adjustments to the final rule, FRA has structured a standard that is not unduly expensive.

Objectivity:

A completely objective standard would allow for compliance to be determined through scientific study or investigation. This is another dimension of enforceability. Like the NPRM, the final rule includes a number of provisions intended to ensure that

application of the standard will be demonstrably objective.

C. Advantages of a Performance-Based Standard; Consideration of Disadvantages

This final rule presents the highest level performance requirements ever attempted by FRA. In the NPRM, FRA discussed at length both the reasons to pursue such a course and concerns perceived by the agency regarding its wisdom.

Since issuance of the NPRM, FRA has continued its inquiries into the advantages and limitations of high-level performance standards and the current utility of available risk assessment techniques to determine compliance with such standards. See,

e.g.,

Coglianese, Nash, and Olmstead, Performance-Based Regulation: Prospects and Limitations in Health, Safety, and Environmental Protection (Regulation Policy Program, John F. Kennedy School of Government, Harvard University 2002). FRA has been impressed both by the potential power of performance standards to foster innovation and by the fact that most regulatory implementations of the concept have been layered on top of prescriptive standards rather than replacing them. That is, practice in most agencies with similar missions has focused on being “risk informed” rather than “risk driven.” The fundamental reason for this is the inherent difficulty of predicting safety outcomes in complex environments.

FRA remains concerned that the performance-based approach of this final rule may not ensure progressive improvements in safety. Risk management practitioners typically set goals for incremental improvements in safety in connection with use of performance standards. By contrast, this final rule makes current risk levels the floor for future performance. However, if reductions in risk levels do not occur as part of the natural progression from application of the rule's performance based standards, the improvement in risk levels can be achieved by regulatory mandate. FRA refers in the final rule to the prerogative of the agency to order improvements in safety where they are supported by appropriate analysis.

In the NPRM, FRA also expressed doubt regarding whether the relevant technical, scientific, and railroad signaling communities are fully prepared to support implementation of the proposed rule. Although commenters did not appear to question the fact that the field of safety-critical systems is relatively new and undergoing a process of maturation, they did question some of FRA's assertions. For instance, a major signal supplier noted that suppliers do provide quantitative information concerning life-cycle safety performance in the transit market. The same supplier stated that the concept of product validation is much better settled than suggested by FRA in the NPRM and questioned FRA's suggestion that quantifying risk with respect to electronic systems was somehow more difficult than with electro-mechanical systems. Notably, however, the supplier was addressing this topic from the context of design and production of systems utilizing traditional safety concepts. The same commenter noted that much more challenging issues associated with less conventional systems (including those relying upon complex commercial off-the-shelf hardware or software for which source code is not available to the designer and where changes may be introduced without notice).

Commenters generally did not question the difficulty associated with assigning values to human factor risk, and FRA's consideration of the issues as informed by intervening discussions of the Working Group (including presentation and discussion of various risk assessment topics) has done nothing to call into question FRA's original concerns regarding the complexity of safety proofs at the system level, particularly where human factors or non-conventional electronic systems are involved.

Neither did commenters effectively reassure FRA regarding the danger that risk assessment could become an “after the fact” justification for a system already constructed. This concern could be exacerbated by the difficulty of conducting risk assessments in parallel with product development against tight time deadlines. Under such circumstances, the tendency is to assign each subsystem of the electronic system a “risk budget,” after which the temptation to stay within budget could have the tendency to skew estimates. FRA has removed a sentence from the appendix on risk assessment that could be read to endorse this approach; but there is, of course, no reasonable way to prevent it from occurring. Rather, FRA will need to be alert to this procedure; and, where it is used, it may be appropriate to require a third party assessment of the verification and validation process that yielded the compliant estimates.

D. Analysis of Risk Associated With Train Control Technologies

As reported in the NPRM, recognizing the need to advance the state of the art with respect to analysis of risk specifically associated with various methods of operations and train control technologies, the Standards Task Force established a team to support development of a ASCAP. At the request of the Standards Task Force, FRA engaged the University of Virginia (UVA) to develop the ASCAP model as a risk assessment “toolkit” for use in implementing the PTC rule then under development. The initial challenge for the ASCAP team and contractor was to describe the level of risk associated with the current method of operation on a CSXT line, which is operated without a signal system using direct traffic control system rules (the “base case”). The first comparison case was to be the operations on the same line should a traffic control system be installed. The second comparison case was to be implementation of the proposed Communications Based Train Management (CBTM) system, an innovative technology that addresses the PTC core functions.

As the effort progressed, the traffic control case was eliminated and the effort focused on CBTM. This “dry run” for ASCAP resulted in development of important elements of the technique, including a relatively sophisticated train management algorithm. The CBTM exercise was then suspended due to the need for the University to focus on the safety case for the Illinois DOT Project under contract to System Designer and Integrator for the North American Joint Positive Train Control Program (NAJPTC). When UVA last briefed the RSAC Working Group on this effort in March of 2003, it was clear that the method had been greatly enriched; however, neither the adjusted base case nor the PTC case had yet been finalized. Due to the difficulty of obtaining useful human factors data, that element of the analysis appeared to be the portion of the work still subject to review and potential redirection.

FRA reiterates that the ASCAP approach appears to have significant value for distinguishing risk between the previous condition and proposed systems. However, in developing this final rule, FRA has necessarily taken notice of the fact that constructing the method has proved much more difficult than initially predicted; and nothing approaching validation of the method has yet been undertaken. As a result, the application of recognized alternative risk assessment methods used in other industries is anticipated. These traditional methods will be accepted on a case-by-case basis, after technical review by the Associate Administrator for Safety.

E. Choice of Type of Performance Standard

FRA adopts the performance standard contained in the NPRM, which is basically that the new condition be at least as safe as the previous condition. In the preamble to the proposed rule, FRA acknowledged that this is a static level of safety.

Following issuance of the NPRM, the agency focused further on the problem of how to characterize the base case. FRA noted that, in cases where no adjustment of the previous condition was necessary, the rule might actually result in uneven outcomes depending upon the level of safety on the particular railroad and particular territory. Very often the level of safety is affected significantly by intangibles such as specific provisions of the operating rules, training, degree of supervisory oversight, and degree of professionalism of the work force. A railroad with a good safety record could, in effect, be constrained in terms of future options by its own good performance. Such a railroad would likely have a commitment to continuous improvement, and FRA did not want to create the opportunity for safety to decline. On the other side of the ledger, it is a positive thing that safety would be improved through investments in signals or train control in an area where risk had been relatively higher; however, FRA did not want to “set the bar too high” lest needed improvements be discouraged.

FRA embraces this concept of progressive improvement and realizes that actual safety outcomes do differ, despite every attempt to maintain minimum standards. FRA notes that, in cases where adjustment of the base case is required, reliance on average numbers for similar territory may be required, which may have the effect of leveling the playing field over time.

F. Options for Demonstrating Compliance With the Performance Standard

In the NPRM, FRA described a series of options for demonstrating compliance with the performance standard and explained that the option selected could be best described as a Bayesian belief network. A Bayesian Network is a special type of mathematical construct called an “ acyclic directed graph” that represents relationships between logical propositions consisting of a set of assumptions called variables. A simple example of an “acyclic directed graph” is the elimination tree used in many sporting events. Each variable in the logical proposition is independent of other variables that it does not share a common parent with. The joint probability over all variables, which is the probability of the events represented by the graph, occurring is represented in terms of local probabilities associated with each of the individual variables. Its principal limitation is that it may not appear totally objective. It asks that the railroad demonstrate “to a high degree of confidence,” that the proposed product would result in no loss of safety. The railroad would be required to make this finding initially. The NPRM attempted to make it clear that, in any case where approval was required, FRA would determine the sufficiency of the safety case. However, the manner in which that would be done was not made clear, since the definition of “high degree of confidence” embodied a “reasonable decision-maker” standard that would be employed to determine compliance, and the railroad had a duty (carried forward in this final rule) to make an initial determination that the safety case was sufficient.

Since issuance of the NPRM, which pointed out the technical challenges associated with issues underlying administration of a performance standard, FRA has noted slow (albeit demonstrable) progress toward resolution of those issues. Accordingly, FRA is concerned that, given the subjectivity inherent in the “reasonable decision maker” finding (which would increase in proportion to the weight of the safety case derived from assumptions and judgments, as opposed to quantified empirical evidence), and given the range of decisions “reasonable decision-makers” might make, the proposed structure of the NPRM could prove problematic. In particular, FRA wishes to achieve consistency in outcomes for comparable Product Safety Plans (PSPs), promoting fairness for all parties and predictability in terms of what will be acceptable.

FRA notes that most PSPs will be handled in accordance with the informational filing procedures, and in that context judgments by railroads will be accepted at face value if the necessary analysis has been completed and incorporated into the PSP. However, where FRA is faced with the need to make a decision whether to approve a PSP that is taken for review—given the degree of uncertainty associated with much of the underlying analysis associated with a complex processor-based system—it is important that FRA's judgment be applied. Other provisions of the proposed rule appear to anticipate that this will be done.

Accordingly, in this final rule FRA makes clear that, in any case where approval is required, FRA will make the decision

de novo

, based upon the information provided within or accompanying the PSP and the criteria set forth in § 236.913(g). The result of this change is that any judicial review of FRA's determination would focus on whether FRA came to a result compatible with that of a reasonable decision maker with the agency's expertise and knowledge of its own requirements (by law FRA may not act in an arbitrary or capricious manner), rather than whether the railroad acted as a reasonable decision maker. In any event, given the difficulty of the underlying analysis, it is important for safety and uniformity that suppliers and railroads anticipate the need to make a persuasive case to FRA that the standard is met. FRA also clarifies § 236.909(b) with regard to the finding of sufficiency.

The primary goal of the risk assessment required by this rule is to give an objective measure of the levels of safety risk involved for comparison purposes. As such, FRA believes the focus of the risk assessment ought to be the determination of relative risk levels, rather than absolute risk levels. Thus, like the proposed rule, the final rule attempts to emphasize the determination of relative risk.

The Standards Task Force realized that risk assessments may be performed using a variety of methods, so its recommendation to the Working Group and the Working Group's recommendation to RSAC, in connection with the NPRM, proposed the creation of certain guidelines to be followed when conducting risk assessments. FRA feels that these guidelines, captured in § 236.909(e) and Appendix B, adequately state the objectives and major considerations of any risk assessment it would expect to see submitted per subpart H. FRA also feels that these guidelines allow sufficient flexibility in the conduct of risk assessments, yet provide sufficient uniformity by helping to ensure final results are presented in familiar units of measurement.

One of the major characteristics of a risk assessment is whether it is performed using qualitative methods or quantitative methods. Initially, the Standards Task Force considered proposing that only quantitative risk assessment methods be used to facilitate relative risk comparison. However, suppliers noted that certain risks, such as software coding errors, cannot be fairly or easily quantified, and that the industry practice is to assess such risks qualitatively. As suggested by RSAC at

the NPRM stage of the rulemaking process and as adopted by FRA, the final rule allows both quantitative and qualitative risk assessment methods to be used, as well as combinations of the two. FRA expects that qualitative methods should be used only where appropriate, and only when accompanied by an explanation as to why the particular risk cannot be fairly quantified. RSAC further recommended to FRA (in connection with the NPRM) that railroads/suppliers not be limited in the type of risk assessments they should be allowed to perform to demonstrate compliance with the minimum performance standard. FRA agrees with the philosophy stated here and feels that state of the art of risk assessment methods could potentially change more quickly than the regulatory process will allow, and not taking advantage of these innovations could slow the progress of implementation of safer signal and train control systems. Thus, FRA is allowing risk assessment methods not meeting the guidelines of this rule, so long as it can be demonstrated to the satisfaction of the FRA Associate Administrator for Safety that the risk assessment method used is suitable in the context of the particular product. FRA believes this determination is best left to the FRA Associate Administrator for Safety because the FRA retains authority to ultimately prevent implementation of a system whose PSP does not adequately demonstrate compliance with the performance standard under the final rule.

Regardless of the risk assessment method used, FRA prefers the same method to be used for both previous condition (base case) calculations and calculations of risk associated with the proposed product. FRA prefers similar if not identical methods to be used so that meaningful comparisons can be made. However, the final rule does not mandate that identical methods be used in every case. FRA is aware that some types of risk are more amenable to measurement by using certain methods rather than others because of the type and amount of data available. For example, in almost all situations where advanced train control technology will be economically viable, safety risk data and accident histories will often be more abundant for the previous condition than for operation with the proposed product. The latter calculation will normally be based on supplier data about the product and modeling of how it is intended to be used on the railroad. Because FRA is interested in ensuring that each relative risk determination is accurate, the final rule does not outright mandate that the same assessment method be used. If a railroad does elect to use two different risk assessment methods, FRA will consider this as a factor for PSP approval (see § 236.913(g)). Also, in such cases, when the margin of uncertainty has been inadequately described, FRA will be more likely to require an independent third party assessment (see § 236.913(h)).

VI. Proceedings to Date

On August 10, 2001, FRA published the NPRM concerning the establishment of performance standards for development and use of Processor-Based Signal and Train Control systems (66 FR 42352). As noted above, the NPRM was based on the extensive work of the Standards Task Force and additional input from the entire PTC Working Group. The recommendations of the Working Group, which included those of the Task Force, were recommended by the full RSAC to FRA. Much of the information presented here was published in the NPRM. Since most readers will not have the benefit of consulting both the NPRM and the final rule together, FRA feels that republication of pertinent background and explanatory material in one document is appropriate.

The publication of the NPRM engendered much response. FRA extended the deadline for written comments in response to specific requests for additional time, and to ensure that all commenters had an opportunity to fully develop their observations (66 FR 51362 ). FRA received a total of 27 comments to the NPRM which can be found in the public docket of the rulemaking. FRA did not receive a request for a hearing and did not hold a hearing.

The comments ranged from observations regarding the historical accuracy of the origin of the practices now codified at part 236 and observations concerning the RSAC process to technical commentary regarding the risk assessment methodology proposed in the rule. The Working Group met December 4-6 of 2001 in San Antonio, Texas to consider comments that had been submitted as of that date. Additional comments were received after the initial Working Group meeting and have also been addressed in this notice. Although the later comments were received long after the deadline for comment submission, FRA has attempted to address those comments, as well.

FRA found the discussions at the December 2001 meeting useful and extremely informative. Many of the commenters were present at the meeting and contributed to the discussion, of comments. Concerns raised by public comments were ultimately resolved by FRA, yet the resolutions were informed by insights obtained in the Working Group discussions. (Minutes of these discussions are in the docket of this rule.) The most challenging issues presented by commenters required additional research and analysis by FRA staff and contractors to the agency.

As noted above, the discussions at San Antonio left open the question of when and how the base case should be adjusted. This issue was pursued by a Working Group team and addressed at the Working Group meeting of July 2003. No consensus on the subject was reached at the 2003 Working Group meeting.

At the July 2003 Working Group meeting, the Working Group did achieve consensus on several recommendations for resolution of other comments on the proposed rule and reported those recommendations to the full RSAC. During August of 2003, the RSAC reviewed the written report of the Working Group and voted by mail ballot. Those recommendations were circulated to the full RSAC for mail ballot, and responses were requested by August 14, 2003. A majority of RSAC members either voted to return the recommendations to the Working Group for reconsideration or non-concurred in the recommendations. Under RSAC procedures, the effect of this vote is to conclude RSAC action on the topic without an RSAC recommendation being to FRA. (Under RSAC procedures, any vote to return consensus recommendations to the working group must be unanimous, or the vote is scored as “non-concur.”) In any event, FRA's schedule for completion of this rulemaking could not accommodate further months of deliberation on recommendations.

FRA continued to refine the principles of this final rule in light of emerging experience with processor-based systems and risk assessment techniques until the time this final rule was submitted for review and clearance within the Executive Branch in September 2003. FRA has benefitted from the active discussion of the issues in this proceeding, including written comments and deliberations of the RSAC. Although the final resolution of the issues reflects insights gained in discussions of the Working Group and in the NPRM, FRA's final disposition of these issues is the responsibility of the agency and was based on its independent judgment.

The agency is addressing general comments in this introductory portion of the preamble to the rule. However, the majority of the comments are addressed in the section-by-section analysis of the rule text to which they apply.

VII. Comments and Conclusions on General Issues

A. Background and RSAC Process

One commenter wanted to clarify the history of the standards codified in part 236. This comment correctly identifies FRA's predecessor agency, the Interstate Commerce Commission (ICC), as having previously issued the same rules and noted that these regulations were based on the internal rules and practices of various railroads prior to World War II.

Most commenters favorably regarded the RSAC process. One comment suggested continuing the work of the RSAC by developing sample Railroad Safety Program Plans (RSPPs) and PSPs. FRA has decided to continue the work of the Working Group by involving the members in monitoring the Illinois Project and serving as a sounding board for implementation of this rule and for other PTC efforts. Although the work of the group will continue, for reasons discussed later, FRA has determined that the agency will not be involved with the creation of sample documents. A reviewed RSPP draft for the Illinois Project is already available for consideration, and RSPPs are intended to be general documents that may take a similar form on most railroads. This final rule provides a detailed outline of required PSP elements, and the wide variety of products within the scope of the rule will require a range of adaptations in the format and content of PSPs. Other comments probed the membership of the PTC Working Group and inquired about the records kept for meetings and voting. Working Group minutes after publication of the NPRM are available in the public docket. Detailed voting records indicating the way in which various parties voted are not available, since a consensus process was utilized. The Working Group and task forces operated by unanimous consensus, whereby all participants supported the recommendations of the group. This process frequently entailed the presentation of issues and vigorous debate among the four stake holder groups. In many instances, stakeholders advocated opposing views, but were persuaded to either compromise or support the opposite view to attain consensus. The minutes reflect the nature and character of the debate demonstrating various options considered and key points impacting the consensus, when consensus was achieved by the group. The consensus product was then presented to the full RSAC which had the option of accepting or rejecting the Working Group's recommendations by a majority vote. The Working Group reached consensus on the recommendations comprising the NPRM, but could not reach consensus on recommendations for the final rule. Although ballots from the full RSAC are available to the public, these typically only show support or non-concurrence for the final product, not positions on the individual issues that ultimately comprise the final rule. FRA has not kept and therefore has no avenue for providing the voting records on each issue. However, as previously noted, the text of the final rule differs in only a few major respects from the NPRM, which was based on the consensus recommendation of RSAC. In addition, FRA has attempted to note throughout the preamble issues where there were strong discussions and vigorous debate at the working group level.

B. The Performance-Based Approach

FRA has decided to pursue a performance-based standard. FRA did not receive strong comments in support of or against its decision to use a performance-based approach. Comments seem to imply a need for a performance-based approach with some prescriptive elements, in lieu of a pure performance-based approach.

C. The Performance Standard—What Will Be the “Base Case” for Comparison?

Among the comments on the risk assessment methodology was a filing from a noted signal expert who faulted the NPRM for, among other things, failing to recognize the capabilities of existing signal technology. The point was that it is incorrect to compare new technology with the rules for older technology (as in the proposed rule's construct for the “previous condition”), to the extent the rules do not fully mirror that technology's inherent advantages. Rather, the commenter would have FRA recognize the actual capabilities of existing technology built to exceed existing minimum standards in terms of its actual functions. Any other course, it was implied, could lead to a reduction in safety. The commenter cited the example that cab signal systems respond to changes in track occupancy and route conditions almost immediately as an integral characteristic of their design, even though there is no explicit requirement that they do so. By contrast, communication-based technology may experience longer delays in response due to processing time and delays along the communications path. (Note: In FRA's experience, the extent of any difference in time for response to changed conditions may vary significantly from system to system, depending upon the overall architecture of the system, system priorities, communication protocols, communication capacity, and other factors.)

Taking the commenter's point, FRA posed to the Working Group the need to recognize “best practices” under traditional signal design principles in constructing any adjusted base case. This resulted in alarm among some members, who viewed the notion as entirely open-ended and as posing the potential that the standard embodied in the rule might become increasingly strict over time. Such a case, they noted, could discourage innovation by holding new systems to an unrealistically high standard based on the existence of little-utilized but theoretically superior technology.

FRA agrees with the commenter that the previous condition should include consideration of the actual functioning of an existing signal technology in place. Indeed, this has never been in dispute with respect to a situation in which no adjustment to the base case is required. Where adjustment to the base case is needed (the contingency most prominent in the commenter's concern), FRA again agrees that the inherent functioning of industry standard technology consistent with subparts A-G of part 236 must be considered in order to avoid the potential for a decline in the actual safety of operations subject to subpart H of part 236.

However, FRA also appreciates the concern that emerged during the December 2001 Working Group discussions that an open-ended standard is not appropriate. Accordingly, FRA wants to make clear that any adjustment should be made using signal technology that is (i) standard practice in the railroad industry (or on the particular railroad, if so desired) as of publication of this final rule and (ii) compliant with subparts A-G of part 236 as amended in this final rule. FRA will accept base case scenarios that utilize this approach, without any attempt to explore what may have been “best practice” from some overall industry point of view. Further, the concept of standard technology is one that will be fixed as of a date certain, so “regulatory creep” will not occur.

During discussions with the Working Group following the NPRM, it was clear that disagreement existed regarding how best to adjust base case scenarios to accomplish the required risk assessment. Although from time to time it appeared to FRA that differing views reflected in Working Group discussions were converging to produce a clear consensus on a recommendation addressing how to proceed, the problem persisted through the December 2001, 2002, and 2003 Working Group deliberations. Despite FRA's efforts to get full consensus on a recommended resolution to the issue of the adjusted base case, which is admittedly quite complex, the Working Group could not reach consensus on a resolution to recommend to the RSAC on the issue. The Working Group tasked the issue to a team with representation from major stakeholders who met, heard the report of a contractor employed by FRA to review and improve data flows for analysis, considered a report on risk analysis that determined the effect of speed, train density and method of operation on safety risk, and apparently reached agreement on language for approval by the full Working Group. See discussion of § 236.903(e). At the final meeting of the Working Group in July 2003, the group failed to reach consensus on the recommendation proposed by the team. FRA acknowledged the need to resolve the issue on its own. Accordingly, as further detailed in the preamble, FRA has included in the final rule language resolving the issue of “triggers” for adjustment of the base case. This language is substantially refined from the general concepts embodied in the NPRM and should provide very objective guidance regarding the circumstances under which the base case must be adjusted.

At the Working Group meeting in December 2001, it also became clear that the issue of train control, as opposed to signal technology, presents a special problem. The regulatory structure for train control is essentially unchanged from issuance of the ICC's RS&I in 1937. The RS&I had its roots in ICC orders beginning in 1922, and since FRA's creation in 1967, the RS&I has been carried forward in part 236.

Realistically, for operations in excess of 79 mph (see § 236.0) FRA applies the current regulations only to existing systems. Existing systems have not been extended to additional territories in part because of the costs involved. Identified safety needs have been addressed by FRA orders. For instance, following the Chase, Maryland, collision of January 4, 1987, FRA was required by law to order installation of speed control (ATC) on all freight and commuter trains operating on the Northeast Corridor (NEC), complementing the cab signal systems already in use. Section 9, Public Law 100-342; 52 FR 44510 (Nov. 19, 1987); 53 FR 1433 (Jan. 9, 1988); 53 FR 39834 (Oct. 12, 1988). As higher speed operations came to the NEC and European signal technology provided the opportunity to achieve full PTC functions, FRA required installation of the ACSES on initial territories, noting the potential for application corridor-wide at an appropriate time. 63 FR 39343 (July 22, 1998).

When Amtrak planned higher speed operations on its Michigan line, FRA supported installation of the Incremental Train Control System (ITCS), providing a limited waiver for system characteristics that differ from traditional signaling technology. ITCS provides positive stop capability as well as speed control and can be utilized to protect work zones. Although a commenter in this proceeding questioned whether ITCS provides the same level of safety as a cab-signal based system, there can be no doubt that it far exceeds the safety provided by an intermittent train stop system. In summary, while existing rules still apply to existing systems, new higher speed operations have been subjected to higher standards.

During Working Group discussions following issuance of the NPRM, FRA considered providing generic guidance for construction of adjusted base cases for PSPs involving planned speeds that exceed 79 mph. FRA further considered participating in consultation with respect to the appropriateness of alternative approaches, based upon the facts in particular cases. FRA has concluded such guidance is necessary and has provided that guidance in the final rule. Of course, FRA cannot relinquish its responsibility ultimately to determine whether the performance standard has been met. In order to provide meaningful flexibility to utilize approaches grounded in systems now in use, optimizing use of public and private resources, FRA is prepared to consider use of base cases employing cab signals and continuous train stop, where that is commercially and operationally realistic and within a reasonable speed range. FRA does not believe that the allowance in existing regulations for intermittent train stop technology would be appropriate for extension to the new performance-based rule. While that technology has an acceptable record under existing conditions of operations, it deviates from the fail-safe requirements applicable to other signal and train control systems and has clear vulnerabilities that have been realized in practice. By the same token, consideration of systems exceeding ACS/ATC is appropriate where train speeds exceed 110 mph, based on determinations FRA has made concerning the NEC, as noted above.

Accordingly, the guidance for adjustment of base cases that is set forth in § 236.909(e) of this final rule also addresses cases involving higher speed operations. In that guidance, FRA emphasizes that high speed rail passenger service should be supported by highly competent train control technology. In view of safety concerns attendant to passenger service and the fact that much of the cost of rail passenger service is met out of public sources, FRA will, where appropriate, examine new high speed passenger rail projects and propose appropriate orders setting a floor for safety for the new systems.

With respect to the base case for the NAJPTC problem, FRA indicated a willingness to make a provisional decision on revenue service for the Illinois PTC system based upon the risk assessment approach described above. Given the configuration of that system and the scope of operations involved, FRA believes that the information under development should be sufficient to permit FRA to estimate whether the PTC system is fully adequate from a safety point of view, particularly as to the fixed block operations planned for revenue service. FRA will make available funding for a required follow-on assessment, utilizing ACS/ATC as the method of operation, so that a more complete and precise record is available to guide deployment of that technology elsewhere on the national rail system. This is particularly important because the project goals include demonstration of (i) “moving” block operations which was not contemplated by previous rules and (ii) provisions for “non-communicating” (unequipped) trains, which was contemplated but not allowed by previous rules.

D. How Does This Rule Affect Locomotive Electronics and Train Control?

The earliest train control systems were electro-mechanical systems that were independent of the discrete pneumatic and mechanical control systems used by the locomotive engineer for normal throttle and braking functions. Examples of these train control systems included cab signals and ACS/ATC appliances. These systems included a separate antenna for

interfacing with the track circuit or inductive devices on the wayside. Their power supply and control logic were separate from other locomotive functions, and the cab signals were displayed from a separate special-purpose unit. Penalty brake applications by the train control system bypassed the locomotive pneumatic and mechanical control systems to directly operate a valve that accomplished a service reduction of brake pipe pressure and application of the brakes as well as reduction in locomotive tractive power. In keeping with this physical and functional separation, train control equipment on board a locomotive came under part 236, rather than the locomotive inspection requirements of part 229. Systems of this type remain in service, and FRA regulations arguably continue to require this type of functional separation in the absence of a waiver or order applicable to the particular technology (see,

e.g.

, 49 CFR §§ 236.5, 236.507, 236.516).

Nevertheless, as the price of microprocessors decreased, and their capability increased, the original equipment manufactures (OEMs) of the various components making up the locomotive and the train control systems began individually repackaging the individual components using the enhanced microprocessor capabilities and eliminating parts and system function control points access. Access to control functions became increasingly restricted to the processor interfaces using proprietary software. While this resulted in significant simplification of the previously complex discrete pneumatic and mechanical control train and locomotive control systems into fewer, more compact and reliable devices, it also eliminated many of the parallel independent control paths previously available to train and locomotive control systems. For example, in the case of pneumatic and mechanical brake system components, the introduction of electronic air brake controllers resulted in the elimination of the mechanical valve previously used for penalty brake applications by the train control system. As a result, penalty application of brakes by the once isolated, totally segregated train control systems could now only occur if the air brakes were actuated through the locomotive electronic air brake controller.

The OEMs also began tapping certain inputs or outputs of the proprietary systems of the individual components for locomotive information. Individual gages displaying operating parameters (such as speed, brake pipe pressure, and amperage) to the engineer were replaced by single integrated electronic displays. These new microprocessor controlled locomotives now respond to operator commands, display system status, and simultaneously make numerous automatic adjustments to locomotive systems to ensure efficient operation. These new locomotive electronic controls, while designed with a high degree of attention to safety, have been built to different design standards and requirements than train control systems and have thus far not been demonstrated to fail safely. In individual cases unsafe failures have occurred. In effect, electronic control of locomotive functions has arisen in recent years without the same degree of regulation as train control functions, and in some cases products have been deployed prior to a level of analysis and testing that would be considered acceptable in a train control system. As a result, locomotive engineers have expressed concern regarding the safety characteristics of certain electronic features. Despite the best efforts of OEMs and suppliers, in some cases engineers have been relegated to use of emergency brake valves in the face of blank screens and uncertain availability of normal control functions.

FRA asked for comment on this issue. GE Transportation Systems responded requesting only that train control circuitry be clearly distinguished from locomotive electronics. GM Electro-Motive (EMD) did not respond until December of 2002, long after the official close of the comment period. EMD asked that the preamble discussion on integration of functions be stricken. EMD felt that requiring isolation of train control functions could drive up costs and slow adoption of PTC. EMD noted that many of the components and subsystems required for PTC are already on board today's locomotives (

e.g.

, power supplies, GPS, displays, data radios). EMD went on to say that in-service failures should be handled in a fail-safe manner, without any operator intervention. EMD continued “the precise mechanism for handling in-service failures is dependent upon the system architecture and must be addressed uniquely by the Product Safety Plan.” Further, EMD suggested that “partitioning and de-coupling strategies should be used to execute train control functions on the locomotive platform, thereby avoiding subjecting the entire locomotive electronics suite from falling within subpart H of part 236.”

Locomotive manufacturers can certainly provide secure locomotive and train controls, and it is important that they do so if locomotives are to function safely in their normal service environment. FRA highly encourages the long-term goal of common platform integration.

As noted in the NPRM, this rule is being prepared against a background of rapid and significant change in locomotive design. This change has direct implications for the future of both train control and locomotive control systems on board locomotives. The net result has been a merging of systems designed to different regulatory standards with differing levels of safety analysis at a single point.

This final rule does not preclude the integration of functions if the overall safety case is made with the required high degree of confidence. It should be noted that for new locomotives in passenger service, 49 CFR “ § 238.105 establishes requirements for fail-safe characteristics or safety redundancy for braking and power functions that are electronically controlled. In the near future, FRA expects to explore further the need for safety criteria for critical locomotive control functions in both passenger and freight service.

VIII. Section-by-Section Analysis

Section 209.11 Request for Confidential Treatment

FRA is amending this section, as proposed in the NPRM, to clarify existing procedures for requesting confidential treatment for documents provided to the FRA in connection with the agency's enforcement activities. The Standards Task Force was concerned that confidential documents would need to be provided to FRA under parts 234 and 236, and that FRA needed to clearly indicate that it would protect such documents. The NPRM proposed to address this issue by amending paragraph (a) of § 209.11 to indicate that the procedures governing requests for confidential treatment apply to documents provided to the FRA in connection with the agency's enforcement of both the railroad safety statutes and the railroad safety implementing regulations.

FRA received several comments on this section. One commenter suggested that no information submitted to the FRA should be treated as confidential. FRA disagrees, and notes that the Freedom of Information Act (FOIA) (5 U.S.C. 552) and the Trade Secrets Act (18 U.S.C. 1905) protect confidential information from public disclosure. Another commenter suggested that FRA confirm that information will be accorded confidential treatment. FRA cannot make any flat pronouncements about the confidentiality of information

it has not yet received. However, it is likely that the type of proprietary information to be submitted in compliance with this rule may be withheld from release as a trade secret or commercial or financial information covered under exemption 4 of the FOIA. It is not the policy of FRA to publicly disseminate such information as will be submitted in compliance with this rule. Should a FOIA request be made for information submitted under this rule, the submitting company will be notified of the request in accordance with the submitter consultation provisions of the Department's FOIA regulations (§ 7.17) and will be afforded the opportunity to submit detailed written objections to the release of information protected by exemption 4 as provided for in § 7.17(a). Because there is no public disclosure requirement in this rule, there is no need at this time to substantially revise § 209.11, but FRA intends to review its confidential business information regulations in the near future.

Section 234.275 Processor-Based Systems

Section 234.275 contains standards for highway-rail grade crossing warning systems using new or novel technology or providing safety-critical data to any product governed by subpart H of part 236. Currently part 234 provides requirements for the maintenance, inspection, and testing of highway-rail grade crossing warning systems. In September 1994, FRA issued a final rule on part 234 (Grade Crossing Signal System Safety, 59 FR 50,086, Sep. 30, 1994), but the final rule did not address processor-based warning systems which are integrated with signal and train control systems. FRA felt it was necessary for these types of systems to be addressed in subpart H because of the potential for their integration or interaction with processor-based signal and train control systems. With the large number of processor-based warning systems currently installed at the nation's highway-rail grade crossings, however, it would be unrealistic to attempt to bring all of those within the scope of subpart H. The processor-based warning systems currently in use and meeting the maintenance, inspection, and testing requirements of part 234 do an admirable job of warning highway users. The Standards Task Force formed a team of its members (prior to publication of the NPRM) to identify such items as PTC system data to be transmitted to and integrated with highway traffic control/information systems (future capability). See “Implementation of Positive Train Control Systems,” page viii (September 8, 1999). The team's focus captured the potential uses of Intelligent Transportation System (ITS) technology at highway-rail grade crossings. This section identifies which processor-based highway-rail grade crossing warning systems are subject to the requirements of subpart H of part 236.

Paragraph (a) provides that relevant definitions of part 236, subpart H, apply to this section.

Paragraph (b) provides a standard for whether a highway-rail grade crossing warning system must meet the requirements of subpart H. “New or novel technology” is defined in the third sentence of the paragraph. FRA envisions new or novel technology to include such technology as that incorporated in new designs which do not use conventional track circuits. For instance, ITS contemplates intelligent controllers that utilize data provided through advanced signal and train control systems to warn motor vehicle drivers of approaching trains. FRA does not intend for new or novel technology to include any technology used in current systems (as of the effective date of this rule), which is consistent with the approach recommended by the Standards Task Force for the NPRM.

Paragraph (c) contains requirements for equipment subject to this section. These are additional requirements which must be included in the PSP.

Paragraph (d)(1) confirms that this section in no way authorizes deviation from the requirements of the Federal Highway Administration's Manual for Uniform Traffic Control Devices (MUTCD). Current “wayside” warning devices are standardized by the MUTCD. The MUTCD sets forth the basic principles that govern the design and usage of traffic control devices for all streets and highways open to public travel regardless of type of class or the governmental agency having jurisdiction. Part VIII of the MUTCD applies to traffic control systems for highway-rail grade crossings. Traffic control systems for such crossings include all signs, signals, markings and illumination devices along highways approaching and at crossings. Traffic control systems are required to be consistent with the design and application of the standards contained within the MUTCD.

FRA received one comment generally supporting this section. The commenter concurred with the language proposed in the NPRM for this section as necessary to ensure the safety and integrity of the system throughout its life cycle.

Section 236.0 Application, Minimum Requirements, and Penalties

As a general matter, this final rule applies to all railroads, with two exceptions. First, railroads which operate only on track that is not part of the general railroad system of transportation are excepted from all requirements of part 236. Second, rapid transit operations in an urban area which are not connected to the general railroad system of transportation are unaffected by the requirements of part 236. FRA changed this language solely to standardize the application of all of the Federal regulations related to railroad safety. For additional information on the extent and exercise of FRA's safety jurisdiction, see 49 CFR part 209 Appendix A as amended on July 10, 2000 (65 FR 42544).

FRA also added a provision noting that a person may be subject to criminal penalties for violating the provisions of 49 U.S.C. 21311. FRA has similar provisions in its other regulations requiring persons or entities to report information to FRA for safety data purposes. FRA's intention here is to emphasize the importance of truthful recordkeeping and reporting, and the possible penalties for failure to do so.

Section 236.18 Software Management Control

This section requires that all railroads adopt a software management control plan to assure that software used in processor-based signal and train control equipment in service is the version intended by the railroad to be in service at each location. Simply put, a software management control plan is an inventory of software at each equipment location. As a processor-based signal and train control system ages and experiences modifications (i.e., changing operating conditions or upgrades in hardware and software), the software management control plan should be updated accordingly, providing traceability to previous versions of software. One should always be able to determine from the software management control plan precisely what software is installed at each equipment location in the field. This requirement provides an audit trail to determine if the correct software is installed at the correct locations for all processor-based signal and train control systems on a railroad.

FRA is requiring this plan because for a considerable time after the introduction to the railroad industry of processor-based equipment in signaling systems, components of such systems were not handled responsibly. It was

not unusual for railroad employees to carry in their clothing pockets printed circuit (PC) boards and the programmable memory devices (PROMS) which plug into those boards. When troubleshooting a piece of equipment, it was common practice to simply exchange the failed PC board with ones from the selection the employee had on hand until the device appeared to function as intended. The pulled board was often saved for the purpose that it might work in another device. For this and other reasons, in the Orders of Particular Applicability for processor-based train control systems on the NEC (63 FR 39343, 52 FR 44510), PROMS were required to be soldered in place in order to assure proper software versions were installed on locomotives. FRA has addressed these practices with railroads where they have been detected, but some no doubt continue to the present day.

With the proliferation of processor-based equipment and use of PROMS with both erasable and non-erasable memory, it is no longer practical to require the soldering of PROMS on PC boards. A software management plan will track the version of software which should be and is in use at all equipment locations on a signal and train control system. Therefore, a requirement for software management control plans provides adequate assurance that processor-based equipment is programmed with the correct software version.

The inventory should identify, among other things, the software by version number. FRA expects the software management control plan to identify and document for each equipment location the executive or application software name, software version number, software revision number, date of software revision, and a description of the cyclic redundancy check for verifying PROM contents. Prior to the issuance of the NPRM, the Task Force had initially considered a requirement that railroads adopt configuration management plans for existing systems, which would cover both software and hardware dealing with safety-critical aspects of processor-based signal and train control systems. Railroads expressed concern during discussions of the Working Group that such a requirement would be unduly burdensome since there is no current configuration management requirement in place, and that certainly simple one-for-one hardware changes need not be tracked. As a practical matter, FRA envisions a limited amount of hardware tracking as a necessary element of software management, since software can reside in portable hardware elements. FRA invited comment on this issue in the NPRM and received several in favor of requiring a hardware and software management control plan. These comments expressly stated that hardware tracking is a necessary element of software management. As previously noted, the subject of configuration management was contemplated by the Standards Task Force (pre-NPRM), but the group opted to recommend to the Working Group that the tracking for existing systems be limited to a software management plan. RSAC made the sure recommendation to FRA, which FRA embodied in the NPRM. FRA has noted the concerns of commenters, but FRA agrees with the decision of the Standards Task Force, pursuant to the reasoning articulated above about the undue burden such a provision would entail, not to include hardware in the software management control plan.

There is currently no recognized industry standard for software management; however FRA is aware that other computerized systems on railroads such as accounting and communications systems use configuration management control principles. FRA believes that a requirement for software management control plans on signal and train control equipment will enhance the safety of these systems and ultimately provide other benefits to the railroad as well.

Under this section, railroads are responsible for all changes to the software configuration of their products in use, including both changes resulting from maintenance and engineering control changes, which result from manufacturer modifications to the product. In FRA's view, both of these types of changes carry significant safety implications, and should be tracked by the railroad. FRA is aware that most maintenance changes involve replacement of PC boards or software on PROMS, and that changes such as replacement of resistors on PC boards are not normally made by the railroad, but rather the product manufacturer. FRA feels that it would be appropriate for the railroad to track changes no deeper than at the PROM software levels; however, it would be unrealistic and cumbersome to expect the railroad to document changes such as replacement of resistors on PC boards.

The NPRM recognized that the proposed section imposed a strict liability standard on the railroads regardless of culpability, and that railroads may be penalized in situations where they receive inaccurate information from the product manufacturer concerning manufacturer modifications which may pose a safety risk. While railroads should be entitled to rely on the manufacturers' product information, since manufacturers obviously know much more about the specifics of their products, FRA intended to hold the railroads responsible since they are primarily responsible for the safety of their operations. On the other hand, a supplier that provide inaccurate information or provides information in an untimely way would cause the railroad to be in violation of its obligation to implement a plan that contains current and accurate information. Under § 236.0(f), any person that causes a violation of part 236 is liable for a civil penalty. With regard to PSPs, the final rule requires that the railroad disclose contractual relationships with the software supplier to ensure such timely notification of safety critical changes. See § 236.907(c)(3). Product suppliers entering into contractual arrangements for product support described in a PSP must promptly report any safety-relevant failures and previously unidentified hazards to each railroad using the product. See § 236.907(c)(4).

FRA invited comments addressing the issue of whether railroads and suppliers ought to share responsibility for the duty of maintaining proper software configuration, and if so, how such responsibility can be effectively delineated. FRA received comments suggesting that the supplier should be responsible for supplying initial software configuration information with the exception of embedded proprietary software and provide software configuration information for changes impacting safety. Another commenter provided a more detailed scenario for assigning responsibility where the suppliers providing the product directly to the railroad would be responsible for verifying the safety of the executive software and the version control of that software. The software version control would clearly identify safety related changes, required supporting hardware, and the compatible interfaces. The railroad would be responsible for maintaining version control of site specific application software for products or systems, and verify the compatibility of all component interfaces.

FRA clearly intends to hold railroads responsible as they are primarily responsible for the safety of their operations, but recognizes the extreme importance to be accorded the supplier or manufacturer. In fact, FRA acknowledged the importance of the

manufacturer's role to the process by inviting comments on the scope of a product manufacturer's duty to provide accurate information concerning initial software configuration of its products and any engineering control changes and the railroads' ability to rely on the information provided by the supplier. FRA received no comments addressing this duty of accuracy by the manufacturer. FRA did however receive a comment generally addressing inclusion of processes to ensure proper configurations. See, also, discussion of § 236.907(c)(3).

Paragraph (a) of § 236.18 discusses the application of this requirement to all railroads within 6 months of the date that the final rule is published and also discusses how it applies to railroads not in operation as of the effective date of this rule. FRA intends for this requirement to apply to all systems which would be specifically excluded by § 236.911 in subpart H. For subpart H products, configuration management for each product must be specified in the PSP and the Operations and Maintenance Manual, as required by §§ 236.907(a)(13) and 236.919(b). These specifications must comply with the railroad's RSPP.

Although the issue of allowing time for compliance was not covered by the Standards Task Force, FRA proposed a 24-month time period as sufficient. FRA sought comment on this issue and received comments both in support and against the proposed 24 months. Comments seeking more time concluded that a 24-month period may not be sufficient due to the significant impact on the development processes, documentation requirements, and product development cycle for products already being designed. The Working Group favorably discussed recommending 30 months for implementation of the software management plan following its completion. Of course, the full RSAC did not make consensus recommendations to FRA on how to resolve comments on the NPRM. Nevertheless, FRA is persuaded by the rationale suggesting the need for extension of the implementation period. FRA has decided to change the language from the NPRM to allow a longer implementation period. In essence, the change extends the previously proposed period of 24 months to 36 months, with 6 months allowed to develop and adopt the plan and 30 months allowed to implement it.

Paragraph (c) replaces the language originally proposed as paragraph (b). FRA received a comment stressing the need to revise the language to require a description of the process to ensure proper configuration in lieu of the previous language which required the identification of the actual testing procedures used to confirm proper configuration. The commenter appropriately distinguished the testing procedures which would be tailored to a particular product from the overall process which could be applied to numerous products. FRA agrees with this distinction and has incorporated the suggested change. As revised, the paragraph requires software management control plans, and further requires that the plan describe the process for identifying and confirming proper configuration when any type of change occurs.

Section 236.110 Results of Tests

FRA is modifying existing § 236.110 to include record keeping requirements for processor-based signal and train control systems under part 236, subpart H, and to make it consistent with current agency policy concerning record keeping. As modified, § 236.110 would incorporate in four paragraphs new language and language from current § 236.110.

Paragraph (a) outlines four primary changes. First, FRA is adding a new section to the list of sections to which § 236.110 applies: § 236.917(a), applies to processor-based equipment covered by subpart H. Currently, there is no established safety record or performance history for these new types of systems.

Second, paragraph (a) allows for electronic record keeping. This policy is consistent with FRA's policy of encouraging electronic record keeping. FRA is requiring that carriers adopting electronic means to record results of tests first obtain FRA's approval through an application process. Requiring FRA approval will establish a process whereby FRA can ensure all the proper information (prescribed in proposed paragraph (a)) is recorded. FRA will also be able to determine where and how the electronic records are available for inspection. FRA notes that if tests are performed by Automated Test Equipment (ATE), the test equipment shall be identified by a unique number, and the test record must reflect that number.

Third, FRA is changing § 236.110 to make clear that records filed with a railroad supervisory officer with jurisdiction are subject to inspection and replication by FRA and FRA certified state inspectors. Railroad supervisory officer is intended to mean an assistant signal supervisor, signal supervisor, or any responsible divisional officer. If a railroad receives approval for electronic record keeping, the railroad shall inform FRA how and where the electronic records will be available for inspection during normal business hours. However, in the case of life cycle records required by proposed § 236.110 (c) (1), the railroad shall inform FRA of the office location(s) where these life cycle records will be kept. If electronic record keeping (in accordance with paragraph (e)) is not used for train control test records, then these records must be kept at the locomotive office nearest the test point location(s).

Fourth, paragraph (a) corrects a misprint in current § 236.110, concerning the list of sections to which it applies. The paragraph lists in proper numerical order the sections to which § 236.110 applies.

Paragraphs (b), (c), and (d) provide requirements for how long such records specified in paragraph (a) are to be maintained. Paragraph (b) simply restates a current requirement of § 236.110 (fourth sentence).

Paragraph (c) provides a requirement specifying the length of time records made in compliance with § 236.917(a) are to be kept. Paragraph (c)(1) requires that all railroads maintain records for results of tests conducted when a processor-based signal or train control system is installed or modified. These records must be retained for the life cycle of the equipment. FRA feels tracking modifications to processor-based equipment is necessary, because such changes, especially those concerning software, are not often readily apparent, yet may lead to hazardous conditions. Whenever processor-based equipment or software is modified or revised, it must be tested to ensure it is still functioning as intended. FRA believes these records will also provide valuable information to the railroad and manufacturer pertaining to the reliability of the equipment.

Paragraph (c)(2) deals with maintenance and repair records. The NPRM proposed requiring the records to be maintained for one year, or until the next record is made. There were two reasons for this requirement. First, a subset of these records (those involving hazardous events) will be tracked in the product's hazard log (see § 236.907(a)(6)). Second, many repairs to signal and train control equipment are not performed by the railroad, but rather by contractors. It would be burdensome for repair records to be tracked by the railroad for the lifetime of the product when different contractors might be performing the actual repair work over the product's

lifetime. Thus, a requirement for lifetime record retention of test records pertaining to product repairs would be substantially duplicative and burdensome. However, FRA has noted that PSPs should address issues of railroad signal employee access to repair records and hazard logs for products used throughout the railroad, as these may contain important information for performance of their duties.

Paragraph (d) simply restates a current requirement of § 236.110 (fifth sentence).

Paragraph (e) allows electronic recordkeeping in lieu of preprinted paper forms.

Section 236.787a. Railroad

FRA inserted this definition to aid in standardizing the application provisions of its regulations.

Section 236.901 Purpose and Scope

This section describes both the purpose and the scope of subpart H.

Section 236.903 Definitions

FRA received a number of comments suggesting new definitions, as well as comments addressing various definitions included in the NPRM. Among the comments suggesting new definitions was a recommendation that the final rule include a definition for the term “application software.” The commenter, however, did not propose a definition for consideration by the agency. Although the comment was considered, FRA could not recommend a definition for the term that would provide clarity to the concept.

Other commenters requested the term “train control” be defined in the rule. FRA received two suggestions for definitions of train control. One definition stated,

Train control means the primary system that instructs the train operator or other track occupant on speed or authority limits and/or automatically restricts the train or other vehicle to the speed or authority limit.

The other suggested definition stated,

Train control is a part of a system interlinked from wayside to track vehicle that automatically warns and enforces against violation of track speeds and authority limits.

The underlying concern presented by these commenters is to ensure the final rule is not misconstrued to cover systems that are not train control systems. The commenters stress the distinction between systems that can initiate enforcement and actually control the train and systems that merely provide information to those individuals controlling the train. In particular, the commenters do not want train pacing systems, alerters and End of Train Devices (EOTs) considered train control systems for purposes of this rule.

FRA agrees and realizes that historically, there was an understanding among parties in the railroad industry regarding what constitutes a train control system. FRA further recognizes that evolving technology will change the nature of what is traditionally considered train control. FRA has decided that an attempt to craft a clear definition or even a laundry list of what systems or features are considered train control or components of train control systems may actually confuse the issue. Since the technology supporting these systems is continuously evolving any list would undoubtedly be outdated at its inception or shortly thereafter. The purpose and scope provision of this rule found at § 236.901 clearly limits the rules application to “safety critical products.” FRA believes the definition of “safety critical” excludes systems that merely provide information. In lieu of attempting to craft a definition of train control, FRA has clearly articulated that pacing systems, alerters, and EOTs are not train control systems, which appears to address the immediate concern of these comments. Having satisfied the immediate concerns and given the difficulty of crafting a definition, FRA has decided to leave the term “train control” undefined.

“Train control” is, among other things, a statutory term; and FRA is keenly aware that evolving electronic architectures will present a variety of questions with respect to the applicability of subpart H. FRA believes these challenges should be considered on their merits, rather than through adoption in the present proceeding of a definition that is over- or under-inclusive.

In the definition of “safety-critical,” FRA has already said that the reach of this proceeding extends to systems that are overlaid on existing methods of operations without being integrated into those systems. Such systems monitor compliance and intervene as necessary to prevent accidents and casualties, and in the future some existing signal systems may be removed because of the safety net they will provide. Other systems providing safety-relevant information on which crews are expected to rely will also fall within this term.

In particular, FRA wishes to emphasize that systems that deliver mandatory directives in text or graphic format are also train control systems. These systems have been excepted from part 220 (Radio Communications) specifically because it was understood that special attention would need to be given to the safety and security of such systems. In light of the events of September 11, 2001, it is particularly important that oversight be provided for implementation of these systems (which FRA encourages and will seek to facilitate).

In referring to overlay systems and systems for the digital transmission of mandatory directives as train control systems, FRA recognizes the reality that both safety and operational efficiency will almost inevitably be implicated in these new technologies. Communications capability will be relied upon to move trains more efficiently, and more or less subtle changes to the underlying methods of operation will emerge. Employees will come to rely on information provided by the systems (including negative cues garnered from the lack of intervention). FRA does not object to these changes, but it is important that the changes be summed into a PSP for analysis so that pluses and minuses can be accounted for and the overall safety impact of the changes can be evaluated.

In addition to suggestions for new definitions, comments were submitted addressing various definitions proposed in the NPRM. These comments will be discussed with the corresponding explanation of each term.

The term “component” is intended to signify an identifiable part of a larger program or construction. A component usually provides a particular function or group of related functions. By requiring such a definition, FRA does not intend to overburden railroads or suppliers by requiring safety performance data and analysis on the least significant of these identifiable parts. Rather, FRA encourages railroads to take advantage of supplier data, which is normally readily available for off-the-shelf components. FRA assumes that railroads and suppliers will use discretion to appropriately define components at levels not quite as simple as a resistor, but also not quite so complex that they could not be readily replaced. For instance, FRA envisions components defined no more specifically than at the printed circuit board level, or E-PROM level.

FRA has added a definition of the term “employer.” The term employer means a railroad, or a contractor to a railroad, that directly employs or compensates individuals to perform the duties specified in § 236.921(a). This definition is needed as a result of the change in the language of § 236.921 to make clear that railroad contractors, as well as the railroads are responsible for

training their employees performing the work specified in § 236.921(a).

The term “executive software” is intended to encompass that software which affects the overall structure of a signal or train control system and the nature of the interfaces between its various subsystems and components. Executive software typically remains the same from installation to installation; the design is not changed and it is not recompiled. Executive software only changes when the manufacturer issues a revision or new version/upgrade.

The term “full automatic operation” is defined per recommendation from the Standards Task Force. This definition was crafted with respect to the railroad industry, which involves both freight and passenger operations. Other definitions come from the transit industry and involve such nuances as door control. The definition captures the notion that locomotive engineers/operators may act as both passive monitors and active controllers in an full automatic operating mode.

This rule is not designed to address all of the various safety issues which would accompany full automatic operation. Indeed, FRA would anticipate the need for further rulemaking to address the wide range of issues that would be presented should automatic operation be seriously contemplated. However, insofar as skills maintenance of the operator is concerned, the rule offers standards in § 236.927.

The term “high degree of confidence” was defined in the NPRM to mean “there exists credible safety analysis which is sufficient to persuade a reasonable decision-maker that the likelihood of the proposed condition associated with the new product being less safe than the previous condition is very small (remote).” This proposed definition was addressed by several commenters, who concluded that the term was subjective, but provided no alternative suggestion. One commenter acknowledged there is no standard that would not be subjective and noted that they could live with the inherent subjectivity of the term and concept. FRA, however, found the term's application inappropriate for subsystem and component level estimates. FRA is therefore changing the definition proposed in the NPRM to indicate that the term is to apply only at the highest level of aggregation of processor based components. FRA received one final comment addressing this term, contending the parenthetical at the end of the definition “(remote)” does not enhance or provide clarity to the concept. The word “small” is already used within the definition and needs no further explanation. In addition the word “remote” may actually add confusion instead of clarity as it has a specific meaning in the risk assessment area. FRA is changing the proposed definition by striking the parenthetical. Further, for reasons detailed above under the discussion of the performance standard, FRA is removing the language concerning the “reasonable decision-maker.” The final definition reads as follows:

High degree of confidence,

as applied to the highest level of aggregation, means there exists credible safety analysis supporting the conclusion that the likelihood of the proposed condition associated with the new product being less safe than the previous condition is very small.

The term “human factors” refers to the limitations in human performance, abilities, and characteristics that designers should consider when designing subpart H products. FRA believes that designers can improve the safety of products by considering human factors as early as possible in the design process. Design that does not account for human factors, however, can degrade safety.

The term “human-machine interface” refers to the way an operator interacts with the product. FRA feels designers who incorporate human factors design principles in a human-machine interface can increase system safety and performance.

The term “Mean Time to Hazardous Event” (MTTHE) is used to capture the parameter widely accepted in the safety/reliability engineering discipline as a scientifically based prediction of the measure of time likely to pass before the occurrence of a hazardous event. Railroads have indicated objection to the use of the term “average” or “expected” in the definition of MTTHE. FRA invited comment on this specific issue. FRA received comments generally in favor of the use of the words “average” or “expected” in the definition. Other comments addressed the term MTTHE generally. One commenter considered the concept of a mean time to a potential hazard troublesome, arguing that if a potential hazard is recognized it should be fixed. This concern and others are not likely to be addressed by a change in the definition and will be discussed with comments on the risk assessment. Another commenter objected to the use of MTTHE as confusing when there is already a commonly used term “Mean Time Between Hazardous Events” (MTBHE) that captures the concept. The commenter encouraged consideration of the IEEE definition of MTBHE to prevent confusion and encourage consistency, yet seemed comfortable with the other term and expressed no objection to the use of the words “average” or “expected” as part of the MTTHE definition. FRA believes the difference between the terms MTTHE and MTBHE is minor, and renders similar if not identical numerical values. The latter implies there has been a previous hazardous event and provides an exponential number representing some unit of time (

e.g.

years or hours) before another hazardous event occurs. Similarly, MTTHE assumes that no hazardous event has occurred and provides an exponential number representing some unit of time before the first hazardous event occurs. In either case, the number represents the average time before a component, subsystem or system failure. FRA believes that it is more appropriate to use MTTHE in light of the gravity of a railroad hazardous event, which may entail consequences that include complete loss of railroad infrastructure or even human life. FRA adopted and does not intend to change the MTTHE as a pro-active measure, which does not assume repetitive hazardous events.

The term “new or next-generation train control system” is intended to capture the notion of a train control system utilizing a relatively new technology or new generation of technology, not currently in use in revenue service. Under this definition, a significant change in the way signal and train control systems work, such as that brought about by Locomotive Speed Limiter (LSL), could trigger classification as a new or next-generation train control system. Other factors, such as the relative maturity of the product brought to market, may be relevant to this determination.

The term “predefined change” is intended to signify any change likely to have an effect on the risk assessment for the product. FRA imagines that predefined changes will include: Additions, removals, or other changes in hardware, software, or firmware to safety-critical products, application software, or physical configuration description data, under circumstances capable of being anticipated when the initial PSP is developed. FRA wants to clarify that these changes would include not only changes made directly to the product, but changes in the product's use.

FRA urges parties developing PSPs to consider all likely configurations for the product, and include such considerations in the risk assessment. This will reduce the likelihood of being

required to file a PSP amendment at a later date when the railroad wishes to slightly reconfigure their product or make a slight change to it.

The term “preliminary safety analysis” is intended to signify the process used to develop a comprehensive listing of all safety-enhancing or safety-preserving functions which safety-critical products will perform. This listing should address the requirements currently used to provide for safety of train movements in the RS&I (part 236). It should also be consistent with those requirements derived from laws of physics, such as minimum required braking distances, and provide guidance as to how such requirements should be met. FRA received one comment indicating that the term is mistakenly listed as “preliminary safety analysis” in the definition section as well as in the rule text. FRA understands that the term preliminary hazard analysis is a more common term in system safety work, but the usage in § 236.905(b) connotes a much broader scope of inquiry. Accordingly, while the term is far from ideal for this application, it has been carried forward as proposed. (The term “preliminary hazard analysis” (PHA) refers to a discrete step in the safety assessment process (specifically verification and validation) that follows or is performed in conjunction with the initial description of system requirements and leads to the creation of a hazard log. Although the term is not used in the PSP section of the rule, a PHA will typically be performed as part of the PSP development process.)

The term “product” is intended to encompass all signal or train control equipment which is processor-based, including: (i) A processor-based component of a signal or train control system, and (ii) a processor-based subsystem of a signal or train control system, or (iii) the system itself, if processor-based.

The term “safety-critical” is intended to apply to any function or system the correct performance of which is essential to the safety of personnel and/or equipment, 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. An example of the latter would be an “overlay” system that does not constitute any part of the method of operation, but maintains safe system operation should any one of the safety-critical functions be omitted or not performed correctly (

e.g.

, human error).

The term “subsystem” is intended to mean, for purposes of this rule, any defined portion of a system. Subsystems will normally have distinct functions, and may constitute systems themselves.

The term “system” is intended to mean a composite of people, procedures and equipment which are integrated to control signals or train movement within a railroad. (Adapted from Roland, Harold E. and Moriarty, Brian, “System Safety Engineering and Management,” Second Edition, John Wiley and Sons, Inc., 1990, p. 6.)

The term “system safety precedence” is intended to capture the concept of a priority of means for hazard elimination or mitigation, as stated in Military Standard 882C, “System Safety Program Requirements” (U.S. Department of Defense; January 18, 1993).

The term “validation” is slightly modified from the IEEE definition to incorporate the notion that validation procedures do not end with the end of the development cycle. Validation can be performed at any stage of a product's life cycle, including and especially after modifications are made to it. One supplier indicated that this definition ought to be modified to exclude references to what stages in a product's life-cycle validation is performed. Comments were solicited on this issue and most commenters concurred with the definition proposed in the NPRM. The dissenting commenter stressed the need to use existing definitions thereby advocating the use of the IEEE definition of validation. The commenter favors the IEEE definition because it was developed by a professional organization comprised of experts in the field, but finds nothing inherently wrong with the definition proposed by FRA. FRA notes the commenter's concern for consistency and the use of existing definitions, but is still inclined to use the definition proposed in the NPRM. Accordingly, the definition of validation does not change.

Section 236.905 Railroad Safety Program Plan (RSPP)

The system approach to safety is used pervasively in a variety of industries to reduce the risk of accidents and injuries. FRA has discussed the need for this approach to safety in three previous rulemakings: FOX High Speed Rail Safety Standards, NPRM, 62 FR 65478, (Dec. 12, 1997); Passenger Train Emergency Preparedness, final rule, 63 FR 24630, (May 4, 1998); and Passenger Equipment Safety Standards, final rule, 64 FR 25540, (May 12, 1999). System safety means the application of design, operating, technical, and management techniques and principles throughout the life cycle of a system to reduce hazards and unsafe conditions to the lowest level possible, through the most effective use of available resources. The system safety approach requires an organization to identify and evaluate safety hazards that exist in any portion of the organization's “system,” including those caused by interrelationships between various subsystems or components of that system. The organization then creates a plan designed to eliminate or mitigate those hazards. Where possible, the development of a system safety plan precedes the design, implementation, and operation of the system, so that potential risks are eliminated at the earliest possible opportunity. System safety plans are viewed as living documents, which should be updated as circumstances or safety priorities change or new information becomes available.

This section requires that railroads implement FRA-approved system safety plans known as Railroad Safety Program Plans (RSPP), enforce them, and update them as necessary. In this process, the railroad is required to implement their RSPP to identify and manage safety risks, and generate data for use in making safety decisions. Based on the philosophy of system safety planning, FRA believes that initiating this process prior to design and implementation of products covered by subpart H is necessary for development of safety-critical processor-based signal and train control systems.

Paragraph (a) requires the railroad to adopt an RSPP. FRA envisions that the RSPP will be a living document that evolves as new information and knowledge become available. Due to the critical role that the RSPP plays in this final rule, FRA is requiring the railroad to submit its initial plan for FRA review and approval prior to implementation of safety-critical products. Since the development of many safety-critical features in products will be guided by the RSPP, FRA believes that its review and approval is essential. FRA feels this role is a logical and necessary outgrowth of its responsibility to promulgate clear, enforceable, and effective safety standards. This paragraph also requires the railroad to submit its initial RSPP to FRA. FRA believes that the RSPP must be used as a guide in the earliest conceptual stages of a project.

FRA received general comments addressing the system safety approach suggesting that FRA provide sample documents or templates detailing format for the RSPP, as well as other documents required by the rule. FRA has decided that providing samples or

templates would not be appropriate, since the railroad's system safety approach will likely dictate the format for any documents submitted. FRA acknowledges that based on initial drafts of the RSPPs provided by various pilot projects, the document is general in nature and lacking details regarding new systems, making the Product Safety Plan (PSP) discussed below, and review of the PSP by FRA, crucial to FRA's safety enforcement role.

Paragraph (b) requires that the RSPP address minimum requirements for development of safety-critical products. It provides minimum requirements which the RSPP must address. FRA intends the plan to be a formal step-by-step process which covers: identification of all safety requirements that govern the operation of a system; evaluation of the total system to identify known or potential safety hazards that may arise over the life cycle of the system; identification of all safety issues during the design phase of the process; elimination or reduction of the risk posed by the hazards identified; resolution of safety issues presented; development of a process to track progress; and development of a program of testing and analysis to demonstrate that safety requirements are met. These minimum requirements are addressed in paragraphs (b)(1) through (b)(4).

FRA received general comments contending that much of the information requested in paragraph (b) is information that does not typically reside with the railroad but is normally information the developer or supplier maintains. The comments further explain that railroads, as the users of various systems, are not realistically expected to know the design criteria requested in paragraph (b). Although FRA understands and appreciates the commenter's concerns, FRA has decided that railroads will remain primarily responsible for providing the requested information, as railroads have the primary responsibility for the safety of their operations. Railroads should make the necessary arrangements to ensure this information is readily available from the supplier for submission to the agency.

Paragraph (b)(1) requires that the RSPP provide a detailed description of the tasks to be completed during the preliminary hazard analysis for every safety-critical product developed for use on the railroad. Paragraphs (b)(1)(i) through (b)(1)(iv) list several types of tasks which must be included in the RSPP. Railroads have indicated that requirement (iv), the identification of the safety assessment process, appears to duplicate (ii), the complete description of risk assessment procedures. FRA intends the risk assessment to be a measurement tool, used to benchmark safety levels and hopefully to provide valuable safety insight to designers. FRA views the safety assessment process as a more comprehensive process in which safety concerns are effectively identified and addressed at all stages of product development.

FRA sought comment on the railroads' claim and FRA's distinction. FRA received several comments concluding that the two concepts were confusing, as presented. One comment proposed language to further clarify the distinction. The commenter proposed that (b)(ii) be revised to read, “A complete description of risk assessment procedures used to benchmark safety/risk levels.” The commenter offered a revision of (b)(iv) which would read, “The identification of the complete safety assessment process used to identify and address all safety concerns at all stages of product development.” FRA did not find the language particularly enhancing or clarifying and has decided not to adopt the language for the final rule. Another commenter suggested that requiring a complete description of the risk assessment procedures may actually work in opposition to the goal of using the latest evaluation techniques. The commenter recommended a summary description of the risk assessment procedure which references a complete description of either a recognized standard or detailed procedure be included in the RSPP. Although FRA understands the commenter's point, FRA has decided to allow the rule text to remain the same. FRA believes the discussion noted above has served to clarify the distinction between the risk assessment and safety assessment. Although the commenters suggested the rule text was confusing, each commenter correctly described the two concepts and their differences. FRA does not believe a rule text change is necessary or helpful here.

Paragraph (b)(2) addresses how the RSPP identifies validation and verification methods for the initial design/development process and future changes, including any standards to be complied with in the validation and verification process. The objective is that a railroad create and maintain documentation which will facilitate an independent third party assessment, if required (see § 236.915(h)). FRA believes this process will also help to refine and standardize validation and verification processes for each railroad. FRA received one comment addressing this paragraph. The commenter suggested that an internal supplier's standards and procedures related to design verification and validation be exempt from this requirement. FRA believes that the approving agency, as well as a third party reviewer may have a need to see the actual standard. FRA has decided to make a slight change in the rule text to accommodate the commenter's concern. The last sentence of paragraph (b)(2) is revised to read, “The RSPP must require that references to any non-published standards be included in the PSP.” This change allows FRA the flexibility to require the supplier to provide a copy of the standard if necessary.

Paragraph (b)(3) requires that the RSPP contain a description of the process used during product development to identify and consider the human-machine interfaces (HMIs) which affect safety. The requirements set forth in this paragraph and in Appendix E attempt to mandate design consideration of, among other concerns, sound ergonomic design practices for cab layout in order to minimize the risk of human error, attention loss, and operator fatigue. FRA believes it is necessary for railroads/product manufacturers to be able to demonstrate how their human factors design requirements are developed and that they are developed at an early stage in the product development process.

Paragraph (b)(4) explains how the RSPP identifies configuration management requirements for products subject to subpart H. FRA believes that this requirement is necessary to help railroads maintain consistency in the configuration management of the products they use.

Paragraph (c) describes the initial review and approval procedures FRA will utilize when considering each railroad's RSPP. Paragraph (c)(1) indicates that the petition must be delivered to the Associate Administrator for Safety, for his or her respective action. Paragraph (c)(2) establishes the timing of the petition process. FRA normally responds in some fashion within 180 days with one of the responses listed (granting the petition, denying the petition, or requesting additional information). However, there may be circumstances in which FRA is unable to respond as planned. Consequently, paragraph (c)(3) indicates that inaction by FRA within the 180-day period means the petition will remain pending. The petition is not approved until the railroad receives an affirmative grant from FRA.

FRA invited and received comments addressing FRA's handling of RSPP petitions beyond 180 days after filing.

Commenters expressed concern that FRA will delay their implementation process, by allowing petitions to remain pending. In addition, commenters view this approach as a significant departure from typical approval procedures where petitions are deemed approved, unless written notification is given to the contrary. Railroads believe the delay will impact the costs of their projects. FRA does not anticipate that petition review will typically take more than 180 days. However, in the unlikely instance that the agency is unable to process petitions within the normal period of time, the agency has allowed itself an open window to address petitions with complicated or problematic issues. FRA firmly believes that its occasional need to extend the review period for petitions will not significantly delay production or impact costs greatly and has decided against changing the approval process.

Paragraph (c)(4) provides that FRA be able to reopen consideration for any previously-approved petition for cause. This will help ensure that FRA has the ability to preempt problems erupting as a result of widely disparate safety priorities being implemented throughout the industry. Commenters who expressed concerns regarding paragraph (c)(3) also expressed concerns about paragraph (c)(4), citing similar reasons. These comments contend that the ability to reopen approved petitions for further review on the basis of unspecified criteria would only further delay implementation and in some cases may actually disrupt service. FRA disagrees with this comment as well, as this measure will be used in only rare cases. FRA has imposed a requirement upon itself to provide the railroad with specific reasons for such actions. This measure requires the agency to be able to provide clearly articulated reasons, not vague concerns for reopening the petitions. As noted with paragraph (c)(3), FRA foresees reopening petitions for cause in only the most problematic cases where any delay, cost or potential disruption in service will be balanced by FRA's responsibility to ensure safety.

Paragraph (d) establishes requirements for how and when RSPPs can be modified. First, FRA believes railroads can and should modify their RSPPs at any time. However, when RSPP modifications related to safety-critical PSP requirements are involved, FRA feels its approval is necessary. Paragraph (d)(1) requires that railroads obtain FRA approval in these cases. In any other case, the railroad would be able to implement the modification without FRA approval. Paragraph (d)(2) explains that procedures for obtaining FRA approval of RSPP modifications are the same for those used to obtain initial FRA approval, with the added requirements that the petition identify the proposed modifications, the reason for the modifications, and the effect of the modifications on safety.

Section 236.907 Product Safety Plan (PSP)

This section describes the contents of the Product Safety Plan (PSP) that must be developed to govern each product. The provisions of this section require each PSP to include all the elements and practices listed in this section to assure these products are developed consistent with generally-accepted principles and risk-oriented proof of safety methods surrounding this technology. Further, each PSP must include acceptable procedures for the implementation, testing, and maintenance of the product.

FRA's existing regulations covering signal and train control systems do not include requirements of such detail since they are based on minimum design standards of long standing application that are recognized as appropriate to achieve the expected level of performance. As a result of the industry's desire to move to “performance-based standards” for signal and train control systems, FRA believes it is necessary to include the provisions contained in this section in order to assure safety of railroad employees, the public, and the movement of trains. In addition, FRA must ensure that key elements in the development of products correlate with the concepts of proven standards for existing signal and train control systems.

FRA sought comments on whether the elements contained in this section are adequate or whether there are other requirements that should be included to assure safety. FRA received one comment concluding that no additional requirements were necessary to ensure safety. FRA received another comment which did not explore the PSP requirements and their relationship to safety, but looked at their relationship to cost. The commenter concluded that generally, much of the information required in this section is not currently required for processor-based systems, as they are typically designed independent of railroad operational characteristics. The comment further reasoned that requiring an analysis of the system inclusive of these operating characteristics will increase the cost of development. FRA believes that suppliers and railroads will develop generic PSPs for most products that adequately address the requirements of the new subpart without substantial additional expense. It is true that the use of general purpose processors and their associated software brings about the availability of a large number of additional features and capabilities that may or may not be used in support of the primary intended function of the designer. As part of the design and evaluation process it is essential to ensure that an adequate analysis of the features and capabilities is made to minimize the possibility that conflicts may result by the use of features resulting in a software fault. Since this analysis is a normal cost of software engineering development, we do not believe it imposes a significant cost beyond what should already be done when developing safety critical software.

Paragraph (a)(1) requires that the PSP include system specifications that describe the overall product and identify each component and its physical relationship in the system. FRA will not dictate a specific product architecture but will examine each to fully understand how various parts relate to one another within a system. Safety-critical functions in particular will be reviewed to determine whether they are designed on the fail-safe principle. FRA believes this provision is an important element that can be applied to determine whether safety is maximized and maintainability can be achieved. During early discussions, prior to publication of the NPRM, concern emerged regarding the level of detail required in describing the product. FRA requested but received no comments on this issue. Accordingly, the rule language will remain the same.

Paragraph (a)(2) requires a description of the operation where the product will be used. FRA is essentially attempting to determine the type of operation on which the product is designed to be used. One signal system supplier noted that this paragraph may not be applicable to products which are independent of some or all of the railroad operation characteristics described in this paragraph. FRA requested comment on this issue and one commenter gave an example of a product where one (or potentially several) of the operational characteristics would not apply. The example cited was an interlocking controller where gross tonnage would not be relevant. In this instance, FRA would expect a short statement indicating which operational characteristics did not apply and why they were not applicable.

Paragraph (a)(3) requires the PSP to include a concepts of operations

document containing a description of the product functional characteristics and how various components within the system are controlled. FRA believes that this provision along with that contained in paragraph (a)(1) above will assist in a thorough understanding of the product. FRA will use this information to review the product for completeness of design for safety by comparing the functionalities with those contained in standards for existing signal and train control systems. While FRA will not prescribe standards for product design, FRA will require that the applicant compare the concepts contained in existing standards to the operational concepts, functionalities, and control contemplated for the product. For example, FRA requirements prescribe that where a track relay is de-energized, a switch or derail is improperly lined, a rail is removed, or a control circuit is opened, each signal governing movements into a block occupied by a train, locomotive, or car must display its most restrictive aspect for the safety of train operations. FRA intends to apply the same concept, among others, when reviewing PSPs to assure such minimum safety requirements exist.

Paragraph (a)(4) requires that the PSP include a safety requirements document that identifies and describes each safety-critical function of the product. FRA intends to use this information to determine that appropriate safety concepts have been incorporated into the proposed product. For example, existing regulations require that when a route has been cleared for a train movement it cannot be changed until the governing signal has been caused to display its most restrictive indication and a predetermined time interval has expired where time locking is used or where a train is in approach to the location where approach locking is used. FRA will apply this concept, among others, to determine whether all the safety-critical functions are included. Where such functionalities are not clearly determined to exist as a result of technology development, FRA will expect the reasoning to be stated and a justification provided describing how that technology provides equivalent or greater safety. Where FRA identifies a void in safety-critical functions, FRA will expect remedial action prior to use of the system. FRA received no comments specifically addressing the adequacy of this process for preserving railroad safety and has not changed the rule text.

Paragraph (a)(5) requires the PSP to contain a document demonstrating that the product architecture satisfies the safety requirements. The product architecture is expected to cover both hardware and software aspects which identify the protection developed against random hardware faults and systematic errors. Further, the document should identify the extent to which the architecture is fault tolerant. This provision may be included in the requirements of paragraph (a)(1).

Paragraph (a)(6) requires that a hazard log be included in the PSP. This log consists of a comprehensive description of all hazards to be addressed during the life-cycle of the product, including maximum threshold limits for each hazard (for unidentified hazards, the threshold shall be exceeded at one occurrence). The hazard log addresses safety-relevant hazards, or incidents/failures which affect the safety and risk assumptions of the product. Safety-relevant hazards include events such as false proceed signal indications and false restrictive signal indications. If false restrictive signal indications happen with any type of frequency, they could cause train crew members or other users (roadway workers, dispatchers, etc.) to develop a lackadaisical attitude towards complying with signal indications or instructions from the product, creating human factors problems. Incidents in which stop indications are inappropriately displayed may also necessitate sudden brake applications that may involve risk of derailment due to in-train forces. Other unsafe or wrong-side failures which affect the safety of the product will be recorded on the hazard log. The intent of this paragraph is to identify all possible safety-relevant hazards which would have a negative effect on the safety of the product. Right-side failures, or product failures which have no adverse effect on the safety of the product (

i.e.

, do not result in a hazard) would not be required to be recorded on the hazard log.

FRA received a comment suggesting that FRA's reference to threshold limits in the hazard log is essentially the same as quantitative risk assessment. This commenter recommended use of the MIIL-STD-882 classifications. This issue was addressed in discussions at the San Antonio meeting of the Working Group. Opposition to the use of the MIL-STD-882 was articulated, as well as concern that the comment was not really applicable to the section. FRA has decided that the MIL-STD-882 is not appropriate here and accordingly, the text will remain the same.

Paragraph (a)(7) requires that a risk assessment be included in the PSP. FRA will use this information as a basis to confirm compliance with the minimum performance standard.

Paragraph (a)(8) requires that a hazard mitigation analysis be included in the PSP. The hazard mitigation analysis must identify the techniques used to investigate the consequences of various hazards and list all hazards addressed in the system hardware and software including failure mode, possible cause, effect of failure, and remedial actions. A safety-critical system must satisfy certain specific safety requirements. Leveson, Nancy G., “Safeware: System Safety and Computers,” Addison-Wesley Publishing Company, 1995. To determine if these requirements are satisfied, the safety assessor must review and assess the results of the following tasks:

1. Hazards associated with the system have been comprehensively identified.

2. Hazards have been appropriately categorized according to risk (likelihood and severity).

3. Appropriate techniques for mitigating the hazards have been identified.

4. Hazard mitigation techniques have been effectively applied.

FRA does not expect that the safety assessment will prove that a product is absolutely safe. However, the safety assessment should provide evidence that risks associated with the product have been carefully considered and that steps have been taken to eliminate or mitigate them. Hazards associated with product use need to be identified, with particular focus on those hazards found to have significant safety effects. Then, the designer must take steps to remove them or mitigate their effects. Hazard analysis methods are employed to identify, eliminate and mitigate hazards. Under certain circumstances, these methods will be required to be reviewed by an independent third party for FRA approval.

FRA received a general comment indicating that the requirements of paragraphs (a)(6) and (a)(8) should be combined and required as one document. The concern presented here is similar to one echoed in several comments regarding the format for both the RSPP and PSP. Some comments requested sample documents to be used as templates by the railroads. FRA is not dictating the format in which the information should be submitted, as the variation in railroad and product will likely drive the outcome of the document. However, FRA believes that documents submitted for the North American Joint PTC Illinois project can be looked to as examples, but are not intended to be a template for submissions. FRA believes the issue of combining the requirements of

paragraphs (a)(6) and (a)(8) into one document is one of format and should be resolved by the submitting railroad. Submissions for the Illinois project can be consulted for examples.

Paragraph (a)(9) also requires that the PSP address safety verification and validation procedures. FRA believes verification and validation for safety are vital parts of the development of products. Verification and validation requires forward planning and, consequently, the PSP should identify the test planning at each stage of development and the levels of rigor applied during the testing process. FRA will use this information to assure the adequacy and coverage of the tests are appropriate.

Paragraph (a)(10) requires the PSP to include the results of the safety assessment process by analysis that identifies each potential hazard and an evaluation of the events leading to the hazard; identification of safety-critical subsystems; the safety integrity level of each safety-critical subsystem; design of each safety-critical subsystem; results of a safety integrity analysis to assess the safety integrity level achieved by the safety-critical subsystems; and ensure from the analysis that the safety integrity levels have been achieved. FRA expects the safety assessment process to be clearly stated and thorough according to the complexity of the product. FRA realizes that paragraphs (a)(9) and (a)(10) may overlap in terms of requirements, and considered consolidation of the concepts required in these two paragraphs. FRA decided to leave the rule language unchanged. The agency has an expectation of some repetition in the railroad's submissions.

Paragraph (a)(11) requires a human factors analysis which addresses all human-machine interfaces (HMI's) and all product functions to be performed by humans to enhance or preserve safety. FRA expects this analysis to place special emphasis on human factors coverage of safety-critical hazards including the consequences of human failure to perform. Each HMI is to be addressed including the basis of assumptions used for selecting each such interface, its effect upon safety and identification of potential hazards associated with each interface. Where more than one employee is expected to perform duties dependent upon the output of, or input to, the HMI, the analysis must address the consequences of human failure to perform singly or in multiple. FRA uses this information to determine the HMI's effect upon the safety of railroad operations. The human factors analysis must address all criteria listed in Appendix E, unless approval is obtained from the Associate Administrator for Safety to use other equally suitable criteria. FRA believes that designers must have this flexibility.

Paragraph (a)(12) requires the railroad to include in its PSP the training, qualification, and designation program for workers whether or not railroad employees who will perform inspection, testing, and maintenance tasks involving the product. FRA believes many benefits accrue from the investment in comprehensive training programs which, among other things, are fundamental to creating a safe workforce. Effective training programs can result in fewer instances of human casualties and defective equipment, leading to increased operating efficiencies, less troubleshooting, and decreased costs. FRA expects any training program to include employees, supervisors and contractors engaged in railroad operations, installation, repair, modification, testing, or maintenance of equipment and structures associated with the product.

Paragraph (a)(13) requires the PSP to identify specific procedures and test equipment necessary to ensure the safe operation, installation, repair, modification and testing of the product. Requirements for operation of the system must be succinct in every respect. The procedures must be specific about the methodology to be employed for each test to be performed that is required for installation, repair, or modification including documenting the results thereof. FRA will review and compare the repair and test procedures for adequacy against existing similar requirements prescribed for signal and train control systems. FRA will use this information to ascertain whether the product will be properly installed, maintained, and tested.

Paragraph (a)(14) provides that products may be so designed that existing requirements contained in part 236, subparts A, B, C, D, E, and F are not applicable. In this event, the PSP must identify each pertinent requirement considered to be inapplicable, fully describe the alternative method used that equates to that requirement and explain how the alternative method fulfills or exceeds the provisions of the requirement. FRA notes that certain sections of part 236 may always be applicable to subpart H products. For example, § 236.0 prescribes, among other requirements, the conditions and speeds for which block signal systems and automatic cab signal, train stop, and train control systems must be installed. These are benchmark safety levels related to operational considerations against which the safety performance of innovative newer systems will be compared. Further, FRA will determine whether the product fully embodies the concepts of proven standards for existing signal and train control systems, as captured by subparts A-G of part 236.

Paragraph (a)(15) requires the PSP to include a description of the security measures necessary to meet the specifications for each product. Security is an important element in the design and development of products and covers issues such as developing measures to prevent hackers from gaining access to software and developing measures to preclude sudden system shutdown. The description should identify the formal method used in development of the system software, identify each hazard and its consequence in event of failure that was mitigated by using the formal method, and indicate the results of the formal proofs of correctness of the design. Where two or more subsystems or components within a system have differing specifications, the description should address the safety measures for each subsystem or component and how the correctness of the relationships between the different specifications was verified. Where two formal methods are used in developing safety-critical software from the same specification, the description should explain why the more rigorous method was not used throughout development process and the effect on the design and implementation.

FRA received several comments on paragraph (a)(15), including one that suggested refining the concept of “security measures.” FRA is reluctant to modify the text or refine the concept, as FRA is concerned about all dimensions of security.

Paragraph (a)(16) requires warnings to ensure safety is addressed in the Operations and Maintenance Manual and warning labels placed on the equipment of each product as necessary. Such warnings include, but are not limited to, means to prevent unauthorized access to the system; warnings of electrical shock hazards; cautionary notices about improper usage, testing or operation; and configuration management of memory and databases. The PSP should provide an explanation justifying each such warning and an explanation of why there are no alternatives that would mitigate or eliminate the hazard for which the warning is placed.

Paragraph (a)(17) requires the railroad to develop comprehensive plans and

procedures for product implementation. Implementation (validation or cutover) procedures must be prepared in detail and identify the processes necessary to verify the product is properly installed and documented, including measures to provide for the safety of train operations during installation. FRA will use this information to ascertain the product will be properly installed, maintained, and tested.

Paragraph (a)(18)(i) requires the railroad to provide a complete description of the particulars concerning measures required to assure products, once implemented, continue to provide the expected safety level without degradation or variation over their life cycles. The measures must be specific regarding prescribed intervals and criteria for testing; scheduled preventive maintenance requirements; procedures for configuration management; and procedures for modifications, repair, replacement and adjustment of equipment. FRA intends to use this information, among other data, to monitor the product to assure it continues to function as intended.

Paragraph (a)(18)(ii) provides a PSP requirement to include a description of each record concerning safe operation. Recordkeeping requirements for each product are discussed in § 236.917.

Paragraph (a)(19) requires that the PSP include a description of all backup methods of operation and safety critical assumptions regarding availability of the product. FRA believes this information is essential for making determinations about the safety of a product and both the immediate and long-term effect of its failure. Railroads have indicated concern that product availability is not in itself a safety function, and that therefore this requirement may be too broad. FRA has contended that availability is directly related to safety to the extent the backup means of controlling operations involves greater risk (either inherently or because it is infrequently practiced). FRA invited comment on this issue but received none.

Paragraph (a)(20) requires that the PSP include a complete description of all incremental and predefined changes.

Paragraph (b) addresses predefined changes. PSPs must identify the various configurable applications of the product, since this rule mandates use of the product only in the manner described in its PSP (see § 236.915(d)). FRA recognizes that railroads' rights-of-way vary with regard to the number of tracks and layouts of interlockings, junctions and stations over which train movements are made at various speeds and density. Products may contain identical subsystems or components having configurable features to provide the capability of controlling a variety of track layout schemes. The PSP must clearly set forth those attributes in such equipment that may be employed or expunged without degradation or variation of safety over the life cycle of the system, as well as the impact such changes may have in the risk assessment. Satisfaction of the minimum performance standard must be demonstrated for each predefined change. Also, the PSP must fully describe the procedures to be followed for each change and the inspections and tests necessary to assure the system functions as intended.

Paragraph (c) addresses incremental and maintenance changes and changes classified as safety-critical software upgrades, patches, or revisions. The term “incremental change” is intended to capture the concept of planned version changes to a product, usually software-type changes. FRA believes these changes will be necessary in order for products to acquire capabilities to perform added functions as safety requirements change. The goal of this paragraph is to encourage as many subsequent product modifications as possible to be considered by initial designers during the product development stage, in order to avoid, to the extent possible, changes made by persons with no link to initial safety design considerations.

The NPRM recognized that hardware and software suppliers were in the best position to know about problems with the products used by the railroads. Commenters indicated that much of the information generally needed for compliance with this rule typically resides with the supplier. Suppliers will likely have information regarding problems with their products. Given the importance of proper configuration management in safety critical systems, FRA believes it is essential that railroads learn of and take appropriate action to address all safety critical software upgrades, patches or revisions for their processor-based system, subsystem, or component, whether or not the railroads have experienced a failure of their system, subsystem, or component. At the same time, FRA recognizes the complexity of the electronics market. Some software will be provided by non-railroad suppliers, often embedded in hardware. Other software may be imported from non-railroad applications; and neither the railroad nor the system integrator (supplier to the railroad) may have access to all information regarding coding errors or hardware failures. Business failures will occur, and competent supply houses may lose their technical edge over time.

FRA seeks to encourage commercial relationships that will contribute to product support over the long term; however, what is perhaps more critical to FRA's oversight role is obtaining a clear understanding of the robustness of the information network available to the railroad for life cycle product maintenance and thus of the residual risk associated with any gaps in that network.

Accordingly, FRA is responding to su

This text is long and has been trimmed here. Open the source document for the complete record.