Onboarding Provedores Tracking (Ensaio)

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

Introdução

Tracking / Network Remote ID

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

Para fornecer o serviço de Net-RID, o provedor deve ser capaz de trocar informações com outros provedores utilizando a interface definida no padrão internacional ASTM 3411-22a - Standard Specification for Remote ID and Tracking. 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.

Onboarding Service Provider

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

Pré-requisitos técnicos

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

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

Autenticação

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

Fluxograma

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

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.

Cenários

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.