1、Designation: F3201 16Standard Practice forEnsuring Dependability of Software Used in UnmannedAircraft Systems (UAS)1This standard is issued under the fixed designation F3201; the number immediately following the designation indicates the year oforiginal adoption or, in the case of revision, the year
2、 of last revision. A number in parentheses indicates the year of last reapproval. Asuperscript epsilon () indicates an editorial change since the last revision or reapproval.1. Scope1.1 This standard practice intends to ensure the dependabil-ity of UAS software. Dependability includes both the safet
3、yand security aspects of the software.1.2 This practice will focus on the following areas: (a)Organizational controls (for example, management, training) inplace during software development. (b) Use of the software inthe system, including its architecture and contribution tooverall system safety and
4、 security. (c) Metrics and designanalysis related to assessing the code. (d) Techniques and toolsrelated to code review. (e) Quality assurance. (f) Testing of thesoftware.1.3 There is interest from industry and some parts of theCAAs to pursue an alternate means of compliance for softwareassurance fo
5、r small UAS (sUAS).1.4 This practice is intended to support sUAS operations. Itis assumed that the risk of sUAS will vary based on concept ofoperations, environment, and other variables. The fact thatthere are no souls onboard the UAS may reduce or eliminatesome hazards and risks. However, at the di
6、scretion of the CAA,this practice may be applied to other UAS operations.1.5 This standard does not purport to address all of thesafety concerns, if any, associated with its use. It is theresponsibility of the user of this standard to establish appro-priate safety and health practices and determine
7、the applica-bility of regulatory limitations prior to use.2. Referenced Documents2.1 FAA Standard:2FAA 23.13091E System Safety Analysis and Assessmentfor Part 23 Airplanes2.2 IEC Standard:3IEC 62304 Medical Device SoftwareSoftware Life CycleProcesses2.3 ISO Standards:4ISO 9001 Quality Management Sys
8、temsRequirements2.4 ICAO Standard:5ICAO 9859 Safety Management Manual2.5 NASA Standard:6NASA Technical Briefs Making Sense out of SOUP (Soft-ware of Unknown Pedigree)2.6 RTCA Standards:7RTCA DO-178C Software Considerations in Airborne Sys-tems and Equipment CertificationRTCA DO278A Software Integrit
9、y Assurance Consider-ations for Communication, Navigation, Surveillance, andAir Traffic Management (CNS/ATM) SystemsRTCADO-326 Airworthiness Security Process Specification2.7 Military Standards:8Department of Defense Joint Software System Safety Hand-bookMIL-STD-882E Department of Defense Standard f
10、or Sys-tem Safety3. Terminology3.1 Definitions of Terms Specific to This Standard:3.1.1 application programming interface (API)definitionof the inputs and outputs for operations intended for use byother software modules.3.1.2 architecturearchitecture is made up of the definitionof the sUAS Software
11、components, the data that flows between1This practice is under the jurisdiction of ASTM Committee F38 on UnmannedAircraft Systems and is the direct responsibility of Subcommittee F38.01 onAirworthiness.Current edition approved Sept. 1, 2016. Published September 2016. DOI:10.1520/F3201-16.2Available
12、from Federal Aviation Administration (FAA), 800 IndependenceAve., SW, Washington, DC 20591, http:/www.faa.gov.3Available from International Electrotechnical Commission (IEC), 3, rue deVaremb, P.O. Box 131, 1211 Geneva 20, Switzerland, http:/www.iec.ch.4Available from International Organization for S
13、tandardization (ISO), ISOCentral Secretariat, BIBC II, Chemin de Blandonnet 8, CP 401, 1214 Vernier,Geneva, Switzerland, http:/www.iso.org.5Available from International Civil Aviation Organization (ICAO), 999 Robert-Bourassa Blvd., Montreal, Quebec H3C 5H7, Canada, http:/www.icao.int.6Available from
14、 U.S. National Air and Space Administration (NASA), 300 E.Street, SW, Suite 5R30, Washington, DC 20546, http:/www.nasa.gov.7Available from Radio Technical Commission for Aeronautics (RTCA), 115018th St., NW, Suite 910, Washington, DC 20036, http:/www.rtca.org.8Available from DLA Document Services, B
15、uilding 4/D, 700 Robbins Ave.,Philadelphia, PA 19111-5094, http:/quicksearch.dla.mil.Copyright ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States1the components (data flow), and the order of execution of thecomponents (control flow).3.1.3 code chu
16、rnthe quantity and frequency of additions,deletions, and modifications to the source code for software.3.1.4 code coveragea measure used to describe the degreeto which the source code of a program is tested by a particulartest suite.3.1.5 customerincludes stakeholders outside of the sUASmanufacturer
17、 who interface with the sUAS.3.1.6 dependabilityattribute of the software code thatproduces the consequences for which it was written, withoutadverse effects, in its intended environment.3.1.7 dynamic program analysisthe practice of analyzingsoftware while it is executing, for example monitoring mem
18、oryaccess, allocation, and deallocation during program execution.For example, Valgrind is a popular open-source tool thatperforms this type of analysis.3.1.8 externally developed software (EDS)software devel-oped outside of the sUAS manufacturer for which adequaterecords of the development process m
19、ay not be available.3.1.9 EDS quality plana plan to address the softwarequality in the event that EDS source code is not available. SeeAppendix X2 for more details.3.1.10 fuzz testinga testing technique wherein the input toa unit under test is unexpected in some way. Examples includetesting with inp
20、ut that is invalid, unexpected, or random.3.1.11 internal userincludes stakeholders within thesUAS manufacturers organization who interface with thesUAS.3.1.12 internally developed software (IDS)software de-veloped within the sUAS manufacturers organization.3.1.13 penetration testinga testing method
21、 intended toidentify and correct vulnerabilities and security defects byattempting to break, bypass, or tamper with software securitycontrols.3.1.14 publishformalized release of a document to appro-priate parties. A history should be maintained for publisheddocuments. The history may be part of revi
22、sion control system,printed papers in a binder, or any other auditable system.3.1.15 quality assurancethe practice of internally moni-toring or auditing the development process.3.1.16 red team evaluationa process designed to detectnetwork and system vulnerabilities and test security by takingan atta
23、cker-like approach to system, network, or data access, orcombinations thereof.3.1.17 shall versus should versus mayuse of the word“shall” implies that a procedure or statement is mandatory andmust be followed to comply with this practice, “should”implies recommended, and “may” implies optional at th
24、ediscretion of the supplier, manufacturer, or operator. Since“shall” statements are requirements, they include sufficientdetail needed to define compliance (for example, thresholdvalues, test methods, oversight, and references to other stan-dards). “Should” statements also represent parameters thatc
25、ould be used in safety evaluations, and could lead to devel-opment of future requirements. “May” statements are providedto clarify acceptability of a specific item or practice, and offeroptions for satisfying requirements.3.1.18 small unmanned aircraft system (sUAS)composedof small unmanned aircraft
26、 (sUA-see 4.2) and all requiredon-board subsystems, payload, control station, other requiredoff-board subsystems, any required launch and recoveryequipment, all required crew members, and command andcontrol (C2) links between sUA and the control station.3.1.19 sUAS manufacturerthe organization and p
27、ersonnelwith design responsibility for the sUAS, including the depend-ability of the system software.3.1.20 sUAS Softwareincludes both IDS and EDS.3.1.21 software baselinea known state of product soft-ware that has been formally reviewed and agreed on, thatthereafter serves as the basis for further
28、development, and canbe changed only through formal change control procedures.3.1.22 software vulnerabilitya mistake in software (alsoknown as a weakness) that can be directly exploited to get acyber-enabled capability to function in an unintended manner.Typically this is the violation of a reasonabl
29、e security policyfor the cyber-enabled capability resulting in a negative techni-cal impact.Although all vulnerabilities involve a weakness, notall weaknesses are vulnerabilities. For example, CommonVulnerabilities and Exposures is a dictionary of commonnames for publicly known software-related vuln
30、erabilities.3.1.23 statement coveragea testing technique that in-volves the execution of all the statements at least once in thesource code.As a metric, it is used to calculate and measure thenumber of statements in the source code which have beenexecuted.3.1.24 threat modelinga structured approach
31、that enablesthe sUAS manufacturer to identify, quantify, and address thesecurity risks associated with an application. The processinvolves systematically identifying security threats and ratingthem according to severity and level of occurrence probability.The overall goal for threat modeling (also k
32、nown as attackmodeling) is the creation of customized knowledge aboutpotential attacks relevant to the application or organization.This customized knowledge guides decisions about changes tothe code and security controls to implement.3.1.25 tier 1 requirementsrequired tasks and activities inthis pra
33、ctice for a software malfunction or penetration thatwould result in a slight reduction in sUAS functional capabili-ties or safety margins (for reference see Minor failure condi-tions per AC 23.13091E).3.1.26 tier 2 requirementsrequired tasks and activities inthis practice for any software malfunctio
34、n or penetration thatwould result in a significant reduction in sUAS functionalcapabilities or safety margins with potential for injury (forreference see Major failure conditions per AC 23.13091E).3.1.27 tier 3 requirementsrequired tasks and activities inthis standard for any software malfunction or
35、 penetration thatwould result in a large reduction in sUAS functional capabili-ties or safety margins and could be expected to result in seriousF3201 162injury or fatality (for reference see Hazardous or more severefailure conditions per AC 23.13091E).3.2 Acronyms:3.2.1 APIApplication Programming In
36、terface3.2.2 CAACivil Aviation Authority3.2.3 EDSExternally Developed Software3.2.4 FAAFederal Aviation Administration3.2.5 IDSInternally Developed Software3.2.6 sUASmall Unmanned Aircraft3.2.7 sUASSmall Unmanned Aircraft System3.2.8 UASUnmanned Aircraft System4. Applicability4.1 The practice is wri
37、tten for all UAS intended for opera-tion within airspace controlled by a CAA.4.2 It is assumed that the maximum weight and airspeed ofa sUAS will be specified by the nations CAA. However,unless otherwise specified by a nations CAA, this practiceapplies only to sUA that:4.2.1 Have a maximum takeoff g
38、ross weight of 55 lb (25 kg)or less;4.2.2 Have the capability to allow remote intervention byflight personnel in the management of the flight during normaloperations.4.3 This practice is intended for software that is part of asUAS. It may be used by itself or in conjunction with otherstandards such
39、as DO-178C, as deemed appropriate by thesUAS manufacturer in accordance with CAA guidance. Thispractice does not replace or supersede other standards, hence asUAS manufacturer may choose to certify under alternativessuch as DO-178C without reference to this practice, subject toCAA guidance. Appendix
40、 X1 contains guidance for producingartifacts corresponding to the requirements in Section 5.4.4 The applicability of the practice extends to those soft-ware items in the sUAS that implement functions essential tosafety. Software items that have no impact on safety are out ofscope for this practice.
41、For example, payload software on thesUAS that is not used to perform a safety-critical function isoutside the scope of this practice.5. RequirementsNOTE 1The hazard analysis (see 5.2.1) will be used to determine theseverity of a sUAS Software malfunction or failure and the correspondingtier. See App
42、endix X2 for examples of tier assignments to sUASfunctions.NOTE 2The applicability of the each requirement is determined by thetier assignment and noted in parentheses next to the requirement. Unlessotherwise indicated, sub-requirements inherit the tier assignments of theparent requirement (for exam
43、ple, if requirement 5.2.1 applies to Tiers 1, 2,and 3, then 5.2.1.1 also applies to the same tiers).NOTE 3Requirements may apply only to EDS, only to IDS, or to thesUAS Software (includes EDS and IDS). Unless otherwise indicated,sub-requirements apply to the kind of software (EDS, IDS, or sUASSoftwa
44、re) specified in the parent requirement. See Appendix X3 forscenarios for using this practice for EDS, IDS, and sUAS Software.5.1 Organizational Planning:5.1.1 Tier 1, 2, 3The sUAS manufacturer shall publish anorganizational software plan for sUAS Software.5.1.1.1 This plan shall define the roles an
45、d responsibilitiesof each part of the manufacturers organization involved insoftware acquisition, development, integration, and testing forall sUAS software projects in the organization.5.1.1.2 The sUAS manufacturer should educate companyexecutives and train employees on the risks and vulnerabilitie
46、sof the EDS integration or software development approach, orboth.5.1.2 Tier 2, 3The sUAS manufacturer shall record alluses and versions of EDS in the sUAS.5.1.3 Tier 3The sUAS manufacturer shall have an orga-nizational response plan to address a flight critical softwaremalfunction or penetration for
47、 sUAS Software.5.1.3.1 The sUAS manufacturer should make informationavailable to all users of its sUAS regarding the software issueand provide guidance within 24 hours of being made aware ofthe issue.5.2 sUAS Software Architecture and Use:5.2.1 Tier 1, 2, 3The sUAS manufacturer shall conduct ananaly
48、sis to determine the hazards and impacts associated withthe potential malfunction, failure, or exploitation of the sUASSoftware and identify potential risk mitigation.5.2.1.1 The analysis shall define the sUAS Softwares in-tended function(s) and document potential failure (gracefullyor suddenly).5.2
49、.1.2 The analysis should be conducted using industrybest practices (see references in Appendix X1) but shouldconsider unique aspects of the sUAS size and operation.5.2.1.3 Security vulnerabilities should be considered aspossible causes of hazards in performing the hazard analysis.5.2.2 Tier 2, 3The sUAS manufacturer shall publish anEDS integration plan.5.2.2.1 The plan shall document the tasks and milestonesthat need to be performed to acquire and integrate the EDS.5.2.2.2 The plan should include release gates/checkpoints/m
