ASTM F3201-26

1.1 This practice covers software development, validation and verification practices for software that is part of an unmanned aircraft system (UAS), including its associated elements. It may also be used by third-party service providers, including UAS Traffic Management (UTM) service providers.

1.2 This practice may be used by software providers who develop a single software component, as well as for end-to-end assessment of the dependability of all software integrated in a UAS. Dependability includes both the safety and security aspects of the software. Appendix X1 provides examples of various software components that may be developed using this practice.

1.3 This practice may be used by any software provider that is responsible for the design of an unmanned aircraft (UA) or an associated element, as well as software providers that develop and deploy software without having control of the UA design. The practice applies only within the interface boundaries for which the software provider is responsible.

1.4 This practice does not establish technical or performance requirements on software components or third-party services themselves, which are generally built to one or more other industry standards. By contrast, this practice provides requirements and best practices to ensure that software providers and system integrators follow robust processes when developing, integrating, testing, deploying and updating their software products and services.

1.5 This practice is intended to be used for software that supports visual line of sight (VLOS) and beyond visual line of sight (BVLOS) UAS operations. It is assumed that the risk associated with UAS software will vary based on the concept of operations, environment, and other variables. For use cases where no people are aboard the UA, operational risks and hazards may be reduced or eliminated. However, at the discretion of the CAA, this practice may be applied to other types of operations.

1.6 This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility of the user of this standard to establish appropriate safety, health, and environmental practices and determine the applicability of regulatory limitations prior to use.

1.7 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.

5.1 There is interest from industry and CAAs to create a means of compliance for software assurance for UAS, particularly in instances where conventional design assurance requirement management processes may over-prescribe requirements in relation to the level of risk of the UAS operation, or of the criticality of the software’s intended use. By way of specific example, RTCA DO-178 is widely accepted for developmental assurance of airborne software. One of its foundational assumptions is that a software failure could result in catastrophic loss of human life (pilots and/or passengers), particularly if a human pilot is not able to detect the problem and continue flying the aircraft. However, this assumption does not hold for UAS. CAAs have recognized that while loss of human life is possible in some failure conditions, for example mid-air collision with a conventional aircraft or ground impact, even those events carry a conditional probability of fatality.

5.2 DO-178 and related standards, such as RTCA DO-278, manage assurance at the front end of software development through strict traceability to pre-defined requirements. As an alternative, this practice articulates a method of development assurance that ensures sufficient dependability through verification and validation testing, as well as consistency of the overall configuration management and software development processes.

5.3 Users of this practice are expected to incorporate its requirements throughout the software development lifecycle. While the specific steps will vary, this generally includes the planning, requirements, design, implementation, test, integration, verification, deployment and maintenance activities. In order to ensure software dependability, this practice requires that its users have consistent processes and procedures across the software development lifecycle.

5.4 Defined configuration management practices, regardless of criticality, ensure that software providers have consistent awareness of the Configuration Items within each release package and are able to track the status of each item’s development and testing.

5.5 Verification and validation testing is expected to be appropriate to the intended use and environment for the software. The software provider remains free to choose the means of test, which may include combinations of Monte Carlo simulations, software-in-the-loop (SIL), hardware-in-the-loop (HIL), and flight testing, as well as other tests not explicitly identified in this practice.

5.6 This practice may be used by any stakeholder who develops or deploys software that supports the safe operation of UAS. Some of these stakeholders include, but are not limited to: