ASTM F3548-21
(Specification)Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability
Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability
SIGNIFICANCE AND USE
7.1 This specification is intended to be used by USS developers, CAAs, and others to assess USS conformance with this UTM specification.
SCOPE
1.1 This specification is intended to be a global specification providing components that may be used to satisfy requirements expected to be common to many UTM-related regulations. This specification is not intended to comprehensively address all aspects of any particular UTM-related regulation or concept of operations. Similarly, because varying terminology for the same concept is frequently used across different regulations, readers should not expect an exact terminology consistency with any particular UTM-related regulation.
1.2 This version of the specification is focused on strategic aspects of UAS operations, including strategic conflict detection, aggregate conformance of operations to their operational intents, constraint awareness, and situational awareness in the event of nonconforming or contingent operations. The intention is that this specification will evolve to address increasingly complex strategic aspects of UAS operations and potentially certain tactical aspects of UAS operations.
1.3 This specification addresses the performance and interoperability requirements, including associated application programming interfaces (APIs), for a set of UTM roles performed by UAS Service Suppliers (USSs) in support of UAS operations.2 Roles are groupings of one or more related UTM services. A competent authority may choose to use the roles defined in this specification in establishing the granularity of authorizations granted to a USS. The roles defined in this specification are:
(1) Strategic Coordination, comprising the Strategic Conflict Detection and Aggregate Operational Intent Conformance Monitoring services;
(2) Conformance Monitoring for Situational Awareness (CMSA);
(3) Constraint Management, comprising the Constraint Management service; and
(4) Constraint Processing, comprising the Constraint Processing service.
1.4 Section 4, Conceptual Overview, provides a description of each of the services and roles and includes further discussion on their scope.
1.5 A regulator may choose to require that a USS support a minimum or prescribed set of roles and services and may adopt terminology other than USS for a software system that provides something other than that minimum or prescribed set of roles and services. However, for purposes of this specification, a USS is a system that provides one or more of the UTM services defined in this specification.
1.6 A USS is not required by this specification to perform all roles or implement all defined services, providing business case flexibility for implementers. A typical USS that supports operators in the planning and execution of UAS operations may implement the Strategic Coordination, Constraint Processing, and CMSA roles. (Note that a USS providing CMSA for a UAS operation is required to also provide Strategic Coordination for the operation.) However, other implementations more limited in scope are possible. For example, a USS may implement only the Constraint Management role and be intended for use only by authorized constraint providers; or, a USS may implement only the Constraint Processing role to provide general airspace awareness to users independent of planning UAS flights. USSs may also provide additional, value-added capabilities and still be compliant with this specification as long as the value-added capabilities do not conflict with the services defined in this specification, and the implementation of services defined in this specification conforms to the applicable requirements.
1.7 A USS may also support other UTM roles such as Remote ID and airspace access (for example, the FAA’s LAANC), specified in other documents.
1.8 This specification addresses aspects common to all roles and services, such as Discovery and Synchronization Services (DSS), security, aud...
General Information
- Status
- Published
- Publication Date
- 30-Nov-2021
- Technical Committee
- F38 - Unmanned Aircraft Systems
- Drafting Committee
- F38.02 - Flight Operations
Relations
- Effective Date
- 01-Jan-2020
- Effective Date
- 01-Nov-2016
- Effective Date
- 01-Apr-2016
- Effective Date
- 15-Sep-2015
- Effective Date
- 01-May-2015
- Effective Date
- 01-Mar-2015
- Effective Date
- 01-Dec-2014
Overview
ASTM F3548-21: Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability provides an internationally recognized framework to support the interoperability, performance, and conformance assessment of USSs within UTM ecosystems. Developed by ASTM, this specification targets a global audience and aims to supply common technical components for meeting regulatory requirements related to unmanned aircraft systems (UAS) operations.
This standard is particularly relevant for UAS Service Supplier (USS) developers, Civil Aviation Authorities (CAAs), and UTM infrastructure stakeholders. It defines roles, services, and system interactions essential for strategic UAS operation management, with a strong focus on interoperability and safety.
Key Topics
- Strategic UAS Operations: The standard covers high-level management of UAS operations, such as strategic conflict detection, aggregate conformance to operational plans, constraint awareness, and situational monitoring for deviations.
- USS Roles and Services: It details specific USS roles, including:
- Strategic Coordination (conflict detection and conformance monitoring)
- Conformance Monitoring for Situational Awareness (CMSA)
- Constraint Management (creation and distribution of airspace constraints)
- Constraint Processing (ingestion and communication of constraints to stakeholders)
- Interoperability Requirements: Sets out requirements for application programming interfaces (APIs), discovery and synchronization services (DSS), security measures, and event handling for effective USS-to-USS and USS-to-system communication.
- Flexibility and Modular Adoption: Allows implementers to adopt all or a subset of roles and services per their business case or regulatory need, increasing adaptability and innovation.
- Terminology and Compatibility: Addresses varied global terminology (e.g., U-Space Service Provider, UTM Service Provider), promoting cross-border and inter-organizational consistency.
Applications
- USS Compliance Assessment: Enables USS developers and operators to verify that their systems meet essential UTM interoperability and performance criteria.
- Civil Aviation Integration: Assists CAAs in referencing or mandating common UTM roles and services for safe, coordinated UAS traffic management across diverse regulatory environments.
- Operational Safety and Efficiency: By defining strategic conflict detection and conformance monitoring, the standard reduces midair collision risks and enhances the reliability of UAS operations.
- Dynamic Airspace Management: Supports real-time coordination between multiple USSs, enabling the sharing of operational intent, constraints, and situational awareness for both routine and off-nominal conditions.
- Business Adaptation: Facilitates limited or focused USS implementations, such as services restricted to constraint management or airspace awareness, encouraging a flexible market landscape.
Related Standards
- ASTM F3411: Specification for Remote ID and Tracking, supporting real-time identification of UAS in the airspace.
- EUROCAE ED-269: Minimum Operational Performance Standard for UAS Geo-Fencing.
- ISO/IEC 27001: International standard for information security management systems.
- Relevant IETF RFCs: For standardized time-stamping (RFC 3339), network protocols (RFC 5905), and secure token management (RFC 7519).
- FAA LAANC: Low Altitude Authorization and Notification Capability - an example of USS-supported airspace access.
Adopting ASTM F3548-21 enables seamless integration across UAS service suppliers and regulatory bodies, fostering safe, scalable, and interoperable UTM environments in alignment with emerging international aviation standards and requirements. This foundational framework is key for the continued growth and harmonization of global drone operations and unmanned traffic management solutions.
Buy Documents
ASTM F3548-21 - Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability
Get Certified
Connect with accredited certification bodies for this standard
BSMI (Bureau of Standards, Metrology and Inspection)
Taiwan's standards and inspection authority.
Sponsored listings
Frequently Asked Questions
ASTM F3548-21 is a technical specification published by ASTM International. Its full title is "Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability". This standard covers: SIGNIFICANCE AND USE 7.1 This specification is intended to be used by USS developers, CAAs, and others to assess USS conformance with this UTM specification. SCOPE 1.1 This specification is intended to be a global specification providing components that may be used to satisfy requirements expected to be common to many UTM-related regulations. This specification is not intended to comprehensively address all aspects of any particular UTM-related regulation or concept of operations. Similarly, because varying terminology for the same concept is frequently used across different regulations, readers should not expect an exact terminology consistency with any particular UTM-related regulation. 1.2 This version of the specification is focused on strategic aspects of UAS operations, including strategic conflict detection, aggregate conformance of operations to their operational intents, constraint awareness, and situational awareness in the event of nonconforming or contingent operations. The intention is that this specification will evolve to address increasingly complex strategic aspects of UAS operations and potentially certain tactical aspects of UAS operations. 1.3 This specification addresses the performance and interoperability requirements, including associated application programming interfaces (APIs), for a set of UTM roles performed by UAS Service Suppliers (USSs) in support of UAS operations.2 Roles are groupings of one or more related UTM services. A competent authority may choose to use the roles defined in this specification in establishing the granularity of authorizations granted to a USS. The roles defined in this specification are: (1) Strategic Coordination, comprising the Strategic Conflict Detection and Aggregate Operational Intent Conformance Monitoring services; (2) Conformance Monitoring for Situational Awareness (CMSA); (3) Constraint Management, comprising the Constraint Management service; and (4) Constraint Processing, comprising the Constraint Processing service. 1.4 Section 4, Conceptual Overview, provides a description of each of the services and roles and includes further discussion on their scope. 1.5 A regulator may choose to require that a USS support a minimum or prescribed set of roles and services and may adopt terminology other than USS for a software system that provides something other than that minimum or prescribed set of roles and services. However, for purposes of this specification, a USS is a system that provides one or more of the UTM services defined in this specification. 1.6 A USS is not required by this specification to perform all roles or implement all defined services, providing business case flexibility for implementers. A typical USS that supports operators in the planning and execution of UAS operations may implement the Strategic Coordination, Constraint Processing, and CMSA roles. (Note that a USS providing CMSA for a UAS operation is required to also provide Strategic Coordination for the operation.) However, other implementations more limited in scope are possible. For example, a USS may implement only the Constraint Management role and be intended for use only by authorized constraint providers; or, a USS may implement only the Constraint Processing role to provide general airspace awareness to users independent of planning UAS flights. USSs may also provide additional, value-added capabilities and still be compliant with this specification as long as the value-added capabilities do not conflict with the services defined in this specification, and the implementation of services defined in this specification conforms to the applicable requirements. 1.7 A USS may also support other UTM roles such as Remote ID and airspace access (for example, the FAA’s LAANC), specified in other documents. 1.8 This specification addresses aspects common to all roles and services, such as Discovery and Synchronization Services (DSS), security, aud...
SIGNIFICANCE AND USE 7.1 This specification is intended to be used by USS developers, CAAs, and others to assess USS conformance with this UTM specification. SCOPE 1.1 This specification is intended to be a global specification providing components that may be used to satisfy requirements expected to be common to many UTM-related regulations. This specification is not intended to comprehensively address all aspects of any particular UTM-related regulation or concept of operations. Similarly, because varying terminology for the same concept is frequently used across different regulations, readers should not expect an exact terminology consistency with any particular UTM-related regulation. 1.2 This version of the specification is focused on strategic aspects of UAS operations, including strategic conflict detection, aggregate conformance of operations to their operational intents, constraint awareness, and situational awareness in the event of nonconforming or contingent operations. The intention is that this specification will evolve to address increasingly complex strategic aspects of UAS operations and potentially certain tactical aspects of UAS operations. 1.3 This specification addresses the performance and interoperability requirements, including associated application programming interfaces (APIs), for a set of UTM roles performed by UAS Service Suppliers (USSs) in support of UAS operations.2 Roles are groupings of one or more related UTM services. A competent authority may choose to use the roles defined in this specification in establishing the granularity of authorizations granted to a USS. The roles defined in this specification are: (1) Strategic Coordination, comprising the Strategic Conflict Detection and Aggregate Operational Intent Conformance Monitoring services; (2) Conformance Monitoring for Situational Awareness (CMSA); (3) Constraint Management, comprising the Constraint Management service; and (4) Constraint Processing, comprising the Constraint Processing service. 1.4 Section 4, Conceptual Overview, provides a description of each of the services and roles and includes further discussion on their scope. 1.5 A regulator may choose to require that a USS support a minimum or prescribed set of roles and services and may adopt terminology other than USS for a software system that provides something other than that minimum or prescribed set of roles and services. However, for purposes of this specification, a USS is a system that provides one or more of the UTM services defined in this specification. 1.6 A USS is not required by this specification to perform all roles or implement all defined services, providing business case flexibility for implementers. A typical USS that supports operators in the planning and execution of UAS operations may implement the Strategic Coordination, Constraint Processing, and CMSA roles. (Note that a USS providing CMSA for a UAS operation is required to also provide Strategic Coordination for the operation.) However, other implementations more limited in scope are possible. For example, a USS may implement only the Constraint Management role and be intended for use only by authorized constraint providers; or, a USS may implement only the Constraint Processing role to provide general airspace awareness to users independent of planning UAS flights. USSs may also provide additional, value-added capabilities and still be compliant with this specification as long as the value-added capabilities do not conflict with the services defined in this specification, and the implementation of services defined in this specification conforms to the applicable requirements. 1.7 A USS may also support other UTM roles such as Remote ID and airspace access (for example, the FAA’s LAANC), specified in other documents. 1.8 This specification addresses aspects common to all roles and services, such as Discovery and Synchronization Services (DSS), security, aud...
ASTM F3548-21 is classified under the following ICS (International Classification for Standards) categories: 17.040.01 - Linear and angular measurements in general. The ICS classification helps identify the subject area and facilitates finding related standards.
ASTM F3548-21 has the following relationships with other standards: It is inter standard links to ASTM F3060-20, ASTM F3060-16a, ASTM F3060-16, ASTM F3060-15b, ASTM F3060-15a, ASTM F3060-15, ASTM F3060-14. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
ASTM F3548-21 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
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.
Designation:F3548 −21
Standard Specification for
UAS Traffic Management (UTM) UAS Service Supplier (USS)
Interoperability
This standard is issued under the fixed designation F3548; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision.Anumber in parentheses indicates the year of last reapproval.A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope (3)Constraint Management, comprising the Constraint
Management service; and
1.1 Thisspecificationisintendedtobeaglobalspecification
(4)Constraint Processing, comprising the Constraint Pro-
providingcomponentsthatmaybeusedtosatisfyrequirements
cessing service.
expected to be common to many UTM-related regulations.
This specification is not intended to comprehensively address
1.4 Section 4, Conceptual Overview, provides a description
allaspectsofanyparticularUTM-relatedregulationorconcept
ofeachoftheservicesandrolesandincludesfurtherdiscussion
of operations. Similarly, because varying terminology for the
on their scope.
same concept is frequently used across different regulations,
1.5 Aregulator may choose to require that a USS support a
readers should not expect an exact terminology consistency
minimumorprescribedsetofrolesandservicesandmayadopt
with any particular UTM-related regulation.
terminology other than USS for a software system that pro-
1.2 This version of the specification is focused on strategic
vides something other than that minimum or prescribed set of
aspects of UAS operations, including strategic conflict
roles and services. However, for purposes of this specification,
detection, aggregate conformance of operations to their opera-
a USS is a system that provides one or more of the UTM
tional intents, constraint awareness, and situational awareness
services defined in this specification.
in the event of nonconforming or contingent operations. The
intention is that this specification will evolve to address 1.6 AUSSisnotrequiredbythisspecificationtoperformall
increasingly complex strategic aspects of UAS operations and roles or implement all defined services, providing business
potentially certain tactical aspects of UAS operations. case flexibility for implementers. A typical USS that supports
operators in the planning and execution of UAS operations
1.3 This specification addresses the performance and in-
may implement the Strategic Coordination, Constraint
teroperability requirements, including associated application
Processing, and CMSA roles. (Note that a USS providing
programming interfaces (APIs), for a set of UTM roles
CMSA for a UAS operation is required to also provide
performed by UAS Service Suppliers (USSs) in support of
Strategic Coordination for the operation.) However, other
UAS operations. Roles are groupings of one or more related
implementations more limited in scope are possible. For
UTM services. A competent authority may choose to use the
example, a USS may implement only the Constraint Manage-
rolesdefinedinthisspecificationinestablishingthegranularity
mentroleandbeintendedforuseonlybyauthorizedconstraint
of authorizations granted to a USS. The roles defined in this
providers; or, a USS may implement only the Constraint
specification are:
Processing role to provide general airspace awareness to users
(1)Strategic Coordination, comprising the Strategic Con-
independent of planning UAS flights. USSs may also provide
flict Detection andAggregate Operational Intent Conformance
additional, value-added capabilities and still be compliant with
Monitoring services;
thisspecificationaslongasthevalue-addedcapabilitiesdonot
(2)Conformance Monitoring for Situational Awareness
conflict with the services defined in this specification, and the
(CMSA);
implementation of services defined in this specification con-
forms to the applicable requirements.
This specification is under the jurisdiction of ASTM Committee F38 on
1.7 A USS may also support other UTM roles such as
UnmannedAircraftSystemsandisthedirectresponsibilityofSubcommitteeF38.02
Remote ID and airspace access (for example, the FAA’s
on Flight Operations.
Current edition approved Dec. 1, 2021. Published March 2022. DOI: 10.1520/
LAANC), specified in other documents.
F3548-21.
Many terms describe UTM and UAS Service Suppliers. For example, UTM is
1.8 Thisspecificationaddressesaspectscommontoallroles
referred to as U-Space, and USSs are referred to as U-Space Service Providers
and services, such as Discovery and Synchronization Services
(USSPs) in Europe. In the United Kingdom, UTM Service Providers (UTMSP) is
(DSS), security, auditing, and handling of off-nominal cases
used. In Japan, USSs are referred to as UAS Service Providers (UASSPs). Unless
otherwise stated, the terms are interchangeable in this specification. (for example, USS or DSS failures).
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
F3548−21
1.9 Additional services or enhancements to the current space information to USS, UAS personnel, or the operator’s
services will be added to subsequent versions of this specifi- automation,orcombinationsthereof.Incircumstanceswherea
cation. Appendix X2, Future Work Items, identifies a set of constraint is used to represent the volume within which a
these items. manned operation is planned, it provides a mechanism to
address the strategic separation of participating UAS from the
1.10 The safety case for this version of the specification,
manned flight. However, USS responsibility is limited to
summarized in Appendix X4, is limited to strategic
providing awareness of constraints, and it is the responsibility
deconfliction, which is accomplished using the services pro-
of the UAS personnel to comply with any regulatory aspect of
videdbytheStrategicCoordinationrole.Thisanalysisdoesnot
constraints.
constituteafullsafetycaseforanyparticularoperatororsetof
1.13 Applicability:
operations, which will have their own unique factors and
variables. It does help operators understand, however, the 1.13.1 This specification applies to operations conducted in
contributionofusingstrategicdeconflictiontotheirsafetycase a connected environment, meaning the UAS personnel have
and what the key variables are in increasing or decreasing the access to the USS (typically by means of the internet) and
contribution. Using assumptions similar to those documented connectivitytotheUnmannedAircraft(UA).Thisspecification
inAppendixX4,strategicdeconflictionreducestheprobability anticipatesandaccommodateslimitedgapsinconnectivity,but
of midair collisions by approximately two to three orders of does not purport to address operations in locations where
magnitude, with the rate of off-nominal events and participa- persistent connectivity is unavailable.
tion being the key variables. 1.13.2 Thisspecificationdoesnotpurporttoaddresstactical
conflicts between UAS. Notifications and data sharing require-
1.11 Of particular note, this version of this specification
ments in this specification associated with Strategic Conflict
does not establish requirements for fairness or equitable
DetectionandConformanceMonitoringforSituationalAware-
airspace access among UAS operations, but instead includes
ness may be useful in aiding some tactical conflict detection
requirements for the logging of information that will inform
and dynamic rerouting capabilities. However, those capabili-
future requirements in this area.
ties are beyond the scope of this specification, and an imple-
1.12 Usage:
mentation cannot assert compliance for tactical conflict detec-
1.12.1 In a region where participating UAS operators vol- tion or dynamic rerouting using this specification.
untarily agree to or are required by the competent authority to
1.13.3 This specification does not purport to address con-
comply with this specification, it enables strategically decon-
flicts between UAS and manned aircraft outside of instances
flicted UAS operations as well as situational awareness for
where a manned operation is encapsulated in a constraint.
operations that may not be required to be strategically decon-
1.13.4 This specification does not purport to address autho-
flicted. This specification is not dependent upon the use of
rization for UAS to operate in controlled or uncontrolled
segregated or nonsegregated airspace.
airspace.
1.12.2 For regions where this specification is required by a
1.13.5 This specification does not purport to address UAS
competent authority, this specification assumes regulations
that are not participating in UTM.
establishedbythecompetentauthority(oritsdelegate)identify
1.14 Relationship to Other International UTM Standards
any prioritization of operations and whether or not strategic
and Specifications:
conflicts are allowed between operations of the same priority.
1.14.1 It is an objective of this specification to be compat-
For example, it may be legal in some jurisdictions for recre-
ible with certain UTM specifications that address common
ational operations to share airspace and have overlapping
subject matter and are developed under other standards devel-
operational intents, relying on UAS personnel to coordinate
opment organizations (SDOs).
and maintain visual separation; whereas in other jurisdictions,
1.14.2 The existence of multiple specifications on the same
thismaynotbeallowed.Thespecificationtakesnopositionon
subject matter can occur when the regulatory environment in a
allowed or disallowed strategic conflicts. Instead it addresses
region requires that a necessary specification be developed by
requirementsforwhenconflictsareallowedbyregulations(for
a particular SDO. In these cases,ASTM International seeks to
example, notifications to involved USSs and UAS personnel)
establish a cooperation arrangement with the applicable SDO
and for when conflicts are not allowed (for example,
to ensure consistency between the related specifications.
replanning, inability to activate an operation with nonallowed
1.14.3 This specification also seeks to support an interna-
conflicts).
tional audience where differing regulatory requirements can
1.12.3 This specification is not intended to address the
exist. Where practical, this specification accommodates the
complete safety case for air collision risk. It provides a
differing requirements through a superset approach using a
mechanismtoaddressoneportionofasafetycase,specifically
varietyoftechniquessuchasoptionalfeaturesandfeaturesthat
the strategic separation of participating UAS from other
are configured to support a particular regulatory ruleset.
participating UAS. Other technologies or procedures, outside
1.14.4 A summary of related specifications and the tech-
the scope of this specification, may be required to mitigate air
niques used to achieve compatibility is provided in Appendix
risk with nonparticipating aircraft and to address other aspects
X3.
of a complete safety case for air collision risk.
1.12.4 Throughtheuseofconstraints,thisspecificationalso 1.15 The values stated in SI units are to be regarded as
provides awareness of geographically and time-limited air- standard.
F3548−21
1.15.1 Units of measurement included in this specification: 2.3 European Union (EU) Regulation:
GDPRGeneral Data Protection Regulation
cm centimeters
km kilometers
2.4 IETC Standards:
m meters
IETFRFC3339DateandTimeontheInternet:Timestamps
deg, ° degrees of latitude and longitude, compass direction
s seconds IETF RFC 5905NetworkTime ProtocolVersion 4: Protocol
Hz Hertz (frequency)
and Algorithms Specification
time unless otherwise specified, formatted in accordance with
IETF RFC 7519JSON Web Token (JWT)
IETF RFC 3339
2.5 ISO/IEC Standards:
1.16 Table of Contents:
ISO/IEC 9001Quality management systems — Require-
Title Section
ments
Scope 1
Referenced Documents 2
ISO/IEC 27001Information technology — Security tech-
Terminology 3
niques — Information security management systems —
Conceptual Overview 4
Requirements
Performance Requirements 5
Test Methods:
2.6 OAIC Document:
Scope 6
APPsThe Australian Privacy Principles
Significance and Use 7
Hazards 8
Test Units 9
3. Terminology
Procedure 10
3.1 Unique and Common Terminology:
Product Marking 11
Packaging and Package Marking 12
3.1.1 Terminology used in multiple ASTM UAS and
Precision and Bias 13
aircraft-related standards is defined in F3341, UAS Terminol-
Keywords 14
Table of Values Annex A1 ogy Standard, and F3060, Aircraft Terminology Standard.
Interoperability Requirements and DSS Testing Annex A2
Terminology unique to this specification is defined in 3.2.
USS-DSS and USS-USS OpenAPI YAML Description Annex A3
Reference Architectures for Interoperability Security Appendix X1
3.2 Definitions of Terms Specific to This Standard:
Controls
3.2.1 3D volume, n—a volume of airspace defined in terms
Future Work Items Appendix X2
of latitude, longitude, and altitude.
Compatibility with Related Standards Appendix X3
Safety Case for Strategic Deconfliction Appendix X4
3.2.2 4D volume, n—a 3D volume plus a start and end time
Failure Modes and Effects Analysis Appendix X5
for the volume.
UTM Ecosystem Testing Strategy Appendix X6
List of Working Group Participants and Contributors Appendix X7
3.2.3 Accepted, n—one of the operational intent states. See
Related Material
4.4 for more details.
1.17 This standard does not purport to address all of the
3.2.4 Activated, n—one of the operational intent states. See
safety concerns, if any, associated with its use. It is the
4.4 for more details.
responsibility of the user of this standard to establish appro-
priate safety, health, and environmental practices and deter-
3.2.5 authorized constraint provider, n—an organization or
mine the applicability of regulatory limitations prior to use.
individual that has been granted the authority to create and
1.18 This international standard was developed in accor-
manage constraints in a region by a competent authority.
dance with internationally recognized principles on standard-
3.2.6 Aggregate Operational Intent Conformance
ization established in the Decision on Principles for the
Monitoring, n—a USS service that monitors an operator’s
Development of International Standards, Guides and Recom-
aggregate conformance with operational intents over time to
mendations issued by the World Trade Organization Technical
ensure the target level of safety for strategic coordination is
Barriers to Trade (TBT) Committee.
being met. Operators could also implement their own Aggre-
gate Operational Intent Conformance Monitoring capability.
2. Referenced Documents
3.2.7 coordinated operational intent, n—an operational in-
2.1 ASTM Standards:
tent that has been coordinated with other relevant USSs to
F3060Terminology for Aircraft
prevent disallowed conflicts. Operational intents are required
F3341Terminology for Unmanned Aircraft Systems
to be coordinated prior to transitioning to the Accepted state
F3411Specification for Remote ID and Tracking
2.2 EUROCAE Standard:
Available from https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/
EUROCAE ED-269Minimum Operational Performance
?uri=CELEX:32016R0679.
Standard for UAS Geo-Fencing
Available from IETF Administration LLC, 1000 N West Street, Suite 1200,
Wilmington, DE 19801.
Visit https://datatracker.ietf.org/doc/html/rfc3339.
Visit https://tools.ietf.org/html/rfc5905.
3 9
For referenced ASTM standards, visit the ASTM website, www.astm.org, or Visit https://tools.ietf.org/html/rfc7519.
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM Available from International Organization for Standardization (ISO), ISO
Standards volume information, refer to the standard’s Document Summary page on Central Secretariat, Chemin de Blandonnet 8, CP 401, 1214 Vernier, Geneva,
the ASTM website. Switzerland, https://www.iso.org.
4 11
Available from European Organisation for Civil Aviation Equipment Available from Office of the Australian Information Commissioner, 175 Pitt
(EUROCAE), 9-23 rue Paul Lafargue, “Le Triangle” building, 93200 Saint-Denis, Street, Sydney NSW 2000, Australia, https://www.oaic.gov.au/__data/assets/pdf_
France, https://www.eurocae.net/. file/0006/2004/the-australian-privacy-principles.pdf.
F3548−21
and to the Activated state (including transitioning from the 3.2.19 DSS pool, n—a synchronized set of DSS instances
Nonconforming state back to the Activated state). where operations may be performed on any instance with the
sameresult,andinformationmaybequeriedfromanyinstance
3.2.8 conflict, n—a situation where two operational intents
with the same result. A DSS region will often have a produc-
intersect both in space and time. For operational intents to
tion DSS pool along with one or more test or staging DSS
intersect both in space and time, at least one 4D volume from
pools.
each operational intent must intersect. For two 4D volumes to
intersect, the spatial dimensions of the 4D volumes must share
3.2.20 DSS region, n—the geographic area supported by a
at least one point and the start/end time range for the two 4D DSS pool.
volumes must overlap.
3.2.21 Ended, n—one of the operational intent states. See
3.2.9 conformance, n—a situation where a UA is flying
4.4 for more details.
according to its Activated operational intent. A UA flying
3.2.22 entity, n—a generic term referring to types of data
inside of its Activated operational intent is in conformance. A
thatneedtobesharedbetweenUSSs.Thisspecificationdefines
UA flying outside of its Activated operational intent is non-
operational intent and constraint entities.
conforming or contingent.
3.2.23 entity reference, n—limited information about an
3.2.10 Conformance Monitoring for Situational Awareness,
entity (including the approximate location and contact details
n—a USS role and service that determines whether a UAis in
for the managing USS) that is stored in the DSS and supports
conformance with its operational intent on behalf of the
the discovery process.
operator or accepts self-reported conformance data from the
3.2.24 fail-safe, n—denotes a situation where the failure of
UAS or operator. The service also initiates the sharing of
asystemsoftwareorhardwarecomponentorinterfacedoesnot
situational awareness data with relevant USSs when noncon-
result in an unsafe condition. Note that in a fail-safe situation,
forming or contingent situations occur.
a loss of service may occur. (For example, operational intents
3.2.11 Contingent, n—one of the operational intent states.
cannot be activated if the associated USS is down.)
See 4.4 for more details.
3.2.25 lowest bound priority status, n—a priority status
3.2.12 constraint, n—one or more 4D volumes that inform
value that is lower than the lowest priority bound defined by
USSs,UASpersonnel,operator’sautomationsystems,orother
the regulator for the strategic conflict detection prioritization
stakeholders, or combinations thereof, about specific geo-
schema.Forexample,iftheregulatorassigns“0”asthelowest
graphicallyandtime-limitedairspaceinformation.Aconstraint
priority value for an operation that is subjected to strategic
may restrict access to airspace for some or all operations, or it
conflict detection prioritization, then a negative integer would
may be informational.
be an acceptable value to assign as the lowest bound priority
3.2.13 constraint intersection, n—a situation where an op-
status.
erationalintentandaconstraintoverlapinbothspaceandtime.
3.2.26 managing USS, n—the USS responsible for an op-
This is similar to operational intent conflicts, but conflicts is
erational intent from creation (that is, successfully transitioned
deliberately not used because a constraint may not restrict
to theAccepted state) or a constraint, including activities such
access to airspace.
as making it discoverable through the DSS, providing associ-
3.2.14 Constraint Management, n—a USS service and role
ated details when requested by other relevant USSs, and
that supports the creation, modification, and deletion of
making modifications. In the context of Conformance Moni-
constraints, as well as the dissemination of constraint informa-
toring for Situational Awareness, the managing USS monitors
tion to other USSs.
position reports and operator reports of nonconformance by
3.2.15 Constraint Processing, n—a USS service and role
means of approved methods.
that enables the USS to ingest constraint information and relay
3.2.27 non-coordinated operational intent, n—an opera-
it to the UAS personnel, operator’s automation systems, or
tional intent that has not been coordinated with other relevant
other stakeholders, or combinations thereof, for applicable
USSs and may contain disallowed conflicts. This situation
operations.
occurs for operational intents with off-nominal 4D volumes.
3.2.16 discovery, n—the process of determining the set of
3.2.28 Nonconforming, n—one of the operational intent
USSs with which data exchange is required for some UTM
states. See 4.4 for more details.
function;discoveryisaccomplishedbymeansofthediscovery
3.2.29 off-nominal, adj—in the context of this specification,
and synchronization service (DSS).
refers to situations where an operational intent is in the
3.2.17 Discovery and Synchronization Service (DSS), n—a
Noncoforming or Contingent states.
service defined in this specification that enables USSs to
3.2.30 off-nominal 4D volumes, n—4D volumes that char-
discover other USSs with which data exchange is required and
acterize where and when a UAis expected to travel while it is
to ensure that USSs use current and consistent entity data.
off-nominal. Off-nominal 4D volumes may reflect a specific
3.2.18 DSS instance, n—for availability purposes, multiple
route of flight when known, or a broader area when a specific
synchronizedcopiesoftheDSSsupportingaDSSregion.Each
route of flight is not known.
copy is referred to as a DSS instance. USSs can interact with
any DSS instance within a pool and switch over to any other 3.2.31 opaque version number (OVN), n—unique value
instance in the event of a failure. associated with a version of an entity, updated when the entity
F3548−21
is modified. OVNs are used to ensure that USSs have the establishedasubscriptionforoperationalintentsorconstraints,
current version of entities. or both, in an area where it may not yet manage operational
intents.
3.2.32 operational intent, n—avolume-basedrepresentation
3.2.38 Strategic Conflict Detection, n—a USS service that
of the intent for a UAS operation; comprises one or more
determines if an operational intent conflicts with other opera-
overlappingorcontiguous4Dvolumes,wherethestarttimefor
tional intents. The process of detecting conflicts by comparing
each volume is the earliest entry time, and the stop time for
operational intents. In contrast, tactical conflict detection
each volume is the latest exit time. Volumes are constructed
generally relies on nonstrategic information such as current
based on the performance of the UAS and represent the
location, heading, and speed.
airspace to which a UAmust conform to a sufficient degree to
achieve a target level of safety for strategic deconfliction. An
3.2.39 Strategic Conflict Resolution, n—the process of re-
operational intent’s volumes normally indicate the intent for solving conflicts through the modification of operational in-
the operation in the Accepted and Activated states. However, tents. Although there is no absolute time threshold, strategic
conflictresolutionrequiressufficienttimebeforetheconflictto
an operational intent is supplemented with off-nominal 4D
generate, coordinate, and implement the modification to the
volumes when in the Nonconforming or Contingent states.
operational intent.
Strictly speaking, off-nominal 4D volumes do not represent
intent, but the underlying structure of operational intents (4D
3.2.40 Strategic Coordination, n—a USS role comprising
volumes)andthemechanismsfordiscoveryandnotificationof
the Strategic Conflict Detection and Aggregate Operational
relevant USSs and operations makes the operational intent a
Intent Conformance Monitoring services.
convenient vehicle for conveying the necessary information in
3.2.41 Strategically Coordinated, adj—refers to an opera-
off-nominal situations.
tional intent that has been constructed with awareness of other
3.2.33 operator, n—the person or organization that applies relevant operational intents and has no disallowed conflicts.
for CAAapproval to operate a UAS or who seeks operational
3.2.42 subscription, n—a DSS mechanism that allows a
approvalfortypesofflightoperationsprohibitedbyaCAAfor
USS to be notified and provided the details of any new,
that UAS.
modified, or deleted entities in a specified area of interest
defined by a 4D volume.
3.2.34 operator’s automation, n—optional automation used
by an operator to handle aspects of UAS operations during the
3.2.43 UASpersonnel,n—referstoanypersonnelassociated
preflight, in-flight, or postflight timeframe that otherwise
with a UAS operation, including the operator, the remote pilot
would be performed by UAS personnel. The scope of func-
in charge, and other personnel who may perform preflight,
tionality is operator-dependent. Operator’s automation may
in-flight, or postflight activities. This generic reference to
interact with a USS instead of UAS personnel. personnel is frequently used in order to avoid incorrect
assumptions about the activities carried out by any particular
3.2.35 position data, n—information provided by a UAS
role in an operator’s organization.
that describes the location of an unmanned aircraft, including
3.2.44 UAS Service Supplier (USS), n—for purposes of this
its latitude, longitude, altitude, and the time the unmanned
specification, a USS is an entity that provides one or more of
aircraft was at the location.
the UTM services defined in this specification.
3.2.36 relevant operational intent, n—an operational intent
3.2.45 UAS Traffıc Management (UTM), n—a federated set
that overlaps or is in close proximity to another operational
of services operated under regulatory oversight that support
intent. Close proximity versus strict overlapping is included
safe and compliant UAS operations.
because the DSS defined in this specification does not deter-
mine intersection using the precise 3D extents of operational 3.2.46 UAS Zone (alt. UAS Geographical Zone), n—the
intents (or constraints), but instead using a coarser representa- terms used in EUROCAE ED-269, Minimum Operational
Performance Standard for UAS Geo-Fencing, for what are
tion. The coarser representation results in actual intersections
always being detected, but also in the occasional identification defined as constraints in this specification. (From ED-269, a
UAS zone is an airspace of defined dimensions, above the land
of operational intents that are merely close to each other. (This
areas or territorial waters of a state, within which a particular
concept also applies to constraints.) The distance that qualifies
restriction or condition for UAS flights applies.)
as in close proximity is not fixed, but depends on the
configuration of the DSS airspace representation. See Annex
3.2.47 User notification, n—informationprovidedbyaUSS
A2 for further detail.
to UAS personnel or to an operator’s automation system, or
both. Because UAS-related concepts of operations can vary
3.2.37 relevant USSs, n—(a) USSs that manage operational
widely from operator to operator, this specification does not
intentsorconstraints,orboth,that,duetotheirproximity,must
mandate a particular form for a user notification; possible
be evaluated by the Strategic Conflict Detection or the Con-
implementations include messages or graphical indications
straint Processing service, or both, of a USS attempting to
through a user interface; text messages; email; and system to
create or modify an operational intent; (b) USSs that manage
system messages.
operational intents that, due to their proximity, are potentially
affected by a Nonconforming or Contingent operational intent
3.2.48 Unmanned Aircraft System (UAS), n—composed of
or a new or modified constraint; or, (c) a USS that has unmanned aircraft (UA) and all required on-board subsystems,
F3548−21
payload, control station, other required off-board subsystems, 3.3.34 UASSP, n—unmanned aircraft system service pro-
anyrequiredlaunchandrecoveryequipment,allrequiredcrew vider
members, and communication links.
3.3.35 USS, n—UAS service supplier
3.2.49 USS network, n—the set of USSs operating collab-
3.3.36 USSP, n—U-Space service provider
oratively in a region.
3.3.37 UTM, n—UAS traffic management
3.2.50 USS role, n—a grouping of one or more USS
3.3.38 UTMSP, n—UTM service provider
Services. USS roles may be used by a competent authority to
3.3.39 VLOS, adj—visual line of sight
establishthegranularityofauthorizationsthatcanbegrantedto
a USS. Roles are also used within this specification to indicate
3.3.40 YAML, n—YAML ain’t markup language
services that should be provided together.
3.2.51 USS service, n—a UTM-related function performed
4. Conceptual Overview
by a USS.
4.1 This section provides a conceptual overview for the
3.3 Acronyms and Abbreviations:
services defined in this specification. No requirements are
3.3.1 3D, adj—three dimensional
provided in this section.
3.3.2 4D, adj—four dimensional
4.2 Scope of Standard:
3.3.3 AFIT, n—Air Force Institute of Technology 4.2.1 The scope of this specification is delineated by the
dotted purple box in Fig. 1. The four USS roles defined in this
3.3.4 AIRAC, n—aeronautical information regulation and
specification are identified by bold text: Strategic
control
Coordination, Conformance Monitoring for Situational
3.3.5 ANSP, n—air navigation service provider
Awareness, Constraint Management, and Constraint Process-
3.3.6 AOI, n—area of interest
ing. A USS may support all or a subset of the roles.
4.2.2 The USS indicated by the central, blue rectangle in
3.3.7 API, n—application programming interface
Fig. 1 contains three roles: Strategic Coordination, Confor-
3.3.8 BVLOS, adj—beyond visual line of sight
mance Monitoring for Situational Awareness, and Constraint
3.3.9 C2, n—command and control
Processing.
3.3.10 CAA, n—civil aviation authority
4.2.3 Strategic Coordination is composed of two services:
Strategic Conflict Detection and Aggregate Operational Intent
3.3.11 CMSA, n—conformance monitoring for situational
Conformance Monitoring.
awareness
4.2.4 StrategicConflictDetectionisusedtocompareopera-
3.3.12 DAA, n—detect and avoid
tional intents to detect conflicts. It is used in the context of a
3.3.13 DAR, n—DSS airspace representation
flight planning or authorization service in which a USS
3.3.14 DSS, n—discovery and synchronization service
discovers or is informed of relevant operational intents and
attemptstoconstructaconflict-freerouteforanewormodified
3.3.15 EMI, n—electromagnetic interference
operational intent. (Aplanning or authorization service includ-
3.3.16 FMEA, n—failure modes and effects analysis
ingconflictresolutionisbeyondthescopeofthisspecification.
3.3.17 FTE, n—flight technical error
Further,itisdeliberatethatStrategicConflictDetectiondetects
3.3.18 ISMS, n—information security management system
conflicts rather than resolves conflicts. The manner in which a
USS finds a conflict-free route during planning or resolves a
3.3.19 LAANC, n—low altitude authorization and notifica-
conflict that arises does not need to be prescribed and should
tion capability
allow for innovation. There will be cases where a conflict-free
3.3.20 MAC, n—midair collision
route cannot be found. During the preflight period, this results
3.3.21 NSE, n—navigation system error
insomeoperationsnotbeingabletobeaccepted.Duringflight,
3.3.22 OIV, n—operational intent volume this results in situations where tactical avoidance methods or
some other form of arbitration are required. These are beyond
3.3.23 OVN, n—opaque version number
the scope of this specification.)
3.3.24 PBN, n—performance-based navigation
4.2.5 Strategic Conflict Detection assumes certain regula-
3.3.25 PII, n—personally identifiable information
tions are established by the competent authority (or its del-
3.3.26 SDO, n—standards development organization egate) that guide the evaluation and processing of conflicts.
These regulations include the identification of priorities of
3.3.27 SMS, n—safety management system
operations and whether or not conflicts are allowed to exist
3.3.28 TBO, n—trajectory-based operations
withinagivenprioritylevel.Alowerpriorityoperationmustbe
3.3.29 TLS, n—target level of safety
planned not to conflict with a higher priority operation. Where
conflicts are allowed within the same priority level, notifica-
3.3.30 TSE, n—total system error
tions are provided to the USSs and UAS personnel and/or the
3.3.31 TTL, n—time to live
operator’s automation for both UAS. Where conflicts are not
3.3.32 UA, n—unmanned aircraft
allowed within the same priority level, the first-planned opera-
3.3.33 UAS, n—unmanned aircraft system tion is given priority over subsequent operations.
F3548−21
FIG. 1Scope of Standard
4.2.6 When determining whether an operational intent is CMSA data for tactical purposes is beyond the scope of this
conflict free, Strategic Conflict Detection must consider other specification, and the specification takes no position on the
operational intents in the same vicinity. Some of the opera- usefulness of the data for those purposes.
tional intents may be managed by other USSs referred to as
4.2.9 There are many possible methods to implement con-
other relevant USSsanddenotedbythegreenbox(upperright)
formance monitoring to detect nonconformance that fall into
in Fig. 1. The operational intents are discovered through a
one of two categories: USS-provided methods and operator-
standardized service (the Discovery and Synchronization
provided methods approved by the competent authority. This
Service, or DSS), and relevant operational intents are shared
specification defines one USS-provided method based on
through standardized APIs. Mechanisms are also provided in
monitoring of position reports from a UAS (position report-
the standardized APIs and DSS to ensure that a USS has the
baseddetectionofnonconformance).AdditionalUSS-provided
current version of all relevant operational intents.
methods may be added to future versions of this specification.
4.2.7 Aggregate Operational Intent Conformance Monitor-
This specification also allows for the use of approved operator
ing determines if operators are conforming with their opera-
detection methods.
tionalintentsovertime.Thisverificationisnecessarytoensure
4.2.10 Detection of nonconformance based on position
that the target level of safety intended to be achieved through
reports is accomplished by comparing ongoing position data
strategically deconflicting operational intents is being met. If
for a UA in flight with the associated operational intent.
anoperatorischronicallynotinconformance,itcouldindicate
Position data comes from the UAS. The absence of position
a problem such as incorrect construction of the operational
data is also taken into consideration. If the position data
intents, incorrect characterization of UA performance
indicate the UA is within the Activated operational intent, the
characteristics, or an issue with some aspect of the operator’s
operation is considered in conformance; if the position data
operating procedures. Performance notifications are provided
indicates the UAis not within theActivated operational intent
to the operator when aggregate conformance is inadequate.
or is not received over a time threshold, the operation is
4.2.8 Conformance Monitoring for SituationalAwareness is
considered nonconforming.
aroleandservice.Itsprimaryfunctionistoprovidesituational
4.2.11 If an aircraft remains Nonconforming beyond a
awareness to relevant USSs and UAS personnel or the opera-
prescribed time threshold, the operational intent transitions to
tor’s automation when a UA is not in conformance or has
the Contingent state and cannot return to the Activated state.
becomecontingent.Thisinformationcanbeusedbyarelevant
(States of operations are discussed in greater detail in 4.4.)
USS for strategic planning purposes (for example, avoiding
airspace where a contingent UA is located). In the future, 4.2.12 Approved methods for operator detection of noncon-
CMSA may support ground-based tactical conflict avoidance formance is acceptable and necessary in certain operational
capabilities, but in this version of this specification, any use of environments.Forexample,someoperationsmaytakeplacein
F3548−21
an environment where the C2 link over which position infor- constraints. Second, a USS may ingest constraints strictly for
mation would normally be received is unavailable due to EMI the purpose of providing geo-awareness to interested parties.
4.2.18 To achieve interoperability, all interfaces contained
or signal blocking (for example, an operation inside an
electrical transmission tower, in a tunnel or pipe, or under a in the dotted purple box denoting the scope of the standard are
standardizedandspecifiedinthisdocument.SeeAnnexA2and
bridge). In such cases, visual confirmation of conformance
Annex A3 for additional details, including an overview of the
combined with an appropriate operator interface to the USS to
interoperability paradigm comprising the DSS and USS peer-
communicate conformance or nonconformance could be used.
to-peer interfaces.
Alternatively, a UAmay have approved onboard conformance
4.2.19 Interfaces that traverse the dotted purple box for
monitoring capabilities as well as methods to mitigate noncon-
communicationwithsystemsorpeopleexternaltothescopeof
formancesuchasautonomouscoursecorrectionorgeofencing,
the standard are predominantly left to the discretion of the
or both, in combination with DAA. In such cases, the operator
implementer. For example, this specification does not mandate
may only need to communicate failures of the onboard
a particular interface for how position data is received from an
capabilities to the USS. This specification does not specify
aircraft. However, the specification does levy requirements on
requirements for all possible operator detection of nonconfor-
these interfaces pertaining to basic function, security, and
mancemethodsornonconformancemitigationcapabilities,but
response times.
does permit their use provided the operator obtains approval
for the method from the competent authority.
4.3 Operational Intents and Off-Nominal 4D Volumes:
4.3.1 Anoperationalintentisavolume-basedrepresentation
4.2.13 Regardless of the method used to detect nonconfor-
of a UAS flight used to define the airspace and time bounds
mance to provide situational awareness to relevant USSs and
intended to contain the flight.An operational intent comprises
operators, for both Nonconforming and Contingent cases, the
a set of one or more contiguous or overlapping 4D volumes
managing USS is required to add off-nominal 4D volumes to
that define the horizontal and vertical bounds of airspace and
the operational intent. Relevant USSs that have operational
the corresponding volume start and end times (which corre-
intents that conflict with or are in close proximity to the
spond to the earliest entry time and latest exit time, respec-
updated Nonconforming or Contingent operational intent are
tively) to which the flight is intended to conform. Operational
notified and can use the off-nominal 4D volumes to inform
intents can represent diverse operations including, but not
actions they deem necessary.
limited to, starting/stopping on the surface and starting/
4.2.14 In addition, if position report data are available for a
stopping in the air. Operational intents are key inputs to the
nonconforming or contingent UA, relevant USSs may request
Strategic Conflict Detection, Aggregate Operational Intent
the data. (This data can only be requested by a relevant USS
Conformance Monitoring, and CMSA services.
while the UA is nonconforming or contingent. In some cases,
4.3.2 The use of a volume-based representation of UAS
suchasafailedC2link,thepositiondatawillnotbeavailable.)
flights draws on the ICAO definition of strategic deconfliction
4.2.15 The third role shown in the large blue rectangle is
as “a service consisting of the arrangement, negotiation and
Constraint Processing. It is a counterpart to the Constraint
prioritization of intended operational volumes, routes or tra-
Management role shown in the red box at the bottom.
jectories of UAS operations to minimize the likelihood of
4.2.16 AconstraintinformsUASpersonnelortheoperator’s
airborne conflicts between operations.” A volume-based
automation, or both, about specific geographically and time- approach has been widely used in international UTM research,
limited airspace information. The Constraint Management trials, and live operations for several years. Benefits of this
service allows an authorized constraint provider to create, approach are discussed further below.
modify, and delete constraints. (The specification supports one 4.3.3 Operational intent 4D volumes are constructed based
on the performance of the UAS and represent the airspace to
or more USSs performing the Constraint Management role in
a region.) Once a constraint is created or modified and made which a UA must conform to a sufficient degree to achieve a
target level of safety for strategic deconfliction. The perfor-
discoverable through the DSS, the associated USS performing
mance of a UA can vary throughout the flight depending on
the Constraint Management role must also support requests
what the UA is doing, such as taking off, operating at cruise
from other relevant USSs for information about the constraint,
altitude, hovering, or landing. The operator may also enhance
as well as proactively send a notification to other USSs that
the performance of the UA in certain locations through
have operational intents or subscriptions that intersect the new
augmentations to the operational environment, such as the use
or modified constraint.
of supplemental navigational aids to improve navigation per-
4.2.17 TheConstraintProcessingserviceinthecentral,blue
formance.Consequently,theperformance-basedhorizontaland
rectanglerepresentstheconsumersideofconstraints.Thereare
vertical buffering may vary across the 4D volumes comprising
two use cases for Constraint Processing. First, USSs ingest the
an operational intent.
constraints from the Constraint Management service so that
intersections with operational intents can be detected, and the
associated 4D information can be communicated to UAS
Unmanned Aircraft Systems Traffıc Management (UTM) – A Common Frame-
personnel or the operator’s automation, or both, to inform
work with Core Principles for Global Harmonization, Edition 3, ICAO, September
operational intent creation, modification, or deletion. Mecha-
2020, p. 11, https://www.icao.int/safety/UA/Pages/UTM-Guidance.aspx, and
nisms are also provided in the standardized APIs and DSS to
https://www.icao.int/safety/UA/Documents/
ensure that a USS has the current version of all relevant UTM%20Framework%20Edition%203.pdf.
F3548−21
4.3.4 The intention of this specification is that the volumes is a combination of the Path Definition Error (PDE), Flight
are constructed (both spatially and temporally) in accordance TechnicalError(FTE),andNavigationSystemError(NSE),as
with the minimum dimensions and time values appropriate for is illustrated in Fig. 2. Note that this example is similar to the
the target level of safety. Volumes that are larger or occupy TSEfoundinPerformanceBasedNavigation(PBN);however,
more time than necessary could adversely impact airspace a key difference is that TSE in this standard is a preflight
efficiency. measure, whereas TSE is an in-flight, dynamic measure in
4.3.5 Operational intents generally fall into one of two PBN.
categories: area-based or trajectory-based; however, it is pos- 4.3.9 For UAS operations, the operational intent creation
sible that one operational intent has both area-based and can be composed of errors associated with the ability of the
trajectory-based 4D volumes.An area-based operational intent Flight Management System (FMS) to follow a lateral path,
doesnotrequireadesiredflightpat
...




Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...