Galileo OSNMA e HAS: il GNSS europeo per sistemi embedded

Galileo OSNMA e Galileo HAS stanno cambiando il modo in cui un sistema embedded può utilizzare la navigazione satellitare. Non si tratta più soltanto di calcolare delle coordinate: un ricevitore compatibile può verificare l’autenticità dei messaggi Galileo, utilizzare correzioni ad alta precisione e contribuire a un’architettura PNT più resiliente per droni, robot, veicoli, sistemi industriali e infrastrutture distribuite.

Quando parliamo genericamente di “GPS”, in realtà ci riferiamo spesso a un ricevitore GNSS capace di utilizzare più costellazioni satellitari. Il GPS è il sistema statunitense, mentre Galileo è il Global Navigation Satellite System sviluppato dall’Unione Europea. A questi si aggiungono altri sistemi globali e regionali, normalmente utilizzati insieme dai ricevitori moderni per aumentare disponibilità e qualità della soluzione.

La disponibilità di Galileo consente all’Europa di disporre di una propria infrastruttura per fornire servizi di Positioning, Navigation and Timing, indicati con la sigla PNT. Il valore tecnologico non deriva però soltanto dall’esistenza di una costellazione europea: servizi come OSNMA e HAS introducono funzioni specifiche di autenticazione e alta precisione che possono essere integrate all’interno di prodotti embedded reali.

Per una panoramica introduttiva sulle costellazioni, sui messaggi NMEA, sui moduli elettronici e sulle tecniche di posizionamento è disponibile anche il nostro approfondimento su GPS e GNSS per sistemi embedded. In questo articolo ci concentriamo invece su Galileo OSNMA, Galileo HAS, development board, Linux, SDR e progettazione di sistemi PNT resilienti.

Dal GPS al PNT europeo

La navigazione satellitare viene spesso associata alla visualizzazione di un punto su una mappa. In realtà i sistemi GNSS forniscono tre risorse differenti: posizione, navigazione e tempo.

La posizione descrive dove si trova il ricevitore. La navigazione comprende anche velocità, direzione e variazione della traiettoria. Il riferimento temporale permette invece di sincronizzare apparati collocati in luoghi differenti.

Questa combinazione viene indicata con la sigla PNT, Positioning, Navigation and Timing.

Il PNT viene utilizzato in smartphone e navigatori, ma anche in telecomunicazioni, reti energetiche, sistemi finanziari, mezzi agricoli, droni, robot mobili, trasporto marittimo, logistica e acquisizione industriale distribuita.

La dipendenza da queste informazioni rende strategica la disponibilità di un’infrastruttura europea. Se una rete, un veicolo o un sistema automatico dipende da posizione e tempo, il GNSS non rappresenta più una funzione accessoria: diventa parte dell’architettura operativa.

Autonomia europea non significa però necessariamente configurare ogni ricevitore affinché utilizzi soltanto Galileo. Un dispositivo multi-GNSS può combinare Galileo, GPS e altre costellazioni, migliorando il numero di satelliti visibili e la geometria della soluzione.

Il valore di Galileo consiste nella disponibilità di un’infrastruttura europea completa sulla quale costruire servizi europei specifici, senza dipendere integralmente da sistemi controllati da altri Stati.

Il problema non è soltanto sapere dove siamo

Un ricevitore GNSS tradizionale acquisisce i segnali provenienti dai satelliti, decodifica i messaggi di navigazione e utilizza le informazioni ottenute per calcolare posizione, velocità e tempo.

In molte applicazioni il risultato viene utilizzato direttamente: il modulo restituisce le coordinate e il firmware le trasferisce all’applicazione, a un server o a un sistema di controllo.

Questo approccio presuppone però che il dato ricevuto sia attendibile.

Un segnale GNSS può essere degradato da ostacoli, edifici, vegetazione, riflessioni, rumore prodotto dall’elettronica e interferenze provenienti da altre sorgenti radio.

Il jamming consiste nell’introdurre interferenze che riducono o impediscono la ricezione. Lo spoofing utilizza invece segnali falsi o manipolati per indurre il ricevitore a calcolare una posizione o un riferimento temporale non corretti.

Le conseguenze dipendono dall’applicazione. Un errore su un’applicazione cartografica può rappresentare un inconveniente. Lo stesso errore su un drone, un robot, un sistema di sincronizzazione o un mezzo autonomo può modificare il comportamento dell’intero sistema.

La domanda progettuale diventa quindi:

“Il dispositivo conosce la propria posizione, ma come può valutare se le informazioni utilizzate sono attendibili?”

Galileo OSNMA: autenticare il messaggio di navigazione

Galileo Open Service Navigation Message Authentication, indicato con la sigla OSNMA, è una funzione gratuita del Galileo Open Service.

Il servizio iniziale OSNMA è stato dichiarato operativo il 24 luglio 2025. Nel luglio 2026, a un anno dall’attivazione, EUSPA ha documentato la progressiva integrazione della tecnologia in ricevitori professionali destinati a timing, trasporti, applicazioni marittime e dispositivi connessi.

OSNMA consente a un ricevitore compatibile di verificare che il messaggio di navigazione ricevuto provenga effettivamente dal sistema Galileo e non sia stato modificato.

Le informazioni di autenticazione vengono trasmesse all’interno di campi dedicati del messaggio Galileo I/NAV sulla componente E1-B. Il ricevitore deve estrarre questi dati, elaborarli attraverso le funzioni crittografiche previste e verificare la catena di autenticazione.

Il protocollo utilizzato è basato su TESLA, Timed Efficient Stream Loss-Tolerant Authentication. Il principio prevede l’utilizzo di codici di autenticazione e la divulgazione ritardata delle chiavi necessarie alla loro verifica.

Il ricevitore memorizza quindi i messaggi e i relativi tag crittografici. Quando la chiave prevista viene resa disponibile, può verificarne l’autenticità e utilizzarla per controllare i dati ricevuti in precedenza.

Questo ritardo è una caratteristica del protocollo e spiega perché la disponibilità di una soluzione di posizione e la disponibilità di dati autenticati non coincidano necessariamente nello stesso istante.

Cosa cambia realmente nel firmware con Galileo OSNMA

Integrare OSNMA non significa semplicemente leggere un nuovo flag dal modulo GNSS.

Un ricevitore compatibile deve estrarre le informazioni OSNMA dal messaggio Galileo, eseguire le operazioni crittografiche previste, disporre di una conoscenza iniziale sufficientemente affidabile del Galileo System Time e mantenere integro il materiale crittografico utilizzato per la verifica.

Il materiale iniziale comprende elementi come la radice del Merkle tree e le chiavi pubbliche certificate. Durante il ciclo di vita del dispositivo deve inoltre essere prevista la possibilità di aggiornare o rinnovare il materiale attraverso i meccanismi definiti dal servizio.

Questi requisiti coinvolgono differenti parti del prodotto:

ricevitore GNSS → gestione delle chiavi → riferimento temporale → firmware → diagnostica → logica applicativa

Il firmware deve inoltre distinguere più stati operativi. Una posizione può essere disponibile mentre il processo di autenticazione è ancora in corso. In altri casi il ricevitore può rilevare un’autenticazione fallita, informazioni incomplete oppure una qualità radio insufficiente.

Il comportamento corretto dipende dal rischio dell’applicazione.

Un tracker logistico può continuare a registrare la posizione aggiungendo un indicatore di affidabilità ridotto. Un robot industriale, un mezzo autonomo o un drone potrebbero invece dover limitare alcune funzioni oppure utilizzare temporaneamente altri sensori.

Per questo un prodotto professionale non dovrebbe memorizzare soltanto latitudine e longitudine. Il logging può includere stato OSNMA, accuratezza stimata, costellazioni utilizzate, qualità dei segnali, indicatori di interferenza e motivo dell’eventuale passaggio in modalità degradata.

OSNMA autentica i dati, non automaticamente la posizione

Uno degli aspetti più importanti è utilizzare la terminologia corretta.

OSNMA realizza una data authentication: autentica specifiche informazioni contenute nel messaggio di navigazione Galileo. Non autentica direttamente tutte le misure di distanza rispetto ai satelliti e non certifica automaticamente l’intera soluzione PVT calcolata dal ricevitore.

È quindi corretto parlare di:

“soluzione calcolata utilizzando dati di navigazione autenticati”

Non è invece corretto trasformare automaticamente questo concetto in:

“posizione sicuramente autentica e immune da spoofing”

OSNMA aumenta la capacità del sistema di riconoscere dati non autenticati e rende più complessa la costruzione di un attacco credibile, ma non impedisce il jamming e non elimina ogni possibile forma di spoofing.

EUSPA prevede ulteriori evoluzioni. Tra i servizi in sviluppo è presente il Galileo Signal Authentication Service, destinato ad aggiungere capacità di autenticazione a livello del segnale di ranging e a completare la protezione offerta da OSNMA.

OSNMA deve quindi essere considerato un componente importante di una strategia PNT resiliente, non una soluzione isolata capace di risolvere qualsiasi anomalia GNSS.

Dal ricevitore autenticato al PNT resiliente

Un sistema embedded resiliente può combinare più livelli di informazione per valutare la coerenza della navigazione.

Un ricevitore multi-costellazione aumenta il numero di satelliti utilizzabili. La ricezione multi-banda può ridurre alcuni errori e migliorare il comportamento in presenza di multipath. OSNMA aggiunge l’autenticazione dei messaggi Galileo. Gli indicatori interni del ricevitore possono segnalare rumore, interferenze o variazioni anomale.

A questi dati possono essere aggiunti sensori indipendenti:

GNSS → IMU → magnetometro → barometro → odometria → visione → logica di fusione e integrità

Consideriamo un drone che riceve una posizione incompatibile con accelerazione, orientamento e quota barometrica. Nessun singolo sensore dimostra automaticamente la presenza di spoofing, ma la divergenza tra sorgenti può generare un indicatore di anomalia.

Su un robot terrestre la traiettoria GNSS può essere confrontata con encoder e odometria. Su un veicolo possono essere disponibili dati delle ruote, heading, mappe e sensori inerziali. In un sistema statico si possono invece monitorare variazioni impossibili della posizione e del riferimento temporale.

La sensor fusion non serve soltanto a migliorare la precisione. Può anche permettere al sistema di continuare a funzionare durante una breve indisponibilità del GNSS.

Questo funzionamento temporaneo viene spesso indicato come dead reckoning. La sua efficacia dipende dalla qualità dei sensori, dalla calibrazione, dalla durata della perdita GNSS e dalla dinamica del mezzo.

Galileo HAS: posizionamento europeo ad alta precisione

Galileo non introduce soltanto servizi di autenticazione.

Il Galileo High Accuracy Service, indicato con la sigla HAS, è un servizio gratuito e disponibile globalmente per applicazioni che richiedono prestazioni superiori rispetto al normale Open Service.

HAS utilizza un approccio PPP, Precise Point Positioning. Il servizio distribuisce informazioni precise sulle orbite, sugli orologi satellitari e sui bias necessari per migliorare la soluzione calcolata dal ricevitore.

Le correzioni possono essere ricevute direttamente attraverso il segnale Galileo E6-B oppure via Internet attraverso i servizi del Galileo Service Centre.

EUSPA descrive HAS come un servizio capace di fornire prestazioni di livello decimetrico. Per sfruttarlo non è però sufficiente che il modulo riporti genericamente il supporto a Galileo: il ricevitore, il firmware e l’intera catena RF devono essere compatibili con le modalità di distribuzione utilizzate.

Galileo HAS e RTK non sono la stessa tecnologia

Galileo HAS viene talvolta presentato come un sostituto diretto dell’RTK. In realtà le due soluzioni hanno caratteristiche differenti.

L’RTK utilizza correzioni provenienti da una base locale oppure da una rete di stazioni di riferimento. Può raggiungere precisioni centimetriche e tempi di convergenza molto ridotti, ma richiede la disponibilità delle correzioni e di un canale attraverso il quale distribuirle.

Il PPP utilizza invece correzioni precise applicabili su aree molto più ampie. Non richiede necessariamente una base locale, ma può richiedere un tempo di convergenza superiore prima di raggiungere la precisione prevista.

La scelta dipende quindi dall’applicazione.

Un robot che deve seguire immediatamente una traiettoria con precisione centimetri può richiedere RTK. Un dispositivo installato in un’area remota, priva di una rete locale di correzione, può beneficiare di un servizio PPP globale. In altri casi si possono utilizzare architetture ibride.

I test del 2026 mostrano il potenziale di Galileo HAS

Nel 2026 EUSPA ha pubblicato i risultati di una sperimentazione di Galileo HAS in agricoltura di precisione.

Nelle specifiche condizioni della campagna, il test ha registrato un errore orizzontale al 95% di circa 5,9 centimetri e un errore verticale al 95% di circa 12,4 centimetri.

I valori sono inferiori ai target di 20 centimetri sul piano orizzontale e 40 centimetri su quello verticale indicati per il servizio.

Questi risultati non devono però essere interpretati come una precisione garantita in qualsiasi ambiente.

Edifici, vegetazione, multipath, geometria satellitare, antenna, qualità del ricevitore, dinamica del mezzo e tempo di convergenza possono modificare sensibilmente la prestazione.

Il dato più interessante è che un servizio europeo gratuito di correzione ad alta precisione sta diventando utilizzabile su ricevitori commerciali e applicazioni reali.

Timing industriale: non basta leggere l’orario NMEA

Un ricevitore GNSS non deve necessariamente essere utilizzato per conoscere una posizione.

I satelliti distribuiscono riferimenti temporali estremamente precisi e un ricevitore può utilizzarli per sincronizzare il proprio clock locale.

Telecomunicazioni, reti elettriche, sistemi finanziari, data logger, gateway industriali e piattaforme di acquisizione distribuita possono dipendere da un riferimento temporale comune.

In un’applicazione professionale non è però sufficiente leggere data e ora da una stringa NMEA.

Diventano importanti l’uscita time pulse o 1PPS, l’offset rispetto alla scala temporale di riferimento, il jitter, la stabilità dell’oscillatore locale e il comportamento di holdover quando il GNSS non è temporaneamente disponibile.

L’holdover indica la capacità del sistema di continuare a fornire un riferimento temporale locale durante una perdita del segnale satellitare. L’incertezza cresce progressivamente in funzione dell’oscillatore e delle condizioni ambientali.

Il software deve quindi distinguere almeno tra:

tempo acquisito → sincronizzazione valida → sorgente autenticata → GNSS degradato → funzionamento in holdover

Prodotti dedicati come u-blox ZED-F9T e il relativo EVK-F9T permettono di sperimentare ricezione GNSS multi-banda, OSNMA e uscita 1PPS attraverso un kit predisposto per applicazioni di timing.

Questo rende il timing un problema di sistema composto da ricevitore, antenna, oscillatore, alimentazione, firmware, distribuzione del segnale e diagnostica.

Sperimentare Galileo con development board commerciali

Per iniziare a lavorare con Galileo non è necessario progettare immediatamente una scheda RF personalizzata.

Le development board permettono di valutare il ricevitore, registrare i dati, confrontare antenne e sviluppare il comportamento del firmware prima di affrontare la PCB definitiva.

La scelta deve però partire dall’obiettivo della prova.

Una scheda economica progettata per GNSS dual-band può essere sufficiente per studiare acquisizione, NMEA, PPS, consumi e integrazione con un microcontrollore. Non significa però che quella stessa scheda supporti OSNMA, HAS, RTK o indicatori avanzati di interferenza.

Allo stesso modo, la presenza della parola Galileo nella scheda tecnica non implica automaticamente il supporto a tutti i servizi Galileo.

Il supporto deve essere verificato sulla variante esatta

Una delle verifiche più importanti riguarda la variante hardware e la versione firmware effettivamente utilizzate.

Una famiglia commerciale può comprendere moduli con funzioni differenti. Anche quando il package e il nome principale sono simili, supporto OSNMA, bande ricevute, HAS, RTK, timing e funzioni di sicurezza possono cambiare.

Nel caso della piattaforma u-blox ZED-X20P, ad esempio, OSNMA è disponibile sulla piattaforma, mentre il supporto Galileo HAS deve essere verificato sulla variante specifica. La versione ZED-X20P-01B è stata presentata nel 2026 proprio con HAS e PPP globale.

Il nome del prodotto non è quindi sufficiente. Prima dell’acquisto o dell’integrazione devono essere verificati:

part number → revisione hardware → versione firmware → bande → servizi Galileo → interfacce → antenna richiesta

Questa verifica evita di costruire il proof of concept su una scheda incapace di esporre le funzioni necessarie all’applicazione.

Una possibile architettura di proof of concept

Un laboratorio Galileo può essere costruito progressivamente, senza iniziare da una scheda personalizzata.

Una prima architettura può essere composta da:

antenna multi-banda → development board GNSS → piattaforma Linux → IMU → logging e dashboard

Il ricevitore fornisce posizione, tempo, qualità della soluzione, stato OSNMA e altri dati disponibili.

L’IMU permette di confrontare accelerazione e rotazione con il movimento calcolato dal GNSS.

La piattaforma Linux raccoglie i dati, registra le sessioni e visualizza in tempo reale lo stato del sistema.

In una seconda fase possono essere aggiunti un modem cellulare, un collegamento LoRa, memoria locale, alimentazione a batteria oppure altri sensori specifici dell’applicazione.

Linux come piattaforma di analisi GNSS

Un computer embedded Linux può trasformare una development board GNSS in un laboratorio portatile.

La piattaforma può acquisire posizione, stato dei satelliti, C/N0, accuratezza stimata, stato OSNMA, informazioni sulle correzioni e dati provenienti da IMU o altri sensori.

Durante una prova su strada, su un drone o su un mezzo industriale, i dati possono essere memorizzati localmente e analizzati successivamente.

Una dashboard può visualizzare in tempo reale:

costellazioni → satelliti → bande → qualità dei segnali → posizione → stato OSNMA → correzioni → sensori

Linux permette inoltre di collegare più interfacce contemporaneamente: USB, UART, Ethernet, CAN, modem cellulare, SDR e dispositivi di misura.

Questo approccio è utile prima della progettazione definitiva perché consente di modificare rapidamente la configurazione, confrontare ricevitori e creare strumenti di diagnostica che potranno essere riutilizzati durante lo sviluppo del prodotto.

Andare più in profondità con una Software Defined Radio

Una development board commerciale esegue internamente gran parte della catena GNSS e restituisce principalmente messaggi, osservabili e risultati già elaborati.

Con una Software Defined Radio è possibile acquisire campioni del segnale e spostare parte dell’elaborazione su un computer.

Il progetto open source GNSS-SDR implementa un ricevitore GNSS software-defined e supporta Galileo OSNMA.

La piattaforma permette di studiare acquisizione, tracking, decodifica del messaggio di navigazione, osservabili e autenticazione con un livello di accesso normalmente non disponibile su un modulo commerciale.

GNSS-SDR può utilizzare OSNMA in modalità di avviso oppure configurare una soluzione che accetti esclusivamente dati autenticati, in funzione della sorgente e della configurazione utilizzata.

Questo non significa che un SDR debba sostituire il ricevitore finale.

Un approccio efficace può utilizzare due livelli:

ricevitore commerciale per il prodotto → SDR per analisi, ricerca e validazione

Registrare i segnali per costruire test ripetibili

La registrazione di campioni RF o dei dati grezzi prodotti dal ricevitore permette di riprodurre più volte la stessa situazione.

Una sessione acquisita durante una prova sul campo può essere analizzata con versioni software differenti oppure utilizzata per confrontare algoritmi e configurazioni senza dover ripetere immediatamente il percorso.

La ripetibilità è importante perché le condizioni satellitari e radio cambiano continuamente.

Un dataset può includere:

campioni IQ → osservabili → messaggi Galileo → PVT → stato OSNMA → IMU → riferimento esterno

Le prove che prevedono la generazione o la ritrasmissione di segnali GNSS via radio devono essere eseguite soltanto in ambienti controllati e schermati. Per normali attività di sviluppo è preferibile utilizzare file IQ, simulatori collegati via cavo o sistemi che non irradino segnali capaci di interferire con ricevitori esterni.

Una buona devboard non corregge una cattiva progettazione RF

Ottenere risultati positivi con una evaluation board non garantisce che il prodotto finale mantenga le stesse prestazioni.

I segnali GNSS ricevuti a terra sono estremamente deboli. Antenna e percorso RF hanno quindi un ruolo determinante.

Devono essere valutati tipo di antenna, bande supportate, piano di massa, posizione sul PCB, contenitore, superfici metalliche, cablaggio, filtri, amplificazione e alimentazione dell’eventuale antenna attiva.

La situazione diventa più complessa quando sullo stesso dispositivo sono presenti LTE, 5G, Wi-Fi, Bluetooth, LoRa o altri trasmettitori.

Per utilizzare Galileo HAS via satellite, ad esempio, il percorso RF deve supportare anche E6-B. Un ricevitore compatibile non può sfruttare correttamente quella banda se antenna, filtri o amplificatori non la lasciano passare.

Anche il rumore prodotto da convertitori switching, display, processori e interfacce ad alta velocità può degradare la ricezione.

Il passaggio dalla development board alla PCB richiede quindi una nuova validazione che includa l’elettronica reale, il contenitore e la posizione di montaggio prevista.

Un proof of concept GNSS si misura, non si giudica da un punto sulla mappa

Visualizzare una posizione apparentemente corretta non è sufficiente per validare un ricevitore o un’architettura PNT.

Una prova professionale deve produrre dati confrontabili ed essere eseguita nelle condizioni in cui il prodotto dovrà realmente funzionare.

I test possono essere statici e dinamici. Devono includere, quando rilevante, aree aperte, zone parzialmente ostruite, edifici, vegetazione, strutture metalliche, movimento, vibrazioni e altre radio presenti sul dispositivo.

Il risultato non dovrebbe essere soltanto una dimostrazione visiva.

Un proof of concept utile deve produrre un report che confronti ricevitori, antenne, configurazioni, firmware e condizioni operative, evidenziando margini e limiti prima della progettazione della scheda definitiva.

Quali applicazioni sono realistiche

Galileo OSNMA, HAS e le tecniche di PNT resiliente possono essere utilizzati in settori differenti, ma ogni applicazione richiede un’architettura specifica.

In un drone, OSNMA può contribuire alla valutazione dell’affidabilità dei dati Galileo, mentre IMU, barometro, magnetometro e sistemi di visione permettono di confrontare il movimento reale con quello dedotto dal GNSS.

In un robot mobile outdoor, RTK o HAS possono essere combinati con odometria, encoder e localizzazione visiva. La logica applicativa deve gestire anche le transizioni tra zone aperte e aree in cui i satelliti sono parzialmente coperti.

In agricoltura di precisione, RTK e Galileo HAS possono essere valutati per guida assistita, georeferenziazione, automazione delle lavorazioni e riduzione delle sovrapposizioni.

In un tracker industriale, posizione e stato di autenticazione possono essere associati a timestamp, eventi, sensori e dati di connettività. Il dispositivo può inviare soltanto le informazioni necessarie attraverso LTE, LoRaWAN o altre reti.

In applicazioni di timing, il dispositivo può essere completamente statico. Il ricevitore viene utilizzato per disciplinare l’orologio locale e sincronizzare sistemi distribuiti.

In ambito marittimo, GNSS multi-banda, OSNMA e indicatori di interferenza possono contribuire a una catena di navigazione più osservabile, integrata con sensori e sistemi già presenti a bordo.

Cosa non dimostra un test con una development board

Una prova positiva con una development board non dimostra automaticamente che il prodotto finale sarà immune da spoofing, funzionerà durante qualsiasi interferenza o manterrà una precisione centimetri in ogni ambiente.

Il risultato ottenuto sul banco può cambiare quando il modulo viene installato su una PCB insieme ad altre radio, inserito in un contenitore, montato vicino a strutture metalliche oppure alimentato da un convertitore rumoroso.

OSNMA non sostituisce la progettazione RF, la sensor fusion, il monitoraggio dell’integrità e una politica applicativa per le condizioni degradate.

Allo stesso modo, una prova HAS eseguita in campo aperto non garantisce gli stessi risultati vicino a edifici, alberi o ostacoli.

Un proof of concept serve a verificare la fattibilità e a identificare i limiti. La validazione del prodotto finale deve essere ripetuta sull’hardware e sull’installazione reali.

Il futuro europeo: Galileo e la costellazione LEO-PNT Celeste

L’evoluzione europea del PNT non si fermerà alla costellazione Galileo attualmente operativa.

Il 28 marzo 2026 l’Agenzia Spaziale Europea ha lanciato i primi due satelliti della missione dimostrativa Celeste LEO-PNT.

Nell’aprile 2026 Celeste ha trasmesso il primo segnale europeo di navigazione da orbita terrestre bassa.

La configurazione dimostrativa prevede complessivamente undici satelliti e servirà a studiare nuovi segnali, nuove bande e servizi capaci di lavorare insieme a Galileo, EGNOS e agli altri GNSS.

I satelliti Galileo operano in orbita terrestre media. Celeste sperimenta invece un livello complementare in orbita bassa, più vicino alla superficie terrestre.

L’obiettivo non è sostituire Galileo, ma valutare come una nuova costellazione possa migliorare robustezza, disponibilità e prestazioni attraverso un’architettura multi-layer.

Per chi progetta sistemi embedded, questa evoluzione suggerisce un principio importante: il sottosistema PNT dovrebbe essere modulare e non dipendere rigidamente da una sola sorgente.

Galileo, EGNOS, futuri segnali LEO, IMU, odometria, visione e tecnologie radio terrestri potranno contribuire a sistemi nei quali posizione e tempo vengono valutati utilizzando informazioni differenti e complementari.

Come valutare un proof of concept Galileo

Un progetto GNSS non dovrebbe iniziare dalla scelta del modulo con il numero più elevato di costellazioni o con la migliore precisione riportata nel datasheet.

La prima attività consiste nel definire i requisiti reali:

precisione → disponibilità → frequenza di aggiornamento → autenticazione → timing → dinamica → ambiente → consumo → comportamento degradato

Successivamente può essere selezionata una development board compatibile con le funzioni da validare.

Le prove devono essere eseguite nelle condizioni rappresentative dell’applicazione: posizione dell’antenna, presenza di edifici o vegetazione, movimento, velocità, altre radio, alimentazione e possibili sorgenti di rumore.

Per sistemi orientati alla sicurezza deve essere definito anche il comportamento quando la qualità PNT diminuisce.

Il prodotto potrebbe continuare a funzionare utilizzando altri sensori, limitare alcune operazioni, generare un allarme oppure interrompere le funzioni per le quali una posizione attendibile è essenziale.

Solo dopo questa fase ha senso definire l’architettura finale, selezionare il modulo, progettare il percorso RF e integrare il ricevitore nella PCB.

Come Silicon Logix può aiutare le aziende

Silicon Logix sviluppa e prototipa sistemi che integrano firmware embedded, microcontrollori, Linux embedded, sensoristica, comunicazioni e interfacce hardware.

Un progetto Galileo o GNSS può partire da development board commerciali per verificare rapidamente la fattibilità dell’applicazione prima di investire nella progettazione dell’hardware definitivo.

Il proof of concept può comprendere ricevitore multi-banda, antenna, Galileo OSNMA, RTK o HAS, piattaforma Linux, IMU, acquisizione dei dati e strumenti di visualizzazione.

Le prove possono confrontare configurazioni differenti e misurare precisione, continuità, tempi di acquisizione, stato di autenticazione, qualità della ricezione e comportamento del sistema durante condizioni degradate.

Per attività di ricerca e caratterizzazione è possibile affiancare al ricevitore commerciale una piattaforma SDR, ottenendo maggiore accesso ai segnali e ai messaggi Galileo.

L’output non è soltanto una dimostrazione. Il progetto può produrre un report tecnico con architettura consigliata, metriche misurate, limiti rilevati, componenti da integrare e percorso verso la PCB definitiva.

Se i test confermano la fattibilità, il prototipo può evolvere verso una scheda personalizzata con modulo GNSS, antenna, alimentazione, firmware, diagnostica, connettività e logica di sensor fusion.

Domande frequenti su Galileo OSNMA e HAS

Galileo può funzionare senza GPS?

Sì. Galileo è un sistema GNSS globale autonomo. Nei ricevitori commerciali viene però spesso utilizzato insieme a GPS e alle altre costellazioni per aumentare disponibilità, numero di satelliti e qualità della geometria.

OSNMA impedisce completamente lo spoofing?

No. OSNMA autentica specifici dati del messaggio di navigazione Galileo e permette di identificare informazioni non autenticate. Non impedisce il jamming e non autentica direttamente ogni misura di distanza utilizzata per calcolare la posizione.

Qualsiasi ricevitore Galileo supporta OSNMA?

No. Il ricevitore deve implementare le funzioni OSNMA previste. Il supporto deve essere verificato sulla variante hardware e sulla versione firmware effettivamente utilizzate.

Galileo HAS sostituisce RTK?

No. HAS utilizza un approccio PPP e distribuisce correzioni globali via E6-B e Internet. RTK utilizza una base o una rete di riferimento e presenta caratteristiche differenti in termini di infrastruttura, convergenza e precisione.

È possibile provare OSNMA con una development board?

Sì, purché la scheda integri un ricevitore e un firmware esplicitamente compatibili con OSNMA. La semplice ricezione della costellazione Galileo non garantisce il supporto al servizio di autenticazione.

Serve una connessione Internet per Galileo HAS?

Non necessariamente. Le correzioni HAS possono essere ricevute via Internet oppure direttamente dal segnale Galileo E6-B. La ricezione satellitare richiede però un ricevitore e un percorso RF compatibili con la banda E6.

Un ricevitore GNSS può essere utilizzato soltanto per sincronizzare il tempo?

Sì. Ricevitori dedicati al timing possono fornire uscite 1PPS e informazioni temporali utilizzabili per sincronizzare reti, gateway, sistemi di acquisizione e infrastrutture distribuite.

Conclusione

Galileo rappresenta molto più di un’alternativa europea al GPS.

La disponibilità di un’infrastruttura GNSS europea permette di costruire servizi autonomi di posizione, navigazione e tempo.

OSNMA introduce l’autenticazione dei messaggi di navigazione Galileo. HAS distribuisce gratuitamente correzioni PPP globali con prestazioni di livello decimetrico. I servizi di timing permettono di utilizzare Galileo anche per sincronizzare sistemi che non si muovono.

Development board, ricevitori commerciali, piattaforme Linux e SDR rendono queste tecnologie accessibili anche a imprese, sviluppatori e laboratori che vogliono verificarle prima di progettare hardware personalizzato.

Il valore non deriva però dalla semplice presenza di un modulo GNSS.

Un sistema professionale deve integrare ricevitore, antenna, firmware, diagnostica, sensor fusion e una politica chiara per le condizioni degradate.

La domanda non è più soltanto:

“Quale modulo GPS possiamo aggiungere al prodotto?”

La domanda diventa:

“Come possiamo costruire un sistema che sappia dove si trova, quanto sia precisa la posizione e quanto possa fidarsi delle informazioni utilizzate?”

È su questo livello che Galileo OSNMA, HAS, Linux, SDR e firmware embedded diventano gli elementi di una nuova generazione di sistemi PNT europei.

Riferimenti tecnici

[1] European GNSS Service Centre, Galileo Open Service Navigation Message Authentication – OSNMA, descrizione ufficiale del servizio, architettura e requisiti del ricevitore.

[2] European Union Agency for the Space Programme, Celebrating one year of Galileo OSNMA: a milestone for trusted positioning, 27 luglio 2026.

[3] European Union Agency for the Space Programme, Galileo to be the first GNSS to offer authentication service worldwide with launch of OSNMA, luglio 2025.

[4] European GNSS Service Centre, Galileo Services, stato dei servizi operativi e dei servizi in sviluppo.

[5] European Union Agency for the Space Programme, Galileo High Accuracy Service, descrizione ufficiale del servizio PPP globale.

[6] European GNSS Service Centre, Galileo High Accuracy Service – HAS, correzioni, distribuzione E6-B e accesso Internet.

[7] European Union Agency for the Space Programme, Galileo HAS ready to increase efficiency of farming tasks, risultati della campagna di test 2026.

[8] u-blox, ZED-X20P all-band high precision GNSS module, documentazione ufficiale.

[9] u-blox, EVK-X20P evaluation kit, piattaforma di valutazione GNSS all-band e RTK.

[10] u-blox, ZED-X20P-01B with Galileo HAS and global PPP, comunicato tecnico del 28 aprile 2026.

[11] u-blox, ZED-F9T high accuracy timing module, documentazione ufficiale per timing e OSNMA.

[12] Septentrio, mosaic-go X5 evaluation kit, piattaforma high-precision con OSNMA e analisi delle interferenze.

[13] STMicroelectronics, X-NUCLEO-LIV4A1, development board GNSS dual-band per STM32 Nucleo.

[14] GNSS-SDR, Introducing GNSS Navigation Message Authentication, implementazione e utilizzo di Galileo OSNMA nel ricevitore software-defined.

[15] European Space Agency, Celeste LEO-PNT, missione dimostrativa europea per un livello di navigazione complementare in orbita bassa.

[16] European Space Agency, Celeste broadcasts first navigation signal from low Earth orbit, aprile 2026.