Le funzionalità di PTP potrebbero rivoluzionare il modo in cui gestiamo molti requisiti di test comuni in futuro. Questo articolo descrive il suo funzionamento e i vantaggi che possiamo trarre da questa tecnologia. PTP sincronizza con precisione gli orologi in tempo reale integrati in molti componenti di sistema moderni. Come il Network Timing Protocol (NTP), PTP opera su Ethernet e TCP/IP. Tuttavia, è molto più preciso: è possibile ottenere facilmente una sincronizzazione fino a 100 ns o anche migliore. Si potrebbe pensare che tali sistemi siano fragili e difficili da configurare, ma non è così. Come vedremo in seguito, la configurazione del sistema è semplice e per lo più automatica. Ma prima, diamo un'occhiata ad alcuni concetti di base dello standard IEEE 1588.
PTP si basa su un'architettura master-slave. Gli orologi slave sono sincronizzati con l'orologio master (in genere quello con la base dei tempi più stabile e precisa). La chiave della precisione di PTP risiede nel modo in cui tiene conto del tempo di trasmissione dei messaggi attraverso la LAN durante la valutazione della deviazione dell'orologio slave (vedere Figura 1).
Come mostrato, l'orologio master invia un messaggio di sincronizzazione, "Sync", allo slave a intervalli regolari. Lo slave risponde con un messaggio di richiesta di ritardo, "Delay_Req". Sia l'invio che la ricezione di questi messaggi vengono registrati dagli orologi. I quattro record temporali risultanti vengono quindi utilizzati per calcolare il tempo di trasmissione (il tempo in cui il messaggio viene effettivamente trasmesso a livello di rete fisica). Si noti che il calcolo mostrato in Figura 1 si basa sul presupposto che il tempo di trasmissione sia simmetrico (con Ethernet, questa è un'ipotesi perfettamente ragionevole). Con il tempo di trasmissione e i registri basati sul tempo del messaggio Sync, il calcolo della deviazione dell'orologio slave è semplice.
L'hardware è meglio del software.
Sebbene non sia un requisito imprescindibile, per prestazioni ottimali, i registri di temporizzazione vengono acquisiti a livello hardware, al livello fisico della rete. Perché? La chiave per una sincronizzazione perfetta risiede in registri di temporizzazione stabili e ripetibili con variazioni minime. E il modo migliore per ottenere questo risultato è attraverso una progettazione hardware (vedere il diagramma a blocchi concettuale in Figura 2).
Con una progettazione Ethernet che prevede un chip fisico separato (implementazione a livello fisico), è relativamente semplice acquisire il flusso di bit dei frame Ethernet. L'hardware di pattern matching cercherà quindi un pattern di messaggio Delay_Req in ingresso o Sync in uscita. Si noti che la specifica standard IEEE 1588 indica chiaramente quali registri di temporizzazione delle transizioni di bit devono essere acquisiti.
Nella progettazione descritta sopra, il registro di temporizzazione viene acquisito come se il frame Ethernet fosse effettivamente inviato al livello fisico della rete. Pertanto, il registro di temporizzazione non può essere inviato come parte dello stesso messaggio. Il messaggio Follow-Up (vedere Figura 1) viene utilizzato per comunicare il registro basato sul tempo ("tempo di invio preciso") separatamente dal messaggio Sync originale.
In alcune situazioni, può essere sufficiente e perfettamente ragionevole utilizzare un'applicazione software per registrare gli eventi in base al tempo. Tuttavia, la precisione di sincronizzazione risultante sarà, come minimo, molto inferiore a causa della variabilità temporale associata al software di gestione dei protocolli di rete.
La fluttuazione del ritardo di rete è il nemico.
Come accennato in precedenza, l'algoritmo di correzione dell'orologio si basa sul presupposto di tempi di trasmissione simmetrici. Pertanto, le fluttuazioni nei tempi di trasmissione (unidirezionali) degraderanno la precisione della sincronizzazione. Per prestazioni ottimali, scegli un'infrastruttura di rete con una fluttuazione del ritardo minima.
Un hub Ethernet, per sua stessa natura, presenta una latenza relativamente bassa e stabile. Un hub è un semplice ripetitore di segnale e i frame Ethernet non vengono né memorizzati né interpretati in alcun modo. Uno switch Ethernet, invece, presenta una latenza maggiore e, soprattutto, un jitter molto più elevato. Lo switch analizza i frame in ingresso e li mette in coda per l'inoltro sulla porta di destinazione appropriata. Un router presenta un livello di jitter ancora più alto perché ispeziona i pacchetti a livello IP e li memorizza e inoltra utilizzando meccanismi software.
Se si desidera utilizzare uno switch o un router per le loro funzionalità aggiuntive rispettivamente ai livelli di rete 2 e 3, non è necessario tollerare il loro jitter più elevato e la conseguente riduzione della precisione di sincronizzazione. La comunicazione punto-punto (PTP) utilizza un meccanismo chiamato clock periferico per neutralizzare l'effetto negativo degli elementi di rete che presentano un jitter elevato (vedere Figura 3).
Un orologio periferico è uno switch o un router dotato di un proprio orologio in tempo reale integrato e conforme allo standard IEEE 1588. Ad eccezione dei messaggi di temporizzazione PTP come Sync e Delay_Req, si comporta come un normale switch o router. Tuttavia, per quanto riguarda il protocollo PTP, l'orologio periferico termina il "percorso di sincronizzazione" dietro ogni singola porta. La porta collegata all'orologio migliore (grandmaster clock) funge da orologio slave. Di conseguenza, l'orologio interno dello switch o del router si sincronizza con il grandmaster clock tramite questa porta. Le altre porte fungono da orologi master. In questo modo, tutti gli orologi slave nel rispettivo percorso di sincronizzazione si sincronizzano con l'orologio interno dell'orologio periferico.
Il meccanismo dell'orologio periferico aumenta drasticamente la precisione della sincronizzazione (al livello di un semplice hub Ethernet o addirittura superiore) perché i messaggi di temporizzazione IEEE 1588 non vengono commutati o instradati attraverso l'elemento di rete (a differenza di altri pacchetti IP o frame Ethernet). Di conseguenza, una fonte significativa di jitter di ritardo (memorizzazione ed elaborazione nell'elemento di rete) viene eliminata.
Fino a che punto si può spingere questa tecnologia?
Come abbiamo visto, un sistema progettato per le massime prestazioni dovrebbe attenersi a due regole importanti. In primo luogo, dovrebbe utilizzare un'implementazione hardware dello standard IEEE 1588 per gli orologi master e slave. In secondo luogo, dovrebbe utilizzare un'infrastruttura di rete appropriata: un semplice hub Ethernet o un elemento di rete più complesso (switch o router) con un orologio periferico. Se seguiamo queste regole, qual è il livello di precisione di sincronizzazione che possiamo raggiungere?
Con le tecniche hardware, la precisione è limitata da due fattori: la cattura del clock dell'implementazione fisica e la stabilità dell'oscillatore o dell'orologio locale stesso. Nell'implementazione di Fast Ethernet, il jitter di cattura del clock è tipicamente nell'ordine di poco meno di dieci nanosecondi. L'effetto di questo jitter può essere ridotto in modo piuttosto efficace utilizzando metodi statistici. La variazione dell'oscillatore locale dipende fortemente dalla progettazione del sistema e potrebbe facilmente minimizzare i problemi di cattura del clock. Va notato che l'intervallo del messaggio Sync può essere ridotto a 1 secondo, ma non meno. Un progetto con elevata stabilità dovrebbe presentare una variazione limitata per compensare la stabilità della cattura del clock (nell'ordine dei nanosecondi). Ciò potrebbe richiedere una soluzione relativamente costosa basata su un oscillatore termicamente resistente.
Le soluzioni migliori includeranno metodi statistici appropriati per ridurre l'effetto delle fluttuazioni di ritardo. Lo standard IEEE 1588 non specifica l'utilizzo di un algoritmo di media; pertanto, questo è un altro ambito in cui i produttori possono apportare un contributo unico alle proprie soluzioni.
Questi sistemi sono difficili da installare?
Uno degli aspetti più interessanti dello standard IEEE 1588 è che la configurazione del sistema è per lo più automatica (a meno che non si preferisca controllare il processo di configurazione). Vediamo come ciò sia possibile.
Ogni orologio mantiene determinati set di dati che descrivono le sue capacità intrinseche (ad esempio, la sua stabilità) e la sua configurazione attuale (ad esempio, una stima della deviazione in tempo reale dal master, nonché l'identificazione dell'orologio master). Questi (e altri) parametri descrivono la qualità di un orologio e vengono "pubblicati" come parte di ogni messaggio Sync inviato dall'orologio.
Quando un orologio entra in funzione, assume il ruolo di master e inizia a inviare messaggi Sync (contenenti le sue specifiche). Gli altri orologi ricevono i parametri di qualità e li confrontano con le proprie specifiche (utilizzando l'algoritmo "Best Master Clock"). Se percepiscono un orologio master migliore, assumono il ruolo di slave.
Quali sono i criteri per un orologio "buono"? Un parametro importante è lo "strato dell'orologio". Questo valore indica se l'orologio ha una tracciabilità diretta o indiretta a una sorgente oraria standard "ufficiale", come ad esempio un ricevitore GPS. Sono preferibili gli orologi con un collegamento diretto a tale sorgente oraria assoluta. Un altro parametro importante è la "varianza dell'orologio", un'indicazione della stabilità intrinseca dell'orologio stesso.
Come accennato in precedenza, le impostazioni automatiche o predefinite possono essere modificate a piacimento. Lo standard IEEE 1588 definisce anche diversi messaggi di gestione a questo scopo. Questi consentono di interrogare i set di dati dell'orologio, regolare l'impostazione in tempo reale e modificare lo stato dell'orologio o altri parametri operativi tramite la LAN.
A cosa serve dunque questa tecnologia?
L'acquisizione dati è un'applicazione ovvia dello standard IEEE 1588. Molte applicazioni di acquisizione dati richiedono la distribuzione di sensori su un'ampia area (ad esempio, in impianti industriali o comunicazioni cablate/wireless). Ma anche nelle applicazioni centralizzate, è necessario sincronizzare diversi strumenti o unità di acquisizione dati. In quasi tutte le applicazioni, è fondamentale sapere quando sono state effettuate le singole misurazioni. L'elevata precisione temporale offerta dallo standard IEEE 1588 apre maggiori possibilità di post-elaborazione e analisi, consentendo una migliore comprensione dei dati. Senza lo standard IEEE 1588, sarebbe necessario sincronizzare gli strumenti utilizzando ricevitori GPS separati o un segnale di trigger generato centralmente. La prima opzione è costosa, mentre la seconda non è semplice a causa del ritardo di propagazione e del rumore di jitter del trigger.
Anche i test funzionali trarranno grande vantaggio dallo standard IEEE 1588. Spesso è necessario applicare stimoli in una sequenza predefinita e con una temporizzazione precisa. È inoltre necessario misurare o registrare la reazione di un dispositivo in prova (DUT) in un momento predefinito. Anche gli scenari più complessi sono facili da implementare grazie al trigger temporizzato reso possibile dallo standard IEEE 1588. Senza di esso, potrebbe essere necessario generare uno o più segnali di trigger hardware e instradarli ai vari strumenti in modo appropriato. Il trigger temporizzato offre una flessibilità molto maggiore perché non è limitato dal cablaggio fisico e non presenta problemi di qualità del segnale.
In sintesi:
lo standard IEEE 1588 è una tecnologia affascinante. Se lavorate nel campo delle applicazioni di sistema, dovreste assolutamente prenderla in considerazione. Questa tecnologia e le sue funzionalità potrebbero semplificarvi la vita. La comunicazione Point-to-Point (PTP) consente la registrazione temporale a livello di sistema e l'attivazione precisa in base al tempo, senza la necessità di cablaggi complessi. Pertanto, offre un livello di flessibilità senza precedenti in questo ambito.
L'autore,
Stefan Kopp, è laureato in Informatica presso l'Università Cooperativa di Stoccarda, in Germania. Lavora presso Agilent (precedentemente HP) dal 1989, ricoprendo diversi ruoli, tra cui project manager per soluzioni di test personalizzate e rappresentante commerciale. Attualmente è consulente nel campo dell'automazione dei test e dei componenti dei sistemi di test.
