the provisions contained in this section in order to provide reasonable
assurance that the product, when developed and deployed, will have no
adverse impact on the safety of railroad employees, the public, and the
movement of trains.
    FRA recognizes that much of the information required by Sec.
236.1013 normally resides with the PTC system's developer or supplier
maintains and not the client railroad. While FRA expects that each
railroad and its PTC system supplier may jointly draft a PTCDP, the
railroad has the primary responsibility for the safety of its
operations and for providing the information required under Sec.
236.1013. Accordingly, each railroad required to submit a PTCDP under
subpart I should make the necessary arrangements to ensure that the
requisite information is readily available from the supplier for
submission to the agency. FRA believes that suppliers and railroads
will develop a PTCDP for most products that adequately address the
requirements of the new subpart without substantial additional expense.
As part of the design and evaluation process, it is essential to ensure
that an adequate analysis of the features and capabilities is made to
minimize the possibility of conflicts resulting from any use or
feature, including a software fault. Since this analysis is a normal
cost of software engineering development, FRA does not believe this
requirement imposes any additional significant costs beyond what should
already be done when developing safety-critical software.
    In proposed Sec. Sec.  236.1013 and 236.1015, various adjectives
may precede the several of the requirements. For instance, certain
paragraphs require ``a complete description,'' ``a detailed
description,'' or simply a ``description.'' These phrases are inherited
from subpart H. Their inclusion in subpart I are similarly not to imply
that any description should be more or less detailed or complete than
any other description required. By contrast, they are included merely
for the purposes of emphasis.
    Paragraph (a)(1) proposes to require that the PTCDP include system
specifications that describe the overall product and identify each
component and its physical relationship in the system. FRA will not
dictate specific product architectures, but will examine each PTC
system to fully understand how its various parts interrelate. Safety-
critical functions in particular will be reviewed to determine whether
they are designed to be fail-safe. FRA believes this provision is an
important element that can be applied to determine whether safety is
maximized and maintainability can be achieved.
    Paragraph (a)(2) proposes to require a description of the operation
where the product will be used. Upon receipt of this information within
a PTCDP, FRA will have better contextual knowledge of the product as it
applies to the type of operation on which it is designed to be used.
Where operational behaviors are not applicable to a particular
railroad, or the product design is not intended to address a particular
operational behavior, FRA would expect a short statement indicating
which operational characteristics do not apply and why they are not
applicable.
    Paragraph (a)(3) proposes that the PTCDP include a concept of
operations, a list of the product's functional characteristics, and a
description explaining how various components within the system are
controlled. FRA expects that the information provided under paragraphs
(a)(2) and (a)(3) will together provide a thorough understanding of the
PTC system. FRA will review this information--primarily by comparing
the subject PTC system's functionalities with those underlying
principles contained in standards for existing signal and train control
systems--to determine whether the PTC system is designed to account for
all relevant safety issues. While FRA proposes to not prescribe PTC
system design standards, FRA expects that each applicant compare the
concepts contained in existing standards to the

operational concepts, functionalities, and controls contemplated for
the PTC system in order to determine whether a sufficient level of
safety will be achieved. For example, the proposed 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 the subject block occupied by a
train, locomotive, or car must display its most restrictive aspect for
the safety of train operations. The principle behind the requirement is
that, when a condition exists in the operating environment, or with
respect to the functioning of the system, that entails a potential
hazard, the system will assume its most restrictive state to protect
the safety of train operations.
    Paragraph (a)(4) proposes that each PTCDP include a document that
identifies and describes each safety-critical function of the subject
PTC system. The product architecture includes both hardware and
software aspects that 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. FRA
intends to use this information to determine whether appropriate safety
concepts have been incorporated into the proposed PTC system. 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 intends to use this information to determine whether all the
safety-critical functions are included. Where such functionalities are
not clearly determined to exist as a result of technology development,
FRA will expect the reasoning to be stated and a justification provided
describing how that technology provides the required level of safety.
Where FRA identifies a void in safety-critical functions, FRA may not
approve the PTCDP until remedial action is taken to rectify the
concern.
    FRA recognizes that the information required under paragraph (a)(4)
may already be provided when complying with paragraph (a)(1). In such a
case, the railroad shall cross reference where in the PTCDP that both
paragraphs (a)(1) and (a)(4) are jointly satisfied.
    Paragraph (a)(5) proposes to require that each PTCDP address the
minimum requirements under Sec.  236.1005 for development of safety-
critical PTC systems. FRA expects the information provided under
paragraph (a)(5) to cover: 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 risks
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. Paragraph (a)(5) also requires that each railroad identify the
PTC system's safety assurance concepts.
    Paragraph (a)(6) proposes to require a submission of a preliminary
human factors analysis that addresses each applicable human-machine
interface (HMI) and all proposed product functions to be performed by
humans to enhance or preserve safety. FRA expects this analysis to
place special emphasis on proposed human factors responses--and the
result of any failure to perform such a response--to safety-critical
hazards, including the consequences of human failure to perform. For
each HMI, the PTCDP should address the proposed basis of assumptions
used for selecting each such interface, its potential affect upon
safety, and all potential hazards associated with each interface. Where
more than one employee is expected to perform duties dependent upon HMI
input or output, the analysis must address the consequences of failure
by one or multiple employees. FRA intends to use this information to
determine the proposed HMI's effect upon the safety of railroad
operations. The preliminary human factors analysis must propose how the
railroad or its PTC system supplier plans to address the HMI criteria
listed in Appendix E to part 236 or any alternatives proposed by the
railroad and deemed acceptable by the Associate Administrator.
    Paragraph (a)(6) also proposes that the PTCDP explain how the
proposed HMI will affect interoperability. RSIA08 requires that each
subject railroad explain how it intends to obtain system
interoperability. The ability of a train crew member to operate another
railroad's PTC system significantly depends upon a commonly understood
HMI. The HMI provides the end user with a method of interacting with
the underlying system and accessing the PTC functionality. FRA expects
that each railroad will adopt an HMI standard that will ensure ease of
use of the PTC system both within, and between, railroads.
    Paragraph (a)(7) proposes to require an analysis regarding how
subparts A through G of part 236 apply, or no longer apply, to the
subject PTC system. FRA recognizes that while a PTC system may be
designed in accordance with the underlying safety concepts of subparts
A through G, the specific existing requirements contained in those
subparts are not applicable. In any event, the PTCDP must identify each
pertinent requirement considered to be inapplicable, fully describe the
alternative method used to fulfill that underlying safety concept, and
explain how the proposed PTC system supports the underlying safety
principle. FRA notes that certain sections in subparts A though G may
always be applicable to PTC systems certified under subpart I.
    FRA is concerned about all dimensions of system security. Thus,
paragraph (a)(8) proposes to require the PTCDP to include a description
of the security measures necessary to meet the specifications for each
PTC system. Security is an important element in the design and
development of PTC systems and covers issues such as developing
measures to prevent hackers from gaining access to software and to
preclude sudden system shutdown, mechanisms to provide message
integrity, and means to authenticate the communicating parties. Safety
and security are two closely related topics. Both are elements for
ensuring that a subject is protected and without risk of harm. In the
industrial marketplace, the goals of safety and security are to create
an environment protecting assets from hazards or harm. While activities
to ensure safety usually relate to the possibility of accidental harm,
activities to ensure security usually relate to protecting a subject
from intentional malicious acts such as espionage, theft, or attack.
Since system performance may be affected by either inadvertent or
deliberate hazards or harms, the safety and security involved in the
implementation and operation of a PTC system must both be considered.
    Integrated security recognizes that optimum protection comes from
three mutually supporting elements: physical security measures,
operational procedures, and procedural security measures. Today, the
convergence of information and physical security is being driven by
several powerful forces, including: interdependency, efficiency and
organizational simplification, security awareness, regulations,
directives, standards, and the evolving global communications
infrastructure. Physical security describes measures

that prevent or deter attackers from accessing a facility, resource, or
information stored on physical media and guidance on how to design
structures to resist various hostile acts. Communications security
describes measures and controls taken to deny unauthorized persons
information derived from telecommunications and ensure the authenticity
of such telecommunications. Because of the integrated nature of
security, FRA expects that each PTCDP will address security as a
holistic concept, and not be restricted to limited or specific aspects.
    Paragraph (a)(9) proposes to require documentation of assumptions
concerning reliability and availability targets of mechanical,
electrical, and electronic components. When building a PTC system,
designers may make numerous presumptions that will directly impact
specific implementation decisions. These fundamental assumptions
usually come in the form of data (e.g., facts collected as the result
of experience, observation or experiment, or processes, or premises)
that can be randomly sampled. FRA does not expect to audit all of the
fundamental assumptions on which a PTC system has been developed.
Instead, FRA envisions sampling and reviewing fundamental assumptions
prior to product implementation and after operation for some time. FRA
expects that the data sampled may vary, depending upon the PTC system.
It is not possible to provide a single set of quantitative numbers
applicable to all systems, especially when systems have yet to be
designed and for which the fundamental assumptions are yet to be
determined. Quantification is part of the risk management process for
each project. FRA believes that the actual performance of the system
observed during the pre-operational testing and post-implementation
phases will provide indications of the validity of the fundamental
assumptions. FRA proposes that this review process will occur for the
life of the PTC system (i.e., as long as the product is kept in
operation). The depth of details required will depend upon what FRA
observes. The range of difference between a PTC system's predicted and
actual performance may indicate to FRA the validity of the underlying
fundamental assumptions. Generally, if the actual performance matches
the predicted performance, FRA believes that it will not have to
extensively review the fundamental assumptions. If the actual
performance does not match predicted performance, FRA may need to more
extensively review the fundamental assumptions.
    FRA expects each subject railroad to confirm the validity of
initial assumptions by comparing them to actual in-service data. FRA is
aware that mechanical and electronic component failure rates and times
to repair are easily quantified data, and usually are kept as part of
the logistical tracking and maintenance management of a railroad. FRA
believes that this proposed criterion will enhance the quality of risk
assessments conducted pursuant to this subpart by forcing PTC system
designers and users to consider the long-term effects of operation over
the course of the PTC system's projected life-cycle. If a PTC system
can be used beyond its design life-cycle, FRA expects that any
continued use would be only under a waiver provided in accordance with
part 211 or under a PTCDP or PTCSP amended in accordance with Sec.
236.1021. In its request for waiver or request for amendment, the
railroad should address any new risks associated with the life-cycle
extension.
    Paragraph (a)(9) also proposes to require specification of the
target safety levels. This includes the identity of each potential
hazard and how the events leading to a hazard will be identified for
each safety-critical subsystem; the proposed safety integrity level of
each safety-critical subsystem, and the proposed means that
accomplishment of these targets will be evaluated. This paragraph also
requires identification of the proposed 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. FRA contends that availability is directly related to
safety to the extent the backup means of controlling operations
involves greater risk (either inherently or because it is infrequently
practiced).
    Paragraph (a)(10) proposes to require a complete description of how
the PTC system will enforce all pertinent authorities and block signal,
cab signal, or other signal related indications. FRA appreciates that
not all PTC architectures will seek to enforce the speed restrictions
associated with intermediate signals directly, but nevertheless a clear
description of these functions is necessary for clarity and evaluation.
    Proposed paragraph (a)(11) requires that, if the railroad is
seeking to deviate from the requirements of section 236.1029 with
respect to movement of trains with onboard equipment that has failed en
route using the flexibility provided by paragraph (c) of that section,
a justification must be provided in the PTCDP. Paragraph (c) of
proposed Sec.  236.1029 provides that, in order for a PTC train that
operates at a speed above 90 miles per hour to deviate from the
operating limitations contain in paragraph (b) of that section, the
deviation must be described and justified in the FRA approved PTCDP or
PTCSP, or by reference to an Order of Particular Applicability, as
applicable. For instance, if Amtrak wished to continue to operate at up
to 125 miles per hour with cab signals and automatic train control in
the case of failure of onboard ACSES equipment, Amtrak would request to
do so based on the applicable language of the Order of Particular
Applicability that required installation of that system on portions of
the Northeast Corridor. Similarly, a railroad wishing more liberal
requirements for a high speed rail system on a dedicated right-of-way
could request that latitude by explaining how the safety of all
affected train movements would be maintained.
    Paragraph (a)(12) requires a complete description of how the PTC
system will appropriately and timely enforce all hazard detectors that
are interconnected with the PTC system in accordance with Sec.
236.105(c)(3), as may be applicable.
    Proposed paragraph (b) specifies the approval standard that will be
employed by the Associate Administrator. The PTCDP is not expected to
provide absolute assurance to the Associate Administrator that every
potential hazard will be eliminated with complete certainty. It only
needs to establish that the PTC system meets the appropriate statutory
and regulatory requirements for a PTC system required under this
subpart, and that there is a reasonable chance that once built, it will
meet the required safety standards for its intended use. FRA emphasizes
that approval of a PTCDP and issuance of a Type Approval does not
constitute final approval to operate the product in revenue service.
Such approval only comes when the Associate Administrator issues an
applicable PTC System Certification.
    Paragraph (c) proposes a time limit on the validity of a Type
Approval. Provided that at least one product is certified within the 5
year period after issuance of the Type Approval, the Type Approval
remains valid until final retirement of the system. The main purpose of
this requirement is to incentivize installation, not just creation, of
a PTC system. This paragraph would also allow FRA to periodically clean
out its records

relating to Type Approvals and PTCDPs for obsolete PTC systems.
    Paragraph (d) proposes the conditions under which a Type Approval
may be used by another railroad. These conditions consist of the
railroad maintaining a continually updated PTCPVL pursuant to Sec.
236.1023(c) and the railroad providing licensing information associated
with the use of the Type Approval. Under paragraph (d), FRA intends to
ensure the implementation of the proper technology and not any orphan
product using apparently similar, but actually different, technology.
When a railroad submits a previously issued Type Approval for its PTC
system, FRA expects that all the proper licensing agreements provide
for continued use and maintenance of the PTC system are in place. To
ensure FRA's confidence in this area, FRA proposes to require each Type
Approval submission to include this relevant licensing information. FRA
recognizes that there may be various licensing arrangements available
relating to the exclusivity and sublicensing of manufacturing or
vending of a particular PTC system. There may be other intellectual
property variables that may make arrangements even more complex. To
adequately capture all applicable arrangements, FRA proposes to
generally require the submission of ``licensing information.'' More
specific language may preclude FRA's ability to collect information
necessary to fulfill its intent. If any of this information were to
change, either through any type of sale, transfer, or sublicense of any
right or ownership, then FRA would expect the railroad to submit a
request for amendment of its PTCDP in accordance with Sec.  236.1021.
FRA recognizes that this may be difficult for a railroad to accomplish,
given the railroad may not be privy to any intellectual property
transactions that may occur outside of its control. In any event, FRA
would expect that a railroad would ensure, either through contractual
obligation or otherwise, that its vendor or supplier provide it with
updated licensing information on a continuing basis. FRA seeks comments
on this proposal.
    Paragraph (e) proposes to require that a railroad submitting a
PTCDP demonstrate that its vendor has a suitable quality control
system. This requirement provides protection to the railroad and FRA
that there is a reasonable probability that the vendor can design and
manufacture the product such that it will meet the design targets
specified in paragraph (a). FRA expects that compliance with paragraph
(e) will eliminate the operation of a PTC system where its vendor has
inadequate quality control procedures and processes to support the
proper development of a safety critical product.
    Paragraph (f) proposes language retaining the Associate
Administrator's ability to impose any conditions necessary to ensure
the safety of the public, train crews, and train operations when
approving the PTCDP and issuing a Type Approval. While FRA expects that
adherence to the remainder of this section's requirements should
justify issuance of a Type Approval, FRA also recognizes that there may
be situations where other unaccounted for variables may reduce the
Associate Administrator's confidence in the PTC system, its
manufacturer, supplier, vendor, or operator.

Section 236.1015 PTCSP Content Requirements and PTC System
Certification

    The PTC Safety Plan (PTCSP) is the core document that provides the
Associate Administrator the information necessary to certify that the
as-built PTC system fulfills the required statutory PTC functions and
is in compliance with the requirements of this subpart. Issuance of a
PTC System Certification is contingent upon the approval of the PTCSP
by the Associate Administrator. Under the proposed rules, the filing
and approval of the PTCSP and issuance of a PTC System Certification is
a mandatory prerequisite for PTC system operation in revenue service.
Each PTCSP is unique to each railroad and must addresses railroad-
specific implementation issues associated with the PTC system
identified by the submitted Type Approval. Paragraph (a) proposes
language explaining these meanings and limits.
    When filing a PTCSP, proposed paragraph (b) proposes to require
each railroad to: Include the applicable and approved PTCIP, PTCDP, and
Type Approval; describe any changes subsequently made to the PTC
system, as reflected in the PTCSP, that would require amendment of the
PTCIP or PTCDP; and assure FRA whether the PTC system built is the same
PTC system described in the PTCDP and PTCSP. Paragraph (b)(1)
effectively merges the approved PTCIP and PTCDP into the PTCSP so that
there will be a single ``package'' available for PTC operations and FRA
review before and after issuance of a PTC System Certification. If a
PTCSP is approved, and the railroad receives a PTC System
Certification, all three plans continue to ``live'' and can only be
amended in accordance with Sec.  236.1021.
    FRA recognizes the possibility that between PTCIP or PTCDP
approval, and prior to PTCSP submission, there may be changes to the
former two documents. While such changes may only be made in accordance
with Sec.  236.1021, documentation of those changes may not be readily
apparent to the reader of the PTCSP. Accordingly, under proposed
paragraph (b)(2), FRA expects that each PTCSP shall include a clear and
complete description of any such changes by specifically and rigorously
documenting each variance. Paragraph (b)(2) also proposes to require
that the PTCSP include an explanation of each variance's significance.
To ensure that there are no other existing variances not documented in
the PTCSP, FRA also proposes under this paragraph to require the
railroad to attest that there are no further variances. For the same
reason, paragraph (b)(3) proposes that, if there have been no changes
to the plans or to the PTC system as intended, the railroad be required
to attest that there are no such variances.
    Proposed paragraph (c) delineates the contents of the PTCSP. The
first elements of the PTCSP are the same elements as the PTCDP (and are
described more fully in the section by section for 236.1013). If the
railroad had already submitted, and FRA had already approved, the
PTCDP, then attachment of the PTCDP to the PTCSP should fulfill this
requirement.
    The additional, proposed railroad specific elements are as follows:
    Paragraph (c)(1) proposes to require that the PTCSP include a
hazard log comprehensively describing 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. In other words, if the hazard has not
been predicted, then any single occurrence of that hazard is
unacceptable. The hazard log addresses safety-relevant hazards, or
incidents or failures that affect the safety and risk assumptions of
the PTC system. Safety relevant hazards include events such as false
proceed signal indications and false restrictive signal indications. If
false restrictive signal indications occur with any type of frequency,
they could influence train crew members, roadway workers, dispatchers,
or other users to develop an apathetic attitude towards complying with
signal indications or instructions from the PTC system, creating human
factors problems.
    Incidents in which stop indications are inappropriately displayed
may also necessitate sudden brake applications

that may involve risk of derailment due to in-train forces. Other
unsafe or wrong-side failures which affect the safety of the product
will be recorded on the hazard log. The intent of this paragraph is to
identify all possible safety-relevant hazards which would have a
negative effect on the safety of the product. Right-side failures, or
product failures which have no adverse effect on the safety of the
product (i.e., do not result in a hazard) would not be required to be
recorded on the hazard log.
    Paragraph (c)(2) proposes to require that a risk assessment be
included in the PTCSP. FRA will use this information as a basis to
confirm compliance with the appropriate performance standard. A
performance standard specifies the outcome required, but leaves the
specific measures to achieve that outcome up to the discretion of the
regulated entity. In contrast to a design standard or a technology-
based standard that specifies exactly how to achieve compliance, a
performance standard sets a goal and lets each regulated entity decide
how to meet that goal. An appropriate performance standard should
provide reasonable assurance of safe and effective performance by
making provision for: (1) Considering the construction, components,
ingredients, and properties of the device and its compatibility with
other systems and connections to such systems; (2) testing of the
product on a sample basis or, if necessary, on an individual basis; (3)
measurement of the performance characteristics; and (4) requiring that
the results of each or of certain of the tests required show that the
device is in conformity with the portions of the standard for which the
test or tests were required. Typically, the specific process used to
design, verify and validate the product is specified in a private or
public standard. The Administrator may recognize all or part of an
appropriate standard established by a nationally or internationally
recognized standard development organization.
    Paragraph (c)(3) proposes to require that the PTCSP include a
hazard mitigation analysis. 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 specified by the system designer or
procuring entity. To determine whether these requirements are
satisfied, the safety assessor must determine that: (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; and (4) hazard mitigation techniques
have been effectively applied. See Leveson, Nancy G., Safeware: System
Safety and Computers, (Addison-Wesley Publishing Company, 1995).
    FRA does not expect that the safety assessment will prove that a
product is absolutely safe. However, the safety assessment should
provide evidence that risks associated with the product have been
carefully considered and that steps have been taken to eliminate or
mitigate them. Hazards associated with product use need to be
identified, with particular focus on those hazards found to have
significant safety effects. The risk assessment proposed under
paragraph (c)(2) must include each hazard that cannot be mitigated by
system designs (e.g., human over-reliance of the automated systems) no
matter how low its probability may be. After the risk assessment, 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, FRA may require an
independent third party assessment in accordance with proposed Sec.
236.1017 to review these methods as a prerequisite to FRA approval.
    Paragraph (c)(4) also proposes that the PTCSP address safety
Verification and Validation procedures as defined under part 236. FRA
believes that Verification and Validation for safety are vital parts of
the PTC system development process. Verification and Validation require
forward planning. Consequently, the PTCSP should identify the testing
to be performed at each stage of development and the levels of rigor
applied during the testing process. FRA will use this information to
ensure that the adequacy and coverage of the tests are appropriate.
    Paragraph (c)(5) proposes to require the railroad to include in its
PTCSP the training, qualification, and designation program for workers
regardless of whether those railroad employees will perform inspection,
testing, and maintenance tasks involving the PTC system. FRA believes
many benefits accrue from the investment in comprehensive training
programs and 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 (c)(6) proposes to require the PTCSP 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 intends to use this information to
ascertain whether the product will be properly installed, maintained,
tested, and repaired.
    Paragraph (c)(7) proposes that each railroad develop a manual
covering the requirements for the installation, periodic maintenance
and testing, modification, and repair for its PTC system. The
railroad's Operations and Maintenance Manual must address the issues of
warnings and describe the warning labels to be placed on each piece of
PTC system equipment as necessary. Such warnings include, but are not
limited to: Means to prevent unauthorized access to the system;
warnings of electrical shock hazards; cautionary notices about improper
usage, testing, or operation; and configuration management of memory
and databases. The PTCSP 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 (c)(8) proposes to require that the PTCSP identify the
various configurable applications of the product, since this rule
mandates use of the product only in the manner described in its PTCDP.
Given the importance of proper configuration management in safety-
critical systems, FRA believes it is essential that railroads learn of
and take appropriate configuration control of hardware and software.
FRA believes that a requirement for configuration management control
will enhance the safety of these systems and ultimately provide other
benefits to the railroad as

well. Under this proposed paragraph, railroads are responsible--through
its applicable Operations and Maintenance Plan and other supporting
documentation maintained throughout the system's life-cycle--for all
changes to configuration of their products in use, including both
changes resulting from maintenance and engineering control changes,
which result from manufacturer modifications to the product. Since not
all railroads may experience the same software faults or hardware
failures, the configuration management and fault reporting tracking
system play a crucial role in the ability of the railroad and the FRA
to determine and fully understand the risks and their implications.
Without an effective configuration management tracking system in place,
it is difficult, if not impossible, to fairly evaluate risks associated
with a product over the life of the product.
    Paragraph (c)(9) proposes to require the railroad to develop
comprehensive plans and procedures for product implementation.
Implementation (field validation or cutover) procedures must be
prepared in detail and identify the processes necessary to verify that
the PTC system is properly installed and documented, including measures
to provide for the safety of train operations during installation. FRA
will use this information to ascertain whether the product will be
properly installed, maintained, and tested. FRA also believes that
configuration management should reduce disarrangement issues. Further,
configuration management will reduce the cost of troubleshooting by
reducing the number of variables and will be more effective in
promoting safety.
    Paragraph (c)(10) proposes to require the railroad to provide a
complete description of the particulars concerning measures required to
assure that the PTC system, once implemented, continues to provide the
expected safety level without degradation or variation over its life-
cycle. The measures specifically provide the prescribed intervals and
criteria for the following: testing; scheduled preventive maintenance
requirements; procedures for configuration management; and procedures
for modifications, repair, replacement and adjustment of equipment. FRA
intends to use this information, among other data, to monitor the PTC
system to assure it continually functions as intended.
    Paragraph (c)(11) proposes to include in each PTCSP a description
of each record concerning safe operation. Recordkeeping requirements
for each product are discussed in proposed Sec.  236.1037.
    Paragraph (c)(12) proposes to require a safety analysis of
unintended incursions into a work zone. Measuring incursion risks is a
key safety risk assumption. Failing to identify incursion risk can have
the effect of making a system seem safer on paper than it actually is.
The requirements set forth in this paragraph attempt to mandate design
consideration of incursion protection at an early stage in the product
development process. The totality of the arrangements made to prevent
unintended incursions or operation at higher than authorized speed
within the work zone must be analyzed. That is, in addition to the
functions of the PTC system, the required actions for dispatchers,
train crews, and roadway workers in charge must be evaluated.
Regardless of whether a PTC system has been previously approved or
recognized, FRA will not accept a system that allows a single point
human failure to defeat the essential protection intended by the
Congress. See NTSB Recommendations R-08-05 and R-08-06. FRA believes
that exposure should be identified because increases in risk due to
increased exposure could be easily distinguished from increases in risk
due solely to implementation and use of the proposed PTC system.
    In the past, little attention was given to formalizing incursion
protection procedures. Training for crews has also not been uniform
among organizations, and has frequently received inadequate attention.
As a result, a variety of procedures and techniques evolved based on
what has been observed or what just seemed correct at the time. This
lack of structure, standardization, and formal training is inconsistent
with the goal of increasing the safety and efficiency.
    Paragraph (c)(13) proposes to require a more detailed description
of any alternative arrangements provided under proposed Sec.
236.1011(a)(10), pertaining to at grade rail-to-rail crossings.
    Paragraph (c)(14) proposes to require a complete description of how
the PTC system will enforce mandatory directives and signal
indications, unless already addressed in the PTCDP. FRA recognizes that
all systems will enforce all signal indications; however, the PTCDP
must describe where the architecture of the system performs this
function.
    Proposed paragraph (c)(15) refers to the requirement of Sec.
236.1019(e) that the PTCSP is aligned with the PTCIP, including any
amendments.
    Under proposed Sec.  236.1029(b), FRA proposes to require certain
limitations on PTC trains operating over 90 miles per hour. Under Sec.
236.1029(c), FRA provides railroads with an opportunity to deviate from
those limitations if the railroad describes and justifies the deviation
in its PTCDP, PTCSP, or by reference to an Order of Particular
Applicability, as applicable. Thus, proposed paragraph (c)(16) to Sec.
236.1015 reminds railroads that this is one of the optional elements
that may be included in a PTCSP. This need may also be addressed
through review of the PTCDP, and FRA reserves the right to so provide
in the final rule.
    Railroads are required under Sec.  236.1005(c) to submit a complete
description of its compliance regarding hazard detector integration and
under Sec. Sec.  236.1005(g)-(k) to submit a temporary rerouting plan
in the event of emergencies and planned maintenance. Railroads must
also submit a document indicating any alternative arrangements for each
rail at-grade crossing not adhering to the table under Sec.
236.1005(a)(1)(i). Proposed paragraphs (c)(17), (c)(18), and (c)(19) to
Sec.  236.1015 reminds railroads that such requirements must be
fulfilled with the submission of the PTCSP. For example, under proposed
paragraph (c)(18), FRA expects each temporary rerouting plan to explain
the host railroad's procedure relating to detouring the applicable
traffic. In other words, FRA expects that each temporary rerouting plan
address how the host railroad will choose the track that traffic will
be rerouted onto. For instance, the plan should explain the factors
that will be considered in determining whether and how the railroad
should take advantage of temporary rerouting. FRA remains concerned
about the unnecessary commingling of PTC and non-PTC traffic on the
same track and expects each temporary rerouting plan to address this
possibility. More specifically, each plan should describe how the
railroad expects to make decisions to reroute non-PTC train traffic
onto a PTC line, especially where another non-PTC line may be
available. While FRA recognizes each railroad may seek to use the most
cost effective route, FRA expects the railroad to also consider the
level of risk associated with that route.
    In paragraph (d), FRA proposes to state the criteria that FRA will
refer to when evaluating the PTCSP, depending upon the underlying
technical approach. Whereas in subpart H the safety case is evaluated
to determine whether it demonstrates with a high degree of confidence
that relevant risk

will be no greater under the new product than previously, the statutory
mandate for PTC calls for a different approach. In crafting the
proposed approach, FRA has attempted to limit requirements for
quantitative risk assessment to those situations where the technique is
truly needed. Regardless of the type of PTC system, the safety case for
the system must demonstrate that it will reliably execute all of the
functions required by this subpart (particularly those provided under
proposed Sec. Sec.  236.1005 and 236.1007). With this foundation, the
additional criteria that must be met depend upon the type of PTC
technology to be employed.
    It is FRA's understanding that PTC systems may be categorized as
one of the following four system types: Non-vital overlay; vital
overlay; standalone; and mixed. Initially, however, all PTC systems
will have some features that are not fully fail-safe in nature, even if
onboard processing and certain wayside functions are fully fail-safe.
Common causes include surveying errors of the track database, errors in
consist weight or makeup from the railroad information technology
systems, and the crew input errors of critical operational data. To the
extent computer-aided dispatching systems are the only check on
potential dispatcher error in the creation or inappropriate
cancellation of mandatory directives, some room for undetected wrong-
side failure will continue to exist in this function as well. This
issue is addressed under paragraph (g) of this section.
    Proposed paragraph (d)(1) specifies the required behavior for non-
vital overlay systems. Based on previous experience with non-vital
systems, FRA believes it is well within the technical capability of the
railroads to reduce the level of risk on any particular track segment
to a level of risk 80% lower than the level of risk prior to
installation of PTC on that segment. For subsequent PTC system
installations on the same line segment, FRA recognizes that requiring
an additional 80% improvement may not be technically or economically
practical. Therefore, FRA is only proposing that an entity installing
or modifying an existing PTC system need only demonstrate that the
level of safety is equal to, and preferably greater than, the level of
safety of the prior PTC system. The risk that must be reduced is the
risk against which the PTC functionalities are directed, assuming a
high level of availability. Note that the required functionalities
themselves do not call for elimination of all risk of mishaps. It is
scope of risk reduction that the functionalities describe that becomes
the 100% universe which is the basis of comparison. Although it is
understood that the system will endeavor to eliminate 100% of this
risk--meaning that if the system worked as intended every time and was
always available, 100% of the target risk would be eliminated--the
analysts will need to account for cases where wrong side failure of the
technology is coincident with a human failure potentially induced by
reliance on the technology. Since, within an appropriate conservative
engineering analysis (i.e., pro forma analysis), non-vital processing
has the theoretical potential to result in more failures than will
typically be experienced, a 20% margin is provided. In preparing the
PTCSP, the railroad will want to affirmatively address how training and
oversight--including programs of operational testing under 49 CFR
217.9--will reduce the potential for inappropriate reliance by those
charged with functioning in accordance with the underlying method of
operation.
    The 80% reduction in risk for PTC preventable accidents must be
demonstrated by an appropriate risk analysis acceptable to the
Associate Administrator and must address all intended track segments
upon which the system will be installed. Again, FRA does not expect, or
require, that these types of systems will prevent all wrong side
failures. However, FRA expects that the systems will be designed to be
robust, all pertinent risk factors (including human factors) will be
fully addressed, and that no corners will be cut to ``take advantage''
of the nominal allowance provided for non-vital approaches. FRA also
encourages those using non-vital approaches to preserve as much as
possible the potential for a transition to vital processing.
    Proposed paragraph (d)(2) addresses vital overlays. Unlike a non-
vital system, the vital system must be designed to address, at a
minimum, the factors delineated in Appendix C. The railroad and their
vendors are encouraged to carry out a more thorough design analysis
addressing any other potential product specific hazards. FRA cannot
overemphasize that vital overlay system designs must be fully designed
to address the factors contained in Appendix C. The associated risk
analysis supporting this design analysis demonstrating compliance may
be accomplished using any of the risk analysis approaches in subpart H,
including abbreviated risk analysis.
    Proposed paragraph (d)(3) addresses stand-alone PTC systems that
are used to replace existing methods of operations. The PTCSP design
and risk analysis submitted to the Associate Administrator must show
that the system does not introduce any new hazards that have not been
acceptably mitigated, based upon all proposed changes in railroad
operation. The required analysis for standalone systems is much more
comprehensive than that required for vital overlay systems, since it
must provide sufficient information to the Associate Administrator to
make a decision with a high degree of confidence. FRA will uniquely and
separately consider each request for standalone operations, and will
render decisions in the context of the proposed operation and the
associated risks. FRA recognizes that application of this standard to a
new rail system for which there is no clear North American antecedent
could present a conceptual challenge. FRA invites comments regarding
how best to frame the risk assessment showing for a standalone system
applied to a new rail operation.
    Proposed paragraph (d)(4) addresses mixed systems (i.e., systems
that include a combination of the systems identified in paragraphs
(d)(1) through (d)(3). Because of the inherent complexity of these
systems, FRA will determine an appropriate approach to demonstrating
compliance after consultation with the railroad. Any approach will, of
course, require that the system perform the PTC requirements as
proposed in Sec. Sec.  236.1005 and 236.1007.
    Paragraph (e) discusses proposed factors that the Associate
Administrator will consider in reviewing the PTCSP. In general, PTC
systems will have some features that are not failsafe in nature.
Examples include surveys of the track database, errors in consist data
from the railroad such as weight and makeup, and crew input errors. FRA
participation in the design and testing of the PTC system product helps
FRA to better understand the strengths and weaknesses of the product
for which approval is requested, and facilitates the approval process.
    The railroad must establish through safety analysis that its
assertions are true. This standard places the burden on the railroad to
demonstrate that the safety analysis is accurate and sufficiently
supports certification of the PTC system. The FRA Associate
Administrator will determine whether the railroad's case has been made.
As provided in subpart H, FRA believes that final agency determinations
under this new subpart I should also be made at the technical level,
rather than the policy level, due to the complex and sometimes esoteric
subject matters associated with risk analysis and

evaluation. This is particularly appropriate in light of the RSIA08's
designation of the Associate Administrator for Railroad Safety as the
Chief Safety Officer of FRA. When considering the PTC system's
compliance with recognized standards in product development, FRA will
weigh appropriate factors, including: The use of recognized standards
in system design and safety analyses; the acceptable methods in risk
estimates; the proven safety records for proposed components; and the
overall complexity and novelty of the product design. In those cases
where the submission lacks information the Associate Administrator
deems necessary to make an informed safety decision, FRA will solicit
the data from the railroad. If the railroad does not provide the
requested information, FRA may determine that a safety hazard exists.
Depending upon the amount and scope of the missing data, PTCSP
approval, and the subsequent system certification, may be denied.
    While paragraph (e) summarizes how FRA intends to evaluate the risk
analysis, proposed paragraph (f) applies specifically to cases where a
PTC system has already been installed and the railroad subsequently
wants to put in a new PTC system. Paragraph (f) re-emphasizes that FRA
policy regarding the safety of PTC systems is not, and cannot expect to
be, static. Rather, FRA policy may evolve as railroad operations
evolve, operating rules are refined, related hazards are addressed
(e.g., broken rails), and other readily available options for risk
reduction emerge and become more affordable. FRA embraces the concept
of progressive improvement and expects that when new systems are
installed to replace existing systems that actual safety outcomes equal
or exceed those for the existing systems.

Section 236.1017 Independent Third Party Review of Verification and
Validation

    As previously noted in the discussion of proposed Sec.
236.1009(e), FRA may require a railroad to engage in an independent
assessment of its PTC system. In the event an independent assessment is
required, Sec.  236.1017 proposes the applicable rules and procedures.
    Proposed paragraph (a) establishes factors considered by FRA when
requiring a third-party assessment. FRA will attempt to make a
determination of the necessary level of third party assessment as early
as possible in the approval process. However, based on issues that may
arise during the development and testing processes, or during the
detailed technical reviews of the PTCDP and PTCSP, FRA may deem it
necessary to require a third party assessment at any time during the
review process.
    Proposed paragraph (b) is intended to make it clear that it is FRA
that will make the determination of the acceptability of the
independence of the third party to avoid any potential issues
downstream regarding the acceptability of the assessor's independence.
If a third party assessment is required, each railroad is encouraged to
identify in writing what entity it proposes to utilize as its third
party assessor. Compliance with paragraph (b) is not mandatory.
However, if FRA determines that the railroad's choice of a third party
does not meet the level of independence contemplated under proposed
paragraph (c), then the railroad will be obligated to have the
assessment repeated, at its expense, until it has been completed by a
third party suitable to FRA.
    Paragraph (c) proposes a definition of the term ``independent third
party'' as used in this section. It limits independent third parties to
those that are compensated by the railroad or an association on behalf
of one or more railroads that is independent of the PTC system
supplier. FRA believes that requiring the railroad to compensate a
third party will heighten the railroad's interest in obtaining a
quality analysis and will avoid ambiguous relationships between
suppliers and third parties that could indicate possible conflicts of
interest.
    Proposed paragraph (d) explains that the minimum requirements of a
third party audit are outlined in Appendix F (which is modeled on
current Appendix D, which is used in conjunction with subpart H) and
that FRA has discretion to limit the extent of the third party
assessment. FRA intends to limit the scope of the assessment to areas
of the safety Verification and Validation as much as possible, within
the bounds of FRA's regulatory obligations. This will allow reviewers
to focus on areas of greatest safety concern and eliminate any
unnecessary expense to the railroad. In order to limit the number of
third-party assessments, FRA first strives to inform the railroad as to
what portions of a submittal could be amended to avoid the necessity
and expense of a third-party assessment altogether. However, FRA wishes
to make it clear that Appendix F represents minimum requirements and
that, if circumstances warrant, FRA may expand upon the Appendix F
requirements as necessary to enable FRA to render a decision that is in
the public interest (i.e., if FRA is unable to certify the system
without the additional information).

Section 236.1019 Main Line Track Exceptions

    The RSIA08 generally defines ``main line'' as ``a segment of
railroad tracks over which 5,000,000 or more gross tons of railroad
traffic is transported annually.'' See 49 U.S.C. 20157(i)(2). However,
FRA may also define ``main line'' by regulation ``for intercity rail
passenger transportation or commuter rail passenger transportation
routes or segments over which limited or no freight railroad operations
occur.'' See 49 U.S.C. 20157(i)(2)(B); 49 CFR 1.49(oo). FRA recognizes
that there may be circumstances where certain statutory PTC system
implementation and operation requirements are not practical and provide
no significant safety benefits. In those circumstances, FRA proposes to
exercise its statutory discretion provided under 49 U.S.C.
20157(i)(2)(B).
    In accordance with the authority provided by the statute and with
carefully considered recommendations from the RSAC, FRA proposes to
consider requests for designation of track over which rail operations
are conducted as ``other than main line track'' for passenger and
commuter railroads, or freight railroads operating jointly with
passenger or commuter railroads. Such relief may be granted only after
request by the railroad or railroads filing a PTCIP and approval by the
Associate Administrator.
    Paragraph (a), therefore, proposes to require the submittal of a
main line track exclusion addendum (MTEA) to any PTCIP filed by a
railroad that seeks to have any particular track segment deemed as
other than main line. Since the statute only provides for such
regulatory flexibility as it applies to passenger transportation routes
or segments which limited or no freight railroad operations occur, only
a passenger railroad may file an MTEA as part of its PTCIP. This may
include a PTCIP jointly filed by freight and passenger railroads. In
fact, FRA expects that in the case of joint operations, only one MTEA
should be agreed upon and submitted by the railroads filing the PTCIP.
After reviewing a submitted MTEA, FRA may provide full or partial
approval for the requested exemptions.
    Each MTEA must clearly identify and define the physical boundaries,
use, and characterization of the trackage for which exclusion is
requested. When describing the tracks' use and characterization, FRA
expects the requesting railroad or railroads to include copies of the
applicable track

and signal charts. Ultimately, FRA expects each MTEA to include
information sufficiently specific to enable easy segregation between
main line track and non-main line track. In the event the railroad
subsequently requests additional track to be considered for exclusion,
a well-defined MTEA should reduce the amount of future information
required to be submitted to FRA. Moreover, if FRA decides to grant only
certain requests in an MTEA, the portions of track for which FRA has
determined should remain considered as main line track can be easily
severed from the MTEA. Otherwise, the entire MTEA, and thus its
concomitant PTCIP, may be entirely disapproved by FRA, increasing the
risk of the railroad or railroads not meeting its statutory deadline
for PTC implementation and operation.
    For each particular track segment, the MTEA must also provide a
justification for such designation in accordance with paragraphs (b) or
(c) of this section.
    Proposed paragraph (b) specifically addresses the conditions for
relief for passenger and commuter railroads with respect to passenger-
only terminal areas. As noted previously in the analysis of Sec.
236.1005(b), FRA proposes to except from the definition of main line
any track within a yard used exclusively by freight operations moving
at restricted speed. In those situations, operations are usually
limited to preparing trains for transportation and do not usually
include actual transportation. FRA does not propose to extend this
automatic exclusion to yard or terminal tracks that include passenger
operations. Such operations may also include the boarding and
disembarking of passengers, heightening FRA's sensitivity to safety and
blurring the lines between what defines ``transportation'' and
``preparing for transportation.'' Moreover, while FRA could not expend
its resources to review whether a freight-only yard should be deemed
other than main line track, FRA believes that the relatively lower
number of passenger yards and terminals would allow for such review.
Accordingly, FRA believes that it is appropriate to review these
circumstances on a case-by-case basis.
    During the PTC Working Group discussions, the major passenger
railroads requested an exception for tracks in passenger terminal areas
because of the impracticability of installing PTC. These are locations
where signal systems govern movements over very complex special track
work divided into short signal blocks. Operating speeds are low (not to
exceed 20 miles per hour), and locomotive engineers moving in this
environment expect conflicting traffic and restrictive signals.
Although low-speed collisions do occasionally occur in these
environments, the consequences are low; and the rate of occurrence is
very low in relation to the exposure. It is the nature of current-
generation PTC systems that they work with averages in terms of
stopping distance and use conservative braking algorithms. Applying
this approach in congested terminals would add to congestion and
frustrate efficient passenger service, in the judgment of those who
operate these railroads. The density of wayside infrastructure required
to effect PTC functions in these terminal areas would also be
exceptionally costly in relation to the benefits obtained. FRA agrees
that technical solutions to address these concerns are not presently
available. FRA does believe that the appropriate role for PTC in this
context is to enforce the maximum allowable speed (which is presently
accomplished in cab signal territory through use of automatic speed
control, a practice which could continue where already in place).
    If FRA grants relief, the proposed conditions of (b)(1), (b)(2), or
(b)(3), as applicable, must be strictly adhered to. These three
conditions represent the minimum conditions FRA believes is necessary
for safe operations. FRA reserves the right to add more restrictive
conditions if necessary to provide for the safety of the public and
train crews. If FRA approves a MTEA and the railroad subsequently
violates any of the applicable conditions, civil penalties may apply.
    Under paragraph (b)(1), FRA proposes to limit relief under
paragraph (b) to operations that do not exceed 20 miles per hour. The
PTC Working Group agreed upon the 20 miles per hour limitation, instead
of requiring restricted speed, because the operations in question will
be by signal indication in congested and complex terminals with short
block lengths and numerous turnouts. FRA agrees with the PTC Working
Group that the use of restricted speed in this environment would
exacerbate congestion, delay trains, and diminish the quality of rail
passenger service.
    Moreover, when trains on the excluded track are controlled by a
locomotive with an operative PTC onboard apparatus, FRA proposes to
require that PTC system component to enforce the regulatory speed limit
or actual maximum authorized speed, whichever is less. While the actual
track may not be outfitted with a PTC system in light of a MTEA
approval, FRA believes it would be nevertheless prudent to require such
enforcement when the technology is available on the operating
locomotives. This can be accomplished in cab signal territory using
existing automatic train stop technology and outside of cab signal
territory by mapping the terminal and causing the onboard computer to
enforce the maximum speed allowed.
    Under paragraph (b)(2), FRA proposes to also limit relief under
paragraph (b) to operations that enforce interlocking rules. Under
interlocking rules, trains are prohibited from moving in reverse
directions without dispatcher permission on track where there are no
signal indications. FRA believes that such a restriction would minimize
the potential for a head-on impact.
    Also, under proposed paragraph (b)(3), such operations would only
be allowed in yard or terminal areas where no freight operations are
permitted. While the definition of main line may not include yard
tracks used solely by freight operations, FRA does not propose to
extend any relief or exception to tracks within yards or terminals
shared by freight and passenger operations. The collision of a
passenger train with a freight consist is typically a more severe
condition because of the greater mass of the freight equipment.
    Paragraph (c) proposes the conditions under which joint limited
passenger and freight operations may occur on defined track segments
without the requirement for installation of PTC. This paragraph
proposes three alternative paths to the main line exception.
    First, under paragraph (c)(1), an exception may be available where
both the freight and passenger trains are limited to restricted speed.
Such operations are feasible only for short distances, and FRA would
examine the circumstances involved to ensure that the exposure is
limited and that appropriate operating rules and training are in place.
    Second, under paragraph (c)(2), FRA will consider an exception
where temporal separation of the freight and passenger operations can
be ensured. A more complete definition of temporal separation is
provided in paragraph (d). Temporal separation of passenger and freight
services reduces risk because the likelihood of a collision is reduced
(e.g., due to freight cars engaged in switching that are not properly
secured) and the possibility of a relatively more severe collision
between a passenger train and much heavier freight consist is obviated.
    Third, under paragraph (c)(3), FRA will consider commingled freight
and passenger operations provided that a jointly agreed risk analysis
is provided

by the passenger and freight railroads, and the level of safety is the
same as that which would be provided under one of the two prior options
selected as the base case. FRA seeks comments on whether FRA or the
subject railroad should determine the appropriate base case. FRA
recognizes that there may be situations where temporal separation may
not be possible. In such situations, FRA may allow commingled
operations provided the risk to the passenger operation is no greater
than if the passenger and freight trains where operating under temporal
separation or with all trains limited to restricted speed. For an
exception to be made under paragraph (c)(3), FRA requires a risk
analysis jointly agreed to and submitted by the applicable freight and
passenger services. This ensures that the risks and consequences to
both parties have been fully analyzed, understood, and mitigated to the
extent practical.
    Paragraph (d) proposes the definition of temporal separation with
respect to paragraph (c)(2). The temporal separation approach is
currently used under the FRA-Federal Transit Administration Joint
Policy on Shared Use, which permits co-existence of light rail
passenger services (during the day) and local freight service (during
the nighttime). See Joint Statement of Agency Policy Concerning Shared
Use of the Tracks of the General Railroad System by Conventional
Railroads and Light Rail Transit Systems, 65 FR. 42,526 (July 10,
2000); FRA Statement of Agency Policy Concerning Jurisdiction Over the
Safety of Railroad Passenger Operations and Waivers Related to Shared
Use of the Tracks of the General Railroad System by Light Rail and
Conventional Equipment, 65 FR 42529 (July 10, 2000). Conventional rail
technology and secure procedures are used to ensure that these services
do not commingle. Amtrak representatives in the PTC Working Group were
confident that more refined temporal separation strategies could be
employed on smaller railroads that carry light freight volumes and few
Amtrak trains (e.g., one train per day or one train per day in each
direction). The Passenger Task Force agreed.
    Proposed paragraph (e) ensures that by the time the railroad
submits its PTCSP, it has made no unapproved changes to the MTEA and
that the PTC system, as implemented, reflects the PTCIP and its MTEA.
Under the proposed rule, the PTCSP shall reflect the PTCIP, including
its MTEA, as it was approved or how it has been modified in accordance
with proposed Sec.  236.1021. FRA believes that it is also important
that the railroad attest that no other changes to the documents or to
the PTC system, as implemented, have been made.
    FRA understands that as a railroad implements its PTC system in
accordance with its PTCIP or even after it receives PTC System
Certification, the railroad may decide to modify the scope of which
tracks it believes to be other than main line. To effectuate such
changes, paragraph (f) proposes to require FRA review. In the case that
the railroad believes that such relief is warranted, the railroad may
file in accordance with proposed Sec.  236.1021 a request for amendment
of the PTCIP, which will eventually be incorporated into the PTCSP upon
PTCSP submission. Each request, however, must be fully justified to and
approved by the Associate Administrator before the requested change can
be made to the PTCIP. If such a RFA is submitted simultaneously with
the PTCSP, the RFA may not be approved, even if the PTCSP is otherwise
acceptable. A change made to a MTEA subsequent to FRA approval of its
associated PTCIP that involves removal or reduction in functionality of
the PTC system is treated as a material modification. In keeping with
traditional signaling principles, such requests must be formally
submitted for review and approval by FRA.

Section 236.1021 Discontinuances, Material Modifications, and
Amendments

    FRA recognizes that after submittal of a plan or implementation of
a train control system, the subject railroad may have legitimate
reasons for making changes in the system design and the locations where
the system is installed. In light of the statutory and regulatory
mandates, however, FRA believes that the railroad should be required to
request FRA approval prior to effectuating certain changes. Section
236.1021 proposes the scope and procedure for requesting and approving
those changes. For example, all requests for covered changes must be
made in a request for amendment (RFA) of the subject PTC system or
plan. While Sec.  236.1021 includes lengthy descriptions of what
changes may, or may not, require FRA approval, there are various places
elsewhere in subpart I that also require the filing of a RFA.
    Under paragraph (a), FRA proposes to require FRA approval prior to
certain PTC system changes. FRA expects that if a railroad wants to
make a PTC system change covered by subpart I, then any such change
would result in noncompliance with one of the railroad's plans approved
under this subpart. For instance, if a railroad seeks to modify the
geographical limits of its PTC implementation, such changes would not
be reflected in the PTCIP. Accordingly, under paragraph (a), after a
plan is approved by FRA and before any change is made to the PTC
system's development, implementation, or operation, FRA proposes that
the railroad file a RFA to the subject plan.
    FRA considers an amendment to be a formal or official change made
to the PTC system or its associated PTCIP, PTCDP, or PTCSP. Amendments
can add, remove, or update parts of these documents, which may reflect
proposed changes to the development, implementation, or operation of
its PTC system. FRA believes that an amending procedure provides a
simpler and cleaner option than requiring the railroad to file an
entirely new plan.
    While the railroad may develop a RFA without FRA input or
involvement, FRA believes that it is more advantageous for the railroad
to informally confer with FRA before formally submitting its RFA. If
FRA is not involved in the drafting process, FRA may not have a
complete understanding of the system, making it difficult for FRA to
evaluate the impact of the proposed changes on public safety. After RFA
submission, all applicable correspondence between FRA and the railroad
must be made formally in the associated docket, as further discussed
below. In such a situation, FRA's review may take a significantly
longer time than usual. If FRA continues to not understand the impact,
it may request a third party audit, which would only further delay a
decision on the request. Accordingly, FRA believes it is more
advantageous for the railroad drafting an RFA to informally confer with
FRA before its formal submission of the change request. The railroad
would then be provided an opportunity to discuss the details of the
change and to assure FRA's understanding of what the railroad wishes to
change and of the change's potential impact.
    Paragraph (b) proposes a mechanism for requesting such change. Once
the RFA is approved, the railroad may--and, in fact, is required under
paragraph (b)--to adopt those changes into the subject plan and
immediately ensure that its PTC complies with the plan, as amended. FRA
expects that each PTC system accurately reflects the information in its
associated approved plans. FRA believes that this requirement will also
incentivize railroads to make approved changes as quickly as possible.
Otherwise, if a railroad delays in implementing the changes reflected
in an approved RFA,

FRA may find it difficult to enforce its regulations until
implementation is completed, since they plans and PTC system to not
accurately and adequately reflect each other. In such circumstances,
railroads may be assessed a civil penalty for violating its plan or for
falsifying records.
    Any change to a PTCIP, PTCDP, or PTCSP, which may include removal
or discontinuance of any signal system, may not take effect until after
FRA has approved the corresponding submitted or amended PTCIP, PTCDP,
or PTCSP. FRA may provide partial or conditional approval. Until FRA
has granted appropriate relief or approval, the railroad may not make
the change, and once a requested change has been made, the railroad
must comply with requested change.
    FRA recognizes that a railroad may wish to remove an existing train
control system due to new and appropriate PTC system implementation.
For train control systems existing prior to promulgation of subpart I,
any request for a material modification or discontinuance must be made
pursuant to part 235. FRA proposes in paragraph (c), however, to
provide the railroads with an opportunity to instead request such
changes in accordance with proposed Sec.  236.1021. FRA believes that
this proposal would reduce the number of required filings and would
otherwise simplify the process requesting material modifications or
discontinuances.
    Paragraph (d) proposes the minimum information required to be
submitted to FRA when requesting an amendment. While FRA proposes to
promulgate procedural rules here different than those in part 235, FRA
expects that the same or similar information be provided. Accordingly,
under paragraph (d)(1), the RFA must contain the information required
in 235.10. Paragraph (d)(1) also requires the railroad to submit, upon
FRA request, certain additional information, including the information
referenced in Sec.  235.12. Paragraphs (d)(2) through (d)(7) provide
further examples of such information. While such information may only
be required upon request, FRA urges each railroad to include this
information in its RFA to help expedite the review process.
    FRA believes that proposed paragraphs (d)(2) through (d)(6) are
self-explanatory. However, according to proposed paragraph (d)(7), FRA
may require with each RFA an explanation of whether each change to the
PTCSP is planned or unplanned. Planned changes are those that the
system developer and the railroad have included in the safety analysis
associated with the PTC system, but have not yet implemented. These
changes provide enhanced functionality to the system, and FRA strongly
encourages railroads to include PTC system improvements that further
increase safety. A planned change may require FRA approved regression
testing to demonstrate that its implementation has not had an adverse
affect on the system it is augmenting. Each planned change must be
clearly identified as part of the PTCSP, and the PTCSP safety analysis
must show the affect that its implementation will have on safety.
    Unplanned changes are those either not foreseen by the railroad or
developer, but nevertheless necessary to ensure system safety, or are
unplanned functional enhancements from the original core system. The
scope of any additional necessary work necessary to ensure safety may
depend upon when in the development cycle phase the changes are
introduced. For instance, if the PTCDP has not yet been submitted to
FRA, no FRA involvement is required. However if the PTCDP has been
submitted to FRA, or if the change impacts the safety functionality of
the system once a Type Approval has been issued, and a PTCSP has not
yet submitted, the railroad must submit a RFA requesting and
documenting that change. Once FRA approves that RFA, FRA expects the
subsequently filed PTCSP to account for the change in analysis.
    If the change is made after approval of the PTCSP and the system
has been certified by FRA, a RFA must be submitted to FRA for approval.
Because this requires significant effort by FRA and the railroad, FRA
expects that every effort will be made to eliminate the need for
unplanned changes. If the railroad and the vendor submit unplanned
safety related changes that FRA believes are a significant amount or
inordinately complex, FRA may revoke any approvals previously granted
and disallow the use of the product until such time the railroad
demonstrates the product is sufficiently mature.
    Paragraph (e) proposes that if a RFA is submitted for a
discontinuance or a material modification to a portion or all of its
PTC system, a notice of its submission shall be published in the
Federal Register. Interested parties will be provided an opportunity to
comment on the RFA, which will be located in an identified docket.
    Proposed paragraph (f) makes it clear that FRA will consider all
impacts on public safety prior to approval or disapproval of any
request for discontinuance, modification, or amendment of a PTC system
and any associated changes in the existing signal system that may have
been concurrently submitted. While the economic impact to the affected
parties may be considered by the FRA, the primary and final deciding
factor on any FRA decision is safety. FRA will consider not only how
safety is affected by installation of the system, but how safety is
impacted by the failure modes of the system.
    The purpose of proposed paragraph (g) is to emphasize the right of
FRA to unilaterally issue a new Type Approval, with whatever conditions
are necessary to ensure safety based on the impact of the proposed
changes.
    In proposed paragraph (h), FRA makes clear that it considers any
implemented PTC system to be a safety device. Accordingly, the
discontinuance, modification, or other change of the implemented system
or its geographical limits will not be authorized without prior FRA
approval. While this requirement primarily applies to safety critical
changes, FRA believes that they should also apply to all changes that
will affect interoperability. FRA seeks comments on this issue. The
principles expressed in the paragraph parallel those embodied in part
235, which implements 49 U.S.C. 20502(a).
    That said, FRA recognizes that there are a limited number of
situations where changes of the PTC system may not have an adverse
impact upon public safety. Specific situations where prior FRA approval
is required are proposed in paragraphs (h)(1) through (h)(4).
    Paragraph (i) proposes the exceptions from the requirement for
prior approval in cases where the discontinuance of a system or system
element will be treated as pre-approved, as when a line of railroad is
abandoned.
    Paragraph (j) proposes exceptions for certain lesser changes that
are not expected to materially affect system risk, such as removal of
an electric lock from a switch where speed is low and trains are not
allowed to clear.
    Paragraph (k) proposes additional exceptions consisting of
modifications associated with changes in the track structure or
temporary construction. FRA notes that only temporary removal of the
PTC system without prior FRA approval is allowed to support highway
rail separation construction or damage to the PTC system by
catastrophic events. In both cases, the PTC system must be restored to
operation no later than 6 months after completion of the event.

Section 236.1023 Errors and Malfunctions

    Because PTC systems are approved, in part, based on certain
assumptions regarding expected failure modes and frequencies, reporting
and recording of errors and malfunctions takes on critical importance.
If the number of errors and malfunctions exceeds those originally
anticipated in the design, or errors and malfunctions that were not
predicted are observed to occur, the validity of the risk analysis
becomes suspect. Since not all railroads may experience the same
software faults or hardware failures, the developer's development,
configuration management, and fault reporting tracking system play a
crucial role in the ability of the railroad and FRA to determine and
fully understand the risks and their implications. Without an effective
configuration management tracking system in place, it is difficult, if
not impossible, to fairly evaluate PTC system risks during the system's
life cycle.
    In the event of a safety-essential PTC system component failing to
perform as intended, FRA intends to propose under Sec.  236.1023 that
the cause be identified and corrective action be taken without undue
delay. Until the repair is completed, the railroad and vendors are
required to take appropriate measures to assure the safety of train
movements, roadway workers, and on-track equipment. This requirement
mirrors the current requirements of 49 CFR 236.11, which applies to all
signal system components. FRA recognizes that there may be situations
where reducing the severity of such hazards will suffice for an
equivalent reduction in risk. For example, a reduction in operating
speeds may not reduce the frequency of certain hazards involving
safety-critical products, but it may reduce the severity of such
hazards in most cases.
    Paragraph (a) proposes a direct obligation on suppliers to report
safety-relevant failures, including ``wrong-side'' failures and other
failures significantly impacting availability, where the PTCSP
indicates availability to be a material issue in the safety performance
of the larger railroad system. FRA expects each applicable supplier to
identify the problem and the necessary corrective actions, recommended
risk mitigations, and provide an estimated amount of time it expects to
complete the corrective actions. FRA believes that it should be
informed to ensure public safety in any case where a commercial dispute
(e.g., over liability) might disrupt communication between a railroad
and supplier.
    Paragraph (b) proposes a similar responsibility on the part of the
railroad to report safety relevant failures to the supplier and FRA,
and to keep the vendor and FRA apprised of any subsequent failures. To
aid FRA in understanding the scope of a problem on a railroad, and to
aid the railroad in communicating any PTC system failures to the
appropriate vendor, paragraph (c) proposes to require that each
railroad keep a currently updated PTC Product Vendor List (PTCVPL),
which must identify each supplier of PTC equipment on its railroad.
    Paragraph (d) proposes the requirement that each railroad identify
the procedures for action upon notification from the manufacturer of a
safety-critical upgrade, patch, or revision performed within the scope
of the applicable PTCDP. FRA expects that when issues are discovered
that may adversely affect the safe operation of the system, regardless
if the railroad has experienced the problem, the railroad will take
corrective action without undue delay (see Sec.  236.11). FRA believes
this is necessary to ensure that each railroad promptly addresses
applicable errors to maintain a common safety baseline by performing
component changes that, if left uncorrected, would increase risk or
interfere with the safety of train operations. If the action were to
take a significant amount of time, FRA proposes to require the railroad
to provide FRA with periodic frequent progress reports.
    Paragraph (e) proposes time limits for reporting failures and
malfunctions and the minimum reporting requirements. FRA has no
specific format for the reports, and will accept any format provided it
contains at least the information required by this proposed rule. FRA
will accept delivery of these reports by commercial courier, fax, and
e-mail.
    Paragraph (f) proposes to require the manufacturer to provide a
detailed explanation of the problem and the intended or performed
corrective action to FRA upon request, in the event that a PTC system
is found to be unsafe due to a design or manufacturing defect. While
the railroad may be able to report symptoms of a problem, it is the
manufacturer who is in the best position to determine its underlying
root cause. FRA may require this information to determine the full
impact of the problem, and to determine if any additional restrictions
or limitations on the use of the PTC may be warranted to ensure the
safety of the general public and the railroad personnel.
    Proposed paragraph (g) is intended to limit unnecessary reporting.
If the failure was the result of improper operation of the PTC system
outside of the design parameters or of non-compliance with the
applicable operating instructions, FRA believes that compliance with
paragraph (f) is not necessary. Instead, FRA expects, and proposes to
require, the railroad to engage in more narrow remedial measures,
including remedial training by the railroad in the proper operation of
the PTC system. Similarly, once a problem has been identified to all
stakeholders, FRA does not believe it is necessary for a manufacturer
to repeatedly submit a formal report in accordance with paragraph (f).
In either situation, however, FRA expects that all users of the
equipment are proactively and timely notified of the misuse that
occurred and the corrective actions taken.
    Such reports, however, do not have to be made within seven days of
occurrence, as required for other notifications under paragraph (e),
but within a reasonable time appropriate to the nature and extent of
the problem.
    Proposed paragraph (h) is intended to make clear that the reporting
requirements of part 233 are not a substitute for the proposed
reporting requirements of this subpart. Both requirements apply. In the
case of a false proceed signal indication, FRA would not expect the
railroad to wait for the frequency of such occurrences to exceed the
threshold reporting level assigned in the hazard log of the PTCSP.
Rather, current Sec.  233.7 requires all such instances to be reported.

Section 236.1027 Exclusions

    This section retains similarities to, but also establishes
contrasts with, Sec.  236.911, which deals with exclusions from subpart
H. In particular, Sec.  236.911(c) offers reassurance that a stand-
alone computer aided dispatching (CAD) system would not be considered a
safety-critical processor-based system within the purview of subpart H.
CADs have long been used by large and small railroads to assist
dispatchers in managing their workload, tracking information required
to be kept by regulation, and--most importantly--providing a conflict
checking function designed to alert dispatchers to incipient errors
before authorities are delivered. Even Sec.  236.911, however, states
that ``a subsystem or component of an office system must comply with
the requirements of this subpart if it performs safety-critical
functions

within, or affects the safety performance of, a new or next-generation
train control system.'' In fact, FRA is currently working with a vendor
on a simple CAD that provides authorities in an automated fashion,
without the direct involvement of a dispatcher.
    For subpart I, FRA wishes to retain the exception referred to in
Sec.  236.911 for CAD systems not associated with a PTC system. Many
smaller railroads use CAD systems to good effect, and there is no
reason to impose additional regulations where dispatchers
contemporaneously retain the function of issuing mandatory directives.
However, in the present context, it is necessary to recognize that PTC
systems utilize CAD systems as the ``front end'' of the logic chain
that defines authorities enforced by the PTC system, particularly in
non-signaled territory.
    Accordingly, paragraph (a) proposes the potential exclusion of
certain office systems technologies from subpart I compliance. These
existing systems have been implemented voluntarily to enhance
productivity and have proven to provide a reasonably high level of
safety, reliability, and functionality. FRA recognizes that full
application of subpart I to these systems would present the rail
industry with a tremendous burden. The burdens of subpart I may
discourage voluntary PTC implementation and operation by the smaller
railroads.
    However, FRA proposes to apply subpart I to those subsystems or
components that perform safety critical functions or affect the safety
performance of the associated PTC system. The level and extent of
safety analysis and review of the office systems will vary depending
upon the type of PTC system with which the office system interfaces.
For example, to prevent the issuance of overlapping and inconsistent
authorities, FRA expects that each PTC system demonstrate sufficient
credible evidence that the requisite safety-critical, conflict
resolution (although not necessarily vital) hardware and software
functions of the system will work as intended. FRA also expects that
the applicable PTCDP's and PTCSP's risk analysis will identify the
associated hazards and describe how they have been mitigated.
Particularly where mandatory directives and work authorities are
evaluated for use in a PTC system use without separate oral
transmission from the dispatcher to the train crew or employee in
charge--with the opportunity for receiving personnel to evaluate and
confirm the integrity of the directive or authority received and the
potential for others overhearing the transmission to note conflicting
actions by the dispatching center--FRA will insist on explanations
sufficient to provide reasonable confidence that additional errors will
not be introduced.
    Paragraph (b) proposes requirements for modifications of excluded
PTC systems. At some point when a change results in degradation of
safety or in a material increase in safety-critical functionality,
changes to excluded PTC systems or subsystems may be significant enough
to require application of subpart I's safety assurance processes. FRA
believes that all modifications caused by unforeseen implementation
factors will not necessarily cause the product to become subject to
subpart I. These types of implementation modifications will be minor in
nature and be the result of site specific physical constraints.
However, FRA expects that implementation modifications that will result
in a degradation of safety or a material increase in safety-critical
functionality, such as a change in executive software, will cause the
PTC system or subsystem to be subject to subpart I and its
requirements. FRA is concerned, however, that a series of incremental
changes, while each individually not meeting the threshold for
compliance with this subpart, may when aggregated result in a product
which differs sufficiently so as to be considered a new product.
Therefore, FRA reserves the right to require products that have been
incrementally changed in this manner to comply with the requirements of
this subpart. Prior to FRA making such a determination, the affected
railroad will be allowed to present detailed technical evidence why
such a determination should not be made. This provision mirrors
paragraph (d) of existing Sec.  236.911.
    Proposed paragraph (c) addresses the integration of train control
systems with other locomotive electronic control systems. The earliest
train control systems were electro-mechanical systems that were
independent of the discrete pneumatic and mechanical control systems
used by the locomotive engineer for normal throttle and braking
functions. Examples of these train control systems included cab signals
and ACS/ATC appliances. These systems included a separate antenna for
interfacing with the track circuit or inductive devices on the wayside.
Their power supply and control logic were separate from other
locomotive functions, and the cab signals were displayed from a
separate special-purpose unit. Penalty brake applications by the train
control system bypassed the locomotive pneumatic and mechanical control
systems to directly operate a valve that accomplished a service
reduction of brake pipe pressure and application of the brakes as well
as reduction in locomotive tractive power. In keeping with this
physical and functional separation, train control equipment on board a
locomotive came under part 236, rather than the locomotive inspection
requirements of part 229.
    Advances in hardware and software technology have allowed the
various PTC systems' and components' original equipment manufacturers
(OEMs) to repackage individual components, eliminating parts and system
function control points access. Access to control functions became
increasingly restricted to the processor interfaces using proprietary
software. While this resulted in significant simplification of the
previously complex discrete pneumatic and mechanical control train and
locomotive control systems into fewer, more compact and reliable
devices, it also creates significant challenges with respect to
compatibility of the application programs and configuration management.
    FRA encourages such enhancements, and believes, if properly done,
can result in significant safety, as well as operational, improvements.
Locomotive manufacturers can certainly provide secure locomotive and
train controls, and it is important that they do so if locomotives are
to function safely in their normal service environment. FRA highly
encourages the long-term goal of common platform integration. However,
when such an integration occurs, it must not be done at the expense of
decreasing the safe, and reliable operation of the train control
system. Accordingly FRA expects that the complete integrated system
will be shown to have been designed to fail-safe principles, and then
demonstrated that the system operates in a fail safe mode. Any
commingled system must have a manual failsafe fall back up that allows
the engineer to be brought to a safe stop in the event of an electronic
system failure. This analysis must be provided to FRA for approval in
the PTCDP and PTCSP as appropriate. This provision mirrors the
heightened scrutiny called for by Sec.  236.913(c) of subpart H for
commingled systems, but is more explicit with respect to FRA's
expectations. The provision in general accords with the requirements
for locomotive systems that are currently under development in the
RSAC's Locomotive Safety Standards Working Group.
    Finally proposed paragraph (d) clarifies the application of
subparts A

through H to products excluded from compliance with Subpart I. These
products are excluded from the requirements of subpart I, but FRA
expects that the developing activity demonstrates compliance of
products with Subparts A through H. FRA believes that railroads not
mandated to implement PTC, or that are implementing other non-PTC
related processor based products should be given the option to have
those products approved under subpart H by submitting a PSP and
otherwise complying with subpart H or voluntarily complying with
subpart I. This provision mirrors Sec.  236.911(e) of subpart H.

Section 236.1029 PTC System Use and En Route Failures

    This section proposes minimum requirements, in addition to those
found in the PTC system's plans, for each PTC system with a PTC System
Certification. Railroads are allowed, and encouraged, to adopt more
restrictive rules that increase safety.
    Paragraph (a) proposes to require that, in the event of the failure
of a component essential to the safety of a PTC system to perform as
intended, the cause be identified and corrective action taken without
undue delay. The paragraph also requires that until the corrective
action is completed, the railroad is required at a minimum, to take the
appropriate measures, including those specified in the PTCSP, to assure
the safety of train movements, roadway workers, and on-track equipment.
This proposed requirement mirrors current requirements of Sec.  236.11,
which applies to all signal and train control system components. Under
proposed paragraph (a), FRA intends to apply to PTC systems provided
PTC System Certification under subpart I the same standard in current
Sec.  236.11.
    Paragraph (b) proposes the circumstance where a PTC onboard
apparatus on a lead locomotive that is operating in or is to be
operated within a PTC system fails or is otherwise cut-out while en
route. Under proposed paragraph (b), the subject train may only
continue such operations in accordance with specific limitations. An en
route failure is applicable only in instances after the subject train
has departed its initial terminal, having had a successful
initialization, and subsequently rendering it no longer responsive to
the PTC system. For example, FRA believes that an en route failure may
occur when the PTC onboard apparatus incurs an onboard fault or is
otherwise cut out.
    Under subpart H, existing Sec.  236.567 provides specific
limitations on each train failing en route in relation to its
applicable automatic cab signal, train stop, and train control system.
FRA believes that it would be desirable to impose somewhat more
restrictive conditions given the statutory mandate and the desire to
have an appropriate incentive to properly maintain the equipment and to
timely respond to en route failures. For instance, FRA recognizes that
the limitations of Sec.  236.567 do not account for the statutory
mandates of the core PTC safety functions. However, during the PTC
Working Group meetings, no consensus was reached on how to regulate en
route failures on PTC territory. Nevertheless, proposed Sec.  236.1029,
and in particular proposed paragraph (b), purposefully intend to
parallel the limitations contained in Sec.  236.567. In other words,
FRA intends that Sec.  236.567 and proposed paragraph (b) to Sec.
236.1029 will share the common purpose of maintaining a level of safety
generally in accord with that expected with the train control system
fully functional. This is accomplished by requiring supplementary
procedures to heighten awareness and provide operational control
(limiting the frequency of unsafe events) and by restricting the speed
of the failed train (reducing the potential severity of any unsafe
event).
    Paragraph (b)(1) proposes to allow the subject train to proceed at
restricted speed--or at medium speed if a block signal system is in
operation according to signal indication--to the next available point
where communication of a report can be made to a designated railroad
officer of the host railroad. The intent of this requirement is to
ensure that the occurrence of an en route failure may be appropriately
recorded and that the necessary alternative protection of absolute
block is established.
    After a report is made in accordance with paragraph (b)(1), or made
electronically and immediately by the PTC system itself, paragraph
(b)(2) proposes to allow the train to continue to a point where an
absolute block can be established in advance of the train in accordance
with the limitations that follow in paragraphs (b)(2)(i) and (ii).
Paragraph (b)(2)(i) proposes to require that where no block signal
system is in use, the train may proceed at restricted speed.
Alternatively, under proposed paragraph (b)(2)(ii), the train may
proceed at a speed not to exceed medium speed where a block signal
system is in operation according to signal indication.
    Paragraph (b)(3) proposes to require that, upon the subject train
reaching the location where an absolute block has been established in
advance of the train, the train may proceed in accordance with the
limitations that follow in paragraphs (b)(3)(i), (ii), or (iii).
Proposed paragraph (b)(3)(i) requires that where no block signal system
is in use, the train may proceed at medium speed; however, if the
involved train is a train which is that of the criteria requiring the
PTC system installation (i.e., a passenger train or a train hauling any
amount of PIH material), it may only proceed at a speed not to exceed
30 miles per hour. Paragraph (b)(3)(ii) requires that where a block
signal system is in use, a passenger train may proceed at a speed not
to exceed 59 miles per hour and a freight train may proceed at a speed
not to exceed 49 miles per hour. Paragraph (b)(3)(iii) requires that
except as provided in paragraph (c), where a cab signal system with an
automatic train control system is in operation, the train may proceed
at a speed not to exceed 79 miles per hour.
    Paragraph (c) requires that, in order for a PTC train that operates
at a speed above 90 miles per hour to deviate from the operating
limitations contained in paragraph (b) of this section, the deviation
must be described and justified in the FRA approved PTCDP or PTCSP, or
the Order of Particular Applicability, as applicable.
    Paragraph (d) proposes to require that the railroad operate its PTC
system within the design and operational parameters specified in the
PTCDP and PTCSP. Railroads will not exceed maximum volumes, speeds, or
any other parameter provided for in the PTCDP or PTCSP. On the other
hand, a PTCDP or PTCSP could be based upon speed or volume parameters
that are broader than the intended initial application, so long as the
full range of sensitivity analyses is included in the supporting risk
assessment. FRA feels this requirement will help ensure that
comprehensive product risk assessments are performed before products
are implemented.
    Paragraph (e) sets forth the requirement that any testing of the
PTC system must not interfere with its normal safety-critical
functioning, unless an exception is obtained pursuant to 49 CFR
236.1035, where special conditions have been established to protect the
safety of the public and the train crew. Otherwise, paragraph (e)
requires that each railroad ensure that the integrity of the PTC system
not be compromised, by prohibiting the normal functioning of such
system to be interfered with by testing or otherwise without first
taking measures to provide for the safety of train movements, roadway
workers, and

on-track equipment that depend on the normal safety-critical
functioning of the system. This provision parallels current Sec.
236.4, which applies to all systems. By requiring this paragraph, FRA
also intends to clarify that the standard in current Sec.  236.4 also
applies to subpart I PTC systems.
    Paragraph (f) proposes to require that each member of the operating
crew has appropriate access to the information and functions necessary
to perform his or her job safely when products are implemented and used
in revenue service. Where two-person crews are employed, availability
of a screen and any needed function keys will enable the second crew
person to carry out PTC onboard computer-related activities without
distracting the locomotive engineer from maintaining situational
awareness of activities outside the locomotive cab. FRA's existing
regulations for train control in Sec.  236.515 requires that the cab
signal display be clearly visible to each member of the crew. FRA
believes the decision to operate with one PTC screen, only accessible
to the engineer, can only be made after careful analysis of the human
factor implications, the associated risks, and the sensitivity of the
safety analysis that is used to potentially justify the decision. FRA
notes that the principles of crew resource management and current crew
briefing practices in the railroad industry require that all members of
a functioning team (e.g., engineer, conductor, dispatcher, roadway
worker in charge) have all relevant information available to facilitate
constructive interactions and permit incipient errors to be caught and
corrected. Retaining and reinforcing this level of cooperation will be
particularly crucial during the early PTC implementation as errors in
train consist information, errors generated in on-board processing,
delays in delivery of safety warnings due to radio frequency
congestion, and occasional errors in dispatching challenge the
integrity of PTC systems even as the normal reliability of day-to-day
functioning supports reductions in vigilance. Loss of crew cooperation
could easily spill over to other functions, including switching
operations and management of emergency situations.
    This issue was the subject of significant disagreement within the
PTC Working Group. FRA appreciates the views of those who suggest that
the cost of additional displays is not warranted and the argument that,
where there is an additional crew member assigned, no value may be
added by isolating the second crew member from potentially corrupted
information communicated from the PTC display. However, FRA believes
that there is a strong likelihood that railroads will at some point in
the future seek to deliver electronically all mandatory directives from
the dispatcher to the PTC onboard apparatus, obviating the need for
oral transmission. When this occurs, FRA believes that having a second
crew member involved in receipt and confirmation of the authority will
be useful to verify situational appropriateness and avoid information
overload of the locomotive engineer.

Section 236.1031 Previously Approved PTC Systems

    FRA recognizes that substantial effort has been voluntarily
undertaken by the railroads to develop, test, and deploy PTC systems
prior to the passage of the RSIA08, and that some of the PTC systems
have accumulated a significant history of safe and reliable operations.
In order to facilitate the ability of the railroads to leverage the
results of PTC design, development, and implementation efforts that
have been previously been approved or recognized by FRA prior to the
adoption of this subpart, FRA is proposing an expedited certification
process in this section.
    Under proposed paragraph (a), each railroad that has a PTC system
that may qualify for expedited treatment would have to submit a Request
for Expedited Certification (REC) letter. Products that have not
received approval under the subpart H, or that have not been previously
recognized by FRA, would be ineligible. The REC letter may be jointly
submitted by PTC railroads and suppliers as long as there is at least
one PTC railroad. A PTC system may qualify for expedited certification
if it fulfills at least one of the descriptions proposed in paragraphs
(a)(1) through (a)(3). While these descriptions are objective in
nature, FRA intends them to cover ETMS, ITCS, and ACSES, respectively.
    Proposed paragraph (a)(1) applies to systems that have been
recognized or approved by FRA after submission of a product safety plan
(PSP) in accordance with subpart H. Subpart I generally reflects the
same criteria required for a PSP under subpart H. Thus, FRA believes
that most of the PTCDP and PTCSP requirements in subpart I can be
fulfilled with the submission of the existing and approved PSP.
However, FRA notes that the subject railroad will also need to submit
the information required in a PTCDP and PTCSP that is not in the
current PSP.
    FRA also recognizes that certain PTC systems may currently operate
in revenue service with FRA approval through the issuance of a waiver
or order. Proposed paragraphs (a)(2) and (a)(3) intend to cover those
systems.
    If a PTC system complying with paragraph (a)(1) is provided
expedited certification, the system plans should ultimately match the
criteria required for each PTCDP and PTCSP. As previously noted, a
railroad may seek to use a PTC system that has already received a Type
Approval. To extend this benefit as it applies to previously used
systems for which expedited certification is provided, paragraph (b)
proposes to give the Associate Administrator the ability to provide a
Type Approval to systems receiving expedited certification in
accordance with paragraph (a)(1).
    FRA recognizes that certain systems eligible for expedited
certification may not entirely comply with the subsequently issued
statutory mandate. Accordingly, under paragraph (c), FRA is compelled
to propose that before any Type Approval or expedited certification may
be provided, the PTC system must be shown to reliably execute the same
functionalities of every other PTC system required by subpart I.
Nothing in this abbreviated process should be construed as implying the
automatic granting by FRA of a Type Approval or PTC System
Certification. Each expedited request for a Type Approval or PTC System
Certification must be submitted by the railroad under this abbreviated
process and, as required under subpart I, must demonstrate that the
system reliably enforces positive train separation and prevents
overspeed derailments, incursions into roadway worker zones, and
movements through misaligned switches.
    Under proposed paragraph (d), FRA encourages railroads, to the
maximum extent possible, to use proven service history data to support
their requests for Type Approval and PTC System Certification. While
proven service history cannot be considered a complete replacement for
an engineering analysis of the risks and mitigations associated with a
PTC product, it provides great creditability for the accuracy of the
engineering analysis. Testing and operation can only show the absence
or mitigation of a particular failure mode, and FRA believes that there
will always be some failure modes that may only be determined through
analysis. Due to this inherent limitation associated with testing and
operation, FRA also strongly encourages the railroads to also submit
any available analysis or information.
    Paragraph (e) proposes that, to the extent that the PTC system
proposed for implementation under this subpart is different in
significant detail from the

system previously approved or recognized, the changes shall be fully
analyzed in the PTCDP or PTCSP as would be the case absent prior
approval or recognition. FRA understands that the PTC product for which
expedited Type Approval and PTC System Certification is sought may
differ in terms of functionality or implementation from the PTC product
previously approved or recognized by FRA. In such a case, the service
history and analysis may not align directly with the new variant of the
product. Similarly, the available service history and analysis
associated with a PTC product may be inconclusive about the reliability
of a particular function. It is because of these possible situations
that FRA can not unequivocally promise that all requests for expedited
Type Approval and PTC System Certification submitted by a railroad
under this subpart will be automatically granted. FRA will, however,
apply the available service history and analytical data as credible
evidence to the maximum extent possible. FRA believes that this still
greatly simplifies each railroad's task in making its safety case,
since the additional testing and analysis required need only address
those areas for which credible evidence is insufficient. To reduce the
overall level of financial resources and effort necessary to obtain
sufficient credible evidence to support the claims being made for the
safety performance of the product, FRA also encourages each railroad to
share with other railroads a system's service history and the results
of any analysis, even in the case where the shared information does not
fully support a particular railroad's safety analysis.
    Proposed paragraph (f) defines terms used only in this section.
``Approved'' refers to approval of a Product Safety Plan under subpart
H. As this NPRM was being prepared, only BNSF Railway's ETMS
Configuration I had been so approved, but other systems were under
development. ``Recognized'' refers to official action permitting a
system to be implemented for control of train operations under an order
or waiver, after review of safety case documentation for the
implementation. As this NPRM was being prepared, only ACSES I had been
recognized under an order of particular applicability, and ACSES II was
under review for potential approval. Only one system, the ITCS in place
on Amtrak's Michigan line, had been approved for unrestricted revenue
service under waiver.
    FRA was unable to fashion an outright ``grandfathering'' of
equipment previously used in transit and foreign service. FRA does not
have the same degree of direct access to the service history of these
systems. Transit systems--except those that are connected to the
general railroad system--are not directly regulated by FRA. FRA has had
limited positive experience eliciting safety documentation from foreign
authorities, particularly given the influence of national industrial
policies.
    However, FRA believes that, while complete exclusion may not be
available in those circumstances, procedural simplification may be
possible. FRA is considering a procedure under which the railroad and
supplier could establish safety performance at the highest level of
analysis for the particular product, relying in part on experience in
the other service environments and showing why similar performance
should be expected in the U.S. environment. Foreign signal suppliers
should be in a good position to marshal service histories for these
products and present them as part of the railroad's PTCSP. For any
change, the applicant must provide additional information that will
enable FRA to make an informed decision regarding the potential impact
of the change on safety. This information must include, but is not
limited to, the following: (1) A detailed description of the change;
(2) a detailed description of the hardware and software impacted by the
change; (3) a detailed description of any new functional data flows
resulting from the change; (4) the results of the analysis used to
verify that the change did not introduce any new safety risks or, if
the change did introduce any new safety risks, a detailed description
of the new safety risks and the associated risk mitigation actions
taken; (5) the results of the tests used to verify and validate the
correct functionality of the product after the change has been made;
(6) a detailed description of any required modifications in the
railroad training plan that are necessary for continued safe operation
of the product after the change; and (7) a detailed description of any
new test equipment and maintenance procedures required for the
continued safe operation of the product. FRA requests comment on
whether and in what way these concepts might be captured in the final
rule.
    In the same vein, paragraph (g) encourages re-use of safety case
documentation previously reviewed, whether under subpart H or subpart
I.

Section 236.1033 Communications and Security Requirements

    Subpart I proposes specific communications security requirements
for PTC system messages. Proposed Sec.  236.1033 originated from the
radio and communications task force within the PTC Working Group. The
objectives of the proposal are to ensure data integrity and
authentication for communications with and within a PTC system.
    In data communications, ``cleartext'' is a message or data in a
form that is immediately comprehensible to a human being without
additional processing. In particular, it implies that this message is
transferred or stored without cryptographic protection. It is related
to, but not entirely equivalent to, the term ``plaintext.'' Formally,
plaintext is information that is fed as an input to a cryptographic
process, while ``ciphertext'' is what comes out of that process.
Plaintext might be compressed, encrypted, or otherwise manipulated
before the cryptographic process is applied, so it is quite common to
find plaintext that is not cleartext. Cleartext material is sometimes
in plain text form, meaning a sequence of characters without
formatting, but this is not strictly required. The security
requirements proposed in this document are consistent with the
Department of Homeland Security (DHS) guidance for SCADA systems and
the National Institute of Standards and Technology guidance. FRA has
coordinated this proposal with DHS.
    Proposed paragraph (a) establishes the requirement for message
integrity and authentication. Integrity is the assurance that data is
consistent and correct. Generally speaking, in cryptography and
information security, integrity refers to the validity of data.
Integrity can be compromised through malicious altering--such as an
attacker altering an account number in a bank transaction, or forgery
of an identity document--or accidental altering--such as a transmission
error, or a hard disk crash. A level of data integrity can be achieved
by mechanisms such as parity bits and Cyclic Redundancy Codes (CRCs).
Such techniques, however, are designed only to detect some proportion
of accidental bit errors; they are powerless to thwart deliberate data
manipulation by a determined adversary whose goal is to modify the
content of the data for his or her own gain. To protect data against
this sort of attack, cryptographic techniques are required. Thus,
appropriate algorithms and keys must be employed and commonly
understood between the entity wanting to provide data integrity and the
entity wanting to be assured of data integrity.
    Authentication is the act of establishing or confirming something
(or someone) as authentic. Various systems have been invented to
provide a means

for readers to reliably authenticate the sender. In any event, the
communication must be properly protected; otherwise, an eavesdropper
can simply copy the relevant data and later replay it, thereby
successfully masquerading as the original, legitimate entity.
    Sender authentication typically finds application in two primary
contexts. Entity identification serves simply to identify the specific
entity involved, essentially in isolation from any other activity that
the entity might want to perform. The second context is data origin
identification, which identifies a specific entity as the source or
origin of a given piece of data. This is not entity identification in
isolation, nor is it entity identification for the explicit purpose of
enabling some other activity. Rather, this is identification with the
intent of statically and irrevocably binding the identified entity to
some particular data, regardless of any subsequent activities in which
the entity might engage. Cryptographically based signatures provide
nearly irrefutable evidence that can be used subsequently to prove to a
third party that this entity did originate--or at least possess--the
data.
    Proposed paragraph (b)(1) requires that cryptographic algorithms
and keys used to establish integrity and authenticity be approved by
either the National Institute of Standards or a similar standards
organization acceptable to FRA. As a practical matter, cryptographic
algorithms can be believed secure by competent, experienced, practicing
cryptographers. This requires that the algorithms be publicly known and
have been seriously studied by working cryptographers. Algorithms that
have been approved by NIST (or similar standards bodies) can be assured
of being both publicly known and seriously studied.
    Proposed paragraph (b)(2) allows the use of either manual or
automated means to distribute keys. Key distribution is the most
important component in secure transmissions. The general key
distribution problem refers to the task of distributing keys between
communicating parties to provide the required security properties.
Frequent key changes are usually desirable to limit the amount of data
compromised if an attacker learns the key. Therefore, the strength of
any cryptographic system results with the key distribution technique, a
term that refers to the means of delivering a key to two parties that
wish to exchange data without allowing others to see the key. Key
distribution can be achieved in a number of ways. There are various
combinations by which a key can be selected manually or in automation
amongst one or multiple parties.
    Proposed paragraph (b)(3) establishes the conditions under which
cryptographic keys must be revoked. Paragraph (b)(3)(i) addresses the
situation when a key has actually been found to have been compromised
and when the possibility of key compromise exists. Cryptographic
algorithms are part of the foundations of the security house, and any
house with weak foundations will collapse. Adequate procedures should
be foreseen to take an algorithm out of service or to upgrade an
algorithm which has been used beyond its lifetime
    Proposed paragraph (d) addresses physical protection as applied to
cryptographic equipment. Compliance does not necessitate locking
devices within mechanical safes or enclosing their electronics within
thick steel or concrete shields (i.e. making them tamper-proof).
Compliance does, however, involve using sound design practices to
construct a system capable of attack detection by a comprehensive range
of sensors (i.e. tamper resistant). The level of physical security
suggested should be such that unauthorized attempts at access or use
will either be unsuccessful or will have a high probability of being
detected during or after the event. Additionally, the cryptographic
equipment should be prominently situated in operation so that its
condition (outward appearance, indicators, controls, etc.) is easily
visible to minimize the possibility of undetected penetration. In any
system containing detection and destruction methods as described here,
there is naturally a cost penalty for providing very high levels of
tamper resistance, due to construction and test requirements by the
manufacturer. It is naturally important to analyze the risks of key
disclosure against cost of protection and specify a suitable
implementation.
    Confidentiality has been defined by the International Organization
for Standardization (ISO) as ``ensuring that information is accessible
only to those authorized to have access.'' Confidentiality, integrity,
and authentication all rely on the same basic cryptographic
primitives--algorithms with basic cryptographic properties--and their
relationship to other cryptographic problems. These primitives provide
fundamental properties, which guarantee one or more of the high-level
security properties. In proposed paragraph (e)(1), FRA makes it clear
that while providing for confidentiality of message data is not a
regulatory requirement, if confidentiality is elected to be implemented
by a railroad, that the same protection mechanisms applicable to the
cryptographic primitives that support integrity and authentication must
also be provided for the cryptographic primitives that support
confidentiality.
    It is only the difficulty of obtaining the key that determines
security of the system, provided that there is no analytic attack
(i.e., a ``structural weakness'' in the algorithms or protocols used),
and assuming that the key is not otherwise available (such as via
theft, extortion, or compromise of computer systems). A key should
therefore be large enough that a brute force attack (possible against
any encryption algorithm) is infeasible, whereas the attack would take
too long to execute. Under information theory, to achieve perfect
secrecy, it is necessary for the key length to be at least as large as
the message to be transmitted and only used once (this algorithm is
called the one-time pad). In light of this, and the practical
difficulty of managing such long keys, modern cryptographic practice
has discarded the notion of perfect secrecy as a requirement for
encryption, and instead focuses on computational security. Under this
definition, the computational requirements of breaking an encrypted
text must be infeasible for an attacker. Paragraph (e)(2) proposes to
require that in the event that a railroad elects to implement
confidentiality, the chosen key length should provide the appropriate
level of computational complexity to protect the information being
protected, and that this information be included in the PTCSP. Both
academic and private organizations provide recommendations and
mathematical formulas to approximate the minimum key size requirement
for security based on mathematic attacks; they generally do not take
algorithmic attacks, hardware flaws, or other such issues into account.
    Key management--the process of handling and controlling
cryptographic keys and associated material during their life cycle in a
cryptographic system--includes ordering, generating, distributing,
storing, loading, escrowing, archiving, auditing, and destroying the
different types of material. Paragraph (e) proposes to require that
cleartext stored cryptographic keys be protected from unauthorized
disclosure, modification, or substitution. During key management,
however, it may be necessary to validate the accuracy of the key being
entered, especially in cases where the key management process is being
done manually. During the key

entry process, keys not encrypted to protect against disclosures may be
temporarily displayed to allow visual verification. However, if the key
has been encrypted to protect against disclosure, then the cleartext
version of the key may not be displayed. This does not, however,
preclude the display of the encrypted version of the key.
    In proposed paragraph (f), FRA requires that each railroad
implement a service restoration and mitigation plan to address restoral
of communications services in the event of their loss or disruption and
to make this plan available to FRA. Loss of communications services
reduces or eliminates the effectiveness of a PTC system and FRA
requires that these critical safety systems, once implemented, are
restored to operation as soon as practical. FRA believes that the
restoration plan must include testing and validating the plan,
communicating the plan, and validating backup and restoration
operations.
    To ensure that these or any other procedures work in the railroads
operational environment, the railroad must validate each procedure
intended for implementation. The backup and restoration plan should
clearly describe who is to implement procedures and how they are to do
it. The primary information to be communicated includes: the team or
person (specified as an individual or a role) that is responsible for
determining when restoration of service is required and the procedures