# Documentação Técnica

# Guia para Integração Técnica ao Projeto



# OpenAPI Specifications

[utm.yaml](https://servicos2.decea.mil.br/br-utm/wiki/attachments/137)

[remoteid.yaml](https://servicos2.decea.mil.br/br-utm/wiki/attachments/136)

[flights.yaml](https://servicos2.decea.mil.br/br-utm/wiki/attachments/135)

[injection.yaml](https://servicos2.decea.mil.br/br-utm/wiki/attachments/133)

[versioning.yaml](https://servicos2.decea.mil.br/br-utm/wiki/attachments/134)

# Chapter 1 — Introduction to BR-UTM

## 1.1 What Is BR-UTM?

BR-UTM is the **Brazilian UAS Traffic Management** system, operated and overseen by **DECEA** (Departamento de Controle do Espaço Aéreo), the Brazilian Department of Airspace Control, under the Brazilian Air Force.

Its purpose is to safely coordinate the operation of Unmanned Aerial Systems (UAS — drones) in Brazilian low-altitude airspace. As the number of commercial and industrial drone operations grows, it becomes critical to ensure that multiple operators can share the same airspace without conflict, and that public safety is maintained at all times.

A useful analogy: **BR-UTM works like a central bank for drone flight planning**. Just as a central bank does not conduct commerce itself but provides the infrastructure, rules, and oversight that allow banks to operate reliably and interoperably — DECEA does not fly drones, but it provides the infrastructure, protocols, and oversight that allow companies to fly drones safely and in coordination with one another.

## 1.2 The Role of DECEA

DECEA is responsible for:

- **Defining and maintaining the standards and protocols** that govern how drone operations are planned, coordinated, and tracked.
- **Operating the central services** of the BR-UTM ecosystem, including the Authentication Server, the Discovery and Synchronization Service (DSS), and the Portal UTM.
- **Validating and authorizing** companies that wish to integrate their software systems into the BR-UTM ecosystem.
- **Creating and managing airspace constraints** — restrictions that reflect no-fly zones, ATM (manned aviation) traffic, DASA-sourced airspace reservations, and other regulatory limitations.
- **Overseeing conformance** — monitoring whether drone operations are being conducted within their declared volumes.

DECEA also operates its own USS (UAS Service Supplier) instance, which it uses to inject high-priority constraints and respond to emergency situations in the airspace.

## 1.3 The Ecosystem — Key Players

The BR-UTM ecosystem has three main categories of participants:

### DECEA (the Authority)
The regulator and infrastructure provider. Operates the DSS, Auth Server, Portal UTM, Interface UTM, and DECEA's own USS. Creates constraints. Validates and approves new USSs.

### USS — UAS Service Suppliers (Integrated Companies)
Companies that have been validated and authorized by DECEA to operate within the BR-UTM ecosystem. A USS manages its own drone operations: it creates flight plans, coordinates with other USSs, activates flights, tracks conformance in real time, and exposes telemetry.

A USS is a software system that must:
- Communicate with DECEA's DSS to register and discover flight intentions.
- Communicate peer-to-peer with other USSs to share operational details.
- Expose a set of public HTTP APIs so other USSs and DECEA can query flight information.
- Monitor its own drones for conformance and react automatically to airspace changes.

### Drone Operators / End Users
The humans or organizations that operate the physical drones. They interact with the USS software (which the company provides) to submit flight plans, receive approvals, and conduct operations. Their interaction is with the USS, not directly with DECEA's APIs.

## 1.4 BR-UTM Services

The ecosystem exposes several services, all available under the **Sandbox environment** base domain `*.sandbox.brutm.dcta.mil.br`:

| Service | URL | Description |
|---------|-----|-------------|
| **Portal UTM** | `http://portal.sandbox.brutm.dcta.mil.br/` | Web portal for companies. Manage accounts, API keys, UTM zones, developer documentation, and support. |
| **Interface UTM** | `http://interface.sandbox.brutm.dcta.mil.br/` | 3D airspace visualization tool. Displays live OIRs, Constraints, ISAs, UTM Zones, and Remote ID telemetry. |
| **API Gateway** | `http://api.sandbox.brutm.dcta.mil.br/` | Entry point for all machine-to-machine APIs. |
| **Auth Server** | `http://api.sandbox.brutm.dcta.mil.br/token` | OAuth2 token endpoint for acquiring JWT access tokens. |
| **DSS** | `http://api.sandbox.brutm.dcta.mil.br/dss` | Discovery and Synchronization Service — the coordination index for airspace operations. |
| **UTM Zones API** | `http://api.sandbox.brutm.dcta.mil.br/zonautm` | API for querying the UTM Zones a company is authorized to operate in. |

> **Note:** The production environment URLs are separate and are only accessible after a company has completed the homologation process. The old `montreal.icea.decea.mil.br` URLs found in older documentation are **deprecated** and must not be used.

## 1.5 International Standards

BR-UTM is built on internationally recognized standards:

- **ASTM F3548-21** — Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability. Defines the strategic coordination protocol between USSs and the DSS.
- **ASTM F3411-22A** — Standard Specification for Remote ID and Tracking. Defines how UASs broadcast and share their identity and location.
- **InterUSS Platform** — An open-source implementation of the ASTM standards, upon which DECEA's DSS is based. This ensures the system is fully interoperable with other international UTM implementations.

The OpenAPI contracts that define the exact HTTP interfaces are published by DECEA and are the definitive reference for integration. They are provided in this repository under the `interfaces/` directory.

## 1.6 Phases of the Project

BR-UTM is being deployed incrementally. The current operational phase is **Phase 1**, which defines:

- The permission level for validated software: **U1**.
- All operational intents in Phase 1 operate at **priority level 0**. No priority differentiation between operators exists yet.
- All flight types (VLOS, EVLOS, BVLOS) are supported in terms of the protocol, but the business and regulatory rules for each are defined by ANAC and ANATEL separately.

Future phases will introduce priority differentiation based on USS scores, use cases (e.g., medical emergency), and other factors.

## 1.7 What This Guide Covers

This guide is intended for **software engineers and technical teams** at companies wishing to integrate their systems into BR-UTM as a USS. It covers:

- How to onboard your company and obtain API credentials.
- How authentication and authorization work.
- How to plan, register, activate, execute, and close a drone flight.
- What APIs your system must implement and expose.
- The non-functional requirements your system must satisfy.
- How the homologation (validation) process works.

For regulatory compliance (ANAC, ANATEL, SISANT, SARPAS), consult the applicable Brazilian aviation regulations separately — those topics are outside the scope of this guide.

# Chapter 2 — Prerequisites and Core Concepts

Before diving into integration, it is essential to understand the foundational concepts and data structures that underpin the entire BR-UTM system. This chapter defines all key terms used throughout the integration guide.

---

## 2.1 DSS — Discovery and Synchronization Service

The **DSS** is the central coordination index of the BR-UTM ecosystem. It is operated by DECEA and is the single authoritative source for discovering what is happening in any given volume of airspace.

**Critically, the DSS does not store the full details of any operation.** It stores only _references_ — lightweight records that tell other participants _who_ is operating _where_ and _when_, and _how to contact them_ to get the full details. The actual volume geometry, flight profile, and telemetry are stored by each USS on their own systems and shared peer-to-peer on demand.

The DSS uses **Google S2 geometry cells** (approximately 1 km² each) to index airspace. Because S2 cells are rectangular approximations, the DSS may return references for operations that are geometrically close but do not precisely intersect with your query area. Your USS is responsible for performing the exact 4D intersection calculation locally.

The DSS is based on the [InterUSS Platform](https://interussplatform.org/) open-source project, implementing ASTM F3548-21 and ASTM F3411-22A.

**Base URL (Sandbox):** `http://api.sandbox.brutm.dcta.mil.br/dss`

---

## 2.2 USS — UAS Service Supplier

A **USS** is a software system operated by a company that has been validated and authorized by DECEA to operate in the BR-UTM ecosystem. The USS is responsible for:

- Managing the full lifecycle of its customers' drone operations.
- Registering and coordinating those operations with the DSS.
- Communicating directly with other USSs (peer-to-peer) to share operational details.
- Exposing public HTTP endpoints that other USSs and DECEA can call.
- Monitoring drone telemetry and ensuring conformance with declared flight plans.

Every USS must have a publicly accessible base URL (e.g., `https://uss.yourcompany.com/utm`) registered in the DSS as part of every Operational Intent Reference it creates. This URL is used by other USSs and DECEA to contact your system directly.

---

## 2.3 OIR — Operational Intent Reference

An **Operational Intent Reference (OIR)** is a record stored in the DSS representing a company's _intention_ to conduct a drone operation. It is the primary unit of coordination in the UTM system.

What the DSS stores about an OIR (the _Reference_):
- A unique entity ID (UUID)
- The managing USS identifier (`manager` — the JWT `sub` claim of the creating USS)
- The operational state (`Accepted`, `Activated`, `Nonconforming`, `Contingent`)
- The temporal window (`time_start`, `time_end`) and S2-indexed extents
- The USS's public base URL (`uss_base_url`) for peer-to-peer contact
- The current version number and **OVN (Object Version Number)**
- The subscription ID associated with this operation

What the USS stores about an OIR (the _Details_, not in DSS):
- The full 4D volumes (`volumes` — array of `Volume4D`)
- Off-nominal volumes (`off_nominal_volumes`) for emergency states
- Priority (currently always `0`)
- Flight type (`VLOS`, `EVLOS`, or `BVLOS`)

Other USSs retrieve these details by calling your USS directly at `GET /uss/v1/operational_intents/{entityid}`.

### OIR States

| State | Description |
|-------|-------------|
| **Accepted** | The flight plan has been created and registered in the DSS. Pre-flight planning phase. No drone is in the air yet. |
| **Activated** | The flight is actively underway. The drone is (or is about to be) airborne. Telemetry must be available. |
| **Nonconforming** | The drone has temporarily left its declared flight volume. The situation is considered recoverable. The OIR includes `off_nominal_volumes`. Can return to `Activated`. |
| **Contingent** | The drone has been outside its declared volume for more than 60 seconds. The situation is considered unrecoverable. Only `off_nominal_volumes` are active. Must eventually be closed. |

---

## 2.4 OVN — Object Version Number

An **OVN (Object Version Number)** is an opaque token (string) that uniquely identifies the _current version_ of a specific Operational Intent or Constraint in the DSS. It changes every time the entity is updated.

OVNs serve a critical purpose in the deconfliction protocol: **they are proof that you have seen and acknowledged the latest state of a neighboring operation or constraint**. Before you can create or update your own OIR, you must collect the OVNs of all nearby OIRs and Constraints (by fetching their details from the respective USSs) and include them in the `key` array of your DSS write request.

If you provide an outdated or missing OVN, the DSS will reject your request with a `409 AirspaceConflictResponse`, listing the entities whose OVNs you are missing.

---

## 2.5 Subscription

A **Subscription** is a registration in the DSS that declares your USS's interest in a specific geographic area and time window. When any USS creates, updates, or deletes an OIR or Constraint that intersects your subscribed area, the DSS includes your USS in the `subscribers` list of its write response. The creating/updating USS then calls your USS at `POST /uss/v1/operational_intents` or `POST /uss/v1/constraints` to notify you.

There are two types of subscriptions:

- **Implicit (automatic):** When you create an OIR in the DSS, the DSS can automatically create a subscription for the same area and time window. You achieve this by providing a `new_subscription` object in your OIR creation request. This is the normal operational flow.
- **Explicit (manual):** You can create a standalone subscription using `PUT /dss/v1/subscriptions/{subscriptionid}`. This is useful for systems that need airspace awareness without having active operations — for example, a visualization or situational awareness tool.

---

## 2.6 ISA — Identification Service Area

An **ISA (Identification Service Area)** is a record stored in the **Remote ID DSS** (which shares the same DSS infrastructure) that indicates your USS is actively serving telemetry for a given geographic area during a given time window.

The ISA tells other systems (display providers, DECEA's monitoring tools) _where_ your USS has active drone operations and _how to query_ your telemetry endpoint (`/uss/flights`).

An ISA must be created **at the moment a flight is activated** (when the OIR transitions to `Activated`). It must be deleted when the flight ends and the OIR is deleted.

---

## 2.7 Volume4D — The 4D Airspace Volume

A **Volume4D** is the fundamental building block for describing airspace in BR-UTM. It combines a 3D geographic volume with a time window:

| Component | Description |
|-----------|-------------|
| **outline_polygon** | A geographic polygon defined by a list of lat/lng vertices. |
| **outline_circle** | Alternatively, a circle defined by a center lat/lng and radius in meters. |
| **altitude_lower** | The floor altitude, in meters, WGS84 reference (`"W84"`). |
| **altitude_upper** | The ceiling altitude, in meters, WGS84 reference (`"W84"`). |
| **time_start** | Start of the time window, in RFC3339 format with UTC timezone (`Z`). |
| **time_end** | End of the time window, in RFC3339 format with UTC timezone (`Z`). |

A single OIR can contain **multiple Volume4D objects** in its `volumes` array. This allows a complex operation (e.g., a vertical takeoff cylinder + a horizontal route polygon + a landing cylinder) to be described as a single coherent operational intent.

**Example: A simple cylindrical volume**
```json
{
  "volume": {
    "outline_circle": {
      "center": { "lat": -23.2071, "lng": -45.8750 },
      "radius": { "value": 100, "units": "M" }
    },
    "altitude_lower": { "value": 0, "reference": "W84", "units": "M" },
    "altitude_upper": { "value": 120, "reference": "W84", "units": "M" }
  },
  "time_start": { "value": "2026-07-01T10:00:00Z", "format": "RFC3339" },
  "time_end": { "value": "2026-07-01T11:00:00Z", "format": "RFC3339" }
}
```

---

## 2.8 Constraint

A **Constraint** is a restriction on airspace usage, created and managed exclusively by DECEA (in Phase 1). Constraints represent no-fly zones, restricted areas, active ATM traffic zones, or reservations sourced from the DASA system (DECEA's airspace reservation tool).

From the USS's perspective, constraints are queried from the DSS just like OIRs. When a constraint exists in your area of interest, you must:
1. Retrieve its OVN from the DSS via `POST /dss/v1/constraint_references/query`.
2. Fetch its full volume details from DECEA's USS at `GET /uss/v1/constraints/{entityid}` (using the `uss_base_url` in the constraint reference).
3. Include its OVN in the `key` array of your OIR creation/update request.
4. Avoid creating operations that intersect active constraints.

Constraints arriving from DASA appear as regular `ConstraintReference` objects — your USS does not need to do anything special to handle them.

---

## 2.9 UTM Zone

A **UTM Zone** is a geographic allocation that a company creates in the Portal UTM to define the area where it intends to operate. It is defined by:

- A **geographic polygon** (the operational area)
- An **altitude range** (floor and ceiling)
- An optional **time validity** (can be permanent/indefinite)

All Operational Intents (OIRs) created by a company must be **strictly inside** their UTM Zone(s). A company can own multiple UTM Zones (e.g., for operations in different cities or regions). UTM Zones are permanently allocated — there is currently no renewal or expiration mechanism defined.

The UTM Zone is also the mechanism that links a validated software version (API Key) to a specific geographic area of operation. When a company registers a new UTM Zone using a valid API Key, DECEA can confirm that the company's software has been validated for operation in that area.

---

## 2.10 off_nominal_volumes

`off_nominal_volumes` is an array of `Volume4D` objects attached to an OIR that is in a `Nonconforming` or `Contingent` state. These volumes represent the **warning area** — the airspace that DECEA and neighboring USSs should treat as potentially hazardous due to the drone's deviation from its planned route.

- In **Nonconforming** state: both `volumes` (original plan) and `off_nominal_volumes` (warning area) are active.
- In **Contingent** state: only `off_nominal_volumes` are active — the original `volumes` are no longer relevant.

The size and shape of `off_nominal_volumes` is **entirely at the USS's discretion**, calculated based on the drone's current position, velocity, and the nature of the deviation. DECEA has not mandated a specific formula, but the off-nominal volumes should reasonably cover the route between the drone's actual position and the nearest point of the original volume.

---

## 2.11 Key Reference Summary

| Term | Short Definition |
|------|-----------------|
| **DSS** | Central coordination index for airspace. Stores only references. |
| **USS** | Your company's integrated software system. Manages flights, exposes APIs. |
| **OIR** | An Operational Intent Reference — a flight plan registered in the DSS. |
| **OVN** | Object Version Number — proof you've seen the latest state of a neighbor entity. |
| **Subscription** | Registration of interest in an airspace area to receive notifications. |
| **ISA** | Identification Service Area — declares you're serving telemetry for an area. |
| **Volume4D** | 3D polygon/circle + altitude range + time window. |
| **Constraint** | Airspace restriction created by DECEA. Must be respected by all USSs. |
| **UTM Zone** | Your company's authorized area of operation. OIRs must be inside it. |
| **off_nominal_volumes** | Warning area declared when a drone deviates from its planned volume. |
| **`manager`** | The JWT `sub` claim of the USS that created an OIR. Informational only. |
| **`uss_base_url`** | The public HTTPS base URL of your USS. Used for peer-to-peer calls and token audience. |

# Chapter 3 — Onboarding Process

This chapter describes the end-to-end process for a new company to become an authorized USS in the BR-UTM ecosystem, from account creation to operating in production.

---

## 3.1 Overview

The onboarding process has two phases:

1. **Development Phase** — Create an account, obtain a development API Key, and integrate your software against the Sandbox environment.
2. **Production Phase** — Submit your software for homologation (validation) by DECEA, receive a production API Key with U1 permission, create UTM Zones, and begin operating.

```
Create Account → Get Dev API Key → Sandbox Integration → Homologation → Production API Key → UTM Zone → Operate
```

---

## 3.2 Step 1 — Create an Account (Contas DECEA)

All access to DECEA digital services starts with a personal account on the **Contas DECEA** platform.

1. Navigate to the **Portal UTM**: [http://portal.sandbox.brutm.dcta.mil.br/](http://portal.sandbox.brutm.dcta.mil.br/)
2. Select the option to create a new account via **Contas DECEA**.
3. Complete the registration with your personal and professional information.

> **Note:** A single individual user account can be associated with multiple company accounts. The account is linked to the person, not the company.

---

## 3.3 Step 2 — Register Your Company

After your personal account is created:

1. Log in to the Portal UTM.
2. Navigate to the company registration section.
3. Register your company with the relevant information (CNPJ, razão social, etc.).

Your company account will be the entity that owns API Keys, UTM Zones, and validated software versions.

---

## 3.4 Step 3 — Obtain a Development API Key

With a registered company account, you can request an API Key for the **development (Sandbox) environment** directly through the Portal UTM.

- Navigate to the developer section of the Portal UTM.
- Request a new API Key for your company.
- The API Key will be created and available immediately in the Portal.

> **During the transition period** (while Portal UTM is not yet fully deployed in production): Contact DECEA through the official support channels — **Mattermost** or the **Central de Ajuda** — to request a development API Key manually.

This API Key is used in all subsequent requests to the Auth Server to obtain JWT tokens.

---

## 3.5 Step 4 — Download DECEA's Public Key

All JWT tokens issued by DECEA's Auth Server are signed with an RS256 private key. Your USS must validate incoming tokens (from other USSs and from the DSS) using DECEA's public key.

The public key is available through the Portal UTM developer section. It is a standard RSA public key in PEM format.

> **Important:** Your USS must validate every incoming request's JWT against this public key. See [Chapter 4 — Authentication](./04-architecture-and-authentication.md) for validation details.

---

## 3.6 Step 5 — Integrate Against the Sandbox

With your development API Key and DECEA's public key, you can begin implementing and testing your USS software against the **Sandbox environment**.

All Sandbox services are accessible under `*.sandbox.brutm.dcta.mil.br`:

| Service | Sandbox URL |
|---------|-------------|
| Auth Server | `http://api.sandbox.brutm.dcta.mil.br/token` |
| DSS | `http://api.sandbox.brutm.dcta.mil.br/dss` |
| UTM Zones | `http://api.sandbox.brutm.dcta.mil.br/zonautm` |

Your integration must implement all mandatory USS-side endpoints. The Interface UTM (`http://interface.sandbox.brutm.dcta.mil.br/`) can be used as a visual debugging aid — it shows active OIRs, Constraints, ISAs, and telemetry in a 3D view of Brazilian airspace.

Refer to the following chapters for detailed technical integration guidance:
- [Chapter 4](./04-architecture-and-authentication.md) — Authentication
- [Chapter 5](./05-flight-lifecycle.md) — The full flight lifecycle
- [Chapter 6](./06-apis-to-implement.md) — APIs your USS must implement

---

## 3.7 Step 6 — Request Homologation

Once your software is ready and has been validated internally against the Sandbox, you request a **homologation process** with DECEA.

Homologation is a **manual validation process conducted by DECEA**, potentially assisted by internal automated testing tools. During this process, DECEA will exercise your USS's APIs through a set of defined test scenarios (see [Chapter 8 — Homologation](./08-homologation.md)).

**To be eligible for homologation, your USS must:**
- Implement all mandatory USS-side endpoints as defined in the OpenAPI specifications.
- Expose the automated testing interfaces (`flights.yaml`, `injection.yaml`, `versioning.yaml`) on your server so DECEA's testing framework can call them.
- Satisfy all non-functional requirements (see [Chapter 7](./07-non-functional-requirements.md)).
- Be deployed and accessible from the internet (your system must have a publicly accessible base URL).

Contact DECEA through the official channel (**Mattermost** or the **Central de Ajuda**) to initiate the homologation request.

---

## 3.8 Step 7 — Receive a Production API Key (U1 Permission)

Upon successful homologation, DECEA grants your software a **production API Key with the U1 permission level**.

- The production API Key is tied to the specific **version of the software** that was validated. If you release a new major version, a new homologation may be required.
- The U1 permission is the first operational authorization level for Phase 1 of BR-UTM.
- The production API Key can also be used to create sub-keys for **third-party companies** that wish to purchase and use your USS software. As the validated software owner, you create these sub-keys and distribute them to your clients.

---

## 3.9 Step 8 — Create UTM Zone(s)

With a production API Key, your company can create **UTM Zones** in the Portal UTM. A UTM Zone is the geographic, altitudinal, and temporal authorization for your company to operate.

To create a UTM Zone:
1. Log in to the Portal UTM with your production account.
2. Navigate to the **Create UTM Zone** section.
3. Provide your API Key — this confirms your software is validated and authorized.
4. Define the UTM Zone:
   - **Geographic polygon** (vertices in lat/lng)
   - **Altitude range** (floor and ceiling in meters WGS84)
   - **Time validity** (optional — can be indefinite/permanent)
5. Submit for creation.

A company can own **multiple UTM Zones** (e.g., one per city, or one per use case). There is currently no limit on the size of a UTM Zone — it can cover a neighborhood, a city, or an entire region.

> **Remember:** All OIRs (Operational Intent References) your USS creates must be **strictly contained within** one of your UTM Zones. Operations outside your UTM Zone boundaries are not permitted.

---

## 3.10 Step 9 — Begin Operating

Once your UTM Zone is active and your production API Key is in use, your USS can begin accepting flight plans from operators and creating OIRs in the production DSS.

The complete technical flow for each individual flight is described in [Chapter 5 — The Flight Lifecycle](./05-flight-lifecycle.md).

---

## 3.11 Onboarding Summary

```
┌─────────────────────────────────────────────────────┐
│                 ONBOARDING SEQUENCE                 │
├─────────────────────────────────────────────────────┤
│  1. Create personal account (Contas DECEA)          │
│  2. Register your company in Portal UTM             │
│  3. Request Development API Key (Portal UTM)        │
│  4. Download DECEA's public key (Portal UTM)        │
│  5. Implement & test against Sandbox environment    │
│  6. Request Homologation from DECEA                 │
│  7. Pass homologation → receive Production API Key  │
│     with U1 permission                              │
│  8. Create UTM Zone(s) in Portal UTM                │
│  9. Begin operating in production                   │
└─────────────────────────────────────────────────────┘
```

## 3.12 Support Channels

| Channel | Purpose |
|---------|---------|
| **Portal UTM** | Self-service: API keys, UTM Zones, documentation |
| **Central de Ajuda** | General support requests, homologation requests |
| **Mattermost** | Real-time developer support and communication with DECEA |
| **Interface UTM** | Visual debugging of airspace state in the Sandbox |

# Chapter 4 — Architecture and Authentication

This chapter describes the authentication and authorization model used across the entire BR-UTM ecosystem, including how your USS obtains tokens, uses them to call DECEA's APIs, validates tokens received from other USSs, and authenticates peer-to-peer calls.

---

## 4.1 Authentication Architecture Overview

BR-UTM uses **OAuth2 Client Credentials flow** with **JWT (JSON Web Token) access tokens**, signed using **RS256 (RSA SHA-256)**. This is a stateless, distributed authentication model where:

1. Your USS presents its **API Key** to DECEA's **Auth Server** to obtain a signed JWT.
2. The JWT is included as a **Bearer token** in every API request (to the DSS, to DECEA's USS, or to other USSs).
3. The receiving server **validates the JWT locally** using DECEA's public key — it does not need to call the Auth Server again.

This architecture is critical for the distributed, peer-to-peer nature of the system: there is no central session state, and any server can independently validate any token.

```
┌──────────────────┐   1. POST /token?apikey=...&scope=...&intended_audience=...
│   Your USS       │──────────────────────────────────────────────────────────────►│ Auth Server │
│                  │◄──────────────────────────────── 2. JWT (signed RS256) ───────│             │
│                  │
│                  │   3. Authorization: Bearer <JWT>
│                  │──────────────────────────────────────────────────────────────►│ DSS / USS   │
│                  │◄──────────────────────────────── 4. Response ────────────────│             │
└──────────────────┘
```

---

## 4.2 Obtaining a JWT Token

To obtain a JWT, send an HTTP GET or POST request to the Auth Server token endpoint:

**Endpoint:** `http://api.sandbox.brutm.dcta.mil.br/token`

**Query parameters (or request body):**

| Parameter | Description | Example |
|-----------|-------------|---------|
| `apikey` | Your company's API Key, obtained from the Portal UTM. Can also be sent as an HTTP header. | `abc123...` |
| `scope` | The OAuth2 scope(s) you need for the operation. Space-separated for multiple scopes. | `utm.strategic_coordination utm.constraint_processing` |
| `intended_audience` | The FQDN (domain name only, no path) of the server this token will be sent to. | `api.sandbox.brutm.dcta.mil.br` or `uss-b.yourpartner.com` |

**Example request:**
```http
GET /token?scope=utm.strategic_coordination&intended_audience=api.sandbox.brutm.dcta.mil.br
Authorization: ApiKey abc123yourapikey
```

**Example response:**
```json
{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600
}
```

---

## 4.3 JWT Token Structure

Every token issued by DECEA's Auth Server is a signed JWT containing the following claims:

| Claim | Description | Example |
|-------|-------------|---------|
| `iss` | The URL of the Auth Server that issued the token. | `http://api.sandbox.brutm.dcta.mil.br/token` |
| `exp` | Token expiration timestamp (Unix epoch). Maximum 1 hour from issuance. | `1751327400` |
| `sub` | Your USS's unique identifier — the `manager` identifier in DSS records. | `"my-company-uss"` |
| `scope` | Granted scopes, space-separated. | `"utm.strategic_coordination utm.constraint_processing"` |
| `jti` | Unique token ID for replay protection (RFC 7519). | `"d3e8f921-..."` |
| `aud` | The FQDN of the intended recipient server. | `"api.sandbox.brutm.dcta.mil.br"` |

### Token Validity

- Tokens are valid for **up to 1 hour** (inspect the `exp` claim for the exact expiry time).
- **Cache and reuse tokens** until they are near expiry. Requesting a new token on every API call is wasteful and may cause rate limiting.
- A single token can carry **multiple scopes** (space-separated in the `scope` claim), so you can request all the scopes you need for a workflow in one token request.

---

## 4.4 Available Scopes

### UTM API (`utm.yaml`)

| Scope | Purpose |
|-------|---------|
| `utm.strategic_coordination` | Create, update, delete, and query OIRs in the DSS. Notify subscriber USSs. Fetch OIR details from other USSs. **Required for all standard flight operations.** |
| `utm.constraint_processing` | Query constraint references in the DSS and fetch constraint details from DECEA's USS. **Required if your area may have constraints.** |
| `utm.conformance_monitoring_sa` | Query OIRs and fetch telemetry for off-nominal situations. Used by DECEA's monitoring systems. |
| `utm.constraint_management` | Create, update, and delete constraints. **DECEA only.** |
| `utm.availability_arbitration` | Set USS availability state in the DSS. **Not required in Phase 1.** |
| `utm.aviation_authority` | Access flight authorization details. **DECEA only.** |

### Remote ID API (`remoteid.yaml`)

| Scope | Purpose |
|-------|---------|
| `rid.service_provider` | Create, update, and delete ISAs in the Remote ID DSS. **Required when activating/deactivating flights.** |
| `rid.display_provider` | Query ISAs and telemetry from other USSs. **Required for situational awareness.** |

### Automated Testing APIs

| Scope | Purpose |
|-------|---------|
| `interuss.flight_planning.direct_automated_test` | Used by DECEA's test framework when calling your `flights.yaml` endpoints during homologation. |
| `interuss.flight_planning.plan` | Used by DECEA's test framework to simulate user flight plan actions. |
| `rid.inject_test_data` | Used by DECEA's test framework when calling your `injection.yaml` endpoints during homologation. |
| `interuss.versioning.read_system_versions` | Used by DECEA's test framework when calling your `versioning.yaml` endpoint. |

### Day-to-Day Scope Requirements

For normal production operations, your USS will primarily need:

```
utm.strategic_coordination
utm.constraint_processing
rid.service_provider
rid.display_provider
```

---

## 4.5 The `intended_audience` Parameter — Peer-to-Peer Calls

The `intended_audience` parameter (which becomes the `aud` claim in the JWT) is **critical for peer-to-peer security**. It binds a token to a specific recipient, preventing token replay attacks.

**Rules:**
- When calling **DECEA's DSS** or **Auth Server**: use the domain of the DSS (e.g., `api.sandbox.brutm.dcta.mil.br`).
- When calling **another USS** (e.g., to fetch OIR details): use **only the domain** of that USS's `uss_base_url` — no path, no port (unless non-standard).

**Example:**

If USS B's `uss_base_url` in the DSS is `https://uss-b.partnercompany.com/api/utm`, then when USS A wants to call USS B:

```
intended_audience = "uss-b.partnercompany.com"
```

USS A requests a fresh token with this audience and includes it in the `Authorization` header when calling `GET https://uss-b.partnercompany.com/api/utm/uss/v1/operational_intents/{id}`.

USS B, upon receiving this request, validates that the token's `aud` claim matches its own domain (`uss-b.partnercompany.com`). If it doesn't match, it rejects the request with HTTP 401.

---

## 4.6 Using the Token

Include the token in every outgoing HTTP request:

```http
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
```

This applies to calls to:
- DECEA's DSS (`/dss/v1/...`)
- DECEA's Remote ID DSS (`/dss/identification_service_areas/...`)
- Any peer USS's endpoints (`/uss/v1/...`)

---

## 4.7 Validating Incoming Tokens (Inbound Requests)

Your USS **must validate every inbound request** — whether from DECEA's systems or from other USSs. Failing to do so is a security vulnerability and a homologation failure.

The validation steps are:

### Step 1 — Extract the Token
```
Extract the JWT from the Authorization header:
Authorization: Bearer <token>
```

### Step 2 — Verify the RS256 Signature
Verify the token's digital signature using **DECEA's public RSA key** (obtained from the Portal UTM during onboarding). The signing algorithm is RS256.

If the signature is invalid → reject with **HTTP 401**.

### Step 3 — Verify Token Expiry
Check that the `exp` claim is greater than the current UTC timestamp.

If the token is expired → reject with **HTTP 401**.

### Step 4 — Verify the Audience
Check that the `aud` claim matches **your own server's FQDN**. This prevents a token intended for another USS from being replayed against your server.

If `aud` doesn't match your domain → reject with **HTTP 401**.

### Step 5 — Verify the Scope
Check that the `scope` claim contains the scope required by the specific endpoint being called. Different endpoints require different scopes (see the OpenAPI specifications for each endpoint's required scope).

If the scope is insufficient → reject with **HTTP 403**.

**Go implementation reference** (from the BR-UTM workshop):
```go
func verifyToken(token string, publicKeyFile string) (bool, error) {
    bytes, _ := os.ReadFile(publicKeyFile)
    publicKey, _ := jwt.ParseRSAPublicKeyFromPEM(bytes)
    parts := strings.Split(token, ".")
    err := jwt.SigningMethodRS256.Verify(
        strings.Join(parts[0:2], "."), parts[2], publicKey,
    )
    return err == nil, err
}
```

---

## 4.8 Token Caching Strategy

For optimal performance:

1. **Cache the token** after obtaining it.
2. **Reuse it** for all requests to the same audience with the same scopes, until it's within a safety margin of expiry (e.g., 60 seconds before `exp`).
3. **Request a new token** when the cached one is near expiry or when you need a different scope/audience combination.

You may maintain multiple cached tokens simultaneously — one per `(scope, audience)` combination that your USS needs.

---

## 4.9 Architecture Diagram — Full Authentication Flow

```
                          ┌─────────────────────────────────────────────┐
                          │              DECEA Infrastructure            │
  ┌──────────────┐        │  ┌──────────────┐    ┌────────────────────┐ │
  │              │──────► │  │  Auth Server  │    │        DSS         │ │
  │   Your USS   │ token  │  │  /token       │    │  /dss/v1/...       │ │
  │              │◄─────  │  └──────────────┘    └────────────────────┘ │
  │              │        │                                              │
  │              │─────────────────── Bearer JWT ──────────────────────►│
  │              │◄──────────────────── Response ──────────────────────  │
  └──────┬───────┘        └─────────────────────────────────────────────┘
         │
         │  Peer-to-Peer (with audience-specific token)
         │
         ▼
  ┌──────────────┐
  │  Partner USS │  validates JWT: sig + exp + aud + scope
  │  /uss/v1/... │
  └──────────────┘
```

---

## 4.10 Security Principles

- **Principle of least privilege**: Request only the scopes your operation actually needs. Avoid requesting all scopes in every token.
- **No token sharing**: Tokens are bound to a specific audience (`aud`). A token obtained to talk to the DSS cannot be used to call another USS, and vice versa.
- **Time synchronization**: Your system clock must be synchronized with DECEA's NTP server (`ntp.decea.gov.br`) to ensure token expiry calculations are accurate. See [Chapter 7 — Non-Functional Requirements](./07-non-functional-requirements.md).

# Chapter 5 — The Full Flight Lifecycle

This chapter walks through the complete technical lifecycle of a drone flight in BR-UTM — from pre-flight planning to post-flight cleanup. Every API call, data structure, and decision point is described in sequence.

---

## 5.1 Lifecycle Overview

A BR-UTM flight goes through the following stages:

```
PRE-FLIGHT                    IN-FLIGHT                    POST-FLIGHT
─────────────────────────     ───────────────────────────   ───────────────
Query DSS (OIRs + Constraints)
  │
  ├─► Fetch details from USSs (peer-to-peer)
  │     (get OVNs)
  │
  ├─► Calculate conflicts locally (4D intersection)
  │
  ├─► Create OIR in DSS (state: Accepted)
  │     (include all OVNs in `key`)
  │
  └─► Notify subscribers                                    Delete OIR from DSS
                                                               │
         │                                                     ├─► Notify subscribers
         ▼                                                     │
  Re-check conflicts (pre-activation)                         └─► Delete ISA from Remote ID DSS
         │
  Activate OIR in DSS (state: Activated)
  Notify subscribers
         │
  Create ISA in Remote ID DSS
         │
  Serve telemetry (≤10s updates)    ──────────────────────────►
         │                                                     │
         ├── Conformance monitoring ────────────────────────── │
         │   (detect out-of-volume)                            │
         │                                                     │
         ├── Handle incoming notifications                     │
         │   (POST /uss/v1/operational_intents)                │
         │                                                     │
         └── Emergency handling (if needed)                    │
             (Nonconforming → Contingent)                      │
```

---

## 5.2 Pre-Flight: Querying the Airspace

Before creating an OIR, your USS must understand the current state of the airspace in the intended operation area.

### 5.2.1 Query for Existing OIRs

**Endpoint:** `POST http://api.sandbox.brutm.dcta.mil.br/dss/dss/v1/operational_intent_references/query`
**Scope:** `utm.strategic_coordination`

```json
{
  "area_of_interest": {
    "volume": {
      "outline_polygon": {
        "vertices": [
          { "lat": -23.205, "lng": -45.878 },
          { "lat": -23.205, "lng": -45.872 },
          { "lat": -23.211, "lng": -45.872 },
          { "lat": -23.211, "lng": -45.878 }
        ]
      },
      "altitude_lower": { "value": 0, "reference": "W84", "units": "M" },
      "altitude_upper": { "value": 200, "reference": "W84", "units": "M" }
    },
    "time_start": { "value": "2026-07-01T10:00:00Z", "format": "RFC3339" },
    "time_end": { "value": "2026-07-01T11:00:00Z", "format": "RFC3339" }
  }
}
```

The response includes a list of `OperationalIntentReference` objects. Each contains the `uss_base_url` of the managing USS.

> **Important:** The DSS uses S2 cell indexing. It may return OIRs that do not precisely intersect your area. Your USS must perform the exact 4D intersection calculation locally after fetching the full volume details.

### 5.2.2 Fetch OIR Details from Peer USSs

For each OIR returned by the DSS that is **managed by another USS**, fetch the full details (including the OVN and exact volumes):

**Endpoint (on the peer USS):** `GET {uss_base_url}/uss/v1/operational_intents/{entityid}`
**Scope:** `utm.strategic_coordination`
**Token audience:** Domain of the peer USS (extracted from `uss_base_url`)

The response includes the full `OperationalIntentDetails` — volumes, off_nominal_volumes, priority, and the current OVN.

**Collect the OVN from each response** — you will need all of them when creating your OIR.

> **Note:** Even if local geometry calculation shows a particular OIR does not intersect with your planned volume, you **must still collect its OVN** and include it in the `key` array. The DSS guarantees airspace awareness at the S2 cell level, not the geometric level.

### 5.2.3 Query for Constraints

**Endpoint:** `POST http://api.sandbox.brutm.dcta.mil.br/dss/dss/v1/constraint_references/query`
**Scope:** `utm.constraint_processing`

Same request format as the OIR query above. The response returns `ConstraintReference` objects.

### 5.2.4 Fetch Constraint Details from DECEA's USS

For each constraint returned, fetch the full details:

**Endpoint (on DECEA's USS):** `GET {constraint_uss_base_url}/uss/v1/constraints/{entityid}`
**Scope:** `utm.constraint_processing`

Collect the OVN from each constraint. If your planned volume intersects a constraint, **you must not proceed** with creating the OIR in that area — deconflict or abandon the operation.

### 5.2.5 Local 4D Conflict Detection

After collecting all nearby OIR and Constraint volumes, perform local 4D intersection calculations:

- **Horizontal**: polygon or circle intersection in the lat/lng plane.
- **Vertical**: overlap between altitude ranges (`altitude_lower` and `altitude_upper`).
- **Temporal**: overlap between time windows (`time_start` and `time_end`).

A conflict exists only when **all three dimensions overlap simultaneously**.

If a conflict with another OIR is detected at the same priority (0), deconfliction strategies include:
- Adjusting the route or volume to avoid overlap.
- Adjusting the time window to fly when the conflicting OIR is not active.
- Suggesting the operator wait and retry.

---

## 5.3 Pre-Flight: Creating the OIR

Once you have resolved any conflicts and collected all OVNs, create the OIR in the DSS.

**Endpoint:** `PUT http://api.sandbox.brutm.dcta.mil.br/dss/dss/v1/operational_intent_references/{entityid}`
**Scope:** `utm.strategic_coordination`

The `{entityid}` is a UUID generated by **your USS** — you own this identifier.

```json
{
  "extents": [
    {
      "volume": {
        "outline_polygon": {
          "vertices": [
            { "lat": -23.207, "lng": -45.875 },
            { "lat": -23.208, "lng": -45.874 },
            { "lat": -23.209, "lng": -45.876 }
          ]
        },
        "altitude_lower": { "value": 0, "reference": "W84", "units": "M" },
        "altitude_upper": { "value": 120, "reference": "W84", "units": "M" }
      },
      "time_start": { "value": "2026-07-01T10:00:00Z", "format": "RFC3339" },
      "time_end": { "value": "2026-07-01T11:00:00Z", "format": "RFC3339" }
    }
  ],
  "key": ["<OVN_of_nearby_OIR_1>", "<OVN_of_constraint_1>"],
  "state": "Accepted",
  "uss_base_url": "https://uss.yourcompany.com/utm",
  "new_subscription": {
    "uss_base_url": "https://uss.yourcompany.com/utm",
    "notify_for_constraints": true
  },
  "flight_type": "BVLOS"
}
```

**Key fields:**
- `extents`: The bounding box of your operation (used for S2 indexing). This should cover all your planned volumes.
- `key`: **All OVNs** you collected in steps 5.2.2 and 5.2.4. Can be empty `[]` if the area is clear.
- `state`: Always `Accepted` at creation time.
- `uss_base_url`: Your publicly accessible base URL. Other USSs will use this to call you.
- `new_subscription`: Creates an implicit subscription for the operation's area, so you receive notifications about new OIRs/Constraints appearing in that area.
- `flight_type`: One of `VLOS`, `EVLOS`, `BVLOS`.

**Response (HTTP 201):**
```json
{
  "operational_intent_reference": {
    "id": "2f8343be-6482-4d1b-a474-16847e01af1e",
    "manager": "your-uss-sub",
    "state": "Accepted",
    "ovn": "9d158f59-80b7-4c11-9c0c-8a2b4d936b2d",
    "uss_base_url": "https://uss.yourcompany.com/utm",
    "subscription_id": "78ea3fe8-...",
    ...
  },
  "subscribers": [
    {
      "subscriptions": [...],
      "uss_base_url": "https://other-uss.com/utm"
    }
  ]
}
```

**Save the `ovn` from the response** — you will need it for all subsequent updates.

---

## 5.4 Pre-Flight: Notifying Subscribers

The DSS response includes a `subscribers` list — the USSs that have subscriptions in your operation's area. You **must notify each of them** immediately after a successful DSS write.

**Endpoint (on each subscriber USS):** `POST {subscriber_uss_base_url}/uss/v1/operational_intents`
**Scope:** `utm.strategic_coordination`
**Token audience:** Domain of the subscriber USS

```json
{
  "operational_intent_id": "2f8343be-6482-4d1b-a474-16847e01af1e",
  "operational_intent": {
    "reference": { ... },
    "details": {
      "volumes": [ ... ],
      "off_nominal_volumes": [],
      "priority": 0
    }
  },
  "subscriptions": [
    {
      "subscription_id": "78ea3fe8-...",
      "notification_index": 1
    }
  ]
}
```

**Expected response:** `204 No Content`

> **Notification timing:** You must send this notification within **5 seconds** in at least 95% of cases. If a subscriber USS is unreachable, proceed — their unavailability does not block your operation.

This same notification pattern applies for **every DSS write** — creation, updates, state changes, and deletion all require notifying the subscribers returned in that write's response.

---

## 5.5 Flight Activation

Immediately before the flight begins, activate the OIR. This is the moment the drone is cleared to launch.

### 5.5.1 Pre-Activation Conflict Re-Check

Before transitioning to `Activated`, perform a fresh conflict check (repeat steps 5.2.1–5.2.5). The airspace may have changed since you created the OIR. If a newly arrived OIR at the same or higher priority conflicts with your volume, **you must not activate** — deconflict first.

The rule: **first to activate wins**. If two USSs with overlapping OIRs at the same priority (0) both attempt activation simultaneously, it is the USS's responsibility to detect this and stand down if necessary.

### 5.5.2 Update OIR State to Activated

**Endpoint:** `PUT http://api.sandbox.brutm.dcta.mil.br/dss/dss/v1/operational_intent_references/{entityid}/{ovn}`
**Scope:** `utm.strategic_coordination`

```json
{
  "extents": [ ... ],
  "key": ["<latest OVNs of all nearby entities>"],
  "state": "Activated",
  "uss_base_url": "https://uss.yourcompany.com/utm",
  "subscription_id": "78ea3fe8-...",
  "flight_type": "BVLOS"
}
```

> **Note:** The `{ovn}` in the URL must be the current OVN of your OIR (from the creation response or last update response). If the DSS returns `409 AirspaceConflictResponse`, it means new entities have appeared in the area whose OVNs you haven't acknowledged. Fetch their details, add their OVNs to `key`, and retry.

**Response (HTTP 200):** Returns the updated reference with a new OVN and a fresh `subscribers` list.

Notify all subscribers (step 5.4) with the `Activated` state.

### 5.5.3 Create the ISA (Remote ID)

Simultaneously with (or immediately after) OIR activation, register an **ISA** in the Remote ID DSS:

**Endpoint:** `PUT http://api.sandbox.brutm.dcta.mil.br/dss/dss/identification_service_areas/{isa_id}`
**Scope:** `rid.service_provider`

```json
{
  "extents": {
    "volume": {
      "outline_polygon": {
        "vertices": [
          { "lat": -23.205, "lng": -45.878 },
          { "lat": -23.205, "lng": -45.872 },
          { "lat": -23.211, "lng": -45.872 },
          { "lat": -23.211, "lng": -45.878 }
        ]
      },
      "altitude_lo": 0,
      "altitude_hi": 120
    },
    "time_start": "2026-07-01T10:00:00Z",
    "time_end": "2026-07-01T11:00:00Z"
  },
  "flights_url": "https://uss.yourcompany.com/uss/flights"
}
```

The `flights_url` tells display providers (like DECEA's monitoring tools) where to query your telemetry.

---

## 5.6 In-Flight: Serving Telemetry

Once the flight is activated and the ISA is registered, your USS must serve **live telemetry** for the drone via the Remote ID endpoints.

DECEA and other display providers will **poll** your telemetry endpoints. You must keep the data fresh.

**Required update frequency:** At least once every **10 seconds**.

Your USS must implement and serve:

**`GET /uss/flights`** — Basic flight list for a view area.
**`GET /uss/flights/{id}/details`** — Detailed information for a specific flight.

See [Chapter 6 — APIs to Implement](./06-apis-to-implement.md) for the full request/response specification.

---

## 5.7 In-Flight: Conformance Monitoring

Your USS must continuously monitor whether the drone is flying within its declared OIR volumes. This is called **conformance monitoring**.

- If the drone's reported position is inside the `volumes` of the Activated OIR → **nominal, no action needed**.
- If the drone's position is outside the `volumes` → trigger the Non-Conforming flow (Section 5.8).

---

## 5.8 In-Flight: Handling Incoming Notifications

While your flight is active, you may receive notifications from other USSs about changes in the airspace near you (new OIRs, constraint changes). These arrive as `POST` requests on your own USS:

- `POST /uss/v1/operational_intents` — A new or updated OIR in your subscription area.
- `POST /uss/v1/constraints` — A new or updated Constraint in your subscription area.

**When you receive such a notification:**
1. Update your internal airspace state.
2. Check whether the new/updated entity conflicts with your active OIR.
3. If a conflict exists and the new entity has **equal or higher priority**, you must deconflict — either modify your route (update the OIR) or, if the flight is active, trigger the Nonconforming flow.

This is how DECEA enforces ATM priority: DECEA's USS may create a high-priority Constraint or OIR in your area, and your USS must react within the 10-second conformance window.

---

## 5.9 Emergency Handling: Non-Conforming State

**Trigger:** The drone's telemetry position is outside the OIR's `volumes`.
**Required response time:** Transition to `Nonconforming` **within 10 seconds** of detecting the deviation.

### 5.9.1 Calculate off_nominal_volumes

Compute a volume that covers the drone's current position and the deviation path. This is your "warning zone" for other operators. The exact calculation is at your USS's discretion — it should be large enough to represent the risk area but not unnecessarily large.

### 5.9.2 Update DSS (within 5 seconds of detection)

**Endpoint:** `PUT .../dss/v1/operational_intent_references/{entityid}/{ovn}`

```json
{
  "extents": [ ... ],
  "state": "Nonconforming",
  "uss_base_url": "https://uss.yourcompany.com/utm",
  "subscription_id": "78ea3fe8-...",
  "flight_type": "BVLOS"
}
```

Note: `key` (OVNs) **may be omitted** in `Nonconforming` state — the DSS does not require proof of airspace awareness during emergencies.

### 5.9.3 Expose Telemetry Endpoint

In `Nonconforming` state, you must also expose live drone position at:
`GET /uss/v1/operational_intents/{entityid}/telemetry`

This allows DECEA and other USSs to monitor the drone's actual position in real time.

### 5.9.4 Notify Subscribers

After the DSS update, notify all subscribers (as returned in the DSS response) with:
- The new `Nonconforming` state.
- The updated `off_nominal_volumes` included in the `details`.

### 5.9.5 Recovery

If the drone returns to its original volume:
1. Update the OIR back to `state: Activated`.
2. Clear `off_nominal_volumes` from the details.
3. Notify subscribers of the recovery.
4. Continue normal telemetry serving.

---

## 5.10 Emergency Handling: Contingent State

**Trigger:** The drone has been continuously in `Nonconforming` state for **more than 60 seconds**.

### Transition to Contingent

**Endpoint:** `PUT .../dss/v1/operational_intent_references/{entityid}/{ovn}`

```json
{
  "extents": [ ... ],
  "state": "Contingent",
  "uss_base_url": "https://uss.yourcompany.com/utm",
  "subscription_id": "78ea3fe8-...",
  "flight_type": "BVLOS"
}
```

In `Contingent` state:
- The **original `volumes` are no longer active** — only `off_nominal_volumes` define the warning zone.
- There is **no recovery path** — the operation must be terminated.
- The ISA **remains active** as long as the drone is still sharing telemetry.
- The telemetry endpoint `GET /uss/v1/operational_intents/{entityid}/telemetry` must remain available.
- Continue notifying subscribers of the Contingent state.

The USS must guide the operator to land the drone and then close the operation (Section 5.11).

---

## 5.11 End of Flight: Cleanup

When the flight concludes normally (or after a Contingent state is resolved), the USS must clean up all DSS records.

### 5.11.1 Delete the ISA

**Endpoint:** `DELETE /dss/identification_service_areas/{isa_id}/{version}`
**Scope:** `rid.service_provider`

Delete the ISA from the Remote ID DSS. The `{version}` comes from the ISA creation response.

Notify the ISA subscribers if the DSS response includes any.

### 5.11.2 Delete the OIR

**Endpoint:** `DELETE /dss/v1/operational_intent_references/{entityid}/{ovn}`
**Scope:** `utm.strategic_coordination`

Delete the OIR from the DSS entirely. There is no "Completed" state — deletion is how a flight is closed.

> **Note:** Each OIR represents a single flight. If the same drone flies a second mission (e.g., after a battery change), create a **new OIR with a new UUID** for that second flight.

### 5.11.3 Notify Subscribers of Deletion

The DSS delete response includes a `subscribers` list. Notify each subscriber:

**Endpoint (on each subscriber):** `POST {subscriber_uss_base_url}/uss/v1/operational_intents`

When sending a deletion notification, **omit the `operational_intent` field** from the body — its absence signals that the OIR has been deleted:

```json
{
  "operational_intent_id": "2f8343be-6482-4d1b-a474-16847e01af1e",
  "subscriptions": [
    {
      "subscription_id": "78ea3fe8-...",
      "notification_index": 5
    }
  ]
}
```

---

## 5.12 Multi-Volume Operations

A single OIR can contain **multiple `Volume4D` objects** in its `volumes` array. This is the correct approach for complex flight paths. Example structure for a takeoff → route → landing mission:

```json
"volumes": [
  {
    "volume": {
      "outline_circle": { "center": {...}, "radius": { "value": 50, "units": "M" }},
      "altitude_lower": { "value": 0, "reference": "W84", "units": "M" },
      "altitude_upper": { "value": 120, "reference": "W84", "units": "M" }
    },
    "time_start": { "value": "2026-07-01T10:00:00Z", "format": "RFC3339" },
    "time_end": { "value": "2026-07-01T10:05:00Z", "format": "RFC3339" }
  },
  {
    "volume": {
      "outline_polygon": { "vertices": [...] },
      "altitude_lower": { "value": 80, "reference": "W84", "units": "M" },
      "altitude_upper": { "value": 120, "reference": "W84", "units": "M" }
    },
    "time_start": { "value": "2026-07-01T10:05:00Z", "format": "RFC3339" },
    "time_end": { "value": "2026-07-01T10:55:00Z", "format": "RFC3339" }
  },
  {
    "volume": {
      "outline_circle": { "center": {...}, "radius": { "value": 50, "units": "M" }},
      "altitude_lower": { "value": 0, "reference": "W84", "units": "M" },
      "altitude_upper": { "value": 120, "reference": "W84", "units": "M" }
    },
    "time_start": { "value": "2026-07-01T10:55:00Z", "format": "RFC3339" },
    "time_end": { "value": "2026-07-01T11:00:00Z", "format": "RFC3339" }
  }
]
```

---

## 5.13 Complete State Transition Summary

```
  [Created] ──────────────────────────────────────────────────── [Deleted]
      │                                                               ▲
      ▼                                                               │
  Accepted ──activate──► Activated ──out of volume──► Nonconforming  │
                              │                           │     │     │
                              │                    back in vol  60s   │
                              │                           │     │     │
                              │                           ▼     ▼     │
                              │                       Activated  Contingent
                              │                                   │
                              └───────────────────────────────────┘
                                     (delete at end of flight)
```

# Chapter 6 — APIs Your USS Must Implement

This chapter describes all the HTTP endpoints that your USS must expose publicly. These are the endpoints that DECEA and other USSs will call against your server. They are divided into:

1. **Production endpoints** — required for all live operations.
2. **Testing/Homologation endpoints** — required for the validation process.

All endpoints must be accessible over HTTPS from the public internet. The base domain of your server becomes the `uss_base_url` registered in the DSS.

---

## 6.1 Production Endpoints (USS-to-USS)

These are defined in `utm.yaml` and `remoteid.yaml` and must be live during production operations.

---

### 6.1.1 `GET /uss/v1/operational_intents/{entityid}`

**Purpose:** Return the full details of one of your USS's Operational Intents to another USS or DECEA that is querying it.

**Required scope (caller must have):** `utm.strategic_coordination`

**Response body:**
```json
{
  "operational_intent": {
    "reference": {
      "id": "2f8343be-6482-4d1b-a474-16847e01af1e",
      "manager": "your-uss-sub",
      "uss_availability": "Normal",
      "version": 3,
      "state": "Activated",
      "ovn": "9d158f59-80b7-4c11-9c0c-8a2b4d936b2d",
      "time_start": { "value": "2026-07-01T10:00:00Z", "format": "RFC3339" },
      "time_end": { "value": "2026-07-01T11:00:00Z", "format": "RFC3339" },
      "uss_base_url": "https://uss.yourcompany.com/utm",
      "subscription_id": "78ea3fe8-..."
    },
    "details": {
      "volumes": [ ... ],
      "off_nominal_volumes": [],
      "priority": 0,
      "flight_type": "BVLOS"
    }
  }
}
```

**Key behaviors:**
- The `ovn` in the reference is what other USSs collect to include in their `key` array.
- When the OIR is in `Nonconforming` or `Contingent` state, the `off_nominal_volumes` field must be populated.
- In `Contingent` state, `volumes` may be empty (only `off_nominal_volumes` applies).

---

### 6.1.2 `POST /uss/v1/operational_intents`

**Purpose:** Receive notifications from other USSs about Operational Intents in your subscription area. This is how you learn about new, updated, or deleted OIRs near your operations.

**Required scope (caller must have):** `utm.strategic_coordination`

**Request body (OIR created or updated):**
```json
{
  "operational_intent_id": "2f8343be-6482-4d1b-a474-16847e01af1e",
  "operational_intent": {
    "reference": { ... },
    "details": {
      "volumes": [ ... ],
      "off_nominal_volumes": [],
      "priority": 0
    }
  },
  "subscriptions": [
    {
      "subscription_id": "78ea3fe8-...",
      "notification_index": 3
    }
  ]
}
```

**Request body (OIR deleted):**
```json
{
  "operational_intent_id": "2f8343be-6482-4d1b-a474-16847e01af1e",
  "subscriptions": [
    {
      "subscription_id": "78ea3fe8-...",
      "notification_index": 5
    }
  ]
}
```
When `operational_intent` is absent, the OIR has been deleted.

**Expected response:** `204 No Content`

**Key behaviors:**
- Update your internal airspace state upon receiving this notification.
- Check whether the new/updated OIR or the deletion changes your own conflict situation.
- If a new high-priority OIR or Constraint conflicts with your active operation, begin deconfliction.

---

### 6.1.3 `GET /uss/v1/constraints/{entityid}`

**Purpose:** Return the full details of a Constraint managed by your USS. In Phase 1, only DECEA creates Constraints, so this endpoint is primarily implemented by **DECEA's USS**. However, it must also be implemented by all USSs for completeness and future phases.

**Required scope (caller must have):** `utm.constraint_processing`

**Response body:**
```json
{
  "constraint": {
    "reference": {
      "id": "c036326c-...",
      "manager": "decea-uss",
      "version": 1,
      "ovn": "a1b2c3d4-...",
      "time_start": { "value": "2026-07-01T08:00:00Z", "format": "RFC3339" },
      "time_end": { "value": "2026-07-01T20:00:00Z", "format": "RFC3339" },
      "uss_base_url": "https://uss.decea.mil.br/utm"
    },
    "details": {
      "volumes": [ ... ],
      "type": "com.decea.restricted_area"
    }
  }
}
```

---

### 6.1.4 `POST /uss/v1/constraints`

**Purpose:** Receive notifications about new, updated, or deleted Constraints in your subscription area. These come from DECEA's USS (and in future phases, potentially other authorized entities).

**Required scope (caller must have):** `utm.constraint_management`

**Request body (Constraint notification):**
```json
{
  "constraint_id": "c036326c-...",
  "constraint": {
    "reference": { ... },
    "details": { "volumes": [ ... ], "type": "..." }
  },
  "subscriptions": [
    { "subscription_id": "...", "notification_index": 1 }
  ]
}
```

When `constraint` is absent, the Constraint has been deleted.

**Expected response:** `204 No Content`

---

### 6.1.5 `GET /uss/v1/operational_intents/{entityid}/telemetry`

**Purpose:** Serve live telemetry for an OIR in `Nonconforming` or `Contingent` state. DECEA's monitoring systems and other USSs call this to track a drone that has deviated from its plan.

**Required scope (caller must have):** `utm.conformance_monitoring_sa`

**Response body:**
```json
{
  "telemetry": {
    "time_measured": { "value": "2026-07-01T10:32:15Z", "format": "RFC3339" },
    "position": {
      "longitude": -45.876,
      "latitude": -23.210,
      "altitude": { "value": 115.2, "reference": "W84", "units": "M" },
      "accuracy_h": "HA10m",
      "accuracy_v": "VA10m"
    },
    "velocity": {
      "speed": 8.5,
      "units_speed": "MetersPerSecond",
      "track": 270.0
    }
  },
  "next_telemetry_opportunity": { "value": "2026-07-01T10:32:25Z", "format": "RFC3339" }
}
```

This endpoint must only be available when the OIR is in `Nonconforming` or `Contingent` state. You may return `404` in other states.

---

### 6.1.6 `GET /uss/flights`

**Purpose:** Return basic flight information for all active drones in a given geographic view area. This is the primary Remote ID polling endpoint.

**Required scope (caller must have):** `rid.display_provider`

**Query parameters:**
- `view` — Bounding box as `lat1,lng1,lat2,lng2` (southwest and northeast corners).
- `recent_positions_duration` — How many seconds of recent position history to include (optional).

**Response body:**
```json
{
  "timestamp": { "value": "2026-07-01T10:32:15Z", "format": "RFC3339" },
  "flights": [
    {
      "id": "flight-uuid-here",
      "aircraft_type": "Helicopter",
      "current_state": {
        "timestamp": { "value": "2026-07-01T10:32:15Z", "format": "RFC3339" },
        "timestamp_accuracy": 0.1,
        "position": {
          "lat": -23.2071,
          "lng": -45.8750,
          "alt": 115.2,
          "accuracy_h": "HA10m",
          "accuracy_v": "VA10m",
          "extrapolated": false
        },
        "track": 270.0,
        "speed": 8.5,
        "speed_accuracy": "SA3mps",
        "vertical_speed": 0.0,
        "operational_status": "Airborne"
      },
      "recent_positions": [ ... ]
    }
  ],
  "no_isas_present": false
}
```

**Update frequency:** The data returned must reflect the drone's actual position, updated at most every **10 seconds**.

---

### 6.1.7 `GET /uss/flights/{id}/details`

**Purpose:** Return detailed information for a specific flight, including UAS identification and operator data.

**Required scope (caller must have):** `rid.display_provider`

**Response body:**
```json
{
  "details": {
    "id": "flight-uuid-here",
    "uas_id": {
      "registration_id": "PR-XXXX"
    },
    "operator_id": "operator-registration-id",
    "operator_location": {
      "position": { "lat": -23.208, "lng": -45.878 },
      "altitude": { "value": 0, "reference": "W84", "units": "M" }
    },
    "operation_description": "Package delivery - Sector A",
    "auth_data": {
      "format": 0,
      "data": ""
    }
  }
}
```

---

## 6.2 Additional Required Endpoints

These endpoints are required by the qualification rules (`uss-qualification-rules.md`) and are called during homologation testing and normal operations.

---

### 6.2.1 `GET /version`

**Purpose:** Return the current deployed version of your USS software.

**No authentication required** (or use your standard validation).

**Response body:**
```json
{
  "version": "1.4.2"
}
```

---

### 6.2.2 `GET /diagnostics/time`

**Purpose:** Return the current system time and NTP synchronization status. Used by DECEA to verify your system clock is properly synchronized.

**Response body:**
```json
{
  "system_time": "2026-07-01T10:32:15.482Z",
  "ntp_sync": {
    "synchronized": true,
    "source": "ntp.decea.gov.br",
    "stratum": 2,
    "offset_ms": 38,
    "last_sync": "2026-07-01T10:32:05.000Z"
  },
  "timestamp_format": "ISO 8601"
}
```

---

### 6.2.3 `POST /telemetry`

**Purpose:** Accept drone telemetry data injection during DECEA's homologation testing. DECEA uses this to simulate drone position updates and test your conformance monitoring logic.

**Request body:**
```json
{
  "flight_id": "a8c4af2a-6640-41d9-b8e7-719fd19a2fce",
  "aircraft_type": "Helicopter",
  "operational_intent_id": "<id-of-the-operational-intent>",
  "position": {
    "timestamp": { "value": "2026-07-01T10:32:00Z", "format": "RFC3339" },
    "lat": -23.207184,
    "lng": -45.875054,
    "alt": 115.0,
    "accuracy_h": "HA10m",
    "accuracy_v": "VA10m",
    "extrapolated": false
  },
  "operational_status": "Airborne",
  "track": 270.0,
  "speed": 10.0,
  "vertical_speed": 0.0,
  "test_metadata": {
    "scenario_id": "VOL4D-EXIT-REENTRY-59S",
    "event": "exit_volume",
    "t_offset_seconds": 0
  }
}
```

---

## 6.3 Homologation/Testing Endpoints

These endpoints are defined in `flights.yaml`, `injection.yaml`, and `versioning.yaml`. They are **only called by DECEA's automated testing framework** during homologation. You implement them, but they are not used in production operations.

---

### 6.3.1 Flight Planning Testing (`flights.yaml`)

These endpoints simulate the user experience of creating and managing flight plans, allowing DECEA's test framework to exercise your OIR creation and management logic.

| Method | Path | Description |
|--------|------|-------------|
| `GET` | `/status` | Return readiness status of your testing interface. |
| `POST` | `/clear_area_requests` | Instruct your USS to cancel all flight plans in a given area. |
| `PUT` | `/flight_plans/{flight_plan_id}` | Create or update a flight plan (simulates a user action). |
| `DELETE` | `/flight_plans/{flight_plan_id}` | Delete a flight plan. |
| `GET` | `/user_notifications` | Return notifications received by the virtual user. |

**Scopes:**
- `interuss.flight_planning.direct_automated_test` — For test director operations (clear area, delete, status).
- `interuss.flight_planning.plan` — For virtual user operations (create/update, notifications).

---

### 6.3.2 Remote ID Data Injection (`injection.yaml`)

These endpoints allow DECEA's test framework to inject simulated drone telemetry directly into your USS, to test your Remote ID serving logic.

| Method | Path | Description |
|--------|------|-------------|
| `PUT` | `/tests/{test_id}` | Create a test: inject one or more simulated flights with telemetry sequences. |
| `DELETE` | `/tests/{test_id}/{version}` | Delete a test and remove all injected data. |
| `GET` | `/user_notifications` | Return notifications received by the virtual user during the test. |

**Scope:** `rid.inject_test_data`

**Example injection request:**
```json
{
  "requested_flights": [
    {
      "injection_id": "test-flight-001",
      "aircraft_type": "Helicopter",
      "telemetry": [
        {
          "timestamp": { "value": "2026-07-01T10:00:00Z", "format": "RFC3339" },
          "position": { "lat": -23.2071, "lng": -45.8750, "alt": 100.0 },
          "track": 90.0,
          "speed": 10.0,
          "vertical_speed": 0.0,
          "operational_status": "Airborne",
          "accuracy_h": "HA10m",
          "accuracy_v": "VA10m"
        }
      ],
      "details_responses": [
        {
          "effective_after": "2026-07-01T09:59:00Z",
          "details": {
            "id": "test-flight-001",
            "operator_id": "OP-TEST-123",
            "uas_id": { "registration_id": "PR-TEST01" }
          }
        }
      ]
    }
  ]
}
```

---

### 6.3.3 Versioning (`versioning.yaml`)

| Method | Path | Description |
|--------|------|-------------|
| `GET` | `/versions/{system_identity}` | Return the version of a specific system component. |

**Scope:** `interuss.versioning.read_system_versions`

**Example:**
```
GET /versions/br.mil.decea.brutm.uss.v1
```
```json
{
  "system_identity": "br.mil.decea.brutm.uss.v1",
  "system_version": "1.4.2"
}
```

---

## 6.4 Summary of All Required Endpoints

| Endpoint | Type | When Required |
|----------|------|---------------|
| `GET /uss/v1/operational_intents/{entityid}` | Production | Always |
| `POST /uss/v1/operational_intents` | Production | Always |
| `GET /uss/v1/constraints/{entityid}` | Production | Always |
| `POST /uss/v1/constraints` | Production | Always |
| `GET /uss/v1/operational_intents/{entityid}/telemetry` | Production | When OIR is Nonconforming/Contingent |
| `GET /uss/flights` | Production (Remote ID) | When any flight is Activated |
| `GET /uss/flights/{id}/details` | Production (Remote ID) | When any flight is Activated |
| `GET /version` | Operations | Always |
| `GET /diagnostics/time` | Operations | Always |
| `POST /telemetry` | Operations/Testing | During homologation |
| `GET /status` | Testing | Homologation |
| `POST /clear_area_requests` | Testing | Homologation |
| `PUT /flight_plans/{id}` | Testing | Homologation |
| `DELETE /flight_plans/{id}` | Testing | Homologation |
| `GET /user_notifications` | Testing | Homologation |
| `PUT /tests/{test_id}` | Testing (Remote ID) | Homologation |
| `DELETE /tests/{test_id}/{version}` | Testing (Remote ID) | Homologation |
| `GET /versions/{system_identity}` | Testing | Homologation |

# Chapter 7 — Non-Functional Requirements

This chapter defines the non-functional requirements (NFRs) that your USS must satisfy to be approved for the BR-UTM ecosystem. These are enforced during homologation and are continuously expected in production.

Failure to meet these requirements can result in:
- Rejection during homologation.
- Operational incidents (missed emergency notifications, incorrect timestamps, clock drift).
- Potential deauthorization from the ecosystem.

---

## 7.1 Time Synchronization (NTP)

**Requirement:** Your USS's system clock must be synchronized with DECEA's NTP server with a precision of **≤ 5 seconds**.

| Parameter | Requirement |
|-----------|-------------|
| NTP Server | `ntp.decea.gov.br` |
| Maximum offset | ≤ 5 seconds |
| Authentication | Required (NTP authentication, integrity and anti-spoofing protection) |

**All timestamps** generated by your system (for OIR time windows, telemetry, notifications, and audit logs) must be derived from this synchronized clock.

**Verification endpoint:** `GET /diagnostics/time`

Your `GET /diagnostics/time` endpoint must return current sync status, including the NTP source, stratum, offset in milliseconds, and last synchronization time. DECEA will call this endpoint during homologation to verify compliance.

```json
{
  "system_time": "2026-07-01T10:32:15.482Z",
  "ntp_sync": {
    "synchronized": true,
    "source": "ntp.decea.gov.br",
    "stratum": 2,
    "offset_ms": 38,
    "last_sync": "2026-07-01T10:32:05.000Z"
  },
  "timestamp_format": "ISO 8601"
}
```

---

## 7.2 Timestamp Format

**Requirement:** All dates and times stored or transmitted by your USS must conform to **ISO 8601 (RFC 3339)** with the **UTC timezone** (expressed as `Z` suffix).

| Parameter | Requirement |
|-----------|-------------|
| Format | ISO 8601 / RFC 3339 |
| Timezone | UTC (`Z`) |
| Examples | `"2026-07-01T10:32:15Z"` or `"2026-07-01T10:32:15.482Z"` |

**Never** use local time or non-UTC offsets in any field transmitted to the DSS, to other USSs, or in any API response. This includes:
- OIR time windows (`time_start`, `time_end`)
- Volume4D time bounds
- Telemetry timestamps
- ISA time windows
- Audit log entries

When wrapping timestamps in the BR-UTM `Time` structure:
```json
{ "value": "2026-07-01T10:32:15Z", "format": "RFC3339" }
```

---

## 7.3 Notification Latency

**Requirement:** When your USS creates, updates, or deletes an OIR or Constraint in the DSS and receives a list of subscribers to notify, it must send the `POST /uss/v1/operational_intents` (or `POST /uss/v1/constraints`) notifications to each subscriber within:

| Metric | Requirement |
|--------|-------------|
| Target latency | ≤ 5 seconds |
| Required percentile | ≥ 95% of cases |

This means that in 95% of all notification events, the subscriber USS must receive the notification within 5 seconds of your DSS write completing. Up to 5% of cases may exceed this threshold (e.g., due to transient network conditions).

**Implementation guidance:**
- Use asynchronous notification dispatch to avoid blocking the main OIR creation flow.
- Implement reasonable timeouts (e.g., 5–10 seconds per subscriber) so a slow subscriber doesn't delay notifications to others.
- Fire notifications in parallel when there are multiple subscribers.

---

## 7.4 Conformance Monitoring Response Time

**Requirement:** When your USS detects that a drone has left its declared OIR volumes, it must:

| Action | Time Limit |
|--------|------------|
| Detect position out-of-volume | ≤ 10 seconds after last telemetry update shows deviation |
| Update DSS with `Nonconforming` state | ≤ 5 seconds after detection |

This means the worst-case end-to-end timeline from drone position deviation to DSS update is **15 seconds**.

Additionally:
- After **60 continuous seconds** in `Nonconforming` state, the USS must transition to `Contingent`.
- Both state transitions must include notification to all subscribers in the area.

---

## 7.5 Telemetry Update Frequency

**Requirement:** Your USS must update the telemetry data served at `GET /uss/flights` at an interval of:

| Metric | Requirement |
|--------|-------------|
| Maximum update interval | 10 seconds |
| When required | During any `Activated`, `Nonconforming`, or `Contingent` operation |

In other words: the position data returned by `GET /uss/flights` must never be more than 10 seconds stale for an active flight.

---

## 7.6 Geospatial Intersection Precision

**Requirement:** Your USS must be able to calculate 4D intersection between volumes with:

| Parameter | Requirement |
|-----------|-------------|
| Horizontal precision | 1 centimeter (1 cm) |
| Dimensions | Latitude, longitude, altitude, time |

This precision is required for accurate conflict detection between OIRs and between OIRs and Constraints. Using imprecise intersection algorithms (e.g., simple bounding box checks) is not acceptable and will fail homologation scenarios.

Your intersection logic must handle both **polygon** and **circle** geometries, and combinations thereof.

---

## 7.7 Audit Logging

**Requirement:** Your USS must maintain comprehensive audit logs of all safety-critical operations. All audit log entries must use timestamps derived from the NTP-synchronized clock.

The audit log must capture:
- All OIR state transitions (creation, activation, nonconformance, contingency, deletion).
- All peer-to-peer notifications sent and received.
- All telemetry positions recorded during active operations.
- All conflict detections and deconfliction actions taken.
- All token validation results for inbound requests.

These logs must be retained for traceability and may be requested by DECEA during incident investigations.

---

## 7.8 Subscription Continuity

**Requirement:** Your USS must maintain an active subscription for any area where you have an active OIR. This ensures you receive notifications about changes in the airspace around your operations.

- Subscriptions must remain active for the full duration of the OIR's time window.
- If a subscription is lost (e.g., due to a DSS connectivity issue), your USS must re-create it as soon as connectivity is restored.
- Your USS must process all incoming notifications and re-evaluate its conflict status whenever a new or updated OIR/Constraint arrives in the subscribed area.

---

## 7.9 DSS Discoverability

**Requirement:** An OIR may only transition between states (`Accepted`, `Activated`, `Nonconforming`, `Contingent`) if it is currently discoverable by other USSs via the DSS.

This means:
- Before transitioning state, your OIR must exist in the DSS with the correct `extents`, `uss_base_url`, and `subscription_id`.
- If your DSS write fails, you must not proceed with the state transition.
- If your USS cannot reach the DSS, active flights must not proceed to activation.

---

## 7.10 Summary Table

| NFR | Requirement |
|-----|-------------|
| NTP synchronization | `ntp.decea.gov.br`, ≤5s offset, authenticated |
| Timestamp format | ISO 8601 / RFC 3339, UTC (`Z`) |
| Notification latency | ≤5 seconds in ≥95% of cases |
| Nonconformance detection | ≤10 seconds |
| Nonconformance DSS update | ≤5 seconds after detection |
| Contingent trigger | After 60 continuous seconds Nonconforming |
| Telemetry update interval | ≤10 seconds for active flights |
| Geospatial intersection precision | 1 cm |
| Audit logs | All safety-critical events, NTP-derived timestamps |
| Subscription continuity | Active for full OIR duration |
| DSS discoverability | Required before any state transition |

# Chapter 8 — Homologation

This chapter describes the homologation (validation) process that a company must complete before receiving a production API Key and being authorized to operate in the BR-UTM ecosystem.

---

## 8.1 What Is Homologation?

Homologation is DECEA's process for validating that a USS implementation:
- Correctly implements all required APIs (as defined in the OpenAPI specifications).
- Behaves correctly in all defined operational scenarios.
- Meets all non-functional requirements (timing, precision, synchronization).
- Is ready to operate safely alongside other USSs in the live ecosystem.

The process is **primarily manual** — conducted by DECEA engineers who run test scenarios against your deployed system. DECEA may also use **internal automated testing tools** (`uss_qualifier` or equivalent) to exercise specific scenarios programmatically.

---

## 8.2 Prerequisites for Homologation

Before requesting homologation, your USS must:

1. **Implement all mandatory production endpoints** (see [Chapter 6](./06-apis-to-implement.md)):
   - `GET /uss/v1/operational_intents/{entityid}`
   - `POST /uss/v1/operational_intents`
   - `POST /uss/v1/constraints`
   - `GET /uss/flights`
   - `GET /uss/flights/{id}/details`
   - `GET /version`
   - `GET /diagnostics/time`
   - `POST /telemetry`

2. **Implement all testing endpoints**:
   - All `flights.yaml` endpoints
   - All `injection.yaml` endpoints
   - The `versioning.yaml` endpoint

3. **Be deployed and reachable from the internet** with a valid HTTPS base URL.

4. **Be registered in the Sandbox** with a development API Key and able to interact with the Sandbox DSS.

5. **Satisfy all non-functional requirements** (see [Chapter 7](./07-non-functional-requirements.md)), especially NTP synchronization.

---

## 8.3 Requesting Homologation

To initiate the homologation process:

1. Contact DECEA through the official support channels:
   - **Mattermost** (developer channel)
   - **Central de Ajuda** (ticketing system)

2. Provide:
   - Your company name and CNPJ.
   - The version of your software being submitted.
   - The publicly accessible base URL of your USS.
   - Contact details for the technical team.

3. DECEA will schedule the homologation session and provide:
   - A testing API Key (granting access to the test ecosystem).
   - The URL of the test ecosystem (if separate from the main Sandbox).
   - The test scenario list to prepare for.

---

## 8.4 What DECEA Tests

DECEA validates your USS against 18 defined scenarios. Each scenario tests one or more functional and non-functional requirements.

### Scenario Matrix

| # | Scenario | Key Requirements Tested |
|---|----------|------------------------|
| 1 | Register an operation in an empty area | Auth (8.1), NTP, notifications (8.2), OIR creation (8.3), conflict check (8.4), DSS discoverability |
| 2 | Register an operation near a non-intersecting Constraint | + Constraint query and processing (8.7) |
| 3 | Register an operation near an intersecting Constraint | + 4D intersection detection, deconfliction (8.5), operator notification |
| 4 | Register an operation near a non-intersecting OIR | + Peer-to-peer OIR details fetch |
| 5 | Register an operation near an intersecting OIR | + Deconfliction, operator notification |
| 6 | Delete an operation (OIR) | + Deletion notification to subscribers |
| 7 | Activate an operation conflicting with another active OIR at the same priority | + Pre-activation conflict check (8.6), blocking activation |
| 8 | Activate an operation conflicting with an active OIR at higher priority | + Deconfliction before activation |
| 9 | Activate an operation conflicting with an active OIR at lower priority | + Correctly allows activation when lower priority conflict exists |
| 10 | DECEA creates a Constraint over an existing Accepted OIR | + Reaction to constraint notification (8.11), deconfliction or state change |
| 11 | DECEA creates a Constraint over an existing Activated OIR | + Immediate reaction (Nonconforming or deconfliction) |
| 12 | DECEA's USS activates a higher-priority OIR over an active OIR | + Priority-based conflict resolution, deconfliction |
| 13 | USS creates an ISA when the OIR is activated | + Remote ID ISA lifecycle (8.8) |
| 14 | USS shares drone position during an active operation | + Telemetry serving at `/uss/flights` and `/uss/flights/{id}/details` |
| 15 | USS updates drone position every 10 seconds | + Update frequency requirement |
| 16 | Drone position exits OIR volume → transition to Nonconforming | + Conformance monitoring timing (≤10s detection, ≤5s DSS update) |
| 17 | Drone position exits OIR → Nonconforming → returns → back to Activated | + Recovery from non-conformance |
| 18 | Drone position exits OIR → Nonconforming for 60s → Contingent | + Full emergency state machine |

### Requirement Mapping

| Code | Full Requirement |
|------|-----------------|
| RF 1 | 4D geospatial intersection calculation, 1 cm precision |
| RF 2 | DSS discoverability before state transitions |
| RF 3 | Automatic high priority for critical situations |
| RF 4 | Transition to Accepted only if no higher-priority conflict |
| RF 5 | Pre-activation final conflict check |
| RF 6 | Continuous situational awareness via subscriptions |
| RF 7 | Automatic conflict notification to operators |
| RF 8 | CMSA-only role for Nonconforming/Contingent transitions |
| RF 9 | Constraint intersection analysis before OIR creation |
| RF 10 | Continuous constraint monitoring during operations |
| RF 11 | Automatic propagation of constraint notifications to affected operators |
| RF 12 | Full telemetry recording during conformance monitoring |
| RF 13 | Aircraft position updated and available within ≤10 seconds |
| RNF 1 | NTP synchronization to `ntp.decea.gov.br` |
| RNF 2 | Consistent timestamps from synchronized clock |
| RNF 3 | Notification latency ≤5s in ≥95% of cases |
| RNF 4 | ISO 8601 / RFC 3339 with UTC timezone |
| RNF 5 | Audit logs with NTP-derived timestamps |

---

## 8.5 How the Automated Testing Works

For scenarios involving Remote ID (scenarios 13–15), DECEA's test framework calls your `injection.yaml` endpoints to inject simulated telemetry:

1. DECEA's framework calls `PUT /tests/{test_id}` with a sequence of simulated aircraft positions.
2. Your USS processes these as if they were real drone telemetry and makes them available via `GET /uss/flights`.
3. DECEA's framework queries `GET /uss/flights` and `GET /uss/flights/{id}/details` to verify the data is correct and timely.
4. After the test, `DELETE /tests/{test_id}/{version}` clears the injected data.

For scenarios involving flight planning (scenarios 1–12), DECEA's framework uses your `flights.yaml` endpoints:

1. DECEA's framework calls `PUT /flight_plans/{id}` to simulate a user creating a flight plan.
2. Your USS translates this into an OIR creation in the DSS and notifies subscribers.
3. DECEA validates the DSS state and your subscriber notifications.
4. `POST /clear_area_requests` may be used to reset the test environment between scenarios.

For conformance monitoring scenarios (16–18), DECEA combines both `injection.yaml` (to inject positions outside the volume) and `flights.yaml` (to set up the OIR), then monitors whether your USS correctly transitions states and notifies within the required time limits.

---

## 8.6 Testing Environment Access

During homologation, DECEA provides a dedicated test environment:
- A test API Key with access to the test ecosystem.
- Possibly a separate test DSS instance.
- Access credentials for DECEA's monitoring systems (Interface UTM) to observe your operations during the test.

This testing key and environment are separate from your normal development (Sandbox) key.

---

## 8.7 After Successful Homologation

Upon passing all scenarios:

1. DECEA grants your software the **U1 permission level** for the **production environment**.
2. You receive a **production API Key** tied to your validated software version.
3. You can now:
   - Create UTM Zones in the production Portal UTM.
   - Begin operating flights in production.
   - Generate sub-keys for third-party operators using your software.

### Third-Party Sub-Keys

If your USS software is a platform sold to third-party drone operators:
- Your company (as the validated software owner) creates **sub-API Keys** for each third-party client.
- The third-party client uses their sub-key to authenticate and to create their own UTM Zones.
- All operations under sub-keys are still associated with your validated software version.

---

## 8.8 Re-Homologation

If you release a **new major version** of your USS software with significant architectural changes, a new homologation process may be required. Contact DECEA to determine whether re-validation is needed for your specific changes.

Minor updates and bug fixes that do not affect the API contract or safety-critical behaviors typically do not require re-homologation.

---

## 8.9 Homologation Checklist

Use this checklist before requesting homologation:

### APIs
- [ ] `GET /uss/v1/operational_intents/{entityid}` implemented and tested
- [ ] `POST /uss/v1/operational_intents` implemented (correctly handles creation, update, deletion)
- [ ] `GET /uss/v1/constraints/{entityid}` implemented
- [ ] `POST /uss/v1/constraints` implemented
- [ ] `GET /uss/v1/operational_intents/{entityid}/telemetry` implemented (active in Nonconforming/Contingent)
- [ ] `GET /uss/flights` implemented with correct data structure
- [ ] `GET /uss/flights/{id}/details` implemented
- [ ] `GET /version` implemented
- [ ] `GET /diagnostics/time` implemented with NTP status
- [ ] `POST /telemetry` implemented
- [ ] All `flights.yaml` endpoints implemented
- [ ] All `injection.yaml` endpoints implemented
- [ ] `versioning.yaml` endpoint implemented

### Functional
- [ ] OIR creation → DSS → subscriber notification flow works end-to-end
- [ ] OIR state transitions (Accepted → Activated → Nonconforming → Contingent) work correctly
- [ ] Pre-activation conflict check is performed
- [ ] Constraint queries and processing are implemented
- [ ] ISA is created on activation and deleted on flight closure
- [ ] Incoming `POST /uss/v1/operational_intents` notifications trigger conflict re-evaluation
- [ ] OIR deletion triggers subscriber notification (with `operational_intent` omitted)
- [ ] Nonconforming detected within 10 seconds
- [ ] DSS updated within 5 seconds of Nonconforming detection
- [ ] Contingent triggered after 60 seconds of Nonconforming

### Non-Functional
- [ ] NTP synchronized to `ntp.decea.gov.br` with ≤5s offset
- [ ] All timestamps in ISO 8601 / RFC 3339 / UTC
- [ ] Subscriber notifications sent within 5 seconds in ≥95% of cases
- [ ] Telemetry data updated at most every 10 seconds
- [ ] 4D intersection precision at 1 cm
- [ ] Audit logs in place with NTP-derived timestamps
- [ ] All inbound JWT tokens validated (signature, expiry, audience, scope)
- [ ] System deployed publicly on HTTPS

# Ensaio Operacional 1 - Março 2024 (Onboarding)

Onboarding para novos provedores do serviço de Tracking para o Ensaio de mar/2024

# Introdução

### Tracking / Network Remote ID

Tracking, Network Remote ID, ou simplesmente Net-RID, é um serviço que permite uma aeronave não tripulada (UAS) prover sua localização, identificação de seu operador e outras informações operacionais relevantes, que podem ser obtidas por entidades autorizadas como órgãos fiscalizadores, outros provedores operando na mesma área, ou até mesmo a população em geral.

Para fornecer o serviço de Net-RID, o provedor deve ser capaz de trocar informações com outros provedores utilizando a interface definida no padrão internacional [ASTM 3411-22a - Standard Specification for Remote ID and Tracking](https://www.astm.org/f3411-22a.html). Para possibilitar a interoperabilidade dos participantes e provedores, deve ser fornecido o serviço de "Service Discovery", que permite a descoberta de outros provedores atuando na mesma área.

<div drawio-diagram="125"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2023-12/drawing-3-1702641413.png" alt=""/></div>

Diagrama: Modelo conceitual

A ASTM também indica a seguinte documentação de API, como sugestão de interfaces para comunicação entre os serviços acima, que pode ser encontrada no padrão OpenAPI em: [https://github.com/uastech/standards/tree/astm\_rid\_api\_2.1/remoteid](https://github.com/uastech/standards/tree/astm_rid_api_2.1/remoteid)

Para nosso ensaio, seguiremos inicialmente a proposta acima, com possibilidade de alterações conforme o grupo achar necessário.

### Service Discovery

Conforme previsto no padrão ASTM F3411-22a, o service discovery deve possibilitar com que provedores descubram outros provedores atuando na mesma região, para que estes possam se comunicar. No cenário de comunicação HTTP, descobrir um provedor significa conhecer seu endereço web (url) para poder enviar requisições HTTP, em endpoints pré-definidos.

Para isso, a Linux Foundation possui um projeto chamado [InterUSS Platform](https://interussplatform.org/) que possui uma implementação do service discovery de maneira distribuída e sincronizada, denominado DSS (Discovery and Synchronization Service). Distribuído significa que várias entidades podem subir suas próprias instâncias do serviço, descentralizando e garantindo que não exista um ponto único de falha. Sincronizado significa que mesmo que haja múltiplas instâncias, todas possuem as mesmas informações ao mesmo tempo.

No escopo do ensaio, será utilizado o DSS sem nenhuma modificação inicial. Porém, para simplificação dos testes, o serviço possuirá somente uma instância, provida pelo DECEA. Isso permite que os potenciais provedores possam focar em implementar suas responsabilidades específicas e agilizar os processos do ensaio.

### Serviços BR-UTM

Seguindo a matriz de serviços que devem ser atendidos pelo BR-UTM, ao final do ensaio esperamos atender de forma completa o serviço de Discovery Service com o DSS, e o de Tracking and Location Service com o Net-RID. Também esperamos atender de forma parcial o Activity Reporting System com o Display Service do Net-RID.

<div drawio-diagram="127"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2023-12/drawing-3-1702647159.png" alt=""/></div>

# Onboarding Service Provider

No contexto do serviço de Tracking, um Service Provider é um provedor USS que é capaz de receber dos seus drones os dados de localização em tempo real, e disponibilizar esses dados on demand em uma API também em tempo real.

### Pré-requisitos técnicos

Para um USS se tornar um provedor de Tracking existem os seguintes pré-requisitos técnicos que não estão no escopo dessa documentação, ficando a critério do provedor como implementar esses pré-requisitos:

1. Possuir um servidor HTTP para solicitar e receber as requisições listadas abaixo
2. Possuir infraestrutura para obter os dados de posição instantânea do drone. Esses dados devem estar disponíveis em tempo real no servidor HTTP

### Autenticação

Para o ensaio, a autenticação será feita em um serviço OAuth centralizado do DECEA, ainda a ser descrito.

### Fluxograma

<div drawio-diagram="173"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2024-01/drawing-3-1704906440.png" alt=""/></div>

### Endpoints

A dinâmica de comunicação entre Service Provider, Display Provider e DSS está descrita na norma ASTM 3411-22a. Para facilitar o entendimento, alguns possíveis cenários de utilização estão descritos na página [Cenários](https://servicos2.decea.mil.br/br-utm/wiki/books/documentacao-tecnica/page/cenarios "Cenários").

O padrão seguido no ensaio será o descrito em [https://github.com/uastech/standards/tree/astm\_rid\_api\_2.1/remoteid](https://github.com/uastech/standards/tree/astm_rid_api_2.1/remoteid)

Conforme o padrão OpenAPI acima, os endpoints que o Service Provider precisará prover

---

<table border="1" class="align-center" id="bkmrk-get-%2Fuss%2Fflights" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 75px;"></col><col></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(97, 175, 254);">**GET**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/uss/flights</td></tr></tbody></table>

Endpoint onde os Display Providers obterão os dados de tracking das aeronaves sob responsabilidade do Service Provider em uma determinada área

<details id="bkmrk-query-parameters-vie"><summary>Query Parameters</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 193.969px;"><colgroup><col style="width: 33.3333%;"></col><col style="width: 33.3333%;"></col><col style="width: 33.3333%;"></col></colgroup><tbody><tr style="height: 113.781px;"><td style="height: 113.781px;">view</td><td style="height: 113.781px;">Área da solicitação, representada por dois pontos no formato `lat1,lng1,lat2,lng2`. Os pontos são as extremidades da diagonal de um quadrado, onde esse quadrado representa a área da solicitação</td><td style="height: 113.781px;">29.978,31.132,29.980,31.135</td></tr><tr style="height: 80.1875px;"><td style="height: 80.1875px;">recent\_positions\_duration</td><td style="height: 80.1875px;">Se for maior que zero, indica que a requisição deve enviar todas as posições do drone nos últimos N segundos. Valor máximo: 60.

Se for zero, indica que deve ser enviado apenas a última posição do drone

</td><td style="height: 80.1875px;">60</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22timestam"><summary>Response</summary>

```json
{
  "timestamp": {
    "value": "1985-04-12T23:20:50.52Z",
    "format": "RFC3339"
  },
  "flights": [
    {
      "id": "PR-333334433.0dfe0e82-fd7a-44d9-af17-7fdd42751b45",
      "aircraft_type": "Helicopter",
      "current_state": RIDAircraftState,
      "operating_area": OperatingArea,
      "simulated": false,
      "recent_positions" = [ RIDRecentAircraftPosition ]
    }
  ],
  "no_isas_present": false
}
```

<table border="1" style="border-collapse: collapse; width: 100%; height: 438.109px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px;">timestamp</td><td style="height: 29.7969px;">Horário em que o Service Provider recebeu a requisição</td></tr><tr style="height: 124.953px;"><td style="height: 124.953px;">flights.id</td><td style="height: 124.953px;">ID único do provedor que identifica um voo em particular. Deverá vir no formato: "UAS\_ID.FLIGHT\_ID", onde UAS\_ID é código SISANT da aeronave, e FLIGHT\_ID é o uuid da solicitação do voo realizada no ECO-UTM.

</td></tr><tr style="height: 63.3906px;"><td style="height: 63.3906px;">flights.aircraft\_type</td><td style="height: 63.3906px;">Tipo de aeronave no padrão ICAO. Para drones, o tipo = Helicopter. Para drones de asa fixa que conseguem decolar verticalmente, o tipo = "HybridLift"</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">flights.current\_state</td><td style="height: 29.7969px;">Dados do tracking de fato da aeronave, no momento atual.</td></tr><tr style="height: 63.3906px;"><td style="height: 63.3906px;">flights.operating\_area</td><td style="height: 63.3906px;">A área que a aeronave se encontra. Deve ser usado apenas quando o campo "flights.current\_state" não está preenchido.</td></tr><tr style="height: 63.3906px;"><td style="height: 63.3906px;">flights.recent\_positions</td><td style="height: 63.3906px;">Lista de posições recentes da aeronave. Deve ser informado apenas quando as "recent\_positions" foram requisitadas.</td></tr><tr style="height: 63.3906px;"><td style="height: 63.3906px;">no\_isas\_present</td><td style="height: 63.3906px;">Indica se o provedor não possui nenhuma ISA na região informada. Caso esse valor retorne verdadeiro, o requisitante deve parar de realizar requisições para a área.</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fuss%2Fflights%2F%7Bid" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.7969px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: #61affe;">**GET**</td><td class="align-left" style="height: 29.7969px; border-width: 0px;">/uss/flights/{id}/details</td></tr></tbody></table>

Endpoint onde os Display Providers obterão dados específicos de um determinado voo

<details id="bkmrk-path-parameters-id-i"><summary>Path Parameters</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 29.7969px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 25.0321%;"></col><col style="width: 25.0321%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px;">id</td><td style="height: 29.7969px;">ID único do provedor para identificar o voo</td><td>b41f2785-1182-4c2e-82d5-f72f754b3fe2.0dfe0e82-fd7a-44d9-af17-7fdd42751b45</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22details%22"><summary>Response</summary>

```json
{
  "details": {
    "id": "b41f2785-1182-4c2e-82d5-f72f754b3fe2.0dfe0e82-fd7a-44d9-af17-7fdd42751b45",
    },
    "uas_id": {
      "registration_id": "PR-333334433",
    },
    "operator_id": "HUKMBB",
    "operator_location": {
      "position": {
        "lng": -118.456,
        "lat": 34.123
      },
      "altitude": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      },
      "altitude_type": "Takeoff"
    },
    "operation_description": "Descrição do voo, mesma descrição informada no SARPAS"
  }
}
```

<table border="1" style="border-collapse: collapse; width: 100%; height: 178.781px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px;">uas\_id</td><td style="height: 29.7969px;">Código SISANT da aeronave</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">operator\_id</td><td style="height: 29.7969px;">Código SARPAS do operador</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">operator\_location</td><td style="height: 29.7969px;">Localização do operador. Opcional</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">operation\_description</td><td style="height: 29.7969px;">Descrição da Operação conforme solicitação no SARPAS</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fuss%2Fidentificat" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.7969px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: #61affe;">**GET**</td><td class="align-left" style="height: 29.7969px; border-width: 0px;">/uss/identification\_service\_areas/{id}</td></tr></tbody></table>

Endpoint para obter o volume 4D de uma ISA controlada pelo Service Provider

<details id="bkmrk-path-parameters-id-u"><summary>Path Parameters</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 29.7969px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 25.0321%;"></col><col style="width: 25.0321%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px;">id</td><td style="height: 29.7969px;">UUID da área possuída pelo provedor</td><td>UUID</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22extents%22"><summary>Response</summary>

```json
{
  "extents": {
    "volume": {
      "outline_circle": {
        "center": {
          "lng": -118.456,
          "lat": 34.123
        },
        "radius": {
          "value": 300.183,
          "units": "M"
        }
      },
      "outline_polygon": {
        "vertices": [
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          }
        ]
      },
      "altitude_lower": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      },
      "altitude_upper": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      }
    },
    "time_start": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "time_end": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    }
  }
}
```

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>volume</td><td>Volume 4D da área específica</td></tr></tbody></table>

</details>### Interação com DSS

O Service Provider, conforme definido no padrão ASTM3411-22a, deve criar entidades de área 4D denominadas Identification Service Area (ISA), onde este proverá o serviço de tracking. Os endpoints expostos pelo DSS estão descritos no arquivo OpenAPI descrito acima.

---

Como exemplo, o endpoint abaixo é onde o Service Provider realizará a criação da ISA no DSS:

<table border="1" class="align-center" id="bkmrk-put-%2Fdss%2Fidentificat" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.7969px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: #fca130;">**PUT**</td><td class="align-left" style="height: 29.7969px; border-width: 0px;">/dss/identification\_service\_area/{id}</td></tr></tbody></table>

Endpoint exposto pelo DSS onde o Service Provider realizará a criação da ISA. Essa área deve ser idêntica à area solicitada e aprovada no Sarpas

<details id="bkmrk-path-param-id-uuid-g"><summary>Path Param</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>id</td><td>UUID da ISA. Deve ser o mesmo UUID devolvido pelo ECO-UTM após a criação da solicitação de voo.  
</td></tr></tbody></table>

</details><details id="bkmrk-body-%7B-%22extents%22%3A-%7B-"><summary>Body</summary>

```json
{
  "extents": {
    "volume": {
      "outline_circle": {
        "center": {
          "lng": -118.456,
          "lat": 34.123
        },
        "radius": {
          "value": 300.183,
          "units": "M"
        }
      },
      "outline_polygon": {
        "vertices": [
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          }
        ]
      },
      "altitude_lower": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      },
      "altitude_upper": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      }
    },
    "time_start": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "time_end": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    }
  },
  "uss_base_url": "https://example.com/rid"
}
```

Campos notáveis

<table border="1" style="border-collapse: collapse; width: 100%; height: 76.3907px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 46.5938px;"><td style="height: 46.5938px;">volume</td><td style="height: 46.5938px;">Polígono **OU** círculo da área, idêntico ao definido no SARPAS</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">altitude\_lower, altitude\_upper</td><td style="height: 29.7969px;">Altitude geodésica (WSG84, W84) máxima e mínima em metros.

</td></tr><tr><td>time\_start, time\_end</td><td>Horário de início e fim da área. Todos os horários devem estar no timezone Zulo (UTC+0). O único formato suportado é "RFC3339"

</td></tr><tr><td>uss\_base\_url</td><td>URL a qual o Service Provider irá responder à solicitações. Não deve conter uma barra '/' ao final. Sugere-se utilizar uma URL e não um IP.

</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22subscrib"><summary>Response</summary>

```json
{
  "subscribers": [],
  "service_area": {
    "uss_base_url": "https://example.com/rid",
    "owner": "myuss",
    "time_start": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "time_end": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "version": "string",
    "id": "string"
  }
}
```

Campos notáveis

<table border="1" style="border-collapse: collapse; width: 100%; height: 141.781px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 63.3906px;"><td style="height: 63.3906px;">subcribers</td><td style="height: 63.3906px;">Lista dos atuais subcribers dessa área. Caso a lista não esteja vazia, é **OBRIGATÓRIO** o envio da ISA para cada um dos subscribers listados</td></tr><tr style="height: 78.3906px;"><td style="height: 78.3906px;">version</td><td style="height: 78.3906px;">Versão da ISA, gerado pelo DSS, para garantia de integridade. É necessário utilizar esse campo para atualizar ou deletar uma ISA.</td></tr></tbody></table>

</details>

# Cadastro Service Provider

Para os **ensaios de Março/24**, os interessados em fornecer serviços deverão realizar o cadastro de seus respectivos provedores conforme mostrado abaixo. Após a aprovação do cadastro, uma API Key será disponibilizada, liberando acesso aos *endpoints* listados mais adiante.

### Cadastro

Acesse o BR-UTM Forms (URL a definir) e siga os passos:

1. Vá para a área de provedores  
    [![BR-UTM Forms - Página Inicial](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/scaled-1680-/image.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/image.png)
2. O responsável pelo provedor cria uma conta e utiliza as mesmas credenciais para acessos futuros  
    [![BR-UTM Forms - Página de cadastro](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/scaled-1680-/c7Rimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/c7Rimage.png)
3. Acesse o Dashboard  
    [![BR-UTM Forms - Página de acesso](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/scaled-1680-/UYHimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/UYHimage.png)
4. No menu superior, clique em "Your Provider"; ou, nas opções do Dashboard, clique em "Register your provider"[![BR-UTM Forms - Página principal (dashboard)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/scaled-1680-/Knwimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/Knwimage.png)
5. Na tela a qual você foi redirecionado, clique em "Register". Você verá o formulário mostrado abaixo (os campos podem ser diferentes no momento do seu acesso)[![BR-UTM Forms - Página casdastro de provedor](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/scaled-1680-/m6Himage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/m6Himage.png)
6. Após o preenchimento correto do formulário, os dados cadastrais de seu provedor serão enviados para análise[![BR-UTM Forms - Página do provedor](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/scaled-1680-/bUTimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/bUTimage.png)
7. Assim que o cadastro for aprovado, sua API Key será disponibilizada na própria página  
    [![BR-UTM Forms - Página do provedor (status aprovado)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/scaled-1680-/yJoimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-01/yJoimage.png)

### Uso da API Key  


Com sua API Key, você pode gerar um *token* de autenticação para realizar ações programaticamente no ECO-UTM em nome de um usuário:

1. Associe um usuário ao seu provedor, passando o SARPAS ID dele nos parâmetros e sua API Key no *header* da requisição;
2. Crie um *token* de autenticação de usuário, passando o SARPAR ID do usuário e sua API Key no *body* requisição;
3. Aprove o *token* recém-criado, passando o SARPAS ID no parâmetro da requisição.

Com ambas as chaves em mãos, você será capaz de fazer requisições nos *endpoints* listados na seção a seguir.

### Lista de endpoints  


**A lista completa de *endpoints* também está disponível [neste arquivo OpenAPI](https://servicos2.decea.mil.br/br-utm/wiki/attachments/31) e [nesta coleção no Insomina.](https://servicos2.decea.mil.br/br-utm/wiki/attachments/32)**

#### ECO-UTM

A URL base para os seguintes *endpoints* é [`http://kong.icea.decea.mil.br:64235/eco-utm/v1/`](http://kong.icea.decea.mil.br:64235/eco-utm/v1/)

---

<table border="1" class="align-center" id="bkmrk-put-%2Fdss%2Fidentificat" style="border-collapse: collapse; width: 100%; height: 29.8px; border: 0px solid rgb(206, 212, 217);"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(252, 161, 48); border-color: rgb(206, 212, 217);">**PUT**</td><td class="align-left" style="height: 29.8px; border-width: 0px; border-color: rgb(206, 212, 217);">/providers/user\_token/{token}/assign</td></tr></tbody></table>

Associar usuário e provedor

<details id="bkmrk-path-param-id-uuid-g"><summary>Headers</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>apikey</td><td>API Key disponível no BR-UTM Forms</td></tr></tbody></table>

</details><details id="bkmrk-path-param-token-o%C2%A0t"><summary>Path Param</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>token  
</td><td>SARPAS ID do usuário</td></tr></tbody></table>

</details><details id="bkmrk-body-%7B-%22extents%22%3A-%7B-"><summary>Body</summary>

```json
{
  "data": {
    "provider_secret": "your-provider-api-key",
    "provider_id": "kong-consumer-custom-id"
    
  }
}
```

Campos notáveis

<table border="1" style="border-collapse: collapse; width: 100%; height: 220px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 46.6px;"><td style="height: 46.6px;">provider\_secret</td><td style="height: 46.6px;">API Key disponível no BR-UTM Forms  
</td></tr><tr style="height: 57.8px;"><td style="height: 57.8px;">provider\_id</td><td style="height: 57.8px;"><span style="color: rgb(0, 0, 0);">\[OPCIONAL\] Custom ID do Kong associado ao Consumer</span>

</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22subscrib"><summary>Response</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>200  
</td><td>Success  
</td></tr><tr><td>404  
</td><td>User not found</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fuss%2Fidentificat" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(73, 204, 144);">**POST**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/providers/auth</td></tr></tbody></table>

Gerar token de autenticação

<details id="bkmrk-headers-apikey-api-k"><summary>Headers</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>apikey</td><td>API Key disponível no BR-UTM Forms</td></tr></tbody></table>

</details><details id="bkmrk-body-%7B-%22data%22%3A-%7B-%22pr"><summary>Body</summary>

```json
{
  "data": {
    "provider_secret": "",
    "provider_id": "",
    "user_id": ""
  }
}
```

Campos notáveis

<table border="1" style="border-collapse: collapse; width: 100%; height: 139.8px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 46.6px;"><td style="height: 46.6px;">provider\_secret</td><td style="height: 46.6px;">API Key disponível no BR-UTM Forms  
</td></tr><tr style="height: 57.8px;"><td style="height: 57.8px;">provider\_id</td><td style="height: 57.8px;"><span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">\[OPCIONAL\] Custom ID do Kong associado ao Consumer</span></span>

</td></tr><tr style="height: 35.4px;"><td style="height: 35.4px;">user\_id  
</td><td style="height: 35.4px;"><span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">SARPAS ID do usuário</span>  
</span>

</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22extents%22"><summary>Response</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>204

</td><td>Success</td></tr><tr><td>404

</td><td>User not found  
</td></tr><tr><td>412

</td><td>Invalid provider and user relationship

</td></tr><tr><td>500

</td><td>Internal server error  
</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fuss%2Fflights" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 75px;"></col><col></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(97, 175, 254);">**GET**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/user-keys/{user-id}</td></tr></tbody></table>

Aprovar token de autenticação do provedor associado ao usuário

<details id="bkmrk-query-parameters-vie"><summary>Path Param</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 193.969px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 113.781px;"><td style="height: 113.781px;">user-id</td><td style="height: 113.781px;"><span style="color: rgb(0, 0, 0);">SARPAR ID do usuário</span>  
</td></tr></tbody></table>

</details><details id="bkmrk-bearer-token-que-tok"><summary>Bearer</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 193.969px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 113.781px;"><td style="height: 113.781px;">token</td><td style="height: 113.781px;"><span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">Bearer token gerado</span></span>  
</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22timestam"><summary>Response</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 31.3833px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 31.3833px;"><td style="height: 31.3833px;">200</td><td style="height: 31.3833px;">Success  
</td></tr><tr><td>500  
</td><td>Error  
</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fpilots%2Fflights" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(73, 204, 144);">**POST**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/pilots/flights</td></tr></tbody></table>

Cria uma solicitação de voo para um espaço aéreo descrito na requisição

<details id="bkmrk-headers-apikey-api-k-1"><summary>Headers</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>apikey</td><td>API Key disponível no BR-UTM Forms</td></tr></tbody></table>

</details><details id="bkmrk-bearer-token-que-tok-1"><summary>Bearer</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 29.8px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px;">token</td><td style="height: 29.8px;">Bearer token gerado  
</td></tr></tbody></table>

</details><details id="bkmrk-body-%7B-%22data%22%3A-%7B-%22ty"><summary>Body</summary>

```json
{
    "data": {
        "type": "/pilots/flights",
        "attributes": {
            "airplane_id": "1ed0e6d9-e88e-6812-bd5f-0242ac12001c",
            "operation": {
                "aircrafts": [
                   {
                        "id": 4,
                        "uuid": "1ed0e6d9-e88e-6812-bd5f-0242ac12001c"
                   }
                ],
                "flight": {
                    "pilots": ["QGRK"],
                    "date": {
                        "start_day": "2025-12-16",
                        "start_hour": "08:00",
                        "finish_day": "2025-12-16",
                        "finish_hour": "09:00"
                    },
                    "type": "VLOS",
                    "observations": "teste",
                    "communication": {
                        "id": "1",
                        "ats_call_type": "vhf-fm",
                        "rpa_call_type": "vhf-am",
                        "rps": [
                            {
                                "name": "1",
                                "lat": "1",
                                "lng": "1",
                                "contact_info": "1",
                                "radius": 100
                            }
                        ]
                    },
                    "sarpas_code": "OJMN",
                    "area": {
                        "asa_id": "283797ce-73e9-4395-adcf-6c6119b3f20f",
                        "takeoff_point": [-34.993236064910896,-8.02209168418088],
                        "landing_point": [-34.993236064910896,-8.02209168418088],
                        "required_route": {
                            "geojson": {
      "type": "Feature",
      "properties": {},
      "geometry": {
        "type": "Polygon",
        "coordinates": [
					[
						[
							-24.080093705511494,
							-49.0539316478104
						],
						[
							-24.081153158442177,
							-49.05006533240442
						],
						[
							-24.08503406183282,
							-49.052976909391695
						],
						[
							-24.082881359600847,
							-49.055986687210066
						],
						[
							-24.080093705511494,
							-49.0539316478104
						]
					]
				]
      }
    }
                            },
                            "flight_type": "height",
                            "flight_distance": 100
                        },
                        "documents": []
                    },
                    "basic_information": {
                        "name": "teste 2",
                        "type": "101",
                        "agree_terms": 1
                    }
                }
            }
        }
    }
```

Campos notáveis

<table border="1" style="border-collapse: collapse; width: 100%; height: 139.8px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 46.6px;"><td style="height: 46.6px;">provider\_secret</td><td style="height: 46.6px;">API Key disponível no BR-UTM Forms  
</td></tr><tr style="height: 57.8px;"><td style="height: 57.8px;">provider\_id</td><td style="height: 57.8px;"><span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">\[OPCIONAL\] Custom ID do Kong associado ao Consumer</span></span>

</td></tr><tr style="height: 35.4px;"><td style="height: 35.4px;">user\_id  
</td><td style="height: 35.4px;"><span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">SARPAR ID do usuário</span>  
</span>

</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%7D-%C2%A0"><summary>Response</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>200  
</td><td>Success</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fbypass%2Fcategori" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(97, 175, 254);">**GET**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/bypass/categorize/{solicitationProtocol}</td></tr></tbody></table>

Categoriza uma solicitação de voo por número de protocolo

<details id="bkmrk-headers-apikey-api-k-2"><summary>Headers</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>apikey</td><td>API Key disponível no BR-UTM Forms</td></tr></tbody></table>

</details><details id="bkmrk-bearer-token-que-tok-2"><summary>Bearer</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 29.8px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px;">token</td><td style="height: 29.8px;"><span style="color: rgb(0, 0, 0);">Bearer token gerado</span></td></tr></tbody></table>

</details><details id="bkmrk-path-param-solicitat"><summary>Path Param</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 10px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 10px;"><td style="height: 10px;">solicitationProtocol</td><td style="height: 10px;"><span style="color: rgb(0, 0, 0);">Número de protocolo da solicitação</span></td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%7D-%C2%A0-1"><summary>Response</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>200  
</td><td>Success</td></tr><tr><td>404  
</td><td>Solicitation not found  
</td></tr><tr><td>500  
</td><td>Error  
</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fbypass%2Fanalyze%2F" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(97, 175, 254);">**GET**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/bypass/analyze/{solicitationProtocol}</td></tr></tbody></table>

Analisa uma solicitação de voo por número de protocolo

<details id="bkmrk-headers-apikey-api-k-3"><summary>Headers</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>apikey</td><td>API Key disponível no BR-UTM Forms</td></tr></tbody></table>

</details><details id="bkmrk-bearer-token-que-tok-3"><summary>Bearer</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 10px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 10px;"><td style="height: 10px;">token</td><td style="height: 10px;"><span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">Bearer token gerado</span></span></td></tr></tbody></table>

</details><details id="bkmrk-path-param-solicitat-1"><summary>Path Param</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 10px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 10px;"><td style="height: 10px;">solicitationProtocol</td><td style="height: 10px;"><span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">Número de protocolo da solicitação</span></span></td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%7D-%C2%A0-2"><summary>Response</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>200  
</td><td>Success</td></tr><tr><td>404  
</td><td>Solicitation protocol not found  
</td></tr><tr><td>500  
</td><td>Error  
</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fuser-aircraft" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(97, 175, 254);">**GET**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/user-aircraft  
</td></tr></tbody></table>

Busca todas as aeronaves de um usuário identificado pelo token de sessão

<details id="bkmrk-headers-apikey-api-k-4"><summary>Headers</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>apikey</td><td>API Key disponível no BR-UTM Forms</td></tr></tbody></table>

</details><details id="bkmrk-bearer-token-que-tok-4"><summary>Bearer</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 10px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 10px;"><td style="height: 10px;">token</td><td style="height: 10px;"><span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">Bearer token gerado</span></span></td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%7D-%C2%A0-3"><summary>Response</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>200  
</td><td>Success</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fshared-aircraft" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(97, 175, 254);">**GET**  
</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/shared-aircraft-user  
</td></tr></tbody></table>

Busca todas as aeronaves compartilhadas com um usuário identificado pelo token de sessão

<details id="bkmrk-headers-apikey-api-k-5"><summary>Headers</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>apikey</td><td>API Key disponível no BR-UTM Forms</td></tr></tbody></table>

</details><details id="bkmrk-bearer-token-que-tok-5"><summary>Bearer</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 10px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 10px;"><td style="height: 10px;">token</td><td style="height: 10px;"><span style="color: rgb(0, 0, 0);">Bearer token gerado</span></td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%7D-%C2%A0-4"><summary>Response</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>200  
</td><td>Success</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-post-%2Fuser%2Fflight%2Fai" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(73, 204, 144);">**POST**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/user/flight/aircrafts</td></tr></tbody></table>

Busca todas as aeronaves em voo, opcionalmente incluindo compartilhadas, de um usuário identificado pelo ID enviado na requisição

<details id="bkmrk-headers-apikey-api-k-6"><summary>Headers</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>apikey</td><td>API Key disponível no BR-UTM Forms</td></tr></tbody></table>

</details><details id="bkmrk-bearer-token-que-tok-6"><summary>Bearer</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 29.8px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px;">token</td><td style="height: 29.8px;"><span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">Bearer token gerado</span></span></td></tr></tbody></table>

</details><details id="bkmrk-body-%7B-%22user_informa"><summary>Body</summary>

```json
{
  "user_information_id": "1ed4b29e-8fe0-60aa-aefd-0242ac120019",
  "shared": true
}
```

Campos notáveis

<table border="1" style="border-collapse: collapse; width: 100%; height: 139.8px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 46.6px;"><td style="height: 46.6px;">user\_information\_id</td><td style="height: 46.6px;"><span style="color: rgb(0, 0, 0);">SARPAS ID do usuário</span>  
</td></tr><tr><td>shared  
</td><td><span style="color: rgb(0, 0, 0);">\[OPCIONAL\] Incluir aeronaves compartilhadas  
</span></td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%7D-%C2%A0-5"><summary>Response</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>200  
</td><td>Success</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fflight-status" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(97, 175, 254);">**GET**  
</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/flight-status  
</td></tr></tbody></table>

Lista os status do voo de um usuário identificado pelo token de sessão

<details id="bkmrk-headers-apikey-api-k-8"><summary>Headers</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>apikey</td><td>API Key disponível no BR-UTM Forms</td></tr></tbody></table>

</details><details id="bkmrk-bearer-token-que-tok-8"><summary>Bearer</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 10px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 10px;"><td style="height: 10px;">token</td><td style="height: 10px;"><span style="color: rgb(0, 0, 0);">Bearer token gerado</span>  
</td></tr></tbody></table>

</details><details id="bkmrk-response-%C2%A0-1"><summary>Response</summary>

200

</details>#### ASA

A URL base para os seguintes *endpoints* é `<a href="http://kong.icea.decea.mil.br:64236/api/">http://kong.icea.decea.mil.br:64236/api/</a>`

---

<table border="1" class="align-center" id="bkmrk-post-%2Fpolygon%2F%7Bpolyg" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(73, 204, 144);">**POST**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/polygon/{polygonId}/{userUuid}</td></tr></tbody></table>

Cria uma área no ASA dados os identificadores do polígono e usuário

<details id="bkmrk-headers-apikey-api-k-9"><summary>Headers</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>apikey</td><td>API Key disponível no BR-UTM Forms</td></tr></tbody></table>

</details><details id="bkmrk-bearer-token-que-tok-9"><summary>Bearer</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 29.8px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px;">token</td><td style="height: 29.8px;"><span style="color: rgb(0, 0, 0);">Bearer token gerado</span>  
</td></tr></tbody></table>

</details><details id="bkmrk-path-param-polygonid"><summary>Path Param</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 10px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 10px;"><td style="height: 10px;">polygonId</td><td style="height: 10px;">ID (definido pelo solicitante) do polígono criado  
</td></tr><tr><td>userUuid  
</td><td>SARPAS ID do usuário  
</td></tr></tbody></table>

</details><details id="bkmrk-body-%7B-%22type%22%3A-%22feat"><summary>Body</summary>

```json
{
    "type": "Feature",
    "properties": {
      "poligonoId": "283797ce-73e9-4395-adcf-6c6119b3f20f",
      "perfil": "1",
      "datasHoras": "{\"date1\":\"2023-11-30\",\"date2\":\"2023-11-30\",\"hora1\":\"14:00\",\"hora2\":\"15:00\"}",
      "elevacoes": {
        "criarAreaMaximo": 10,
        "criarAreaMinimo": 0,
        "criarAreaMaximoFt": 32.8084,
        "criarAreaMinimoFt": 0,
        "criarAreaNome": "",
        "criarAreaDescricao": "",
        "alturaEditavelMetros": "10",
        "alturaEditavelPes": 32.8084,
        "dataInicio": "2025-12-12",
        "dataTermino": "2025-12-12",
        "horaInicio": "08:00",
        "horaTermino": "09:00",
        "update": []
      },
      "raio": 0,
      "altura": "10",
      "formato": "poligono",
      "contextoId": 1,
      "pontoDecolagem": {
        "latLng": {
          "lat": -24.098672973607677,
          "lng": -48.909985432572751,
          "valido": true
        },
        "unidade": "gms",
        "elevationM": 10,
        "elevationFt": 32.8084,
        "valido": true
      }
    },
    "geometry": {
      "type": "Polygon",
      "coordinates": [
					[
						[
							-24.080093705511494,
							-49.0539316478104
						],
						[
							-24.081153158442177,
							-49.05006533240442
						],
						[
							-24.08503406183282,
							-49.052976909391695
						],
						[
							-24.082881359600847,
							-49.055986687210066
						],
						[
							-24.080093705511494,
							-49.0539316478104
						]
					]
				]
    }
  }
```

Campos notáveis

<table border="1" style="border-collapse: collapse; width: 100%; height: 139.8px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 46.6px;"><td style="height: 46.6px;">  
</td><td style="height: 46.6px;"> </td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-voo_id%3A-s"><summary>Response</summary>

```json
{
  voo_id: string
}
```

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr><td>voo\_id</td><td>  
</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fpolygon%2F%7Bsolici" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(97, 175, 254);">**GET**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/polygon/{solicitationProtocol}/result</td></tr></tbody></table>

<span style="color: rgb(0, 0, 0);">Obter resultado da solicitação de área</span>

<details id="bkmrk-headers-apikey-api-k-10"><summary>Headers</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>apikey</td><td>API Key disponível no BR-UTM Forms</td></tr></tbody></table>

</details><details id="bkmrk-bearer-token-que-tok-10"><summary>Bearer</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 10px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 10px;"><td style="height: 10px;">token</td><td style="height: 10px;"><span style="color: rgb(0, 0, 0);">Bearer token gerado</span>  
</td></tr></tbody></table>

</details><details id="bkmrk-path-param-solicitat-2"><summary>Path Param</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 10px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 10px;"><td style="height: 10px;">solicitationProtocol</td><td style="height: 10px;">Número de protocolo da solicitação de área</td></tr></tbody></table>

</details><details id="bkmrk-response-200-ok"><summary>Response</summary>

200 OK

</details>

# Onboarding Display Provider

No contexto do serviço de Tracking, um Display Provider é um provedor USS que tem objetivo de exibir a posição de drones em tempo real para seus usuários.

### Pré-requisitos técnicos

Para um USS se tornar um provedor de display de Tracking existem os seguintes pré-requisitos técnicos que não estão no escopo dessa documentação, ficando a critério do provedor como implementar esses pré-requisitos:

1. Possuir um servidor HTTP para solicitar e receber requisições
2. Possuir App para visualização de posição de drones

### Autenticação

Para o ensaio, a autenticação será feita em um serviço OAuth centralizado do DECEA, ainda a ser descrito.

### Endpoints

A dinâmica de comunicação entre Service Provider, Display Provider e DSS está descrita na norma ASTM 3411-22a. Para facilitar o entendimento, alguns possíveis cenários de utilização estão descritos na página [Cenários](https://servicos2.decea.mil.br/br-utm/wiki/books/documentacao-tecnica/page/cenarios "Cenários").

O padrão seguido no ensaio será o descrito em [https://github.com/uastech/standards/tree/astm\_rid\_api\_2.1/remoteid](https://github.com/uastech/standards/tree/astm_rid_api_2.1/remoteid)

Conforme o padrão OpenAPI acima, os endpoints que o Display Provider precisará prover:

<table border="1" class="align-center" id="bkmrk-get-%2Fuss%2Fflights" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 75px;"></col><col></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(73, 204, 144);">**POST**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/uss/identification\_service\_areas/{id}</td></tr></tbody></table>

<details id="bkmrk-path-parameters-id-u-1"><summary>Path Parameters</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>id</td><td>UUID da ISA</td></tr></tbody></table>

</details><details id="bkmrk-request-body-%7B-%22serv"><summary>Request Body</summary>

</details>### Interação com DSS

O Service Provider, conforme definido no padrão ASTM3411-22a, deve criar entidades de Subscription em uma área específica, para encontrar os atuais Service Providers, e também para receberem notificações caso novos provedores se registrem na área. Os endpoints expostos pelo DSS estão descritos no arquivo OpenAPI descrito acima.

Como exemplo, o endpoint abaixo é para criação de Subscriptions:

<table border="1" class="align-center" id="bkmrk-put-%2Fdss%2Fidentificat" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.7969px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: #fca130;">**PUT**</td><td class="align-left" style="height: 29.7969px; border-width: 0px;">/dss/subscriptions/{id}</td></tr></tbody></table>

<details id="bkmrk-path-parameters-id-u"><summary>Path Parameters</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>id</td><td>UUID da Subscription, criado pelo Display Provider</td></tr></tbody></table>

</details><details id="bkmrk-request-body-%7B-%22exte"><summary>Request Body</summary>

```json
{
  "extents": {
    "volume": {
      "outline_circle": {
        "center": {
          "lng": -118.456,
          "lat": 34.123
        },
        "radius": {
          "value": 300.183,
          "units": "M"
        }
      },
      "outline_polygon": {
        "vertices": [
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          }
        ]
      },
      "altitude_lower": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      },
      "altitude_upper": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      }
    },
    "time_start": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "time_end": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    }
  },
  "uss_base_url": "https://example.com/rid"
}
```

Campos notáveis

<table border="1" style="border-collapse: collapse; width: 100%; height: 76.3907px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 46.5938px;"><td style="height: 46.5938px;">volume</td><td style="height: 46.5938px;">Polígono **OU** círculo da área, idêntico ao definido no SARPAS</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">altitude\_lower, altitude\_upper</td><td style="height: 29.7969px;">Altitude geodésica (WSG84, W84) máxima e mínima em metros.

</td></tr><tr><td>time\_start, time\_end</td><td>Horário de início e fim da área. Todos os horários devem estar no timezone Zulo (UTC+0). O único formato suportado é "RFC3339"

</td></tr><tr><td>uss\_base\_url</td><td>URL a qual o Service Provider irá responder à solicitações. Não deve conter uma barra '/' ao final. Sugere-se utilizar uma URL e não um IP.

</td></tr></tbody></table>

</details><details id="bkmrk-response-body-%7B-%22ser"><summary>Response Body</summary>

```json
{
  "service_areas": [],
  "subscription": {
    "id": "string",
    "uss_base_url": "https://example.com/rid",
    "owner": "myuss",
    "notification_index": 0,
    "time_end": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "time_start": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "version": "string"
  }
}
```

<table border="1" style="border-collapse: collapse; width: 100%; height: 122.984px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 63.3906px;"><td style="height: 63.3906px;">service\_areas</td><td style="height: 63.3906px;">Lista de ISAs já existentes no volume 4D. Caso a lista não esteja vazia, o Display Provider deve solicitar os dados de telemetria para as URLs definidas na lista</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">version</td><td style="height: 29.7969px;">Versão da Subscription, gerado pelo DSS, para garantia de integridade. É necessário utilizar esse campo para atualizar ou deletar uma Subscription.</td></tr></tbody></table>

</details>

# Cenários

#### Cenário 1:

Apenas um Service provider e nenhum Display provider na área durante o Voo

<div drawio-diagram="255"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2024-02/drawing-3-1709118152.png" alt=""/></div>

#### Cenário 2:

Service provider cria área onde já existe uma Subscription (Display Provider)

<div drawio-diagram="115"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2023-12/drawing-3-1702578626.png" alt=""/></div>

#### Cenário 3:

Criação de Subscription onde já exista ISA

<div drawio-diagram="116"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2023-12/drawing-3-1702578754.png" alt=""/></div>

#### Cenário 4:

Usuário do Display Provider deseja visualizar uma área. Nessa área já existe um Service Provider (USS 1), e durante a exibição, um novo Service Provider (USS 2) inicia operações na área. Esse cenário foi adaptado da documentação do InterUSS DSS.

<div drawio-diagram="128"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2023-12/drawing-3-1702692143.png" alt=""/></div>

# Ensaio Operacional 1 - Março 2024



# Cenários Operacionais

### Descrever a proposta de cenários operacionais para teste no ensaio de Março/2024.

#### Variáveis que serão testadas nos cenários:

- - Número de USS operando simultaneamente (1, 2 USS).
    - Sem e com conflito de intenção de operação.
    - Sem e com restrições de voo.
    - Conflito entre intenções de operação: 
        - VLOS e BVLOS.
        - BVLOS e BVLOS.

#### Detalhamento dos cenários a serem ensaiados:

- Cenário 0.0:  
    
    - Objetivo: cenário baseline - similar à situação atual para testar interface dos USS.
    - 1 USS
    - Sem conflito de rota
    - Sem restrições
    - VLOS
    - Detalhamento do cenário: 
        - Ensaio 0.0.0: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Solicitar acesso ao espaço aéreo UTM (4D).
            - Receber autorização para uso do espaço aéreo (4D).
            - Realizar voo VLOS.
            - Liberar espaço utilizado para próxima utilização.
- Cenário 0.1: 
    - Objetivo: ensaio igual ao cenário 0.0, incluindo restrições de voo.
    - 1 USS
    - Sem conflito de rota
    - Com restrições
    - VLOS
    - Detalhamento do cenário: 
        - Ensaio 0.1.0: Solicitação de voo com restrição pré-existente: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Solicitar acesso ao espaço aéreo UTM (4D).
            - Verificar restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Receber autorização para uso do espaço aéreo (4D).
            - Realizar voo VLOS.
            - Liberar espaço utilizado para próxima utilização.
        - Ensaio 0.1.1: Solicitação de voo com restrição imposta posteriormente: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Solicitar acesso ao espaço aéreo UTM (4D).
            - Verificar restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Receber autorização para uso do espaço aéreo (4D).
            - Provedor de serviços recebe restrição no espaço aéreo UTM, em conflito com o espaço aéreo previamente autorizado.
            - Provedor de serviços informa ao operador referente à restrição no espaço aéreo.
            - Operador aborta a missão (caso ainda não tenha iniciado o voo), ou retorna à base (caso já tenha iniciado o voo).
            - Liberar espaço utilizado para próxima utilização.
- Cenário 1.0: 
    - Objetivo: aumento da complexidade, incluindo conflito de rota VLOS e BVLOS.
    - 1 USS
    - Com conflito de rota
    - Sem restrições
    - VLOS e BVLOS
    - Detalhamento do cenário: 
        - Ensaio 1.0.0: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), um para voo VLOS e outro para voo BVLOS, para o mesmo provedor de serviços. Depois invertem a ordem da solicitação.
            - Verificar restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Realização dos voos.
            - Liberar espaço utilizado para próxima utilização.
- Cenário 1.1: 
    - Objetivo: ensaio igual ao cenário 1.0, incluindo restrições de voo.
    - 1 USS
    - Com conflito de rota
    - Com restrições
    - VLOS e BVLOS
    - Detalhamento do cenário: 
        - Ensaio 1.1.0: Solicitação de voo com restrição pré-existente: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), um para voo VLOS e outro para voo BVLOS, para o mesmo provedor de serviços. Depois invertem a ordem da solicitação.
            - Verificar restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Realização dos voos.
            - Liberar espaço utilizado para próxima utilização.
        - Ensaio 1.1.1: Solicitação de voo com restrição imposta posteriormente: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), um para voo VLOS e outro para voo BVLOS, para o mesmo provedor de serviços. Depois invertem a ordem da solicitação.
            - Verificar restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Provedor de serviços recebe restrição no espaço aéreo UTM, em conflito com o espaço aéreo previamente autorizado.
            - Provedor de serviços informa aos operadores referente à restrição no espaço aéreo.
            - Operadores abortam a missão (caso ainda não tenha iniciado o voo), ou retornam à base (caso já tenha iniciado o voo).
            - Liberar espaço utilizado para próxima utilização.
- Cenário 2.0: 
    - Objetivo: aumento da complexidade, incluindo conflito de rota BVLOS e BVLOS.
    - 1 USS
    - Com conflito de rota
    - Sem restrições
    - BVLOS e BVLOS
    - Detalhamento do cenário: 
        - Ensaio 2.0.0: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), ambos para voos BVLOS, para o mesmo provedor de serviços.
            - Verificar restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Realização dos voos.
            - Liberar espaço utilizado para próxima utilização.
- Cenário 2.1: 
    - Objetivo: ensaio igual ao cenário 2.0, incluindo restrições de voo.
    - 1 USS
    - Com conflito de rota
    - Com restrições
    - BVLOS e BVLOS
    - Detalhamento do cenário: 
        - Ensaio 2.1.0: Solicitação de voo com restrição pré-existente: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), ambos para voos BVLOS, para o mesmo provedor de serviços.
            - Verificar restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Realização dos voos.
            - Liberar espaço utilizado para próxima utilização.
        - Ensaio 2.1.1: Solicitação de voo com restrição imposta posteriormente: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), ambos para voos BVLOS, para o mesmo provedor de serviços.
            - Verificar restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Provedor de serviços recebe restrição no espaço aéreo UTM, em conflito com o espaço aéreo previamente autorizado.
            - Provedor de serviços informa aos operadores referente à restrição no espaço aéreo.
            - Operadores abortam a missão (caso ainda não tenha iniciado o voo), ou retornam à base (caso já tenha iniciado o voo).
            - Liberar espaço utilizado para próxima utilização.
- Cenário 3.0: 
    - Objetivo: ensaio igual ao cenário 1.0, mas com 2 USS diferentes solicitando voos (VLOS e BVLOS).
    - 2 USS
    - Com conflito de rota
    - Sem restrições
    - VLOS e BVLOS
    - Detalhamento do cenário: 
        - Ensaio 3.0.0: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), um para voo VLOS e outro para voo BVLOS, para diferentes provedores de serviços (um operador para cada provedor de serviços). Depois invertem a ordem da solicitação.
            - Provedores de serviço verificam restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Realização dos voos.
            - Liberar espaço utilizado para próxima utilização.
- Cenário 3.1: 
    - Objetivo: ensaio igual ao cenário 3.0, incluindo restrições de voo.
    - 2 USS
    - Com conflito de rota
    - Com restrições
    - VLOS e BVLOS
    - Detalhamento do cenário: 
        - Ensaio 3.1.0: Solicitação de voo com restrição pré-existente: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), um para voo VLOS e outro para voo BVLOS, para diferentes provedores de serviços (um operador para cada provedor de serviços). Depois invertem a ordem da solicitação.
            - Provedores de serviço verificam restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Realização dos voos.
            - Liberar espaço utilizado para próxima utilização.
        - Ensaio 3.1.1: Solicitação de voo com restrição imposta posteriormente: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), um para voo VLOS e outro para voo BVLOS, para diferentes provedores de serviços (um operador para cada provedor de serviços). Depois invertem a ordem da solicitação.
            - Provedores de serviço verificam restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Provedores de serviços recebem restrição no espaço aéreo UTM, em conflito com o espaço aéreo previamente autorizado.
            - Provedores de serviços informam aos operadores referente à restrição no espaço aéreo.
            - Operadores abortam a missão (caso ainda não tenha iniciado o voo), ou retornam à base (caso já tenha iniciado o voo).
            - Liberar espaço utilizado para próxima utilização.
- Cenário 4.0: 
    - Objetivo: ensaio igual ao cenário 2.0, mas com 2 USS diferentes solicitando voos (BVLOS e BVLOS).
    - 2 USS
    - Com conflito de rota
    - Sem restrições
    - BVLOS e BVLOS
    - Detalhamento do cenário: 
        - Ensaio 4.0.0: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), ambos para voos BVLOS, para diferentes provedores de serviços (um operador para cada provedor de serviços).
            - Provedores de serviço verificam restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Realização dos voos.
            - Liberar espaço utilizado para próxima utilização.
- Cenário 4.1: 
    - Objetivo: ensaio igual ao cenário 4.0, incluindo restrições de voo.
    - 2 USS
    - Com conflito de rota
    - Com restrições
    - BVLOS e BVLOS
    - Detalhamento do cenário: 
        - Ensaio 4.1.0: Solicitação de voo com restrição pré-existente: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), ambos para voos BVLOS, para diferentes provedores de serviços (um operador para cada provedor de serviços).
            - Provedores de serviço verificam restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Realização dos voos.
            - Liberar espaço utilizado para próxima utilização.
        - Ensaio 4.1.1: Solicitação de voo com restrição imposta posteriormente: 
            - Testar acesso dos operadores ao ECO-UTM através da interface dos provedores de serviço.
            - Dois operadores solicitam acesso ao espaço aéreo UTM (4D), ambos para voos BVLOS, para diferentes provedores de serviços (um operador para cada provedor de serviços).
            - Provedores de serviço verificam restrições presentes no espaço aéreo solicitado.
            - Desconflitar espaço solicitado das restrições presentes (caso existam).
            - Desconflitar espaço solicitado por cada operador (ordem cronológica de solicitação).
            - Operadores recebem autorização para uso do espaço aéreo (4D).
            - Provedores de serviços recebem restrição no espaço aéreo UTM, em conflito com o espaço aéreo previamente autorizado.
            - Provedores de serviços informam aos operadores referente à restrição no espaço aéreo.
            - Operadores abortam a missão (caso ainda não tenha iniciado o voo), ou retornam à base (caso já tenha iniciado o voo).
            - Liberar espaço utilizado para próxima utilização.

# I WorkShop BR-UTM - Julho 2024

Documentação para participação no WorkShop

# Repositórios e Endpoints

[Apresentação Workshop](https://docs.google.com/presentation/d/17UNKi6QQ_hO4Lv314aAa8VlsqurcgUyg/edit?usp=sharing&ouid=115891639852919271691&rtpof=true&sd=true)

DSS: [https://github.com/dp-icea/dss](https://github.com/dp-icea/dss)

Monitoring: [https://github.com/dp-icea/utm\_monitoring](https://github.com/dp-icea/utm_monitoring)

SCD-Provider Example: [https://github.com/dp-icea/scd\_provider/tree/refactor-golang](https://github.com/dp-icea/scd_provider/tree/refactor-golang)

Swagger: [http://172.18.31.95:9001/](http://172.18.31.95:9001/)

### Endpoints

Validator: [http://montreal.icea.decea.mil.br:64235/verifier/validate](http://montreal.icea.decea.mil.br:64235/verifier/validate)

# Entidades da Simulação

A seguir estão as coordenadas GeoJSON das entidades presentes no cenário de simulação

Visualizador: [http://172.18.35.75:3000/](http://172.18.35.75:3000/)

##### SBR497

<details id="bkmrk-sbr-497-json-%7B-%22type"><summary>GeoJSON</summary>

```json
{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "id": 0,
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [
              -48.1622,
              -22.2156
            ],
            [
              -48.1403,
              -22.2004
            ],
            [
              -48.1183,
              -22.1853
            ],
            [
              -48.0963,
              -22.1702
            ],
            [
              -48.0744,
              -22.155
            ],
            [
              -48.0524,
              -22.1399
            ],
            [
              -48.0305,
              -22.1248
            ],
            [
              -48.0086,
              -22.1096
            ],
            [
              -47.9866,
              -22.0945
            ],
            [
              -47.9647,
              -22.0793
            ],
            [
              -47.9428,
              -22.0642
            ],
            [
              -47.9411,
              -22.0504
            ],
            [
              -47.9394,
              -22.0366
            ],
            [
              -47.9378,
              -22.0228
            ],
            [
              -47.9241,
              -22.0294
            ],
            [
              -47.9104,
              -22.0361
            ],
            [
              -47.8967,
              -22.0428
            ],
            [
              -47.9036,
              -22.0588
            ],
            [
              -47.9106,
              -22.0748
            ],
            [
              -47.9176,
              -22.0908
            ],
            [
              -47.9246,
              -22.1068
            ],
            [
              -47.9316,
              -22.1228
            ],
            [
              -47.9385,
              -22.1388
            ],
            [
              -47.9455,
              -22.1548
            ],
            [
              -47.9525,
              -22.1708
            ],
            [
              -47.9549,
              -22.1881
            ],
            [
              -47.9574,
              -22.2054
            ],
            [
              -47.9598,
              -22.2228
            ],
            [
              -47.9623,
              -22.2401
            ],
            [
              -47.9647,
              -22.2574
            ],
            [
              -47.9672,
              -22.2747
            ],
            [
              -47.9696,
              -22.292
            ],
            [
              -47.9721,
              -22.3093
            ],
            [
              -47.9745,
              -22.3266
            ],
            [
              -47.9769,
              -22.3439
            ],
            [
              -47.9955,
              -22.3311
            ],
            [
              -48.014,
              -22.3182
            ],
            [
              -48.0326,
              -22.3054
            ],
            [
              -48.0511,
              -22.2926
            ],
            [
              -48.0696,
              -22.2797
            ],
            [
              -48.0882,
              -22.2669
            ],
            [
              -48.1067,
              -22.2541
            ],
            [
              -48.1252,
              -22.2412
            ],
            [
              -48.1437,
              -22.2284
            ],
            [
              -48.1622,
              -22.2156
            ]
          ]
        ]
      },
      "geometry_name": "geom",
      "properties": {
        "id": "SBR497",
        "feattype": "eac_r"
      }
    }
  ]
}
```

</details><details id="bkmrk-vizualiza%C3%A7%C3%A3o-%C2%A0"><summary>Vizualização</summary>

 [![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/scaled-1680-/image.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/image.png)

</details>##### OIR USS ICEA

<details id="bkmrk-geojson-%7B%C2%A0-%22type%22%3A-%22"><summary>GeoJSON</summary>

{  
 "type": "FeatureCollection",  
 "features": \[  
 {  
 "type": "Feature",  
 "properties": {},  
 "geometry": {  
 "coordinates": \[  
 \[  
 \[  
 -48.04294926032304,  
 -22.29007270340638  
 \],  
 \[  
 -47.97913316615177,  
 -22.33798336379246  
 \],  
 \[  
 -47.97534728820932,  
 -22.27599508625559  
 \],  
 \[  
 -48.04294926032304,  
 -22.29007270340638  
 \]  
 \]  
 \],  
 "type": "Polygon"  
 }  
 }  
 \]  
}

</details><details id="bkmrk-visualiza%C3%A7%C3%A3o"><summary>Visualização</summary>

[![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/scaled-1680-/lROimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/lROimage.png)

</details>##### Restrição

<details id="bkmrk-geojson-%7B%C2%A0-%22type%22%3A-%22-1"><summary>GeoJSON</summary>

{  
 "type": "FeatureCollection",  
 "features": \[  
 {  
 "type": "Feature",  
 "properties": {},  
 "geometry": {  
 "coordinates": \[  
 \[  
 \[  
 -48.15454075371537,  
 -22.21502857838594  
 \],  
 \[  
 -48.07855594639369,  
 -22.26593911208886  
 \],  
 \[  
 -48.07126578841704,  
 -22.15692404482543  
 \],  
 \[  
 -48.15454075371537,  
 -22.21502857838594  
 \]  
 \]  
 \],  
 "type": "Polygon"  
 }  
 }  
 \]  
}

</details><details id="bkmrk-visualiza%C3%A7%C3%A3o-1"><summary>Visualização</summary>

[![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/scaled-1680-/WOpimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/WOpimage.png)

</details>

# [Desconflito][Autenticação] Roteiro Etapa 1

### Criação de OIR

Uma *Operational Intent Reference(OIR)* é a representação 4D da intenção de operação de uma aeronave não tripulada. No ambiente UTM, a criação e edição de OIRs deve ser coordenada com os outros provedores presentes ou interessados na região da operação. Para possibilitar que essa coordenação seja feita programaticamente, o DECEA manterá um serviço de Descoberta, que é um local onde provedores podem declarar suas operações, assim como obter as operações de outros provedores numa área específica.

Nesse workshop, iremos aprender a interagir com esse serviço de descoberta, chamado DSS. O DSS provido pelo DECEA é derivado da implementação feita pelo projeto [InterUSS](https://interussplatform.org/), que por sua vez é uma implementação dos padrões ASTM-3411 e ASTM-3548. A comunicação com o DSS é feita via HTTP e os contratos estão definidos em: [https://github.com/dp-icea/Protocols](https://github.com/dp-icea/Protocols)

A complexidade na criação da OIR depende de quantas outras entidades (Constraints ou outras OIRs) estão presentes no mesmo volume 4D. Nesse workshop, iniciaremos com o cenário mais simples, evoluindo até o cenário mais complexo.

<details id="bkmrk-oir-isolada-%C2%A0"><summary>OIR isolada</summary>

<div drawio-diagram="456"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2024-06/drawing-3-1719771300.png" alt=""/></div>

</details><details id="bkmrk-oir-pr%C3%B3xima-a-constr"><summary>OIR próxima a Constraint</summary>

<div drawio-diagram="460"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2024-06/drawing-3-1719772649.png" alt=""/></div>

</details><details id="bkmrk-oir-com-conflito-mai"><summary>OIR com conflito</summary>

**Maior ou igual prioridade**

<div drawio-diagram="465"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2024-06/drawing-3-1719773244.png" alt=""/></div>

**Menor prioridade**

<div drawio-diagram="464"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2024-06/drawing-3-1719773229.png" alt=""/></div>

</details><details id="bkmrk-endpoints-de-coorden"><summary>Endpoints de coordenação</summary>

[![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/scaled-1680-/7QUimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/7QUimage.png)

</details><details id="bkmrk-ativa%C3%A7%C3%A3o-de-oir-%28mom"><summary>Ativação de OIR (Momentos antes do voo)</summary>

Atualizar a OIR no DSS e notificar os Subscribers

[![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/scaled-1680-/mIlimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/mIlimage.png)

</details>#### Autenticação

<details id="bkmrk-autenticar-se-%C2%A0"><summary>Autenticar-se</summary>

A URL base é [`http://montreal.icea.decea.mil.br:64235/token`](http://montreal.icea.decea.mil.br:64235/token)

A requisição deve conter as seguintes *query\_strings*

<table border="1" style="border-collapse: collapse; width: 99.9786%; height: 106.033px;"><colgroup><col style="width: 50.0471%;"></col><col style="width: 50.0471%;"></col></colgroup><tbody><tr style="height: 46.5167px;"><td style="height: 46.5167px;">intended\_audience</td><td style="height: 46.5167px;"><span style="color: rgb(0, 0, 0);">USS de destino da mensagem (Domínio do provedor) Ex. "utm.decea.mil.br"</span></td></tr><tr style="height: 29.8px;"><td style="height: 29.8px;">scope</td><td style="height: 29.8px;"><span style="color: rgb(0, 0, 0);">escopo da requisição. Ex.: utm.strategic\_coordination.</span>

<span style="color: rgb(0, 0, 0);">O scope esperado de cada endpoint está definido no OpenAPI  
</span>

</td></tr><tr style="height: 29.7167px;"><td style="height: 29.7167px;">apikey</td><td style="height: 29.7167px;"><span style="color: rgb(0, 0, 0);">chave recebida do ICEA. Pode-se optar em enviar esse campo no Header da requisição  
</span></td></tr></tbody></table>

</details><details id="bkmrk-validar-autentica%C3%A7%C3%A3o"><summary>Validar autenticação de outro USS</summary>

Ao receber uma requisição de outro USS em seu servidor, é necessário validar o token de autenticação fornecido pelo outro USS. O payload do token contém as seguintes informações:

<table border="1" style="border-collapse: collapse; width: 99.9786%; height: 266.517px;"><colgroup><col style="width: 33.3333%;"></col><col style="width: 33.3333%;"></col><col style="width: 33.3333%;"></col></colgroup><tbody><tr style="height: 46.5167px;"><td style="height: 46.5167px;">aud  
</td><td style="height: 46.5167px;">Domínio do seu provedor.</td><td style="height: 46.5167px;">"utm.provider1.com"  
</td></tr><tr style="height: 63.4px;"><td style="height: 63.4px;">exp  
</td><td style="height: 63.4px;">Timestamp epoch do horário de expiração do token. O token não deve ser aceito a partir desse horário  
</td><td style="height: 63.4px;">1719777868</td></tr><tr style="height: 29.8px;"><td style="height: 29.8px;">iss  
</td><td style="height: 29.8px;">Nome do provedor emissor do token  
</td><td style="height: 29.8px;">ICEA  
</td></tr><tr style="height: 80.2px;"><td style="height: 80.2px;">scope  
</td><td style="height: 80.2px;">Scope autorizado pelo token. Cada endpoint deve aceitar apenas determinados scopes, conforme definido no OpenAPI  
</td><td style="height: 80.2px;">utm.strategic\_coordination  
</td></tr><tr style="height: 46.6px;"><td style="height: 46.6px;">sub  
</td><td style="height: 46.6px;">Nome do provedor origem da requisição. Não deve ser validado</td><td style="height: 46.6px;">"USS1"</td></tr></tbody></table>

Os passos para verificação são

1. Verificar assinatura do token 
    1. Deve-se validar a assinatura do token utilizando a chave pública do ICEA, que será fornecida durante o workshop.
2. Verificar a validade do token 
    1. Deve-se validar que o campo "exp" não seja menor do que o horário atual
3. Verficiar audiência do token 
    1. Deve-se validar que o campo "aud" seja o seu nome, ou seja, o nome do provedor que está recebendo a requisição
4. Verificar o scope 
    1. Deve-se validar que o campo "scope" contenha o scope necessário para requisitar o endpoint. Um token pode possuir mais de um scope separados por espaço em branco.

</details><details id="bkmrk-chave-publica-eco-ut"><summary>Chave Publica Eco-UTM</summary>

\-----BEGIN PUBLIC KEY-----  
MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgHkNtpy3GB0YTCl2VCCd22i0rJwI  
GBSazD4QRKvH6rch0IP4igb+02r7t0X//tuj0VbwtJz3cEICP8OGSqrdTSCGj5Y0  
3Oa2gPkx/0c0V8D0eSXS/CUC0qrYHnAGLqko7eW87HW0rh7nnl2bB4Lu+R8fOmQt  
5frCJ5eTkzwK5YczAgMBAAE=  
\-----END PUBLIC KEY-----

</details>

# Introdução Teórica RID e DSS

### Tracking / Network Remote ID

Tracking, Network Remote ID, ou simplesmente Net-RID, é um serviço que permite uma aeronave não tripulada (UAS) prover sua localização, identificação de seu operador e outras informações operacionais relevantes, que podem ser obtidas por entidades autorizadas como órgãos fiscalizadores, outros provedores operando na mesma área, ou até mesmo a população em geral.

Para fornecer o serviço de Net-RID, o provedor deve ser capaz de trocar informações com outros provedores utilizando a interface definida no padrão internacional [ASTM 3411-22a - Standard Specification for Remote ID and Tracking](https://www.astm.org/f3411-22a.html). Para possibilitar a interoperabilidade dos participantes e provedores, deve ser fornecido o serviço de "Service Discovery", que permite a descoberta de outros provedores atuando na mesma área.

<div drawio-diagram="125"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2023-12/drawing-3-1702641413.png" alt=""/></div>

Diagrama: Modelo conceitual

A ASTM também indica a seguinte documentação de API, como sugestão de interfaces para comunicação entre os serviços acima, que pode ser encontrada no padrão OpenAPI em: [https://github.com/uastech/standards/tree/astm\_rid\_api\_2.1/remoteid](https://github.com/uastech/standards/tree/astm_rid_api_2.1/remoteid)

Para nosso ensaio, seguiremos inicialmente a proposta acima, com possibilidade de alterações conforme o grupo achar necessário.

### Service Discovery

Conforme previsto no padrão ASTM F3411-22a, o service discovery deve possibilitar com que provedores descubram outros provedores atuando na mesma região, para que estes possam se comunicar. No cenário de comunicação HTTP, descobrir um provedor significa conhecer seu endereço web (url) para poder enviar requisições HTTP, em endpoints pré-definidos.

Para isso, a Linux Foundation possui um projeto chamado [InterUSS Platform](https://interussplatform.org/) que possui uma implementação do service discovery de maneira distribuída e sincronizada, denominado DSS (Discovery and Synchronization Service). Distribuído significa que várias entidades podem subir suas próprias instâncias do serviço, descentralizando e garantindo que não exista um ponto único de falha. Sincronizado significa que mesmo que haja múltiplas instâncias, todas possuem as mesmas informações ao mesmo tempo.

No escopo do ensaio, será utilizado o DSS sem nenhuma modificação inicial. Porém, para simplificação dos testes, o serviço possuirá somente uma instância, provida pelo DECEA. Isso permite que os potenciais provedores possam focar em implementar suas responsabilidades específicas e agilizar os processos do ensaio.

### Serviços BR-UTM

Seguindo a matriz de serviços que devem ser atendidos pelo BR-UTM, ao final do ensaio esperamos atender de forma completa o serviço de Discovery Service com o DSS, e o de Tracking and Location Service com o Net-RID. Também esperamos atender de forma parcial o Activity Reporting System com o Display Service do Net-RID.

<div drawio-diagram="127"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2023-12/drawing-3-1702647159.png" alt=""/></div>

# Autenticação Service Provider

### API Key:

Na comunicação do BR-UTM (imagem abaixo), as requisições devem ser autenticadas e autorizadas. Devido à natureza distribuída da arquitetura, não é viável que cada provedor possua sua lógica de autenticação e autorização.

[![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-04/scaled-1680-/image.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-04/image.png)

Portando, a solução proposta pela ASTM é a de um servidor de autenticação central onde os provedores obtém tokens OAuth2 codificados e assinados em JWT. O Validator da documentação abaixo checa a validade da assinatura do token, utilizando a chave pública do Auth Server.

[![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-04/scaled-1680-/LgFimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-04/LgFimage.png)

Um exemplo de troca de mensagens autenticadas é:

[![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-04/scaled-1680-/n2zimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-04/n2zimage.png)

### Uso da API Key  


Com sua API Key, você pode realizar ações programaticamente no ECO-UTM:

1. <span style="background-color: rgb(224, 62, 45);">Insira a sua API Key no *header* da requisição;</span>
2. <span style="background-color: rgb(224, 62, 45);">Insira o `scope` </span>
3. <span style="background-color: rgb(224, 62, 45);">Insira o `intended_audience`</span>  
    
    1. <span style="background-color: rgb(224, 62, 45);">Em caso de comunicação com outro USS, o preencha com o conteúdo do campo `manager` da resposta do DSS.</span>

### Validator

[![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/scaled-1680-/Pbcimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/Pbcimage.png)

#### Implementação

Código de exemplo para início da implementação do Auth Server e do Validator em Go

<details id="bkmrk-c%C3%B3digo-exemplo-packa"><summary>Código exemplo</summary>

```go
package main

import (
	"encoding/json"
	"flag"
	"log"
	"net/http"
	"os"
	"strings"

	"github.com/golang-jwt/jwt"
)

var (
	keyFile       = flag.String("private_key_file", "auth.key", "OAuth private key file")
	publicKeyFile = flag.String("public_key_file", "auth.pem", "OAuth public key file")
)

func verifyToken(token string) (bool, error) {
	bytes, err := os.ReadFile(*publicKeyFile)
	if err != nil {
		log.Panic(err)
	}

	publicKey, err := jwt.ParseRSAPublicKeyFromPEM(bytes)
	if err != nil {
		log.Panic(err)
	}

	parts := strings.Split(token, ".")
	err = jwt.SigningMethodRS256.Verify(strings.Join(parts[0:2], "."), parts[2], publicKey)
	if err != nil {
		return false, nil
	}
	return true, nil

}

func main() {

	http.HandleFunc("/validate", func(w http.ResponseWriter, r *http.Request) {
		tokenString := r.URL.Query().Get("token")
		valid, err := verifyToken(tokenString)
		if err != nil {
			log.Panic(err)
		}

		log.Println(valid)
	})

	http.HandleFunc("/token", func(w http.ResponseWriter, r *http.Request) {
		
		token := jwt.NewWithClaims(jwt.SigningMethodRS256, jwt.MapClaims{
			"aud":   "aud",
			"scope": "scope",
			"iss":   "iss",
			"exp":   "exp",
			"sub":   "sub",
		})

		// Read private key
		bytes, err := os.ReadFile(*keyFile)
		if err != nil {
			log.Panic(err)
		}
		privateKey, err := jwt.ParseRSAPrivateKeyFromPEM(bytes)
		if err != nil {
			log.Panic(err)
		}

		// Sign and get the complete encoded token as a string using the secret
		tokenString, err := token.SignedString(privateKey)
		if err != nil {
			log.Panic(err)
		}

		resp := make(map[string]string)
		resp["access_token"] = tokenString
		jsonResp, err := json.Marshal(resp)
		if err != nil {
			log.Fatalf("Error happened in JSON marshal. Err: %s", err)
		}
		w.WriteHeader(http.StatusOK)
		w.Header().Set("Content-Type", "application/json")
		w.Write(jsonResp)
		return

	})

	log.Fatal(http.ListenAndServe(":9096", nil))
}
```

</details><details id="bkmrk-eco-utm-autenticator"><summary>Eco-UTM Autenticator Public Key</summary>

```
-----BEGIN PUBLIC KEY-----
MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgHkNtpy3GB0YTCl2VCCd22i0rJwI
GBSazD4QRKvH6rch0IP4igb+02r7t0X//tuj0VbwtJz3cEICP8OGSqrdTSCGj5Y0
3Oa2gPkx/0c0V8D0eSXS/CUC0qrYHnAGLqko7eW87HW0rh7nnl2bB4Lu+R8fOmQt
5frCJ5eTkzwK5YczAgMBAAE=
-----END PUBLIC KEY-----
```

</details>### Lista de endpoints  


**A lista completa de *endpoints* também está disponível neste [link](http://montreal.icea.decea.mil.br:64235/swagger)<span style="background-color: rgb(224, 62, 45);">, [neste arquivo OpenAPI](https://servicos2.decea.mil.br/br-utm/wiki/attachments/31) e [nesta coleção no Insomina.](https://servicos2.decea.mil.br/br-utm/wiki/attachments/32)</span>**

#### ECO-UTM

A URL base para os seguintes *endpoints* é `<a href="http://montreal.icea.decea.mil.br:64235/">http://montreal.icea.decea.mil.br:64235/</a>`

---

<table border="1" class="align-center" id="bkmrk-get-%2Fuss%2Fflights" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.7969px; border-width: 0px;"><colgroup><col style="width: 75px;"></col><col></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(97, 175, 254);">**GET**</td><td class="align-left" style="height: 29.7969px; border-width: 0px;">/token</td></tr></tbody></table>

Aprovar token de autenticação do provedor associado ao usuário

<details id="bkmrk-query-parameters-vie"><summary>Path Param</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 59.5938px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px;">intented\_audience</td><td style="height: 29.7969px;"><span style="color: rgb(0, 0, 0);">user da entetidade de destino da mensagem</span>  
</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">scope</td><td style="height: 29.7969px;"><span style="color: rgb(0, 0, 0);">escopo da requisição</span></td></tr><tr><td>apikey</td><td><span style="color: rgb(0, 0, 0);">chave recebida do ICEA</span></td></tr></tbody></table>

</details><details id="bkmrk-bearer-token-que-tok"><summary>Bearer</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 193.969px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 50.0642%;"></col></colgroup><tbody><tr style="height: 113.781px;"><td style="height: 113.781px;">token</td><td style="height: 113.781px;"><span style="color: rgb(224, 62, 45);"><span style="color: rgb(0, 0, 0);">Bearer token gerado</span></span>  
</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22timestam"><summary>Código exemplo python</summary>

```ht
response = requests.get(
            f"{AUTH_URL}/token",
            params={
                "grant_type": "client_credentials",
                "intended_audience": "localhost",
                "scope": "utm.constraint_management",
                "apikey": "brutm",
            },
        )
```

</details><details id="bkmrk-response-200-success"><summary>Response</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 59.5938px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px;">200  
</td><td style="height: 29.7969px;">Success  
</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">403  
</td><td style="height: 29.7969px;">Non-Authoritative Information</td></tr></tbody></table>

</details><details id="bkmrk-response-body-access"><summary>Response Body</summary>

<table border="1" style="width: 100%;"><tbody><tr><td style="width: 15.145%;">access\_token</td><td style="width: 84.855%;">token de acesso ao ECO-UTM</td></tr></tbody></table>

</details>---

# [Remote ID] Onboarding Service Provider

No contexto do serviço de Network RemoteID, um Service Provider é um provedor USS que é capaz de receber dos seus drones os dados de localização em tempo real, e disponibilizar esses dados on demand em uma API também em tempo real. A especificação a ser seguida está definida pela ASTM F3411-22a. Ainda não foi definido a obrigatoriedade do item 4.4 "*Broadcast Remote ID".* Portanto, nessa página apenas será definido o uso dos itens 4.5 em diante.

### Pré-requisitos técnicos

Para um USS se tornar um provedor de Tracking existem os seguintes pré-requisitos técnicos que não estão no escopo dessa documentação, ficando a critério do provedor como implementar esses pré-requisitos:

1. Possuir um servidor HTTP para solicitar e receber as requisições listadas abaixo
2. Possuir infraestrutura para obter os dados de posição instantânea do drone. Esses dados devem estar disponíveis em tempo real no servidor HTTP

### Fluxograma

<div drawio-diagram="173"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2024-01/drawing-3-1704906440.png" alt=""/></div>

### Endpoints

A dinâmica de comunicação entre Service Provider, Display Provider e DSS está descrita na norma ASTM 3411-22a. Para facilitar o entendimento, alguns possíveis cenários de utilização estão descritos na página [Cenários](https://servicos2.decea.mil.br/br-utm/wiki/books/documentacao-tecnica/page/cenarios "Cenários").

O padrão seguido no ensaio será o descrito em [https://github.com/dp-icea/Protocols/tree/main/remoteid](https://github.com/dp-icea/Protocols/tree/main/remoteid)

Conforme o padrão OpenAPI acima, os endpoints que o Service Provider precisará prover

---

<table border="1" class="align-center" id="bkmrk-get-%2Fuss%2Fflights" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 75px;"></col><col></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(97, 175, 254);">**GET**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/uss/flights</td></tr></tbody></table>

Endpoint onde os Display Providers obterão os dados de tracking das aeronaves sob responsabilidade do Service Provider em uma determinada área

<details id="bkmrk-query-parameters-vie"><summary>Query Parameters</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 193.969px;"><colgroup><col style="width: 33.3333%;"></col><col style="width: 33.3333%;"></col><col style="width: 33.3333%;"></col></colgroup><tbody><tr style="height: 113.781px;"><td style="height: 113.781px;">view</td><td style="height: 113.781px;">Área da solicitação, representada por dois pontos no formato `lat1,lng1,lat2,lng2`. Os pontos são as extremidades da diagonal de um quadrado, onde esse quadrado representa a área da solicitação</td><td style="height: 113.781px;">29.978,31.132,29.980,31.135</td></tr><tr style="height: 80.1875px;"><td style="height: 80.1875px;">recent\_positions\_duration</td><td style="height: 80.1875px;">Se for maior que zero, indica que a requisição deve enviar todas as posições do drone nos últimos N segundos. Valor máximo: 60.

Se for zero, indica que deve ser enviado apenas a última posição do drone

</td><td style="height: 80.1875px;">60</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22timestam"><summary>Response</summary>

```json
{
  "timestamp": {
    "value": "1985-04-12T23:20:50.52Z",
    "format": "RFC3339"
  },
  "flights": [
    {
      "id": "PR-333334433.0dfe0e82-fd7a-44d9-af17-7fdd42751b45",
      "aircraft_type": "Helicopter",
      "current_state": RIDAircraftState,
      "operating_area": OperatingArea,
      "simulated": false,
      "recent_positions" = [ RIDRecentAircraftPosition ]
    }
  ],
  "no_isas_present": false
}
```

<table border="1" style="border-collapse: collapse; width: 100%; height: 438.109px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px;">timestamp</td><td style="height: 29.7969px;">Horário em que o Service Provider recebeu a requisição</td></tr><tr style="height: 124.953px;"><td style="height: 124.953px;">flights.id</td><td style="height: 124.953px;">ID único do provedor que identifica um voo em particular. Deverá vir no formato: "UAS\_ID.FLIGHT\_ID", onde UAS\_ID é código SISANT da aeronave, e FLIGHT\_ID é o uuid da solicitação do voo realizada no ECO-UTM.

</td></tr><tr style="height: 63.3906px;"><td style="height: 63.3906px;">flights.aircraft\_type</td><td style="height: 63.3906px;">Tipo de aeronave no padrão ICAO. Para drones, o tipo = Helicopter. Para drones de asa fixa que conseguem decolar verticalmente, o tipo = "HybridLift"</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">flights.current\_state</td><td style="height: 29.7969px;">Dados do tracking de fato da aeronave, no momento atual.</td></tr><tr style="height: 63.3906px;"><td style="height: 63.3906px;">flights.operating\_area</td><td style="height: 63.3906px;">A área que a aeronave se encontra. Deve ser usado apenas quando o campo "flights.current\_state" não está preenchido.</td></tr><tr style="height: 63.3906px;"><td style="height: 63.3906px;">flights.recent\_positions</td><td style="height: 63.3906px;">Lista de posições recentes da aeronave. Deve ser informado apenas quando as "recent\_positions" foram requisitadas.</td></tr><tr style="height: 63.3906px;"><td style="height: 63.3906px;">no\_isas\_present</td><td style="height: 63.3906px;">Indica se o provedor não possui nenhuma ISA na região informada. Caso esse valor retorne verdadeiro, o requisitante deve parar de realizar requisições para a área.</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fuss%2Fflights%2F%7Bid" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.7969px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: #61affe;">**GET**</td><td class="align-left" style="height: 29.7969px; border-width: 0px;">/uss/flights/{id}/details</td></tr></tbody></table>

Endpoint onde os Display Providers obterão dados específicos de um determinado voo

<details id="bkmrk-path-parameters-id-i"><summary>Path Parameters</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 29.7969px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 25.0321%;"></col><col style="width: 25.0321%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px;">id</td><td style="height: 29.7969px;">ID único do provedor para identificar o voo</td><td>b41f2785-1182-4c2e-82d5-f72f754b3fe2.0dfe0e82-fd7a-44d9-af17-7fdd42751b45</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22details%22"><summary>Response</summary>

```json
{
  "details": {
    "id": "b41f2785-1182-4c2e-82d5-f72f754b3fe2.0dfe0e82-fd7a-44d9-af17-7fdd42751b45",
    },
    "uas_id": {
      "registration_id": "PR-333334433",
    },
    "operator_id": "HUKMBB",
    "operator_location": {
      "position": {
        "lng": -118.456,
        "lat": 34.123
      },
      "altitude": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      },
      "altitude_type": "Takeoff"
    },
    "operation_description": "Descrição do voo, mesma descrição informada no SARPAS"
  }
}
```

<table border="1" style="border-collapse: collapse; width: 100%; height: 178.781px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px;">uas\_id</td><td style="height: 29.7969px;">Código SISANT da aeronave</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">operator\_id</td><td style="height: 29.7969px;">Código SARPAS do operador</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">operator\_location</td><td style="height: 29.7969px;">Localização do operador. Opcional</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">operation\_description</td><td style="height: 29.7969px;">Descrição da Operação conforme solicitação no SARPAS</td></tr></tbody></table>

</details>---

<table border="1" class="align-center" id="bkmrk-get-%2Fuss%2Fidentificat" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.7969px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: #61affe;">**GET**</td><td class="align-left" style="height: 29.7969px; border-width: 0px;">/uss/identification\_service\_areas/{id}</td></tr></tbody></table>

Endpoint para obter o volume 4D de uma ISA controlada pelo Service Provider

<details id="bkmrk-path-parameters-id-u"><summary>Path Parameters</summary>

<table border="1" style="border-collapse: collapse; width: 100%; height: 29.7969px;"><colgroup><col style="width: 50.0642%;"></col><col style="width: 25.0321%;"></col><col style="width: 25.0321%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px;">id</td><td style="height: 29.7969px;">UUID da área possuída pelo provedor</td><td>UUID</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22extents%22"><summary>Response</summary>

```json
{
  "extents": {
    "volume": {
      "outline_circle": {
        "center": {
          "lng": -118.456,
          "lat": 34.123
        },
        "radius": {
          "value": 300.183,
          "units": "M"
        }
      },
      "outline_polygon": {
        "vertices": [
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          }
        ]
      },
      "altitude_lower": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      },
      "altitude_upper": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      }
    },
    "time_start": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "time_end": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    }
  }
}
```

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>volume</td><td>Volume 4D da área específica</td></tr></tbody></table>

</details>### Interação com DSS

O Service Provider, conforme definido no padrão ASTM3411-22a, deve criar entidades de área 4D denominadas Identification Service Area (ISA), onde este proverá o serviço de tracking. Os endpoints expostos pelo DSS estão descritos no arquivo OpenAPI descrito acima.

---

Como exemplo, o endpoint abaixo é onde o Service Provider realizará a criação da ISA no DSS:

<table border="1" class="align-center" id="bkmrk-put-%2Fdss%2Fidentificat" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.7969px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: #fca130;">**PUT**</td><td class="align-left" style="height: 29.7969px; border-width: 0px;">/dss/identification\_service\_area/{id}</td></tr></tbody></table>

Endpoint exposto pelo DSS onde o Service Provider realizará a criação da ISA. Essa área deve ser idêntica à area solicitada e aprovada no Sarpas

<details id="bkmrk-path-param-id-uuid-g"><summary>Path Param</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>id</td><td>UUID da ISA. Deve ser o mesmo UUID devolvido pelo ECO-UTM após a criação da solicitação de voo.  
</td></tr></tbody></table>

</details><details id="bkmrk-body-%7B-%22extents%22%3A-%7B-"><summary>Body</summary>

```json
{
  "extents": {
    "volume": {
      "outline_circle": {
        "center": {
          "lng": -118.456,
          "lat": 34.123
        },
        "radius": {
          "value": 300.183,
          "units": "M"
        }
      },
      "outline_polygon": {
        "vertices": [
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          }
        ]
      },
      "altitude_lower": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      },
      "altitude_upper": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      }
    },
    "time_start": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "time_end": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    }
  },
  "uss_base_url": "https://example.com/rid"
}
```

Campos notáveis

<table border="1" style="border-collapse: collapse; width: 100%; height: 76.3907px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 46.5938px;"><td style="height: 46.5938px;">volume</td><td style="height: 46.5938px;">Polígono **OU** círculo da área, idêntico ao definido no SARPAS</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">altitude\_lower, altitude\_upper</td><td style="height: 29.7969px;">Altitude geodésica (WSG84, W84) máxima e mínima em metros.

</td></tr><tr><td>time\_start, time\_end</td><td>Horário de início e fim da área. Todos os horários devem estar no timezone Zulo (UTC+0). O único formato suportado é "RFC3339"

</td></tr><tr><td>uss\_base\_url</td><td>URL a qual o Service Provider irá responder à solicitações. Não deve conter uma barra '/' ao final. Sugere-se utilizar uma URL e não um IP.

</td></tr></tbody></table>

</details><details id="bkmrk-response-%7B-%22subscrib"><summary>Response</summary>

```json
{
  "subscribers": [],
  "service_area": {
    "uss_base_url": "https://example.com/rid",
    "owner": "myuss",
    "time_start": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "time_end": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "version": "string",
    "id": "string"
  }
}
```

Campos notáveis

<table border="1" style="border-collapse: collapse; width: 100%; height: 141.781px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 63.3906px;"><td style="height: 63.3906px;">subcribers</td><td style="height: 63.3906px;">Lista dos atuais subcribers dessa área. Caso a lista não esteja vazia, é **OBRIGATÓRIO** o envio da ISA para cada um dos subscribers listados</td></tr><tr style="height: 78.3906px;"><td style="height: 78.3906px;">version</td><td style="height: 78.3906px;">Versão da ISA, gerado pelo DSS, para garantia de integridade. É necessário utilizar esse campo para atualizar ou deletar uma ISA.</td></tr></tbody></table>

</details>

# [Tracking] Onboarding Display Provider

No contexto do serviço de Tracking, um Display Provider é um provedor USS que tem objetivo de exibir a posição de drones em tempo real para seus usuários.

### Pré-requisitos técnicos

Para um USS se tornar um provedor de display de Tracking existem os seguintes pré-requisitos técnicos que não estão no escopo dessa documentação, ficando a critério do provedor como implementar esses pré-requisitos:

1. Possuir um servidor HTTP para solicitar e receber requisições
2. Possuir App para visualização de posição de drones

### Autenticação

Para o ensaio, a autenticação será feita em um serviço OAuth centralizado do DECEA, ainda a ser descrito.

### Endpoints

A dinâmica de comunicação entre Service Provider, Display Provider e DSS está descrita na norma ASTM 3411-22a. Para facilitar o entendimento, alguns possíveis cenários de utilização estão descritos na página [Cenários](https://servicos2.decea.mil.br/br-utm/wiki/books/documentacao-tecnica/page/cenarios "Cenários").

O padrão seguido no ensaio será o descrito em [https://github.com/uastech/standards/tree/astm\_rid\_api\_2.1/remoteid](https://github.com/uastech/standards/tree/astm_rid_api_2.1/remoteid)

Conforme o padrão OpenAPI acima, os endpoints que o Display Provider precisará prover:

<table border="1" class="align-center" id="bkmrk-get-%2Fuss%2Fflights" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.8px; border-width: 0px;"><colgroup><col style="width: 75px;"></col><col></col></colgroup><tbody><tr style="height: 29.8px;"><td style="height: 29.8px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: rgb(73, 204, 144);">**POST**</td><td class="align-left" style="height: 29.8px; border-width: 0px;">/uss/identification\_service\_areas/{id}</td></tr></tbody></table>

<details id="bkmrk-path-parameters-id-u-1"><summary>Path Parameters</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>id</td><td>UUID da ISA</td></tr></tbody></table>

</details><details id="bkmrk-request-body-%7B-%22serv"><summary>Request Body</summary>

</details>### Interação com DSS

O Service Provider, conforme definido no padrão ASTM3411-22a, deve criar entidades de Subscription em uma área específica, para encontrar os atuais Service Providers, e também para receberem notificações caso novos provedores se registrem na área. Os endpoints expostos pelo DSS estão descritos no arquivo OpenAPI descrito acima.

Como exemplo, o endpoint abaixo é para criação de Subscriptions:

<table border="1" class="align-center" id="bkmrk-put-%2Fdss%2Fidentificat" style="font-family: var(--font-body); font-size: 14px; width: 100%; height: 29.7969px; border-width: 0px;"><colgroup><col style="width: 9.25926%;"></col><col style="width: 90.7407%;"></col></colgroup><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px; border-width: 0px; background-clip: padding-box; color: white; border-radius: 5px; background-color: #fca130;">**PUT**</td><td class="align-left" style="height: 29.7969px; border-width: 0px;">/dss/subscriptions/{id}</td></tr></tbody></table>

<details id="bkmrk-path-parameters-id-u"><summary>Path Parameters</summary>

<table border="1" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>id</td><td>UUID da Subscription, criado pelo Display Provider</td></tr></tbody></table>

</details><details id="bkmrk-request-body-%7B-%22exte"><summary>Request Body</summary>

```json
{
  "extents": {
    "volume": {
      "outline_circle": {
        "center": {
          "lng": -118.456,
          "lat": 34.123
        },
        "radius": {
          "value": 300.183,
          "units": "M"
        }
      },
      "outline_polygon": {
        "vertices": [
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          },
          {
            "lng": -118.456,
            "lat": 34.123
          }
        ]
      },
      "altitude_lower": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      },
      "altitude_upper": {
        "value": 19.5,
        "reference": "W84",
        "units": "M"
      }
    },
    "time_start": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "time_end": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    }
  },
  "uss_base_url": "https://example.com/rid"
}
```

Campos notáveis

<table border="1" style="border-collapse: collapse; width: 100%; height: 76.3907px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 46.5938px;"><td style="height: 46.5938px;">volume</td><td style="height: 46.5938px;">Polígono **OU** círculo da área, idêntico ao definido no SARPAS</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">altitude\_lower, altitude\_upper</td><td style="height: 29.7969px;">Altitude geodésica (WSG84, W84) máxima e mínima em metros.

</td></tr><tr><td>time\_start, time\_end</td><td>Horário de início e fim da área. Todos os horários devem estar no timezone Zulo (UTC+0). O único formato suportado é "RFC3339"

</td></tr><tr><td>uss\_base\_url</td><td>URL a qual o Service Provider irá responder à solicitações. Não deve conter uma barra '/' ao final. Sugere-se utilizar uma URL e não um IP.

</td></tr></tbody></table>

</details><details id="bkmrk-response-body-%7B-%22ser"><summary>Response Body</summary>

```json
{
  "service_areas": [],
  "subscription": {
    "id": "string",
    "uss_base_url": "https://example.com/rid",
    "owner": "myuss",
    "notification_index": 0,
    "time_end": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "time_start": {
      "value": "1985-04-12T23:20:50.52Z",
      "format": "RFC3339"
    },
    "version": "string"
  }
}
```

<table border="1" style="border-collapse: collapse; width: 100%; height: 122.984px;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr style="height: 63.3906px;"><td style="height: 63.3906px;">service\_areas</td><td style="height: 63.3906px;">Lista de ISAs já existentes no volume 4D. Caso a lista não esteja vazia, o Display Provider deve solicitar os dados de telemetria para as URLs definidas na lista</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">version</td><td style="height: 29.7969px;">Versão da Subscription, gerado pelo DSS, para garantia de integridade. É necessário utilizar esse campo para atualizar ou deletar uma Subscription.</td></tr></tbody></table>

</details>

# [USS Qualifier] Teste automatizado de Provedor

US: [https://pista.decea.mil.br/project/br-utm-tecnologia/us/41?milestone=309](https://pista.decea.mil.br/project/br-utm-tecnologia/us/41?milestone=309)

#### Introdução

A [InterUSS](https://interussplatform.org/) disponibiliza um conjunto de testes suites automatizados ([USS QUALIFIER](https://github.com/interuss/monitoring)) para validar os conformidade na implementação de UAS Service Suppliers (USS).

Validação dos seguintes critérios de conforme:  
\- [Remote ID ](https://www.astm.org/f3411-22a.html)(ASTM F3411-19/22);  
-[ Strategic Conflict Detection ](https://www.astm.org/f3548-21.html)(ASTM F3548-21);  
\- UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability Specification.

Como a implementação do DSS feita pelo time de pesquisa do ICEA foi feita a partir da solução da InterUSS, para um provedor se integrar ao nosso ecossistema, sua implementação deve estar em concordância com as normas utilizadas em sua implementação.

O objetivo dessa US é implementar a configuração de um ambiente de testes automatizada a partir de um arquivo .env

#### Solução

Para utilizar USS locais em seus testes, deve-se subir um container contendo a aplicação e sua configuração de ambiente, a qual deve conter as seguintes variáveis:

```yaml
 environment:
      - MOCK_USS_AUTH_SPEC=DummyOAuth(http://oauth.authority.localutm:8085/token,uss1)
      - MOCK_USS_DSS_URL=http://dss.uss1.localutm
      - MOCK_USS_PUBLIC_KEY=/var/test-certs/auth2.pem
      - MOCK_USS_TOKEN_AUDIENCE=scdsc.uss1.localutm,localhost,host.docker.internal
      - MOCK_USS_BASE_URL=http://scdsc.uss1.localutm
      - MOCK_USS_SERVICES=scdsc,versioning,interaction_logging,flight_planning
      - MOCK_USS_INTERACTIONS_LOG_DIR=output/scdsc_a_interaction_logs
      - MOCK_USS_PORT=80
      - MOCK_USS_PROXY_VALUES=x_for=1,x_proto=1,x_host=1,x_prefix=1,x_port=1
```

Após configurar e implantar o USS, pode-se configurar o test suite que deseja executar. Como existem perfis diferentes de USS, foram disponibilizados arquivos de configuração visando validar conformes mais específicos dos seus respectivos tipos, estes podem ser encontrados no diretório `monitoring/monitoring/uss_qualifier/configurations/dev/`

[![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/Efcimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/Efcimage.png)

Caso seja necessário criar um novo arquivo de teste, é necessário implementá-lo através de um arquivo .yaml ou JSON seguindo as guidelines definidas nesse [README](https://github.com/interuss/monitoring/tree/03a462d7a209528b885ffa9651d936e8b4df8f18/monitoring/uss_qualifier/configurations)

#### How to

[Quick start guide](https://github.com/interuss/monitoring/tree/main/monitoring/uss_qualifier)

```bash

git clone https://github.com/interuss/monitoring.git

cd monitoring

#deploys local infrastructure containing DSS, database and Auth Server 
make start-locally

COMPOSE_PROFILES='' make start-uss-mocks

cd /monitoring/uss_qualifier

./run_locally.sh

```

# OIR Status

<span style="color: rgb(34, 34, 34); font-family: var(--font-heading, var(--font-body)); font-size: 1.666em; font-weight: 400;">Responsabilidades Provedores</span>

- <span style="text-decoration: underline;">Utilizar todos os estados das OIRs</span>
    - Ao criar uma OIR, ela está no estado "Accepted". Quando a operação iniciar, o provedor deve mudar o status para "Activated". Ao fim da operação, o provedor deve encerrar a OIR, deletando ela do DSS.
    - Em casos de Não conformidade e contingência, o provedor deve mudar o status da OIR. Os outros provedores subscritos na área devem agir de acordo com a nova situação.
    - [![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/qRoimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/qRoimage.png)
- <span style="text-decoration: underline;">Utilizar NTP do ICEA</span>
    - O ICEA disponibilizará um servidor NTP para sincronizar os horários entre todos os provedores.
    - [![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/dqbimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/dqbimage.png)
- <span style="text-decoration: underline;">Utilizar altitude WSG84</span>
    - Padronizar o uso de altitude utilizando o padrão WSG84.
- <span style="text-decoration: underline;">Utilizar autenticação</span>
    - Para comunicação com o DSS e entre provedores, toda requisição deve possuir um token emitido pelo servidor de autenticação do ICEA
- <span style="text-decoration: underline;">Utilizar campo de prioridade na OIR</span>
    - Os provedores devem considerar o campo "priority" na criação de OIR.
    - Uma OIR com prioridade maior pode "sobrescrever" uma com prioridade menor. Ou seja, as OIRs com maior prioridade podem ser criadas onde já existia uma outra OIR com prioridade menor.
    - A tabela descrevendo qual a prioridade de cada tipo de operação ainda será definida.
- <span style="text-decoration: underline;">Permitir conflito entre voos VLOS/EVLOS</span>
    - OIRs para voos visuais podem ter conflito com outras OIRs de voos visuais.
    - OIRs para voos não visuais não podem ter conflito com nenhuma outra OIR, de nenhum tipo

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

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

[![0 - Fluxo.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/0-fluxo-1.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/0-fluxo-1.png "Teste")

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.

[![1 - Autorização de Voo (1).png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/1-autorizacao-de-voo-1.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/1-autorizacao-de-voo-1.png)

P1 - Autorização de Voo

[![1.1 - Desconflito Estratégico (1).png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/1-1-desconflito-estrategico-1.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/1-1-desconflito-estrategico-1.png)

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.

[![2 - Ativação de voo (3).png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/2-ativacao-de-voo-3.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/2-ativacao-de-voo-3.png)

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.

[![3 - Mudanças Dinâmicas (1).png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/3-mudancas-dinamicas-1.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/3-mudancas-dinamicas-1.png)

P3 - Mudanças Dinâmicas

---

#### Emergência

WIP

# Operações USS: Diagramas de Sequencia

#### Cenário 1:

Apenas um Service provider e nenhum Display provider na área durante o Voo

<div drawio-diagram="255"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2024-02/drawing-3-1709118152.png" alt=""/></div>

#### Cenário 2:

Service provider cria área onde já existe uma Subscription (Display Provider)

<div drawio-diagram="730"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2025-07/drawing-3-1752236349.png" alt=""/></div>

#### Cenário 3:

Criação de Subscription onde já exista ISA

<div drawio-diagram="116"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2023-12/drawing-3-1702578754.png" alt=""/></div>

#### Cenário 4:

Usuário do Display Provider deseja visualizar uma área. Nessa área já existe um Service Provider (USS 1), e durante a exibição, um novo Service Provider (USS 2) inicia operações na área. Esse cenário foi adaptado da documentação do InterUSS DSS.

<div drawio-diagram="128"><img src="https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/drawio/2023-12/drawing-3-1702692143.png" alt=""/></div>

# [USS][Desconflito] Código Exemplo

Exemplo de código Provedor de Desconflito (Go e Python): [https://github.com/dp-icea/scd\_provider](https://github.com/dp-icea/scd_provider)

Para realizar autenticação:

1. Verificar se está gerando o token

Para criar OIR:

1. Enviar GeoJSON da área desejada

Abaixo segue exemlpo de código em Python:

<details id="bkmrk-app.py-from-flask-im"><summary>app.py</summary>

```python
from flask import Flask, request

from dss import Dss

import json

app = Flask(__name__)

database = {}

dss = Dss()


@app.route('/uss/v1/operational_intents/<operational_intent_id>', methods=['GET'])
def get_oir(operational_intent_id):
    print(database)
    if operational_intent_id not in database:
        return {"msg": 'No such OIR'}, 404

    return json.dumps(database[operational_intent_id], default=lambda o: o.__dict__)


@app.route('/injection/oir', methods=['PUT'])
def inject_oir():
    volume = request.get_json()
    try:
        dss.conflict_manager.check_restrictions(volume)
        dss.scd.check_strategic_conflicts(volume)
        oir = {}
        oir["operational_intent"] = {}
        oir["operational_intent"]["reference"] = dss.scd.put_operational_intent(volume)
        oir["operational_intent"]["details"] = {
            "volumes": [],
            "off_nominal_volumes": [],
            "priority": 0
        }
        oir["operational_intent"]["details"]["volumes"].append(volume)
        database[oir["operational_intent"]["reference"]['id']] = oir


    except Exception as ex:
        print(f"Erro na criação: {ex}")
        return {"msg": "Erro"}, 400

    return {"Success": True}, 201


if __name__ == '__main__':
    app.run(port=5050)


```

</details><details id="bkmrk-dss.py-from-conflict"><summary>dss.py</summary>

```python
from conflict_manager import ConflictManager
from scd import Scd


class Dss:
    def __init__(self) -> None:
        self.conflict_manager = ConflictManager()
        self.scd = Scd()

```

</details><details id="bkmrk-scd.py-import-reques"><summary>scd.py</summary>

```python
import requests
import uuid

from env import USS_BASE_URL, DSS_HOST


class Scd:

    def __init__(self) -> None:
        self.auth()

    def auth(self):
        url = "http://kong.icea.decea.mil.br:64235/token?grant_type=client_credentials&intended_audience=localhost&issuer=localhost&scope={0}"
        self.strategic_coordination = requests.get(url.format("utm.strategic_coordination")).json()["access_token"]

    def check_strategic_conflicts(self, volume):
        url = DSS_HOST + "/dss/v1/operational_intent_references/query"
        body = {
            "area_of_interest": volume
        }
        header = {"authorization": f"Bearer {self.strategic_coordination}"}
        response = requests.post(url, headers=header, json=body).json()

        if (len(response['operational_intent_references']) > 0):
            raise Exception(f"Interseção com outra Intenção {response['operational_intent_references'][0]['id']}")
        else:
            print("Sem intenções para o volume")
        
    def put_operational_intent(self, volume):
        id = str(uuid.uuid4())
        url = DSS_HOST + f"/dss/v1/operational_intent_references/{id}"

        body = {
            "flight_type": "VLOS",
            "extents": [volume],
            "key": [],
            "state": "Accepted",
            "uss_base_url": USS_BASE_URL,
            "new_subscription": {
                "uss_base_url": USS_BASE_URL,
                "notify_for_constraint": False
            }
        }

        print(body)

        header = {"authorization": f"Bearer {self.strategic_coordination}"}

        response = requests.put(url, headers=header, json=body).json()

        print(f"OIR criada com id: {id}")
        print(response)

        return response['operational_intent_reference']


```

</details><details id="bkmrk-conflict_manager.py-"><summary>conflict\_manager.py</summary>

```python
import requests
import uuid

from env import USS_BASE_URL, DSS_HOST


class Scd:

    def __init__(self) -> None:
        self.auth()

    def auth(self):
        url = "http://kong.icea.decea.mil.br:64235/token?grant_type=client_credentials&intended_audience=localhost&issuer=localhost&scope={0}"
        self.strategic_coordination = requests.get(url.format("utm.strategic_coordination")).json()["access_token"]

    def check_strategic_conflicts(self, volume):
        url = DSS_HOST + "/dss/v1/operational_intent_references/query"
        body = {
            "area_of_interest": volume
        }
        header = {"authorization": f"Bearer {self.strategic_coordination}"}
        response = requests.post(url, headers=header, json=body).json()

        if (len(response['operational_intent_references']) > 0):
            raise Exception(f"Interseção com outra Intenção {response['operational_intent_references'][0]['id']}")
        else:
            print("Sem intenções para o volume")
        
    def put_operational_intent(self, volume):
        id = str(uuid.uuid4())
        url = DSS_HOST + f"/dss/v1/operational_intent_references/{id}"

        body = {
            "flight_type": "VLOS",
            "extents": [volume],
            "key": [],
            "state": "Accepted",
            "uss_base_url": USS_BASE_URL,
            "new_subscription": {
                "uss_base_url": USS_BASE_URL,
                "notify_for_constraint": False
            }
        }

        print(body)

        header = {"authorization": f"Bearer {self.strategic_coordination}"}

        response = requests.put(url, headers=header, json=body).json()

        print(f"OIR criada com id: {id}")
        print(response)

        return response['operational_intent_reference']


```

</details>

# Ensaio Operacional 2 - Agosto 2025



# Escopo

Escopo do Segundo Ensaio Técnico do BR-UTM, ainda sem data definida. A previsão é executar o ensaio em ambiente de produção, na SBR-497.

#### Responsabilidades Provedores

- <span style="text-decoration: underline;">Utilizar todos os estados das OIRs</span>
    - Ao criar uma OIR, ela está no estado "Accepted". Quando a operação iniciar, o provedor deve mudar o status para "Activated". Ao fim da operação, o provedor deve encerrar a OIR, deletando ela do DSS.
    - Em casos de Não conformidade e contingência, o provedor deve mudar o status da OIR. Os outros provedores subscritos na área devem agir de acordo com a nova situação.
    - [![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/qRoimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/qRoimage.png)
- <span style="text-decoration: underline;">Utilizar NTP do ICEA</span>
    - O ICEA disponibilizará um servidor NTP para sincronizar os horários entre todos os provedores.
    - [![image.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/dqbimage.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/dqbimage.png)
- <span style="text-decoration: underline;">Utilizar altitude WSG84</span>
    - Padronizar o uso de altitude utilizando o padrão WSG84.
- <span style="text-decoration: underline;">Utilizar autenticação</span>
    - Para comunicação com o DSS e entre provedores, toda requisição deve possuir um token emitido pelo servidor de autenticação do ICEA
- <span style="text-decoration: underline;">Utilizar campo de prioridade na OIR</span>
    - Os provedores devem considerar o campo "priority" na criação de OIR.
    - Uma OIR com prioridade maior pode "sobrescrever" uma com prioridade menor. Ou seja, as OIRs com maior prioridade podem ser criadas onde já existia uma outra OIR com prioridade menor.
    - A tabela descrevendo qual a prioridade de cada tipo de operação ainda será definida.
- <span style="text-decoration: underline;">Permitir conflito entre voos VLOS/EVLOS</span>
    - OIRs para voos visuais podem ter conflito com outras OIRs de voos visuais.
    - OIRs para voos não visuais não podem ter conflito com nenhuma outra OIR, de nenhum tipo.

#### Responsabilidades ICEA/DECEA

- Adapter do Sarpas para DSS
- Adapter do DASA para DSS
- Criar servidor NTP
- Centralizador de logs
- Servidor auth
- Ferramenta de onboarding provedores
- Cadastro de provedores

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

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

[![0 - Fluxo.png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/0-fluxo-1.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/0-fluxo-1.png "Teste")

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.

[![1 - Autorização de Voo (1).png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/1-autorizacao-de-voo-1.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/1-autorizacao-de-voo-1.png)

P1 - Autorização de Voo

[![1.1 - Desconflito Estratégico (1).png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/1-1-desconflito-estrategico-1.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/1-1-desconflito-estrategico-1.png)

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.

[![2 - Ativação de voo (3).png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/2-ativacao-de-voo-3.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/2-ativacao-de-voo-3.png)

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.

[![3 - Mudanças Dinâmicas (1).png](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/scaled-1680-/3-mudancas-dinamicas-1.png)](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/3-mudancas-dinamicas-1.png)

P3 - Mudanças Dinâmicas

---

#### Emergência

WIP

# Briefing: BR-UTM Field Test 2

**<span class="selected">Document Version:</span>**<span class="selected"> 1.2 </span>**<span class="selected">Date:</span>**<span class="selected"> June 16, 2025</span>

## <span class="selected">1. Introduction &amp; Vision</span>

<span class="selected">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.</span>

<span class="selected">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.</span>

### <span class="selected">1.1. New Features for Validation</span>

<span class="selected">This test will validate all previously tested features, plus the following crucial additions:</span>

- **<span class="selected">USS-to-USS Authentication:</span>**<span class="selected"> Secure, token-based authentication for all inter-USS communication.</span>
- **<span class="selected">OIR Activation &amp; State Management:</span>**<span class="selected"> The full lifecycle of an OIR, including the transition to an "activated" state just before flight.</span>
- **<span class="selected">Priority Operations:</span>**<span class="selected"> Handling of high-priority flights that may require other operations to adjust.</span>
- **<span class="selected">Remote Identification (Remote ID):</span>**<span class="selected"> Integration of Remote ID information services into the USS workflow.</span>
- **<span class="selected">In-Flight Contingency Management:</span>**<span class="selected"> Real-time response to dynamic, high-priority airspace constraints that appear during an active flight.</span>

## <span class="selected">2. Core Objectives</span>

<span class="selected">The primary goals of this field test are to:</span>

1. **<span class="selected">Validate End-to-End OIR Lifecycle:</span>**<span class="selected"> Demonstrate the complete process of creating, strategically deconflicting, activating, and closing out OIRs in a multi-USS environment.</span>
2. **<span class="selected">Verify Secure Inter-USS Coordination:</span>**<span class="selected"> Ensure all participants can successfully implement and use the specified authentication protocols for all DSS and peer-to-peer USS interactions.</span>
3. **<span class="selected">Test Advanced Strategic Deconfliction:</span>**<span class="selected"> Validate the system's ability to manage and resolve conflicts between multiple OIRs, including those with different priorities.</span>
4. **<span class="selected">Demonstrate OIR Activation:</span>**<span class="selected"> Ensure that the transition of an OIR to its "activated" state is correctly propagated and managed by all relevant USSs.</span>
5. **<span class="selected">Validate Priority Handling:</span>**<span class="selected"> Successfully manage the introduction of a high-priority OIR, requiring other active or planned operations to be modified or cleared.</span>
6. **<span class="selected">Integrate Remote ID Services:</span>**<span class="selected"> Demonstrate that USSs can support the provision of Remote ID data for active flights to authorized entities.</span>
7. **<span class="selected">Conduct Live Flight Operations:</span>**<span class="selected"> Have operators fly drones based on successfully coordinated and activated OIRs, proving the link between the digital UTM system and real-world flight.</span>

## <span class="selected">3. Technical Architecture &amp; Protocols</span>

<span class="selected">The core of the technical architecture remains the DECEA-provided </span>**<span class="selected">Discovery and Synchronization Service (DSS)</span>**<span class="selected">, which is an implementation of the InterUSS Platform.</span>

- **<span class="selected">API Contracts:</span>**<span class="selected"> All participants must implement the server-side and client-side portions of the API contracts defined in the </span>[**<span class="selected">dp-icea/Protocols GitHub repository</span>**](https://github.com/dp-icea/Protocols "null")<span class="selected">. This is the single source of truth for all required interfaces.</span>
- **<span class="selected">DSS Implementation:</span>**<span class="selected"> For context and documentation on the underlying technology, refer to the </span>[**<span class="selected">interuss/dss GitHub repository</span>**](https://github.com/interuss/dss "null")<span class="selected">.</span>

### <span class="selected">3.1. Authentication</span>

<span class="selected">Authentication is </span>**<span class="selected">mandatory</span>**<span class="selected"> for all inter-USS and DSS API calls. The process is detailed in the workshop documentation [\[Desconflito\]\[Autenticação\] Roteiro Etapa 1](https://servicos2.decea.mil.br/br-utm/wiki/books/documentacao-tecnica/page/desconflitoautenticacao-roteiro-etapa-1 "[Desconflito][Autenticação] Roteiro Etapa 1")</span><span class="selected">.</span>

- **<span class="selected">Token Generation:</span>**<span class="selected"> Before making a request to another USS, you must first request a JSON Web Token (JWT) from the DECEA authentication service. The </span>`<span class="selected">intended_audience</span>`<span class="selected"> and </span>`<span class="selected">scope</span>`<span class="selected"> parameters are critical.</span>
- **<span class="selected">Token Validation:</span>**<span class="selected"> When your USS receives a request, you must validate the incoming JWT. This involves:</span>
    
    
    1. <span class="selected">Verifying the token's signature using the Eco-UTM public key.</span>
    2. <span class="selected">Checking the token's expiration time (</span>`<span class="selected">exp</span>`<span class="selected">).</span>
    3. <span class="selected">Confirming the audience (</span>`<span class="selected">aud</span>`<span class="selected">) matches your USS identifier.</span>
    4. <span class="selected">Ensuring the token contains the required </span>`<span class="selected">scope</span>`<span class="selected"> for the requested endpoint.</span>

### <span class="selected">3.2. Governing Standards</span>

<span class="selected">This field test will adhere to the following international standards, which form the basis of the technical and operational protocols:</span>

- **<span class="selected">UTM Interoperability:</span>**<span class="selected"> All strategic coordination and information exchange between USSs shall be conducted in accordance with </span>**<span class="selected">ASTM F3548-21</span>**<span class="selected">, "Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability."</span>
- **<span class="selected">Remote ID:</span>**<span class="selected"> The implementation and data formats for Network Remote ID services shall follow </span>**<span class="selected">ASTM F3411-22a</span>**<span class="selected">, "Standard Specification For Remote ID And Tracking."</span>

## <span class="selected">4. Participant Roles &amp; Responsibilities</span>

<span class="selected">Participants can choose to act in one or both of the following roles:</span>

- **<span class="selected">USS Provider:</span>**<span class="selected"> An entity running a software implementation that provides UAS services.</span>
    
    
    - **<span class="selected">Responsibilities:</span>**
        
        
        - <span class="selected">Implement the full API contract.</span>
        - <span class="selected">Integrate with the authentication service.</span>
        - <span class="selected">Connect to the central DSS to discover other operations and publish their own.</span>
        - <span class="selected">Manage the full lifecycle of OIRs on behalf of their operator clients.</span>
        - <span class="selected">Coordinate directly with other USSs for strategic deconfliction.</span>
        - <span class="selected">Provide an endpoint for other USSs to subscribe to updates for OIRs they manage.</span>
- **<span class="selected">Drone Operator:</span>**<span class="selected"> An entity that plans and executes drone flights.</span>
    
    
    - **<span class="selected">Responsibilities:</span>**
        
        
        - <span class="selected">Partner with a registered USS Provider for flight planning.</span>
        - <span class="selected">Conduct pre-flight checks.</span>
        - <span class="selected">Execute the flight mission precisely according to the activated OIR (trajectory, altitude, and time).</span>
        - <span class="selected">Equip the drone with the necessary hardware for Remote ID broadcast.</span>
        - <span class="selected">Maintain communication with the USS during flight and be prepared to act on in-flight instructions, including immediate termination of the operation.</span>

## <span class="selected">5. Test Scenarios</span>

<span class="selected">The field test will be structured around a series of progressively complex scenarios.</span>

### <span class="selected">Scenario 1: Nominal Coordination and Flight Activation</span>

- **<span class="selected">Objective:</span>**<span class="selected"> Validate the basic workflow, authentication, and OIR activation.</span>
- **<span class="selected">Execution:</span>**
    
    
    1. <span class="selected">Two or more USS providers will each create a distinct, non-conflicting OIR in the DSS.</span>
    2. <span class="selected">Just prior to the scheduled flight time, each USS will update their OIR state to </span>**`<span class="selected">Accepted</span>`**<span class="selected"> and then </span>**`<span class="selected">Activated</span>`**<span class="selected">. They must notify any subscribers of this change.</span>
    3. <span class="selected">The corresponding Drone Operator will execute the flight.</span>
    4. <span class="selected">During the flight, the drone will broadcast Remote ID data.</span>
    5. <span class="selected">Upon completion, the USS will update the OIR state to </span>**`<span class="selected">Ended</span>`**<span class="selected">.</span>

### <span class="selected">Scenario 2: Strategic Deconfliction with a Constraint</span>

- **<span class="selected">Objective:</span>**<span class="selected"> Validate conflict detection and resolution against a static geographical constraint.</span>
- **<span class="selected">Execution:</span>**
    
    
    1. <span class="selected">The DSS will be pre-populated with a </span>`<span class="selected">Constraint</span>`<span class="selected"> (e.g., a no-fly zone).</span>
    2. <span class="selected">A USS will attempt to create an OIR that partially overlaps with the constraint.</span>
    3. <span class="selected">The USS must identify the conflict by querying the DSS.</span>
    4. <span class="selected">The USS must then modify the OIR's geometry to remove the conflict before it can be successfully created and activated.</span>
    5. <span class="selected">The Operator will fly the deconflicted mission.</span>

### <span class="selected">Scenario 3: Inter-USS Deconfliction &amp; Negotiation</span>

- **<span class="selected">Objective:</span>**<span class="selected"> Validate peer-to-peer coordination to resolve a conflict between two OIRs.</span>
- **<span class="selected">Execution:</span>**
    
    
    1. <span class="selected">USS-A creates and submits a valid OIR to the DSS.</span>
    2. <span class="selected">USS-B attempts to create an OIR whose 4D volume overlaps with USS-A's OIR.</span>
    3. <span class="selected">USS-B's initial attempt to create the OIR in the DSS should fail due to the conflict.</span>
    4. <span class="selected">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).</span>
    5. <span class="selected">One or both USSs will adjust their OIRs to resolve the conflict.</span>
    6. <span class="selected">Once resolved, both OIRs can be created and subsequently activated for flight.</span>

### <span class="selected">Scenario 4: Priority Operation (Pre-Flight)</span>

- **<span class="selected">Objective:</span>**<span class="selected"> Validate the system's response to a high-priority flight identified during the planning phase.</span>
- **<span class="selected">Execution:</span>**
    
    
    1. <span class="selected">Multiple "standard" priority OIRs are planned or active in the DSS.</span>
    2. <span class="selected">A designated USS (the "Emergency Services USS") will introduce a new OIR with </span>**`<span class="selected">priority</span>`**<span class="selected"> set higher than the others (e.g., for a simulated medical delivery or security overwatch). This OIR will overlap with existing standard operations.</span>
    3. <span class="selected">Other USSs must detect this high-priority OIR and are required to modify or cancel their own conflicting operations to clear the area.</span>
    4. <span class="selected">The high-priority flight is then activated and flown.</span>

### <span class="selected">Scenario 5: In-Flight Contingency - Dynamic Constraint</span>

- **<span class="selected">Objective:</span>**<span class="selected"> Validate a USS's ability to monitor for new conflicts during an active flight and instruct the operator to take immediate, appropriate action.</span>
- **<span class="selected">Execution:</span>**
    
    
    1. <span class="selected">USS-A has an OIR in the </span>`<span class="selected">Activated</span>`<span class="selected"> state, and its Operator is conducting the flight.</span>
    2. <span class="selected">An "Emergency Services USS" creates a new, high-priority </span>`<span class="selected">Constraint</span>`<span class="selected"> or </span>`<span class="selected">OIR</span>`<span class="selected"> that dynamically appears and conflicts with USS-A's active flight volume.</span>
    3. <span class="selected">USS-A must detect this new, superseding conflict in near real-time by monitoring the DSS or receiving a notification from a subscription.</span>
    4. <span class="selected">Upon detecting the unmitigable conflict, USS-A must immediately relay a command to its Drone Operator to cease the operation.</span>
    5. <span class="selected">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).</span>
    6. <span class="selected">USS-A updates its OIR state to </span>`<span class="selected">Ended</span>`<span class="selected"> to reflect the early termination of the flight.</span>

## <span class="selected">6. Operational Safety Considerations</span>

<span class="selected">To ensure the safety of all participants and the public, the following operational rules are mandatory for all live flights during the test.</span>

- **<span class="selected">Flight Rules:</span>**<span class="selected"> All live flights will be conducted under Visual Line of Sight (VLOS) conditions, in strict accordance with </span>**<span class="selected">ICA 100-40</span>**<span class="selected">. 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.</span>
- **<span class="selected">Immediate Operation Termination:</span>**<span class="selected"> 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.</span>
- **<span class="selected">Loss of C2 Link Procedure:</span>**<span class="selected"> 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.</span>
- **<span class="selected">Fly-Away Emergency Declaration:</span>**<span class="selected"> 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.</span>

## <span class="selected">7. Getting Started &amp; Prerequisites</span>

<span class="selected">All participants must complete the following steps to be ready for the field test:</span>

1. **<span class="selected">Register Participation:</span>**<span class="selected"> Formally register your organization and declare your intended role(s).</span>
2. **<span class="selected">Review Documentation:</span>**<span class="selected"> Thoroughly read the API documentation at </span>`<span class="selected">https://github.com/dp-icea/Protocols</span>`<span class="selected">.</span>
3. **<span class="selected">Implement Authentication:</span>**<span class="selected"> Implement the JWT-based authentication client and server logic. You will be provided with API keys and the public key.</span>
4. **<span class="selected">Implement OIR Activation:</span>**<span class="selected"> Ensure your system correctly handles the </span>`<span class="selected">Accepted</span>`<span class="selected">, </span>`<span class="selected">Activated</span>`<span class="selected">, and </span>`<span class="selected">Ended</span>`<span class="selected"> states of an OIR.</span>
5. **<span class="selected">Provide Endpoints:</span>**<span class="selected"> 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.</span>
6. **<span class="selected">Prepare for Flight:</span>**<span class="selected"> Operators must have their drones, ground control stations, and Remote ID broadcast modules ready for operation.</span>
7. <span class="selected">**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.</span>

<span class="selected">We look forward to your participation in this critical test to advance the future of aviation in Brazil.</span>

# Ensaio Operacional 3 - Dezembro 2025

Documentos relacionados ao ensaio operacional que será realizado em Dezembro de 2025 com testes focados no operacional, fora os requisitos tecnicos ja testados

# Escopo

## Objetivo

Executar ensaio operacional no IEAv (15 a 17 de dezembro de 2025), com foco em validação de procedimentos de contingência, integração de restrições dinâmicas e avaliação da reação dos provedores diante de eventos simulados.

## Tópicos Principais

### Testes Operacionais

- **Check-in / Check-out**
    
    
    - Não permitido por telefone ou comunicação informal.
    - Definir processo padronizado.
- **Alertas e Geografia de Voo**
    
    
    - Notificação automática ao sair da área de voo (avaliar uso de Remote ID).
    - Identificação de drones com Remote ID que entram na área.
    - Resposta operacional do provedor diante dessas situações.
- **Restrições Dinâmicas**
    
    
    - Criação de restrição parcial com OIR ativa → ações possíveis:
        
        
        - Sair da área, cancelar voo ou reagir em tempo adequado.
    - Simulação de pouso de helicóptero → restrição automática temporária.
    - Avaliar tempo de reação dos provedores (cronometração) para agir após emergencia.
- **Condições de Operação**
    
    
    - Proibir pouso no mesmo ponto de decolagem em caso de restrição.
    - Testar Geo Fence → verificar se provedores cumprem restrições e se todas as OIRs estão dentro da Zona UTM.
    - Avaliar resposta a voos fora da Zona UTM.
    - Se drone sair da OIR → verificar se provedor cria nova OIR ou declara contingência.

### Features Extras a Testar

- Definir lista de **procedimentos padrão ao encerrar operação** para diferentes tipos de restrições (não assumir apenas “Return to Home”).
- Testar **volumes não nominais**:
    
    
    - Como provedores lidam com sua criação e gerenciamento.
- <span style="background-color: rgb(248, 202, 198);">\[NÃO PRIORIZADO\] </span>- *Inclusão de **detalhes nas restrições** (grau de severidade, ações obrigatórias, manobras seguras permitidas).*

### Requisitos BRAC

- Não é permitido ativar voo em volume não nominal.
- Caso o drone saia da OIR, deve-se calcular área possível e criar automaticamente volume não nominal.

### Observações Gerais

- Necessidade de ensaios mais orgânicos (“vai voando e eu vou avaliando os requisitos”).
- Foco na observação em tempo real da reação dos provedores.

# [WIP] Briefing: BR-UTM Field Test 3

<div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk-" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;"></div># Briefing: BR-UTM Field Test 3

**Document Version**: 1.0

**Date**: October 6, 2025

<div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk--1" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;">---

</div>## 1. Introduction &amp; Vision

Following the successful validation of the end-to-end operational lifecycle in Field Test 2, this Third Field Test will shift focus to **real-time contingency management and provider responsiveness**. The vision is to move beyond pre-planned scenarios and evaluate how USS platforms and operators react to dynamic, unexpected events in a more organic operational environment.

This test, scheduled for **December 15-17, 2025, at IEAv**, will concentrate on the validation of advanced contingency procedures, the integration of dynamic constraints on active flights, and the automated handling of in-flight deviations.

### 1.1. New Features for Validation

This test will validate all previously tested features, with a specific focus on the following new capabilities:

<div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk-dynamic-constraint-i" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;">- **Dynamic Constraint Integration:** The ability for the system and participants to manage airspace restrictions that are created or modified *after* a flight has been activated.
- **Geo-Fencing and Automated Alerts:** Real-time detection and notification of deviations from the approved 4D operational volume (OIR).
- **Non-Nominal Volume Management:** The automated creation and management of non-nominal volumes in response to an in-flight deviation, as per BRAC requirements.
- **Provider Reaction Time:** Measurement and evaluation of the time taken for a USS to detect a conflict or deviation, process it, and deliver actionable instructions to the operator.

---

</div>## 2. Core Objectives

The primary goals of this field test are to:

<div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk-validate-real-time-c" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;">1. **Validate Real-Time Contingency Response:** Demonstrate that USSs can detect dynamic constraints affecting an active flight and guide the operator through appropriate, timely mitigation measures.
2. **Test Geo-Fence Compliance and Deviation Handling:** Verify that USSs can automatically detect when a drone exits its authorized OIR and trigger the appropriate operational response (e.g., alerts, a contingency declaration, or the creation of a non-nominal volume).
3. **Evaluate Non-Nominal Volume Procedures:** Ensure that in case of a deviation, USSs correctly calculate and create a non-nominal volume, and that flights cannot be activated within one.
4. **Measure USS Performance:** Quantitatively measure the reaction time of USS providers in responding to simulated emergencies and dynamic changes in the airspace.
5. **Standardize Contingency Maneuvers:** Test the implementation of specific, pre-defined contingency procedures beyond the default "Return to Home," based on information provided in dynamic constraints.

</div><div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk--2" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;">---

</div>## 3. Technical Architecture &amp; Protocols

The core architecture remains the DECEA-provided **Discovery and Synchronization Service (DSS)**, based on the InterUSS Platform. All interactions will continue to adhere to the API contracts and authentication protocols established in Field Test 2.

<div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk-governing-standards%3A" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;">- **Governing Standards:** All operations will continue to be governed by **ASTM F3548-21** (UTM Interoperability) and **ASTM F3411-22a** (Remote ID).

</div><div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk--3" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important;">---

</div>## 4. Test Scenarios

The field test will focus on dynamic scenarios designed to assess real-time decision-making and system responsiveness.

### Scenario 1: Dynamic Constraint on an Active Flight

<div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk-objective%3A-to-valida" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important; text-align: justify;">- **Objective:** To validate the USS's ability to manage a new constraint that appears during flight and measure its reaction time.
- **Execution:**
    
    
    1. A USS activates an OIR, and the corresponding drone begins its mission.
    2. A test coordinator creates a new, high-priority `Constraint` that partially overlaps the active OIR (e.g., simulating a helicopter landing zone). The constraint will contain detailed instructions.
    3. The USS must detect the conflict in near real-time. The time from constraint publication to USS action will be measured.
    4. The USS must instruct its operator to take appropriate action based on its safety procedures (e.g., immediately exit the restricted area, hold position, or land at an alternate location).

</div>### Scenario 2: OIR Deviation and Non-Nominal Volume Creation

<div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk-objective%3A-to-valida-1" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important; text-align: justify;">- **Objective:** To validate the automated response to a drone breaching its approved flight geometry (Geo-Fence).
- **Execution:**
    
    
    1. A drone is operating under a valid, `Activated` OIR.
    2. The operator intentionally flies the drone outside the lateral and/or vertical boundaries of the OIR.
    3. The managing USS must automatically detect the deviation via Remote ID data or other tracking means.
    4. The USS must issue an immediate alert to the operator.
    5. Per BRAC requirements, the USS must then calculate the potential flight area and automatically create a `non-nominal volume` in the DSS to represent the contingency.

</div>### Scenario 3: Response to Flight Outside UTM Zone

<div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk-objective%3A-to-evalua" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important; text-align: justify;">- **Objective:** To evaluate the system's response to an operation that deviates outside the designated UTM test zone.
- **Execution:**
    
    
    1. An operator flies a drone near the boundary of the defined UTM Zone.
    2. The drone then proceeds to fly *outside* this zone.
    3. The managing USS and the overall system must detect this breach and initiate the appropriate alert and contingency procedures.

</div>### Scenario 4: Standardized Check-in / Check-out

<div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk-objective%3A-to-valida-2" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important; text-align: justify;">- **Objective:** To validate a formal, standardized electronic procedure for flight check-in and check-out.
- **Execution:**
    
    
    1. Before activating an OIR, a USS must perform a formal "check-in" using a defined digital process. Informal communications (phone, etc.) are not permitted.
    2. Upon normal completion or early termination of the flight, the USS must perform a formal "check-out" to close the operation.

---

</div>## 5. Operational Safety Considerations

All safety protocols from the previous test remain in effect.

<div _ngcontent-ng-c3766125863="" class="markdown markdown-main-panel enable-updated-hr-color" dir="ltr" id="bkmrk-flight-rules%3A-all-fl" style="--animation-duration: 400ms; --fade-animation-function: linear; font-family: Google Sans Text, sans-serif !important; line-height: 1.15 !important; margin-top: 0px !important; text-align: justify;">- **Flight Rules:** All flights will be conducted under **Visual Line of Sight (VLOS)** conditions, per **ICA 100-40**.
- **Immediate Termination:** Operators must be prepared to terminate flight operations immediately upon command from their USS.
- **Loss of C2 Link Procedure:** All UAS must be configured with a "Return to Home" (RTH) procedure upon loss of C2 link.
- **Emergency Declaration:** Operators must immediately declare any fly-away or loss-of-control event to DECEA personnel and their USS.

</div>

# Modelo de Procedimento Operacional Padrão (SOP)

### 1. Autoridade e Definições

Este SOP estabelece os procedimentos para todas as operações BVLOS conduzidas com integração a um Provedor de Serviços UTM (USS).

* **1.1. Operador (Piloto Remoto):** O operador é a autoridade final pela condução segura do voo. Esta autoridade é exercida em coordenação direta com os serviços e informações providos pelo USS.
* **1.2. Provedor de Serviços UTM (USS):** Entidade responsável pela prestação de serviços de gerenciamento de tráfego, incluindo planejamento, autorização, monitoramento de conformidade e fornecimento de dados do espaço aéreo.
* **1.3. GCS (Estação de Controle de Solo):** Interface primária do operador para o controle do Drone e para a comunicação de dados com o USS.

### 2. Operação e Automação

* **2.1. Nível de Automação:** A operação BVLOS será conduzida primariamente através de planos de voo automatizados (waypoints), com o operador monitorando a telemetria e o ambiente operacional.
* **2.2. Interface com USS:** A GCS deve manter comunicação constante com o USS para transmissão de telemetria (posição, altitude, status) e recebimento de informações de tráfego e do espaço aéreo.
* **2.3. "Cabine Estéril" (Sterile Cockpit):** Durante todas as fases críticas do voo (lançamento, recuperação e qualquer manobra tática), o operador deve se abster de atividades não essenciais.

### 3. Planejamento de Voo e Espaço Aéreo

* **3.1. Análise do Espaço Aéreo:**
    * Antes de submeter um plano de voo, o operador deve consultar a interface do USS para identificar todas as restrições de espaço aéreo estáticas (ex: áreas proibidas) e dinâmicas (ex: NOTAMs, outras operações autorizadas).
* **3.2. Submissão do Plano de Voo (4D):**
    * O operador deve submeter um volume 4D (latitude, longitude, altitude e janela de tempo) ao USS para análise.
* **3.3. Autorização do USS (Desconflito Estratégico):**
    * A operação **só pode ser iniciada** após o USS validar o plano de voo, realizar o desconflito estratégico contra todas as outras operações conhecidas e emitir uma autorização digital.
* **3.4. Briefing de Operação:**
    * O briefing pré-voo deve incluir:
        * Condições meteorológicas.
        * Status do Drone e baterias.
        * Revisão da autorização 4D emitida pelo USS.
        * Procedimentos de contingência (Seção 6).

### 4. Procedimentos Pré-Operação (Checklists)

* **4.1. Inspeção do Drone (RPA):**
    * Verificar estrutura, motores, hélices e links de C2 (Comando e Controle).
* **4.2. Inspeção do Controle (GCS):**
    * Verificar carga da GCS, software e links de C2.
* **4.3. Conexão com USS:**
    * Estabelecer conexão de dados entre a GCS e o USS.
    * Verificar na interface do USS se o status do voo planejado está "Aprovado" e "Pronto para Ativação".
    * **A decolagem é proibida** sem a confirmação de conexão e autorização do USS.

### 5. Execução da Operação (Controle e Monitoramento)

* **5.1. Ativação do Voo:**
    * No momento do lançamento, o operador deve "Ativar" o voo na interface do USS. O USS inicia o monitoramento de conformidade.
* **5.2. Monitoramento pelo Operador:**
    * O operador deve monitorar continuamente:
        * Telemetria do Drone (posição, altitude, bateria).
        * O "feed" de dados do USS, buscando alertas de tráfego ou do espaço aéreo.
* **5.3. Monitoramento de Conformidade (pelo USS):**
    * O sistema do USS monitora se a telemetria do Drone permanece dentro do volume 4D autorizado.
* **5.4. Alertas de Tráfego e Desconflito Tático:**
    * Ao receber um alerta de tráfego (outra aeronave) do USS, o operador deve avaliar a ameaça e estar preparado para executar manobras de contingência.
* **5.5. Pouso e Finalização:**
    * Após o pouso, o operador deve "Finalizar" o voo na interface do USS.
    * Isso libera o volume do espaço aéreo utilizado, permitindo que o USS o aloque para outras operações.

### 6. Procedimentos de Contingência e Emergência

* **6.1. Perda de Link C2 (Drone-Controle):**
    * O Drone executará o procedimento pré-programado (ex: RTH - Retorno à Base).
    * A GCS deve, automaticamente ou manualmente, notificar o USS sobre o status "Link Perdido" para que o USS possa alertar outros tráfegos na área.
* **6.2. Perda de Link de Dados (GCS-USS):**
    * O operador deve notificar verbalmente o USS (se um canal de rádio for definido) ou tentar restabelecer a conexão.
    * Se a conexão não for restabelecida, o operador deve encerrar o voo BVLOS na área segura mais próxima.
* **6.3. Desvio de Rota (Não-Conformidade):**
    * **Emergência:** Em caso de desvio imediato (ex: desviar de obstáculo ou meteorologia), o operador deve manobrar e, assim que possível, notificar o USS. O sistema USS detectará a não-conformidade e emitirá alertas para outros tráfegos.
    * **Não-Emergência:** Se o operador *precisar* alterar a rota, ele deve submeter um pedido de modificação de plano de voo ao USS e aguardar a autorização 4D atualizada.
* **6.4. Alerta de Bateria Crítica:**
    * O operador deve iniciar um pouso imediato no local de contingência mais próximo e notificar o USS sobre o pouso fora da área planejada.
* **6.5. Propagação da Contingência**
  * Em casos de detecção automática de contingência pelo USS, o Operador será notificado pela GCS quanto à melhor alternativa para encerrar ou corrigir a operação.
  * Em casos de declaração de contingência pelo Operador, o USS calcula a área necessária de volume não nominal automaticamente.
  * Para todos os casos, o USS é responsável por propagar a informação da contingência no ecossistema UTM.

# Exemplo Procedimento Operacional Padrão Ensaio III

### 1. Autoridade e Definições

Este SOP estabelece os procedimentos do Provedor de Serviços UTM (USS) para o **BR-UTM Field Test 3**, a ser conduzido no IEAv entre 15 e 17 de dezembro de 2025.

* **1.1. Operador (Piloto Remoto):** Responsável final pela condução segura do voo, operando em conformidade com as instruções e alertas deste USS e da ICA 100-40 (VLOS).
* **1.2. Provedor de Serviços UTM (USS):** Este USS, responsável pela prestação de serviços de gerenciamento, autorização, monitoramento de conformidade e resposta a contingências.
* **1.3. GCS (Estação de Controle de Solo):** Interface do operador para controle da RPA e para comunicação (envio de telemetria e recebimento de instruções) com este USS.
* **1.4. DSS (Discovery and Synchronization Service):** Plataforma central (InterUSS) para compartilhamento de dados de intenção operacional e restrições.
* **1.5. OIR (Operational Intent Reference):** O volume 4D (espaço e tempo) autorizado pelo USS para a operação.
* **1.6. Volume Não-Nominal:** Volume de contingência criado e publicado no DSS pelo USS em resposta a um desvio de voo.

### 2. Operação e Automação

* **2.1. Foco do Teste:** Este SOP foca na validação de gerenciamento de contingência em tempo real. O objetivo primário é **automação da interação com UTM, alerta imediato e resposta procedural** a desvios e mudanças no espaço aéreo.
* **2.2. Interface com USS:** A GCS manterá comunicação constante, enviando telemetria (via Remote ID) e recebendo alertas e instruções dinâmicas deste USS.
* **2.3. Padrões Mandatórios:** Todas as interações do USS com o DSS e com o operador seguirão os padrões **ASTM F3548-21** (Interoperabilidade) e **ASTM F3411-22a** (Remote ID).

### 3. Planejamento de Voo e Espaço Aéreo

* **3.1. Análise do Espaço Aéreo:**
    * Antes da submissão do OIR, o USS analisará o DSS para identificar todas as restrições estáticas e dinâmicas, incluindo `Volumes Não-Nominais` ativos de outras operações.
* **3.2. Submissão do OIR (4D):**
    * O operador submeterá um OIR 4D ao USS para análise de desconflito estratégico.
* **3.3. Autorização do USS:**
    * A operação só será autorizada (status "Aprovado") se o OIR estiver livre de conflitos com outras operações e *não* interceptar nenhum `Volume Não-Nominal` ativo.

### 4. Procedimentos Pré-Operação (Checklists)

* **4.1. Inspeção do Drone (RPA):**
    * Conforme SOP do operador. Verificação de links C2 e RTH por perda de C2.
* **4.2. Inspeção do Controle (GCS):**
    * Conforme SOP do operador. Verificação de software e link de dados com o USS.
* **4.3. Conexão e Check-in com USS:**
    * O operador deve estabelecer conexão de dados com o USS.
    * O operador deve executar o procedimento de **"Check-in Digital"** formal na interface do USS antes da ativação.
    * *Nota: Comunicações informais (ex: telefone) não substituem o check-in digital.*

### 5. Execução da Operação (Controle e Monitoramento)

* **5.1. Ativação do OIR:**
    * Após o "Check-in Digital", o operador ativará o OIR na GCS no momento do lançamento. O USS mudará o status do OIR para "Ativo" no DSS.
* **5.2. Monitoramento pelo Operador:**
    * O operador monitorará a telemetria e a interface do USS, pronto para executar instruções ou terminar o voo imediatamente.
* **5.3. Monitoramento de Conformidade (USS):**
    * O USS monitorará continuamente a telemetria (Remote ID) e a comparará com os limites laterais e verticais do OIR `Ativo` (Geo-Fence).
* **5.4. Gerenciamento de Restrições Dinâmicas:**
    * O USS monitora o DSS em tempo real para novas `Restrições` (Constraints).
    * Ao detectar uma nova `Restrição` que conflite com um OIR `Ativo`:
        1.  O USS medirá o tempo de detecção.
        2.  Enviará um alerta imediato à GCS do operador.
        3.  Fornecerá instruções de mitigação claras, baseadas nas informações da `Restrição` (ex: "Sair da Área Imediatamente", "Manter Posição", "Pousar em Alternativa").
* **5.5. Pouso e Check-out:**
    * Após o pouso (normal ou por contingência), o operador deve executar o procedimento de **"Check-out Digital"** formal na interface do USS.
    * O USS finalizará a operação e removerá o OIR do DSS.

### 6. Procedimentos de Contingência e Emergência

* **6.1. Perda de Link C2 (Drone-Controle):**
    * O Drone executará o RTH automático (conforme Safety Considerations).
    * O operador deve declarar imediatamente à equipe do DECEA e ao USS.
* **6.2. Detecção de Desvio de OIR (Geo-Fence):**
    * No momento em que o USS detectar (via Remote ID) que a RPA saiu dos limites do OIR `Ativo` ou da Zona UTM designada:
        1.  O USS emitirá um alerta imediato de "Desvio de OIR" ao operador.
        2.  O USS declarará internamente o voo como "Não-Nominal".
* **6.3. Criação de Volume Não-Nominal:**
    * Imediatamente após a detecção de desvio (6.2), ou contigências simuladas (6.6), o sistema USS irá:
        1.  Calcular automaticamente o `Volume Não-Nominal` (potencial área de voo) conforme os requisitos BRAC.
        2.  Publicar este `Volume Não-Nominal` no DSS para alertar todos os outros participantes do espaço aéreo.
* **6.4. Outras Emergências (Fly-away, Bateria Crítica):**
    * O operador deve declarar imediatamente qualquer "fly-away" ou perda de controle ao pessoal do DECEA e ao USS.
    * O USS tratará esta declaração como um desvio (6.2) e criará um `Volume Não-Nominal` (6.3).
* **6.5. Manobras de Contingência Padronizadas:**
    * Este USS está configurado para instruir manobras de contingência específicas (além do RTH padrão) com base no tipo de alerta (ex: "Pousar Imediatamente" em caso de desvio crítico ou "Manter Posição" em caso de conflito com tráfego).
* **6.6. Contigências simuladas**
  * Para os casos de contingências simuladas previstas nos cenários de teste do ensaio, o operador receberá do USS as informações necessárias através do GCS.

# Whitepaper

# <span style="font-size: 23pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">III Ensaio de Campo BR-UTM</span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Data:</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> 15 a 17 de dezembro de 2025</span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">**Realização**: Instituto de Controle do Espaço Aéreo (ICEA)</span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Local:</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> Instituto de Estudos Avançados (IEAv), São José dos Campos, SP.</span>

## <span style="font-size: 17pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">1. Introdução</span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">O terceiro ensaio de campo do projeto </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">BR-UTM</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> consolidou o avanço da maturidade operacional do Gerenciamento de Tráfego de Aeronaves Não Tripuladas no Brasil. Diferente de ensaios laboratoriais, este evento focou na </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">realidade do operador</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">, permitindo que as empresas participantes (Aeroscan, Atech e Speedbird) propusessem seus próprios perfis de voo para testar a resiliência de seus sistemas em cenários de contingência, detecção de desvios e conformidade com volumes operacionais.</span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Com o suporte tecnológico da </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Arsitec</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> na detecção de drones, o ensaio validou como a troca de dados entre o provedor USS (Unmanned Service Supplier) e o ecossistema UTM impacta diretamente a segurança da operação em tempo real.</span>

## <span style="font-size: 17pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">2. Objetivos Operacionais</span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Os ensaios foram estruturados para validar cinco pilares fundamentais para a segurança do voo:</span>

1. <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Resposta a Contingências em Tempo Real:</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> Capacidade do USS de identificar restrições dinâmicas e guiar o piloto na mitigação do risco.</span>
2. <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Conformidade com a OIR (Operation Intent Region):</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> Verificação automática de desvios geográficos e transição de estados de voo (Ativo → Não-Conforme → Contingência).</span>
3. <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Gestão de Volumes Não Nominais:</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> Garantia de que, em caso de falha, o sistema reserve um volume de proteção (buffer) e impeça novos voos nessa área.</span>
4. <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Desempenho de Reação:</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> Medição do tempo entre o evento adverso e a notificação ao operador.</span>
5. <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Automação de Check-in / Check-out:</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> Ativação e desativação de OIR de maneira automática e transparente para o operador</span>

## <span style="font-size: 17pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">3. Infraestrutura e Ecossistema</span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">A arquitetura do ecossistema UTM (composta pelo DSS, Servidor de Autenticação e Provedores de Restrição) foi hospedada de forma híbrida entre o </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">ICEA</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> e o </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">NCTI</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">, garantindo a integridade dos dados e a visualização centralizada por parte do órgão regulador.</span>

## <span style="font-size: 17pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">4. Detalhamento dos Ensaios por Provedor</span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Nesta edição, as empresas tiveram autonomia para propor voos que refletissem seus desafios operacionais diários, totalizando três missões por provedor.</span>

#### <span style="font-size: 13pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Atech</span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">A arquitetura da Atech utilizou a transmissão de </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">RemoteID Broadcast</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> da aeronave para uma antena local, que serviu de ponte para o USS. O operador recebeu os alertas em um tablet posicionado paralelamente ao rádio controle.</span>

- <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Voo 01: Gestão de Não-Conformidade e Contingência Temporal</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> O drone foi comandado para fora dos limites da OIR. O sistema detectou o desvio e alterou o status para </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Não-Conforme</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">, disparando um prompt no tablet orientando o retorno imediato. O operador retornou à área e o sistema reativou o status "Ativo". Em seguida, o drone saiu novamente e permaneceu fora por mais de 60 segundos; o sistema então escalou a operação para </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Contingência</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">, emitindo uma ordem de encerramento imediato.</span>
- <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Voo 02: Violação de Perímetro UTM (Saída de Área)</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> Neste cenário, o drone cruzou o limite externo da Zona UTM. Diferente do voo anterior, a transição para o estado de </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Contingência</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> foi instantânea, refletindo a gravidade de operar em espaço aéreo não monitorado pelo sistema.</span>
- <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Voo 03: Resposta a Restrição Dinâmica em Voo</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> Durante a navegação nominal, o ecossistema injetou uma restrição de espaço aéreo (volume de exclusão). O operador recebeu a notificação no tablet e executou o pouso de emergência conforme as instruções do USS.</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">  
    </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Nota Operacional:</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> Durante as não-conformidades, a Atech projetou um buffer não-nominal restrito à aeronave. Na contingência, o volume projetado no sistema expandiu para cobrir toda a autonomia restante do drone.</span>

#### <span style="font-size: 13pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Aeroscan </span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">A Aeroscan utilizou uma abordagem integrada, onde o software de gerenciamento UTM roda diretamente no controle remoto da aeronave, consolidando a consciência situacional em uma única tela.</span>

- <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Voo 01: Bloqueio de Ativação por Restrição Prévia</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> O operador solicitou uma OIR para um horário futuro. Antes da decolagem, criou-se uma restrição sobrepondo a área. Ao tentar iniciar a missão, o sistema bloqueou a ativação no solo, exibindo claramente o motivo da interdição.</span>
- <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Voo 02: Notificação de Restrição Dinâmica e Finalização</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> Com o drone já em voo, uma nova restrição foi ativada. O sistema notificou o operador diretamente na interface de comando, que procedeu com a finalização segura da missão.</span>
- <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Voo 03: Desvio de OIR e Criação de Volume Não-Conforme</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> O operador forçou a saída lateral da área autorizada. O aplicativo sinalizou visualmente a entrada em estado não-conforme e o ecossistema UTM passou a exibir o volume de proteção atualizado para os demais atores do espaço aéreo.</span>

#### <span style="font-size: 13pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Speedbird </span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Como fabricante e operadora, a Speedbird integrou sua </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">GCS (Ground Control Station)</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> diretamente ao UTM, permitindo uma comunicação profunda entre a telemetria da aeronave e o serviço de rede.</span>

- <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Voo 01: Desconflito Estratégico em Solo</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> O USS da Speedbird realizou uma consulta ao DSS onde já constava uma OIR ativa de outro provedor. O sistema impediu que o operador iniciasse a operação, garantindo a separação básica entre aeronaves de diferentes empresas.</span>
- <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Voo 02: Decisão de Contingência em Restrição Dinâmica</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> Ao receber um alerta de restrição dinâmica durante o voo, o operador utilizou as informações da estação de pilotagem para selecionar a alternativa de pouso mais segura e rápida, encerrando a operação com sucesso.</span>
- <span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Voo 03: Teste de Cerca Virtual (Controle Manual)</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> O operador assumiu o comando manual e tentou acelerar o drone contra o limite da OIR. O sistema de navegação da aeronave, integrado aos dados de volume do UTM, considerou a inércia e impediu que o drone saísse da área, atuando como uma trava física automática de segurança.</span>

## <span style="font-size: 17pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">5. Conclusão Operacional</span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Um grande ganho deste ensaio foi a validação da Lógica de Volumes Não-Nominais</span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">:</span>

<div align="left" dir="ltr" id="bkmrk-cen%C3%A1rio-objetivo-res" style="margin-left: 0pt;"><table style="border: none; border-collapse: collapse;"><colgroup><col width="144"></col><col width="170"></col><col width="288"></col></colgroup><tbody><tr style="height: 26.5pt;"><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Cenário</span>

</td><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Objetivo</span>

</td><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Resultado Observado</span>

</td></tr><tr style="height: 54.25pt;"><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Desvio de OIR</span>

</td><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Validar alertas de conformidade</span>

</td><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Transição precisa de "Ativa" para "Não-Conforme" com prompts de correção.</span>

</td></tr><tr style="height: 54.25pt;"><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Restrição Dinâmica</span>

</td><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Testar reação a fechamento de área</span>

</td><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Bloqueio imediato de ativação e comando de pouso em áreas seguras.</span>

</td></tr><tr style="height: 54.25pt;"><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Volume Não Nominal</span>

</td><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Proteção de terceiros</span>

</td><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">USS notificou o ecossistema criando áreas de exclusão baseadas na autonomia da bateria.</span>

</td></tr><tr style="height: 54.25pt;"><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Intervenção de Inércia</span>

</td><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Segurança física</span>

</td><td style="vertical-align: top; padding: 5pt 5pt 5pt 5pt; overflow: hidden; overflow-wrap: break-word; border: solid #000000 0.75pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">O drone respeitou os limites geográficos mesmo sob comando manual agressivo.</span>

</td></tr></tbody></table>

</div><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">O III Ensaio de Campo do BR-UTM provou que a tecnologia de suporte ao operador está pronta para lidar com imprevistos de forma automatizada. A principal lição para os operadores é que o UTM não atua apenas como um "fiscal", mas como uma ferramenta de </span><span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">consciência situacional.</span>

<span style="font-size: 11pt; font-family: Arial, sans-serif; background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">A capacidade dos USSs de gerarem volumes não nominais e impedirem decolagens em áreas restritas garante que o erro humano ou falhas técnicas sejam contidos antes de afetarem a segurança geral do espaço aéreo. O próximo passo envolve a maturação dos tempos de resposta para operações em larga escala e a integração total com a detecção de drones não colaborativos via Arsitec.</span>