ASTM F3201-16

This international standard was developed in accordance with internationally recognized principles on standardization established in the Decision on Principles for the
Development of International Standards, Guides and Recommendations issued by the World Trade Organization Technical Barriers to Trade (TBT) Committee.
Designation: F3201 − 16
Standard Practice for
Ensuring Dependability of Software Used in Unmanned
Aircraft Systems (UAS)
This standard is issued under the fixed designation F3201; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope 2.2 IEC Standard:
IEC 62304 Medical Device Software—Software Life Cycle
1.1 This standard practice intends to ensure the dependabil-
Processes
ity of UAS software. Dependability includes both the safety
2.3 ISO Standards:
and security aspects of the software.
ISO 9001 Quality Management Systems—Requirements
1.2 This practice will focus on the following areas: (a)
2.4 ICAO Standard:
Organizationalcontrols(forexample,management,training)in ICAO 9859 Safety Management Manual
place during software development. (b) Use of the software in
2.5 NASA Standard:
the system, including its architecture and contribution to
NASA Technical Briefs Making Sense out of SOUP (Soft-
overall system safety and security. (c) Metrics and design
ware of Unknown Pedigree)
analysis related to assessing the code. (d) Techniques and tools
2.6 RTCA Standards:
related to code review. (e) Quality assurance. (f) Testing of the
RTCA DO-178C Software Considerations in Airborne Sys-
software.
tems and Equipment Certification
RTCA DO–278A Software Integrity Assurance Consider-
1.3 There is interest from industry and some parts of the
ations for Communication, Navigation, Surveillance, and
CAAs to pursue an alternate means of compliance for software
Air Traffic Management (CNS/ATM) Systems
assurance for small UAS (sUAS).
RTCADO-326 AirworthinessSecurityProcessSpecification
1.4 This practice is intended to support sUAS operations. It
2.7 Military Standards:
is assumed that the risk of sUAS will vary based on concept of Department of Defense Joint Software System Safety Hand-
operations, environment, and other variables. The fact that book
there are no souls onboard the UAS may reduce or eliminate MIL-STD-882E Department of Defense Standard for Sys-
tem Safety
somehazardsandrisks.However,atthediscretionoftheCAA,
this practice may be applied to other UAS operations.
3. Terminology
1.5 This standard does not purport to address all of the
3.1 Definitions of Terms Specific to This Standard:
safety concerns, if any, associated with its use. It is the
3.1.1 application programming interface (API)—definition
responsibility of the user of this standard to establish appro-
of the inputs and outputs for operations intended for use by
priate safety and health practices and determine the applica-
other software modules.
bility of regulatory limitations prior to use.
3.1.2 architecture—architecture is made up of the definition
of the sUAS Software components, the data that flows between
2. Referenced Documents
2.1 FAA Standard:
Available from International Electrotechnical Commission (IEC), 3, rue de
FAA 23.1309–1E System Safety Analysis and Assessment
Varembé, P.O. Box 131, 1211 Geneva 20, Switzerland, http://www.iec.ch.
for Part 23 Airplanes
Available from International Organization for Standardization (ISO), ISO
Central Secretariat, BIBC II, Chemin de Blandonnet 8, CP 401, 1214 Vernier,
Geneva, Switzerland, http://www.iso.org.
Available from International Civil Aviation Organization (ICAO), 999 Robert-
This practice is under the jurisdiction ofASTM Committee F38 on Unmanned Bourassa Blvd., Montreal, Quebec H3C 5H7, Canada, http://www.icao.int.
Aircraft Systems and is the direct responsibility of Subcommittee F38.01 on Available from U.S. National Air and Space Administration (NASA), 300 E.
Airworthiness. Street, SW, Suite 5R30, Washington, DC 20546, http://www.nasa.gov.
Current edition approved Sept. 1, 2016. Published September 2016. DOI: Available from Radio Technical Commission for Aeronautics (RTCA), 1150
10.1520/F3201-16. 18th St., NW, Suite 910, Washington, DC 20036, http://www.rtca.org.
2 8
Available from Federal Aviation Administration (FAA), 800 Independence Available from DLA Document Services, Building 4/D, 700 Robbins Ave.,
Ave., SW, Washington, DC 20591, http://www.faa.gov. Philadelphia, PA 19111-5094, http://quicksearch.dla.mil.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
F3201 − 16
the components (data flow), and the order of execution of the could be used in safety evaluations, and could lead to devel-
components (control flow). opment of future requirements. “May” statements are provided
to clarify acceptability of a specific item or practice, and offer
3.1.3 code churn—the quantity and frequency of additions,
options for satisfying requirements.
deletions, and modifications to the source code for software.
3.1.18 small unmanned aircraft system (sUAS)—composed
3.1.4 code coverage—a measure used to describe the degree
of small unmanned aircraft (sUA-see 4.2) and all required
to which the source code of a program is tested by a particular
on-board subsystems, payload, control station, other required
test suite.
off-board subsystems, any required launch and recovery
3.1.5 customer—includes stakeholders outside of the sUAS
equipment, all required crew members, and command and
manufacturer who interface with the sUAS.
control (C2) links between sUA and the control station.
3.1.6 dependability—attribute of the software code that
3.1.19 sUAS manufacturer—the organization and personnel
produces the consequences for which it was written, without
with design responsibility for the sUAS, including the depend-
adverse effects, in its intended environment.
ability of the system software.
3.1.7 dynamic program analysis—the practice of analyzing
3.1.20 sUAS Software—includes both IDS and EDS.
softwarewhileitisexecuting,forexamplemonitoringmemory
3.1.21 software baseline—a known state of product soft-
access, allocation, and deallocation during program execution.
ware that has been formally reviewed and agreed on, that
For example, Valgrind is a popular open-source tool that
thereafter serves as the basis for further development, and can
performs this type of analysis.
be changed only through formal change control procedures.
3.1.8 externally developed software (EDS)—software devel-
3.1.22 software vulnerability—a mistake in software (also
oped outside of the sUAS manufacturer for which adequate
known as a weakness) that can be directly exploited to get a
records of the development process may not be available.
cyber-enabled capability to function in an unintended manner.
3.1.9 EDS quality plan—a plan to address the software
Typically this is the violation of a reasonable security policy
quality in the event that EDS source code is not available. See
for the cyber-enabled capability resulting in a negative techni-
Appendix X2 for more details.
calimpact.Althoughallvulnerabilitiesinvolveaweakness,not
all weaknesses are vulnerabilities. For example, Common
3.1.10 fuzz testing—a testing technique wherein the input to
Vulnerabilities and Exposures is a dictionary of common
a unit under test is unexpected in some way. Examples include
names for publicly known software-related vulnerabilities.
testing with input that is invalid, unexpected, or random.
3.1.23 statement coverage—a testing technique that in-
3.1.11 internal user—includes stakeholders within the
volves the execution of all the statements at least once in the
sUAS manufacturer’s organization who interface with the
sourcecode.Asametric,itisusedtocalculateandmeasurethe
sUAS.
number of statements in the source code which have been
3.1.12 internally developed software (IDS)—software de-
executed.
veloped within the sUAS manufacturer’s organization.
3.1.24 threat modeling—a structured approach that enables
3.1.13 penetration testing—a testing method intended to
the sUAS manufacturer to identify, quantify, and address the
identify and correct vulnerabilities and security defects by
security risks associated with an application. The process
attempting to break, bypass, or tamper with software security
involves systematically identifying security threats and rating
controls.
them according to severity and level of occurrence probability.
3.1.14 publish—formalized release of a document to appro-
The overall goal for threat modeling (also known as attack
priate parties. A history should be maintained for published
modeling) is the creation of customized knowledge about
documents.The history may be part of revision control system,
potential attacks relevant to the application or organization.
printed papers in a binder, or any other auditable system.
This customized knowledge guides decisions about changes to
the code and security controls to implement.
3.1.15 quality assurance—the practice of internally moni-
toring or auditing the development process.
3.1.25 tier 1 requirements—required tasks and activities in
this practice for a software malfunction or penetration that
3.1.16 red team evaluation—a process designed to detect
would result in a slight reduction in sUAS functional capabili-
network and system vulnerabilities and test security by taking
ties or safety margins (for reference see Minor failure condi-
an attacker-like approach to system, network, or data access, or
tions per AC 23.1309–1E).
combinations thereof.
3.1.26 tier 2 requirements—required tasks and activities in
3.1.17 shall versus should versus may—use of the word
this practice for any software malfunction or penetration that
“shall” implies that a procedure or statement is mandatory and
would result in a significant reduction in sUAS functional
must be followed to comply with this practice, “should”
capabilities or safety margins with potential for injury (for
implies recommended, and “may” implies optional at the
reference see Major failure conditions per AC 23.1309–1E).
discretion of the supplier, manufacturer, or operator. Since
“shall” statements are requirements, they include sufficient 3.1.27 tier 3 requirements—required tasks and activities in
detail needed to define compliance (for example, threshold this standard for any software malfunction or penetration that
values, test methods, oversight, and references to other stan- would result in a large reduction in sUAS functional capabili-
dards). “Should” statements also represent parameters that tiesorsafetymarginsandcouldbeexpectedtoresultinserious
F3201 − 16
injury or fatality (for reference see Hazardous or more severe 5.1.1.1 This plan shall define the roles and responsibilities
failure conditions per AC 23.1309–1E). of each part of the manufacturer’s organization involved in
software acquisition, development, integration, and testing for
3.2 Acronyms:
all sUAS software projects in the organization.
3.2.1 API—Application Programming Interface
5.1.1.2 The sUAS manufacturer should educate company
3.2.2 CAA—Civil Aviation Authority
executives and train employees on the risks and vulnerabilities
3.2.3 EDS—Externally Developed Software
of the EDS integration or software development approach, or
3.2.4 FAA—Federal Aviation Administration both.
5.1.2 Tier 2, 3—The sUAS manufacturer shall record all
3.2.5 IDS—Internally Developed Software
uses and versions of EDS in the sUAS.
3.2.6 sUA—Small Unmanned Aircraft
5.1.3 Tier 3—The sUAS manufacturer shall have an orga-
3.2.7 sUAS—Small Unmanned Aircraft System
nizational response plan to address a flight critical software
3.2.8 UAS—Unmanned Aircraft System
malfunction or penetration for sUAS Software.
5.1.3.1 The sUAS manufacturer should make information
4. Applicability
available to all users of its sUAS regarding the software issue
4.1 The practice is written for all UAS intended for opera-
and provide guidance within 24 hours of being made aware of
tion within airspace controlled by a CAA.
the issue.
4.2 It is assumed that the maximum weight and airspeed of
5.2 sUAS Software Architecture and Use:
a sUAS will be specified by the nation’s CAA. However,
5.2.1 Tier 1, 2, 3—The sUAS manufacturer shall conduct an
unless otherwise specified by a nation’s CAA, this practice
analysis to determine the hazards and impacts associated with
applies only to sUA that:
the potential malfunction, failure, or exploitation of the sUAS
4.2.1 Haveamaximumtakeoffgrossweightof55lb(25kg)
Software and identify potential risk mitigation.
or less;
5.2.1.1 The analysis shall define the sUAS Software’s in-
4.2.2 Have the capability to allow remote intervention by
tended function(s) and document potential failure (gracefully
flight personnel in the management of the flight during normal
or suddenly).
operations.
5.2.1.2 The analysis should be conducted using industry
4.3 This practice is intended for software that is part of a
best practices (see references in Appendix X1) but should
sUAS. It may be used by itself or in conjunction with other consider unique aspects of the sUAS size and operation.
standards such as DO-178C, as deemed appropriate by the
5.2.1.3 Security vulnerabilities should be considered as
sUAS manufacturer in accordance with CAA guidance. This
possible causes of hazards in performing the hazard analysis.
practice does not replace or supersede other standards, hence a
5.2.2 Tier 2, 3—The sUAS manufacturer shall publish an
sUAS manufacturer may choose to certify under alternatives
EDS integration plan.
such as DO-178C without reference to this practice, subject to
5.2.2.1 The plan shall document the tasks and milestones
CAAguidance. Appendix X1 contains guidance for producing
that need to be performed to acquire and integrate the EDS.
artifacts corresponding to the requirements in Section 5.
5.2.2.2 The plan should include release gates/checkpoints/
4.4 The applicability of the practice extends to those soft-
milestones and associated criteria at one or more points during
ware items in the sUAS that implement functions essential to theacquisitionandintegrationprocess,aswellasconfiguration
safety. Software items that have no impact on safety are out of
management for all EDS code and documents.
scope for this practice. For example, payload software on the
5.2.2.3 The EDS integration plan may be part of a larger
sUAS that is not used to perform a safety-critical function is
software integration plan or other lifecycle documentation.
outside the scope of this practice.
5.2.2.4 The EDS integration plan should address how con-
figuration tables, data, and libraries that may be included in the
5. Requirements
EDS are integrated.
NOTE 1—The hazard analysis (see 5.2.1) will be used to determine the
5.2.2.5 The sUAS manufacturer shall ensure that the EDS
severity of a sUAS Software malfunction or failure and the corresponding
tier. See Appendix X2 for examples of tier assignments to sUAS
integration plan is folowed and track exceptions to the plan.
functions.
5.2.2.6 All exceptions to the EDS integration plan shall be
NOTE2—Theapplicabilityoftheeachrequirementisdeterminedbythe
incorporated into the plan and published.
tier assignment and noted in parentheses next to the requirement. Unless
5.2.3 Tier 1, 2, 3—The sUAS manufacturer shall publish a
otherwise indicated, sub-requirements inherit the tier assignments of the
parent requirement (for example, if requirement 5.2.1 applies toTiers 1, 2, software development and integration plan for IDS.
and 3, then 5.2.1.1 also applies to the same tiers).
5.2.3.1 The IDS development and integration plan shall
NOTE 3—Requirements may apply only to EDS, only to IDS, or to the
establish the software baseline and document the tasks and
sUAS Software (includes EDS and IDS). Unless otherwise indicated,
milestones that need to be performed to develop the software
sub-requirements apply to the kind of software (EDS, IDS, or sUAS
Software) specified in the parent requirement. See Appendix X3 for for a specific project.
scenarios for using this practice for EDS, IDS, and sUAS Software.
5.2.3.2 The IDS development and integration plan should
5.1 Organizational Planning: include release gates/checkpoints/milestones and associated
5.1.1 Tier 1, 2, 3—The sUAS manufacturer shall publish an criteria at one or more points in the development process, and
organizational software plan for sUAS Software. configuration management of code and documents.
F3201 − 16
5.2.3.3 The IDS development and integration plan should example, trade space between size, features, cost, speed, etc.)
address the pedigree of software development and testing tools in order to understand the chosen features and complexity of
and the development and testing of configuration tables, data, the EDS compared with other available software.
and libraries.
5.2.7 Tier 2, 3—The sUAS manufacturer shall review and
5.2.3.4 Tier 2, 3 only—The sUAS manufacturer shall ensure
document sUAS Software architecture and the sUAS Software
thattheIDSdevelopmentintegrationplanisfollowedandtrack
functional, interface, and performance requirements.
exceptions to the plan.
5.2.7.1 Performance requirements may be stated in terms of
5.2.3.5 Tier 2, 3 only—All exceptions to the IDS develop-
timing, precision, etc.
ment and integration plan shall be incorporated into the plan
5.2.7.2 Functional and interface requirements may be as-
and published.
sessed via the sUAS Software architecture.
5.2.4 Tier 2, 3—The sUAS manufacturer shall publish an
5.2.7.3 The architecture should show the relationship of the
EDS maintenance plan that documents the criteria and method
sUAS Software function to total system function including all
for how patches, bug fixes, upgrades, etc. provided by the EDS
interfaces.
supplier will be applied.
5.2.7.4 The architecture should show any mechanism for
5.2.4.1 The sUAS manufacturer shall perform maintenance
fail-safe or redundancy, or both, for sUAS Software.
on the EDS per the EDS maintenance plan.
5.2.7.5 The sUAS manufacturer may use traditional (for
5.2.4.2 The EDS maintenance plan shall contain processes
example,“shall”statements)ornon-traditional(forexample,in
that are performed at least annually. These processes may
the form of user stories) requirements.
include reviewing EDS changes, release notes, bug fixes, etc.
5.2.8 Tier 2, 3—The sUAS manufacturer shall neutralize
5.2.4.3 The EDS maintenance plan shall include the process
unwaranted functionality of the sUAS Software by disabling,
that ensures that the executable EDS object code and included
removing, or mitigating, or combinations thereof, risk associ-
configuration tables, data, and libraries are properly loaded in
ated with functions and features that are not needed for the
the appropriate computer(s) in the sUAS.
intended function of the sUAS Software.
5.2.4.4 The EDS maintenance plan should include how
configuration management will be leveraged to record changes 5.2.8.1 If code is disabled or removed, the sUAS manufac-
to the EDS throughout its use. turer shall confirm through regression tests (see 5.6.4) the
disabling or removal of those functions does not adversely
5.2.4.5 The EDS maintenance plan may be part of a larger
maintenance plan or other lifecycle documentation. affect the sUAS Software.
5.2.4.6 The sUAS manufacturer shall ensure that the EDS
5.2.8.2 The sUAS manufacturer may write unit tests to
maintenance plan is followed and track exceptions to the plan.
ensure that unneeded code does not adversely affect the
5.2.4.7 All exceptions to the EDS maintenance plan shall be system.
incorporated into the plan and published.
5.2.9 Tier 3—The sUAS manufacturer shall establish and
5.2.5 Tier 1, 2, 3—The sUAS manufacturer shall publish an
utilize a formal, documented process by which internal users
IDS maintenance plan that documents how patches, bug fixes,
and customers can report problems and have them resolved for
upgrades, etc. will be applied.
sUAS Software.
5.2.5.1 The IDS maintenance plan should include how
5.2.9.1 The formal process should include resolution track-
configuration management will be leveraged to record changes
ingandhavevisibilityacrossdevelopersandprojectmanagers.
to the software throughout its use.
5.2.9.2 If EDS is being integrated, the sUAS manufacturer
5.2.5.2 The IDS maintenance plan shall include the process
should have a method to contact the EDS supplier with
that ensures that the executable object code and included
problem reports.
configuration tables, data, and libraries are properly loaded in
5.2.10 Tier 3—The sUAS manufacturer shall document and
the appropriate computer(s) in the sUAS.
track the sUAS Software’s relevant service history where
5.2.5.3 The IDS maintenance plan shall address changes to
possible, including how many problems have been reported
software baselines, archival and retrieval process
...