I WorkShop BR-UTM (Jul/24)

Documentação para participação no WorkShop

Repositórios e Endpoints

Apresentação Workshop

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"
      }
    }
  ]
}

 

Vizualização

 image.png

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"
      }
    }
  ]
}

Visualização

image.png

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"
      }
    }
  ]
}

Visualização

image.png

[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

Endpoints de coordenação

image.png

 

Ativação de OIR (Momentos antes do voo)

Atualizar a OIR no DSS e notificar os Subscribers

image.png

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

  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-----

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.

image.png

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

image.png

Um exemplo de troca de mensagens autenticadas é:

image.png

Uso da API Key

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

  1. Insira a sua API Key no header da requisição;
  2. Insira o scope 
  3. Insira o intended_audience
    1. Em caso de comunicação com outro USS, o preencha com o conteúdo do campo manager da resposta do DSS.

Validator

image.png

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 linkneste 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:

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

Fluxograma

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:

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

Autenticação

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

Endpoints

A dinâmica de comunicação entre Service Provider, Display Provider e DSS está descrita na norma ASTM 3411-22a. Para facilitar o entendimento, alguns possíveis cenários de utilização estão descritos na página Cenários.

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/

image.png

Caso seja necessário criar um novo arquivo de teste, é necessário implementá-lo através de um arquivo .yaml ou JSON seguindo as guidelines definidas nesse README

How to

Quick start guide


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

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

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

0 - Fluxo.png

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


Autorização de Voo

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

1 - Autorização de Voo (1).png

P1 - Autorização de Voo

1.1 - Desconflito Estratégico (1).png

P1.1 - Desconflito Estratégico


Ativação de Voo

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

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

2 - Ativação de voo (3).png

P2 - Ativação de Voo


Mudanças Dinâmicas


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

3 - Mudanças Dinâmicas (1).png

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:

  1. Verificar se está gerando o token

Para criar OIR:

  1. 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']