1、Designation: F3269 17Standard Practice forMethods to Safely Bound Flight Behavior of UnmannedAircraft Systems Containing Complex Functions1This standard is issued under the fixed designation F3269; the number immediately following the designation indicates the year oforiginal adoption or, in the cas
2、e of revision, the year 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 defines design and test bestpractices that if followed, would provid
3、e guidance to anapplicant for providing evidence to the civil aviation authority(CAA) that the flight behavior of an unmanned aircraft system(UAS) containing complex function(s) is constrained through arun-time assurance (RTA) architecture to maintain an accept-able level of flight safety.1.2 This p
4、ractice will have the benefit of enabling highlyautomated UAS operations. It is envisioned that applicants willuse this practice as a means of compliance for safe implemen-tation of complex functions for routine operations.1.3 Verification of complex functions is considered toochallenging to use con
5、ventional software assurance methodssuch as RTCA DO-178C or IEC 61508. Certification chal-lenges under these standards include generating requiredartifacts, such as requirements, elimination of unintendedfunctionality, traceability/coverage, and test cases required forverification.1.4 There is signi
6、ficant interest from industry and CAAs tohave a standard practice to enable flight operations for UAScontaining complex functions. Developing a certification pathfor these UAS technologies could also advance safety inGeneral Aviation.1.5 The following design tenets are offered to provideguidance to
7、the UAS manufacturer as to the intended applica-tion of this standard.1.5.1 The RTA Architecture is intended to be used forComplex Functions that would require an amount of effort thatis beyond reasonably practicable to pass CAA conventionalcertification requirements.1.5.2 The UAS manufacturer shoul
8、d engage in appropriatedesign, test, and validation activities to enable the ComplexFunction to perform as intended.1.5.3 The complexity of the Recovery Control Function(RCF) deterministic commands should be minimized insofar aspracticable.1.5.4 Repeated invocation of an RCF during a single mis-sion
9、 may be considered an indication of improper ComplexFunction performance.1.5.5 An RTA design with multiple RCFs should considerthe aircraft state, relative outcomes, and differences in RTArecovery times in prioritizing the recovery actions in the safetymonitor.1.5.6 The UAS manufacturer should striv
10、e to minimizefalse or nuisance triggers of one or more RCFs as these falsealarms undermine user confidence in the system and impactoperational efficiency.1.6 This standard does not purport to address all of thesafety concerns, if any, associated with its use. It is theresponsibility of the user of t
11、his standard to establish appro-priate safety, health, and environmental practices and deter-mine the applicability of regulatory limitations prior to use.1.7 This international standard was developed in accor-dance with internationally recognized principles on standard-ization established in the De
12、cision on Principles for theDevelopment of International Standards, Guides and Recom-mendations issued by the World Trade Organization TechnicalBarriers to Trade (TBT) Committee.2. Referenced Documents2.1 ASTM Standards:2F3201 Practice for Ensuring Dependability of SoftwareUsed in Unmanned Aircraft
13、Systems (UAS)F3178 Practice for Operational Risk Assessment of SmallUnmanned Aircraft Systems (sUAS)2.2 Civil Standards, Policy, and Guidance:IEC 61508 Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems31This practice is under the jurisdiction of ASTM Committee
14、 F38 on UnmannedAircraft Systems and is the direct responsibility of Subcommittee F38.01 onAirworthiness.Current edition approved Sept. 1, 2017. Published September 2017. DOI:10.1520/F3269-17.2For referenced ASTM standards, visit the ASTM website, www.astm.org, orcontact ASTM Customer Service at ser
15、viceastm.org. For Annual Book of ASTMStandards volume information, refer to the standards Document Summary page onthe ASTM website.3Available from International Electrotechnical Commission (IEC), 3, rue deVaremb, 1st Floor, P.O. Box 131, CH-1211, Geneva 20, Switzerland, http:/www.iec.ch.Copyright AS
16、TM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United StatesThis international standard was developed in accordance with internationally recognized principles on standardization established in the Decision on Principles for theDevelopment of International Sta
17、ndards, Guides and Recommendations issued by the World Trade Organization Technical Barriers to Trade (TBT) Committee.1Mon Apr 30 46 RTCA DO-178C Software Considerations in Airborne Sys-tems and Equipment Certification43. Terminology3.1 Definitions of Terms Specific to This Standard:3.1.1 complex fu
18、nctionsoftware function or algorithm thatmay cause the UAS to operate in a manner that is difficult topredict due to compounded implications from factors such assensor measurement precision, algorithm complexity, environ-mental variables (for example, gusts, traffic, electromagneticeffects, etc.), m
19、ulti-core processing, probabilistic algorithms,fuzzy logic, machine learning, genetic algorithms, resourceavailability, and aircraft system state. These software functionsor algorithms are sometimes referred to as “autonomous”,“non-deterministic”, “artificial intelligence”, “adaptive”, or“intelligen
20、t” algorithms.3.1.2 continuous built-in testcomponent level tests thatare critical for monitoring the integrity of data and health of theaircraft systems which are crucial for validating the data usedfor determining acceptable aircraft safety and stability andcontrol.3.1.3 decision delaycumulative d
21、elays from the safetymonitor and the RTA Switch.3.1.4 input delaycumulative delay from the sensed inputsand the RTA Input Manager.3.1.5 non-pedigreed componentshardware and softwareitems for which the UAS manufacturer does not or cannotproduce sufficient evidence that these items on their own willop
22、erate within an acceptable level of risk based on theoperational risk assessment.3.1.6 pedigreed componentshardware and software itemsfor which the UAS manufacturer produces sufficient evidencethat these items on their own will operate within an acceptablelevel of risk based on the operational risk
23、assessment.3.1.7 pre-defined limitsdefined not-to-exceed restrictionsthat, if exceeded, would create a safety hazard. These “hardlimits” are determined from the operational risk assessment(for example, taking into account vehicle characteristics,CONOPS, etc.).3.1.8 recovery control functiona pedigre
24、ed function orsoftware algorithm to return the UAS to a safe state. Forexample, a sequence of commands that causes the UAS to landsafely, to maneuver in space, return to level flight, or deploy aflight recovery system.3.1.8.1 RCF completethe system state where the RCF hasbeen effective in ensuring t
25、he UAS will not violate itspre-defined limits.3.1.8.2 RCF delaythe cumulative delay from each RCF.3.1.8.3 RCF response delaythe delay between the initia-tion of the RCF and RCF complete.3.1.8.4 RCF trigger thresholdsthe thresholds in the safetymonitor which the UAS manufacturer sets to ensure that a
26、ctionis taken before the UAS violates a pre-defined limit. These“soft limits” trigger the safety monitor to command the RTAswitch to an appropriate RCF and account for all delaysbetween command of the RTA switch and the execution of therecovery action.3.1.9 run-time assurance architecturea system of
27、 pedi-greed components that implements real-time monitoring,prediction, and fail-safe recovery mechanisms that bounds theflight behavior of a non-pedigreed complex function to ensurethe safety of a UAS. Includes the components in Fig. 1.3.1.9.1 RTA input managera function or device that inte-grates
28、sensor data and monitors sensor state.3.1.9.2 RTA recovery timethe delay between the inputs tothe RTA architecture and RCF complete. RTA recovery timeincludes the RTA response time plus vehicle dynamics, humanresponse time (if implemented), etc.3.1.9.3 RTA required inputsdata from sensors, discretes
29、tate indicators, vehicle state monitors, and other sources thatdescribe the aircraft state and its environment.3.1.9.4 RTA response timethe delay between the inputs tothe RTA architecture and the activation of each recoverycontrol function. RTA response time is the system end-to-enddelay and include
30、s input delay, decision delay, and RCF delay.See Fig. 2.3.1.9.5 RTA switcha function or device that receivescontrol commands from the safety monitor which determineswhether the complex function or specific recovery controlfunctions are sending commands to the aircraft systems toexecute the appropria
31、te action. The RTA switch ensures thatonly a single function is sending commands to the vehiclemanagement system.3.1.10 safety monitorcontinually monitors aircraft state todetermine if the aircraft is or is predicted to exceed pre-definedlimits. As necessary it will control the safety switch to enab
32、leexecution of the recovery control function (including determin-ing which recovery control function is executed if more thanone exists).3.1.11 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, “s
33、hould”implies recommended, and “may” implies optional at thediscretion 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-
34、dards). “Should” statements also represent parameters thatcould 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.12 vehicle mana
35、gement systemelements critical tomaintaining normal flight and to executing all recovery controlfunctions. Requirements for the VMS are derived from otherstandards and may include certified autopilots, inner-loop flightcontrols, outer-loop flight controls, etc.4Available from Radio Technical Commiss
36、ion for Aeronautics (RTCA), 115018th NW, Suite 910, Washington, DC 20036, www.rtca.org.F3269 172Mon Apr 30 46 3.2 Acronyms:3.2.1 CAACivil Aviation Authority.3.2.2 CFComplex Function.3.2.3 ORAOperational Risk Assessment.3.2.4 RCFRecovery Control Function.3.2.5 RTARun-time assurance.3.2.6 SMSafety Mon
37、itor.3.2.7 UASUnmanned Aircraft System.3.2.8 VMSVehicle Management System.4. Applicability4.1 The focus of this practice is UAS operations, includingextended visual line of sight and beyond visual line of sightoperations. At the discretion of the CAA, this practice may beapplied to other UAS or othe
38、r aviation operations, based on aFIG. 1 Functional Components of a Generic Run-Time Assurance ArchitectureFIG. 2 RTA Response Timing DiagramF3269 173Mon Apr 30 46 risk-based assessment of the specific aircraft design, intendedmission, and area of intended operation.4.2 The practice is expected to be
39、come an acceptable, butnot the only, means of compliance in support of airworthiness,design, or operational approval processes for UAS.4.3 The CAA requires that an applicant must show anddocument an acceptable means of compliance for the designand testing for the RTA system incorporated on the UAS.
40、It isimportant that both the CAA and the applicant agree upon useof industry consensus standard(s) so that acceptable engineer-ing practices are used throughout the life cycle of the product.Using these standards is intended to provide the confidencelevel required to allow non-pedigreed complex func
41、tions tooperate while being monitored by a run-time assurance archi-tecture for possible undetected errors.4.4 Run-Time Assurance ArchitectureIt is assumed thatthe complex function will not be certified. It is assumed that thesafety monitor will monitor vehicle state and command theRTA switch to a r
42、ecovery control function. See Fig. 1.4.4.1 Integrating a complex function into a UAS may resultin hazards due to the complexity of the algorithm and itsresponse to environment, mission, and vehicle state.4.4.2 These hazards may be mitigated through the use ofone or more recovery control functions.4.
43、4.3 The purpose of the recovery control function(s) is toensure that hazards to third parties, other aircraft, theenvironment, etc. are mitigated to an acceptable level of risk.4.5 Run-time Assurance Architecture Description:4.5.1 Fig. 1 shows a minimal set of functional and input/output blocks to i
44、mplement a generic RTA architecture. TheRTA required inputs, RTA input manager (for example, systemstate, continuous built-in test, derived inputs, etc.), safetymonitory, RTA switch, and recovery control function(s) allwork together to monitor and limit the control authority of thecomplex function t
45、o maintain safety of the UAS.4.5.2 Because of the difficulty, cost, or practically, orcombinations thereof, of certifying the complex function bytraditional means, the complex function is deemed to be ofunknown pedigree and therefore cannot be the only availablemeans of control to ensure flight safe
46、ty. The complex functionmay receive input data from non-pedigreed sensor sources(these sources are not shown in Fig. 1). The RCF provides oneor more alternatives to replace the control of the complexfunction returning the system to a safe method of control withthe assurance level specified in the sa
47、fety analysis. One ormore recovery methods are selectable through a switch that iscontrolled by the safety monitor and passed to the VMS (forexample, physical plant, inner-loop flight control, outer-loopflight control, etc.).4.5.3 Recovery control functions can be either temporary(that is, control i
48、s passed back to the complex function) orterminal (that is, control remains with the recovery controlfunction until flight is terminated).4.5.4 The safety monitors sole purpose is to monitor theUAS safety state (that is, the state of the UAS relative topotential hazards), to determine (via the RTA s
49、witch) whichfunction (either the complex function or one of the recoverycontrol functions) has control authority.4.5.5 An example implementation of an RTA architecturefor a ground collision avoidance system is provided in Appen-dix X1.4.6 Fig. 2 contains a timing diagram which is a graphicalrepresentation of relationship of different measures of RTAprocessing (green) to various milestone events both external(dark orange) and internal (in black) to the RTA. The timingdiagram is intended to be used to explain these relationships toaid UA
