Ensaio 2

• Modelagem de Processos - Autorização de Voo por Provedores
• Briefing: BR-UTM Field Test 2

Modelagem de Processos - Autorização de Voo por Provedores

O processo habitual de autorização de voo por provedores deve seguir o seguinte fluxo:

Fluxo de Autorização e Ativação de  Voo

---

Autorização de Voo

O processo de Autorização de Voo (P1) é a primeira etapa do desconflito estratégico de uma operação com drone. O processo começa com um pedido do operador. Esse pedido deve seguir um padrão (ainda não definido), e esse padrão deve ser validado pelo provedor USS. Após, o provedor deve realizar a checagem de desconflito estratégico, e por fim cadastrar o novo voo no ECO-UTM. Caso alguma checagem falhe, o provedor deve notificar o operador dessa falha. É permitido, porém não obrigatório, que o USS sugira alternativas para o operador em casos de rejeição.

P1 - Autorização de Voo

P1.1 - Desconflito Estratégico

---

Ativação de Voo

Após ter seu voo aprovado, o operador deve solicitar a ativação do voo instantes antes de sua execução. Nessa etapa, o provedor deve garantir que a autorização de voo continua válida, e que as condições de voo (condições ainda não definidas) permitem a realização segura do voo. Após a checagem, o USS notifica o operador que ele pode inicar a operação. 

Então, o provedor aguarda notificação do operador sobre o encerramento da operação. Recebendo a notificação, o operador deve encerrar o plano de voo no ECO-UTM.

P2 - Ativação de Voo

---

Mudanças Dinâmicas

No período entre a autorização e a ativação, pode ocorrer mudanças nas condições do espaço aéreo, como uma nova restrição ou um novo voo com maior prioridade. Nesses casos, é de suma importância que o USS notifique o operador dessa atualização, para evitar frustrações do operador na hora da ativação do voo.

P3 - Mudanças Dinâmicas

---

Emergência

WIP

Briefing: BR-UTM Field Test 2

Document Version: 1.2 Date: June 16, 2025

1. Introduction & Vision

The BR-UTM Field Test 1 successfully validated the foundational capabilities of our Discovery and Synchronization Service (DSS), based on the InterUSS platform. Participants demonstrated the ability to perform basic strategic deconfliction of Operational Intent References (OIRs) and deconfliction from static Constraints.

This Second Field Test will expand upon that foundation, introducing critical new capabilities to validate the complete, end-to-end operational lifecycle. The vision is to simulate a real-world operational environment where multiple UAS Service Suppliers (USS) coordinate flights, and operators conduct live drone operations based on these coordinated intents.

1.1. New Features for Validation

This test will validate all previously tested features, plus the following crucial additions:

• USS-to-USS Authentication: Secure, token-based authentication for all inter-USS communication.

• OIR Activation & State Management: The full lifecycle of an OIR, including the transition to an "activated" state just before flight.

• Priority Operations: Handling of high-priority flights that may require other operations to adjust.

• Remote Identification (Remote ID): Integration of Remote ID information services into the USS workflow.

• In-Flight Contingency Management: Real-time response to dynamic, high-priority airspace constraints that appear during an active flight.

2. Core Objectives

The primary goals of this field test are to:

1. Validate End-to-End OIR Lifecycle: Demonstrate the complete process of creating, strategically deconflicting, activating, and closing out OIRs in a multi-USS environment.

2. Verify Secure Inter-USS Coordination: Ensure all participants can successfully implement and use the specified authentication protocols for all DSS and peer-to-peer USS interactions.

3. Test Advanced Strategic Deconfliction: Validate the system's ability to manage and resolve conflicts between multiple OIRs, including those with different priorities.

4. Demonstrate OIR Activation: Ensure that the transition of an OIR to its "activated" state is correctly propagated and managed by all relevant USSs.

5. Validate Priority Handling: Successfully manage the introduction of a high-priority OIR, requiring other active or planned operations to be modified or cleared.

6. Integrate Remote ID Services: Demonstrate that USSs can support the provision of Remote ID data for active flights to authorized entities.

7. Conduct Live Flight Operations: Have operators fly drones based on successfully coordinated and activated OIRs, proving the link between the digital UTM system and real-world flight.

3. Technical Architecture & Protocols

The core of the technical architecture remains the DECEA-provided Discovery and Synchronization Service (DSS), which is an implementation of the InterUSS Platform.

• API Contracts: All participants must implement the server-side and client-side portions of the API contracts defined in the dp-icea/Protocols GitHub repository. This is the single source of truth for all required interfaces.

• DSS Implementation: For context and documentation on the underlying technology, refer to the interuss/dss GitHub repository.

3.1. Authentication

Authentication is mandatory for all inter-USS and DSS API calls. The process is detailed in the workshop documentation [Desconflito][Autenticação] Roteiro Etapa 1.

• Token Generation: Before making a request to another USS, you must first request a JSON Web Token (JWT) from the DECEA authentication service. The intended_audience and scope parameters are critical.

• Token Validation: When your USS receives a request, you must validate the incoming JWT. This involves:

  1. Verifying the token's signature using the Eco-UTM public key.

  2. Checking the token's expiration time (exp).

  3. Confirming the audience (aud) matches your USS identifier.

  4. Ensuring the token contains the required scope for the requested endpoint.

3.2. Governing Standards

This field test will adhere to the following international standards, which form the basis of the technical and operational protocols:

• UTM Interoperability: All strategic coordination and information exchange between USSs shall be conducted in accordance with ASTM F3548-21, "Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability."

• Remote ID: The implementation and data formats for Network Remote ID services shall follow ASTM F3411-22a, "Standard Specification For Remote ID And Tracking."

4. Participant Roles & Responsibilities

Participants can choose to act in one or both of the following roles:

• USS Provider: An entity running a software implementation that provides UAS services.

  • Responsibilities:

    • Implement the full API contract.

    • Integrate with the authentication service.

    • Connect to the central DSS to discover other operations and publish their own.

    • Manage the full lifecycle of OIRs on behalf of their operator clients.

    • Coordinate directly with other USSs for strategic deconfliction.

    • Provide an endpoint for other USSs to subscribe to updates for OIRs they manage.

• Drone Operator: An entity that plans and executes drone flights.

  • Responsibilities:

    • Partner with a registered USS Provider for flight planning.

    • Conduct pre-flight checks.

    • Execute the flight mission precisely according to the activated OIR (trajectory, altitude, and time).

    • Equip the drone with the necessary hardware for Remote ID broadcast.

    • Maintain communication with the USS during flight and be prepared to act on in-flight instructions, including immediate termination of the operation.

5. Test Scenarios

The field test will be structured around a series of progressively complex scenarios.

Scenario 1: Nominal Coordination and Flight Activation

• Objective: Validate the basic workflow, authentication, and OIR activation.

• Execution:

  1. Two or more USS providers will each create a distinct, non-conflicting OIR in the DSS.

  2. Just prior to the scheduled flight time, each USS will update their OIR state to Accepted and then Activated. They must notify any subscribers of this change.

  3. The corresponding Drone Operator will execute the flight.

  4. During the flight, the drone will broadcast Remote ID data.

  5. Upon completion, the USS will update the OIR state to Ended.

Scenario 2: Strategic Deconfliction with a Constraint

• Objective: Validate conflict detection and resolution against a static geographical constraint.

• Execution:

  1. The DSS will be pre-populated with a Constraint (e.g., a no-fly zone).

  2. A USS will attempt to create an OIR that partially overlaps with the constraint.

  3. The USS must identify the conflict by querying the DSS.

  4. The USS must then modify the OIR's geometry to remove the conflict before it can be successfully created and activated.

  5. The Operator will fly the deconflicted mission.

Scenario 3: Inter-USS Deconfliction & Negotiation

• Objective: Validate peer-to-peer coordination to resolve a conflict between two OIRs.

• Execution:

  1. USS-A creates and submits a valid OIR to the DSS.

  2. USS-B attempts to create an OIR whose 4D volume overlaps with USS-A's OIR.

  3. USS-B's initial attempt to create the OIR in the DSS should fail due to the conflict.

  4. USS-B must query the DSS, identify the conflicting OIR from USS-A, and initiate a strategic negotiation (as defined by the ASTM standard, though this may be a manual coordination step for the test).

  5. One or both USSs will adjust their OIRs to resolve the conflict.

  6. Once resolved, both OIRs can be created and subsequently activated for flight.

Scenario 4: Priority Operation (Pre-Flight)

• Objective: Validate the system's response to a high-priority flight identified during the planning phase.

• Execution:

  1. Multiple "standard" priority OIRs are planned or active in the DSS.

  2. A designated USS (the "Emergency Services USS") will introduce a new OIR with priority set higher than the others (e.g., for a simulated medical delivery or security overwatch). This OIR will overlap with existing standard operations.

  3. Other USSs must detect this high-priority OIR and are required to modify or cancel their own conflicting operations to clear the area.

  4. The high-priority flight is then activated and flown.

Scenario 5: In-Flight Contingency - Dynamic Constraint

• Objective: Validate a USS's ability to monitor for new conflicts during an active flight and instruct the operator to take immediate, appropriate action.

• Execution:

  1. USS-A has an OIR in the Activated state, and its Operator is conducting the flight.

  2. An "Emergency Services USS" creates a new, high-priority Constraint or OIR that dynamically appears and conflicts with USS-A's active flight volume.

  3. USS-A must detect this new, superseding conflict in near real-time by monitoring the DSS or receiving a notification from a subscription.

  4. Upon detecting the unmitigable conflict, USS-A must immediately relay a command to its Drone Operator to cease the operation.

  5. The Operator must comply with the instruction and safely terminate the flight (e.g., land immediately or execute a pre-planned return-to-launch maneuver).

  6. USS-A updates its OIR state to Ended to reflect the early termination of the flight.

6. Operational Safety Considerations

To ensure the safety of all participants and the public, the following operational rules are mandatory for all live flights during the test.

• Flight Rules: All live flights will be conducted under Visual Line of Sight (VLOS) conditions, in strict accordance with ICA 100-40. While the technical scenarios will simulate Beyond Visual Line of Sight (BVLOS) coordination, the actual flight must remain within the pilot's line of sight at all times.

• Immediate Operation Termination: All operators must be able to cease operations immediately upon command from their managing USS. This capability is critical for scenarios involving in-flight contingencies.

• Loss of C2 Link Procedure: All UAS must be configured to execute a "Return to Home" (RTH) procedure automatically upon loss of the command and control (C2) link. The RTH altitude must be set to the operation's maximum authorized ceiling to ensure predictable behavior and vertical deconfliction.

• Fly-Away Emergency Declaration: In the event of a fly-away or any situation where the operator loses control of the aircraft, the operator must immediately declare an emergency to DECEA’s personnel, as well as the USS. The USS will then be responsible for propagating this information as required.

7. Getting Started & Prerequisites

All participants must complete the following steps to be ready for the field test:

1. Register Participation: Formally register your organization and declare your intended role(s).

2. Review Documentation: Thoroughly read the API documentation at https://github.com/dp-icea/Protocols.

3. Implement Authentication: Implement the JWT-based authentication client and server logic. You will be provided with API keys and the public key.

4. Implement OIR Activation: Ensure your system correctly handles the Accepted, Activated, and Ended states of an OIR.

5. Provide Endpoints: USS Providers must supply the base URL for their publicly accessible API so it can be registered in the DSS for peer-to-peer communication.

6. Prepare for Flight: Operators must have their drones, ground control stations, and Remote ID broadcast modules ready for operation.

7. Synchronize Time Servers: All USS and operator systems must synchronize their clocks with DECEA’s official NTP (Network Time Protocol) server, to be provided. Accurate, synchronized time is critical for the correct sequencing of operations, conflict detection, and logging.

We look forward to your participation in this critical test to advance the future of aviation in Brazil.