# Ensaio Operacional 3 - Dezembro 2025
Documentos relacionados ao ensaio operacional que será realizado em Dezembro de 2025 com testes focados no operacional, fora os requisitos tecnicos ja testados
# Escopo
## Objetivo
Executar ensaio operacional no IEAv (15 a 17 de dezembro de 2025), com foco em validação de procedimentos de contingência, integração de restrições dinâmicas e avaliação da reação dos provedores diante de eventos simulados.
## Tópicos Principais
### Testes Operacionais
- **Check-in / Check-out**
- Não permitido por telefone ou comunicação informal.
- Definir processo padronizado.
- **Alertas e Geografia de Voo**
- Notificação automática ao sair da área de voo (avaliar uso de Remote ID).
- Identificação de drones com Remote ID que entram na área.
- Resposta operacional do provedor diante dessas situações.
- **Restrições Dinâmicas**
- Criação de restrição parcial com OIR ativa → ações possíveis:
- Sair da área, cancelar voo ou reagir em tempo adequado.
- Simulação de pouso de helicóptero → restrição automática temporária.
- Avaliar tempo de reação dos provedores (cronometração) para agir após emergencia.
- **Condições de Operação**
- Proibir pouso no mesmo ponto de decolagem em caso de restrição.
- Testar Geo Fence → verificar se provedores cumprem restrições e se todas as OIRs estão dentro da Zona UTM.
- Avaliar resposta a voos fora da Zona UTM.
- Se drone sair da OIR → verificar se provedor cria nova OIR ou declara contingência.
### Features Extras a Testar
- Definir lista de **procedimentos padrão ao encerrar operação** para diferentes tipos de restrições (não assumir apenas “Return to Home”).
- Testar **volumes não nominais**:
- Como provedores lidam com sua criação e gerenciamento.
- \[NÃO PRIORIZADO\] - *Inclusão de **detalhes nas restrições** (grau de severidade, ações obrigatórias, manobras seguras permitidas).*
### Requisitos BRAC
- Não é permitido ativar voo em volume não nominal.
- Caso o drone saia da OIR, deve-se calcular área possível e criar automaticamente volume não nominal.
### Observações Gerais
- Necessidade de ensaios mais orgânicos (“vai voando e eu vou avaliando os requisitos”).
- Foco na observação em tempo real da reação dos provedores.
# [WIP] Briefing: BR-UTM Field Test 3
# Briefing: BR-UTM Field Test 3
**Document Version**: 1.0
**Date**: October 6, 2025
---
## 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.
|