ASTM F3269-21

1.1 The scope of this practice includes the following:

• 1.1.1 A set of components that comprise an RTA system.
• 1.1.2 Requirements and best practices to determine safe boundaries and RTA system coverage.
• 1.1.3 Requirements and best practices for an RTA system and RTA components, as applicable.
• 1.1.4 Appendixes with examples that demonstrate key RTA system concepts.

1.2 RTA components are required to meet the design assurance level dictated by a safety assessment process. Guidance for the safety assessment process may be found in references appropriate for the intended operations (ARP4754A, ARP4761, Practice F3178, etc.).

1.3 This practice was developed with UAS in mind. It may be applicable for aspects of manned aircraft certification/approval, as well as aviation ground systems. The scope of this practice is also envisioned to allow a variety of aircraft implementations where a human may perform the role of either the Complex Function or a Recovery Function.

1.4 The scope of this practice does not cover aspects of hardware/software integration. These should be considered separately during the development process.

Note 1: This practice does not suggest a one-size-fits-all strategy knowing that not all use cases may fit well into this architecture. There may exist additional components required to satisfy specific applications to the practice.

1.5 The values stated in inch-pound units are to be regarded as standard. No other units of measurement are included in this standard.

1.6 Table of Contents:

• Introduction
• Background
• Scope — Section 1
• Referenced Documents — Section 2
  • ASTM Standards — Section 2.1
  • FAA Advisory Circular — Section 2.2
  • RTCA Standards — Section 2.3
  • SAE Standards — Section 2.4
• Terminology — Section 3
  • Unique and Common Terminology — Section 3.3
  • Definitions of Terms Specific to This Standard — Section 3.4
  • Abbreviations — Section 3.5
• Significance and Use — Section 4
• RTA Functional Architecture — Section 5
  • Overall Architecture — Section 5.4
    • Components and Interfaces — Section 5.4.1
    • RTA System Coverage — Section 5.4.2
    • RTA Scenarios — Section 5.4.3
      • Event Sequencing and Timing — Section 5.4.3.8
    • Best Practices — Section 5.4.4
    • Requirements — Section 5.4.5
  • RTA Interfaces — Section 5.5
  • Input Manager — Section 5.6
    • Description — Section 5.6.1
    • Requirements — Section 5.6.2
  • Safety Monitor — Section 5.7
    • Requirements — Section 5.7.2
  • RTA Switch — Section 5.8
    • Description — Section 5.8.1
    • Requirements — Section 5.8.2
  • Recovery Function — Section 5.9
    • Description — Section 5.9.1
    • Best Practices — Section 5.9.2
    • Requirements — Section 5.9.3
• Keywords — Section 6
• Ground Collision Avoidance System (GCAS) as an Example RTA — Appendix X1
  • Introduction
  • Unassured Function — Section X1.1
  • RTA Required Inputs — Section X1.2
  • RTA Input Manager — Section X1.3
  • Safety Monitor — Section X1.4
  • Recovery Function — Section X1.5
  • RTA Switch — Section X1.6
  • Vehicle Management System — Section X1.7
• Machine Learning AI Autopilot (MLAA) — Appendix X2
  • Introduction
  • Assured and Unassured Data — Section X2.1
  • Input Manager — Section X2.2
  • Complex Function — Section X2.3
  • Safety Monitors — Section X2.4
  • Recovery Control Function — Section X2.5
  • RTA Switch — Section X2.6
  • Summary — Section X2.7
• Run-Time Assurance for a Neural Network-Based Adaptive Flight Control of an Unmanned Aircraft — Appendix X3
  • Visual Line-of-Sight Operations — Section X3.1
  • Beyond Visual Line-of-Sight Operation — Section X3.2
• Run-Time Assurance for Risk-Based Operation — Appendix X4
• Example Implementation of Timing and Latency Requirement — Appendix X5
• References

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

1.1 The scope of this practice includes the following:

• 1.1.1 A set of components that comprise an RTA system.
• 1.1.2 Requirements and best practices to determine safe boundaries and RTA system coverage.
• 1.1.3 Requirements and best practices for an RTA system and RTA components, as applicable.
• 1.1.4 Appendixes with examples that demonstrate key RTA system concepts.

1.2 RTA components are required to meet the design assurance level dictated by a safety assessment process. Guidance for the safety assessment process may be found in references appropriate for the intended operations (ARP4754A, ARP4761, Practice F3178, etc.).

1.3 This practice was developed with UAS in mind. It may be applicable for aspects of manned aircraft certification/approval, as well as aviation ground systems. The scope of this practice is also envisioned to allow a variety of aircraft implementations where a human may perform the role of either the Complex Function or a Recovery Function.

1.4 The scope of this practice does not cover aspects of hardware/software integration. These should be considered separately during the development process.

Note 1: This practice does not suggest a one-size-fits-all strategy knowing that not all use cases may fit well into this architecture. There may exist additional components required to satisfy specific applications to the practice.

1.5 The values stated in inch-pound units are to be regarded as standard. No other units of measurement are included in this standard.

1.6 Table of Contents:

4.1 This practice provides an architectural framework for developing an RTA system, which provides run-time assurance as an alternative to design-time assurance to fulfill safety requirements for an unassured or complex function. The standard provides best practices and guidelines to assist in the RTA system’s development. Further, it describes the architectural components and requirements for designing the RTA system.

Compliance to this practice is achieved by deriving RTA System requirements from the standard and capturing them in the Larger System Specification. The system design requirements can then be validated and verified using acceptable engineering practices. It is anticipated that this practice will provide a means to accept complex automation/autonomy aircraft functions that have been difficult to certify using traditional methods.

4.2 The following three-step process is used to derive verifiable design requirements using this architecture standard:

• 4.2.1 Create RTA System requirements using the guidance provided by this architecture standard.
• 4.2.2 Capture RTA System requirements in the Larger System Specification.
• 4.2.3 Perform verification and validation on the RTA System requirements in the Larger System Specification.

4.3 The RTA architecture can be applied to all sizes, levels, and classes of UAS. Using run-time assurance can provide systems with the following benefits:

• 4.3.1 The ability to mitigate hazards related to nondeterministic or unexpected behavior from unassured functions that employ advanced software methods or algorithmic complexity that cannot be certified using traditional certification practices.
• 4.3.2 The ability to use functions for which it may not be possible to obtain artifacts of conventional DO-178 or DO-254 assurance processes.
• 4.3.3 The ability to use COTS hardware or software, or both, for the unassured function.
  • 4.3.3.1 For example, automotive components, thereby leveraging mature software with extensive service history that was developed for other safety-critical industries, but cannot be shown to comply with aviation development assurance practices.
  • 4.3.3.2 For example, industry components where source code or other associated engineering artifacts are unavailable.
• 4.3.4 A reduction in cost and schedule burdens by allowing rapid design iterations of the unassured or complex function during and after initial certification. This update of the standard allows unassured or complex function upgrades after initial certification to minimize subsequent modifications to the certification or approval.