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

Sincron Sistemi - Hunting the White Rabbit

Sincron Sistemi - Hunting the White Rabbit

Sincron Sistemi Srl è lieta di annunciare di avere raggiunto l'accordo per la distribuzione in esclusiva sul territorio Italiano dei prodotti di Seven Solution.

Seven Solution è un’azienda Spagnola, con sede a Granada, che sviluppa da oltre 8 anni soluzioni basate sulla tecnologia White Rabbit che permette il trasferimento del sincronismo con una accuratezza che raggiunge il sub-nano secondo.

La tecnologia White Rabbit è nata nel settore scientifico della ricerca ed stata sviluppata e fortemente promossa da istituti di ricerca come il CERN ed ora sta pian piano entrando a far parte della prossima generazione di reti di telecomunicazioni e diverse applicazioni industriali.

 

Soluzione

Questa partnership permetterà a Sincron Sistemi di integrare ed ampliare ulteriormente la propria offerta di prodotti relativi alla sincronizzazione : a partire dalle soluzioni di Stratum 1 con ricevitori GNSS (GPS, Galileo, Glonass e BeiDou) e con la possibilità di integrare diverse tipologie di oscillatori (dagli OCXO alle soluzioni Rubidio) fornite da Meinberg, per essere poi in grado di distribuire il segnale di tempo generato dall’unità Meinberg con una accuratezza sub-nano secondo attraverso gli apparati Seven Solution.

Una volta terminato il collegamento White Rabbit tra i due o più Switches di Seven Solution (quindi anche dopo diverse decine di Km, oppure centinaia di Km nel caso di più rilanci) si potrà avere nuovamente localmente a disposizione diversi tipi di segnali legacy di sincronismo, come il PPS il 10 MHz ed il PTP per sincronizzare la rete locale, direttamente dai dispositivi Seven Solution.

Le opzioni non finiscono qui : grazie alle soluzioni di integrazione di Sincron Sistemi, nel sito remoto un dispositivo Meinberg  potrà gestire una notevole pluralità di utenti ed anche costituire sorgente ridondante ed alternativa, mediante l’ingresso Multi Reference Source. A questo punto possono essere rigenerati i più svariati segnali tipo PTPv2 con qualsiasi profilo (dal profilo default IEEE 1588v2 PTPv2, al profilo Power IEC 61850-9-3, ai profili Telecom ITU-T G.8265.1, ITU-T G.8275.1, ITU-T G.8275.2 ai profili Broadcast SMPTE ST 2059-2 o Enterprise), grazie alla ampia disponibilità e varietà di moduli di Output presenti nelle soluzioni IMS di Meinberg, il tutto senza avere la necessità di avere una ulteriore antenna.

 

Scenario

Questa tipologia di progetto potrebbe essere perfetta per tutte le applicazioni dove non è fisicamente possibile installare un’antenna nel punto di destinazione finale  (come per esempio per determinati edifici classificati come storici con vincoli dei beni culturali) oppure come seconda fonte di sincronismo (con una funzione di anti-jamming o anti-spoofing visto che le sorgenti di riferimento potranno essere anche a decine e decine di Km ed in zone di sicurezza e/o di disaster recovery).

Il sistema può essere ulteriormente espanso nel caso in cui il server o l'unità da sincronizzare sia sprovvista di scheda Hardware dedicata per il PTP v2, in questo caso infatti si potrà inserire una NIC dedicata di Oregano Solutions (sempre distributa da Sincron Sistemi) in modo tale da avere un Time Stamp hardware ed un’accuratezza maggiore lato slave PTPv2, oppure si potrà di utilizzare lo stack per il PTPv2 via software (IEEE 1588-2008 Client Software for Windows and Linux ) con il nuovo pacchetto messo a disposizione da Meinberg proprio in collaborazione con Oregano.

 

Conclusione

Riassumendo, ecco alcuni punti di forza della tecnologia White Rabbit:

  • Risparmio del Time-Budget in collegamenti inter-metropolitani con la possibilità di raggiungere un’accuratezza sub-nano secondo

  • Jamming and Spoofing protection

  • Un’ampia, uniforme ed ultra-accurata sincronizzazione di tutti i server all’interno di un datacenter senza nessun vincolo di distanza (conformità MiFID II)

  • Cross validation della reference di tempo nella core networks degli operatori Telecom (5G)

  • Accuratezza sub-nano secondo per applicazioni di ricerca/scientifica ove siano richiesti tali livelli di accuratezza

Una possibile applicazione e lo scenario futuro dell’utilizzo del protocollo White Rabbit, sarà sicuramente quello del Time As a Service e cioè della propagazione del segnale di riferimento di tempo e frequenza attraverso Fibra Ottica e la realizzazione di vere e proprie reti che potranno fornire il segnale temporale (magari anche certificato UTC attraverso la collaborazione con determinati istituti metrologici di riferimento) per i settori come aerospazio, telecomunicazioni, tarature, smart grid, finanza ed e-commerce, che hanno sempre più bisogno di riferimenti di tempo e frequenza ad alta precisione.

Tutti questi temi saranno trattati ed approfonditi in futuro sul blog di Sincron Sistemi, ma per ulteriori informazioni e/o necessità vi invitiamo a contattarci direttamente.

Vuoi approfondire questo articolo?
Contattaci...

Continue reading
226 Hits
0 Comments

Ethernet Switches e supporto PTP

High End Ethernet Switches & PTP support

Articolo pubblicato su Linkedin - 1 Febbraio 2018
by Heiko Gerstung - Managing Director at Meinberg

 

Introduzione

Sono milioni gli switch installati nei data center del pianeta, buona parte di loro con caratteristiche che cercano di ottimizzare l’uso della banda, della capacità d’uscita così come della gestione,  della sicurezza, affidabilità ed efficienza. Molti di loro non hanno nulla a che fare con il PTP, ma tipicamente supportano l’NTP per mantenere il proprio timing interno allineato con gli altri dispositivi in rete, consentendo quindi di correlare i file d’ingresso ed assicurare le certificazioni richieste.

Diversamente da NTP, il PTP nella sua corrente versione IEEE1588-2008 ( è attesa una revisione nel 2018) specifica come gli Ethernet Bridges (nome ufficiale degli switches) possano supportare la sincronizzazione di tempo nella rete, riducendo e/o rimuovendo le variazioni del ritardo causato dallo switch stesso. Lo standard PTP definisce il concetto di boundary clock e quello di transparent clock (http://blog.meinbergglobal.com/2013/10/21/ieee-1588-clock-types/) fornendo una soluzione che riduce notevolmente gli errori di tempo dovuti ai PTP slave in una rete composta da switches conformi al protocollo PTP.

Ovviamente gli switch PTP sono molto più costosi di quelli non “PTP aware”. Meinberg/Sincron-Sistemi lavorano con clienti di diversi settori industriali che necessitano del PTP per le loro applicazioni , come ad esempio le Smart Grid dell’energia, reti Telecom, Broadcast e tutto il mondo Finanziario.

 

Caso reale e mondiale : il settore finanziario

Nel Settore finanziario c’è una forte richiesta di accuratezza ti tempo per diverse ragioni. Recentemente una delle motivazioni più significative è stata la nuova edizione del “Markets in Financial Instruments Directive” dell’Unione Europea, più comunemente noto come “MiFID II”. Questa direttiva introduce nuove imposizioni legali e definisce l’accuratezza temporale da applicarsi agli operatori e traders finanziari ; le linee guida per l’attuazione della MiFID II richiedono chiaramente il preciso monitoraggio della sincronizzazione.

In aggiunta alle esigenze strettamente legali, molte istituzioni finanziarie necessitano di infrastrutture di rete PTP conformi per loro esigenze operative : per esempio high speed & algorithmic trading necessitano di ridurre al minimo la latenza, per ottenere vantaggi operativi sul mercato; questo richiede a sua volta perfetto sincronismo, sovente submicrosecondo, dei sistemi in rete.

 

3 pesanti problemi sul PTP negli switches Ethernet

Siccome il supporto PTP è oggettivamente una prestazione critica che si trova solo negli switches più costosi, ci si sarebbe aspettato che i diversi costruttori avessero convenuto su uno standard e quindi gli utenti non avessero riscontrato problemi nel gestire le diverse marche.

Purtroppo non è così : riceviamo continuamente reports da clienti che si trovano ad affrontare problemi nella realizzazione della rete PTP. L’elenco dei problemi che i nostri clienti si trovano ad affrontare è sorprendentemente lunga e sorprende anche noi. Ecco nel seguito i 3 più significativi problemi da noi affrontati.

 

Problema 1 ) Non è standard il “Best Master Clock Algorithm”

È sorprendente che un prodotto che vanta l’etichetta IEEE1588-2008 non attui correttamente la sua funzione basica : l’algoritmo di selezione del clock, appunto denominato BMCA (Best Master Clock Algorithm). Lo standard è piuttosto chiaro e diretto nella descrizione che assicura che, per ogni dominio PTP, ci sia 1 solo Master Clock autorizzato ad inviare messaggi di sincronizzazione a tutti gli utenti PTP in rete.

Meinberg partecipa a tutti gli eventi di interoperabilità da oltre 10 anni, verificando la compatibilità dei propri prodotti in reti PTP aventi Switches multivendor.  Dopo un così lungo periodo ci si sarebbe aspettato che questa importante caratteristica per le operazioni PTP multicast/ibrido fosse correttamente attuata, specialmente per la gamma alta degli Switches PTP.

 

Problema 2) limitate opzioni  di configurazioni PTP

Lo standard IEEE1588-2008 introduce il concetto di “profilo PTP”; il profilo sostanzialmente definisce quale modo di operatività, descritto nello standard medesimo, viene utilizzata (i.e. multicast level2 con misura del ritardo end to end). Tale profilo è per sé stesso uno standard; ad esempio nel settore dell’Energia il profilo utilizzato è IEEE C37.238; nel mondo broadcast è SMPTE-2059-2; ed inoltre definisce per impostazione predefinita i parametri PTP da utilizzare.

Purtroppo talune implementazioni di profili PTP inseriscono di default certi parametri e non ne consentono la modifica, anche se il profilo definisce una lista di valori utilizzabili che però non compaiono nella lista di default.

Il risultato è che il dispositivo non opera correttamente con altri in rete e rigetta il master clock o addirittura non lo vede; per esempio il profilo consente l’uso di un certo numero di domini PTP ma lo switch non ha la possibilità di modificare il proprio numero di dominio e quindi usa quello di default. Siccome vanno ignorati tutti quei messaggi PTP con lo stesso numero di dominio, lo stack PTP di quello specifico switch ignorerà tutti i messaggi provenienti da quel nodo.

 

Problema 3) Erroneo scarto di frame PTP

Un problema molto comune con l'implementazione del PTP negli switch boundary clock (e questo include alcuni noti fornitori) è che i pacchetti PTP o frame Ethernet che non devono essere gestiti dallo switch boundary clock vengono scartati quando entrano nello switch. Un modello comune sembra essere che lo switch può essere configurato per identificare specifici pacchetti / frame che poi vengono inoltrati alla CPU di gestione invece di essere inoltrati sullo switching plane (che è ciò che tipicamente accade con tutti i frame e pacchetti non richiesti dalla CPU di gestione).

Sfortunatamente, un certo numero di produttori di switch ha scelto di impostare filtri molto semplici per identificare un pacchetto PTP, ad esempio: "if udp.port == 319 then redirect_to_CPU". Il problema con questo approccio è che tutti i frame PTP vengono reindirizzati alla CPU dello switch.

Anche nelle reti multicast o ibride (ad esempio le reti PTP con il profilo Enterprise), ciò influisce sui Management messages PTP che hanno un targetPortId diverso da quelli di cui è responsabile il Boundary Clock. Include anche pacchetti con un numero di dominio PTP diverso da quelli utilizzati nell'implementazione PTP dello switch.

 

Il risultato dell'implementazione di filtri troppo semplici o ampi per catturare i pacchetti PTP:

Lo stack PTP sulla CPU di gestione riceve i frame dallo switching plane, scopre che non è interessato (perché il dominio PTP non corrisponde o il pacchetto ha un indirizzo di destinazione sconosciuto alla CPU) e - avete indovinato - semplicemente scarta il pacchetto. Questo crea una specie di firewall PTP che blocca tutto il traffico PTP non destinato a essere utilizzato dallo switch stesso. Chiaramente una "caratteristica" che la maggior parte dei clienti con configurazioni PTP più sofisticate non apprezza.

 

Come affrontare il problema?

Secondo i membri del gruppo di lavoro IEEE 802.1, il numero #3 è una violazione IEEE 802.1Q quando il nodo all'origine di un errore è uno switch. Inoltre, altri problemi violano lo stesso IEEE 1588-2008 o gli standard che definiscono il profilo. Un comportamento non conforme di un prodotto che dichiara di essere conforme deve essere considerato un bug dal fornitore di switch. Ma anche se i datasheet degli switch interessati non dichiarano chiaramente una piena conformità a questi standard, mi aspetterei che il fornitore risolvesse alcuni problemi semplicemente perché i loro clienti ne soffrono e ciò inoltre limita l'usabilità dei prodotti, per non parlare dei problemi che devono affrontare tutti gli altri vendors conformi agli standard presenti in rete.

Con grande sorpresa ci siamo accorti che i nostri clienti avevano difficoltà a convincere i loro fornitori di switch a risolvere queste problematiche. Sebbene alcuni vendors abbiano iniziato a lavorare sulle correzioni e siano riusciti a risolvere almeno alcuni dei problemi riscontrati, le tempistiche sono solitamente piuttosto importanti. Molto spesso ciò richiede l'instaurazione di una telefonata congiunta con il fornitore di switch, noi e il nostro cliente. Le cose iniziano a muoversi quando, durante queste conferenze telefoniche, spieghiamo il problema, il produttore di switch lo comprende e cosa più importante, il cliente conferma che si tratta di un problema.

Tuttavia, spesso occorrono settimane o mesi prima che una nuova versione del firmware per il modello di switch interessato sia disponibile per i test. Durante questo periodo, proviamo a sviluppare soluzioni alternative per consentire al cliente di monitorare i propri dispositivi PTP per la conformità con MiFID II o aiutarli a creare una configurazione di rete che consenta loro di utilizzare PTP unicast e multicast in parallelo o più domini PTP nonostante il loro super economico switch Ethernet a bassissima latenza “mangia” ogni singolo pacchetto PTP che non interpreta correttamente.

 

E voi?

Sulla base delle nostre discussioni con i nostri clienti, sappiamo che la qualità delle implementazioni PTP sugli switch è molto spesso un problema. La reazione dei venditori di switch sembra indicare che non considerano questo un problema diffuso che coinvolge molti dei loro utenti. Questo può essere vero fino a un certo punto, poiché PTP non è certamente una tecnologia ampiamente utilizzata ad oggi. Naturalmente, in generale si desidera correggere le cose che riguardano i clienti, anche se si tratta solo di una piccola fetta della vostra base utenti.

Meinberg è interessata a conoscere la vostra percezione riguardo alla qualità e all'affidabilità dell'implementazione PTP presente sui vostri switch preferiti.

In qualità di Sincron Sistemi invece possiamo informarvi che, se stai affrontando i problemi sopra descritti o hai a che fare con altri problemi riguardanti il PTP che ti rendono la vita più difficile o ti impediscono di utilizzare questa tecnologia a vantaggio della tua applicazione, saremo lieti di assisterti o guidarti nelle scelte tecnologiche.

In qualsiasi caso, siamo in attesa di ricevere i vostri feedback!

Vuoi approfondire questo articolo?
Contattaci...

Continue reading
226 Hits
0 Comments

Meinberg Trusted Source - Fonte attendibile

TRS "Fonte attendibile" - Meinberg Trusted Source

Articolo pubblicato sul blog Meinerg - By Andreja Jarc

Dalla versione firmware 6.24 in poi è disponibile una nuova funzionalità chiamata Trusted Source. Questa funzionalità aggiuntiva è attesa da tutti coloro che sono alla ricerca di un metodo che aiuti a mitigare le vulnerabilità del segnale GPS.

Anomalie nella temporizzazione GPS causate da falsi segnali di spoofing e/o trasmissione di dati errati da parte del sistema GPS stesso, come osservato il 26 gennaio 2016, portano alla perdita di ricezione o addirittura alla modifica dell’orario di un ricevitore sincronizzato GPS, se non sono state prese ulteriori misure preso per mitigare l'influenza di questi effetti. Meinberg ha implementato il cosiddetto metodo "fonte attendibile" (TRS) - che consente di collegare una o più fonti di tempo aggiuntive a un ricevitore GPS. La funzionalità di questo controllo richiede l’utilizzo di un ricevitore MRS (Multi Reference Source- https://blog.meinbergglobal.com/2017/11/16/multi-reference-clock/ ).

Il metodo TRS è supportato nei sistemi Meinberg LANTIME in combinazione con un XHE Rubidium esterno collegato al ricevitore GPS. Il TRS consente controlli di coerenza più approfonditi del tempo ricevuto.

Figura 1: Impostazione di una fonte attendibile che include LANTIME M3000 con ricevitore GPS180 e un dispositivo XHE Rubidium. Nel normale funzionamento, il Rubidio esterno viene guidato da PPS proveniente dall'orologio GPS. Nei periodi di permanenza, d'altra parte, il Rubidio diventa una fonte principale e dirige l'orologio di riferimento con il suo PPS.

Il Rubidio esterno funge da buffer di holdover rimanendo sincronizzato dal Master MRS fino a quando lo stesso è attendibile. Se il Master GPS fallisce o se il GPS per qualche motivo inizia a fornire dati corrotti, il TRS lo rileva come una violazione del limite di offset. Di conseguenza, l'algoritmo di selezione di riferimento scarterà il master corrente e la sorgente XHE di rubidio diventerà il nuovo master per la sincronizzazione.
Quando il segnale GPS ritorna al normale funzionamento e la differenza di orario ritorna sotto il limite TRS, il GPS diventa nuovamente la sorgente principale.

 

Come configurare la feature TRS in un LANTIME

Di seguito tutti i passaggi su come configurare la modalità TRS nel tuo LANTIME.

Innanzitutto, la sorgente GPS deve essere selezionata come sorgente 1 nell'elenco prioritario e "ext. OSC "(riferito a XHE Rubidium) dovrebbe essere configurato come priorità 2. Tutti gli altri livelli di priorità dovrebbero essere lasciati non configurati. Queste impostazioni sono disponibili dall’interfaccia grafica: LANTIME Web GUI-> Clock->GNS Clock->Source Priority

Figura 2: Elenco delle priorità con GPS e ext. Osc. in MRS Settings.

In secondo luogo, dovrebbe essere attivato l'algoritmo di selezione dei riferimenti (IRSA).
Configuriamo un limite TRS che la sorgente GPS Master deve rispettare nel campo Precision. Nel nostro esempio abbiamo configurato 250 ns che è la deviazione di tempo massima consentita del ricevitore GPS.

Figura 3: limite di offset TRS per il ricevitore GPS.

Terzo, la modalità TRS dovrebbe essere abilitata selezionando "Use Trusted Source" per il master GPS. (LANTIME Web GUI-> Clock-> GNS Clock-> Features). Il rubidio deve essere configurato come “Is Trusted Source”.

Figura 4: attivazione della modalità di funzionamento TRS.

Infine, la sorgente GPS dovrebbe avere abilitato "Time of Day Source” e “Phase Source", il che significa che il GPS è una fonte sia per l'Ora del giorno che per la Fase. Al rubidio dovrebbe essere abilitata solo la “Phase Source”, dato che l'orologio atomico da solo non fornisce informazioni sull'ora del giorno.

Figura 5: selezione delle informazioni sull'ora del giorno e sulla fase.

È possibile monitorare l'operazione TRS in MRS Status. Finché l'intervallo di tempo tra GPS e XHE non supera il valore di precisione GPS, lo stato di funzionamento normale viene mostrato come di seguito.

Figura 6: informazioni sullo stato nel normale funzionamento (normal operation).

Quando il limite TRS viene violato, l'algoritmo di riferimento scarta il master corrente e passa automaticamente a "ext. La modalità di backup OSC "(cioè XHE Rubidium) e il flag" TRS Limit violated "viene visualizzato nelle informazioni di stato della sorgente GPS.
La violazione TRS è elencata anche nelle matrici degli eventi di notifica e può essere attivata per il monitoraggio.

Figura 7: Selezione degli eventi di notifica per l'allarme e il monitoraggio dell'operazione TRS.

Permettetemi di ringraziare Andre Hartmann, l'amministratore delegato di Ricerca & Sviluppo in Meinberg per aver fornito l'esperienza tecnica per lo sviluppo della funzionalità TRS. Spero che questo post sia stato utile e rimaniamo a disposizione in caso di necessità.

Vuoi approfondire questo articolo?
Contattaci...

Continue reading
216 Hits
0 Comments

Sincron Sistemi and Seven Solutions stablish a partnership in Italy towards addressing industrial deployment of Ultra-accurate time transfer using White Rabbit

Sincron Sistemi and Seven Solutions  stablish a partnership in Italy towards addressing industrial deployment of Ultra-accurate time transfer using White Rabbit

Seven Solutions, the world’s leader in ultra-accurate timing distribution and synchronization announced today an exclusive distributor agreement with Sincron Sistemi to address sectors such as Defense, Finance, Telecommunications, Science and Smart Grid in the Italian market.

Seven Solutions, has been developing White Rabbit as an ultra-accurate time transfer and synchronization solution for the last 8 years and deployed it all around the world in many scientific and industrial facilities, pushing the boundaries in deterministic synchronization over Ethernet-based networks to the nanosecond range. The White Rabbit technology was born in the high-energy physics segment, mainly pushed by leading scientific organisms such as CERN and now is part of the next generation of telecommunication networks and industrial markets.

Sincron Sistemi is leader in Italy in efficiently adapting, integrating and supporting high end technological international solutions for diverse market segments. They are one of the leaders in Italy in Timing and Synchronization systems integrating solutions also from other international timing system leaders. Sincron Sistemi has intensively tested the performance of Seven Solutions equipment with different experimental network topologies and measurement equipment. The obtained performance is outstanding in terms of time distribution accuracy in the range of the nanosecond which matches the most demanding customers’ requirements in different segments. The ultra-accurate time distribution capability of Seven Solutions allows meeting the requirements of 5G networks and many others high level and scientific projects.

This agreement between Seven Solutions and Sincron Sistemi will marry the best integration and support capabilities of Sincron Sistemi in the Italian market with the best-of-breed White Rabbit products of Seven Solutions to enable a highly demanding timing segment to natively integrate nanosecond synchronization capabilities and deterministic timing. This collaboration integrates the advantages of the time transfer and synchronization outstanding performance of Seven Solutions products with the technical support and integration capability of Sincron Sistemi for end customers in Italy.

Eduardo Ros, COO of Seven Solutions, said “White Rabbit is a smart solution for ultra-accurate time distribution and synchronization able to fulfill the most advanced needs for the incoming industrial timing. This new agreement with Sincron Sistemi will enable fast adaptation and integration in Italy by customers in different industrial segments such as new solutions for defense, Telecom and finance markets”.

Franco Baroncini of Sincron Sistemi Corporation, adds “We’re really proud of this collaboration between Sincron Sistemi and Seven Solution. This collaboration will allow us to provide to our customer a complete synchronization newtwork with the highest performance and standard that are now available on the market!

About Seven Solutions

Seven Solutions S.L. is the worldwide leader of ultra-accurate time distribution and synchronization solutions through White Rabbit technology. The company got involved in its development from the very early stages towards translating the concept into actual outstanding time distribution product and now accounts for more than 7 years of expertise in its development, customization, deployment and more than 200 customers worldwide as early adopters of our solutions powered by White Rabbit technology. In addition to the most advanced White-Rabbit equipment, Seven Solutions provides calibration, deployment and support for setting up telecommunication networks at datacenters or over networks of hundreds of kilometers and thousands of nodes. This enables the provision of next generation of deterministic industrial timing based on IEEE-1588 protocols and Ethernet networks. .

Acknowledgments

Seven Solutions has received funding from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (grant agreement n° 725490)

About Sincron Sistemi Coporation

Sincron Sistemi Srl it is primarily focused at the commercialization of instruments and systems for Time and Frequency synchronization.

Thanks to the high level of quality of our representatives and the experience gained during our 25 years of activity in the sector, Sincron Sistemi is able to assist customers in the different stages of the project: from the design phase, to the installation of the units until the final activation and trainings of equipments on the network in the Italian market.

Sincron Sistemi's expertise ranges from traditional legacy synchronization technologies (such as E1, IRIG, NTP, PPM, 10 MHz signals) through the reception of GNSS signals such as GPS, Glonass, Beidou and  Galileo, to the latest solutions and innovative, non-satellite, like the PTP / IEEE 1588 and the Ethernet sync and now, thanks to this collaboration, to the White Rabbit.

Continue reading
244 Hits
0 Comments

SMPTE ST2110

SMPTE ST2110 - Professional Media Over Managed IP Networks

La suite SMPTE ST 2110 è il fattore di maggior rilevanza nel movimento verso un conosciuto protocollo internet basato su IP per le industrie media professionali.

Cosa significherà l'adozione di SMPTE ST 2110 per le industrie?
L'impatto va oltre il solo rimpiazzo delle interfacce seriali (SDI). Con il concetto di IP si avrà la flessibilità per emergere con un intero set di applicazioni basate su protocolli e infrastruttura IT (information technology).

E riguardo Ultra HD, 4K, 8K e high-dynamic-range (HDR)?
Si! SMPTE ST 2110 supporta le tecnologie Ultra HD, HDR, e altri nuovi formati emergenti.

Le applicazioni professionali trovano luogo soprattutto in questi ambiti:

  • Film/Broadcast/OTT production and postproduction
  • Theme parks (show control, image, and sound)
  • Live event production, such as concert production and sport venues (show control, image, sound, video displays, and pyrotechnics)
  • Museums (large audio/video displays)
  • Digital advertising (such as in Times Square)
  • Digital (internet) release production and postproduction
  • Media research 
  • Contribution
  • Primary distribution
  • Playout
    Ma non solo...

Meinberg, ancora una volta dimostra di potersi posizionare tra i principali leader di mercato. Le soluzioni proposte dall'azienda tedesca possono essere viste in alcuni Booth rilevanti come Arista, Nevion, Axon ma soprattutto, sincronizzando l'IP Showcase dimostrano l'interoperabilità dei prodotti con le tecnologie disponibili in commercio.

Tra i partner Meinberg, nel settore entertainment ci sono RAVENNA e SMPTE: Society of Motion Picture and Television Engineers.

Come Sincron Sistemi può aiutarti in questa transizione?

• ST 2110 consente il routing separato di Video, Audio attraverso IP
• ST 2110 utilizza/richiede l'utilizzo del protocollo ST2059 PTP per il timing

Sincron Sistemi può proporvi la soluzione più adatta alle vostre esigenze per quanto riguarda la sincronizzazione PTP, assistervi nella configurazione e migrazione verso questa nuova tecnologia e nell'integrazione dei dispositivi all'interno della vostra infrastruttura IT.

Inoltre, attraverso alcune partnership consolidate con aziende che operano nel settore IT, siamo in grado di offrirvi una soluzione di sincronizzazione PTP via IP "chiavi in mano" (GrandMaster + Switches di rete a bassa latenza).

Per maggiori informazioni non  esitate a contattarci e saremo lieti di assistervi.

 

Continue reading
432 Hits
0 Comments

GPS - Rischio di blocco/disturbo (jamming/spoofing)

Crescono gli episodi di disturbo e falsificazione del segnale causati da test militari. Sospetti sui russi.


Perché? Di che si tratta ma soprattutto COME TUTELARSI?

Rif. articolo pubblicato il 09/10/2017 - LA STAMPA
http://www.lastampa.it/2017/10/09/societa/cyberguerriglia-gps-fuori-uso-su-aerei-e-navi-forse-test-militari-htQIS8nclYFn2GTyHvHbAI/pagina.html

Recentemente sono aumentati i casi di disturbo e falsificazione del segnale GPS: alcuni aerei di linea in Norvegia non hanno potuto usare per diversi giorni il sistema Gps, lo strano caso delle navi «spostate», altri episodi di segnale disturbato segnalati da molti cittadini a Mosca.
Si tratta di un sistema fragile?
Di sicuro, la fragilità del sistema satellitare ad attacchi aveva già messo in allarme gli esperti. Tanto che lo scorso aprile il Dipartimento di sicurezza nazionale statunitense aveva organizzato un evento per testare i ricevitori GPS di vari produttori e il rischio di blocco/disturbo (jamming) o falsificazione (spoofing) del segnale.

Come è possibile tutelarsi?

L'idea di basare la sicurezza dei propri sistemi su una piattaforma potenzialmente vulnerabile, può spaventare.
Tuttavia, attualmente in commercio ci sono soluzioni che incrementano la sicurezza e la disponibilità del servizio: si tratta di creare una ridondanza acquisendo l'informazione da più sorgenti distinte.

  • Rimanendo in ambito spaziale si possono utilizzare ricevitori multi-costellazione  che consentono la ricezione, anche mediata, del GPS, Glonass, Beidou e Galileo.
  • Ricezione con FO dedicata dei segnali di tempo emesso da INRIM (Istituto Nazionale di Ricerca Metrologica).
  • Ricezione via Ethernet del sincronismo PTP emesso un centro prestabilito.

Per maggiori informazioni o per approfondimenti non esitate a contattarci e saremo lieti di mostrarvi le soluzioni indicate sopra.

Continue reading
469 Hits
0 Comments

Nuova edizione del protocollo IEEE 1588 - Work in progress

Cosa porterà con sé la nuova edizione del protocollo IEEE 1588?

Traduzione dell'articolo pubblicato il 24 Settembre 2017 sul blog Meinberg a cura di Douglas Arnold (Co-Chair of the IEEE 1588 Working Group, Co-Chair of the IEEE 1588 Architecture Subcommittee,  and a Co-Chair of the ISPCS IEEE 1588 Plugfest Committee).

La nuova edizione del protocollo PTP è al completo per quanto riguarda le funzionalità disponibli. Stiamo ancora lavorando sulla rifinitura del linguaggio. Il tutto, sarà pubblicato nel 2018. Quindi, qual’è la prossima mossa? Tutto ciò che è stato cambiato o che è stato aggiunto fu fatto con lo scopo di:

  • Rendere questo standard più chiaro e comprensibile

  • Aggiungere maggiore flessibilità al protocollo

  • Rendere il protocollo più robusto

  • Incrementare l’accuratezza

Alcuni di questi cambiamenti sono stati estratti dai profili PTP esistenti. Gli autori dei profili PTP hanno trovato alcune caratteristiche sono troppo belle per essere riservate ad una singola industria o settore. Poco fa vi ho detto quali sono le nuove funzionalità. Ora vorrei citare The Hitchhiker’s Guide to the Galaxy, dicendo: DON’T PANIC

Tutto il tempo, le risorse e i soldi spesi sul PTPv2 non sono andati persi.
La nuova versione sarà compatibile con la precedente. Lo consideravamo talmente importante che abbiamo scritto nel gruppo di lavoro IEEE 1588:
“Il gruppo di lavoro deve assicurare che il progetto risultante abbia il più alto grado di retrocompatibilità possibile rispetto alla precedente edizione del protocollo IEEE 1588”.


Per rendere questo concetto chiaro ci stiamo riferendo alla nuova versione del protocollo PTP come PTPv2.1. Solo una minor revision; non un grosso problema.  Ma una minor revision con tante nuove opzioni interessanti. Abbiamo pensato alla retrocompatibilità in questo modo: è possibile estrarre un dispositivo PTPv2 fuori dalla rete e sostituirlo con un dispositivo PTPv2.1, e la rete lavorerà esattamente come prima. Oppure puoi prendere un dispositivo PTPv2 dallo scaffale e aggiungerlo in una rete PTPv2.1, e sarà in grado di funzionare regolarmente, a meno che il vecchio dispositivo non debba eseguire una delle nuove opzioni non supportate.

Ok. Quindi, quali sono queste opzioni?

Le trovate elencate di seguito suddivise per categoria:

Per la flessibilità:

  • Modular Transparent clocks.  TCs che possono essere facilmente which can be integrati in un server blade, o in una architettura SFP.

  • Porte PTP speciali per interfacciarsi con tecnologie che hanno i loro meccanismi di timing come per esempio il WiFi.

  • Mixed Multicast/Unicast operation.  Di solito questo significa che i messaggi di Announce e Sync sono multicast, mentre DelayRequest e Delay Response sono unicast.

Opzioni per l’accuratezza:

  • Configurazione manuale delle porte: Senza bisogno di utilizzare BMCA.

  • Asymmetry calibration.

  • Physical layer syntonization.

Queste sono tre chiavi aggiuntive per l’estensione del PTP White Rabbit. Utilizzando queste funzionalità i più abili Using these feature the clever scienziati al CERN sono stati in grado di ottenere un tempo di trasferimento nell’ordine dei sub-ns, utilizzando lo standard Ethernet PHYs.

Opzioni per la robustezza:

  • Isolamento del profilo. Eseguire profili incompatibili sulla stessa rete?  Possibile!

  • Interazioni Inter-domain. Vi ricordate qunado vi ho detto che i domini PTP sono indipendenti gli uni dagli altri? Bene, ma in determinate circostanze.

  • Sicurezza. Abbiamo definito una sicurezza TLV per i messaggi e un controllo per l’integrità della fonte. Più un gruppo di linee guida molto utili  sulla sicurezza.

  • Metriche di prestazioni standard. Che ne direste se ogni nodo PTP sulla rete rendesse disponibili statistiche sulle performance nello stesso formato?

  • Save port monitoring. Non trasferite solo il tempo al clock slave ma prova anche di averlo fatto!

Nei prossimo post, descriverò le opzioni precedenti aggiungendo maggiori dettagli. Fino a quel momento, felice sincronizzazione!

Douglas Arnold

 

Per qualsiasi informazione sul PTP non esitate a contattarci compilando il modulo sul nostro sito.

 

Continue reading
458 Hits
0 Comments

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
520 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
596 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
1145 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
625 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
858 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
747 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
1520 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
1394 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
730 Hits
0 Comments