Mappa del sito
Sincron Sistemi
SINCRON SISTEMI S.R.L - Via A.Moro, 55 20060 Gessate (MI)
Tel.02.95 384 218 | Fax 02.95 384 210
SINCRON SISTEMI

MiFID II

LA DIRETTIVA MIFID II

La direttiva MIFID II riguarda il mercato degli strumenti finanziari e dovrà essere attuata dai soggetti coinvolti a partire dal Gennaio 2018. Nell'ambito della nuova regolamentazione, le sedi di negoziazione delle transazioni finanziarie ed i loro membri sono tenuti a sincronizzare le reti commerciali interne, mantenendosi entro tolleranze definite rispetto ad UTC (Universal Coordinated Time).
Le sedi di negoziazione sono inoltre tenute a dimostrare, con cadenza annuale, la conformità a tale normativa ed il rispetto delle tolleranze prescritte attraverso documentazione prodotta dal sistema di sincronizzazione.
Le norme RTS 25 specificano una deviazione di non più di 100 microsecondi da UTC negli ambienti High Frequency Trading (HFT) o una latenza di 1 millisecondo da UTC in tutti gli altri ambienti commerciali non umani. Una varianza stretta significa che la fonte principale del tempo deve essere la più accurata possibile per consentire qualsiasi jitter imprevisto sulla rete, che potrebbe aumentare il ritardo dei pacchetti di temporizzazione e quindi la sincronizzazione dell'applicazione finale.

 

COME SODDISFARE LA DIRETTIVA

Per rispettare tolleranze così basse è stato previsto l'utilizzo di un protocollo nato per il trasporto del tempo ad elevata accuratezza, PTP (precision time protocol) ad oggi nella versione 2.
I fruitori della fonte del tempo sono quindi le applicazioni di trading che possiamo identificare come dei server sui quali risiedono. Per trasportare il tempo a questi server occorre costruire un'infrastruttura di erogazione composta da vari elementi, i quali hanno in comune la necessità primaria di essere componenti abilitanti e aware del servizio PTP; tutto questo allo scopo di portare il tempo ai server rimanendo ben al di sotto della tolleranza prevista in direttiva.

La catena di servizio è composta da:

1. Grandmaster (GM) PTPv2: è collegato ad antenne per la ricezione del segnale satellitare (e quindi del tempo assoluto) ed inoltre è collegato a switch ethernet per distribuire il clock alle applicazioni.
È importante che il GM possa collegarsi a più fonti di clock (GPS, Glonass, Galileo, BeiDou) e abbia la capacità di supportare un’elevata quantità di applicazioni lato cliente.

2. Switch ethernet PTPv2 aware, per il trasporto del tempo ai server; la componente di switching di rete è estremamente delicata e deve prevedere un'attenta progettazione per questi motivi:
- deve essere aware del protocollo PTPv2 e deve abilitarne la sua distribuzione, attraverso la correzione del tempo stesso; questo prevede che ogni switch misuri il tempo di attraversamento di ogni pacchetto PTPv2 e introduca tale valore negli opportuni campi del protocollo affinchè il server finale possa applicare le correzioni di tempo. A tale scopo è importante che lo switch sia dotato di oscillatore interno, in modo che possa eseguire misure ad elevata precisione e supportare l'infrastruttura anche nel caso il GM non sia disponibile
- gli switch devono poter ricoprire differenti ruoli nell'infrastruttura: Boundary clock e Transparent clock. Oltre alla capacità di gestire ambienti multi-cliente.
Si noti come gli switch, oltre alle classiche capacità come le elevate performance, la bassa latenza e la presenza di buffer profondi, debbano avere funzionalità ad-hoc per l'applicazione PTPv2

3. Server specifici per creare time stamp compatibili con MiFID II.

4. Sistema di monitoraggio per rispettare quanto indicato dall'articolo 4 della MiFID-II, il quale richiede una revisione annuale per dimostrare la conformità.

 

LA SOLUZIONE INTEGRATA CHIAVI IN MANO

La delicatezza del servizio necessita di un approccio integrato, che preveda una soluzione completa di tutte le componenti infrastrutturali e la competenza professionale per la progettazione, integrazione, rilascio in produzione, monitoring e supporto continuativo.
VISTA TECHNOLOGY e SINCRON-SISTEMI hanno stretto una forte partnership verticale su questa applicazione che ha portato all'identificazione della migliore e più affidabile soluzione end to end, composta dalle tecnologie leader di mercato e supportata da elevate professionalità che vantano l'esperienza di soluzioni MIFID II PTP già portate in campo con successo presso importanti istituzioni finanziarie e centri servizio.

 

ABOUT SINCRON SISTEMI

Sincron Sistemi si indirizza primariamente alla commercializzazione di strumenti e sistemi per la sincronizzazione sia di Tempo che di Frequenza che, con l’avvento del digitale in tutte le diverse branche dell’elettronica, è di importanza essenziale per il corretto funzionamento dei sistemi moderni.
www.sincron-sistemi.it

 

ABOUT VISTA TECHNOLOGY


VISTA TECHNOLOGY nasce con la missione di system integrator focalizzato nello studio, progettazione, realizzazione e gestione di cloud data center, intelligent backbone, integrated access campus network ed enterprise security infrastructure. I principi che guidano VISTA nella realizzazione dei progetti infrastrutturali sono: automazione, agilità, sicurezza, opennes ed efficienza.
www.vistatech.it

 

Continue reading
52 Hits
0 Comments

Aggiornamento firmware Meinberg 6.22

Aggiornamento Firmware applicabile a tutti  i Server Meinberg

L’aggiornamento 6.22 per Meinberg's LANTIME firmware LTOS6 offre molte nuove funzionalità per migliorare le capacità di sincronizzazione e gestione della  rete.

Bad Pyrmont, June 23, 2017- Meinberg ha rilasciato il nuovo aggiornamento firmware 6.22. Questo aggiornamento è compatibile con tutti i prodotti Meinberg LANTIME della serie Mxxx, SyncFire ed il range di prodotti IMS-Series, inclusi i sistemi M300/M600. L’aggiornamento, come da politica aziendale Meinberg è gratuito ed indirizzato a tutti i clienti.
Ancora una volta Meinberg dimostra l’impegno, non solo nell’offrire supporto per i prodotti, ma soprattutto nell’aggiornamento software distribuito gratuitamente durante l’intero ciclo di vita.

LANTIME firmware LTOS6 versione 6.22 offre molteplici soluzioni innovative al fine di affinare ulteriormente i requisiti di sincronizzazione più stringenti, odierni e futuri;  Meinberg lavora costantemente migliorando il firmware LTOS6 dei suoi dispositivi.

Ecco le maggiori novità introdotte dalla versione 6.22:

 

PARALLEL REDUNDANCY PROTOCOL (PRP)

Un protocollo di rete seamless failover che fornisce una ridondanza senza perdita di pacchetti. I nodi PRP hanno due porte di rete individuali, ognuna delle quali è attaccata a due reti separate. Un nodo invia due copie di un frame su ogni porta e il nodo finale prende il primo pacchetto in arrivo scartando il secondo. PRP è un protocollo basato su layer 2 e disponibile per NTP e PTP. Due interfacce fisiche qualsiasi possono essere combinate per formare un gruppo a interfaccia PRP, supportando indirizzi IP multipli, VLANs e servizi.

Per maggiori informazioni su come attivare la funzionalità PRP non esitate a contattarci.

 

IEEE 802.1X - PORT BASED AUTHENTICATION

Un controllo degli accessi e protocollo di autenticazione client-server che impedisce che client non autorizzati possano connettersi ad una LAN se non autenticati correttamente.

 

LLDP AND OTHER NETWORK DISCOVERY PROTOCOLS

E’ possibile abilitare LLDP, Cisco Discovery Protocol (CDP), Foundry Discovery Protocol (FDP) e Nortel Discovery Protocol (NDP) su tutte le interfacce fisiche dei tuoi dispositivi compatibili con LTOS6.

 

SUPPORT OF NEW PTP TELECOM PROFILES

ITU-T G.8275.2: profilo Telecom utilizzato da applicazioni telecom che richiedono accuratezza di sincronizzazione di tempo e fase (time-of-day) come per esempio: LTE-TDD e LTE advanced base station.
DOCSIS 3.1, configurazione di base dei Cable Provider (Data-Over-Cable Service Interface Specifications) basato su un profilo Telecom ITU-T G.8275.1.

 

PTP V1 SUPPORT ON HPS100

Meinberg ripristina anche il supporto del PTP v1 come funzionalità sulla scheda HPS-100. Questo consente di sincronizzare applicazioni e reti che si basano ancora su PTP v1 (IEEE 1588-2002), come per esempio DANTE based Audio over IP networks. 
Ricordiamo inoltre che, la versione v1 del PTP  non è compatibile con la versione v2. 
Aggiornando l’infrastruttura di sincronizzazione con una scheda HPS-100 che supporta il PTP v1 è possibile gestire con semplicità questo protocollo in parallelo al PTP v2, oppure insieme ad altre tecnologie di sincronizzazione. La configurazione base consente di ottenere delle performance di circa 12k pacchetti/secondo (~3000 clients).

 

NET-SYNC MONITOR

Uno strumento di monitoring multifunzione che può essere molto utile per rispettare regolamenti come ad esempio MiFID II, consentendo di monitorare centinaia di nodi NTP e PTP sulla rete. Il monitoraggio PTP è possibile utilizzando un modulo HPS100 (con opzione di licenza PL-D) configurato per essere utilizzato in modalità “monitoring mode”. 
Il monitoraggio NTP è possibile utilizzando sia il modulo CPU standard che la scheda di espansione di rete LNE. NetSync Monitor ha la sua interfaccia utente integrata nella Web GUI standard di ogni LTOS6 LANTIME con versione firmware 6.22 o successive e fornisce potenti funzionalità di virtualizzazione e gestione avvisi/allarmi.

 

SECURITY

La sicurezza diventa sempre più importante e perciò Meinberg ha rilasciato questa nuova versione firmware e continuerà a rafforzare le prossime versioni.

·         Protection against XSS, Cross-Site-Request-Forgery attacks improved

·         Latest NTP-Version 4.2.8p10 con 15 fixes for several security vulnerabilities

·         Latest GLIBC, OpenSSL e aggiornamenti SSH

·         SSH & HTTPS: Removed unsecure/weak ciphers

·         Outcome of security audits integrated into LTOS6 to close and minimize vulnerabilities and attack vectors

Un numero di correzioni di vulnerabilità e miglioramenti sono stati sviluppati basandosi sul risultato di un controllo effettuato da Sebastian Krause e Toralf Gimpel della GAI NetConsult GmbH. Diversamente da tutti i competitors, Meinberg continua ad aggiungere nuove funzionalità, nuovi protocolli e correzioni di sicurezza offrendo supporto tecnico gratuito a vita su tutti i suoi prodotti, mettendo il cliente al primo posto.

 

Il nuovo firmware LANTIME version 6.22 può essere scaricato da questa pagina del sito ufficiale Meinberg: LANTIME Firmware 6.22.  Su questa pagina trovate anche l’articolo originale e non esitate a contattarci per ricevere maggiori informazioni attraverso la nostra pagina di contatto.

Continue reading
133 Hits
0 Comments

Sincronizzazione di Tempo per la MiFID II - Raggiungere la conformità e FAQ per MiFID II -

NOTA: Questa breve guida scritta originariamente da Rob Skinner, Sales and Support for Time and Frequency Sinchronization Systems di APC Technology Group, distributore ufficiale dei prodotti Meinberg per il Regno Unito, ha lo scopo di fornire le più risposte alle domande più ricorrenti per soddisfare i nuovi requisiti della MiFID II con l’utilizzo dei dispositivi Meinberg dedicati al PTP. Ve la riproponiamo in quanto rispecchia totalmente il campo di lavoro di Sincron Sistemi per il mercato Italiano.

 

La direttiva MiFID II, relativa al mercato degli strumenti finanziari, sarà attuato nei mercati finanziari a partire dal Gennaio 2018.  Nell'ambito della nuova regolamentazione, le sedi di negoziazione ed loro  membri sono tenuti a sincronizzare le loro reti commerciali interne, mantenendosi entro definite tolleranze rispetto ad UTC (Universal Coordinated Time).

Le sedi di negoziazione sono inoltre tenute a dimostrare, con cadenza annuale, la conformità, basata sulla documentazione del sistema di sincronizzazione, a questa nuova normativa.


Quale precisione è necessaria in una rete ad alta frequenza di trading per MiFID II?

Le norme RTS 25 specificano una deviazione di non più di 100 microsecondi da UTC negli ambienti High Frequency Trading (HFT) o una latenza di 1 millisecondo da UTC in tutti gli altri ambienti commerciali non umani. Una varianza stretta significa che la fonte principale del tempo deve essere il più accurato possibile per consentire qualsiasi jitter imprevisto sulla rete, che potrebbe aumentare il ritardo dei pacchetti di temporizzazione e quindi la sincronizzazione del client finale.

È estremamente difficile soddisfare questo requisito 100 microsecondi utilizzando un server NTP, poiché il protocollo NTP non è abbastanza preciso negli ambienti di rete standard. Pertanto, per ridurre al minimo il margine possibile, è consigliabile utilizzare un orologio Grandmaster PTPv2, switch PTPv2 compatibili e server specifici per creare Time Stamp compatibili con MiFID II. Sincron Sistemi può fornire sia soluzioni flessibili per PTPv2 Grandmaster Clocks attraverso la gamma Meinberg Lantime IMS di server di tempo, che supportarvi nella fase di progetto di switches a bassa latenza attraverso la collaborazione con i nostri partner, in modo tale da fornirvi un servizio “chiavi in mano” per quanto riguarda l’aspetto relativo alla sincronizzazione. Tutti questi sistemi possono essere personalizzati individualmente in base ai requisiti dell'utente finale e della rete, permettendo la massima modularità e flessibilità.


Quale tipo di precisione posso prevedere dal Grand Master al server se utilizzo PTPv2?

Non è possibile fornire un valore preciso relativo alla latenza globale del percorso di rete in quanto dipende da molte variabili indipendenti all'interno di ciascuna rete.

Un caso potrebbe essere se l'intero percorso di rete è PTPv2 compatibile; Se gli switches non sono compatibili con PTPv2, si aggiungerà un ritardo sconosciuto allo slave finale, che il protocollo PTPv2 non sarà in grado di compensare per ridurre la deviazione dall'ora UTC. Altre variabili da considerare sono se i pacchetti PTPv2 seguiranno sempre lo stesso percorso di rete dal Grandmaster al gateway finale (ritardo simmetrico) piuttosto che diversi percorsi di rete da e verso il gateway finale (ritardo asimmetrico) e altri fattori come La larghezza di banda della rete e il tipo di profilo PTPv2 utilizzato.


Come si può dimostrare che il tempo è rintracciabile all'ora UTC?

Il 10 ottobre 2016 L'ESMA ha confermato che la sincronizzazione con GNSS è accettabile, fintanto che la trasmissione di tempo è in UTC, secondo l'istruzione seguente: "L'impiego dell'origine temporale del sistema di posizionamento globale (GPS) statunitense o di qualsiasi altro sistema satellitare di navigazione globale, come il sistema satellitare russo GLONASS o europeo Galileo, quando sarà operativo, è altrettanto accettabile per registrare eventi dichiarabili a condizione che qualsiasi compensazione da UTC venga contabilizzata e rimossa dal timestamp. Il tempo GPS è diverso da UTC. Tuttavia, il messaggio di tempo GPS include anche un offset da UTC (secondi di salto) e questo offset dovrebbe essere combinato con il timestamp GPS per fornire un timestamp conforme ai requisiti di divergenza massima in RTS 25."

 

Cosa succede se la sincronizzazione GNSS viene persa? La rete sarebbe ancora conforme?

Ciò dipende dal rimanente budget di errore che è lasciato al termine della rete. I sistemi Meinberg possono essere forniti con diversi tipi di oscillatore che consentono all'Orologio Grandmaster di tenere il tempo per un certo periodo dopo la perdita della sincronizzazione GNSS.

La scelta di quale oscillatore prevedere è difficile in quanto il rimanente "budget di errore" deve essere conosciuto per garantire che la deriva dell'oscillatore non influenzi l'ora sui pacchetti PTPv2 in una misura tale da mettere fuori rete le specifiche di conformità . Ad esempio, se un sistema Meinberg Lantime / M1000 / IMS fosse dotato di un oscillatore OCXO-HQ e sincronizzato solo con un segnale GNSS e installato in rete, nel "budget di errore" dovrebbero essere disponibili almeno 22 µSecondi per consentire al Grandmaster di fornire la sincronizzazione PTPv2 per 1 giorno in hold over mode. L'OCXO-HQ ha una deriva temporale massima di 22 µSecondi  al giorno, dopo essere rimasto sincronizzato con un segnale GNSS per 24 ore. Gli oscillatori di qualità più elevata consentirebbero un hold over più lungo, ma anche un consistente incremento di costi; ad esempio un oscillatore di backup Rubidium offre un hold over di soli 1,1 22 µSecondi al giorno, ma a fronte di prezzo molto più elevato dell’ OCXO-HQ. Potete confrontare la tabella degli oscillatori Meinberg disponibili a questo link.

Una possibile alternativa potrebbe essere quella d’aver una ulteriore sorgente PTPv2 di rimpiazzo in caso la connessione GNSS dovesse cadere.



Quali alternative esistono alla sincronizzazione GNSS?

Come accennato in precedenza, un'altra alternativa è quella di installare un altro Clock Grandmaster in una posizione separata (disaster recovery) e quindi fornire il servizio PTPv2 diretto come backup per il GPS, con entrambe le soluzioni totalmente ridondate, in modo tale da garantire la più totale sicurezza dell'intero sistema.

 

 
Cosa sono i leap-seconds e perché sono importanti per le norme RTS25?

I “leap-seconds” sono incrementi del tempo di correzione per correggere l'effetto della rotazione non standard della Terra. La rotazione della Terra infatti non è uniforme, e per evitare che la lunghezza del giorno si sposti, diventa necessario regolare l'ora UTC per corrispondere a questo offset, attraverso l'introduzione di leap-seconds. L'avvento dei leap-second è stabilito da un ente internazionale con sede a Parigi, chiamato  INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS). I leap seconds sono importanti per RTS 25 perché, come detto sopra, è necessario che l'ora in rete sia fornita in UTC. Se un secondo aggiornamento di leap second non viene trattato correttamente attraverso l'apparecchiatura, la rete si scosterà di 1 secondo dall'ora UTC, provocando grossi problemi in rete. I sistemi Meinberg sincronizzati GNSS normalmente ricevono e gestiscono automaticamente le informazioni di leap second, in quanto tutti i secondi annunci di salto vengono trasmessi attraverso i satelliti GNSS con diversi mesi di anticipo. Tuttavia è importante verificare come la rete gestirà l'aggiunta di un leap second e se tutte le apparecchiature installate siano in grado di affrontare il leap second. 

 
E la verifica della rete?

L'articolo 4 della MiFID II richiede una revisione annuale per dimostrare la conformità ai regolamenti MiFID II.

Le norme non indicano la necessità di monitorare la rete tra le successive revisioni di conformità, tuttavia è altamente consigliabile che una soluzione di monitoraggio sia considerata ed attuata.

Uno degli incentivi principali per l'attuazione di una soluzione di monitoraggio nella rete infatti è il caso in cui (per esempio) la revisione annuale risultasse non conforme ai requisiti. In questo caso il cliente dovrebbe essere in grado di dimostrare davanti agli enti competenti che la rete è stata conforme per tutta la maggior parte dell'anno e dimostrare anche le ragioni per cui non è stata in conformità al giorno della revisione.

Se si può dimostrare che per il 99% dell'anno la rete è stata conforme questo significa che la normativa rispettata e di conseguenza sarà anche più facile dimostrare che il giorno della revisione c’è stato un qualsiasi tipo di malfunzionamento o di errore, come ad esempio a causa di un problema di sincronizzazione del segnale GPS che ha causato una perdita di sincronizzazione primaria e questo permetterà sicuramente di evitare eventuali sanzioni.

In base a questo il monitoring diventa una vera e propria necessità delle reti dedicate alla finanza e per questo motivo Meinberg ha sviluppato una soluzione di monitoraggio per le normative MiFID II che incorpora un'estensione al protocollo PTPv2 esistente per misurare direttamente il ritardo dei clienti finali selezionati, piuttosto che affidarsi allo stato di auto-segnalazione dei clienti.  Le informazioni di ritardo ottenute dai client monitorati possono essere visualizzate in formato grafico tramite l'interfaccia web del sistema Meinberg, consentendo un rapido elaborazione di informazioni per scopi di controllo o in alternativa scaricati e memorizzati in remoto per l'elaborazione e la valutazione.

 

Non esitate a contattarci per ricevere maggiori informazioni attraverso la nostra pagina di contatto. 

Continue reading
409 Hits
0 Comments

Come assegnare un indirizzo IP statico ad un dispositivo Meinberg - Tutorial -

 

Questo breve video tutorial vi mostrerà come assegnare un indirizzo IP statico ad un dispositivo della famgilia Lantime di Meinberg.

Sono coperti tutti i dispositivi: dai Lantime M100 (senza display) fino ad arrivare alle nuove unità IMS modulari, Lantime M1000 e Lantime M3000.

NOTA: Nel caso siano richiesti i sottotitoli in Inglese (o Italiano), è possibile attivarli tramite la sezione Impostazioni => Sottotitoli => Traduzione Automatica di YouTube

Continue reading
206 Hits
0 Comments

Ripetizione del segnale GNSS per area Kiss & Ride stazione Bologna

Il rapido incremento della popolarità dei terminali, sistemi e servizi GNSS - Global Navigation Satellite System (GPS, Glonass, BeiDou, Galileo) ha provocato lo sviluppo di nuove applicazioni e con il tempo sta generando aspettative che questi dispositivi siano in grado di operare pure all'interno degli edifici. 

Proprio per questo motivo Sincron Sistemi è ha progettato e realizzato attraverso il proprio laboratorio un sistema di ripetizione del segnale GNSS per l'are Kiss & Ride della stazione alta velocità di Bologna.

Tra le varie motivazioni a supporto della necessità di mantenere costantemente l’aggancio al GPS per l’opportuna localizzazione, c’è quella, molto specifica per le reti radiotelefoniche dei Taxi, di rimanere in aggancio anche quando si è in aree non coperte dalla rete satellitare, come lunghe gallerie.

Nel caso specifico dell’area Kiss & Ride della stazione dell’Alta Velocità di Bologna, un tunnel della lunghezza di circa 600 metri, i tassisti restavano senza connessione per tutto il tempo di permanenza nell'area, e quindi formalmente non localizzati dalla centrale.

Rete Ferroviaria Italiana, la società del Gruppo FS che ha realizzato e gestisce il Kiss & Ride, ci ha quindi incaricato di sottoporre un progetto per la soluzione del problema.

Il progetto, nel seguito descritto, è stato appaltato, eseguito ed è attualmente operativo.

Se la propagazione delle onde elettromagnetiche nello spazio vuoto è facilmente prevedibile e computabile, all'interno di gallerie essa è difficilmente presumibile : infatti la riflessione del segnale, fatta dalle pareti, determina aree, anch'esse non identificabili, in cui i segnali diretti e quelli riflessi si combinano in opposizione di fase, di fatto azzerando il campo presente in quelle aree.

Un sistema usato frequentemente, ma soprattutto per lunghe distanze, è quello di utilizzare la cosiddetta linea fessurata : si tratta di un cavo coassiale che contiene “fessure” a distanze regolari, che emettono un po' di segnale da ogni fessura e consentono quindi una copertura continua della galleria. 

La line fessurata è piuttosto costosa come cavo, ed anche nella installazione e manutenzione.

La soluzione che si è preferito adottare, per andare a colpo sicuro e non rischiare di avere buchi di copertura, è stata quella di coprire la galleria mediante 8 antenne ripetitrici, relativamente direttive, poste alternativamente a destra e sinistra nel tunnel, e con inclinazione di circa 60 °C.

Ovviamente la posizione che viene calcolata, indipendentemente da dove ci si trovi nel tunnel,  è quella dell’antenna primaria posta all'esterno, dove i segnali dei diversi satelliti si combinano; l’impianto complessivo comprende inoltre 3 amplificatori, filtri GPS/Glonass e l’utilizzo di cavi a bassa perdita. 

L’impianto è operativo anche per le costellazione GPS e Galileo (entrambi operanti a 1575 MHz) e Glonass (1598 -1615 MHz).

 

Continue reading
347 Hits
0 Comments

Caratterizzare gli OCXO : dal dominio della Frequenza al dominio del Tempo

Vi sono molte applicazioni (PTP, stazione satellitari di terra, applicazioni Hi-Rel) in cui la scelta e la caratterizzazione dell'oscillatore interno va fatta in base alle specifiche che sono richieste in fase di progetto. A tal punto presentiamo questo breve articolo, nella speranza che vi possa essere utile nella caratterizzazione dei vostri oscillatori.

La tecnica digitale, imperante ovunque oggigiorno, richiederebbe la caratterizzazione degli oscillatori nel dominio del tempo, e cioè specificando il Jitter oppure, per gli OCXO più prestanti, l’Allan Variance.

Di fatto, per motivi storici e soprattutto per facilità e comodità di misura, gli oscillatori vengono caratterizzati più frequentemente nel dominio della frequenza, specificando il Phase Noise a diverse distanze dalla portante.

La trasformazione dal dominio della frequenza al dominio del tempo richiederebbe, da un punto di vista rigoroso, l’utilizzo dell’integrale totale del rumore ; di fatto il rumore “pesante” è quello vicino alla portante.

I due grafici del primo allegato mostrano la correlazione esistente tra il rumore a 1 e 10 Hz con l’Allan Variance (Tau = 1Sec) : quello a 10 Hz è ancora un po’ disperso, ma quello ad 1 Hz lo è meno, ovviamente.

 

Ed ecco il file consultabile: Isotemp-correlazione-Phase-Noise-AV.xls

In sostanza la regola del pollice documentata è : per avere 1E-11 di AV (Tau = 1 Sec) occorre avere almeno 88 dBc ad 1 Hz; per avere 1E-12 di AV ne occorrono almeno 108 dBc

Quanto sopra detto è sperimentale : rilievi fatti su 208 samples OCXO @ 10 MHz con quarzo SC in 3° overtone. 

La cosi detta ”vasca da bagno” dell’Allan Variance è sostanzialmente piatta per valori di Tau di 0,1-1-10 Sec, come si evince dal secondo allegato.

Ed ecco il secondo file consultabile: Isotemp-131-40-Phase-Noise--AV.xls

Continue reading
298 Hits
0 Comments

Nuovo modulo ricevitore GNS181: supporto Multi GNSS per le serie IMS e LANTIME (GPS, Galileo, GLONASS e Beidou)

 

Il nuovo modulo ricevitore IMS Meinberg GNS181 introduce la funzionalità multi GNSS per tutte le applicazioni di sincronizzazione ed è una delle prime soluzioni presenti sul mercato per le soluzioni di sincronizzazione di tempo e frequenza che supporta Galileo.

Il modulo GNS181 può essere configurato per selezionare fino a tre differenti costellazioni GNSS che possono essere usate in parallelo; supporta infatti i segnali GPS, Glonass, Beidou e Galileo oppure, in alternativa, delle combinazioni di questi quattro sistemi satellitari.

Inoltre è totalmente compatibile con i dispositivi della serie Intelligent Modular Synchronization di Meinberg (IMS).
Questo significa che il modulo di clock IMS-GNS181 può essere installato in qualsiasi slot di clock (CLK) di tutti i sistemi IMS, compresi i modelli LANTIME M500, M1000, M3000 e M4000. Più informazoni a questi modelli si trovano nella pagina SINCRONIZZAZIONE del nostro sito. Ovviamente la scheda IMS-GNS181 può essere equipaggiata con tutti gli oscillatori disponibili nella tabella degli oscillatori di Meinberg.

Il recente nuovo ricevitore GNS della Meinberg non solo consente di agganciarsi ad una delle qualsiasi costellazioni GPS, Glonass, BeiDou o Galileo, ma può anche “mediare” tra diverse combinazioni di costellazioni come da tabellina allegata. 

L’aggancio contemporaneo a più costellazioni NON assicura una miglior accuratezza della ricostruzione del PPS, bensì una maggior sicurezza nel caso in cui - per qualsiasi motivo – qualche satellite non dovesse essere disponibile.

 

 


Gli utenti inoltre possono facilmente aggiungere il modulo GNS181 come seconda unità di clock in modo da rendere la loro soluzione ridondata, oppure sostituire i loro attuali moduli di clock IMS con la nuova scheda multi-sorgente GNSS.


Si possono trovare maggiori informazioni sul nostro nuovo modulo di clock GNS181 direttamente sul sito Meinberg:

https://www.meinbergglobal.com/english/products/gps-glonass-galileo-beidou-receiver.htm


Ma le novità non finiscono qui: oltre alla serie IMS, anche alcuni prodotti LANTIME M-Series, come il LANTIME M300 e M600 possono essere già ordinati con la nuova scheda ricevente ed, in futuro, anche altri prodotti Meinberg saranno disponibili con un ricevitore GNS, come ad esempio le schede PCIe.

Il ricevitore Meinberg GNS richiede un'antenna che deve essere in grado di ricevere i segnali GNSS desiderati, a questo proposito confermiamo che l'antenna attualmente utilizzata da Meinberg per ricevere i segnali GLONASS/GPS è già in grado di ricevere i segnali multi-GNSS e, pertanto, può essere utilizzato per tutti i segnali GNSS supportati dalla scheda GNS.

Ad oggi, la costellazione Galileo è ancora carente di alcuni satelliti ma l’ESA è impegnata a preparare il prossimo lancio, durante il 17 novembre, con il volo numero VA233. Per la prima volta, il lanciatore Ariane 5 porterà un totale di quattro satelliti Galileo (invece di due), portando in questo modo la costellazione ad un totale di 18 SV ( "Space Vehicle"). Anche se due satelliti (SV ID12 e 20) sono contrassegnati come "Non disponibili" fino ad nuovo avviso (dal 2014), la capacità operativa iniziale di stato (IOC – Initial Opration Capability) dovrebbe essere raggiunta prima della fine di quest'anno.

Per ulteriori approfondimenti può essere consultato il sito ESA che riporta tutte le informazioni relative al lancio di Galileo:

http://www.esa.int/Our_Activities/Navigation/Galileo/Launching_Galileo

Lo stato attuale della costellazione può essere invece verificato nella pagina Constellation Information del Centro Servizi del GNSS europeo alla pagina: 

https://www.gsc-europa.eu/system-status/Constellation-Information

Come sempre Meinberg si conferma leader nell’innovazione e nel fornire nuove funzionalità  e servizi ai suoi clienti. Per ulteriori informazioni non esitate a contattarci nella pagina di contatto.

Continue reading
781 Hits
0 Comments

NTP vs PTP : Confronto tra Protocolli di Sincronizzazione*

Per le reti di trasmissione a pacchetto 

Molti persone mi hanno posto domande circa le diverse temporizzazioni di rete. Alcune non sono facili da rispondere; tuttavia la più frequente è stata “mi serve un sincronismo NTP o PTP?”.

Tutto dipende dalla accuratezza di tempo che si ricerca : siamo nel campo dei secondi, millisecondi, microsecondi o nanosecondi ? Se la risposta è secondi o millisecondi, il protocollo NTP è sufficiente; se la risposta è invece microsecondi o nanosecondi, è necessario PTP (IEEE 1588).

Recentemente ho scritto l’articolo “Perché il PTP è così accurato? (Info: qui)”: il fatto è che con la tecnologia PTP il Time Stamping (la marcatura temporale)  è attuato a livello hardware, mentre questo non avviene con l’NTP. L’hardware timestamping è permesso nei client e nei server che utilizzano l’NTP, ma quasi nessuno dei dispositivi che utilizzano questo protocollo implementano questa funzione. 

La causa primaria di errore nel trasporto della temporizzazione è dovuta alle variazioni delle code che si determinano negli ingressi di routers o switches. Il protocollo NTP non è in grado di gestire questi ritardi, mentre il PTP lo è.

La soluzione consiste nell’utilizzare routers o switches dedicati per il PTP chiamati Transparent Clocks o Boundary Clocks. A breve analizzeremo questi dispositivi anche sul nostro blog.

Se l’obiettivo è quello di sincronizzare i dispositivi con accuratezza di qualche millisecondo, l’NTP è sufficiente; ma se il PTP è più accurato perché non usarlo sempre ? La risposta è cheil protocollo NTP è più facile ad attuarsi, perché gratuito e già disponibile in ogni PC , router o switch presente sul mercato; per il client è sufficiente interrogare il Time Server (LANTIME) e si riceve una risposta. 

 

E’ anche possibile scaricare ed installare SW specifici che contengono liste di Time Server disponibili (e relativo indirizzo IP) che possono essere usati come soluzioni di back-up o di emergenza per particolari situazioni (ad esempio la rete deve avere un accesso all’esterno, in caso di rete privata o chiusa questo non è possibile).

Il protocollo NTP è più economico perché non richiede switches particolari. Molti integratori infatti acquistano server dedicati (come i Time Server Meinberg della famiglia LANTIME) per liberarsi dal problema di dover integrare ricevitori GPS dedicati (per ottenere il tempo accurato) e ricrearsi il sincronismo NTP. Ogni Time Server Meinberg infatti può quindi gestire migliaia (o anche più) di clients sd averli tutti sincronizzati.

Continue reading
757 Hits
0 Comments

Temporizzazione Accurata per le prossime generazioni dei sistemi di generazione d’energia

La riduzione dei gas-serra, tra le cause primarie del surriscaldamento globale, è uno degli obiettivi primari oggigiorno. La produzione di energia elettrica causa approssimativamente il 25% delle emissioni di gas-serra; per questo i fornitori di energia devono rivedere il modo di generare e distribuirla. Un aspetto è la Smart Grid, un concetto del 21° secolo avente l’obiettivo di ridurre le emissioni, usando maggiormente energie sostenibili e contemporaneamente soddisfare la crescente domanda di energia elettrica. Tramite le azioni integrate di tutti i giocatori in campo - produttori, distributori, utilizzatori - la Smart Grid combina prodotti innovativi e servizi con avanzate azioni di monitoraggio, controllo, autocorrezione e comunicazione a 2 vie.

Continue reading
357 Hits
0 Comments