[Federal Register: August 10, 2001 (Volume 66, Number 155)]
[Proposed Rules]               
[Page 42351-42396]
From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr10au01-34]                         


[[Page 42351]]

-----------------------------------------------------------------------

Part V





Department of Transportation





-----------------------------------------------------------------------



Federal Railroad Administration



-----------------------------------------------------------------------



49 CFR Part 209 et al.



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


[[Page 42352]]


-----------------------------------------------------------------------

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: Notice of proposed rulemaking.

-----------------------------------------------------------------------

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

DATES: Written Comments. Comments must be received by October 9, 2001. 
Comments received after that date will be considered to the extent 
possible without incurring additional expense or delay.
    Public Hearings: Upon specific request, FRA will hold public 
hearings as appropriate to receive oral comments from any interested 
party.

ADDRESSES: Comments should be sent to the Docket Clerk, Docket 
Management System, U.S. Department of Transportation Room PL 401, 400 
Seventh Street, SW., Washington, DC 20590-0001. If you wish to receive 
confirmation of receipt of your written comments, please include a 
self-addressed, stamped postcard.
    The docket management system is located on the Plaza level of the 
Nassif Building at the Department of Transportation at the above 
address. You can review public dockets there between the hours of 9 
a.m. and 5 p.m., Monday through Friday, except federal holidays. You 
can also review comments on-line at the DOT Docket Management System 
web site at http://frwebgate.access.gpo.gov/cgi-bin/leaving.cgi?from=leavingFR.html&log=linklog&to=http://dms.dot.gov.
    You may submit comments electronically by accessing the Docket 
Management System web site at http://frwebgate.access.gpo.gov/cgi-bin/leaving.cgi?from=leavingFR.html&log=linklog&to=http://dms.dot.gov and following the 
instructions for submitting a document electronically.

FOR FURTHER INFORMATION CONTACT: William H. Goodman, Staff Director, 
Railroad Signal Program, Office of Safety, FRA, 1120 Vermont Avenue, 
NW, Washington, DC 20590 (telephone: 202-493-6325); Grady C. Cothen, 
Jr., Deputy Associate Administrator for Safety Standards, FRA, 1120 
Vermont Avenue, NW, Mail Stop 25, Washington, D.C. 20590 (telephone: 
202-493-6302); Cynthia B. Walters, Office of Chief Counsel, FRA 1120 
Vermont Avenue, NW, Mail Stop 10, Washington, DC 20590 (telephone: 202-
493-6064); or David T. Matsuda, Office of Chief Counsel, FRA, 1120 
Vermont Avenue, NW, Mail Stop 10, Washington, DC 20590 (telephone: 202-
493-6046).

SUPPLEMENTARY INFORMATION:

I. Statutory Background

    The Federal Railroad Administration (FRA) has broad statutory 
authority to regulate all areas of railroad safety. 49 U.S.C. 20103(a); 
49 CFR 1.49. 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. 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 in large part 
governed the installation and removal of signal equipment for most of 
the previous century.
    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. For example, in the area 
of railroad signal and train control systems, FRA has issued 
regulations, found at 49 CFR part 236 (``Part 236''), addressing the 
security of signal apparatus housings (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 shall be parts located in 
Title 49 of the Code of Federal Regulations.

II. 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 Secs. 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 positive train control (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 needed to facilitate realization of the potential of 
electronic control systems and for safety and efficiency.
    FRA has already used its 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 (UP)/Burlington 
Northern Santa Fe (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. (CSX) Communication-Based Train 
Management (CBTM) project in Georgia, and the Alaska Railroad PTC 
project. FRA recently granted conditional

[[Page 42353]]

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 responsible tests, 
demonstrations, and implementations, the need for controlling 
principles in this area is becoming increasingly obvious. This 
rulemaking provides the forum for identifying and codifying those 
principles.
    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.'' The RSERA mandated that the Secretary conduct a 
safety inquiry to assess, among other areas, the status of advanced 
train control systems and the need for federal standards to ensure that 
such systems provide for positive train separation and are compatible 
nationwide. FRA conducted such an inquiry and submitted a comprehensive 
Report to Congress on July 8, 1994.
    As part of this Report, FRA called for implementation of an action 
plan to deploy PTC systems (``Railroad communications and Train 
Control,'' FRA, July 1994). 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.
    Following through on the Report, the FRA 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 the Pacific Northwest, Michigan, 
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 (``Administrator'') asked the Railroad Safety Advisory 
Committee to address several issues involving PTC.

III. Railroad Safety Advisory Committee (RSAC)

A. RSAC

    Since 1993, FRA has been taking action to promote earlier and more 
extensive participation by all interested parties in the agency's 
regulatory processes. That year, the Administrator conducted a series 
of roundtables on all aspects of FRA's safety program. FRA initiated 
its first formal negotiated rulemaking in 1994 on the topic of roadway 
worker safety.
    FRA also conducted outreach and a review of its regulatory program 
under the President's Regulatory Reinvention Initiative and the 
National Performance Review. FRA concluded that railroad safety would 
be best served if the agency varied its traditional ``hear and decide'' 
regulatory style to a new one founded on consensus among those who are 
benefitted and burdened by the agency's regulations. Implicit in this 
change is the concept that decisions regarding the best approach to 
resolution of safety issues should be made with the full participation 
of all affected parties.
    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 Transit Association (APTA)
American Short Line and Regional Railroad Association (ASLRRA)
American Train Dispatchers Department/BLE (ATDD/BLE)
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 Employes (BMWE)
Brotherhood of Railroad Signalmen (BRS)
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) (non-voting)
League of Railway Industry Women (non-voting)
National Association of Railroad Passengers (NARP)
National Association of Railway Business Women (non-voting)
National Conference of Firemen & Oilers
National Railroad Construction and Maintenance Association
Amtrak
Railway Progress Institute (RPI)
Safe Travel America
Secretaria de Communicaciones y Transporte (non-voting)
Sheet Metal Workers International Association
Tourist Railway Association Inc.
Transport Canada (non-voting)
Transport Workers Union of America (TWUA)
Transportation Communications International Union/BRC (TCIU/BRC)
United Transportation Union (UTU)
National Transportation Safety Board (NTSB) (non-voting)
Federal Transit Administration (FTA) (non-voting)

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 recommendations to FRA for 
action on the task. These recommendations are developed by consensus. 
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. If the working group is unable to reach consensus 
on recommendations for action, FRA moves ahead to resolve the issue 
through traditional rulemaking proceedings.
    Recommendations from RSAC come in all varieties. RSAC may recommend 
continued implementation of existing measures, voluntary initiatives by 
individual parties, concerted voluntary initiatives by several parties, 
amendment of existing regulations, new regulatory requirements, or 
enactment

[[Page 42354]]

of legislation, as appropriate. The advice and recommendations of RSAC 
form the basis for this proposed rule.
    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.

B. The PTC Working Group

    FRA gratefully acknowledges the participation and leadership of 
representatives of the following organizations who served on the PTC 
Working Group:
    AAR, including members from

BNSF
Canadian National
Conrail
CSX
Metra
Norfolk Southern Railway Company
UP
Amtrak
AASHTO
APTA
ASLRRA
ATDD/BLE
BLE
BMWE
BRS
FRA
FTA (non-voting)
HSR/MAG LEV
IBEW
NTSB (non-voting)
RPI
UTU

    In order to efficiently accomplish the three tasks assigned to it 
involving PTC issues, the PTC 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 on September 8, 1999. Report of the Railroad Safety 
Advisory Committee to the Federal Railroad Administrator, 
``Implementation of Positive Train Control Systems,'' (September 8, 
1999). The Data and Implementation Task Force will be involved in 
monitoring implementation of PTC technology on the joint Illinois/AAR/
UP/FRA project.
    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.
    In addition to providing assistance from FRA staff and staff from 
the Volpe National Transportation Safety Center, 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.

C. The Standards Task Force

    The Working Group, consisting of both the Data and Implementation 
Task Force and the Standards Task Force, held a meeting at Ponte Vedra 
Beach, Florida in November 1997 to set the direction of the Standards 
Task Force. An informal first meeting of the Standards Task Force was 
held in Washington DC on December 18, 1997, followed by the first 
formal meeting on February 25, 1998, in Fort Worth, Texas. The 
Standards Task Force is primarily responsible, with the FRA Office of 
Chief Counsel and Office of Safety, for drafting this proposed rule.
    After the initial informal meeting, the Standards Task Force met 
almost every month until the last meeting in New Orleans, LA on June 
28-29 of 2000. Much documentation was produced at these meetings, due 
to extensive discussions, presentations and tutorials. This 
documentation has been placed in the docket for this rulemaking.
    The primary mission of the Standards Task Force was to develop 
regulations that would address the new PTC systems, as well as 
subsystems and components thereof. PTC systems were described as 
achieving three core functions: (1) Preventing train-to-train 
collisions (positive train separation); (2) enforcing speed 
restrictions, including civil engineering restrictions and temporary 
slow orders; and (3) providing protection for roadway workers and their 
equipment operating under specific authorities.
    At each meeting, proposed standards were continually developed and 
modified. The text of the proposed regulation became known as the 
``Master Draft.'' Four primary stakeholder groups worked on the Master 
Draft and presented their own views and opinions as to what should be 
included in the regulations. As such, consensus was very difficult to 
obtain. The four stakeholder groups involved were: (1) The federal 
government, (2) railroad management, (3) railroad labor, and (4) 
railroad signal and train control system suppliers. The first three 
groups had voting powers. The supplier group did not have voting 
powers, but their input was essential and valuable to the other 
interest groups, especially railroad management, their primary 
customers. All Standards Task Force meetings were open to all 
interested parties, and on the average, 30 to 35 people attended. The 
final two meetings recorded over 50 attendees each. Any attendee was 
considered a member of the Standards Task Force and had the right to 
express an opinion at the meeting. However, when consensus was called 
for, only actual voting members from the PTC Working Group were 
counted.
    In December 1999, the Standards Task Force reached consensus on 
most outstanding issues. Chiefly, these included the adoption of risk 
assessment criteria, requirements for independent third party review of 
validation and verification, applicability of the proposed rule to 
existing systems, life cycle recordkeeping and reporting, and related 
matters.
    On June 29, 2000, the Standards Task Force presented its consensus 
recommendation to the entire working group. The PTC Working Group 
accepted the recommendation with minor changes and forwarded its 
consensus recommendation to RSAC, which approved it on September 14, 
2000.

IV. Major Issues

A. Why a Performance-Based Approach?

What is a Performance Standard?
    During the Standards Task Force discussion, FRA noted that the 
existing ``Rules, Standards and Instructions'' (Part 236) take a 
performance-oriented approach at the functional level,

[[Page 42355]]

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 
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 that the group pursue higher-level performance 
standards. Supplier and labor representatives agreed to this approach, 
and FRA has endeavored to support the Standards Task Force in pursuing 
it.
    Early in the deliberations of the Standards Task Force, carrier 
representatives requested that FRA arrange presentations on the use of 
performance standards in lieu of prescriptive regulations. The group 
heard from representatives of the Research and Special Programs 
Administration (RSPA), Federal Highway Administration's Office of Motor 
Carrier Safety (now Federal Motor Carrier Safety Administration 
(FMCSA)), 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. The Working Group 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., 49 CFR 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-related 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 (though just how specific the 
requirements should remain is one of the subjects of this proceeding).

Criteria for Evaluation of Performance-Related Approach

    The discussion that follows identifies some of the general 
considerations that apply to use of performance standards and some of 
the practical factors that come into play with respect to the safety of 
processor-based signal and train control technologies.
    In response to the report of the Vice President's Commission on 
Aviation Safety and Security, the Federal Aviation Administration (FAA) 
published a brief ``Performance-Based Regulations Guide'' (October 31, 
1997). That guide notes four ``substantive criteria'' that can be used 
to determine whether regulations can be written in a performance-based 
manner:
    1. Can the regulatory requirement be stated in terms of a practical 
goal that can be understood by an individual or company (e.g., meeting 
a prescribed climb gradient with one engine inoperative)?
    2. Will a regulation stated in performance terms be enforceable?
    3. Will a performance-based regulation discriminate against smaller 
companies?
    4. Is it possible to establish an equivalency rule that will itself 
be considered a performance-based regulation? (In FAA terminology, ``an 
equivalency rule'' is one that is based upon a command-and-control 
requirement but allows the regulated party to demonstrate that an 
alternative approach provides an equivalent level of safety.)

The FAA guide noted performance-based regulations should not be used 
if:
    1. Congress has mandated a specific outcome (e.g., ``no smoking'' 
on domestic flights).
    2. The standard would be so vague as to be unenforceable (e.g., 
``fly safely'').
    3. The FAA cannot agree on an acceptable alternative to a command-
and-control standard (e.g., the age 60 rule [for air transport pilots] 
could be eliminated only if the FAA could prescribe medical and flight 
testing standards that would provide an equivalent level of safety).

These criteria are generally applicable to the issue presented by this 
proposal, and other possible concerns can be added. For instance, what 
if administration of a performance standard would involve too much cost 
to all regulated entities, small entities only, or the government? What 
if the performance standard is clear, but verifiable only after the 
fact and thus enforceable only in a reactive sense? What if the 
standard is very clear, but the analytical techniques needed to

[[Page 42356]]

verify compliance are poorly developed or are not validated?
    FRA has identified several criteria of its own with respect to 
promulgating a performance standard for this area of regulation: 
simplicity, relevancy, reliability, cost, and objectivity.
    First, FRA feels the standard should be simple, because it will 
apply to many regulated entities. If the standard requires complex 
mathematics, there may be no way for many of the entities to comply, 
and if complicated enough, the standard may be beyond FRA's capacity to 
enforce. For instance, the Standards Task Force has been exposed to 
many briefings on mathematical techniques used to measure product 
safety. Often, the mathematics were extremely complicated, the issues 
surrounding selection of a model so esoteric that only a small fraction 
of the expert population present fully understood the issues, and at no 
point was there a consensus that any particular technique was 
technically superior.
    Second, FRA feels the standard should be relevant with respect to 
safety. There may be many convenient measurable qualities of processor-
based systems which are not relevant to safety. For example, the mean 
time to repair a product subsystem may or may not necessarily be 
relevant to safety, depending upon the backup method of operation in 
place.
    Third, FRA believes the standard should be reliable in that the 
test applied should yield similar results each time it is applied.
    Fourth, FRA believes demonstrating compliance with the standard 
should not be unduly expensive. Train control systems have a very good 
safety record. The cost of proving compliance with the standard should 
not cost more than the benefits it will bring. Furthermore, a standard 
could be so exacting that it would prevent the deployment of systems 
which would very likely improve safety, but which do not meet some 
extremely difficult or expensive test. Thus a purported safety standard 
might actually impose safety costs.
    Fifth, FRA feels the standard should be objective. A completely 
objective standard would allow for compliance to be determined through 
scientific study or investigation. This is critical from a regulatory 
perspective, because FRA feels it would not be fulfilling its safety 
mission if it could not verify compliance with the performance 
standard. Also, an objective standard would allow for sound business 
planning with respect to budgeting for and development of processor-
based systems. Thus, FRA can realize additional safety benefits from 
this standpoint.

Development of the Proposed Standard

    The Standards Task Force considered only two different performance 
standards, yet determining an adequate method for demonstrating 
compliance was the key factor in the Standards Task Force's final 
decision.
    The first standard proposed for discussion by the Standards Task 
Force was a standard which would have required that the implementation 
of proposed systems lead to safety improvements of 33% to 50%. This 
standard was proposed in order to address the uncertainties involved in 
the safety determinations. The theory behind the proposal was that an 
actual increase in safety by a discrete relative amount would overcome 
any uncertainties involved in the safety assessment process. In 
addition to the objectivity problems involved in not necessarily 
requiring a certain level of confidence in the safety measurements, the 
most disconcerting issue to the group was the cost of such a standard. 
It would impose burdensome safety and operational costs. The safety 
costs would result primarily from railroads not being able to replace 
products with those which would improve safety by less than the desired 
margin. The operational costs would result from not being able to 
replace a product with one that was equally as safe, but less costly. 
These shortcomings were too severe for the Standards Task Force to 
warrant further consideration of this option.
    The only other performance standard considered by the Standards 
Task Force was the one which led to the proposed rule: that new 
products must not degrade safety. This standard was not formally agreed 
to by the Standards Task Force until a means for demonstrating 
compliance could be agreed upon. The remainder of the discussions 
focused on the various ways in which compliance with this standard 
could be determined, and which of them is the most appropriate.
    The first proposal under this standard would have required a 
comparison of the sample means of the distributions of risk for the 
proposed product and the current system. This proposal would require 
demonstration with a minimum ninety-five percent confidence level that 
the likelihood that the distribution of risk for the proposed system is 
not less than the sample mean for the current system. The Standards 
Task Force found cost to be the most serious concern with this 
proposal. For relatively simple products this approach may be cost-
effective. It would be moderately expensive, as it requires some 
modeling of the risk, but the cost of modeling might still be less than 
the costs of complying with a specification standard. The most 
significant costs would be incurred when a proposed system takes 
advantage of current-generation, high-capability processors. The 
expense of computing time required to generate statistically 
significant modeling results would be prohibitive.
    A slightly different approach would be to test the standard 
deviations of the differences in sample means. This approach is not 
much more complicated than simply testing against the standard 
deviations. The cost would be roughly the same, however, this approach 
would pose reliability problems. If the number of simulation cycles 
were held to a fixed ratio between cycles for the current system and 
cycles for the proposed product, the standard deviation of the sample 
mean would decrease in proportion to the square root of the number of 
simulation cycles. Furthermore, the looseness of the assumptions would 
affect reliability of this approach as a measurement tool. There could 
also be significant problems with non-random re-selection of paths in 
simulations.
    The next approach proposed was to weight each risk calculation by a 
factor of uncertainty, and then run the simulation to see what the 
relationship is between current risk levels and levels of risk 
associated with use of the proposed product. This approach would 
require a higher level of confidence for a lower subjective confidence 
in the underlying assumptions. This option is more complex than any yet 
discussed by the Standards Task Force, and does not appear to be either 
reliable or objective. The Standards Task Force ultimately concluded 
that this test is too subjective for their purpose.
    Also suggested was an approach utilizing statistics of extremes, or 
extreme value theory. This objective technique is favored for risk 
analysis in civil engineering and environmental science applications 
and is designed to overcome the problems which arise when using 
traditional distribution models to analyze low probability, high 
consequence events. It is sufficiently complex that there was no 
consensus in the group as to its effectiveness for train control 
applications, although the University of Virginia continues to provide 
the group with more information on this technique. An informal survey 
of group members revealed that fewer than one tenth of an expert group 
claimed to be familiar with extreme value analysis. Thus, the Standards 
Task Force concluded

[[Page 42357]]

unfamiliarity with this approach within the industry would probably 
make it expensive to require.
    The final mathematical approach suggested was described as a 
Bayesian belief network. This is also a complicated test, which appears 
not totally objective. This approach would require the railroad to show 
by some high evidentiary standard, such as ``demonstrating to a high 
degree of confidence,'' that the proposed product would result in no 
loss of safety. It is this final test which FRA proposes. The Standards 
Task Force has developed more specific criteria for satisfying the 
performance standard under this approach using current safety 
engineering practices and principles within the industry.
    Although advantages of and concerns with the proposed standard are 
addressed in the sections which follow, FRA seeks comments addressing 
the decisions reached by the Standards Task Force concerning the 
various standards and compliance methodologies considered and rejected.

Advantages of a Performance-Based Standard

    This NPRM presents the highest level performance requirements ever 
attempted by FRA. To informed advocates of performance-based 
regulations, the reasons for taking this course are obvious. The 
emerging technologies documented in the RSAC's Report to the 
Administrator (``Implementation of Positive Train Control Systems,'' 
September 8, 1999), reflect an extensive array of electronic 
applications, including short-range radio frequency (RF) data links 
(transponders), medium-range RF data links, train location systems 
employing GPS/DGPS positioning supported by inertial guidance and track 
database analysis, and logic controllers placed at central office 
locations, on the wayside and onboard trains. Inputs may be derived 
from a variety of on-board systems, automatic equipment identification 
systems, two-way end-of-train telemetry, existing signal and train 
control systems, and other sources. Additional technologies are on the 
horizon, and others will no doubt emerge between the date of 
publication of a final rule in this proceeding and the next revision of 
the regulations by FRA.
    While some new train control systems may not yield all of the same 
safety benefits that are supported by traditional track circuits (e.g., 
detection of some broken rails), they may be capable of very nearly 
eliminating train-to-train collisions and addressing the other PTC core 
functions. Data derived from train control applications may be used for 
improved train management, crew management, and other business 
purposes. Ultimately, PTC technology may permit the transfer of train 
movement information for use in providing warning at highway-rail grade 
crossings under conditions that are, today, prohibitively expensive.
    In short, the future benefits of emerging railway electronic 
systems will be substantial, and suppliers and carriers will need a 
great deal of flexibility to avoid inadvertent limitations on the 
growth of important safety systems. This rulemaking was commenced to 
facilitate introduction of these new technologies. A performance-based 
approach should be the most powerful means of accomplishing that 
objective because it would:
     Provide the maximum flexibility to design capable systems, 
increasing the likelihood that all possibilities will be carefully 
explored;
     Permit designers to optimize systems to address safety and 
other needs, making systems more attractive to those making capital 
allocation decisions; and
     Avoid inappropriate requirements that could drive up costs 
and put the technology out of reach for years to come.

Concerns With a Performance-Based Standard

    This notice embodies a very high-level approach to performance 
standards that would offer unprecedented flexibility for carriers to 
design and deploy new signal and train control technologies. At the 
same time, it would require extensive documentation of the safety of 
the system prior to its introduction in revenue service. This approach 
has many profound advantages, and notable disadvantages, that deserve 
scrutiny in this rulemaking.
    FRA has also noted significant obstacles to successful 
implementation of performance standards in this context, as well as 
reservations with respect to the utility of such standards. These 
concerns are sufficient to warrant caution and a vigorous public 
debate.
    The first concern that has arisen is the static nature of a fixed 
performance standard grounded in current safety performance levels. As 
noted above, this proceeding is intended to facilitate safety 
improvement through accelerated introduction of new technology. The 
proposed performance standard described below, which basically provides 
that the safety of a new system may not fall below the base condition 
(existing technology, with certain adjustments), sets a modest 
objective for suppliers and railroads. However, progress is not the 
inevitable result of technological innovation. It is at least 
theoretically possible for a railroad to claim greater efficiencies 
associated with new technology, add modest safety enhancements that go 
beyond the capabilities of existing signal technology, but delete 
certain functionalities associated with the existing system or 
implement the system in a manner that includes significant safety 
vulnerabilities. The net result could be cost savings with no advance 
in safety. Yet, unlike today, FRA would lack leverage under the 
regulations to insist that known vulnerabilities in the system be 
corrected, even if that could be done on a highly cost effective basis. 
(FRA would retain its general authority under the Signal Inspection 
Act, but the extent to which that authority might be impaired could 
only be determined after extensive litigation, should its exercise be 
challenged.)
    The thought that a performance standard might stagnate safety 
improvements is not a fanciful concern. Since economic deregulation of 
the railroad industry (signified most notably by enactment of the 
Staggers Rail Act of 1980), railroads have progressed toward 
profitability principally by cutting costs. Strong intermodal 
competition has caused the railroads to turn much of the resulting 
savings back to shippers in the form of reduced contract rates. 
Particularly in the wake of major mergers and consolidations (a 
condition applicable to each of the four largest railroads today), the 
pressure from the financial community for cost reduction is 
particularly strong. This has sometimes led to management decisions 
based on short-term considerations. FRA regularly deals with the 
effects of this phenomenon in the context of Safety Assurance and 
Compliance Programs on the various properties.
    Clearly, the railroads have managed to improve their overall safety 
performance during the past 20 years while also cutting costs, in part 
by using technology to good advantage. However, the low-hanging fruit 
is largely gone. Managers and employees are increasingly asked to do 
more with less, which is a confining business practice. Properly 
implemented, new signal and train control technology can help reduce 
workload requirements while also improving asset utilization. 
Improperly implemented, the technology could stagnate safety 
improvements.
    Second, doubt remains whether the relevant technical, scientific, 
and railroad signaling communities are fully

[[Page 42358]]

prepared to support implementation of this rule. FRA has funded 
significant research into the safety of processor-based systems. See, 
e.g., ``Analytical Methodology for Safety Validation of Computer 
Controlled Subsystems,'' (Luedeke, John, (Battelle) for Volpe National 
Transportation Systems Center; DOT-VNTSC-FRA-95-8 (April 1994)). 
Administration of existing regulations, including consideration of 
waivers associated with novel train control proposals, has provided FRA 
with the opportunity to become familiar with strengths and limitations 
of the safety programs of major signal suppliers. Field compliance 
efforts have provided a reasonably good view of railroads' efforts to 
implement processor-based technologies. FRA's observations from this 
experience follow.
    The field of system safety for safety-critical control systems is 
relatively young and remains in flux. Military Standard 882C, ``System 
Safety Program Requirements'' (U.S. Department of Defense; January 18, 
1993), provides an overall framework for safety planning and analysis. 
A growing body of literature documents good practice in the field. See, 
e.g., Leveson, Nancy G., ``Safeware: System Safety and Computers,'' 
Addison Wesley Publishing Company, Inc., 1995. FRA purchased and 
distributed to Standards Task Force members copies of ``Safety-Critical 
Computer Systems'' (Storey, Neil; Addison-Wesley Longman (Harlow, 
England 1996)), a text addressing the subject matter in a way 
characterized as suitable for a final-year undergraduate or masters-
level program in engineering. The FAA, the Nuclear Regulatory 
Commission, and other Federal agencies have addressed this issue in 
various ways and continue to conduct relevant research. Parallel 
efforts internationally include the European Committee for Electrical 
Standardization (CENELEC) standard prEN50129 ``Railway Applications--
Safety-Related Electronic Systems for Signaling,'' (May 18, 1998).
    Railroad signal suppliers maintain a strong emphasis on the safety 
of their systems. However, formal processes to conduct and document 
safety analyses for new products are not uniform in their content; and 
FRA is aware of departures from what might be deemed acceptable within 
the framework of a rule implementing the proposals set forth below. In 
general, suppliers employ varying safety assurance concepts for their 
products and are not currently able to provide quantitative information 
concerning the projected life-cycle safety performance of new products. 
The vigorous emphasis on more formal methods of safety assurance in the 
supply community is exemplified by the recent adoption by the Institute 
of Electrical and Electronic Engineers, Inc. (IEEE), of the new 
``Standard for the Verification of Safety for Processor-based Systems 
Used in Rail Transit Control'' (No. 1483). The lack of complete 
consensus on the issue of proofs of safety is perhaps best exemplified 
by the fact that the IEEE standard just referenced does not address 
validation of these systems.
    Recognizing that any performance standard must provide a level 
playing field for the supply community and clear decisional criteria 
for FRA's review of safety documentation, FRA asked the Standards Task 
Force to focus specifically on the requirements for verification and 
validation and the associated quantization of safety (further discussed 
below). Although the supply community representatives were able to 
agree with other Standards Task Force members on general principles 
that should apply to these safety processes and the metric of Mean Time 
to Hazardous Event (MTTHE), suppliers were not able to agree to provide 
estimates of MTTHE based on fully quantitative inputs derived from 
uniform analytical methods. The possibility remains, therefore, that 
estimates of residual risk from different suppliers might have 
different meanings and be based on differing levels of confidence. As 
public comment is received and considered, FRA will continue to work 
with the parties to ensure that information provided in support of 
various products is reasonably comparable.
    FRA has also funded research into the application of risk 
assessment techniques to railroad operations and has made use of risk 
studies in the development of its own rules and in the evaluation of 
system safety estimates presented by various parties. Although FRA 
decision-making with respect to safety has always been founded on a 
keen appreciation for the elements of risk (event likelihood, severity, 
and an appropriate means for normalizing exposure), FRA recognizes that 
future advances in safety and transportation efficiency will 
necessitate a heavier reliance on often complex risk assessment 
techniques, as well as system safety principles. Quantitative risk 
assessments can enlighten decision making by taking into consideration 
a variety of relevant factors, providing a means of testing the 
sensitivity of key assumptions, and projecting the risk environment 
into the future. In an ideal circumstance, risk assessment may help 
identify critical system safety decisions and shed light on their 
mitigation well before the potential for hazardous events is realized 
in the field.
    However, at the outset it must be said that use of risk assessment 
to determine compliance with performance criteria embodied in a 
regulation presents an awkward problem. Practitioners of risk 
assessment are the first to point out that they do not purport to 
provide information that will predict actual levels of performance. 
Rather, they provide analysis that suggests the ``relative safety'' of 
the projected system in relation to a base case construct against which 
it is evaluated. This is a particularly powerful technique to improve 
the safety of a system, if properly executed. But the results do not 
constitute direct proof that a particular level of safety will be 
achieved.
    Obviously, this problem could be ``solved'' by simply requiring 
that an analysis meeting certain criteria show an improvement in 
safety. However, FRA believes that this approach would ask the wrong 
question and result in an increasingly parochial focus on the 
techniques of risk assessment and their proper execution, to the 
exclusion of the concrete safety issues presented by particular 
systems. FRA was not established to regulate risk assessment 
techniques, and attempting to do so would only inhibit the growth of 
the discipline. Accordingly, FRA has insisted that the proposed 
performance criterion be stated in absolute terms, with latitude 
afforded to scale the analytical effort to the problem at hand. 
Obviously, in the end FRA would have to be convinced that the 
particular showing was persuasive with respect to the likelihood that 
the new system would meet or exceed the safety performance of the 
existing system.
    Further, quantitative risk assessment as applied to the safety of 
railroad operations is best viewed as an art, rather than a science. A 
proper analysis must correctly describe salient elements of the 
operating system, correctly assess the contribution of the risk 
dimension under review to key scenarios, accurately estimate the 
frequency with which the risk will arise, accurately describe the 
severity of hazardous events that may occur, and fairly evaluate the 
impact of mitigating measures on the prevention, or reduction in 
severity, of the hazardous event. This requires that the analyst(s) be 
fully conversant with the railroad operating system, that input data be 
available (and be properly selected if various data are available), 
that the analysis be structured to produce a credible result, and that 
the result be

[[Page 42359]]

appropriately characterized. There are challenges associated with each 
of these steps.
    FRA is also concerned that a requirement for a risk assessment 
based on probability or likelihood will refocus safety efforts during 
development from optimization to post-design justification. That is, 
FRA fears that the focus will shift to proving that the product is safe 
enough after it has been designed. This concern is fueled by such facts 
as: (1) Subsystems and components involving software and/or human 
factors do not readily lend themselves to risk quantization as electro-
mechanical ones do, (2) risk calculations for current operations will 
most likely be limited in precision, and (3) early FRA involvement in 
the product development process is not mandated. As William D. 
Ruckelshaus, former two-time Director of the U.S. Environmental 
Protection Agency (EPA), has pointed out, ``risk assessment data can be 
like the captured spy; if you torture it long enough, it will tell you 
anything you want to know.'' Leveson at 60.
    In practice, FRA has had occasion to substantially discount the 
value of risk assessments in some cases, while relying heavily on the 
results (together with other information) in other cases. FRA expects 
that the quality of risk assessment practice will improve over time, as 
experience is gained and as peer review strengthens the quality of 
analysis.
    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 an ``Axiomatic Safety-
Critical Assessment Process'' (ASCAP). At the request of the Standards 
Task Force, FRA engaged the University of Virginia to develop the ASCAP 
model as a risk assessment ``toolkit'' for use in implementing this 
proposed rule. The initial challenge for the ASCAP team and contractor 
has been to describe the relative safety of 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 will be the safety of operations on the same line 
should a traffic control system be installed. The second comparison 
case will be implementation of the proposed CBTM system, an innovative 
technology that addresses the PTC core functions.
    As this proposed rule was being finalized for review and 
publication, the ASCAP effort was progressing toward generation of the 
base case and an initial comparison case. The University of Virginia 
principal researcher continued to meet with the ASCAP team providing 
peer review and support for the project. Data was being assembled and 
reviewed for suitability. A Human Factors Team had been established to 
assist in formulating input assumptions with respect to the anticipated 
actions of employees under various conditions associated with the three 
methods of operations.
    FRA believes that the ASCAP model (more fully described below) will 
represent a significant step forward in the quality of risk assessment 
methodologies related to train control. If successful, the technique 
may provide a level of analytical refinement significantly exceeding 
other known techniques. However, the success of this effort is not 
inevitable, given the degree of technical difficulty, the relative 
paucity of detailed data available for use within the model, and the 
uncertainties with respect to the role of human factors under the three 
cases. (For instance, CSXT and it employees who will be responsible for 
maintenance of various aspects of the system have not had experience 
with respect to maintenance of CBTM in the field. It may be difficult 
to project all failure modes that could be associated with routine 
maintenance and with modification of the system over its life cycle.) 
While it should be possible to benchmark the estimated risk for the 
base case and the traffic control system against experience on the CSXT 
line and for similar operations nationally, being certain of the 
validity for the CBTM case would require extensive, long-term 
experience in revenue service.
    Indeed, for many risk assessment problems, the base case will not 
be ``known'' in a statistical sense before the work begins because 
there will not have been sufficient exposure in the specific territory 
affected, under current or projected conditions, to make collision and 
other data representative of actual long-term performance. This will 
require somewhat elaborate construction of a base case scenario (as in 
the current CSXT ``dark territory'' case mentioned immediately above) 
to permit consideration of the extent to which local conditions may 
affect national statistics that could otherwise be applied to the 
problem.
    The Standards Task Force has discussed the fact that some margin of 
error will be associated with both base and comparison cases in any 
risk assessment. The group has discussed the need to employ sensitivity 
analysis to determine the effect of key assumptions and the 
desirability of putting a value on the extent to which the underlying 
analysis supports confidence in estimated risk, expressed as a point 
value or range. After examining several options, the group agreed to a 
standard fairly characterized as one of reasonableness, with respect to 
the current state of the art.
    Whatever formal risk values emerge from an assessment conducted in 
conformity with the proposed rule, some statistical variability would 
apply to post-implementation review of systems. This is true both 
because risk assessments will provide an imperfect view of a very 
complex reality, but also because the wide dispersion of the pertinent 
risk and the seemingly random nature of potentiating events (e.g., a 
maintenance of way employee leaving a switch open on the main line) 
make precise predictions impossible. For instance, take the case of 
removal of an existing automatic block system (ABS) and its replacement 
by a non-vital communication-based train control system overlaid on 
track warrant control. The safety documentation for this ``product,'' 
as reviewed under this proposed rule (including part 235), might show 
an actual accident history of 2 severe events in the last 20 years, an 
estimated base risk level of 2.5 such events, and a predicted accident 
frequency for the new system of one severe event over 20 years into the 
future. Should the actual experience under the new system (with no 
change in traffic levels) be one severe event and one moderate event in 
the first five years, this could indicate the emergence of risk factors 
not foreseen when the analysis was conducted or simply the occurrence 
of events well within the range of expected outcomes.
    FRA is particularly concerned that, under these circumstances, the 
dialogue between the FRA and the railroad not proceed based only upon 
the narrow technical details of risk assessment. Instead, the dialogue 
should center around the extent to which the events that occurred 
involved unnecessary harm to employees or the public and require 
remedial action that is practical and cost effective. If the public is 
to be served, FRA should not be shackled by its own performance 
criteria, and pro forma compliance with risk assessment should not bar 
inquiry into whether, as a practical matter, systems ``may be operated 
safely without unnecessary risk of personal injury.'' No amount of 
research is likely to make risk assessment a pure science, and no 
amount of litigation over it will protect employees and the public from 
patent hazards identified after the fact. FRA is not reassured by the 
discussion that led

[[Page 42360]]

to this proposal that this concern is frivolous, and FRA will not 
proceed with a final rule in this proceeding until a way has been found 
to resolve it.
    FRA invites comments specifically addressing any of the agency's 
concerns detailed in this proposal.

Application to Part 235: Risk Assessments and Material Modification 
of Systems

    This set of regulatory proposals includes performance-based rules 
for new signal and train control systems (including subsystems and 
components) but does not alter part 235, which governs applications for 
discontinuance or material modification of a signal system. FRA 
believes that risk assessment techniques can be helpful in evaluating 
applications for modification or discontinuance of existing signal 
systems. However, FRA is not prepared at this time to be bound by risk 
assessment outcomes in evaluating these applications.
    In enacting the Signal Inspection Act, the Congress both authorized 
FRA to require installation of signal systems and required that FRA 
review their removal or any reduction in their effectiveness. FRA has 
been reluctant to order new signal system installations, because it 
appears that the market functions reasonably well due to the natural 
constraints associated with the growth of rail traffic. Railroads 
continue to install traffic control systems where capacity requires it, 
and those investments provide efficiencies that benefit the health of 
the railroads while also enhancing safety over the long term, both 
directly and indirectly.
    FRA has also been reluctant, however, to allow removal of signal 
systems where current travel levels benefit from the safety that they 
provide, even if the agency would not order installation of a new 
system under the same circumstances. Tools such as the CRAM II model 
and the ASCAP model should assist FRA in determining the circumstances 
under which signalization is helpful. However, FRA is not convinced 
that the precision those tools can provide will always exceed in 
quality the judgment of railroad safety professionals who are 
intimately familiar with the territory and operations, particularly as 
applied to matters of limited scale.
    FRA has also been reluctant to allow, and in recent years has been 
steadfastly opposed to allowing, elimination of automatic cab signal 
(ACS) and automatic train control (ATC) functions--functions that 
directly address, to a considerable degree, the issues of collision 
avoidance and protection of roadway workers. Certainly risk assessment 
techniques will be useful in the future to analyze proposals to replace 
ACS/ATC systems with communication-based PTC alternatives. However, FRA 
would not expect to seriously entertain arguments, based upon elaborate 
risk analysis, that less certain safety strategies or modest declines 
in traffic would support removal of ACS/ATC systems.

B. How Does This Proposal Affect Locomotive Electronics and Train 
Control?

    This rule is prepared against a background of rapid and significant 
change in locomotive design. This change has direct implications for 
the future of train control systems onboard locomotives.
    In the past, train control functions and systems for control of 
normal locomotive operating functions have been kept separate. Train 
control apparatus has applied independent of the normal throttle and 
braking functions, which were traditionally accomplished by mechanical 
and pneumatic controls used by the locomotive engineer. Cab signals and 
ATC/ATS appliances have included a separate antenna for interfacing 
with the track circuit or inductive devices on the wayside. The power 
supply and control logic for train control have been separate from 
other locomotive functions, and cab signals have been displayed from a 
special-purpose unit. Penalty brake applications have been accomplished 
by direct operation of a valve that accomplishes a service reduction of 
brake pipe pressure, and the train control system also functions to 
``knock down'' the locomotive's tractive power. In keeping with this 
physical and functional separation, train control systems on board a 
locomotive have been considered exclusively within Part 236, rather 
than the locomotive inspection requirements of part 229.
    Onboard locomotives, braking and throttle functions have 
traditionally worked independently, with discrete mechanical and 
pneumatic controls. As electronic systems were initially introduced, 
controls remained separate and distinct. Until recently, electronic 
controls have been packaged incrementally by various vendors (e.g., 
speed sensor vendor, brake system vendor, locomotive manufacturer). In 
locomotives that employ this arrangement, control functions may be 
distributed among several processors using proprietary software.
    During the 1990's locomotive manufacturers (``original equipment 
manufacturers'' or ``OEMs'') began to integrate discrete functions, 
tapping certain inputs or outputs of the proprietary systems for 
informational or control purposes. Most new locomotives are controlled 
by microprocessors that respond to operator commands while making 
numerous automatic adjustments to locomotive systems to ensure 
efficient operation. In lieu of individual gages, operating parameters 
(such as speed, brake pipe pressure, and amperage) are displayed to the 
engineer on a single electronic display. The AAR has established 
Locomotive System Integration (LSI) criteria to promote compatibility 
among systems and uniformity in the information displayed to the 
locomotive engineer.
    Currently, manufacturers are deploying central processors that may 
``run'' a variety of systems simultaneously in a multi-tasking 
environment. While ``integration'' has been largely functional in the 
past, including the common display, the control systems themselves may 
be unified in the future.
    Locomotive manufacturers are preparing more capable electronic 
platforms to support locomotive and train control functions, but to 
date FRA has taken the position that train control functions should 
remain separate. Historically, and within the context of existing ACS/
ATC systems, train control functions have been required to be carried 
out in a failsafe manner by ``vital'' systems. Locomotive electronic 
controls, while designed with a high degree of attention to safety, 
have thus far not been demonstrated to fail safely with a high degree 
of reliability, and in individual cases unsafe failures have occurred. 
In effect, electronic control of locomotive functions has arisen in 
recent years without regulation, and in some cases products have been 
deployed prior to adequate analysis and testing. 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.
    Very clearly, certain locomotive controls are highly safety-
critical, and FRA is working with the OEMs to encourage adoption of 
formal safety methods in the design, verification and validation of 
locomotive systems. FRA is confident that, over the next few years, 
OEMs and their suppliers will succeed in improving the quality of 
safety-relevant locomotive electronic

[[Page 42361]]

systems. As that occurs, integration of train control functions with 
other on-board functions will be appropriate. Until that time, FRA 
believes that cab signal and train control functions, including 
innovative PTC technologies, should continue to operate independent of 
locomotive information and control systems. In the context of 
developing PTC projects, and with respect to application of required 
ACS/ATC systems on new locomotives, FRA will for the time being 
continue to insist upon separation of locomotive and train control 
functions (absent an affirmative showing by the OEM that essential 
functions are effectively isolated and implemented in a failsafe manner 
as required in part 236). However, both for today and the future, FRA 
sees value in use of the electronic display for cab signal and train 
control functions, if the generation of the relevant attributes of the 
display can be made failsafe (with the exception of the very low-
probability possibility of a transient fault in the display itself).
    FRA seeks comment on this issue and the circumstances under which 
the final rule should authorize or prohibit integration of locomotive 
control and train control functions. Should integration of these 
functions be allowed? If they are integrated, how should in-service 
failures of various kinds be handled (e.g., failure of one of two 
displays available to the engineer or failure of the conductor's 
display). If these functions are integrated, should the entire 
locomotive electronic system be subject to verification and validation 
under the new performance standards? If so, to what extent might train 
control functions be partitioned from other applications to simplify 
the problem, and in what way?

C. What Risk Assessment Methods Will Be Considered Adequate?

    One of FRA's greater challenges concerning this proposed rule will 
be verification of compliance with the performance-based standard. The 
Standards Task Force has recommended an enforcement scheme under which 
railroads would conduct, when required, a risk assessment to show that 
the performance standard is met. In most cases, FRA envisions that the 
risk assessment will identify the assigned risk classes for the system, 
assign a numerical expression for each safety integrity level, specify 
a target failure rate, and identify the standards upon which the 
assessment and calculations were made. This information can be used as 
a basis to measure and identify the likelihood of a hazardous event and 
the potential for the system to function as intended. With this 
information, the railroad and FRA can confirm compliance with the 
performance standard.
    The primary goal of the risk assessment required by this proposed 
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. Most of the analytical 
techniques explored by the Standards Task Force analyzed relative risk 
levels much more effectively than they analyzed absolute risk levels. 
Thus, the proposed 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 they proposed creation of 
certain guidelines to be followed when conducting risk assessments. FRA 
feels these guidelines, captured in Sec. 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 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. The 
proposed rule would allow 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. Initially, the Standards Task Force 
considered allowing only quantitative risk assessment methods 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. FRA invites comments addressing the extent to 
which qualitative risk assessment methods ought to be considered 
sufficient.
    The Standards Task Force further recommended 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 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 proposes that risk assessment 
methods not meeting the guidelines of this proposed rule be allowed, so 
long as it could be demonstrated to 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 would 
retain authority to ultimately prevent implementation of a system whose 
Product Safety Plan does not adequately demonstrate compliance with the 
performance standard under the proposed 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 proposed 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 proposed 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 Sec. 236.915(g)). 
Also, in such cases, FRA will be more likely to require an independent 
third party review and assessment (see Sec. 236.915(h)).

Section-by-Section Analysis

Section 209.11  Request for Confidential Treatment

    FRA proposes an amendment to this section, as recommended by the 
Standards Task Force, to clarify existing procedures for requesting 
confidential treatment for documents provided to the

[[Page 42362]]

FRA in connection with the agency's enforcement activities. First, the 
section would be amended 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. 
Second, the section would be amended to clarify the definition of what 
activities constitute FRA enforcement activities. Under the revised 
definition, enforcement would include receipt by the FRA of documents 
required to be submitted by FRA regulations, and all documents received 
by the FRA in connection with FRA's investigative and compliance 
activities, in addition to the development of violation reports and 
recommendations for prosecution.

Section 234.275  Processor-Based Systems

    Section 234.275 proposes 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 feels it is 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 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). This focus captured the potential uses 
of Intelligent Transportation System (ITS) technology at highway-rail 
grade crossings. This proposed requirement 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) proposes 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 or that used in ITS, which 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). FRA is considering 
tailoring this definition to more accurately reflect the intent of the 
Standards Task Force, which was to include only technology not 
previously recognized for use in applications subject to part 234.
    Paragraph (c) proposes requirements for equipment subject to this 
section. These are additional requirements which must be included in 
the PSP.
    Paragraph (d)(1) is proposed to confirm that this section in no way 
authorizes deviation from the requirements of the 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.

Section 236.0  Application

    As a general matter, this proposed rule would apply to all 
railroads, with two exceptions. First, railroads which operate on track 
wholly separate from 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 would be unaffected by the 
requirements of part 236. FRA proposes this change in 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).

Section 236.18  Software Management Control Plan

    This section proposes a requirement for all railroads to 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 proposed requirement would provide 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 proposes this requirement because for a considerable time after 
the introduction of processor-based equipment into signaling systems, 
components of such systems were not always 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 driving to equipment locations, 
sometimes remote, these employees would even recklessly place PC boards 
and PROMs in tool bins and tool boxes. 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 Northeast Corridor (63 FR 
39343, 52 FR 44510),

[[Page 42363]]

PROMs were required to be soldered in place in order to assure proper 
software versions were installed on locomotives.
    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 
would provide 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 would expect the software management control plan 
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 cyclic 
redundancy check for verifying PROM contents. The Task Force had 
initially considered a requirement that railroads adopt configuration 
management plans, which would cover both software and hardware dealing 
with safety-critical aspects of processor-based signal and train 
control systems. Railroads expressed concern 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 invites comments specifically addressing this issue.
    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.
    This proposed requirement holds railroads 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. FRA invites comments specifically addressing this issue.
    It is also recognized that this requirement may unduly burden the 
railroads in situations where they receive inaccurate information from 
the product manufacturer concerning manufacturer modifications. This 
poses safety risks because a railroad relying on a manufacturer's 
statement certifying compatibility, for example, with another 
manufacturer's system may create a dangerous situation if in fact the 
two products are not compatible. FRA feels that the railroads should be 
entitled to rely on the manufacturers' product information since 
manufacturers obviously know much more about the specifics of their 
products. In essence, the proposed requirement would impose a strict 
liability standard on the railroads regardless of culpability. FRA 
invites 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 further invites comments concerning the 
scope of a product manufacturer's duty to provide accurate information 
concerning initial software configuration of its products and any 
engineering control changes.
    Paragraph (a) discusses the proposed application of this 
requirement to all railroads and how it applies to railroads not in 
operation as of the effective date of this rule. The Standards Task 
Force intended for this requirement to apply to all systems which would 
be specifically excluded by the Sec. 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 
Secs. 236.907(a)(13) and 236.919(b). These specifications must comply 
with the railroad's RSPP.
    Although the issue of allowance time for compliance was not covered 
by the Standards Task Force, FRA proposes a 24-month time period as 
sufficient. FRA welcomes comments specifically addressing this issue.
    Paragraph (b) proposes a requirement for software management 
control plans, and further would require that the plan identify tests 
required by the system developer and/or the railroads in the event of 
replacement, modification, and disarrangement.

Section 236.110  Results of Tests

    FRA proposes modification of existing Sec. 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, 
Sec. 236.110 would incorporate in four paragraphs new language and 
language from current Sec. 236.110.
    Paragraph (a) outlines four primary changes. First, FRA proposes to 
add two new sections to the list of sections to which Sec. 236.110 
applies: Secs. 236.911 and 236.917(a), both of which apply 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) proposes to allow for electronic record 
keeping. In conjunction with FRA's policy of encouraging such methods 
where available and appropriate, FRA would like to allow for railroads 
to be able to avail themselves of this method. FRA proposes 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 offers changes to Sec. 236.110 to make clear that 
records filed with a railroad supervisory officer with jurisdiction are 
subject to inspection and replication by FRA. 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 Sec. 236.110(c)(1), the railroad 
shall inform

[[Page 42364]]

FRA of the office location(s) where these life cycle records will be 
kept. If electronic recordkeeping (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 Sec. 236.110, 
concerning the list of sections to which it applies. The proposed 
paragraph lists in proper numerical order the sections to which 
Sec. 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 Sec. 236.110 (fourth 
sentence).
    Paragraph (c) proposes a requirement to specify the length of time 
records made in compliance with Sec. 236.917(a) are to be kept. 
Paragraph (c)(1) proposes a requirement for all railroads to 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. For the 
following two reasons, the Standards Task Force recommended that these 
records be kept for one year, or until the next record is made. First, 
a subset of these records (those involving hazardous events) will be 
tracked in the product's hazard log (see Sec. 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, the Task 
Force 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 Sec. 236.110 
(fifth sentence).
    Paragraph (e) proposes to allow electronic recordkeeping in lieu of 
preprinted paper forms.

Section 236.787a.  Railroad

    FRA proposes this definition to aid in standardizing the 
application provisions of its regulations. See also 49 CFR 238.5.

Section 236.901  Purpose and Scope

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

Section 236.903  Definitions

    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 proposing 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.
    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 remains the same from 
installation to installation; the design is not changed and it is not 
recompiled.
    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 proposed 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 proposed rule offers standards in 
Sec. 236.927.
    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'' 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 invites comments 
addressing this issue specifically.
    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 be 
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 is considering amending the definition of 
predefined change to includes both

[[Page 42365]]

changes made directly to the product and changes to how the product is 
used. FRA urges parties developing product 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 hazard 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 Rules, Standards & 
Instructions (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.
    The term ``product'' is proposed 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 the 
system itself, if processor-based. A processor-based subsystem is 
intended to signify a signal or train control system's subsystem which 
contains a processor-based component. A processor-based signal or train 
control system is intended to mean a signal or train control system 
which contains a processor-based component.
    For issues related to the definition of ``risk assessment,'' please 
see major issue (c)-Risk Assessment Methods.
    The term ``safety-critical'' is intended to apply to any function 
which must be correctly performed in order to avoid causing a hazardous 
condition to equipment or personnel. If not performing correctly, a 
safety-critical system, subsystem, or component could cause a hazardous 
condition or permit the occurrence of a hazardous condition which it 
was designed to prevent. 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 be 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 proposed 
definition ought to be modified to exclude references to what stages in 
a product's life cycle validation is performed. Commenters are invited 
to address this issue specifically.

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 recent 
rulemakings: FOX High Speed Rail Safety Standards, 62 FR 65478, Dec. 
12, 1997; Passenger Train Emergency Preparedness, 63 FR 24630, May 4, 
1998; and Passenger Equipment Safety Standards, 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 proposes that railroads implement FRA-approved system 
safety plans, enforce them, and update them as necessary. In this 
process, FRA proposes that the railroad 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) would require 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 proposed rule, FRA proposes that the 
railroad submit their 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 their initial RSPP to 
FRA. FRA believes that the RSPP must be used as a guide in the earliest 
conceptual stages of a project.
    Paragraph (b) proposes that the RSPP address minimum requirements 
for development of 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).
    Paragraph (b)(1) proposes a requirement that the RSPP provide a 
detailed description of the tasks to be completed during the 
preliminary hazard analysis for every safety-critical

[[Page 42366]]

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 design for safety concerns are 
effectively identified and addressed at all stages of product 
development. FRA welcomes further comments concerning the railroad's 
claim and this distinction.
    Paragraph (b)(2) discusses 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 railroad 
create and maintain documentation which will facilitate an independent 
third party assessment, if required (see Sec. 236.915(h)). FRA believes 
this process will also help to refine and standardize validation and 
verification processes for each railroad.
    Paragraph (b)(3) proposes a requirement 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 proposed 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) discusses how the RSPP identifies configuration 
management requirements for the configuration of products subject to 
subpart H. The Standards Task Force felt this requirement was necessary 
to help railroads maintain consistency in the configuration management 
of the products they use.
    Paragraph (c) describes the proposed 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 
Docket Clerk, Office of Chief Counsel, for action by the FRA Associate 
Administrator for Safety. 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 (grant the petition, deny the 
petition, or request 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. Railroad members of the Standards Task Force suggested that FRA 
should notify them if an extension to the 180-day period will be 
needed, and provide the reasons therefore. FRA invites comments 
addressing FRA's handling of RSPP petitions beyond 180 days after 
filing. Paragraph (c)(4) proposes 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.
    Paragraph (d) proposes 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) proposes a requirement 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) proposes 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. FRA notes that it may not be 
necessary to remit copies of the entire RSPP.

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 seeks comments on 
whether the elements contained in this section are adequate or whether 
there are other requirements that should be included to assure safety.
    Paragraph (a)(1) would require 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 failsafe principle. FRA believes this 
provision is an important element that can be applied to determine 
whether safety is maximized and maintainability can be achieved. 
Railroads have expressed concern over the level of detail required in 
describing the product. Commenters are invited to address this issue.
    Paragraph (a)(2) would require 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 invites 
comments addressing this issue.
    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

[[Page 42367]]

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 
would 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) proposes 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 justification provided 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. Interested parties are asked to comment on the adequacy 
of this process for preserving railroad safety.
    Paragraph (a)(5) would require 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) proposes 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 on 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 the product (i.e., do not result in a 
hazard) would not be required to be recorded on the hazard log.
    Paragraph (a)(7) would require that a risk assessment be included 
in the PSP. See major issue (c)-Risk Assessment Methods. FRA will use 
this information as a basis to confirm compliance with the minimum 
performance standard.
    Paragraph (a)(8) proposes 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 absolutely 
that a product is 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 be 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.
    Paragraph (a)(9) would also require that the PSP address safety 
verification and validation procedures. FRA believes verification and 
validation for safety are vital parts of the development of products 
and, in certain cases, should be performed by a third party. 
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) would require 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 
is considering consolidation of the concepts required in these two 
paragraphs.
    Paragraph (a)(11) would require a human factors analysis which 
addresses

[[Page 42368]]

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. The Standards Task Force felt this flexibility is necessary 
for designers to have.
    Paragraph (a)(12) would require the railroad to include in its PSP 
the training, qualification, and designation program for workers who 
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) would require 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 
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, Sec. 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) would require 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 were 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.
    Paragraph (a)(16) would require warnings to ensure safety be 
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 
opposing 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) would require 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) would require 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, modifications, and 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) discusses a PSP requirement to include a 
description of each record concerning safe operation. Recordkeeping 
requirements for each product are discussed in Sec. 236.917.
    Paragraph (a)(19) proposes a requirement 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 suggests that availability i