1.1 本惯例的范围包括以下内容: 1.1.1 组成RTA系统的一组组件。 1.1.2 确定安全边界和RTA系统覆盖范围的要求和最佳实践。 1.1.3 RTA系统和RTA组件的要求和最佳实践（如适用）。 1.1.4 附录和示例演示了RTA系统的关键概念。 1.2 RTA组件需要满足安全评估过程规定的设计保证水平。安全评估过程指南可在适用于预期操作的参考文献中找到（ARP4754A、ARP4761，规程 F3178 等）。 1.3 这种做法是在考虑无人机的情况下制定的。它可能适用于载人飞机认证/批准以及航空地面系统。这一实践的范围也被设想为允许各种飞机实施，其中人类可以执行复杂功能或恢复功能。 1.4 本实践的范围不包括硬件/软件集成方面。在开发过程中应单独考虑这些问题。 注1: 这种做法并不建议采用“一刀切”的策略，因为并非所有用例都适合这种架构。可能需要额外的组件来满足实践的特定应用。 1.5 以英寸-磅为单位的数值应视为标准值。本标准不包括其他计量单位。 1.6 目录: 标题 部分 介绍 出身背景 范围 1. 参考文件 2. ASTM标准 2.1 FAA咨询通告 2.2 RTCA标准 2.3 SAE标准 2.4 术语 3. 独特和通用的术语 3.3 本标准专用术语的定义 3.4 缩写 3.5 意义和用途 4. RTA功能架构 5. 总体架构 5.4 组件和接口 5.4.1 RTA系统覆盖率 5.4.2 RTA场景 5.4.3 事件排序和计时 5.4.3.8 最佳实践 5.4.4 要求 5.4.5 RTA接口 5.5 输入管理器 5.6 描述 5.6.1 要求 5.6.2 安全监视器 5.7 要求 5.7.2 RTA开关 5.8 描述 5.8.1 要求 5.8.2 恢复功能 5.9 描述 5.9.1 最佳实践 5.9.2 要求 5.9.3 关键词 6. 地面防撞系统（GCAS）为例 RTA 附录X1 介绍 未保证函数 X1.1 RTA所需输入 X1.2 RTA输入管理器 X1.3 安全监视器 X1.4 恢复功能 X1.5 RTA开关 X1.6 车辆管理系统 X1.7 机器学习人工智能自动驾驶仪（MLAA） 附录X2 介绍 有保证和无保证的数据 X2.1 输入管理器 X2.2 复函数 X2.3 安全监视器 X2.4 恢复控制功能 X2.5 RTA开关 X2.6 总结 X2.7 基于神经网络的自适应算法的运行时保证 飞行控制 无人驾驶飞机的 附录X3 视觉视线操作 X3.1 超视距操作 X3.2 基于风险的操作的运行时保证 附录X4 时序和延迟需求的示例实现 附录X5 工具书类 1.7 本标准并非旨在解决与其使用相关的所有安全问题（如有）。本标准的用户有责任在使用前制定适当的安全、健康和环境实践，并确定监管限制的适用性。 1.8 本国际标准是根据世界贸易组织技术性贸易壁垒（TBT）委员会发布的《关于制定国际标准、指南和建议的原则的决定》中确立的国际公认标准化原则制定的。 ====意义和用途====== 4.1 本实践为开发RTA系统提供了架构框架，该系统提供运行时保证，作为设计时保证的替代方案，以满足未保证或复杂功能的安全要求。该标准提供了最佳实践和指南，以协助RTA系统的开发。此外，它描述了设计RTA系统的架构组件和要求。通过从标准中导出RTA系统需求并将其捕获到更大的系统规范中，可以实现对该实践的遵从性。然后，可以使用可接受的工程实践来验证和验证系统设计需求。预计该实践将提供一种方法，以接受使用传统方法难以验证的复杂自动化/自主飞机功能。 4.2 以下三步过程用于使用本架构（architecture）标准推导可验证的设计需求: 4.2.1 使用本架构（architecture）标准提供的指导创建RTA系统需求。 4.2.2 在更大的系统规范中捕获RTA系统需求。 4.2.3 对较大系统规范中的RTA系统需求进行验证和确认。 4.3 RTA架构可以应用于所有规模、级别和类别的无人机。使用运行时保证可以为系统提供以下好处: 4.3.1 缓解与未保证功能的不确定性或意外行为相关的危险的能力，这些功能采用先进的软件方法或算法复杂性，无法使用传统的认证实践进行认证。 4.3.2 使用可能无法获得常规DO伪影的函数的能力- 178或DO-254保证过程。 4.3.3 使用COTS硬件或软件（或两者）实现未保证功能的能力。 4.3.3.1 例如，汽车零部件，因此利用了为其他安全关键行业开发的具有广泛服务历史的成熟软件，但无法证明其符合航空开发保证实践。 4.3.3.2 例如，源代码或其他相关工程工件不可用的行业组件。 4.3.4 通过允许在初始认证期间和之后对未保证或复杂功能进行快速设计迭代，减少成本和进度负担。本标准的更新允许在初始认证后进行未保证或复杂的功能升级，以尽量减少对认证或批准的后续修改。

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