I WorkShop BR-UTM (Jul/24)
Documentação para participação no WorkShop
- Repositórios e Endpoints
- Entidades da Simulação
- [Desconflito][Autenticação] Roteiro Etapa 1
- Introdução Teórica RID e DSS
- Autenticação Service Provider
- [Remote ID] Onboarding Service Provider
- [Tracking] Onboarding Display Provider
- [USS Qualifier] Teste automatizado de Provedor
- OIR Status
- Modelagem de Processos - Autorização de Voo por Provedores
- Operações USS: Diagramas de Sequencia
- [USS][Desconflito] Código Exemplo
Repositórios e Endpoints
DSS: https://github.com/dp-icea/dss
Monitoring: https://github.com/dp-icea/utm_monitoring
SCD-Provider Example: https://github.com/dp-icea/scd_provider/tree/refactor-golang
Swagger: http://172.18.31.95:9001/
Endpoints
Validator: 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/
SBR497
GeoJSON
{
"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"
}
}
]
}
OIR USS ICEA
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"
}
}
]
}
Restrição
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"
}
}
]
}
[Desconflito][Autenticação] Roteiro Etapa 1
Criação de OIR
Uma Operational Intent Reference(OIR) é a representação 4D da intenção de operação de uma aeronave não tripulada. No ambiente UTM, a criação e edição de OIRs deve ser coordenada com os outros provedores presentes ou interessados na região da operação. Para possibilitar que essa coordenação seja feita programaticamente, o DECEA manterá um serviço de Descoberta, que é um local onde provedores podem declarar suas operações, assim como obter as operações de outros provedores numa área específica.
Nesse workshop, iremos aprender a interagir com esse serviço de descoberta, chamado DSS. O DSS provido pelo DECEA é derivado da implementação feita pelo projeto InterUSS, que por sua vez é uma implementação dos padrões ASTM-3411 e ASTM-3548. A comunicação com o DSS é feita via HTTP e os contratos estão definidos em: https://github.com/dp-icea/Protocols
A complexidade na criação da OIR depende de quantas outras entidades (Constraints ou outras OIRs) estão presentes no mesmo volume 4D. Nesse workshop, iniciaremos com o cenário mais simples, evoluindo até o cenário mais complexo.
OIR isolada
OIR próxima a Constraint
OIR com conflito
Maior ou igual prioridade
Menor prioridade
Autenticação
Autenticar-se
A URL base é 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
- Verificar assinatura do token
- Deve-se validar a assinatura do token utilizando a chave pública do ICEA, que será fornecida durante o workshop.
- Verificar a validade do token
- Deve-se validar que o campo "exp" não seja menor do que o horário atual
- Verficiar audiência do token
- Deve-se validar que o campo "aud" seja o seu nome, ou seja, o nome do provedor que está recebendo a requisição
- Verificar o scope
- 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-----
Introdução Teórica RID e DSS
Tracking / Network Remote ID
Tracking, Network Remote ID, ou simplesmente Net-RID, é um serviço que permite uma aeronave não tripulada (UAS) prover sua localização, identificação de seu operador e outras informações operacionais relevantes, que podem ser obtidas por entidades autorizadas como órgãos fiscalizadores, outros provedores operando na mesma área, ou até mesmo a população em geral.
Para fornecer o serviço de Net-RID, o provedor deve ser capaz de trocar informações com outros provedores utilizando a interface definida no padrão internacional ASTM 3411-22a - Standard Specification for Remote ID and Tracking. Para possibilitar a interoperabilidade dos participantes e provedores, deve ser fornecido o serviço de "Service Discovery", que permite a descoberta de outros provedores atuando na mesma área.
Diagrama: Modelo conceitual
A ASTM também indica a seguinte documentação de API, como sugestão de interfaces para comunicação entre os serviços acima, que pode ser encontrada no padrão OpenAPI em: https://github.com/uastech/standards/tree/astm_rid_api_2.1/remoteid
Para nosso ensaio, seguiremos inicialmente a proposta acima, com possibilidade de alterações conforme o grupo achar necessário.
Service Discovery
Conforme previsto no padrão ASTM F3411-22a, o service discovery deve possibilitar com que provedores descubram outros provedores atuando na mesma região, para que estes possam se comunicar. No cenário de comunicação HTTP, descobrir um provedor significa conhecer seu endereço web (url) para poder enviar requisições HTTP, em endpoints pré-definidos.
Para isso, a Linux Foundation possui um projeto chamado InterUSS Platform que possui uma implementação do service discovery de maneira distribuída e sincronizada, denominado DSS (Discovery and Synchronization Service). Distribuído significa que várias entidades podem subir suas próprias instâncias do serviço, descentralizando e garantindo que não exista um ponto único de falha. Sincronizado significa que mesmo que haja múltiplas instâncias, todas possuem as mesmas informações ao mesmo tempo.
No escopo do ensaio, será utilizado o DSS sem nenhuma modificação inicial. Porém, para simplificação dos testes, o serviço possuirá somente uma instância, provida pelo DECEA. Isso permite que os potenciais provedores possam focar em implementar suas responsabilidades específicas e agilizar os processos do ensaio.
Serviços BR-UTM
Seguindo a matriz de serviços que devem ser atendidos pelo BR-UTM, ao final do ensaio esperamos atender de forma completa o serviço de Discovery Service com o DSS, e o de Tracking and Location Service com o Net-RID. Também esperamos atender de forma parcial o Activity Reporting System com o Display Service do Net-RID.
Autenticação Service Provider
API Key:
Na comunicação do BR-UTM (imagem abaixo), as requisições devem ser autenticadas e autorizadas. Devido à natureza distribuída da arquitetura, não é viável que cada provedor possua sua lógica de autenticação e autorização.
Portando, a solução proposta pela ASTM é a de um servidor de autenticação central onde os provedores obtém tokens OAuth2 codificados e assinados em JWT. O Validator da documentação abaixo checa a validade da assinatura do token, utilizando a chave pública do Auth Server.
Um exemplo de troca de mensagens autenticadas é:
Uso da API Key
Com sua API Key, você pode realizar ações programaticamente no ECO-UTM:
- Insira a sua API Key no header da requisição;
- Insira o
scope
- Insira o
intended_audience
- Em caso de comunicação com outro USS, o preencha com o conteúdo do campo
manager
da resposta do DSS.
- Em caso de comunicação com outro USS, o preencha com o conteúdo do campo
Validator
Implementação
Código de exemplo para início da implementação do Auth Server e do Validator em Go
Código exemplo
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-----
Lista de endpoints
A lista completa de endpoints também está disponível neste link, neste arquivo OpenAPI e nesta coleção no Insomina.
ECO-UTM
A URL base para os seguintes endpoints é http://montreal.icea.decea.mil.br:64235/
GET | /token |
Aprovar token de autenticação do provedor associado ao usuário
Path Param
intented_audience | user da entetidade de destino da mensagem |
scope | escopo da requisição |
apikey | chave recebida do ICEA |
Bearer
token | Bearer token gerado |
Código exemplo python
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 |
[Remote ID] Onboarding Service Provider
No contexto do serviço de Network RemoteID, um Service Provider é um provedor USS que é capaz de receber dos seus drones os dados de localização em tempo real, e disponibilizar esses dados on demand em uma API também em tempo real. A especificação a ser seguida está definida pela ASTM F3411-22a. Ainda não foi definido a obrigatoriedade do item 4.4 "Broadcast Remote ID". Portanto, nessa página apenas será definido o uso dos itens 4.5 em diante.
Pré-requisitos técnicos
Para um USS se tornar um provedor de Tracking existem os seguintes pré-requisitos técnicos que não estão no escopo dessa documentação, ficando a critério do provedor como implementar esses pré-requisitos:
- Possuir um servidor HTTP para solicitar e receber as requisições listadas abaixo
- Possuir infraestrutura para obter os dados de posição instantânea do drone. Esses dados devem estar disponíveis em tempo real no servidor HTTP
Fluxograma
Endpoints
A dinâmica de comunicação entre Service Provider, Display Provider e DSS está descrita na norma ASTM 3411-22a. Para facilitar o entendimento, alguns possíveis cenários de utilização estão descritos na página Cenários.
O padrão seguido no ensaio será o descrito em https://github.com/dp-icea/Protocols/tree/main/remoteid
Conforme o padrão OpenAPI acima, os endpoints que o Service Provider precisará prover
GET | /uss/flights |
Endpoint onde os Display Providers obterão os dados de tracking das aeronaves sob responsabilidade do Service Provider em uma determinada área
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
{
"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
{
"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
{
"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 |
Interação com DSS
O Service Provider, conforme definido no padrão ASTM3411-22a, deve criar entidades de área 4D denominadas Identification Service Area (ISA), onde este proverá o serviço de tracking. Os endpoints expostos pelo DSS estão descritos no arquivo OpenAPI descrito acima.
Como exemplo, o endpoint abaixo é onde o Service Provider realizará a criação da ISA no DSS:
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
{
"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
{
"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. |
[Tracking] Onboarding Display Provider
No contexto do serviço de Tracking, um Display Provider é um provedor USS que tem objetivo de exibir a posição de drones em tempo real para seus usuários.
Pré-requisitos técnicos
Para um USS se tornar um provedor de display de Tracking existem os seguintes pré-requisitos técnicos que não estão no escopo dessa documentação, ficando a critério do provedor como implementar esses pré-requisitos:
- Possuir um servidor HTTP para solicitar e receber requisições
- Possuir App para visualização de posição de drones
Autenticação
Para o ensaio, a autenticação será feita em um serviço OAuth centralizado do DECEA, ainda a ser descrito.
Endpoints
A dinâmica de comunicação entre Service Provider, Display Provider e DSS está descrita na norma ASTM 3411-22a. Para facilitar o entendimento, alguns possíveis cenários de utilização estão descritos na página Cenários.
O padrão seguido no ensaio será o descrito em https://github.com/uastech/standards/tree/astm_rid_api_2.1/remoteid
Conforme o padrão OpenAPI acima, os endpoints que o Display Provider precisará prover:
POST | /uss/identification_service_areas/{id} |
Path Parameters
id | UUID da ISA |
Request Body
Interação com DSS
O Service Provider, conforme definido no padrão ASTM3411-22a, deve criar entidades de Subscription em uma área específica, para encontrar os atuais Service Providers, e também para receberem notificações caso novos provedores se registrem na área. Os endpoints expostos pelo DSS estão descritos no arquivo OpenAPI descrito acima.
Como exemplo, o endpoint abaixo é para criação de Subscriptions:
PUT | /dss/subscriptions/{id} |
Path Parameters
id | UUID da Subscription, criado pelo Display Provider |
Request Body
{
"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
{
"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. |
[USS Qualifier] Teste automatizado de Provedor
US: https://pista.decea.mil.br/project/br-utm-tecnologia/us/41?milestone=309
Introdução
A InterUSS disponibiliza um conjunto de testes suites automatizados (USS QUALIFIER) para validar os conformidade na implementação de UAS Service Suppliers (USS).
Validação dos seguintes critérios de conforme:
- Remote ID (ASTM F3411-19/22);
- Strategic Conflict Detection (ASTM F3548-21);
- UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability Specification.
Como a implementação do DSS feita pelo time de pesquisa do ICEA foi feita a partir da solução da InterUSS, para um provedor se integrar ao nosso ecossistema, sua implementação deve estar em concordância com as normas utilizadas em sua implementação.
O objetivo dessa US é implementar a configuração de um ambiente de testes automatizada a partir de um arquivo .env
Solução
Para utilizar USS locais em seus testes, deve-se subir um container contendo a aplicação e sua configuração de ambiente, a qual deve conter as seguintes variáveis:
environment:
- MOCK_USS_AUTH_SPEC=DummyOAuth(http://oauth.authority.localutm:8085/token,uss1)
- MOCK_USS_DSS_URL=http://dss.uss1.localutm
- MOCK_USS_PUBLIC_KEY=/var/test-certs/auth2.pem
- MOCK_USS_TOKEN_AUDIENCE=scdsc.uss1.localutm,localhost,host.docker.internal
- MOCK_USS_BASE_URL=http://scdsc.uss1.localutm
- MOCK_USS_SERVICES=scdsc,versioning,interaction_logging,flight_planning
- MOCK_USS_INTERACTIONS_LOG_DIR=output/scdsc_a_interaction_logs
- MOCK_USS_PORT=80
- MOCK_USS_PROXY_VALUES=x_for=1,x_proto=1,x_host=1,x_prefix=1,x_port=1
Após configurar e implantar o USS, pode-se configurar o test suite que deseja executar. Como existem perfis diferentes de USS, foram disponibilizados arquivos de configuração visando validar conformes mais específicos dos seus respectivos tipos, estes podem ser encontrados no diretório monitoring/monitoring/uss_qualifier/configurations/dev/
Caso seja necessário criar um novo arquivo de teste, é necessário implementá-lo através de um arquivo .yaml ou JSON seguindo as guidelines definidas nesse README
How to
git clone https://github.com/interuss/monitoring.git
cd monitoring
#deploys local infrastructure containing DSS, database and Auth Server
make start-locally
COMPOSE_PROFILES='' make start-uss-mocks
cd /monitoring/uss_qualifier
./run_locally.sh
OIR Status
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.
- Utilizar NTP do ICEA
- 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
Modelagem de Processos - Autorização de Voo por Provedores
O processo habitual de autorização de voo por provedores deve seguir o seguinte fluxo:
Fluxo de Autorização e Ativação de Voo
Autorização de Voo
O processo de Autorização de Voo (P1) é a primeira etapa do desconflito estratégico de uma operação com drone. O processo começa com um pedido do operador. Esse pedido deve seguir um padrão (ainda não definido), e esse padrão deve ser validado pelo provedor USS. Após, o provedor deve realizar a checagem de desconflito estratégico, e por fim cadastrar o novo voo no ECO-UTM. Caso alguma checagem falhe, o provedor deve notificar o operador dessa falha. É permitido, porém não obrigatório, que o USS sugira alternativas para o operador em casos de rejeição.
P1 - Autorização de Voo
P1.1 - Desconflito Estratégico
Ativação de Voo
Após ter seu voo aprovado, o operador deve solicitar a ativação do voo instantes antes de sua execução. Nessa etapa, o provedor deve garantir que a autorização de voo continua válida, e que as condições de voo (condições ainda não definidas) permitem a realização segura do voo. Após a checagem, o USS notifica o operador que ele pode inicar a operação.
Então, o provedor aguarda notificação do operador sobre o encerramento da operação. Recebendo a notificação, o operador deve encerrar o plano de voo no ECO-UTM.
P2 - Ativação de Voo
Mudanças Dinâmicas
No período entre a autorização e a ativação, pode ocorrer mudanças nas condições do espaço aéreo, como uma nova restrição ou um novo voo com maior prioridade. Nesses casos, é de suma importância que o USS notifique o operador dessa atualização, para evitar frustrações do operador na hora da ativação do voo.
P3 - Mudanças Dinâmicas
Emergência
WIP
Operações USS: Diagramas de Sequencia
Cenário 1:
Apenas um Service provider e nenhum Display provider na área durante o Voo
Cenário 2:
Service provider cria área onde já existe uma Subscription (Display Provider)
Cenário 3:
Criação de Subscription onde já exista ISA
Cenário 4:
Usuário do Display Provider deseja visualizar uma área. Nessa área já existe um Service Provider (USS 1), e durante a exibição, um novo Service Provider (USS 2) inicia operações na área. Esse cenário foi adaptado da documentação do InterUSS DSS.
[USS][Desconflito] Código Exemplo
Exemplo de código Provedor de Desconflito (Go e Python): https://github.com/dp-icea/scd_provider
Para realizar autenticação:
- Verificar se está gerando o token
Para criar OIR:
- Enviar GeoJSON da área desejada
Abaixo segue exemlpo de código em Python:
app.py
from flask import Flask, request
from dss import Dss
import json
app = Flask(__name__)
database = {}
dss = Dss()
@app.route('/uss/v1/operational_intents/<operational_intent_id>', methods=['GET'])
def get_oir(operational_intent_id):
print(database)
if operational_intent_id not in database:
return {"msg": 'No such OIR'}, 404
return json.dumps(database[operational_intent_id], default=lambda o: o.__dict__)
@app.route('/injection/oir', methods=['PUT'])
def inject_oir():
volume = request.get_json()
try:
dss.conflict_manager.check_restrictions(volume)
dss.scd.check_strategic_conflicts(volume)
oir = {}
oir["operational_intent"] = {}
oir["operational_intent"]["reference"] = dss.scd.put_operational_intent(volume)
oir["operational_intent"]["details"] = {
"volumes": [],
"off_nominal_volumes": [],
"priority": 0
}
oir["operational_intent"]["details"]["volumes"].append(volume)
database[oir["operational_intent"]["reference"]['id']] = oir
except Exception as ex:
print(f"Erro na criação: {ex}")
return {"msg": "Erro"}, 400
return {"Success": True}, 201
if __name__ == '__main__':
app.run(port=5050)
dss.py
from conflict_manager import ConflictManager
from scd import Scd
class Dss:
def __init__(self) -> None:
self.conflict_manager = ConflictManager()
self.scd = Scd()
scd.py
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
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']