Um GNSSA avaliação do receptor deve responder a uma questão de engenharia específica: sob condições controladas e repetíveis, o que o receptor reporta, como a plataforma conectada reage e que evidências sustentam a recuperação após um evento adverso? Um teste de bancada não é uma garantia de desempenho em campo. É um método documentado de comparação para o receptor exato, caminho de antena, firmware, configuração, interfaces e lógica da plataforma em análise.
O Perfil Fundamental de PNT do NIST usa as funções Identificar, Proteger, Detectar, Responder e Recuperar para enquadrar o uso responsável de posicionamento, navegação e tempo (PNT). A Estrutura de Conformidade de PNT Resiliente do Departamento de Segurança Interna dos EUA é baseada em resultados e distingue níveis de resiliência de acordo com a necessidade da aplicação. As melhores práticas do DHS também exigem observáveis de saída bem definidos, relato de adversidades e capacidades de recuperação. Essas referências apoiam um plano de teste baseado em risco; elas não certificam nenhumResiNavproduto nem substituem a documentação atual do produto.
1. Defina a decisão antes de escolher um teste
Comece com a decisão da plataforma que o teste deve apoiar. Exemplos incluem comparar duas configurações de receptor, confirmar se um controlador reconhece uma mudança de status do receptor, verificar se um alarme chega à interface do operador ou documentar as condições necessárias antes de a plataforma retornar ao seu modo normal de navegação.
Escreva a questão de aceitação em termos observáveis. “O receptor é resiliente” não é testável por si só. Uma declaração útil identifica a condição de entrada, a saída do receptor ou a resposta da plataforma a observar, a base de tempo, as transições de estado permitidas e as evidências que serão retidas.
Para responsabilidades de interface, consulte oGNSSguia de compatibilidade do receptore oResiNavCentro de Tecnologia.
2. Congele o artigo de teste e a configuração
Um resultado repetível precisa de um registro de configuração exato. Antes da primeira execução, identifique o modelo do receptor, revisão de hardware, firmware, constelações habilitadas e bandas de frequência, conjunto de mensagens, taxa de atualização, modelo dinâmico, máscara de elevação, saída de tempo, antena, cabo, conector, fonte de alimentação, software de controle e configuração de registro.
Registre cada mudança entre execuções. Se firmware, ganho da antena, perda de cabo, taxa de interface ou filtragem da plataforma mudarem, trate o resultado como uma nova configuração em vez de combiná-lo com a linha de base anterior. Armazene exportações de configuração onde o receptor as suportar e retenha capturas de tela ou transcrições de comandos apenas quando não exporem credenciais.
3. Estabeleça uma linha de base limpa
A execução da linha de base mostra se a bancada, cabeamento, energia e sistema de registro estão estáveis antes de uma condição adversa ser introduzida. Capture o status do receptor, constelações e sinais rastreados, estado da solução relatado, status de tempo, idade da mensagem de saída, erros de interface, eventos de energia e a fonte de navegação selecionada pela plataforma.
Use uma fonte de sinal documentada ou uma configuração de recepção legal adequada para a instalação. Observe o estado de calibração do equipamento de teste, atenuação, perdas de distribuição, referência de relógio e condições de RF ambiente. Uma linha de base que já contenha redefinições, mensagens perdidas ou energia instável não pode ser usada para atribuir comportamento posterior à condição de teste pretendida.
4. Separe observáveis do receptor das conclusões da plataforma
As melhores práticas do DHS recomendam que o equipamento de usuário PNT exponha observáveis e informações de estado adequados para teste e avaliação, incluindo anomalias ou ameaças detectadas onde o equipamento suportar tal relatório. Capture as saídas documentadas do receptor sem inventar significados para campos não documentados.
- tipo de solução, validade e status relacionado à integridade;
- sinais rastreados, medições ou indicadores de potência de RF relatados quando disponíveis;
- idade da mensagem, sequência e intervalo de atualização;
- status de tempo e relação com 1PPS quando usado;
- alarmes do receptor, redefinições e estados de readquisição;
- serial, Ethernet ou outros erros de interface;
- seleção de fonte da plataforma, modo, alarme e notificação ao operador.
Um alarme da plataforma é evidência de uma decisão da plataforma, não prova da causa de RF. Da mesma forma, um campo de status do receptor não prova que o controlador consumiu ou agiu corretamente sobre ele.
5. Construir um registro de eventos alinhado no tempo
A recuperação não pode ser medida de forma confiável quando a fonte de sinal, o receptor, o controlador e a interface do operador usam relógios não relacionados. Defina a escala de tempo do teste, a resolução de timestamp e o método de sincronização antes da coleta. Retenha os timestamps originais e documente qualquer alinhamento ou reamostragem posterior.
Coloque marcadores de evento no início e no fim de cada condição controlada. Correlacione-os com o status do receptor, entrega de mensagens, decisões do controlador, sensores complementares e alarmes do operador. Se a plataforma usa GPS tempo, UTC, um relógio local ou uma fonte de tempo de rede, documente a conversão e os deslocamentos conhecidos.
6. Usar condições adversas controladas e legais
GPS.gov afirma que o uso intencional de dispositivos de interferência é ilegal nos Estados Unidos, e restrições semelhantes se aplicam em muitas jurisdições. Nunca irradie um jammer ou sinal de spoofing não autorizado em um ambiente aberto. Conduza testes de adversidade de RF somente em uma instalação autorizada e controlada, usando geração de sinal, blindagem, injeção conduzida ou métodos de simulação aprovados.
As condições adversas devem ser rastreáveis e repetíveis. Exemplos podem incluir uma interrupção de sinal documentada, perfil de atenuação, desconexão de interface, evento de energia, sequência de mensagens inválida ou atrasada, ou entrada simulada definida por um vetor de teste aprovado. A condição selecionada deve corresponder à questão de engenharia; nem todo receptor ou plataforma deve ser exposto a todos os cenários.
7. Medir detecção e resposta separadamente
A detecção é o intervalo entre o marcador de evento definido e uma indicação documentada do receptor ou da plataforma. A resposta é a ação subsequente, como rejeitar a entrada, mudar a fonte, limitar a operação, notificar o operador ou entrar em um estado seguro.
Relate ambos os intervalos com a configuração associada e o método de observação. Não publique um único número de tempo como uma especificação universal do produto. O valor pode depender da condição do sinal, das configurações do receptor, da taxa de mensagens, da latência da interface, da lógica do controlador e dos filtros de persistência da própria plataforma.
8. Defina a recuperação antes de executar o teste
A recuperação é mais do que a primeira coordenada válida após um evento. A orientação do DHS descreve a recuperação como a restauração da operação e do desempenho nominais após um evento adverso. Para um teste de plataforma, defina as condições do receptor e da plataforma que devem ser satisfeitas antes que o uso normal seja retomado.
- status do receptor e estado do tempo;
- entrega estável de mensagens por um período de observação especificado;
- saúde da interface e ausência de redefinições repetidas;
- concordância com sensores complementares onde o sistema os utiliza;
- seleção de fonte e estado de modo do controlador;
- reconhecimento de alarme e evidência de evento retida.
Registre a reaquisição, a estabilização e a reentrada na plataforma como eventos separados. Isso evita que uma saída de curta duração seja confundida com um retorno controlado ao serviço.
9. Crie uma matriz de evidências de teste de bancada
| Grupo de evidências | Registro para cada execução | Pergunta respondida |
|---|---|---|
| Configuração | Receptor, firmware, antena, cabo, bandas, interfaces e compilação da plataforma | A configuração pode ser reproduzida? |
| Linha de base | Fonte de sinal, estado do receptor, status de tempo, energia e saúde da interface | A bancada estava estável antes do evento? |
| Condição adversa | Método autorizado, marcadores de evento, nível ou perfil e duração | Qual condição de entrada foi realmente aplicada? |
| Detecção | Campos do receptor, alarmes da plataforma e carimbos de tempo | Quando a condição foi reconhecida? |
| Resposta | Seleção de fonte, modo de controle, aviso ao operador e ação de segurança | A plataforma seguiu sua lógica aprovada? |
| Recuperação | Reaquisição, observação estável, limpeza de alarmes e critérios de retorno | O retorno ao serviço foi controlado? |
10. Compare execuções sem exagerar o resultado
Use a mesma configuração, perfil de eventos, referência de tempo e regras de aceitação para execuções repetidas. Relate a distribuição das observações, não apenas a melhor execução. Mantenha execuções falhas e inconclusivas com seus códigos de motivo. Se uma execução for excluída, documente a exclusão antes de revisar o resultado.
Uma comparação em bancada apoia uma revisão de engenharia para a configuração testada. Ela não estabelece desempenho para outra posição de antena, cabo, receptor, firmware, plataforma, ambiente de RF ou política operacional. A verificação em campo permanece necessária para a instalação alvo.
11. Converta os resultados em integração e RFQ entradas
Forneça o modelo do receptor e a documentação, constelações e bandas, restrições de antena e cabo, energia e interfaces, mensagens necessárias, saídas de tempo, lógica do modo de plataforma, perguntas de aceitação e formato de evidência. Indique se a necessidade é uma revisão de integração em nível de antena, terminal ou sistema.
Navegue pelo ResiNav catálogo de produtos, em seguida, use o RFQ formulário para solicitar uma revisão de engenharia. A compatibilidade do produto e a adequação à implantação devem ser confirmadas contra a documentação atual do produto e a plataforma alvo.
Perguntas frequentes
Um teste de bancada bem-sucedido prova a resiliência em campo?
Não. Ele documenta o comportamento para a configuração testada e condições controladas. Instalação, ambiente de RF, firmware, configurações do receptor e lógica da plataforma podem alterar o resultado, portanto, a verificação em campo permanece necessária.
O tempo de recuperação deve ser medido desde o fim da interferência até a primeira saída de posição?
Não por si só. Registre a reaquisição do receptor, o status estável, a entrega da interface, a seleção da fonte da plataforma e a condição aprovada de retorno ao serviço como eventos separados.
Um jammer de ar livre pode ser usado para teste de receptor?
Nenhum sinal de interferência ou spoofing não autorizado deve ser irradiado. Use uma instalação legal e controlada e um método aprovado conduzido, blindado, simulado ou de vetor de teste.
O que um OEM deve fornecer para uma avaliação de receptor?
Forneça o receptor e o firmware, constelações e bandas, antena e cabo, alimentação e interfaces, observáveis necessários, lógica da plataforma, condições de teste autorizadas, perguntas de aceitação e o formato de evidência exigido.
Referências de engenharia
- NIST: Uso Responsável de Serviços de Posicionamento, Navegação e Tempo
- NISTIR 8323 Rev. 1: Perfil Fundamental de PNT
- DHS: Estrutura de Conformidade de PNT Resiliente
- DHS: Melhores Práticas para PNT Resiliente
- GPS.gov: Informações sobre GPS Interferência
Próximo passo
Para revisar os requisitos de receptor, antena, interface e evidências para uma avaliação controlada, solicite uma ResiNav revisão de engenharia.
PRÓXIMA ETAPA
Transforme as informações disponíveis da plataforma em uma revisão de engenharia.
Use o centro de Tecnologia para orientar a discussão, analise os cenários de aplicação relevantes e envie então os detalhes disponíveis da plataforma e do receptor para confirmação.