# Documentação Técnica
# I WorkShop BR-UTM (Jul/24)
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
GeoJSON
```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"
}
}
]
}
```
Vizualização
[](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/image.png)
GeoJSON
{
"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"
}
}
\]
}
Visualização
[](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/lROimage.png)
GeoJSON
{
"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"
}
}
\]
}
Visualização
[](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/WOpimage.png)
OIR isolada
OIR próxima a Constraint
OIR com conflito
**Maior ou igual prioridade**
**Menor prioridade**
Endpoints de coordenação
[](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/7QUimage.png)
Ativação de OIR (Momentos antes do voo)
Atualizar a OIR no DSS e notificar os Subscribers
[](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-06/mIlimage.png)
Autenticar-se
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*
| intended\_audience | USS de destino da mensagem (Domínio do provedor) Ex. "utm.decea.mil.br" |
| scope | escopo da requisição. Ex.: utm.strategic\_coordination.
O scope esperado de cada endpoint está definido no OpenAPI
|
| apikey | chave recebida do ICEA. Pode-se optar em enviar esse campo no Header da requisição
|
Validar autenticação de outro USS
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:
| aud
| Domínio do seu provedor. | "utm.provider1.com"
|
| exp
| Timestamp epoch do horário de expiração do token. O token não deve ser aceito a partir desse horário
| 1719777868 |
| iss
| Nome do provedor emissor do token
| ICEA
|
| scope
| Scope autorizado pelo token. Cada endpoint deve aceitar apenas determinados scopes, conforme definido no OpenAPI
| utm.strategic\_coordination
|
| sub
| Nome do provedor origem da requisição. Não deve ser validado | "USS1" |
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.
Chave Publica Eco-UTM
\-----BEGIN PUBLIC KEY-----
MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgHkNtpy3GB0YTCl2VCCd22i0rJwI
GBSazD4QRKvH6rch0IP4igb+02r7t0X//tuj0VbwtJz3cEICP8OGSqrdTSCGj5Y0
3Oa2gPkx/0c0V8D0eSXS/CUC0qrYHnAGLqko7eW87HW0rh7nnl2bB4Lu+R8fOmQt
5frCJ5eTkzwK5YczAgMBAAE=
\-----END PUBLIC KEY-----
Código exemplo
```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))
}
```
Eco-UTM Autenticator Public Key
```
-----BEGIN PUBLIC KEY-----
MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgHkNtpy3GB0YTCl2VCCd22i0rJwI
GBSazD4QRKvH6rch0IP4igb+02r7t0X//tuj0VbwtJz3cEICP8OGSqrdTSCGj5Y0
3Oa2gPkx/0c0V8D0eSXS/CUC0qrYHnAGLqko7eW87HW0rh7nnl2bB4Lu+R8fOmQt
5frCJ5eTkzwK5YczAgMBAAE=
-----END PUBLIC KEY-----
```
Path Param
| intented\_audience | user da entetidade de destino da mensagem
|
| scope | escopo da requisição |
| apikey | chave recebida do ICEA |
Bearer
Código exemplo python
```ht
response = requests.get(
f"{AUTH_URL}/token",
params={
"grant_type": "client_credentials",
"intended_audience": "localhost",
"scope": "utm.constraint_management",
"apikey": "brutm",
},
)
```
Response
| 200
| Success
|
| 403
| Non-Authoritative Information |
Response Body
| access\_token | token de acesso ao ECO-UTM |
Query Parameters
| view | Á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 | 29.978,31.132,29.980,31.135 |
| recent\_positions\_duration | 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
| 60 |
Response
```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
}
```
| timestamp | Horário em que o Service Provider recebeu a requisição |
| flights.id | 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.
|
| flights.aircraft\_type | Tipo de aeronave no padrão ICAO. Para drones, o tipo = Helicopter. Para drones de asa fixa que conseguem decolar verticalmente, o tipo = "HybridLift" |
| flights.current\_state | Dados do tracking de fato da aeronave, no momento atual. |
| flights.operating\_area | A área que a aeronave se encontra. Deve ser usado apenas quando o campo "flights.current\_state" não está preenchido. |
| flights.recent\_positions | Lista de posições recentes da aeronave. Deve ser informado apenas quando as "recent\_positions" foram requisitadas. |
| no\_isas\_present | 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. |
| **GET** | /uss/flights/{id}/details |
Endpoint onde os Display Providers obterão dados específicos de um determinado voo
Path Parameters
| id | ID único do provedor para identificar o voo | b41f2785-1182-4c2e-82d5-f72f754b3fe2.0dfe0e82-fd7a-44d9-af17-7fdd42751b45 |
Response
```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"
}
}
```
| uas\_id | Código SISANT da aeronave |
| operator\_id | Código SARPAS do operador |
| operator\_location | Localização do operador. Opcional |
| operation\_description | Descrição da Operação conforme solicitação no SARPAS |
| **GET** | /uss/identification\_service\_areas/{id} |
Endpoint para obter o volume 4D de uma ISA controlada pelo Service Provider
Path Parameters
| id | UUID da área possuída pelo provedor | UUID |
Response
```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"
}
}
}
```
| volume | Volume 4D da área específica |
| **PUT** | /dss/identification\_service\_area/{id} |
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
Path Param
| id | UUID da ISA. Deve ser o mesmo UUID devolvido pelo ECO-UTM após a criação da solicitação de voo.
|
Body
```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
| volume | Polígono **OU** círculo da área, idêntico ao definido no SARPAS |
| altitude\_lower, altitude\_upper | Altitude geodésica (WSG84, W84) máxima e mínima em metros.
|
| time\_start, time\_end | 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"
|
| uss\_base\_url | 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.
|
Response
```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
| subcribers | 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 |
| version | Versão da ISA, gerado pelo DSS, para garantia de integridade. É necessário utilizar esse campo para atualizar ou deletar uma ISA. |
| **POST** | /uss/identification\_service\_areas/{id} |
Path Parameters
Request Body
| **PUT** | /dss/subscriptions/{id} |
Path Parameters
| id | UUID da Subscription, criado pelo Display Provider |
Request Body
```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
| volume | Polígono **OU** círculo da área, idêntico ao definido no SARPAS |
| altitude\_lower, altitude\_upper | Altitude geodésica (WSG84, W84) máxima e mínima em metros.
|
| time\_start, time\_end | 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"
|
| uss\_base\_url | 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.
|
Response Body
```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"
}
}
```
| service\_areas | 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 |
| version | Versão da Subscription, gerado pelo DSS, para garantia de integridade. É necessário utilizar esse campo para atualizar ou deletar uma Subscription. |
app.py
```python
from flask import Flask, request
from dss import Dss
import json
app = Flask(__name__)
database = {}
dss = Dss()
@app.route('/uss/v1/operational_intents/', 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)
```
dss.py
```python
from conflict_manager import ConflictManager
from scd import Scd
class Dss:
def __init__(self) -> None:
self.conflict_manager = ConflictManager()
self.scd = Scd()
```
scd.py
```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']
```
conflict\_manager.py
```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']
```
Query Parameters
| view | Á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 | 29.978,31.132,29.980,31.135 |
| recent\_positions\_duration | 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
| 60 |
Response
```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
}
```
| timestamp | Horário em que o Service Provider recebeu a requisição |
| flights.id | 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.
|
| flights.aircraft\_type | Tipo de aeronave no padrão ICAO. Para drones, o tipo = Helicopter. Para drones de asa fixa que conseguem decolar verticalmente, o tipo = "HybridLift" |
| flights.current\_state | Dados do tracking de fato da aeronave, no momento atual. |
| flights.operating\_area | A área que a aeronave se encontra. Deve ser usado apenas quando o campo "flights.current\_state" não está preenchido. |
| flights.recent\_positions | Lista de posições recentes da aeronave. Deve ser informado apenas quando as "recent\_positions" foram requisitadas. |
| no\_isas\_present | 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. |
| **GET** | /uss/flights/{id}/details |
Endpoint onde os Display Providers obterão dados específicos de um determinado voo
Path Parameters
| id | ID único do provedor para identificar o voo | b41f2785-1182-4c2e-82d5-f72f754b3fe2.0dfe0e82-fd7a-44d9-af17-7fdd42751b45 |
Response
```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"
}
}
```
| uas\_id | Código SISANT da aeronave |
| operator\_id | Código SARPAS do operador |
| operator\_location | Localização do operador. Opcional |
| operation\_description | Descrição da Operação conforme solicitação no SARPAS |
| **GET** | /uss/identification\_service\_areas/{id} |
Endpoint para obter o volume 4D de uma ISA controlada pelo Service Provider
Path Parameters
| id | UUID da área possuída pelo provedor | UUID |
Response
```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"
}
}
}
```
| volume | Volume 4D da área específica |
| **PUT** | /dss/identification\_service\_area/{id} |
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
Path Param
| id | UUID da ISA. Deve ser o mesmo UUID devolvido pelo ECO-UTM após a criação da solicitação de voo.
|
Body
```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
| volume | Polígono **OU** círculo da área, idêntico ao definido no SARPAS |
| altitude\_lower, altitude\_upper | Altitude geodésica (WSG84, W84) máxima e mínima em metros.
|
| time\_start, time\_end | 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"
|
| uss\_base\_url | 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.
|
Response
```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
| subcribers | 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 |
| version | Versão da ISA, gerado pelo DSS, para garantia de integridade. É necessário utilizar esse campo para atualizar ou deletar uma ISA. |
| **PUT** | /providers/user\_token/{token}/assign |
Associar usuário e provedor
Headers
| apikey | API Key disponível no BR-UTM Forms |
Path Param
| token
| SARPAS ID do usuário |
Body
```json
{
"data": {
"provider_secret": "your-provider-api-key",
"provider_id": "kong-consumer-custom-id"
}
}
```
Campos notáveis
| provider\_secret | API Key disponível no BR-UTM Forms
|
| provider\_id | \[OPCIONAL\] Custom ID do Kong associado ao Consumer
|
Response
| 200
| Success
|
| 404
| User not found |
Body
```json
{
"data": {
"provider_secret": "",
"provider_id": "",
"user_id": ""
}
}
```
Campos notáveis
| provider\_secret | API Key disponível no BR-UTM Forms
|
| provider\_id | \[OPCIONAL\] Custom ID do Kong associado ao Consumer
|
| user\_id
| SARPAS ID do usuário
|
Response
| 204
| Success |
| 404
| User not found
|
| 412
| Invalid provider and user relationship
|
| 500
| Internal server error
|
| **GET** | /user-keys/{user-id} |
Aprovar token de autenticação do provedor associado ao usuário
Path Param
| user-id | SARPAR ID do usuário
|
Bearer
Response
Bearer
Body
```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
| provider\_secret | API Key disponível no BR-UTM Forms
|
| provider\_id | \[OPCIONAL\] Custom ID do Kong associado ao Consumer
|
| user\_id
| SARPAR ID do usuário
|
Response
| **GET** | /bypass/categorize/{solicitationProtocol} |
Categoriza uma solicitação de voo por número de protocolo
Bearer
Path Param
| solicitationProtocol | Número de protocolo da solicitação |
Response
| 200
| Success |
| 404
| Solicitation not found
|
| 500
| Error
|
| **GET** | /bypass/analyze/{solicitationProtocol} |
Analisa uma solicitação de voo por número de protocolo
Bearer
Path Param
| solicitationProtocol | Número de protocolo da solicitação |
Response
| 200
| Success |
| 404
| Solicitation protocol not found
|
| 500
| Error
|
Bearer
Response
| **GET**
| /shared-aircraft-user
|
Busca todas as aeronaves compartilhadas com um usuário identificado pelo token de sessão
Bearer
Response
| **POST** | /user/flight/aircrafts |
Busca todas as aeronaves em voo, opcionalmente incluindo compartilhadas, de um usuário identificado pelo ID enviado na requisição
Bearer
Body
```json
{
"user_information_id": "1ed4b29e-8fe0-60aa-aefd-0242ac120019",
"shared": true
}
```
Campos notáveis
| user\_information\_id | SARPAS ID do usuário
|
| shared
| \[OPCIONAL\] Incluir aeronaves compartilhadas
|
Response
Bearer
Response
200
| **POST** | /polygon/{polygonId}/{userUuid} |
Cria uma área no ASA dados os identificadores do polígono e usuário
Bearer
Path Param
| polygonId | ID (definido pelo solicitante) do polígono criado
|
| userUuid
| SARPAS ID do usuário
|
Body
```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
Response
```json
{
voo_id: string
}
```
| **GET** | /polygon/{solicitationProtocol}/result |
Obter resultado da solicitação de área
Bearer
Path Param
| solicitationProtocol | Número de protocolo da solicitação de área |
Response
200 OK
| **POST** | /uss/identification\_service\_areas/{id} |
Path Parameters
Request Body
| **PUT** | /dss/subscriptions/{id} |
Path Parameters
| id | UUID da Subscription, criado pelo Display Provider |
Request Body
```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
| volume | Polígono **OU** círculo da área, idêntico ao definido no SARPAS |
| altitude\_lower, altitude\_upper | Altitude geodésica (WSG84, W84) máxima e mínima em metros.
|
| time\_start, time\_end | 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"
|
| uss\_base\_url | 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.
|
Response Body
```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"
}
}
```
| service\_areas | 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 |
| version | Versão da Subscription, gerado pelo DSS, para garantia de integridade. É necessário utilizar esse campo para atualizar ou deletar uma Subscription. |
Isolated OIR
JSON \[000\]
```json
{
"chave":"valor"
}
```
JSON \[020\]
```json
{
"operational_intent_reference": {
"id": "2f8343be-6482-4d1b-a474-16847e01af1e",
"flight_type": "VLOS",
"manager": "uss1",
"uss_availability": "Unknown",
"version": 1,
"state": "Accepted",
"ovn": "9d158f59-80b7-4c11-9c0c-8a2b4d936b2d",
"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://uss.example.com/utm",
"subscription_id": "78ea3fe8-71c2-4f5c-9b44-9c02f5563c6f"
}
}
```
JSON \[040\]
```json
{
"operational_intent": {
"reference": {
"id": "2f8343be-6482-4d1b-a474-16847e01af1e",
"flight_type": "VLOS",
"manager": "uss1",
"uss_availability": "Unknown",
"version": 1,
"state": "Accepted",
"ovn": "9d158f59-80b7-4c11-9c0c-8a2b4d936b2d",
"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://uss.example.com/utm",
"subscription_id": "78ea3fe8-71c2-4f5c-9b44-9c02f5563c6f"
},
"details": {
"volumes": [],
"off_nominal_volumes": [],
"priority": 0
}
}
}
```
Conflict OIR - Not implemented
Successful Auth
Invalid Scope
Invalid audience
Invalid token signature
In this test, the director creates an invalid token, that was not issued by an authorized token provider.
OIR activation
JSON 020
```json
{
"operational_intent_reference": {
"id": "2f8343be-6482-4d1b-a474-16847e01af1e",
"flight_type": "VLOS",
"manager": "uss1",
"uss_availability": "Unknown",
"version": 1,
"state": "Accepted",
"ovn": "9d158f59-80b7-4c11-9c0c-8a2b4d936b2d",
"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://uss.example.com/utm",
"subscription_id": "78ea3fe8-71c2-4f5c-9b44-9c02f5563c6f"
}
}
```
JSON 050
```json
{
"operational_intent_reference": {
"id": "2f8343be-6482-4d1b-a474-16847e01af1e",
"flight_type": "VLOS",
"manager": "uss1",
"uss_availability": "Unknown",
"version": 1,
"state": "Accepted",
"ovn": "9d158f59-80b7-4c11-9c0c-8a2b4d936b2d",
"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://uss.example.com/utm",
"subscription_id": "78ea3fe8-71c2-4f5c-9b44-9c02f5563c6f"
}
}
```
Conflict Constraint
Conflict Constraint
ISA com Subscription
JSON \[000\]
```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"
}
```
JSON \[010\]
```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": 100000,
"reference": "W84",
"units": "M"
},
"altitude_upper": {
"value": 100000,
"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://uss.example.com/utm",
"notify_for_operational_intents": false,
"notify_for_constraints": false
}
```
JSON \[020\]
```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"
}
}
}
```
JSON \[050\]
```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"
}
}
```
| Legenda
| 1. Serviço
- Requisito Alto Nível
- Requisitos Técnicos
|
1. Comunicação de Atividades
- o USP deve ser capaz de registrar e oferecer as intenções de voo, além de armazenar o histórico de atividades
- Inserir OIR
- Armazenar Logs de Operações
- Ser capaz de se inscrever (criar subscription) na área de operação do DSS
2. Autorização do espaço aéreo
- o USP deve ser capaz de processar as solicitações de voo
- Ser homologado como Provedor membro do BR-UTM
- Cumprir os requisitos
- Completar o processo de Onboarding BR-UTM
3. Gestão de conflitos e separação
- O USP deve ser capaz de identificar e bloquear a intenção de operação numa área que já esteja sendo utilizada, além de prover o geocaging
- Consultar OIR existentes
- Consultar Restrições
- Garantir Geocaging
4. Descoberta
- O USP deve ser capaz de consumir as informações disponibilizadas nos serviços de descoberta e sincronização
- Ser capaz de se comunicar com o DSS
- Possuir token gerado pelo Provedor de autenticação do BR-UTM para garantir autenticidade das comunicações
5. Planejamento de voo
- o USP deve disponibilizar ferramentas para o planejamento da operação durante a solicitação
- Fornecer uma interface para o operador planejar sua operação
- Criar OIR no padrão ASTM no DSS
6. Identificação
- O USP deve ser capaz de consumir as informações de cadastro de aeronaves do ecoUTM
- Enviar os dados de identificação SISANT nas solicitações do USP, conforme padrão ASTM
- Ser capaz de se autenticar no BR-UTM, e garantir a autenticidade de sua comunicação com outros USP
7. Registro
- O USP deve ser capaz de informar ao DSS o SISANT e dados dos envolvidos
- Ter um registro dentro do sistema BR-UTM que contenha os dados do USP
- Possuir token gerado pelo Provedor de autenticação do BR-UTM para garantir autenticidade das comunicações
8. Gerenciamento de restrições
- o USP deve ser capaz de aplicar as restrições recebidas do DSS
- Se comunicar com os Provedores de restrições
- Ser capaz de ler as informações de restrição no padrão ASTM
- Ser capaz de restringir/notificar as operações dos seus operadores com base nas restrições
9. Rastreamento e localização
- o USP deve ter a capacidade de notificação da ocupação efetiva da área proposta
- Prover informações de Remote Id
- Ser capaz de criar ISA (Identification Service Area) no padrão ASTM
- Ser capaz de obter tracking em tempo real de seus UAV
# LGPD
Documentações e dados a respeito da LGPD
# Comunicação com Ouvidoria ANPD
**De:** Vinicius Juvinski <>
**Enviado:** quinta-feira, 14 de dezembro de 2023 09:56
**Para:** ANPD - Ouvidoria <>
**Assunto:** Informações sobre a LGPD e Sistema de controle de tráfego aéreo do DECEA
Bom dia,
Faço parte da comissão que está desenvolvendo as premissas do sistema BR-UTM – é o novo sistema de controle de tráfego aéreo brasileiro que inclui também a parte de drones neste sistema.
Contudo, na concepção deste sistema, existem alguns papéis, o usuário/operador (piloto de drone), o Provedor(empresa de iniciativa privada que opera a área e responsável por todas as aeronaves que voam naquele espaço) e o DECEA.
Para que o sistema funcione, o Provedor deve enviar para o DECEA uma série de informações de identificação e rastreio dos drones voados pelo usuário/operador. Além destes dados serem enviados para o DECEA, o sistema prevê o compartilhamento destes dados com as autoridades (Policia, Policia federal) e surgiu a questão de o que se faz necessário entre as partes para que esse transito de informações não inflija a LGPD.
Somente o termo de uso informando que existe esse compartilhamento de informações já é o suficiente para que este novo sistema esteja de acordo com a LGPD?
Quais mecanismos se fazem necessário para que tudo esteja de acordo com a LGPD.
Obrigado
Tomo a liberdade de adicionar a página do projeto caso queiram mais informações
[https://www.decea.mil.br/?i=midia-e-informacao&p=pg\_noticia&materia=reuniao-do-projeto-br-utm-valida-desafios-e-avanca-em-propostas-de-abordagem](https://www.decea.mil.br/?i=midia-e-informacao&p=pg_noticia&materia=reuniao-do-projeto-br-utm-valida-desafios-e-avanca-em-propostas-de-abordagem)
Resposta:
Prezado Vinicius,
Em atenção à sua mensagem, pontuamos que a Autoridade Nacional de Proteção de Dados (ANPD) não tem realizado análises nem emitido orientações quanto ao enquadramento legal de processos ou atividades específicas nas hipóteses de tratamento previstas na Lei Geral de Proteção de Dados Pessoais - LGPD (Lei nº 13.709, de 14 de agosto de 2018). Nesse sentido, não dispomos de resposta específica à consulta apresentada.
Destacamos que, dentro de suas realidades, os agentes de tratamento devem adotar as providências destinadas à adequação à LGPD, que incluem o mapeamento e o registro das operações específicas de tratamento de dados pessoais que realizarem, assim como a identificação das respectivas bases legais e finalidades específicas. Essa identificação deve ser realizada com base nas circunstâncias e especificidades dos tratamentos de dados realizados.
Pontuamos que no site da ANPD podem ser consultadas respostas a Perguntas Frequentes (
[https://www.gov.br/anpd/pt-br/acesso-a-informacao/perguntas-frequentes-2013-anpd](https://www.gov.br/anpd/pt-br/acesso-a-informacao/perguntas-frequentes-2013-anpd)), e que futuros entendimentos desta Autoridade relativos à interpretação da LGPD também serão divulgados em nosso site ([https://www.gov.br/anpd/pt-br/documentos-e-publicacoes)](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes)).
Cabe ressaltar que os temas que serão objeto de regulamentação no biênio 2023-2024 estão previstos na Agenda Regulatória da ANPD, aprovada pela Portaria nº 35, de 4 de novembro de 2022 ([https://www.in.gov.br/en/web/dou/-/portaria-anpd-n-35-de-4-de-novembro-de-2022-442057885](https://www.in.gov.br/en/web/dou/-/portaria-anpd-n-35-de-4-de-novembro-de-2022-442057885)). No item 7 do referido documento está prevista a edição de Guia específico sobre as hipóteses legais de tratamento de dados pessoais.
Agradecemos o seu contato e permanecemos à disposição.
Atenciosamente,
Ouvidoria
**Autoridade Nacional de Proteção de Dados**
# 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.
# Ensaio 2
# 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
- Utilizar todos os estados das OIRs
- 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.
- [](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/qRoimage.png)
- Utilizar NTP do ICEA
- O ICEA disponibilizará um servidor NTP para sincronizar os horários entre todos os provedores.
- [](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/dqbimage.png)
- Utilizar altitude WSG84
- Padronizar o uso de altitude utilizando o padrão WSG84.
- Utilizar autenticação
- Para comunicação com o DSS e entre provedores, toda requisição deve possuir um token emitido pelo servidor de autenticação do ICEA
- Utilizar campo de prioridade na OIR
- 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.
- Permitir conflito entre voos VLOS/EVLOS
- 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:
[](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.
[](https://servicos2.decea.mil.br/br-utm/wiki/uploads/images/gallery/2024-05/1-autorizacao-de-voo-1.png)
P1 - Autorização de Voo
[](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.
[](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.
[](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
**Document Version:** 1.2 **Date:** June 16, 2025
## 1. Introduction & Vision
The BR-UTM Field Test 1 successfully validated the foundational capabilities of our Discovery and Synchronization Service (DSS), based on the InterUSS platform. Participants demonstrated the ability to perform basic strategic deconfliction of Operational Intent References (OIRs) and deconfliction from static Constraints.
This Second Field Test will expand upon that foundation, introducing critical new capabilities to validate the complete, end-to-end operational lifecycle. The vision is to simulate a real-world operational environment where multiple UAS Service Suppliers (USS) coordinate flights, and operators conduct live drone operations based on these coordinated intents.
### 1.1. New Features for Validation
This test will validate all previously tested features, plus the following crucial additions:
- **USS-to-USS Authentication:** Secure, token-based authentication for all inter-USS communication.
- **OIR Activation & State Management:** The full lifecycle of an OIR, including the transition to an "activated" state just before flight.
- **Priority Operations:** Handling of high-priority flights that may require other operations to adjust.
- **Remote Identification (Remote ID):** Integration of Remote ID information services into the USS workflow.
- **In-Flight Contingency Management:** Real-time response to dynamic, high-priority airspace constraints that appear during an active flight.
## 2. Core Objectives
The primary goals of this field test are to:
1. **Validate End-to-End OIR Lifecycle:** Demonstrate the complete process of creating, strategically deconflicting, activating, and closing out OIRs in a multi-USS environment.
2. **Verify Secure Inter-USS Coordination:** Ensure all participants can successfully implement and use the specified authentication protocols for all DSS and peer-to-peer USS interactions.
3. **Test Advanced Strategic Deconfliction:** Validate the system's ability to manage and resolve conflicts between multiple OIRs, including those with different priorities.
4. **Demonstrate OIR Activation:** Ensure that the transition of an OIR to its "activated" state is correctly propagated and managed by all relevant USSs.
5. **Validate Priority Handling:** Successfully manage the introduction of a high-priority OIR, requiring other active or planned operations to be modified or cleared.
6. **Integrate Remote ID Services:** Demonstrate that USSs can support the provision of Remote ID data for active flights to authorized entities.
7. **Conduct Live Flight Operations:** Have operators fly drones based on successfully coordinated and activated OIRs, proving the link between the digital UTM system and real-world flight.
## 3. Technical Architecture & Protocols
The core of the technical architecture remains the DECEA-provided **Discovery and Synchronization Service (DSS)**, which is an implementation of the InterUSS Platform.
- **API Contracts:** All participants must implement the server-side and client-side portions of the API contracts defined in the [**dp-icea/Protocols GitHub repository**](https://github.com/dp-icea/Protocols "null"). This is the single source of truth for all required interfaces.
- **DSS Implementation:** For context and documentation on the underlying technology, refer to the [**interuss/dss GitHub repository**](https://github.com/interuss/dss "null").
### 3.1. Authentication
Authentication is **mandatory** for all inter-USS and DSS API calls. The process is detailed in the workshop documentation [\[Desconflito\]\[Autenticação\] Roteiro Etapa 1](https://servicos2.decea.mil.br/br-utm/wiki/books/documentacao-tecnica/page/desconflitoautenticacao-roteiro-etapa-1 "[Desconflito][Autenticação] Roteiro Etapa 1").
- **Token Generation:** Before making a request to another USS, you must first request a JSON Web Token (JWT) from the DECEA authentication service. The `intended_audience` and `scope` parameters are critical.
- **Token Validation:** When your USS receives a request, you must validate the incoming JWT. This involves:
1. Verifying the token's signature using the Eco-UTM public key.
2. Checking the token's expiration time (`exp`).
3. Confirming the audience (`aud`) matches your USS identifier.
4. Ensuring the token contains the required `scope` for the requested endpoint.
### 3.2. Governing Standards
This field test will adhere to the following international standards, which form the basis of the technical and operational protocols:
- **UTM Interoperability:** All strategic coordination and information exchange between USSs shall be conducted in accordance with **ASTM F3548-21**, "Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability."
- **Remote ID:** The implementation and data formats for Network Remote ID services shall follow **ASTM F3411-22a**, "Standard Specification For Remote ID And Tracking."
## 4. Participant Roles & Responsibilities
Participants can choose to act in one or both of the following roles:
- **USS Provider:** An entity running a software implementation that provides UAS services.
- **Responsibilities:**
- Implement the full API contract.
- Integrate with the authentication service.
- Connect to the central DSS to discover other operations and publish their own.
- Manage the full lifecycle of OIRs on behalf of their operator clients.
- Coordinate directly with other USSs for strategic deconfliction.
- Provide an endpoint for other USSs to subscribe to updates for OIRs they manage.
- **Drone Operator:** An entity that plans and executes drone flights.
- **Responsibilities:**
- Partner with a registered USS Provider for flight planning.
- Conduct pre-flight checks.
- Execute the flight mission precisely according to the activated OIR (trajectory, altitude, and time).
- Equip the drone with the necessary hardware for Remote ID broadcast.
- Maintain communication with the USS during flight and be prepared to act on in-flight instructions, including immediate termination of the operation.
## 5. Test Scenarios
The field test will be structured around a series of progressively complex scenarios.
### Scenario 1: Nominal Coordination and Flight Activation
- **Objective:** Validate the basic workflow, authentication, and OIR activation.
- **Execution:**
1. Two or more USS providers will each create a distinct, non-conflicting OIR in the DSS.
2. Just prior to the scheduled flight time, each USS will update their OIR state to **`Accepted`** and then **`Activated`**. They must notify any subscribers of this change.
3. The corresponding Drone Operator will execute the flight.
4. During the flight, the drone will broadcast Remote ID data.
5. Upon completion, the USS will update the OIR state to **`Ended`**.
### Scenario 2: Strategic Deconfliction with a Constraint
- **Objective:** Validate conflict detection and resolution against a static geographical constraint.
- **Execution:**
1. The DSS will be pre-populated with a `Constraint` (e.g., a no-fly zone).
2. A USS will attempt to create an OIR that partially overlaps with the constraint.
3. The USS must identify the conflict by querying the DSS.
4. The USS must then modify the OIR's geometry to remove the conflict before it can be successfully created and activated.
5. The Operator will fly the deconflicted mission.
### Scenario 3: Inter-USS Deconfliction & Negotiation
- **Objective:** Validate peer-to-peer coordination to resolve a conflict between two OIRs.
- **Execution:**
1. USS-A creates and submits a valid OIR to the DSS.
2. USS-B attempts to create an OIR whose 4D volume overlaps with USS-A's OIR.
3. USS-B's initial attempt to create the OIR in the DSS should fail due to the conflict.
4. USS-B must query the DSS, identify the conflicting OIR from USS-A, and initiate a strategic negotiation (as defined by the ASTM standard, though this may be a manual coordination step for the test).
5. One or both USSs will adjust their OIRs to resolve the conflict.
6. Once resolved, both OIRs can be created and subsequently activated for flight.
### Scenario 4: Priority Operation (Pre-Flight)
- **Objective:** Validate the system's response to a high-priority flight identified during the planning phase.
- **Execution:**
1. Multiple "standard" priority OIRs are planned or active in the DSS.
2. A designated USS (the "Emergency Services USS") will introduce a new OIR with **`priority`** set higher than the others (e.g., for a simulated medical delivery or security overwatch). This OIR will overlap with existing standard operations.
3. Other USSs must detect this high-priority OIR and are required to modify or cancel their own conflicting operations to clear the area.
4. The high-priority flight is then activated and flown.
### Scenario 5: In-Flight Contingency - Dynamic Constraint
- **Objective:** Validate a USS's ability to monitor for new conflicts during an active flight and instruct the operator to take immediate, appropriate action.
- **Execution:**
1. USS-A has an OIR in the `Activated` state, and its Operator is conducting the flight.
2. An "Emergency Services USS" creates a new, high-priority `Constraint` or `OIR` that dynamically appears and conflicts with USS-A's active flight volume.
3. USS-A must detect this new, superseding conflict in near real-time by monitoring the DSS or receiving a notification from a subscription.
4. Upon detecting the unmitigable conflict, USS-A must immediately relay a command to its Drone Operator to cease the operation.
5. The Operator must comply with the instruction and safely terminate the flight (e.g., land immediately or execute a pre-planned return-to-launch maneuver).
6. USS-A updates its OIR state to `Ended` to reflect the early termination of the flight.
## 6. Operational Safety Considerations
To ensure the safety of all participants and the public, the following operational rules are mandatory for all live flights during the test.
- **Flight Rules:** All live flights will be conducted under Visual Line of Sight (VLOS) conditions, in strict accordance with **ICA 100-40**. While the technical scenarios will simulate Beyond Visual Line of Sight (BVLOS) coordination, the actual flight must remain within the pilot's line of sight at all times.
- **Immediate Operation Termination:** All operators must be able to cease operations immediately upon command from their managing USS. This capability is critical for scenarios involving in-flight contingencies.
- **Loss of C2 Link Procedure:** All UAS must be configured to execute a "Return to Home" (RTH) procedure automatically upon loss of the command and control (C2) link. The RTH altitude must be set to the operation's maximum authorized ceiling to ensure predictable behavior and vertical deconfliction.
- **Fly-Away Emergency Declaration:** In the event of a fly-away or any situation where the operator loses control of the aircraft, the operator must immediately declare an emergency to DECEA’s personnel, as well as the USS. The USS will then be responsible for propagating this information as required.
## 7. Getting Started & Prerequisites
All participants must complete the following steps to be ready for the field test:
1. **Register Participation:** Formally register your organization and declare your intended role(s).
2. **Review Documentation:** Thoroughly read the API documentation at `https://github.com/dp-icea/Protocols`.
3. **Implement Authentication:** Implement the JWT-based authentication client and server logic. You will be provided with API keys and the public key.
4. **Implement OIR Activation:** Ensure your system correctly handles the `Accepted`, `Activated`, and `Ended` states of an OIR.
5. **Provide Endpoints:** USS Providers must supply the base URL for their publicly accessible API so it can be registered in the DSS for peer-to-peer communication.
6. **Prepare for Flight:** Operators must have their drones, ground control stations, and Remote ID broadcast modules ready for operation.
7. **Synchronize Time Servers:** All USS and operator systems must synchronize their clocks with DECEA’s official NTP (Network Time Protocol) server, to be provided. Accurate, synchronized time is critical for the correct sequencing of operations, conflict detection, and logging.
We look forward to your participation in this critical test to advance the future of aviation in Brazil.
# Checklist Provedores
Um provedor que deseja se integrar tecnicamente ao ecossistema do BR-UTM pode utilizar os checklists abaixo como balizadores para o desenvolvimento das suas soluções.
Os checklists estão dividos em três. O primeiro, de autenticação, é obrigatório para todos o provedores e deve ser completado por primeiro, visto que todos os outros checklists dependem da autenticação. O checklist de desconflito visa guiar o desenvolvimento para provedores que desejam criar liberações de espaço aéreo para seus operadores, em alternativa à liberação obtida através do SARPAS. Já o checklist de identificação guia o desenvolvimento de aplicações que provêm em tempo real a posição dos drones via internet. A obrigatoriedade da identificação durante a operação ainda está em debate pelo grupo. Orienta-se que provedores tenham essa capacidade para todos os voos.
Autenticação
O protocolo de autenticação utilizada no ecossistema no BR-UTM segue a arquitetura definida em ASTM F3548-21 Anexo X1.1 "*Base Deployment: Access Tokens with Audience Claims*", baseado no padrão de tokens JWT: IETC RFC 7519.
Checklist:
- [ ] Obter apikey
- [ ] Realizar autenticação
- [ ] Validar autenticação de outro USS
Os detalhes técnicos podem ser obtidos abaixo. A referência técnica da etapa de autenticação pode ser encontrada em [Autenticação Service Provider](https://servicos2.decea.mil.br/br-utm/wiki/books/documentacao-tecnica/page/autenticacao-service-provider "Autenticação Service Provider")
Desconflito
Para ser um provedor de desconflito, o provedor deve seguir a especificação ASTM F3548-21. Os detalhes técnicos estão em: [\[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")
Checklist
- [ ] OIR Isolada
- [ ] OIR próxima a constraint
- [ ] OIR com conflito
- [ ] Endpoints de coordenação
- [ ] Ativação de OIR
- [ ] Exibição da OIR no viewer do ICEA (Entrar em contato com a equipe técnica)
Identificação
Para ser um provedor de identificação, o provedor deve seguir a especificaçao ASTM F3411-22a. Os detalhes técnicos estão em: [\[Remote ID\] Onboarding Service Provider.](https://servicos2.decea.mil.br/br-utm/wiki/books/documentacao-tecnica/page/remote-id-onboarding-service-provider "[Remote ID] Onboarding Service Provider")
O protocolo de comunicação entre DRONE <-> USS não é escopo do BR-UTM, ficando cada USS livre para implementar da melhor maneira possível. É esperado que o provedor atualize a posição de seus drones no mínimo a cada 4 segundos
Checklist
- [ ] Criação ISA sem subscription
- [ ] Criação ISA com subcription
- [ ] Exibição da posição do drone no viewer do ICEA (Entrar em contato com a equipe técnica)
Autenticar-se
A URL base é GET [`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*
| intended\_audience | USS de destino da mensagem (Vem na OIR ou Constraint no campo *manager*)
|
| scope | escopo da requisição. Ex.: utm.strategic\_coordination.
O scope esperado de cada endpoint está definido no OpenAPI
|
| apikey | chave recebida do ICEA. Pode-se optar em enviar esse campo no Header da requisição
|
Validar autenticação de outro USS
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:
| aud
| Nome do provedor destino da requisição
| "core-service"
|
| exp
| Timestamp epoch do horário de expiração do token. O token não deve ser aceito a partir desse horário
| 1719777868 |
| iss
| Nome do provedor emissor do token
| ICEA
|
| scope
| Scope autorizado pelo token. Cada endpoint deve aceitar apenas determinados scopes, conforme definido no OpenAPI
| utm.strategic\_coordination
|
| sub
| Nome do provedor origem da requisição
| "USS1" |
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
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.
Eco-UTM Autenticator Public Key
```
-----BEGIN PUBLIC KEY-----
MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgHkNtpy3GB0YTCl2VCCd22i0rJwI
GBSazD4QRKvH6rch0IP4igb+02r7t0X//tuj0VbwtJz3cEICP8OGSqrdTSCGj5Y0
3Oa2gPkx/0c0V8D0eSXS/CUC0qrYHnAGLqko7eW87HW0rh7nnl2bB4Lu+R8fOmQt
5frCJ5eTkzwK5YczAgMBAAE=
-----END PUBLIC KEY-----
```
---
## 1. Introduction & 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:
- **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.
---
## 2. Core Objectives
The primary goals of this field test are to:
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.
---
## 3. Technical Architecture & 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.
- **Governing Standards:** All operations will continue to be governed by **ASTM F3548-21** (UTM Interoperability) and **ASTM F3411-22a** (Remote ID).
---
## 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
- **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).
### Scenario 2: OIR Deviation and Non-Nominal Volume Creation
- **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.
### Scenario 3: Response to Flight Outside UTM Zone
- **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.
### Scenario 4: Standardized Check-in / Check-out
- **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.
---
## 5. Operational Safety Considerations
All safety protocols from the previous test remain in effect.
- **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.
# 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
# III Ensaio de Campo BR-UTM
Data: 15 a 17 de dezembro de 2025
**Realização**: Instituto de Controle do Espaço Aéreo (ICEA)
Local: Instituto de Estudos Avançados (IEAv), São José dos Campos, SP.
## 1. Introdução
O terceiro ensaio de campo do projeto BR-UTM 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 realidade do operador, 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.
Com o suporte tecnológico da Arsitec 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.
## 2. Objetivos Operacionais
Os ensaios foram estruturados para validar cinco pilares fundamentais para a segurança do voo:
1. Resposta a Contingências em Tempo Real: Capacidade do USS de identificar restrições dinâmicas e guiar o piloto na mitigação do risco.
2. Conformidade com a OIR (Operation Intent Region): Verificação automática de desvios geográficos e transição de estados de voo (Ativo → Não-Conforme → Contingência).
3. Gestão de Volumes Não Nominais: Garantia de que, em caso de falha, o sistema reserve um volume de proteção (buffer) e impeça novos voos nessa área.
4. Desempenho de Reação: Medição do tempo entre o evento adverso e a notificação ao operador.
5. Automação de Check-in / Check-out: Ativação e desativação de OIR de maneira automática e transparente para o operador
## 3. Infraestrutura e Ecossistema
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 ICEA e o NCTI, garantindo a integridade dos dados e a visualização centralizada por parte do órgão regulador.
## 4. Detalhamento dos Ensaios por Provedor
Nesta edição, as empresas tiveram autonomia para propor voos que refletissem seus desafios operacionais diários, totalizando três missões por provedor.
#### Atech
A arquitetura da Atech utilizou a transmissão de RemoteID Broadcast 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.
- Voo 01: Gestão de Não-Conformidade e Contingência Temporal O drone foi comandado para fora dos limites da OIR. O sistema detectou o desvio e alterou o status para Não-Conforme, 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 Contingência, emitindo uma ordem de encerramento imediato.
- Voo 02: Violação de Perímetro UTM (Saída de Área) Neste cenário, o drone cruzou o limite externo da Zona UTM. Diferente do voo anterior, a transição para o estado de Contingência foi instantânea, refletindo a gravidade de operar em espaço aéreo não monitorado pelo sistema.
- Voo 03: Resposta a Restrição Dinâmica em Voo 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.
Nota Operacional: 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.
#### Aeroscan
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.
- Voo 01: Bloqueio de Ativação por Restrição Prévia 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.
- Voo 02: Notificação de Restrição Dinâmica e Finalização 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.
- Voo 03: Desvio de OIR e Criação de Volume Não-Conforme 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.
#### Speedbird
Como fabricante e operadora, a Speedbird integrou sua GCS (Ground Control Station) diretamente ao UTM, permitindo uma comunicação profunda entre a telemetria da aeronave e o serviço de rede.
- Voo 01: Desconflito Estratégico em Solo 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.
- Voo 02: Decisão de Contingência em Restrição Dinâmica 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.
- Voo 03: Teste de Cerca Virtual (Controle Manual) 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.
## 5. Conclusão Operacional
Um grande ganho deste ensaio foi a validação da Lógica de Volumes Não-Nominais:
| Cenário
| Objetivo
| Resultado Observado
|
| Desvio de OIR
| Validar alertas de conformidade
| Transição precisa de "Ativa" para "Não-Conforme" com prompts de correção.
|
| Restrição Dinâmica
| Testar reação a fechamento de área
| Bloqueio imediato de ativação e comando de pouso em áreas seguras.
|
| Volume Não Nominal
| Proteção de terceiros
| USS notificou o ecossistema criando áreas de exclusão baseadas na autonomia da bateria.
|
| Intervenção de Inércia
| Segurança física
| O drone respeitou os limites geográficos mesmo sob comando manual agressivo.
|
