failure at a particular point on its trajectory. The effective casualty
area for each piece of debris is a modeling construct in which the area
within which 100 percent of the population are assumed to be a
casualty, and outside of which 100 percent of the population are
assumed not to be a casualty.
    In proposed Sec.  450.135(e)(8), an applicant would be required to
submit sample collective and individual outputs under representative
conditions and the worst foreseeable conditions, including the total
collective casualty expectation for the proposed operation; a list of
the collective risk contribution for at least the top ten population
centers and all centers with collective risk exceeding 1 percent of the
collective risk criterion in proposed Sec.  450.101; a list of the
maximum individual PC for the top ten population centers and
all centers that exceed 10 percent of the individual risk criterion in
proposed Sec.  450.101. The applicant would also be required to submit
a list of the probability of loss of functionality of any critical
asset that exceeds 1 percent of the critical asset criterion in
proposed Sec.  450.101. Proposed Sec.  450.135(e)(9) would require an
operator to submit a list of the conditional collective casualty
expectation for each vehicle response mode for each one-second interval
of flight under representative conditions and the worst foreseeable
conditions. Finally, in all FSAs, the applicant must also submit
additional products that allow an independent analysis, if requested by
the FAA, in order to assure that the public risk criteria are
satisfied.
13. Far-field Overpressure Blast Effects
    The FAA proposes to consolidate its regulations on far-field
overpressure blast effects analyses in proposed Sec.  450.137 (Far-
Field Overpressure Blast Effect Analysis), used to demonstrate
compliance with the public safety criteria in proposed Sec.  450.101.
This analysis looks at the potential public hazard from broken windows
as a result of impacting explosive debris, including impact of an
intact launch vehicle.
    The near-field effects of explosions are covered under debris risk
analysis, where meteorological conditions do not significantly
influence the attenuation of overpressure. However, the FAA would
require a far-field blast effect analysis for peak incident
overpressures below 1 pound per square inch (psi,) the point where
meteorological conditions can significantly influence the attenuation
of explosive overpressures. A launch and reentry operator would be
required to conduct a far-field overpressure blast effects analysis
(also known as distance focusing overpressure, or DFO) that
demonstrates compliance with public safety criteria in proposed Sec.
450.101. An operator would need to complete the analysis either prior
to the day of the operation accounting for all foreseeable conditions
within the flight commit criteria or during the countdown using the
best available input data. An applicant would be required to describe
the critical input data, such as the meteorological measurements, and
develop flight commit criteria to include any hazard controls derived
from this FSA in accordance with proposed Sec.  450.165(b)(6).
    Impacting explosive materials, both liquid and solid, have the
potential to explode. Given the appropriate combination of atmospheric
pressure and temperature gradients, the impact explosion can produce
distant focus overpressure at significant distance from the original
blast point. Overpressures from as low as 0.1 psi may cause windows to
break. However, other forms of overpressure, such as multiple pulses,
may also prove hazardous depending on the size and thickness of windows
and the number of windowpanes. Moreover, levels of overpressure will
change depending on distance, atmospherics, and a vehicle's explosive
yield.
    Multiple historical events involving large explosions, including
rocket failures, have shown that under unfavorable atmospheric
conditions, a shock wave may focus to produce significant peak
overpressures at communities beyond the boundaries of the launch site,
potentially causing window breakage and injuries. In light of the
historical evidence of blast damage due to overpressure focusing, and
building on the legacy of U.S. agency efforts to protect against the
potential public risks associated with rocket explosions, the FAA
adopted regulations to protect the public from the DFO phenomena in
Sec.  417.229 (Far-field overpressure blast effect analysis) and
appendix A to part 417 (section A417.29.) In Sec.  417.229, the FAA
requires an FSA to establish flight commit criteria that protect the
public from any hazard associated with DFO effects and demonstrate
compliance with the public risk criterion. Section 417.229(b) currently
lists appropriate constraints on the analysis and section A417.29
provides an acceptable means of compliance. Section A417.29 includes
hazard controls based on ANSI S2.20-183 Standard,\205\ as well as a
standard and a measure of fidelity used to assess any proposed
alternative analytic approach. Section A417.29 also lists the products
of a valid DFO analysis.
---------------------------------------------------------------------------

    \205\ ANSI S2.20-1983, Estimating Air Blast Characteristics for
Single Point Explosions in Air, with a Guide to Evaluation of
Atmospheric Propagation and Effects, Acoustical Society of America,
New York (1983).
---------------------------------------------------------------------------

    However, current regulations lack clarity on when a day-of-launch
DFO analysis is necessary. Specifically, section A417.29(c) requires
that an operator conduct a risk analysis that accounts for ``current
meteorological conditions,'' unless the operator complies with the
prescriptive requirements in Sec.  417.229(b) that include the
extremely conservative method prescribed by the ANSI S2.20-183
Standard. These requirements have led to situations where an operator
was technically required to perform a day-of-launch risk analysis to
protect against the DFO hazard, when in fact the public risks due to
the DFO phenomena were insignificant based on every weather condition
measured over a period of many years.
    Part 431 does not explicitly address the potential public hazard
posed by

DFO. However, since 2016, Sec.  431.35(b)(1)(i) has required an
applicant to demonstrate that the total collective risk does not exceed
1 x 10-\4\ EC, where the total risk consists of
risk posed by impacting inert and explosive debris, toxic release, and
far-field blast overpressure. Because the RLVs licensed to date under
part 431 have relatively low potential explosive yields (compared to
large ELVs), some part 431 license applicants were able to perform
hazard analyses based on the extremely conservative method prescribed
by the ANSI S2.20-183 Standard to demonstrate that the public risks due
to the DFO phenomena were insignificant.
    The FAA proposes to streamline and clarify its regulations on DFO
analyses. Whereas part 417 regulations and relevant appendices contain
prescriptive methodology requirements in Appendix A, the proposal would
distill these sections into performance requirements applicable to both
launch and reentry flight operations.
    Proposed Sec.  450.137(a) would provide applicants an option to
perform a DFO risk analysis that demonstrates compliance with public
safety criteria in proposed Sec.  450.101, either prior to the day of
the operation, by accounting for all foreseeable conditions within the
flight commit criteria, or during the countdown using the best
available input data. If an operator could satisfy Sec.  450.137(a)(1),
then it would not be required to satisfy Sec.  450.137(a)(2). There are
at least two different screening analyses that would demonstrate
compliance with Sec.  450.137(a)(1). Method one would be a very simple
deterministic window breakage screening analysis. Method two would be a
simplified risk-based screening analysis. If either screening analysis
indicates no potential hazards or insignificant risks, with or without
mitigations, then an operator would not be required to comply with
Sec.  450.137(a)(2). Conversely, an operator would be required to
satisfy proposed Sec.  450.137(a)(2) if it could not demonstrate
compliance with Sec.  450.137(a)(1). Thus, the proposal would provide
clarity regarding how to determine if a day-of-operations risk analysis
is necessary, and flexibility to establish flight commit criteria to
limit the contribution of DFO public risks based on analysis done prior
to the day of the operation. This clarity and flexibility were lacking
in both parts 417 and 431.
    Proposed Sec.  450.137(b) would set required performance outcomes
and the specific factors that a DFO FSA must consider. Substantively,
Sec.  450.137(b) would contain the same requirements as those currently
in Sec.  417.229(b). Note that the level of fidelity of the DFO
analysis would be subject to the requirements in proposed Sec.
450.101(g), so that the analysis methods used must produce results
consistent with, or more conservative than, the results available from
valid benchmarks.
    Proposed Sec.  450.137(c) would clarify the materials an operator
must submit with its license application, which are generally
consistent with those currently required to comply with part 417. This
paragraph would clarify the level of fidelity required for the products
of a DFO analysis by specifying the key input data and critical model
elements that an application would be required to describe. The
proposal would require an application to include: (1) A description of
the population centers, terrain, building types, and window
characteristics used as input to the far-field overpressure analysis;
(2) a description of the methods used to compute the foreseeable
explosive yield probability pairs, and the complete set of yield-
probability pairs, used as input to the far-field overpressure
analysis; (3) a description of the methods used to compute peak
incident overpressures as a function of distance from the explosion and
prevailing meteorological conditions, including sample calculations for
a representative range of the foreseeable meteorological conditions,
yields, and population center locations; (4) a description of the
methods used to compute the probability of window breakage, including
tabular data and graphs for the probability of breakage as a function
of the peak incident overpressure for a representative range of window
types, building types, and yields accounted for; (5) a description of
the methods used to compute the PC for a representative
individual, including tabular data and graphs for the PC, as
a function of location relative to the window and the peak incident
overpressure for a representative range of window types, building
types, and yields accounted for; (6) tabular data and graphs showing
the hypothetical location of any member of the public that could be
exposed to a PC of 1 x 10-\5\ or greater for
neighboring operations personnel, and 1 x 10-\6\ or greater
for other members of the public, given foreseeable meteorological
conditions, yields, and population exposures; (7) the maximum expected
casualties that could result from far-field overpressure hazards
greater given foreseeable meteorological conditions, yields, and
population exposures; and (8) a description of the meteorological
measurements used as input to any real-time far-field overpressure
analysis. It would also require the submission of any additional
products that allow an independent analysis, as requested by the
Administrator.
14. Toxic Hazards for Flight
    The FAA proposes to replace current Sec.  417.227 and appendix I to
part 417 with the following two performance-based regulations: Sec.
450.139 for toxic hazard analyses for flight operations and Sec.
450.187 for toxic hazards mitigation for ground operations.
    Currently, the requirements for a toxic release hazard analysis are
specified in Sec.  417.227. Section 417.277 requires that an FSA
establish flight commit criteria that protect the public from any
hazard associated with toxic release and demonstrate compliance with
the public risk criteria of Sec.  417.107(b). This analysis must
account for any toxic release that will occur during the proposed
flight of a launch vehicle or that would occur in the event of a flight
mishap, and for all members of the public that may be exposed to toxic
release. Additionally, Sec.  417.405 sets forth the requirements for a
ground safety analysis, and, although toxic release is not explicitly
enumerated, a launch operator must identify each potential hazard
including the sudden release of a hazardous material. Appendix I to
part 417 provides methodologies for performing toxic release hazard
analysis for the flight of a launch vehicle and for launch processing
at a launch site in the U.S. as required by Sec.  417.407(f).
    Similarly, Sec.  431.35 requires that for a reusable launch vehicle
mission, an applicant must demonstrate that the proposed mission does
not exceed the acceptable risk defined in Sec.  417.107(b)(1) that
includes the risk associated with toxic release. Further, Sec.
431.35(c) requires that an applicant employ a system safety process to
identify the hazards and assess the risks to public health and safety
of property associated with the mission. Although parts 431 and 435
have the same risk criteria for toxic release as are contained in part
417, unlike part 417, they have no explicit requirements for
establishing toxic thresholds. Instead, toxic hazards are addressed as
part of the systems safety process. The lack of definitive requirements
in parts 431 and 435 has created a lack of clarity as to the
requirements for toxic release hazard analysis during the system safety
process.
    The current toxic hazard requirements have a number of
shortcomings. The

requirements of Sec.  417.227 are not sufficiently definitive for an
operator to establish the toxic concentration and exposure duration
threshold for a toxic propellant, to evaluate toxic hazards for flight
or for ground operations, to determine a toxic hazard area in the event
of a release during flight or from a ground operations mishap, or to
require toxic containment or evacuation of the public from a toxic
hazard area.
    Conversely, the existing appendix I to part 417 is overly
prescriptive in defining permissible values for assumptions and data
inputs to analyses but, as discussed later, lacks important items. In
many instances, appendix I requires specific methods, formulas,
acceptable sources, specific conditions, and assumptions. However,
often these are not the only ways in which the requirements or required
demonstrations can be made.
    There are numerous examples of the prescriptive nature of appendix
I to part 417. For example, section I417.3(c)(1) identifies only three
agencies of the U.S. Government, namely, the Environmental Protection
Agency, the Federal Emergency Management Agency, and the Department of
Transportation, that the launch operator is permitted to use as sources
of toxicant levels of concern (LOC). There are no common standards in
toxicological dose-response data. The data bases of concentration
thresholds are different from agency to agency. Specific toxic
chemicals that are released may not be included in some or many lists,
and some databases account for exposure durations where others do not.
Additionally, some databases account for differences in the age and
vulnerability of populations exposed, while others do not. Furthermore,
some databases account for differences in the severity of physiological
responses to exposure, when others do not. Therefore, excluding
available dose-response databases limits the capability of the operator
to select the most appropriate LOC. Other U.S Government agencies that
have established airborne toxic concentration thresholds of exposure,
including the National Research Council (NRC), the U.S. Occupational
Safety and Health Administration (OSHA), the National Institute for
Occupational Safety and Health (NIOSH), the National Oceanic and
Atmospheric Administration (NOAA), the American Conference of
Government Industrial Hygienists (ACGIH), the U.S. Department of
Defense, the National Institutes of Health (NIH), the U.S. National
Institute of Medicine, and the U.S. National Library of Medicine.
    Other prescriptive examples in Appendix I include section
I417.3(c)(3) which requires the launch operator to use only one
formulation to determine the toxic concentration threshold for mixtures
of two or more toxicants, and section I417.5(c)(2), which prescribes a
set of single-valued worst-case conditions that a launch operator must
apply in an analysis of toxic hazard conditions for uncommon or unique
propellants. Other sections of the appendix mandate specific
assumptions.\206\
---------------------------------------------------------------------------

    \206\ For example, section I417.7(e)(2), the worst-case release
scenario for toxic liquids, requires an assumption that liquid
spreads to one centimeter deep, and that the volatilization rate
must account for the highest daily maximum temperature occurring the
past 3 years precluding more severe or more realistic worst-case
conditions, such as assuming the liquid spreads to a lesser depth,
exposing a greater surface area for evaporation. This may not be
conservative enough to provide acceptable public safety in some
cases.
---------------------------------------------------------------------------

    In addition to being overly prescriptive, Appendix I also contains
inaccuracies and out of date information. For example, section
I417.7(b) (Process hazards analysis) provides that an analysis that
complies with 29 CFR 1910.119(e) satisfies section I417.7(b)(1) and
(2). However, the specific requirements of 29 CFR 1910.119(e) are not
completely congruent with the specific requirements of section
I417.7(b)(1) and (2). In particular, the following requirements of
section I417.7(b)(2) do not have counterparts in Sec.  1910.119(e):
location of the source of the release; each opportunity for equipment
malfunction or human error that can cause an accidental release; and
each safeguard used or needed to control each hazard or prevent
equipment malfunctions or human error. Thus, if an operator chooses to
satisfy Sec.  1910.119(e), important parts of section I417.7(b)(2) may
not be addressed, such as the location of the source of the release
which is needed to determine the toxic hazard area necessary to achieve
toxic containment.
    The tables in appendix I are also problematic and in many cases
omit important information. For example, Table I417-1, Commonly Used
Non-Toxic Propellants, contains only three propellants, designated as
commonly used non-toxic propellants. However, this list leaves other
non-toxic liquid propellants such as liquid methane or liquefied
natural gas without an explicit exemption from performing a toxic
release hazard analysis.
    The FAA proposes to consolidate the requirements for toxic release
analysis for the launch of an ELV currently contained in parts 415 and
417, the launch and reentry of an RLV in part 431, and the launch of a
reentry vehicle other than a reusable launch vehicle in part 435.
Specifically, the FAA proposes to replace current Sec.  417.227 and
appendix I to part 417, with two performance-based regulations--
proposed Sec. Sec.  450.139 and 450.187. The proposed requirements
would apply to all launches and reentries, and would provide more
definitive application requirements for the toxic release hazard
analysis.
    Both proposed Sec. Sec.  450.139 and 450.187 would apply to launch
and reentry vehicles, including all components and payloads that have
toxic propellants or other toxic chemicals, making it explicitly clear
that reentry operations require a toxic hazard release analysis where
the requirement was not previously explicit in parts 431 and 435. The
FAA decided to split the toxic release analysis regulations into two
sections, one for flight and the other for ground operations, because
ground operations and flight operations have different criteria
available to establish an acceptable level of public safety.
Specifically, the FAA proposes to apply a quantitative public risk
acceptability criteria for flight consistent with the risk criteria in
Sec.  450.101 and to apply a qualitative hazard acceptability criterion
for ground hazards that is consistent with the standard in Sec.
450.109(a)(3).\207\
---------------------------------------------------------------------------

    \207\ Section 450.109(a)(3) would require that the risk
associated with each hazard meets the following criteria: (i) The
likelihood of any hazardous condition that may cause death or
serious injury to the public must be extremely remote and (ii) the
likelihood of any hazardous condition that may cause major damage to
public property or critical assets must be remote.
---------------------------------------------------------------------------

    Proposed Sec.  450.139(b)(1) would require an operator to conduct a
toxic release hazard analysis. Additionally, under paragraph (b)(2) an
operator would be required to manage the risk of casualties that could
arise from exposure to toxic release either through containing hazards
in accordance with proposed Sec.  450.139(d) or performing a toxic risk
assessment under proposed paragraph (e) that protects the public in
compliance with proposed Sec.  450.101, including toxic release.
Furthermore, under proposed Sec.  450.139(b)(3) an operator would be
required to establish flight commit criteria based on the results of
its toxic release hazard analysis, containment analysis, or toxic risk
assessment for any necessary evacuation of the public from any toxic
hazard area.
    Section 450.139(c) would contain the requirements for a toxic
release hazard analysis, which are currently lacking in

Sec.  417.227. Specifically, under proposed Sec.  450.139(c) the toxic
release hazard analysis would require an operator to account for any
toxic releases that could occur during nominal or non-nominal launch or
reentry for flight operation. Furthermore, an operator's toxic release
hazard analysis would be required to include a worst-case release
scenario analysis or a maximum-credible release scenario analysis for
each process that involves a toxic propellant or other chemical;
determine if toxic release can occur based on an evaluation of the
chemical compositions and quantities of propellants, other chemicals,
vehicle materials, and projected combustion products, and the possible
toxic release scenarios; account for both normal combustion products
and any unreacted propellants and phase change or molecular derivatives
of released chemicals; and account for any operational constraints and
emergency procedures that provide protection from toxic release. While
the proposed Sec.  450.139(c) would contain more definitive
requirements than current regulations, it would also provide the
operator more flexibility in the analysis because unlike the current
regulations it would not require an operator to make specific
assumptions when performing a worst-case release scenario analysis to
determine worst-case released quantities of toxic propellants, toxic
liquids, or toxic gases from ground operations.
    Proposed Sec.  450.139(b)(2) would require an operator to manage
the risk of casualties arising from toxic release either by containing
the hazards in accordance with paragraph (d) or by performing a toxic
risk assessment in accordance with paragraph (e) that protects the
public in compliance with the risk criteria of Sec.  450.101. If an
operator chose toxic containment to comply with proposed Sec.
450.139(b)(2), the operator would be required to manage the risk of
casualties by either (1) evacuating, or being prepared to evacuate, the
public from a toxic hazard area, where an average member of the public
would be exposed to greater than one percent conditional individual
PC in the case of worst-case release or maximum credible
release scenario, or (2) by employing meteorological constraints to
limit a launch operation to times when the prevailing winds would
transport a toxic release away from populated areas otherwise at risk.
The conditional individual PC would be computed assuming
that (1) a maximum credible release event occurs, and (2) average
members of the public are present along the boundary of the toxic
hazard area.
    If an operator chose to comply with proposed Sec.  450.139(b)(2) by
conducting a toxic risk assessment that protects the public in
compliance with proposed Sec.  450.101, in accordance with Sec.
450.139(e), the toxic risk assessment would require the operator to
account for airborne concentration and duration thresholds of toxic
propellants or other chemicals. For any toxic propellant, other
chemicals, or combustion product, an operator would be required to use
airborne toxic concentration and duration thresholds identified in a
means of compliance accepted by the Administrator. Currently, the
thresholds set by the Acute Exposure Guideline Level 2 (AEGL-2), the
Emergency Response Planning Guidelines Level 2 (ERPG-2), or the Short-
term Public Emergency Guidance Level (SPEGL) \208\ would be accepted
means of compliance for proposed Sec.  450.139(e)(1) (and Sec.
450.187(d)(1)). These are thresholds designed to anticipate casualty-
causing health effects from exposure to certain airborne chemical
concentrations. The FAA anticipates, as discussed earlier, that
additional agencies' threshold values could satisfy the requirements
and would identify any additional accepted thresholds. By requiring an
operator to use airborne toxic concentration thresholds identified in a
means of compliance accepted by the Administrator under proposed Sec.
450.35, the FAA anticipates that operators would be provided with some
flexibility to utilize toxic concentration thresholds identified by
agencies other than the three currently identified in appendix I to
part 417 thereby enhancing the capability of the operator to select the
most appropriate LOC for its operation.
---------------------------------------------------------------------------

    \208\ AEGLs are used by EPA, the American Industrial Hygiene
Association's ERPGs are used by NOAA, and the National Research
Council's SPEGL is used by the DOD.
---------------------------------------------------------------------------

    An operator also would be required under Sec.  450.139(e)(2) to
account for physical phenomena (such as meteorological conditions and
characterization of the terrain) expected to influence any toxic
concentration and duration in the area surrounding the potential
release site instead of prescribing a set of single-valued wind speed
and atmospheric stability classes and dictating how an operator must
derive the variance of the mean wind directions. Hence, under proposed
Sec.  450.139(e)(2) the toxic assessment would likely be more
appropriate for the actual situation. Proposed Sec.  450.139(e)(3)
would require an operator to determine a toxic hazard area for the
launch or reentry, surrounding the potential release site for each
toxic propellant or other chemical based on the amount and toxicity of
the propellant or other chemical, the exposure duration, and the
meteorological conditions involved. Finally, under proposed Sec.
450.139(e)(4) and (5) the toxic assessment would be required to account
for all members of the public that may be exposed to the toxic release,
including all members of the public on land and on any waterborne
vessels, populated offshore structures, and aircraft that are not
operated in direct support of the launch or reentry, and for any risk
mitigation measures applied in the risk assessment.
    In many respects, proposed Sec. Sec.  450.139 and 450.187 are
nearly identical, and the rationale behind the revisions proposed in
Sec.  450.139 would be the same for proposed Sec.  450.187. As
discussed previously, proposed Sec.  450.187 would apply to any launch
or reentry vehicle, including all vehicle components and payloads, that
uses toxic propellants or other toxic chemicals. Like Sec.  450.139,
Sec.  450.187(b) would require a toxic hazard analysis.
    Under the proposed rule an operator would be required to manage
risk from a toxic release hazard or demonstrate compliance with
proposed Sec.  450.109(a)(3) \209\ with a toxic risk assessment. The
requirements for a toxic risk assessment under proposed Sec.
450.187(e) are substantially similar to those of proposed Sec.
450.139, except that ground operations use a qualitative acceptability
criteria and flight operations can use quantitative risk criteria. FAA
has not proposed quantitative criteria for ground operations because
there are no commonly accepted criteria.
---------------------------------------------------------------------------

    \209\ As discussed earlier, Sec.  450.109(a)(3) would require
that the risk associated with each hazard meets the following
criteria: (i) The likelihood of any hazardous condition that may
cause death or serious injury to the public must be extremely remote
and (ii) the likelihood of any hazardous condition that may cause
major damage to public property or critical assets must be remote.
---------------------------------------------------------------------------

    The proposed application requirements under Sec.  450.139(f) toxic
hazards for flight and under Sec.  450.187(e) for ground operations
would be similar. The FAA believes that the proposed approach will
provide applicants with a clear understanding of what the FAA requires
in order to avoid repeated requests for clarifications and additional
information. Both would require the applicant to submit: (1) The
identity of the toxic propellant, chemical, or toxic combustion
products or derivatives in the possible toxic release; (2) its selected
airborne toxic concentration and duration thresholds; (3)
meteorological conditions for the atmospheric

transport, and buoyant cloud rise of any toxic release from its source
to downwind receptor locations; (4) characterization of the terrain;
(5) the identity of the toxic dispersion model used, and any other
input data; (6) representative results of toxic dispersion modeling to
predict concentrations and durations at selected downwind receptor
locations; (7) a description of the failure modes and associated
relative probabilities for potential toxic release scenarios used in
the risk evaluation; (8) the methodology and representative results of
the worst-case or maximum-credible quantity of any toxic release; (9) a
demonstration that the public will not be exposed to airborne
concentrations above the toxic concentration and duration thresholds;
(10) the population density in receptor locations that are identified
by toxic dispersion modeling as toxic hazard areas; and (11) a
description of any risk mitigations applied in the toxic risk
assessment; and (12) the identity of the population database used. Like
other risk analyses, the FAA may request additional products that allow
the FAA to conduct an independent analysis.
15. Wind Weighting for the Flight of an Unguided Suborbital Launch
Vehicle
    The FAA proposes to consolidate three current part 417 provisions
expressly regulating unguided suborbital launch vehicle operations into
Sec.  450.141. The proposed rule would retain the performance
requirements and remove the prescriptive provisions in Sec. Sec.
417.125 and 417.233. The FAA also proposes to incorporate the
overarching safety performance requirements in appendix C to part 417
related to wind weighting analysis products. This proposal applies
specifically to the flight of unguided suborbital launch vehicles using
wind weighting to meet the public safety criteria of proposed Sec.
450.101.
    An unguided suborbital launch vehicle is a suborbital rocket that
does not contain active guidance or a directional control system.
Unlike the launch of a guided launch vehicle, an unguided suborbital
launch vehicle may safely fly by adjusting the launcher azimuth and
elevation (aiming the rocket) shortly before launch to correct for the
effects of wind conditions at the time of flight. This process limits
impact locations to those that minimize public exposure. The FAA refers
to this safety process as ``wind weighting,'' which involves unique
organizational and operational safety requirements.
    Section 417.125 provides the broad requirements for launching an
unguided suborbital launch vehicle. Specifically, it lays out
provisions for a flight safety system, a wind weighting safety system,
public risk criteria, stability, tracking, and post launch review.
Section 417.125(b) requires an applicant to use an FSS if the vehicle
can reach a populated area and the applicant does not use an effective
wind weighting system. Section 417.125(c) sets requirements for a wind
weighting system if that system is used in place of an FSS. It provides
that the vehicle must not contain a guidance or directional control
system. It also requires the launcher azimuth and elevation setting to
be wind weighted to correct for the effects of wind conditions at the
time of flight in compliance with Sec.  417.233's FSA requirements, and
requires specific nominal launcher elevation angle for proven (85[deg],
and 86[deg] with wind correction) and unproven (80[deg], and 84[deg]
with wind correction) unguided suborbital launch vehicles. These
prescriptive launch elevation angles are used so that the vehicle does
not fly uprange. In other words, the rocket should not be angled so
vertically that winds could force the rocket uprange instead of the
intended downrange direction. Section 417.125(d) expressly requires
unguided suborbital launch vehicles to fly in accordance with the
public risk criteria required for all launch vehicles under part 417.
    In addition, the current rule has stability, tracking, and post-
launch review requirements that are specific to unguided suborbital
launch vehicles. Section Sec.  417.125(e) requires specific stability
requirements measured in calibers to ensure that the unguided
suborbital launch vehicle is stable throughout flight. The tracking
requirements in Sec.  417.125(f) require that a launch operator track
impact locations after launch to verify that the preflight wind
weighting analysis was accurate. Section 417.125(g) is related to post-
launch review and states that the launch operator must provide these
impact locations, a comparison of actual to predicted nominal
performance, and investigation results of any launch anomaly.
    Current Sec.  417.233 describes the FSA requirements particular to
unguided suborbital launch vehicles with wind weighting systems. The
analyses must establish flight commit criteria, wind constraints under
which launch may occur, and launcher azimuth and elevation settings
that correct for wind effects on the launch vehicle. This last
requirement is known as the wind weighting analysis.
    Appendix C to part 417 contains flight safety methodologies and
products for an unguided suborbital launch vehicle flown with a wind
weighting safety system. These includes methodologies and products for
a trajectory analysis, a wind weighting analysis, a debris analysis, a
risk analysis, and a collision avoidance analysis. Section C417.3
requires the launch operator perform a six-degrees-of-freedom
trajectory simulation in order to determine a nominal trajectory,
impact point, and potential three-sigma dispersions about the nominal
impact point. Section C417.5 is related to wind weighting and describes
the methodology an applicant must use to measure winds and incorporate
them into the trajectory simulation in order to determine launch
elevation angle and azimuth settings. The debris (section C417.7) and
risk (section C417.9) analyses describe methodologies and analysis
products applicable to all launch vehicles for calculating
EC. The parts of appendix C that are covered elsewhere in
the proposed rule because they are applicable to all vehicles have not
been transferred to proposed Sec.  450.141. This includes the debris,
risk, and collision avoidance analyses.
    Proposed Sec.  450.141 would consolidate the requirements of
Sec. Sec.  417.125 and 417.233 and appendix C, but would not carry over
the detailed methodological and prescriptive requirements. Proposed
Sec.  450.141(a) would explain that the section applies to the flight
of an unguided suborbital launch vehicle using a wind weighting safety
system to meet the public safety criteria of proposed Sec.  450.101.
The FAA proposes to define a wind weighting safety system as equipment,
procedures, analysis, and personnel functions used to determine the
launcher elevation and azimuth setting that correct for wind effects
that an unguided suborbital launch vehicle will experience during
flight. The FAA proposes the wind weighting safety system be a means to
satisfy the safety requirements in proposed Sec.  450.101.
    Proposed Sec.  450.141(b) would set the requirements for the wind
weighting safety system. It would require that the launcher azimuth and
elevation angle settings (1) be wind weighted to correct for the
effects of wind conditions at the time of flight to provide a safe
impact location, and (2) ensure the rocket will not fly in an
unintended direction given wind uncertainties. This section would
replace current Sec.  417.125(b), which requires a flight safety system
unless the vehicle uses wind weighting or does not have sufficient
energy to reach a populated area. Rather than the blanket FSS
requirement in current Sec.  417.125(b), the consequence analysis in
proposed Sec.  450.135(d) would determine the need

for an FSS. This section also eliminates the requirement in Sec.
417.125(c)(3) regarding specific nominal launcher elevation angle for
proven (85[deg] and 86[deg] with wind correction) and unproven (80[deg]
and 84[deg] with wind correction) vehicles to prevent the vehicle from
flying uprange. Rather than requiring specific launcher elevation
angles to prevent a vehicle from flying uprange, the FAA would require
an operator to determine what angles would ensure the rocket not fly in
unintended direction given wind uncertainties. This flexibility would
allow a licensee to determine the best angle to both maximize mission
objectives given the particularities of their operation while
simultaneously ensuring safety.
    Proposed Sec.  450.141(c) would contain FSA performance
requirements that apply only to the launch of an unguided suborbital
launch vehicle flown with a wind weighting safety system. It is
necessary to establish the flight commit criteria and other flight
safety rules to control risk to the public and satisfies the public
safety criteria in proposed Sec.  450.101. Proposed Sec.  450.141(c)
would require an operator to establish any wind constraints under which
launch could occur, and conduct a wind weighting analysis that
establishes the launcher azimuth and elevation settings. Proposed Sec.
450.141(c) is, in essence, the same as Sec.  417.233.
    Proposed Sec.  450.141(d) would require an unguided suborbital
launch vehicle to remain stable in all configurations throughout each
stage of powered flight. This performance outcome would eliminate the
need for the specific prescriptive stability requirements of current
Sec.  417.125(e), which requires a suborbital launch vehicle be stable
in flexible body to 1.5 calibers and rigid body to 2.0 calibers
throughout each stage of powered flight.
    Finally, proposed Sec.  450.141(e) would establish the agency's
application requirements specific to unguided suborbital launch
vehicles. The FAA would require a description of wind weighting
analysis methods, description of wind weighting system and equipment,
and a sample wind weighting analysis, all derived from part 417,
appendix C, section C417.5(d). The remainder of appendix C was not
included in the proposal because these are all prescriptive
methodologies, or are requirements applying to all launch vehicles
covered in other sections of the proposal. For instance, the Trajectory
Analysis of section C417.3 would be covered by proposed Sec. Sec.
450.117 and 450.119. Except for section C417.5(d) as described earlier,
section C417.5 was not included in the proposal since this is a
prescriptive methodology. The methodologies for debris analysis from
section C417.7 are not in the proposal and the debris analysis proposal
would now be in proposed Sec.  450.121. Similarly, section C417.9 would
be covered by proposed Sec.  450.135 without the prescribed
methodologies. Lastly, the collision avoidance section of the appendix,
section C417.11 would be covered by proposed Sec.  450.169.

B. Software

    As discussed earlier, the FAA proposes software safety requirements
in Sec.  450.111. The risk mitigation measures that result from this
rule are meant to be minimums, and software development processes tend
to benefit from consistency across projects, so an applicant may apply
the requirements from its most critical software to all of its
software, but the FAA does not require that an applicant do so.
    Software can contribute to accidents or losses in several ways.
Software may contain errors that, in certain system conditions, cause
unintended behaviors or prevent intended behaviors. Software may also
perform actions that while correct and intended in isolation, cause
hazards when interacting with other components or the system as a
whole. Software may provide accurate information to an operator in a
manner that confuses the operator, leading to a software-human
interaction error. Software safety therefore typically requires
separate analyses of the software, software and computing system
interaction, and the integration of software, hardware, and humans into
the entire system.
    Software becomes safety-critical when the applicant uses its
outputs in safety decisions. The development, validation, and
evaluation of safety-critical software requires a level of rigor
commensurate with the severity of the potential hazards and the
software's degree of control over those hazards. Reliance on software
differs among operators. For example, some launch systems employ
Autonomous Flight Safety Systems (AFSS) that rely on rigorously-
developed and thoroughly-tested software to make safety decisions to
protect the public without human intervention. Other systems require
human intervention to make safety decisions, such as when a pilot or
ground transmitter operator must make decisions for launch systems.
    Current FAA licensing regulations segregate software safety
requirements by type of vehicle (ELV, RLV, or reentry vehicle) in three
separate sections.\210\ Current software safety regulations in parts
415, 417, and 431 are flexible. With this flexibility comes
uncertainty. For example, Sec.  415.123(b) requires that a launch
operator provide all plans for software development, the results of
software hazard analyses, and plans and results of software validation
and verification, but does not give guidance on the minimum-acceptable
levels of rigor for those products or guidance on their contents. The
FAA and the operator must determine the appropriate level of rigor,
scope, and content of each plan and result for each operation. This
process can be labor-intensive, requiring multiple meetings over a
period of weeks or months.
---------------------------------------------------------------------------

    \210\ Part 415 covers launch license application procedures for
ELVs; part 417 addresses launch safety requirements for ELVs, and
part 431 sets launch license and safety requirements for RLVs.
---------------------------------------------------------------------------

    Also, Sec.  417.123(c), applicable to ELVs, requires that a launch
operator conduct computing system and software hazard analyses for the
integrated system. This requirement does not specify the requisite
forms of the analyses, the scope and contents of the analyses, or the
application data required to demonstrate compliance with the
requirement. The FAA and the applicant must negotiate the specifics for
each of those items for every application. Similarly, Sec.  417.123(d)
requires that a launch operator develop and implement computing system
and software validation and verification plans, but is silent regarding
the contents of the plans. This again requires that the FAA and the
applicant discuss, often at length, the software test plans for every
operation.
    Unlike Sec. Sec.  415.123 and 417.123, Sec.  431.35 does not
contain any explicit references to software safety. However, in
practice, the FAA has set software safety requirements under the
current system safety process requirements in Sec.  431.35(c). Pursuant
to Sec.  431.35(c), the FAA has required applicants satisfy Sec.
417.123 or demonstrate an equivalent level of safety, in order to meet
Sec.  431.35 for software safety. This lack of detail forces the FAA
and applicant to work collaboratively to develop the system safety
process criteria on a case-by-case basis.
    Operators have offered consistent feedback on the FAA's software
safety requirements. Applicants frequently asked whether Sec. Sec.
417.123(b) and 431.35(c)'s verification and validation plan requirement
included a requirement for independent verification and validation.
Independent verification and validation is a common

and effective method of mitigating software hazards for high-
criticality software, one for which there is no known substitute. Thus,
although not explicitly stated in the regulations, the FAA has required
independent verification and validation as part of the verification and
validation requirements in Sec. Sec.  417.123(b) and 431.35(c). The FAA
considers software testers independent when the test organization is
independent of the development organization up to the senior-executive
level. Generally, an in-house software testing team can be sufficiently
independent to perform a credible independent verification and
validation function when rigorously insulated from software development
authorities and incentives. Still more independence may be required for
highly safety-critical autonomous software, such as an independent
contractor, depending on the risks and the other mitigation measures
implemented by the applicant. The FAA has required at least
independence up to the senior-management level and expected an
applicant to show evidence of this independence in its application.
    Applicants have also often asked whether the FAA requires
submissions of software code. The FAA has not historically required
executable code submissions and does not plan to do so in this
proposal. Instead, the FAA's requirements focus on the software
development and testing processes, combined with analysis of the
software's use in the context of the system as a whole. Firstly, the
FAA seeks to understand the software development processes used for the
design, production, verification, and qualification of software to
determine the code quality. Proposed Sec.  450.111(a), (b), and (c)
would provide these general software process requirements that are
independent of the degree of control exercised by a given software
component. Secondly, the FAA must understand the impacts of the
software on the system as a whole. It is important to understand design
risks, which are those risks inherent to the software design and
architecture; and also process risks, which arise from the software
development processes and standards of the applicant. The FAA uses
these two components, process and implementation, to evaluate software
components and processes for the appropriate level of rigor.
    The FAA must also understand the relationship between software
actions and system risks to set the appropriate level of rigor.
Establishing the required level of rigor and understanding its
implementation form the basis of software safety determinations.
Configuration management, including version control, then ensures the
operator uses the intended processes and functionality for the correct
software in the system's operation.
    Applicants have often sought help in determining whether software
is safety-critical in accordance with Sec. Sec.  417.123(b) and
415.123(a). For instance, operators sometimes use software to generate
information used in safety-critical decisions, such as initiating a
deorbit burn. The FAA has consistently found software that generates
information used in safety-critical decisions to be safety-critical
software, albeit with a low degree of control over the system.
    Applicants have also asked whether the FAA requires redundant
processing such as running a second instance of a software component on
a second independent computer, and if so, the required level of risk.
The FAA has made such determinations based on the hazards involved and
on the software's degree of control over those hazards. The FAA has
chosen not to prescribe a requirement for redundant processing because
such a requirement is best derived from the applicant's individual
approach to hazard mitigation at the system level. Redundant copies of
identical software contain identical software faults, so redundant
processing is best described as a mitigation for hardware failures. The
proposal would allow for software without redundant processing whenever
processing redundancy is not necessary to achieve acceptable risk. For
example, the FAA may not require redundant processing in fail-safe
systems, low-criticality systems, or where hardware ensures software
processing integrity by using hardware features such as watchdog timers
or error-correcting memory.
    In light of the range of design strategies between commercial space
operators, the FAA realized that a one-size-fits-all approach to
software safety would not be practical. Instead, in proposed Sec.
450.111(d) through (g) the FAA would establish requirements for each
safety category of software. The safety categories, commonly known in
the software safety industry as ``levels of rigor'' or ``software
criticality indexes,'' would range from autonomous software with
catastrophic hazards to software with no safety impact.
    Applicants may rely upon Federal launch range standards to show
compliance with the proposed rule, provided the standards meet the
regulations. The FAA maintains awareness of the Federal launch range
safety standards through the CSWG. The FAA currently incorporates the
known and coordinated standards maintained by the Federal launch ranges
into FAA licensing in order to avoid duplication of effort. The Federal
launch ranges have an extensive launch safety history, and their
standards meet or exceed the level of safety required by the FAA. The
FAA intends to retain the ability to apply Federal launch range safety
standards toward license evaluation and issuance.
    In developing this proposed rule, the FAA has tried to remain
consistent with prevalent industry standards related to the ``level of
rigor'' approach to software safety. Specifically, the FAA has used the
level of rigor approaches applied by the Department of Defense and NASA
to inform the FAA's proposed level of rigor approach to software safety
regulation.
    The FAA proposes to use the Department of Defense's MIL-STD-882E
concept of ``level of rigor'' to categorize software according to the
amount of risk it presents to the operation and use its ``level of
rigor tasks'' to derive appropriate regulatory requirements for each
level of rigor. MIL-STD-882E uses a software hazard severity category
with a software control category to assign level of rigor tasks to
software. This method has proven successful in achieving an acceptable
level of safety for space operations.
    The FAA also used RCC 319, Flight Termination Systems Commonality
Standard, to develop the requirements for autonomous software in
proposed Sec.  450.111(d). RCC 319-14 provides detailed software
requirements for autonomous flight safety systems, which have been
extensively reviewed by the space community. RCC 319-14 creates
software categories that combine hazard severity and degree of control
in a single step, and provides deep detail on the appropriate risk
reduction tasks for each category. AFSPCMAN 91-712 (draft) is the
source of RCC 319-14's software categories and risk reduction tasks.
    The FAA also reviewed NASA's Software Safety Standard (NASA-STD-
8719.13C), which provides standards applicable to defining the
requirements for implementing a systematic approach to software safety.
Like RCC 319-14, NASA-STD-8719.13C combines software hazard's severity
with the software's degree of control to assign analysis and testing
tasks. However, NASA expands its software control category definitions
to include software autonomy, software complexity, time-criticality,
and degree of hazard control. The FAA also considered NASA's Software
Assurance Standard (NASA-STD-8739.8), which provides criticality, risk,
resource investment, and financial impact categorizations and
correlates

these to levels of software assurance effort. These two NASA documents
provided the FAA with a wealth of potential software safety
requirements and methods to determine the requirements that would be
most appropriate for a variety of space systems. These documents also
provided a checklist of key aspects of software projects that enable
software safety. The FAA has drawn from these documents the minimum set
of requirements that would enable space operators to protect the
public, and the minimum set of data that would enable the FAA to verify
that space operators will protect the public in the course of their
innovations.
    Finally, the FAA reviewed the Air Force Space Command's draft 91-
712, Launch Safety Software and Computing System Requirements. The Air
Force has successfully used 91-712 for military space projects and it
is the source of many RCC 319-14 requirements. 91-712, and the
standards discussed earlier, all prescribe increasing the effort
devoted to software safety in proportion to the severity of the hazards
that software can create and in proportion to the degree of control
that software exercises over those hazards.
    The proposed software safety regulations would categorize software
and computing functions into the following degrees of control as
defined in proposed Sec.  450.111(d) through (g): Autonomous software,
semi-autonomous software, redundant fault-tolerant software,
influential software, and no safety impact.
    This proposal for software safety would address the causes of
software faults and software failures. Software faults are design flaws
in software that cause unintended behaviors or prevent intended
behaviors. Software faults include errors in syntax, definitions,
steps, or processes that can cause a program to produce an unintended
or unanticipated result. The presence of software faults might not
always result in an observable software failure that is evident to the
user because it may appear to be behaving properly. A software failure,
in contrast, is an unintended or undesirable event caused by, or
unintentionally allowed by, one or more software faults. A software
fault is a defect or vulnerability in software while a software failure
results from the execution of faulty software.\211\
---------------------------------------------------------------------------

    \211\ An example of a software failure is the ``blue screen of
death,'' which causes a computer to end all processing. An example
of software fault is a fault in requirements for measurement units
and a fault in test procedures. The Mars Climate Orbiter was lost as
a result of these two faults when one function was written in
English units while the rest were written in metric.
---------------------------------------------------------------------------

    This proposal would address faults in software requirements by
analytical means in proposed Sec.  450.111. Specifically, the proposal
would require an applicant to describe the functions and features,
including interfaces, of the software. The FAA has interpreted the need
to describe software to include providing the software requirements for
each safety-critical software component even though not explicitly
required by Sec.  431.35 or Sec.  417.123. The proposal therefore
codifies current practice.
    Software requirements are an excellent, even indispensable, means
of understanding any software component's safety implications. Software
requirements, both documented and implied, are the basis of the
software design and constitute a key part of Sec.  417.123(a) through
(e) requirement for software designs. The FAA proposes to clarify the
necessity and scope of software requirements that would be required to
be included in an application in proposed Sec.  450.111(h). Software
requirements would need to be documented and analyzed whenever safety-
critical software is present.\212\ Software requirements are frequently
inherited from system requirements, and both must be internally and
mutually consistent and valid for the resulting software to work
safely. A system-level hazard analysis finds out what hazards software
presents to the system. The software analyses can use the system-level
analyses as initial assessments of software's criticality when starting
software safety analyses. If software requirements are flawed, the
software written to those software requirements will be flawed as well.
This causal path, where software faults originate in software
requirements, is the reason for the proposal's focus on identification,
documentation, validation, and verification of software requirements.
---------------------------------------------------------------------------

    \212\ Implied or undocumented software requirements are common
sources of software faults.
---------------------------------------------------------------------------

    This proposal addresses faults in implementation by requiring
specific types of software verification and validation testing in
proposed Sec.  450.111(d)(4), (e)(4), (f)(3), and (g)(2). This proposal
would clarify the required types of software verification and
validation testing that are required under current Sec. Sec.
417.123(d) and 415.123(b)(8).\213\ Verification and validation are
standard aspects of a software development cycle and are used together
to determine that software meets its intended purpose. In this context,
verification refers to ensuring software meets the software
requirements and design specifications. Validation ensures that the
software achieves its intended purpose.\214\ While testing does not
ensure the absence of software faults, it helps detect and therefore
reduce their presence.
---------------------------------------------------------------------------

    \213\ Examples of testing include unit testing to verify some of
the smallest units of code, such as functions, and acceptance
testing to validate high-level software requirements.
    \214\ Verification takes place while the software is under
development while validation is performed after completing software
development and implementation.
---------------------------------------------------------------------------

    The proposal would address faults in configuration with explicit
requirements to establish and verify software configuration management
processes. Configuration management is the set of processes that ensure
that the flight components, including software components, are the
correct components with the appropriate development and test heritage.
Faults in configuration management can lead to unsuitable or
incompatible components in a system, resulting in an increased
potential for unintended and unsafe system actions.
    Proposed Sec.  450.111(a) would require operators to document a
process that identifies the risks to the public health and safety and
the safety of property arising from computing systems and software.
This is consistent with the Sec.  417.123(a) requirement for a
description of the computing system and software system safety process.
It adds no more requirements than part 415 because Sec.  415.123(b)(6)
requires an applicant to describe the computing system and software
system safety process as required by Sec.  417.123(a). Unlike Sec.
431.35(c), proposed Sec.  450.111(a) specifically mentions computing
systems and software as items to be included in the system safety
process.
    Proposed Sec.  450.111(b) would require an operator to identify all
safety-critical functions associated with its computing systems and
software. The 10 listed functions are a minimum set of items to include
whenever they are present in a system, because they represent the most
common safety-critical roles in which software can be employed. For
example, software used to control or monitor safety-critical systems is
capable of hazardous actions by definition. Similarly, software that
accesses safety-critical data is safety-critical because it may alter
safety-critical data or prevent other components from accessing safety-
critical data at required times. The software safety process must then
demonstrate that the software that accesses safety-critical data cannot

cause a hazard by doing so. These requirements are the same as in the
current Sec.  417.123(b), with the addition of one new criterion for
software that displays safety-critical information. Proposed Sec.
450.111 would retain the requirement of Sec.  417.123(b) for the
identification of safety-critical functions. The proposal would add
detail and clarity to this requirement, specifying that the identified
functions must be accompanied by assessments of the criticality of each
software function. This is normally done by assessing the consequences
of a functional failure or error and assessing the degree of control
that the software can exercise to implement the function. The proposal
would retain the examples of software that may have safety-critical
functions, with the expectation that the full list of safety-critical
functions is not limited to the examples. It differs from Sec.
415.123(b), which describes the documents and materials that the
applicant must provide, whereas proposed Sec.  450.111(b) would list
the safety-critical computing system and software functions that must
be identified and would not list the application requirements in the
same section. The proposal would depart from Sec.  431.35(d)(3) by
specifically requiring the applicant to identify all safety-critical
functions associated with its computing systems and software instead of
implicitly requiring the identification of safety-critical software as
part of the process of identifying safety-critical systems.
    Proposed Sec.  450.111(c) would require the identification of
safety-critical software functions by consequence and degree of
control. It would elaborate on the requirements of Sec. Sec.
415.123(a) and 417.123(a), which require the identification and
assessment of the software risks to public safety by specifying that
the assessments must include the public safety consequences of each
safety-critical software function and the degree of control that
software exercises over the performance of that function. Proposed
Sec.  450.111(c) would provide the classification for the applicants to
use while the application requirements are contained in proposed Sec.
450.111(h). Requiring software degree of control would allow the FAA to
request less information for software components with reduced or no
influence on public safety. The proposal would differ from Sec.  431.35
by explicitly requiring identification of software hazards by function
and specifying the documentation requirements related to computing
systems and software in proposed Sec.  450.111(h). Even though this
language is different from Sec.  431.35, this is not a new requirement.
    The requirements in the proposal vary based on the software degree
of control and degree of hazard presented. The first and highest degree
of control is autonomous software. Autonomous software would mean
software that exercises autonomous control over safety-critical
systems, subsystems, or components such that a control entity cannot
detect or intervene to prevent a hazard that may impact public health
and safety or the safety of property. It is any software that can act
without an opportunity for meaningful human intervention. The FAA would
impose the most stringent requirements for autonomous software with
potential catastrophic public safety consequences. Proposed Sec.
450.111(d) would set forth five criteria specific to autonomous
software.
    Under proposed Sec.  450.111(d)(1), the software component would be
required to undergo full path coverage testing and any inaccessible
code must be documented and addressed. Full path coverage testing is a
systematic technique for ensuring that all routes through the code have
been tested. Path coverage testing includes decision, statement, and
entry and exit coverage. Proposed Sec.  450.111(d)(1) would retain and
clarify the current requirements in Sec.  431.35(d). Full path coverage
testing and documentation of inaccessible code would be required for
autonomous components because the presence of inaccessible code
segments presents a potential for the execution of untested
instructions, which is obviously deleterious for an autonomous system
that, by definition, depends on the correctness of its instructions for
safe operation.
    Under proposed Sec.  450.111(d)(2), the software component's
functions would be required to be tested on flight-like hardware.
Testing would be required also to include nominal operation and fault
responses for all functions. The proposal would retain and clarify the
current requirements in Sec. Sec.  431.35(d) and 415.123(b)(8). Testing
software components on flight-like hardware, including nominal
operation and fault responses, is an industry standard for ensuring
that the software interfaces with the hardware as designed. All
autonomous safety-critical components require this testing.
    Under proposed Sec.  450.111(d)(3), an operator would be required
to conduct hazard analyses of computing systems and software for the
integrated system and for each autonomous, safety-critical software
component. A software hazard analysis identifies those hazards
associated with safety-critical computer system functions, assesses
their risk, identifies methods for mitigating them, and specifies
evidence of the implementation of those mitigation measures. This
requirement is currently in Sec. Sec.  415.123(b)(7), 417.123(c), and
431.35(d)(4). All software components, regardless of degree of control,
require this analysis for the integrated system. This analysis is also
required for each autonomous, safety-critical software component.
Hazard analyses provide the essential foundation for risk assessment
and management of any system. This analysis is necessary throughout the
lifecycle of the system, from development to disposal. As a system is
modified during design, operation, and maintenance, changes to any part
of the system can lead to unexpected consequences that may incur new
hazards to public safety. It is important to consider risks that result
from software and computing errors as a class or subsystem, as well as
those resulting from the operation and interaction of software with all
other components of the system.
    Proposed Sec.  450.111(d)(4) would require an operator to validate
and verify any computing systems and software. Current Sec. Sec.
415.123(b)(8) and 417.123(d) already require verification and
validation although this proposed rule would add the requirement that
testing be conducted by testers who are independent from the software
developers. Independence is essential because it enables testing of
cases and conditions that the software developers may not have
considered or may have inadvertently omitted.
    Under proposed Sec.  450.111(d)(5), an operator would be required
to develop and implement software development plans as currently
required in Sec. Sec.  415.123(b)(9) and 417.123(e)(1) through (5). A
software development plan is a means to consolidate and standardize the
management of a software development process. These plans would include
descriptions of coding standards used, configuration control,
programmable logic controllers, and policies on use of commercial-off-
the-shelf software and software reuse. It would be updated as necessary
throughout the lifecycle of the project, and may be comprised of one or
several documents.
    The configuration control of a software development project is
particularly important to ensure and facilitate an efficient and
accurate development process. Therefore, the proposal would retain the
existing, if implicit, requirements of Sec.  417.123(e)(2) to limit
faults in configuration by

requiring robust configuration management. Proper configuration
management ensures consistency and accuracy throughout a system's
design, development, operation, and maintenance. In software
engineering terms, it is a fundamental aspect of a disciplined approach
to the software lifecycle that provides a continuously current baseline
for the system. The FAA would set configuration management requirements
for all safety-critical documentation and code, including but not
limited to software requirements, hazard analysis, test plans, test
results, change requests, and development plans. Tools, processes, and
procedures for configuration management are employed throughout the
software industry.
    Proposed Sec.  450.111(e) would apply to semi-autonomous software,
with a definition nearly identical to that stated in MIL-STD-882E. The
FAA regards semi-autonomous software as software that exercises control
over safety-critical hardware systems, subsystems, or components,
allowing time for safe detection and intervention by a control entity.
The software safety requirements for semi-autonomous software are a
subset of those required for autonomous software as described in
proposed Sec.  450.111(d).
    Under proposed Sec.  450.111(e)(1), the software component's
safety-critical functions, as categorized by the process in proposed
Sec.  450.111(a), (b), and (c), would be required to be subjected to
full path coverage testing and any inaccessible code must be documented
and addressed. Proposed Sec.  450.111(e)(1) would retain and clarify
current Sec.  431.35(d) as described in proposed Sec.  450.111(d)(1).
The rationale for proposed Sec.  450.111(e)(1) and (d)(1) are
identical.
    Under proposed Sec.  450.111(e)(2), the semi-autonomous software
component's safety-critical functions would be required to be tested on
flight-like hardware, including testing of nominal operation and fault
responses for all safety-critical functions. Proposed Sec.
450.111(e)(2) would also retain and clarify the current requirements in
Sec.  431.35(d) as described in proposed Sec.  450.111(d)(2).
    Under proposed Sec.  450.111(e)(3), an operator would be required
to conduct computing system and software hazard analyses for the
integrated system. The proposal would retain the requirement of
conducting computing system and software hazard analyses that exists in
current Sec. Sec.  415.123(b)(7), 417.123(c), and 431.35(d)(4). All
software components, regardless of level of control, would require this
analysis for the integrated system. The rationale for proposed Sec.
450.111(e)(3) and (d)(3) are identical.
    Under proposed Sec.  450.111(e)(4), an operator would need to
verify and validate any computing systems and software related to semi-
autonomous software as described earlier, with the associated
rationale, for autonomous software relative to proposed Sec.
450.111(d)(4). This verification and validation would be required to
include testing by a test team independent of the software development
division or organization. This would retain the requirement for
verification and validation of computing systems and software,
including testing by an independent test team, as currently required in
Sec. Sec.  415.123(b)(8) and 417.123(d).
    Under proposed Sec.  450.111(e)(5), an operator would be required
to develop and implement software development plans as currently
required in Sec. Sec.  415.123(b)(9) and 417.123(e)(1) through (5). The
rationale for proposed Sec.  450.111(e)(5) and (d)(5) are identical.
    Proposed Sec.  450.111(f) would apply to redundant fault-tolerant
software, which is defined as software that exercises control over
safety-critical hardware systems, subsystems, or components, for which
a non-software component must also fail in order to impact public
health and safety or the safety of property.\215\ There are redundant
sources of safety-significant information, and mitigating functionality
can respond within any time-critical period. The proposal would include
four criteria for redundant fault-tolerant software.
---------------------------------------------------------------------------

    \215\ MIL-STD-882E elaborates that the definition of redundant
fault-tolerant assumes that there is adequate fault detection,
annunciation, tolerance, and system recovery to prevent the hazard
occurrence if software fails, malfunctions, or degrades.
---------------------------------------------------------------------------

    Proposed Sec.  450.111(f)(1) is consistent with the second criteria
for autonomous and semi-autonomous software in proposed Sec.
450.111(d)(2) and (e)(2), in that the software component's safety-
critical functions would be required to be tested on flight-like
hardware, including testing of nominal operation and fault responses
for all safety-critical functions. The proposal would retain and
clarify the current requirements in Sec.  431.35(d).
    Proposed Sec.  450.111(f)(2) would repeat the third criteria for
autonomous and semi-autonomous software as described in proposed Sec.
450.111(d)(3) and (e)(3). It would require that an operator conduct
computing system and software hazard analyses for the integrated
system. The proposal would retain the requirement of conducting
computing system and software hazard analyses that exists in the
current Sec. Sec.  415.123(b)(7), 417.123(c), and 431.35(d)(4). All
software components, regardless of level of control, would require this
analysis for the integrated system. The rationale for this part is the
same as that for proposed Sec.  450.111(d)(3).
    Under proposed Sec.  450.111(f)(3), an operator would be required
to verify and validate any computing systems and software related to
redundant fault-tolerant software as described earlier, with associated
rationale, for autonomous software related to proposed Sec.
450.111(d)(4) and semi-autonomous software in proposed Sec.
450.111(e)(4). This verification and validation would be required to
include testing by a test team independent of the software development
division or organization. This would retain the requirement for
verification and validation of computing systems and software,
including testing by an independent test team, as currently required
under Sec. Sec.  415.123(b)(8) and 417.123(d).
    Under proposed Sec.  450.111(f)(4), an operator would be required
to develop and implement software development plans as currently
required under Sec. Sec.  415.123(b)(9) and 417.123(e)(1) through (5).
The same rationale applies here as for proposed Sec.  450.111(d)(5) and
(e)(5).
    Proposed Sec.  450.111(g) would apply to software that provides
information to a person who uses the information to take actions or
make decisions that can impact public health and safety or the safety
of property, but does not require operator action to avoid a mishap.
Influential software provides information that is used in safety-
critical decisions, but cannot cause a hazard on its own. The proposal
would include three criteria for influential software.
    Proposed Sec.  450.111(g)(1) would require an operator to conduct
computing system and software hazard analyses for the integrated
system. The proposed rule would retain the requirement of conducting
computing system and software hazard analyses that exists in the
current Sec. Sec.  415.123(b)(7), 417.123(c), and 431.35(d)(4). All
software components, regardless of level of control, would require this
analysis for the integrated system. The rationale for this proposed
section is the same as that for proposed Sec.  450.111(d)(3).
    Proposed Sec.  450.111(g)(2) would require an operator to verify
and validate any computing systems and software related to influential
software. This verification and validation would be required to include
testing by a test

team independent of the software development division or organization.
This would retain the requirement for verification and validation of
computing systems and software, including testing by an independent
test team, as currently required under Sec. Sec.  415.123(b)(8) and
417.123(d). The rationale for this proposed section is the same as that
for proposed Sec.  450.111(d)(4).
    Proposed Sec.  450.111(g)(3) would require an operator to develop
and implement software development plans as required in existing
Sec. Sec.  415.123(b)(9) and 417.123(e)(1) through (5). The same
rationale applies here as for proposed Sec.  450.111(d)(5), (e)(5), and
(f)(4).
    Proposed Sec.  450.111(h) would retain the application requirements
of Sec. Sec.  415.123 and 417.123, but would vary in the required
amount of detail according to the level of control of the software. The
amount of application materials would depend on the software
component's risk to safety. The proposal would differ from Sec.  431.35
by expressly requiring documentation related to computing systems and
software. This requirement was implicit in Sec.  431.35 and the FAA has
requested these documents in practice. The FAA would require
descriptions of software components with no safety impact but would not
impose process requirements. This information would be required to
supplement the vehicle description requirements contained elsewhere in
this proposal. It would also lead to a shared understanding of the
systems and components that do not have known safety significance
allowing the FAA only cursorily to review those systems during the
license application evaluation without undue concern over undocumented
systems, functions, or features.

C. Changes to Parts 401, 413, 414, 420, 437, 440

1. Part 401--Definitions
    The FAA proposes to modify definitions in parts 401, 414, 417, 420,
437, and 440. This would include adding new definitions to or modifying
current definitions in Sec.  401.5 (Definitions) to align with the new
proposed regulations. The FAA also proposes to clarify and move some of
the definitions that are currently in part 417 to proposed part 450.
Also, the proposal would not retain some of the definitions currently
in part 417. Finally, the FAA proposes to remove various current
definitions from Sec. Sec.  401.5 and 420.5.
    The FAA proposes to add new definitions to Sec.  401.5. These
definitions would be necessary additions to accompany the proposed part
450 requirements, especially in the area of flight safety analysis.
Proposed Sec. Sec.  450.113 through 450.139 would require the addition
of ``Casualty Area,'' ``Critical Asset,'' ``Deorbit,'' ``Dose-Response
Relationship,'' ``Disposal,'' ``Effective Casualty Area,'' ``Expected
Casualty,'' ``Flight Abort,'' ``Flight Abort Rules,'' ``Flight Hazard
Area,'' ``Liftoff,'' ``Limits of a Useful Mission,'' ``Orbital
Insertion,'' and ``Probability of Casualty.'' Most important within
that group are ``Critical Asset,'' which is driven by proposed
protection criteria for assets that are essential to the national
interests of the United States, and ``Disposal,'' which is driven by
proposed upper stage disposal risk criteria. The other terms and
associated definitions that would be added to support proposed
Sec. Sec.  450.113 through 450.139 are referenced in the proposed FSA
requirements.
    The proposed system safety regulations would require the addition
of the following terms and associated definitions: ``Hazard Control''
and ``Launch or Reentry System.'' Proposed Sec.  450.101(a)(1) and
(b)(1) would require a definition for ``Neighboring Operations
Personnel''; proposed Sec.  450.107(b) would require a clear definition
of ``Physical Containment''; proposed Sec.  450.111 would require a
definition for ``Control Entity'' and ``Software Function''; proposed
Sec. Sec.  450.139 and 450.187 would require a definition for ``Toxic
Hazard Area.'' Proposed Sec.  450.101(c) would require the addition of
``Vehicle Response Mode.'' The collision avoidance requirements in
proposed Sec.  450.169 would require the addition of ``Reentry Window''
and ``Window Closure'' to Sec.  401.5, while the unguided suborbital
requirements in proposed Sec.  450.141 would require the addition of
``Unguided Suborbital Launch Vehicle'' and ``Wind Weighting Safety
System.''
    These new definitions are discussed in detail in corresponding
sections of this preamble, including the proposed meaning and usage.
    Current Sec.  401.5 definitions that would be modified by this rule
are as follows: ``Contingency Abort,'' which would be simplified;
``Flight Safety System,'' which would be simplified to incorporate the
new term ``Flight Abort;'' and ``Instantaneous Impact Point,'' which
would remove drag effects and clarify that this term means a predicted
impact point. ``Mishap'' would be defined as having four classes or
categories, from most to least severe, based on lessons learned as
discussed earlier in this preamble. The current definition of ``Public
Safety'' would be removed from Sec.  401.5 and the definition of
``Public'' would be removed from Sec.  420.5, and a new definition for
``Public'' would be added to Sec.  401.5. ``Launch'' and ``Reenter;
Reentry'' would be modified to remove language that further scopes what
aspects of space transportation are licensed, as discussed earlier.
Scoping language would be transferred to proposed Sec.  450.3. ``Safety
Critical'' would be modified to remove the last sentence because it is
unnecessary. The definition for ``State and United States'' would fix a
minor printing error.
    Section 417.3 contains the definitions for part 417, only some of
which would be preserved and added to Sec.  401.5 by this proposed
rulemaking. These are ``Command Control System,'' ``Countdown,''
``Crossrange,'' ``Data Loss Flight Time,'' ``Downrange,'' ``Explosive
Debris,'' ``Flight Abort Crew,'' ``Flight Safety Limit,'' ``Gate,''
``Launch Window,'' ``Normal Flight,'' ``Normal Trajectory,''
``Operating Environment,'' ``Operation Hazard,'' ``Service Life,''
``System Hazard,'' ``Sub-Vehicle Point,'' ``Tracking Icon,'' and
``Uprange.'' A number of changes have been made as follows:
     ``Command Control System'' would be modified to take out
unnecessary detail.
     ``Countdown,'' ``Downrange,'' ``Explosive Debris,'' and
``Normal Flight'' would be modified to add reentry.
     ``Crossrange,'' ``Launch Window,'' ``Normal Trajectory,''
``Service Life,'' and ``System Hazard'' would be unchanged.
     The term ``Flight Abort Crew'' would be changed from
``Flight Safety Crew,'' and would be simplified.
     ``Operating Environment'' would be changed to add reentry,
and would use the term ``lifecycle'' within the definition instead of
the limiting reference to acceptance testing, launch countdown, and
flight.
     ``Operation Hazard'' would be modified to clarify that a
system hazard is not an operation hazard.
     The term ``Protected Area'' would be removed, and the term
``Uncontrolled Area'' would be added to Sec.  401.5 but with the
inclusion of a launch or reentry site operator, an adjacent site
operator, or other entity by agreement who can control an area of land.
     The term ``Service life'' would be changed to replace
reference to a flight termination system component with any safety-
critical system component.
     The last sentence in ``Sub-Vehicle Point'' and ``Uprange''
would be

removed because these sentences are unnecessary.
     ``Tracking Icon'' would be modified to include autonomous
flight safety systems.
     ``Data Loss Flight Time,'' ``Flight Safety Limit,'' and
``Gate'' would be changed as discussed earlier in this preamble.
    In part 414, ``Safety Approval'' would be changed to ``Safety
Element Approval,'' so that a part 414 approval is not confused with a
proposed part 450 safety approval. Its meaning, however, would remain
the same as discussed earlier in this preamble.
    The definition of ``Maximum Probable Loss (MPL)'' in Sec.  440.3
would be modified to include Neighboring Operations Personnel.
    The definition of ``Anomaly'' would be removed from part 437 and
added to Sec.  401.5 with a revised meaning.
    Definitions that would not be retained from part 417 are ``Command
Destruct Systems,'' ``Conjunction on Launch,'' ``Destruct,'' ``Drag
Impact Point,'' ``Dwell Time,'' ``Fail-Over,'' ``Family Performance
Data,'' ``Flight Safety System,'' ``Flight Termination System,''
``Inadvertent Separation Destruct System,'' ``In-Family,'' ``Launch
Azimuth,'' ``Launch Crew,'' ``Launch Wait,'' ``Meets Intent
Certification,'' ``Non-Operating Environment,'' ``Operating Life,''
``Out-of-Family,'' ``Passive Component,'' ``Performance
Specifications,'' ``Safe-Critical Computer System Function,'' ``Storage
Life,'' and ``Waiver.'' These would no longer be a part of commercial
space regulations because they have been replaced with different terms
(i.e., ``Conjunction on Launch'' and ``Launch Wait''), are already
defined in Sec.  401.5 (i.e., ``Flight Safety System''), or are simply
not used (all others).
    This proposed rule would also remove from Sec.  401.5, ``Human
Space Flight Incident,'' ``Launch Accident,'' ``Launch Incident,''
``Reentry Accident,'' and ``Reentry Incident.'' In addition, it would
remove ``Launch Site Accident'' from Sec.  420.5. These definitions
would be removed because of the proposed changes in definitions related
to mishaps. The proposed rule would also remove from Sec.  401.5
``Emergency Abort,'' because it is no longer in use, and ``Vehicle
Safety Operations Personnel,'' because those personnel are referred to
as ``Safety Critical Personnel'' in proposed part 450.
    The FAA also proposes to remove the definition of ``Instantaneous
Impact Point'' from Sec.  420.5. This definition would be removed
because a new definition with a modified meaning would be added to
Sec.  401.5.
2. Part 413--Application Procedures
i. Sec.  413.1 Clarification of the Term ``Application''
    The FAA proposes to modify Sec.  413.1 to clarify the term
``application.'' Specifically, the FAA would add to Sec.  413.1 that
the term application means either an application in its entirety, or a
portion of an application for incremental review and determination in
accordance with Sec.  450.33. This change is necessary to enable
incremental review as discussed earlier.
ii. Sec.  413.21 Denial of a License or Permit Application
    The FAA proposes to correct the section heading of Sec.  413.21 to
reflect the content of the section, and also correct paragraph (c) of
this section to reference both license and permit applications.
    Section 413.21 applies to a license or permit application. However,
the section heading and paragraph (c) of this section only reference
``license.'' To correct this oversight, the FAA proposes to revise the
section heading to read, ``Denial of a license or permit application.''
In addition, the FAA proposes to remove the reference to ``license''
from paragraph (c) so that it would apply to both license and permit
applications.
iii. ``Complete Enough'' and ``Sufficiently Complete''
    The FAA proposes to change the term ``sufficiently complete'' in
part 414 to ``complete enough,'' as used in Sec.  413.11, because the
two terms mean the same thing. That is, they both describe the point at
which the FAA has determined it has sufficient information to accept an
application and begin its evaluation to make findings regarding issuing
a license or permit.
    Section 413.11 uses ``complete enough'' to describe when the FAA
will accept an application and begin its review for a launch license or
permit. The original intent was to use the same term in other chapter
III sections. However, the term ``sufficiently complete'' in Sec. Sec.
414.15(a), 415.107(a), and 417.203(c) was never changed to ``complete
enough.''
    Therefore, the agency proposes to change the term ``sufficiently
complete'' to ``complete enough'' for consistency and clarity. The
proposed change would be made in part 414 and in proposed part 450,
since parts 415 and 417 would be consolidated under this new part.
iv. Electronic Submission
    This rule proposes to amend Sec.  413.7(a)(3) to allow an applicant
the option to submit its application by email as a link to a secure
server, and remove the requirement that an application be in a format
that cannot be altered.
    In 2015, the FAA published the ``Electronic Applications for
Licenses, Permits, and Safety Approvals'' rule.\216\ In that rule, the
FAA made the application process more flexible and efficient by
providing an applicant with the option to submit applications to the
FAA electronically, either via email or on an electronic storage
device, rather than submitting a paper application. Specifically, Sec.
413.7(a)(3) requires that an application made via email be submitted as
an email attachment to [email protected] in a format that cannot
be altered. The FAA's intent was to allow applicants to transact with
the agency electronically, in accordance with the Government Paperwork
Elimination Act. However, since the rule published, the FAA has found
that many of the files containing the necessary application materials
are too large to be transmitted successfully by email. When this
occurs, applicants have transmitted an email message with a File
Transfer Program (FTP) link or a link to a digital repository where the
materials can be downloaded by the FAA. The FAA has found this to be an
acceptable means of submitting an application. Because the FAA proposes
to amend application procedures in this rulemaking, the FAA also
proposes to align the regulations with the current acceptable practice
of allowing this form of electronic application submission.
Accordingly, the FAA proposes to amend Sec.  413.7(a)(3) to allow an
applicant the option to submit its application by email as a link to a
secure server.
---------------------------------------------------------------------------

    \216\ Electronic Applications for Licenses, Permits, and Safety
Approvals, Direct Final Rule. 80 FR 30147 (May 27, 2015).
---------------------------------------------------------------------------

    Additionally, the 2015 rulemaking identified that in requiring a
file format that could not be altered, the FAA would accept a PDF
document or a read-only Word file. Because both of these file types can
actually be modified, the FAA has found it is impossible to comply with
the requirement in Sec.  413.7(a)(3)(ii). However, the need for
document and version control of applications still exists for accurate
record keeping and to ensure that the application materials the FAA
evaluates and enforces represent the final and accurate submission from
the applicant and have not been altered in any way. As nearly every
form of electronic file submitted could be altered in some way or
another, the FAA proposes to replace the current Sec.  413.7(a)(3)(ii)
with a new

requirement that an applicant's email submission would be required to
identify each document appended to the email, including any that are
included as an attachment or that are stored on a secure server. The
FAA further proposes to include a new Sec.  413.7(a)(3)(iii) which
would require all electronic files be date stamped and include version
control documentation. The replacement of Sec.  413.7(a)(3)(ii) and the
addition of Sec.  413.7(a)(3)(iii) would further the FAA's intent to
prevent any unrecognized alteration.
    The proposed amendments to Sec.  414.13(a)(3) would mirror the
proposed text of Sec.  413.7(a)(3). The FAA also proposes to remove
Sec.  414.11(a)(3) because those requirements would be addressed in the
proposed text of Sec.  414.13(a)(3). These changes would remove
unactionable application requirements and replace them with regulations
that align with current practice and practicable compliance.
    The FAA also proposes to change the heading of part 413 from
``License Application Procedures'' to ``Application Procedures.'' The
proposed heading change reflects the multiple application procedures
under part 413, which includes launch and reentry licenses, launch and
reentry site licenses, and experimental permits. The FAA proposes this
title change to improve the regulatory clarity for future experimental
permit applicants.
3. Part 414--Safety Element Approvals
    As discussed earlier, the FAA proposes to change the part 414 term
from ``safety approval'' to ``safety element approval'' to distinguish
it from ``safety approval'' as used in parts 415, 431, and 435, and
proposed part 450. Also, the FAA proposes to modify part 414 to enable
applicants to request a safety element approval in conjunction with a
license application as provided in proposed part 450.\217\
---------------------------------------------------------------------------

    \217\ Discussion on safety element approval changes to part 414
can be found in the Process Improvements section A portion of this
preamble.
---------------------------------------------------------------------------

4. Part 420--License To Operate a Launch Site
    As discussed earlier, the proposal would modify the environmental
requirements in Sec.  420.15 to match the environmental requirements in
proposed Sec.  450.47. Also, the proposal would remove the definitions
of ``instantaneous impact point,'' ``launch site accident,'' and
``public'' from Sec.  420.5, and allow alternate time frames in Sec.
420.57. In addition, it would change the heading of Sec.  420.59 from
``Launch Site Accident Investigation Plan'' to ``Mishap Plan,'' and
modify the section as discussed earlier. Further, it would make a minor
edit in Sec.  420.51.
5. Part 433--License To Operate a Reentry Site
    As discussed earlier, the proposal would modify the environmental
requirements in Sec. Sec.  433.7 and 433.9 to align them with the
environmental requirements in proposed Sec.  450.47.
6. Part 437--Experimental Permits
    As discussed earlier, the FAA proposes to modify part 437
(Experimental Permits) in six ways. First, the proposal would remove
the definition of ``anomaly'' from Sec.  437.3 and include a modified
version in Sec.  401.5. Second, the proposal would modify the
environmental requirements in Sec.  437.21(b)(1) to match the
environmental requirements proposed in Sec.  450.47. Third, it would
change the name of ``safety approval'' to ``safety element approval''
in Sec.  437.21. Fourth, it would modify the mishap plan requirements
in Sec. Sec.  437.41 and 437.75. Fifth, it would change the
requirements for collision avoidance to match proposed Sec.  450.169.
Sixth, it would allow for alternate time frames in Sec.  437.89.
7. Part 440--Financial Responsibility
    As discussed earlier, the FAA proposes to modify Sec.  440.15 to
allow for alternate time frames, and modify the definition of ``maximum
probable loss'' in Sec.  440.3 to align it with the new, proposed
definition of ``neighboring operations personnel.''

IV. Regulatory Notices and Analyses

A. Regulatory Evaluation

    Changes to Federal regulations must undergo several economic
analyses. First, Executive Order 12866 and Executive Order 13563 direct
that each federal agency shall propose or adopt a regulation only upon
a reasoned determination that the benefits of the intended regulation
justify its costs. Second, the Regulatory Flexibility Act of 1980 (Pub.
L. 96-354) requires agencies to analyze the economic impact of
regulatory changes on small entities. Third, the Trade Agreements Act
(Pub. L. 96-39 as amended) prohibits agencies from setting standards
that create unnecessary obstacles to the foreign commerce of the United
States. In developing U.S. standards, the Trade Agreements Act requires
agencies to consider international standards and, where appropriate,
that they be the basis of U.S. standards. Fourth, the Unfunded Mandates
Reform Act of 1995 (Pub. L. 104-4) requires agencies to prepare a
written assessment of the costs, benefits, and other effects of
proposed or final rules that include a Federal mandate likely to result
in the expenditure by State, local, or tribal governments, in the
aggregate, or by the private sector, of $100 million or more annually
(adjusted for inflation with base year of 1995). The FAA has provided a
more detailed Preliminary Regulatory Impact Analysis of the benefits
and costs of this proposed rule in the docket of this rulemaking. This
portion of the preamble summarizes this analysis.
    In conducting these analyses, the FAA has determined that this
proposed rule: (1) Has benefits that justify its costs, (2) is not an
economically ``significant regulatory action'' as defined in section
3(f) of Executive Order 12866, (3) is ``significant'' as defined in
DOT's Regulatory Policies and Procedures, (4) will have a significant
economic impact on a substantial number of small entities, (5) will not
create unnecessary obstacles to the foreign commerce of the United
States, and (6) will not impose an unfunded mandate on state, local, or
tribal governments, or on the private sector by exceeding the threshold
identified earlier. These analyses are summarized below.
Baseline Problem and Statement of Need
    The FAA is proposing this deregulatory action to comply with
President Donald J. Trump's Space Policy Directive-2 (SPD-2)
``Streamlining Regulations on Commercial Use of Space.'' The directive
instructed the Secretary of Transportation to publish for notice and
comment, proposed rules rescinding or revising the launch and reentry
licensing regulations. Section 2 of SPD-2 charged the Department of
Transportation with revising regulations to require a single license
for all types of commercial space flight operations and replace
prescriptive requirements with performance-based criteria. The subject
proposed rule would implement this section of SPD-2.
    The FAA's existing regulations have been criticized as overly-
prescriptive, lacking sufficient clarity, outdated, and inconsistent
with the requirements of other Government agencies. The regulations for
ELV launches in parts 415 and 417 have proven to be too prescriptive
and one-size-fits-all. The requirements of these parts were written in
a very detailed fashion, which has caused some sections to become
outdated or obsolete. In contrast, the regulations for RLV launches
have proven to be too general, lacking

regulatory clarity. For example, part 431 does not contain specificity
regarding the qualification of flight safety systems, acceptable
methods for flight safety analysis, and ground safety requirements.
    The purpose of the proposed rule is to streamline and simplify the
licensing of launch and reentry operations by relying on performance-
based regulations rather than prescriptive regulations. This action
would consolidate and revise multiple commercial space launch and
reentry regulations addressing licensing into a single regulatory part
that states safety objectives to be achieved for the launch of
suborbital and orbital expendable and reusable launch vehicles, and the
reentry of reentry vehicles. This action would also enable flexible
timeframes, remove unnecessarily burdensome ground safety regulations,
redefine when launch begins to allow specified pre-flight operations
prior to license approval, and allow applicants to seek a license to
launch from multiple sites. This proposal is necessary to reduce the
need to file and process waivers, improve clarity of the regulations,
and relieve administrative and cost burdens on industry and the FAA.
The intended effect of this action is to make commercial space
transportation regulations more efficient and effective, while
maintaining public safety.
    Since the last comprehensive update to the regulations in 2006, the
differences between ELVs and RLVs have blurred. Vehicles that utilize
traditional flight safety systems now are partially reusable. For
example, the Falcon 9 first stage, launched by Space Exploration
Technologies Corp. (SpaceX), routinely returns to the launch site or
lands on a barge and other operators are developing launch vehicles
with similar capabilities. Although the reuse of safety critical
systems or components can have public safety implications, labeling a
launch vehicle as expendable or reusable has not shown to impact the
primary approach necessary to protect public safety, certainly not to
the extent suggested in the differences between part 431 and parts 415
and 417.
    This deregulatory action would consolidate and revise multiple
commercial space regulatory parts to apply a single set of licensing
and safety regulations across several types of operations and vehicles.
It would also replace many prescriptive regulations with performance-
based regulations, giving industry greater flexibility to develop a
means of compliance that maximizes their business objectives. This
proposed rule would result in net cost savings for industry and enable
future innovation in U.S. commercial space transportation.
Affected Operators and Launches
    At the time of writing based on FAA license data, the FAA estimates
this proposed rule would affect 12 operators that have an active
license or permit to conduct launch or reentry operations. In addition,
the FAA estimates this proposed rule would affect approximately 276
launches over the next 5 years based on actual launch and reentry
numbers and forecasted numbers.\218\ The FAA anticipates that the
proposed rule would reduce the costs of current and future launch
operations by removing current prescriptive requirements that are often
burdensome to meet or require a waiver. The FAA expects these changes
would lead to more efficient launch operations and have a positive
effect on expanding the number of future launch and reentry operations.
---------------------------------------------------------------------------

    \218\ See the Preliminary Regulatory Impact Analysis of this
proposed rule in the docket for more information. The FAA Office of
Commercial Space Transportation derived the launches affected by
this proposed rule for a 5-year period of analysis due to the
rapidly changing environment of commercial space transportation.
---------------------------------------------------------------------------

Summary of Impacts
    Over a 5-year period of analysis, this proposed rule would result
in net present value cost savings to industry of about $19 million
using a 7% discount rate or about $21 million using a 3% discount rate,
with annualized net cost savings to industry of about $4.6 million
using either discount rate. This proposed rule would also result in net
present value savings for FAA of about $0.8 million using a 7% discount
rate or about $1 million using a 3% discount rate, with annualized net
cost savings to FAA of about $0.2 million using either discount rate.
    The largest quantified cost savings for industry would result from
eliminating or relaxing requirements for a flight safety system on some
launches (about $11 million in present value savings over 5 years at a
discount rate of 7% or about $12 million at a discount rate of 3%) and
from reducing the number of personnel that would have to be evacuated
from neighboring launch sites (about $8 million in present value
savings over 5 years at a discount rate of 7% or about $9 million at a
discount rate of 3%). These cost savings are described in more detail
below.
    The FAA proposes to move from prescriptive flight safety system
requirements to performance-based requirements. As a result, the
proposed rule would not require all launch vehicles to have a full
flight safety system. Launch vehicles that have a very low probability
of multiple casualties even if vehicle control fails would not be
required to have a flight safety system. In addition, vehicles that
have moderately low probability of casualty even if vehicle control
fails would not be required to have robust flight safety systems.\219\
These performance-based requirements would reduce costs for some
vehicle operators, especially for small vehicles or those operating in
remote locations.
---------------------------------------------------------------------------

    \219\ See discussion in the preamble regarding being compliant
with the flight safety systems of part 417.
---------------------------------------------------------------------------

    The proposed rule would provide a new definition of neighboring
operations personnel and establish new criteria for neighboring launch
site personnel for the purposes of risk and financial responsibility.
The change would allow affected operators to potentially reduce the
number of personnel that have to evacuate and enable more concurrent
operations by accepting a small safety risk tradeoff. The FAA has
monetized the value of this small increased safety risk as summarized
in the following tables. The FAA estimates the present value of these
small increased safety risks to be about $1.4 million discounted at 7%
or about $1.5 discounted at 3% over the five years.
    The FAA estimates some small costs to industry that would assist
both industry and the FAA in the implementation of this proposed rule,
such as providing information to the FAA that other agencies frequently
request or performing one-time updates of flight safety limit analyses
and ground hazard analyses that would be used to determine performance-
based means of compliance that provide future savings. In addition,
there may be additional costs for the modification of existing licenses
to benefit from the cost saving provisions of this proposed rule. The
FAA would also incur small costs for payload review, ground hazard
analysis, and the review of modifications to existing licenses.
    The following table summarizes total quantified savings, costs, and
net impacts.

                        Summary of Total 5-Year Quantified Savings, Costs and Net Impacts
                                       [Presented in thousands of dollars]
----------------------------------------------------------------------------------------------------------------
                                                     Industry        Industry
                     Impact                        present value   present value    FAA present     FAA present
                                                       (7%)            (3%)         value (7%)      value (3%)
----------------------------------------------------------------------------------------------------------------
Cost Savings....................................       $19,386.1       $21,844.5        $1,045.7        $1,208.9
Costs...........................................          -542.6          -569.5          -222.3          -237.0
                                                 ---------------------------------------------------------------
    Net Cost Savings............................        18,843.5        21,275.0           823.4           971.8
                                                 ---------------------------------------------------------------
        Annualized Net Cost Savings.............         4,595.7         4,645.5           200.8           212.2
----------------------------------------------------------------------------------------------------------------
Increased Safety Risks..........................        -1,370.2        -1,540.6  ..............  ..............
                                                 ---------------------------------------------------------------
    Net Cost Savings less Increased Safety Risks        17,473.3        19,734.4           823.4           971.8
                                                 ---------------------------------------------------------------
        Annualized Net Cost Savings less                 4,261.6         4,309.1           200.8           212.2
         Increased Safety Risks.................
----------------------------------------------------------------------------------------------------------------
Table notes: The sum of individual items may not equal totals due to rounding. Negative signs are used to
  indicate costs and increased safety risks in this table. Present value estimates provided at 7% and 3% per OMB
  guidance.

    The following table summarizes quantified impacts by provision
category.

                    Summary of 5-Year Quantified Savings, Costs and Net Impacts by Provisions
                                       [Presented in thousands of dollars]
----------------------------------------------------------------------------------------------------------------
                                                     Industry        Industry
            Provision category/impact              present value   present value    FAA present     FAA present
                                                       (7%)            (3%)         value (7%)      value (3%)
----------------------------------------------------------------------------------------------------------------
Waiver Avoidance:
    --Definition of Launch......................           $32.8           $36.7           $10.3           $11.5
    --Waterborne Vessel Hazard Areas............            65.6            73.3            20.5            22.9
    --Waiver for 48 Hour Readiness..............            41.0            45.8            12,8            14.3
System Safety Program--Safety Official..........            39.1            43.7            45.7            51.0
Duration of a Vehicle License...................            50.6            56.5           104.3           116.5
Readiness--Elimination of pre-launch meeting 15            709.9           799.0           127.7           143.6
 days prior.....................................
Flight Safety System--Not required for all              10,612.6        11,981.3           572.5           679.2
 launches.......................................
Flight Safety Analysis no longer required for               22.1            25.0             2.8             3.2
 hybrids........................................
Neighboring Operations *........................         7,698.9         8,656.7  ..............  ..............
Ground Hazard Analysis..........................           113.3           126.6           149.2           166.6
                                                 ---------------------------------------------------------------
    Total Cost Savings..........................        19,386.1        21,844.5         1,045.7         1,208.9
----------------------------------------------------------------------------------------------------------------
Payload Review and Determination................           -45.6           -51.2           -46.4           -52.2
Flight Safety Limit Analysis....................          -157.7          -163.8  ..............  ..............
Ground Hazard Analysis..........................           -24.0           -26.8           -27.2           -30.4
Modification Costs for Existing Licenses........          -315.4          -327.6          -148.7          -154.5
                                                 ---------------------------------------------------------------
    Total Costs.................................          -542.6          -569.5          -222.3          -237.0
                                                 ---------------------------------------------------------------
        Net Cost Savings........................        18,843.5        21,275.0           823.4           971.8
                                                 ---------------------------------------------------------------
            Annualized Net cost Savings.........         4,595.7         4,645.5           200.8           212.2
----------------------------------------------------------------------------------------------------------------
Increased Safety Risks: Neighboring Operations *        -1,370.2        -1,540.6  ..............  ..............
                                                 ---------------------------------------------------------------
    Net Cost Savings less Increased Safety Risks        17,473.3        19,734.4           823.4           971.8
                                                 ---------------------------------------------------------------
        Annualized Net Cost savings Less                 4,261.6         4,309.1           200.8           212.2
         Increased Safety Risks.................
----------------------------------------------------------------------------------------------------------------
* Changes to Neighboring Operations requirements result in net savings less increased safety risks.
Table notes: The sum of individual items may not equal totals due to rounding. Negative signs are used to
  indicate costs and increased safety risks in this table. Present value estimates provided at 3% and 7% per OMB
  guidance.

    The FAA also expects industry will gain additional unquantified
savings and benefits from the proposed rule, since it provides
flexibility and scalability through performance-based requirements that
would reduce the future cost of innovation and improve the efficiency
and productivity of U.S. commercial space transportation.
    The following table summarizes some of the proposed changes that
would result unquantified savings.

                          Unquantified Savings
------------------------------------------------------------------------
            Change                               Savings
------------------------------------------------------------------------
Time Frames...................  The proposal would revise time frames in
                                 parts 404, 413, 414, 415, 417, 420,
                                 431, 437, and 440 that may be
                                 burdensome for some operators. This
                                 would increase flexibility by allowing
                                 an operator the option to propose
                                 alternative time frames that better
                                 suit their operations. Eligible time
                                 frames include preflight and post-
                                 flight reporting among others listed in
                                 proposed Appendix A to Part 404--
                                 Alternative Time Frames.
Safety Element Approval.......  The proposal would remove the
                                 requirement in part 414 to publish in
                                 the Federal Register the criteria upon
                                 which safety element approvals were
                                 based. The purpose of this notification
                                 requirement was to make clear the
                                 criteria and standards the FAA used to
                                 assess a safety element, particularly
                                 when no clear regulatory requirement
                                 existed and there could be other
                                 potential users of the safety approval.
                                 However, the FAA has found that this
                                 requirement is unnecessary, and has
                                 potentially discouraged applications
                                 for safety element approvals due to
                                 concerns that propriety data may be
                                 disclosed. FAA anticipates that
                                 removing this requirement will lead to
                                 increased use of safety element
                                 approvals, reducing industry burden and
                                 potentially improving safety.
Mishaps.......................  The proposal would provide the following
                                 mishap-related enhancements, which FAA
                                 expects to better tailor mishap
                                 responses.
                                 Replace current part 400 mishap
                                 related definitions with a consolidated
                                 mishap classification system
                                 (streamlines and reduces confusion).
                                 Consolidate existing part 400
                                 mishap/accident investigation and
                                 emergency response plan requirements
                                 into a single part (streamlines and
                                 reduces confusion).
                                 Exempt pre-coordinated test-
                                 induced property damage from being a
                                 mishap (removes need to consider test-
                                 induced property damages from mishap
                                 requirements and likely results in
                                 fewer investigations of minor mishaps).
                                 This proposal also eliminates
                                 the small $25,000 monetary threshold
                                 from the current mishap and accident
                                 investigation requirements potentially
                                 reducing the number of mishaps being
                                 investigated that do not pose a threat
                                 to public safety. A minor damage that
                                 does not pose a threat to public safety
                                 can easily exceed the $25,000 monetary
                                 threshold, triggering potentially
                                 costly and burdensome notification,
                                 reporting, and investigation
                                 requirements.
Toxics........................  The proposal would replace part 417
                                 toxic release hazard analysis
                                 requirements with performance-based
                                 regulations that would provide
                                 flexibility for operators to comply
                                 with the required risk criteria in
                                 varied and innovative ways relative to
                                 their operations.
Lightning protection            The proposal would remove appendix G to
 requirement.                    part 417, Natural and Triggered
                                 Lightning Flight Commit Criteria, and
                                 replace it with the performance-based
                                 requirements. The current requirements
                                 are outdated, inflexible, overly
                                 conservative, and not explicitly
                                 applicable to RLVs and RVs. The
                                 proposed revision would provide an
                                 operator with more flexibility, and
                                 allow it to take into account the
                                 vehicle's mission profile when
                                 determining how to mitigate the direct
                                 and indirect effects of a lightning
                                 discharge.
------------------------------------------------------------------------

    The FAA intends to update its analysis with additional information
and data identified during the comment period to better assess the
impacts of this deregulatory action. Estimates may change for the final
rule as a result.
    The FAA invites comments on the benefits, savings, or costs of this
proposed rule. Send comments by any of the methods identified under
Addresses in this proposed rule. Specifically, the FAA requests
information and data that can be used to quantify the additional
savings of this proposed rule. Please provide references and sources
for information and data.

B. Regulatory Flexibility Determination

    The Regulatory Flexibility Act of 1980 (Pub. L. 96-354) (RFA)
establishes ``as a principle of regulatory issuance that agencies shall
endeavor, consistent with the objectives of the rule and of applicable
statutes, to fit regulatory and informational requirements to the scale
of the businesses, organizations, and governmental jurisdictions
subject to regulation. To achieve this principle, agencies are required
to solicit and consider flexible regulatory proposals and to explain
the rationale for their actions to assure that such proposals are given
serious consideration.'' The RFA covers a wide-range of small entities,
including small businesses, not-for-profit organizations, and small
governmental jurisdictions.
    Agencies must perform a review to determine whether a rule will
have a significant economic impact on a substantial number of small
entities. If the agency determines that it will, the agency must
prepare a regulatory flexibility analysis as described in the RFA.
    Under Section 603(b) of the RFA, the initial regulatory flexibility
analysis for a proposed rule must:
     Describe reasons the agency is considering the action;
     State the legal basis and objectives;
     Describe the recordkeeping and other compliance
requirements;
     State all federal rules that may duplicate, overlap, or
conflict;
     Describe an estimated number of small entities impacted;
and
     Describe alternatives considered.
1. Description of Reasons the Agency Is Considering the Action
    The Chair of the National Space Council, the Vice President,
directed the Secretaries of Transportation and Commerce, and the
Director of the Office of Management and Budget, to conduct a review of
the U.S. regulatory framework for commercial space activities and
report back within 45 days with a plan to remove barriers to commercial
space enterprises.
    The Council approved four recommendations, including the Department
of Transportation's recommendation that the launch and reentry
regulations should be reformed into a consolidated, performance-based
licensing regime.
    Codifying the recommendations of the Council, SPD-2 was issued on
May 24, 2018. SPD-2 instructed the Secretary of Transportation to
publish for notice and comment proposed rules rescinding or revising
the launch and reentry licensing regulations, no later than February 1,
2019. SPD-2 charged the Department with revising the regulations such
that they would require a single license for all types of commercial
space flight operations and replace prescriptive requirements with
performance-based criteria. The current action is complying with this
recommendation.
    Current regulations setting forth procedures and requirements for
commercial space transportation licensing were based largely on the
distinction between expendable or reusable launch vehicles.
Specifically, 14 CFR parts 415 and 417 address the launch of expendable
launch vehicles, part 431 addresses the launch and

reentry of reusable launch vehicles, and part 435 addresses the reentry
of reentry vehicles.
    The regulations in parts 415 and 417 are based on the Federal
launch range standards developed in the 1990s. Parts 431 and 435 are
primarily process-based, relying on a license applicant to derive
safety requirements through a ``system safety'' process. While these
regulations satisfied the need of the commercial launch industry at the
time they were issued, the industry has changed and continues to
evolve, thus rendering the current regulatory structure cumbersome and
outdated.
2. Statement of the Legal Basis and Objectives
    The Commercial Space Launch Act of 1984, as amended and re-codified
at 51 U.S.C. 50901-50923 (the Act), authorizes the Department of
Transportation, and the FAA through delegation, to oversee, license,
and regulate commercial launch and reentry activities, and the
operation of launch and reentry sites as carried out by U.S. citizens
or within the United States. Section 50905 directs the FAA to exercise
this responsibility consistent with public health and safety, safety of
property, and the national security and foreign policy interests of the
United States. The FAA is authorized to regulate only to the extent
necessary to protect the public health and safety, safety of property,
and national security and foreign policy interests of the United
States. In addition, section 50903 requires that the FAA encourage,
facilitate, and promote commercial space launches and reentries by the
private sector.
    If adopted as proposed, this rulemaking would streamline and
increase flexibility in the FAA's commercial space regulations. This
action would consolidate and revise multiple regulatory parts to apply
a single set of licensing and safety regulations across several types
of operations and vehicles. It would also replace many prescriptive
regulations with performance-based rules, giving industry greater