Onde se situa o Kshana
O Kshana é um motor aberto e reprodutível de evidências de resiliência de PNT (posicionamento, navegação e temporização). Descreve-se um cenário — os sensores ou relógios, uma falha de GNSS (global navigation satellite system), um ataque de jamming ou spoofing, um orçamento — e ele indica quão bem o tempo e a posição se mantêm, pontuados face a figuras de mérito operacionais (FoM). Cada capacidade por trás dessas figuras é rotulada numa matriz verificada por máquina como VALIDATED (verificada face a uma referência independente externa), MODELLED (internamente consistente, não verificada externamente) ou PARTNER (da responsabilidade de um parceiro de hardware). Esta página diz onde o Kshana se destaca, para que serve e o que não é.
Onde se destaca: temporização e holdover para infraestruturas críticas#
A parte do motor melhor validada é a temporização. As redes de telecomunicações, as redes elétricas e as plataformas financeiras obtêm o seu tempo do GNSS, e cada uma tem de dimensionar o holdover: durante quanto tempo um relógio local pode funcionar livremente através de uma perda de GNSS antes de o seu erro de tempo ultrapassar o orçamento.
- O que é VALIDATED. Os estimadores de estabilidade de frequência de que se constrói uma resposta de holdover — desvio de Allan (ADEV), desvio de Allan modificado (MDEV), desvio de tempo (TDEV), erro máximo de intervalo de tempo (MTIE) e o estimador Theo1 de gama alargada — são verificados face a desvios de referência do Stable32, à biblioteca independente
allantoolse a um relógio de césio medido real. O cálculo da variância de deriva em holdover e a sua inversão para um tempo de holdover são verificados face ao SciPy. ConsulteVERIFICATION-MATRIX.mdpara cada linha, o seu teste e a sua referência independente. - O que continua MODELLED. Os patamares de ruído por classe de relógio (por exemplo o patamar de longo prazo de uma dada classe de oscilador) determinam a resposta para um relógio estável, e são valores representativos, não medições do seu dispositivo. Forneça patamares medidos para um número que pretenda defender.
- Unidades de telecomunicações. O tipo de cenário
telecom-timingcomunica MTIE e TDEV, verifica-os face às máscaras do Setor de Normalização das Telecomunicações da União Internacional das Telecomunicações (ITU-T) — G.8272 para um relógio de tempo de referência primário (PRTC), G.8272.1 para um PRTC melhorado (ePRTC), G.8273.2 para um relógio de fronteira de telecomunicações (T-BC) e G.8271.1 para os limites da rede no ponto de referência C — e comunica durante quanto tempo um holdover se mantém dentro de cada orçamento de erro de tempo. ConsulteTELECOM-TIMING.md.
O que o torna diferente#
A física e as normas não são a diferença: a propagação Simplified General Perturbations 4 (SGP4), o desvio de Allan, os referenciais e a diluição de precisão estão disponíveis, gratuitos e corretos, noutras bibliotecas, e o Kshana verifica-se face a várias delas. A diferença é a disciplina de evidências:
- Aberto. O motor está sob a GNU Affero General Public License (AGPL), pelo que qualquer pessoa o pode ler e voltar a executar. Existe uma licença comercial para integração fechada.
- Reprodutível. Um resultado é determinado por
scenario + seed + engine version, bit a bit, e uma execução pode ser partilhada como uma ligação para o playground no navegador. - Com proveniência rotulada. Cada parâmetro de sensor é rastreado até uma fonte publicada (
PROVENANCE.md), e cada capacidade traz o seu nível VALIDATED / MODELLED / PARTNER. Uma salvaguarda de integração contínua (CI) recusa uma linha VALIDATED sem referência independente externa, pelo que uma autoverificação interna não pode ser apresentada como validação.
Não encontrámos outra ferramenta aberta que combine isto em holdover, integridade, seguimento inercial e sensores quânticos, mas uma pesquisa que não encontra nada não é prova de que nada exista; não afirmamos ser a única.
Quântico: um método de compromisso neutro, resultados rotulados MODELLED#
O Kshana compara relógios e sensores inerciais quânticos e clássicos no mesmo cenário com o mesmo código: cada dispositivo é um modelo de erro, e o motor não sabe qual deles é "quântico". Trate-o como um método neutro de compromisso quântico versus clássico cujos resultados são rotulados MODELLED. A maioria das entradas são coeficientes de Allan/orçamento de ruído publicados; o acelerómetro de interferómetro de átomos frios tem uma camada de princípios fundamentais que deriva o seu coeficiente de ruído. Os dados medidos de desvio de Allan de um parceiro podem ser introduzidos através do tipo quantum-trade, que é o caminho para promover os valores de um dispositivo específico. Consulte QUANTUM.md e QUANTUM-MODELS.md.
Lunar, cislunar e espaço profundo: mantidos, não em destaque#
O conjunto lunar / cislunar (monitorização de integridade lunar, o núcleo de três corpos Terra–Lua, escalas de tempo lunares, análise de volume de serviço) e o motor de navegação radiométrica de espaço profundo são capacidades mantidas. A maioria das suas linhas é MODELLED, e já existem ferramentas dedicadas que servem a navegação lunar, pelo que são oferecidas como capacidades do mesmo motor, cada uma com o seu nível, e não como destaque.
O resto do motor#
O mesmo motor, com os mesmos níveis, abrange também:
- PNT em órbita terrestre baixa (LEO), de ponta a ponta. Projeto de sinal (
leo-signal), passagem e balanço de ligação por banda (leo-pass), mensagem de navegação difundida (leo-navmsg), posicionamento fundido em órbitas terrestres média e baixa (leo-pvt), convergência de posicionamento preciso de ponto (PPP) com aumentação por LEO (leo-ppp), posicionamento a partir de uma rede não terrestre 5G (ntn-positioning), eleo-pnt-chain, que passa a saída de cada fase à seguinte para um só sistema. - Espetro. Uma cascata de densidade espetral de potência em banda L (e em ultra-alta frequência (UHF), banda S e banda C) sob uma cronologia de jammer programada, com relação jammer-sinal por banda e densidade efetiva de portadora-ruído (
spectrum), e entrada e saída de gravações Signal Metadata Format (SigMF). - O sistema solar e qualquer corpo central. Posições e constantes físicas dos planetas e das principais luas (
solar-system), posicionamento em torno de qualquer desses corpos (body-pnt), e projeto de constelações Walker e de posições publicadas com mapas de cobertura e de diluição de precisão em torno de qualquer um deles (constellation-design). - Campanhas. Tipos existentes encadeados numa cronologia partilhada, varridos, executados como conjuntos Monte Carlo com semente, ou executados lado a lado sob condições partilhadas (
campaign). - Saídas. Cada execução escreve um documento de resultado, um gráfico e um relatório em HTML (HyperText Markup Language) e JSON (JavaScript Object Notation);
--animateescreve uma animação SVG (Scalable Vector Graphics), HTML ou em sequência de imagens;--exportescreve efemérides CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON ou STK (Systems Tool Kit) para os tipos que situam coisas na Terra, e SigMF paraspectrum.
A maioria destas linhas é MODELLED; a matriz de verificação nomeia as poucas que são VALIDATED (por exemplo as recomendações da União Internacional das Telecomunicações sobre chuva e cintilação, o algoritmo de efemérides difundidas do Galileo, a verificação de trama CRC-24Q (verificação de redundância cíclica de 24 bits) e o resolvedor planetário de tempo de luz).
O que o Kshana não é#
- Não é um simulador de sinais de radiofrequência (RF) nem uma plataforma de hardware-in-the-loop (HIL). O Kshana não aciona nenhum hardware de rádio e não transmite nada. A maior parte funciona ao nível de modelos de erro e balanços de ligação, antes de se comprar hardware ou tempo de laboratório. Ao nível do sinal é apenas software: a camada IQ GNSS (
iq) escreve ficheiros de amostras IQ (em fase/quadratura) em banda de base de sinais GNSS legítimos para recetores de software e executa neles o seu próprio recetor de software; a secção[iq]do tipospectrum(desde a 0.29.0) escreve um instantâneo SigMF (Signal Metadata Format) do seu modelo analítico que inclui os jammers configurados (jammers semelhantes a ruído banda a banda, tons e chirps como formas de onda); espoof_capturesoma em memória um sinal autêntico e uma réplica de spoofer para testar a captura das malhas, sem a escrever. Testar um recetor de hardware face a um estímulo de RF real é tarefa de um simulador de RF. - Não é um substituto de MATLAB/Simulink, STK ou Orekit. Situa-se a par deles. Lê e escreve os formatos de intercâmbio que eles usam — mensagens de efemérides orbitais CCSDS (Consultative Committee for Space Data Systems), órbitas precisas SP3 (Standard Product 3), RINEX (Receiver Independent Exchange Format) — escreve efemérides CZML, KML, GeoJSON e STK para os seus visualizadores, e o seu modelo numérico de forças é verificado de forma cruzada face ao Orekit em vez de ser oferecido em seu lugar.
- Não é um motor de processamento GNSS de fase da portadora nem um serviço de posicionamento (consulte abaixo).
- Não é uma entidade certificadora. Um rótulo VALIDATED significa que uma capacidade coincide com uma referência independente externa; não é uma certificação de nenhum produto ou operador.
O que o Kshana é, e não é, ao lado de um motor de processamento GNSS#
O Kshana não é um motor de processamento GNSS de fase da portadora, e nenhum tipo de cenário é um serviço de posicionamento. Tem, contudo, um pé no domínio das medições, como código de biblioteca em que o estudo de desempenho se apoia e que é verificado face a referências independentes. O posicionamento cinemático em tempo real (RTK) de linha de base curta com fixação de inteiros LAMBDA (least-squares ambiguity decorrelation adjustment) executa-se sobre observações RINEX reais de dupla frequência, tal como um filtro de posicionamento preciso de ponto (PPP) estático de ambiguidades flutuantes com órbitas e relógios finais do IGS, e o relógio do recetor que esse filtro estima é uma solução de tempo face ao relógio final de estação do IGS. Cada um dos três é uma linha VALIDATED da matriz de verificação, face aos dados de estações do IGS que aí nomeia, e cada um executa-se em janelas de observação estáticas e curtas, não como um serviço em contínuo com resolução de ambiguidades em linhas de base longas, suavização por portadora ou um rover cinemático. O tipo leo-ppp executa um filtro PPP de ambiguidades flutuantes sobre código e fase da portadora, mas sobre medições que simula por si próprio, para estudar o tempo de convergência com e sem aumentação por LEO; não processa um ficheiro de observações. O tipo pvt (posição, velocidade e tempo) resolve a posição de um recetor a partir de pseudodistâncias de código RINEX reais mais efemérides difundidas, validado face a uma coordenada levantada do International GNSS Service (IGS) (estação ABMF, 2018-05-13) com 5,7 m de RMS (raiz do erro quadrático médio) 3-D / 1,1 m horizontal. Mas o produto é o estudo de desempenho, não o serviço de posicionamento, e o enquadramento que se segue destina-se a poupar a um potencial utilizador a desilusão de ter escolhido a ferramenta errada.
| Kshana | Um motor de processamento GNSS (RTKLIB, uma biblioteca aberta de posicionamento cinemático em tempo real; gLAB, o conjunto de ferramentas de laboratório GNSS do grupo gAGE da Universidade Politécnica da Catalunha) | |
|---|---|---|
| Entrada | um cenário: modelos de erro de sensores, janelas de falha, geometria — ou, para pvt, um ficheiro real de observações RINEX mais a navegação difundida |
observações GNSS reais (RINEX), efemérides, correções |
| Saída | FoM de desempenho: holdover, erro de temporização/posição, disponibilidade, limites de integridade/segurança — mais uma posição de posicionamento de ponto único (SPP) por código a partir do tipo pvt |
uma solução de posição/velocidade/tempo (SPP, PPP, RTK) |
| Pergunta a que responde | "quão boa seria esta arquitetura, e onde falha?" | "dadas estas medições, onde estou agora?" |
| Sensores quânticos / óticos | modelados como modelos de erro (relógios óticos, unidade de medição inercial (IMU) de átomos frios, transferência ótica de tempo), resultados rotulados MODELLED | não modelado |
| Processamento de observações reais | SPP por código a partir de observações RINEX reais (pvt, ao nível do metro); RTK de linha de base curta com LAMBDA e PPP estático de ambiguidades flutuantes sobre fase da portadora real, como código de biblioteca verificado face a estações do IGS (VALIDATED, janelas estáticas e curtas, não um serviço em contínuo); mais geometria / diluição de precisão (DOP) / disponibilidade |
a competência central, até ao PPP/RTK de fase da portadora |
| Instalar | zero — executa-se num separador do navegador (WebAssembly) | compilação nativa / cadeia de ferramentas |
Complementares, não concorrentes — RTKLIB e gLAB#
O RTKLIB e o gLAB são conjuntos de processamento GNSS maduros e amplamente usados. Recebem medições reais e produzem uma solução de posicionamento (SPP/PPP/RTK; o gLAB é também uma excelente ferramenta de ensino com uma forte herança na Agência Espacial Europeia (ESA) e no European Geostationary Navigation Overlay Service (EGNOS)). O Kshana não os substitui e não tenta fazê-lo. O seu percurso de observações é estreito: posicionamento de ponto único por código (pvt) e, como código de biblioteca verificado, RTK de linha de base curta com fixação de inteiros LAMBDA e um filtro PPP estático de ambiguidades flutuantes sobre observações reais de dupla frequência, cada um VALIDATED face a dados de estações do IGS (o filtro PPP também face a uma execução do RTKLIB com as mesmas entradas). Não tem suavização por portadora, nem processamento cinemático ou em contínuo, nem resolução de ambiguidades em linhas de base longas, e pvt não estima a troposfera nem a ionosfera — aplica os modelos de troposfera de Saastamoinen/Niell e a combinação livre de ionosfera L1/L2, não os resolve como estados.
O pipeline é complementar:
- RTKLIB / gLAB respondem a "onde estou, a partir destes sinais?"
- O Kshana responde a "durante quanto tempo mantenho uma boa resposta quando esses sinais cessam — e quanto me proporciona um melhor relógio ou sensor inercial, clássico ou quântico?"
Um fluxo de trabalho natural usa um motor de processamento para o segmento com GNSS disponível e o Kshana para estudar o comportamento de holdover e o espaço de compromissos de sensores à sua volta. Se precisar de um serviço de posicionamento por fase da portadora — PPP cinemático ou RTK, linhas de base longas, resolução de ambiguidades em rede — use o RTKLIB ou o gLAB; se precisar de evidências reprodutíveis e rotuladas sobre resiliência e holdover, é para isso que o Kshana foi construído.
Um nível de instalação zero no navegador#
A maioria das ferramentas de simulação neste domínio (RTKLIB, gLAB, a General Mission Analysis Tool (GMAT), Orekit, STK) exige uma instalação nativa ou uma licença, e uma curva de aprendizagem antes do primeiro resultado. O Kshana compila para WebAssembly e executa-se inteiramente no navegador — o playground carrega um cenário resolvido, executa o motor real do lado do cliente (nada é enviado) e mostra o resultado em segundos. Os cursores guiados e os cenários de um clique significam que o primeiro resultado útil não precisa de TOML (Tom's Obvious Minimal Language, o formato de ficheiro de cenário) nem de cadeia de ferramentas.
Esse nível de instalação zero é uma posição deliberada:
- Alcance — um revisor, estudante ou responsável de aquisições pode experimentar o motor verdadeiro a partir de uma ligação, em qualquer dispositivo, sem configuração.
- Reprodutibilidade — o mesmo motor que é distribuído no navegador é a biblioteca distribuída no crates.io, no Python Package Index (PyPI) e no npm; um resultado é reproduzível a partir de
scenario + seed + engine version, e uma execução pode ser partilhada como um URL (endereço web). - Honestidade — executar o motor por si, às claras, é o contrapeso mais forte a "confie nos números": o nível do navegador é a superfície de auditoria.
O nível do navegador não faz do Kshana um substituto de um conjunto de processamento de secretária — torna a questão do estudo de compromissos de desempenho acessível a pessoas que nunca instalariam um.
Ver também#
CAPABILITY.md— o mapa de âmbito linha a linha (o âmbito completo e os resíduos do resolvedorpvtestão na linha Processamento GNSS / PNT).VALIDATION.md— o que está validado, com evidências.TELECOM-TIMING.md— o tipo de temporização de telecomunicações e as suas máscaras.GLOSSARY.md— definições em linguagem simples dos termos aqui usados.web/README.md— o playground no navegador.