Introducció
El concepte de construcció d'una "subestació digital" a la indústria de l'energia elèctrica requereix una sincronització amb una precisió d'1 μs. Les transaccions financeres també requereixen una precisió de microsegons. En aquestes aplicacions, la precisió del temps NTP ja no és suficient.
El protocol de sincronització PTPv2, descrit per l'estàndard IEEE 1588v2, permet una precisió de sincronització de diverses desenes de nanosegons. PTPv2 us permet enviar paquets de sincronització a través de xarxes L2 i L3.
Les principals àrees on s'utilitza PTPv2 són:
- energia;
- equips de control i mesura;
- complex militar-industrial;
- telecomunicacions;
- sector financer.
Aquesta publicació explica com funciona el protocol de sincronització PTPv2.
Tenim més experiència a la indústria i sovint veiem aquest protocol en aplicacions energètiques. En conseqüència, farem la revisió amb precaució .
Per què és necessari?
Actualment, STO 34.01-21-004-2019 de PJSC Rosseti i STO 56947007-29.240.10.302-2020 de PJSC FGC UES contenen requisits per organitzar un bus de procés amb sincronització horària mitjançant PTPv2.
Això es deu al fet que els terminals de protecció de relés i els dispositius de mesura estan connectats al bus de procés, que transmeten valors instantanis de corrent i tensió a través del bus de procés, mitjançant els anomenats fluxos SV (flujos multicast).
Els terminals de protecció de relés utilitzen aquests valors per implementar la protecció de la badia. Si la precisió de les mesures de temps és petita, algunes proteccions poden funcionar de manera falsa.
Per exemple, les defenses de la selectivitat absoluta poden ser víctimes d'una sincronització horària "dèbil". Sovint, la lògica d'aquestes defenses es basa en una comparació de dues quantitats. Si els valors divergeixen en un valor prou gran, s'activa la protecció. Si aquests valors es mesuren amb una precisió de temps d'1 ms, es pot obtenir una gran diferència on els valors són realment normals si es mesuren amb una precisió d'1 μs.
Versions PTP
El protocol PTP es va descriure originalment l'any 2002 a l'estàndard IEEE 1588-2002 i es va anomenar "Estàndard per a un protocol de sincronització de rellotge de precisió per a sistemes de mesura i control en xarxa". L'any 2008 es va publicar l'estàndard IEEE 1588-2008 actualitzat, que descriu la versió 2 de PTP. Aquesta versió del protocol va millorar la precisió i l'estabilitat, però no va mantenir la compatibilitat amb la primera versió del protocol. A més, el 2019, es va publicar una versió de l'estàndard IEEE 1588-2019, que descriu PTP v2.1. Aquesta versió afegeix millores menors a PTPv2 i és retrocompatible amb PTPv2.
En altres paraules, tenim la següent imatge amb versions:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
-
Incompatible
Incompatible
PTPv2 (IEEE 1588-2008)
Incompatible
-
Compatible
PTPv2.1 (IEEE 1588-2019)
Incompatible
Compatible
-
Però, com sempre, hi ha matisos.
La incompatibilitat entre PTPv1 i PTPv2 significa que un dispositiu habilitat per PTPv1 no es podrà sincronitzar amb un rellotge precís que s'executi a PTPv2. Utilitzen diferents formats de missatge per sincronitzar-se.
Però encara és possible combinar dispositius amb PTPv1 i dispositius amb PTPv2 a la mateixa xarxa. Per aconseguir-ho, alguns fabricants us permeten seleccionar la versió del protocol als ports del rellotge de vora. És a dir, un rellotge de límit es pot sincronitzar mitjançant PTPv2 i encara sincronitzar altres rellotges connectats amb ell mitjançant PTPv1 i PTPv2.
Dispositius PTP. Què són i en què es diferencien?
L'estàndard IEEE 1588v2 descriu diversos tipus de dispositius. Tots ells es mostren a la taula.
Els dispositius es comuniquen entre ells a través d'una LAN mitjançant PTP.
Els dispositius PTP s'anomenen rellotges. Tots els rellotges prenen l'hora exacta del rellotge del gran mestre.
Hi ha 5 tipus de rellotges:
Gran mestre rellotge
La principal font de temps exacte. Sovint està equipat amb una interfície per connectar GPS.
Rellotge ordinari
Un dispositiu d'un sol port que pot ser mestre (rellotge mestre) o esclau (rellotge esclau)
Rellotge mestre (mestre)
Són la font de l'hora exacta amb la qual es sincronitzen altres rellotges
Rellotge esclau
Dispositiu final que es sincronitza des del rellotge mestre
Rellotge de límit
Un dispositiu amb múltiples ports que pot ser un mestre o un esclau.
És a dir, aquests rellotges es poden sincronitzar des del rellotge mestre superior i sincronitzar els rellotges esclaus inferiors.
Rellotge transparent d'extrem a extrem
Un dispositiu amb múltiples ports que no és ni un rellotge mestre ni un esclau. Transmet dades PTP entre dos rellotges.
Quan es transmeten dades, el rellotge transparent corregeix tots els missatges PTP.
La correcció es produeix afegint el temps de retard d'aquest dispositiu al camp de correcció de la capçalera del missatge transmès.
Rellotge transparent peer-to-peer
Un dispositiu amb múltiples ports que no és ni un rellotge mestre ni un esclau.
Transmet dades PTP entre dos rellotges.
Quan es transmeten dades, el rellotge transparent corregeix tots els missatges PTP Sync i Follow_Up (més informació sobre ells a continuació).
La correcció s'aconsegueix afegint al camp de correcció del paquet transmès el retard en el dispositiu transmissor i el retard en el canal de transmissió de dades.
Node de gestió
Un dispositiu que configura i diagnostica altres rellotges
Els rellotges mestre i esclau es sincronitzen mitjançant segells de temps als missatges PTP. Hi ha dos tipus de missatges al protocol PTP:
- Els missatges d'esdeveniment són missatges sincronitzats que impliquen generar una marca de temps en el moment en què s'envia el missatge i en el moment en què es rep.
- Missatges generals: aquests missatges no requereixen marques de temps, però poden contenir marques de temps per a missatges relacionats
Missatges d'esdeveniments
Missatges generals
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Anuncia
Segueix
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Senyalització
Tot tipus de missatges es tractaran amb més detall a continuació.
Problemes bàsics de sincronització
Quan un paquet de sincronització es transmet a través d'una xarxa local, es retarda al commutador i a l'enllaç de dades. Qualsevol canvi produirà un retard d'uns 10 microsegons, cosa inacceptable per a PTPv2. Després de tot, hem d'aconseguir una precisió d'1 μs al dispositiu final. (Això és si estem parlant d'energia. Altres aplicacions poden requerir una major precisió.)
IEEE 1588v2 descriu diversos algorismes de funcionament que us permeten registrar el retard i corregir-lo.
Algorisme de treball
Durant el funcionament normal, el protocol funciona en dues fases.
- Fase 1: establiment de la jerarquia "Rellotge mestre - Rellotge esclau".
- Fase 2: sincronització del rellotge mitjançant un mecanisme d'extrem a extrem o d'igual a igual.
Fase 1 - Establiment de la jerarquia mestre-esclau
Cada port d'un rellotge normal o de vora té un nombre determinat d'estats (rellotge esclau i rellotge mestre). L'estàndard descriu l'algorisme de transició entre aquests estats. En programació, aquest algorisme s'anomena màquina d'estats finits o màquina d'estats (més detalls a Wiki).
Aquesta màquina d'estat utilitza el millor algorisme de rellotge mestre (BMCA) per configurar el mestre quan connecta dos rellotges.
Aquest algorisme permet que el rellotge assumeixi les responsabilitats del rellotge gran mestre quan el rellotge gran mestre aigües amunt perd el senyal GPS, es desconnecta, etc.
Les transicions d'estat segons el BMCA es resumeixen al diagrama següent:
La informació sobre el rellotge a l'altre extrem del "cable" s'envia en un missatge especial (anunciar missatge). Un cop rebuda aquesta informació, s'executa l'algoritme de la màquina d'estats i es fa una comparació per veure quin rellotge és millor. El port del millor rellotge es converteix en el rellotge mestre.
Al diagrama següent es mostra una jerarquia senzilla. Els camins 1, 2, 3, 4, 5 poden contenir un rellotge transparent, però no participen en l'establiment de la jerarquia Rellotge mestre - Rellotge esclau.
Fase 2: sincronitzar els rellotges regulars i de punta
Immediatament després d'establir la jerarquia "Rellotge mestre - Rellotge esclau", comença la fase de sincronització dels rellotges regulars i de límit.
Per sincronitzar, el rellotge mestre envia un missatge que conté una marca de temps als rellotges esclaus.
El rellotge mestre pot ser:
- etapa única;
- de dues etapes.
Els rellotges d'una sola etapa envien un missatge de sincronització per sincronitzar.
Un rellotge de dues etapes utilitza dos missatges per a la sincronització: Sync i Follow_Up.
Es poden utilitzar dos mecanismes per a la fase de sincronització:
- Mecanisme de petició-resposta retardat.
- Mecanisme de mesura del retard entre iguals.
En primer lloc, mirem aquests mecanismes en el cas més senzill: quan no s'utilitzen rellotges transparents.
Mecanisme de petició-resposta retardat
El mecanisme consta de dos passos:
- Mesurar el retard en la transmissió d'un missatge entre el rellotge mestre i el rellotge esclau. Es realitza mitjançant un mecanisme de sol·licitud-resposta de retard.
- Es realitza la correcció del canvi horari exacte.
Mesura de la latència
t1 – Hora d'enviament del missatge de sincronització pel rellotge mestre; t2 – Hora de recepció del missatge de sincronització pel rellotge esclau; t3 – Temps d'enviament de la sol·licitud de retard (Delay_Req) pel rellotge esclau; t4 – Temps de recepció Delay_Req pel rellotge mestre.
Quan el rellotge esclau coneix els temps t1, t2, t3 i t4, pot calcular el retard mitjà a l'hora de transmetre el missatge de sincronització (tmpd). Es calcula de la següent manera:
Quan es transmet un missatge de sincronització i seguiment, es calcula el retard de temps del mestre a l'esclau: t-ms.
Quan es transmeten missatges Delay_Req i Delay_Resp, es calcula el retard de temps de l'esclau al mestre - t-sm.
Si es produeix una certa asimetria entre aquests dos valors, apareix un error en la correcció de la desviació de l'hora exacta. L'error és causat pel fet que el retard calculat és la mitjana dels retards t-ms i t-sm. Si els retards no són iguals entre si, no ajustarem el temps amb precisió.
Correcció de torn horari
Un cop conegut el retard entre el rellotge mestre i el rellotge esclau, el rellotge esclau realitza la correcció de temps.
Els rellotges esclaus utilitzen el missatge de sincronització i un missatge de seguiment opcional per calcular el desplaçament horari exacte quan es transmet un paquet del rellotge mestre als rellotges esclaus. El desplaçament es calcula mitjançant la fórmula següent:
Mecanisme de mesura del retard entre iguals
Aquest mecanisme també utilitza dos passos per a la sincronització:
- Els dispositius mesuren el temps de retard a tots els veïns a través de tots els ports. Per fer-ho utilitzen un mecanisme de retard entre iguals.
- Correcció del canvi horari exacte.
Mesura de la latència entre dispositius que admeten el mode Peer-to-Peer
La latència entre els ports que admeten el mecanisme peer-to-peer es mesura mitjançant els missatges següents:
Quan el port 1 coneix els temps t1, t2, t3 i t4, pot calcular el retard mitjà (tmld). Es calcula mitjançant la fórmula següent:
Aleshores, el port utilitza aquest valor quan calcula el camp d'ajust per a cada missatge de sincronització o missatge de seguiment opcional que passa pel dispositiu.
El retard total serà igual a la suma del retard durant la transmissió a través d'aquest dispositiu, el retard mitjà durant la transmissió a través del canal de dades i el retard que ja conté aquest missatge, habilitat en els dispositius upstream.
Els missatges Pdelay_Req, Pdelay_Resp i Pdelay_Resp_Follow_Up opcionals permeten obtenir el retard de mestre a esclau i d'esclau a mestre (circular).
Qualsevol asimetria entre aquests dos valors introduirà un error de correcció de desplaçament temporal.
Ajustar el canvi horari exacte
Els rellotges esclaus utilitzen un missatge de sincronització i un missatge de seguiment opcional per calcular el desplaçament horari exacte quan es transmet un paquet del rellotge mestre als rellotges esclaus. El desplaçament es calcula mitjançant la fórmula següent:
Avantatges ajust del mecanisme peer-to-peer: el retard de cada missatge de sincronització o seguiment es calcula a mesura que es transmet a la xarxa. En conseqüència, canviar el camí de transmissió no afectarà de cap manera la precisió de l'ajust.
Quan s'utilitza aquest mecanisme, la sincronització horària no requereix calcular el retard de temps al llarg del camí recorregut pel paquet de sincronització, com es fa a l'intercanvi bàsic. Aquells. Els missatges Delay_Req i Delay_Resp no s'envien. En aquest mètode, el retard entre els rellotges mestre i esclau es suma simplement al camp d'ajust de cada missatge de sincronització o seguiment.
Un altre avantatge és que el rellotge mestre està alliberat de la necessitat de processar missatges Delay_Req.
Modes de funcionament dels rellotges transparents
En conseqüència, aquests eren exemples senzills. Ara suposem que els interruptors apareixen al camí de sincronització.
Si utilitzeu commutadors sense suport PTPv2, el paquet de sincronització es retardarà al commutador aproximadament 10 μs.
Els commutadors que admeten PTPv2 s'anomenen rellotges transparents en terminologia IEEE 1588v2. Els rellotges transparents no es sincronitzen amb el rellotge mestre i no participen en la jerarquia "Rellotge mestre - rellotge esclau", però quan transmeten missatges de sincronització recorden quant de temps van retardar el missatge. Això us permet ajustar el temps de retard.
Els rellotges transparents poden funcionar de dues maneres:
- D'extrem a extrem.
- D'igual a igual.
Extrem a extrem (E2E)
El rellotge transparent E2E emet missatges de sincronització i missatges de seguiment a tots els ports. Fins i tot aquells que estan bloquejats per alguns protocols (per exemple, RSTP).
El commutador recorda la marca de temps quan es va rebre un paquet de sincronització (Follow_Up) al port i quan es va enviar des del port. A partir d'aquestes dues marques de temps, es calcula el temps que triga el commutador a processar el missatge. A la norma, aquest temps s'anomena temps de residència.
El temps de processament s'afegeix al camp correctionField del missatge Sync (rellotge d'un pas) o Follow_Up (rellotge de dos passos).
El rellotge transparent E2E mesura el temps de processament dels missatges Sync i Delay_Req que passen pel commutador. Però és important entendre que el retard de temps entre el rellotge mestre i el rellotge esclau es calcula mitjançant el mecanisme de petició-resposta de retard. Si el rellotge mestre canvia o el camí des del rellotge mestre fins al rellotge esclau canvia, es torna a mesurar el retard. Això augmenta el temps de transició en cas de canvis de xarxa.
El rellotge transparent P2P, a més de mesurar el temps que triga un commutador a processar un missatge, mesura el retard de l'enllaç de dades al seu veí més proper mitjançant un mecanisme de latència de veí.
La latència es mesura en tots els enllaços en ambdues direccions, inclosos els enllaços bloquejats per algun protocol (com ara RSTP). Això us permet calcular immediatament el nou retard en el camí de sincronització si canvia el rellotge de gran mestre o la topologia de la xarxa.
El temps de processament dels missatges mitjançant commutadors i la latència s'acumula quan s'envien missatges de sincronització o de seguiment.
Tipus de suport PTPv2 per commutadors
Els commutadors poden suportar PTPv2:
- programàticament;
- maquinari.
Quan s'implementa el protocol PTPv2 al programari, el commutador sol·licita una marca de temps al microprogramari. El problema és que el microprogramari funciona cíclicament i haureu d'esperar fins que acabi el cicle actual, accepti la sol·licitud de processament i emeti una marca de temps després del cicle següent. Això també trigarà temps i tindrem un retard, encara que no tan significatiu com sense suport de programari per a PTPv2.
Només el suport de maquinari per a PTPv2 us permet mantenir la precisió necessària. En aquest cas, el segell de temps l'emet un ASIC especial, que s'instal·la al port.
Format del missatge
Tots els missatges PTP consten dels camps següents:
- Capçalera: 34 bytes.
- Cos: la mida depèn del tipus de missatge.
- El sufix és opcional.
Header
El camp Capçalera és el mateix per a tots els missatges PTP. La seva mida és de 34 bytes.
Format de camp de capçalera:
tipus de missatge – conté el tipus de missatge que s'està transmetent, per exemple, Sync, Delay_Req, PDelay_Req, etc.
messageLength – conté la mida completa del missatge PTP, incloent la capçalera, el cos i el sufix (però excloent els bytes de farciment).
nombre de domini – determina a quin domini PTP pertany el missatge.
Nom del domini - Es tracta de diversos rellotges diferents recollits en un grup lògic i sincronitzats des d'un rellotge mestre, però no necessàriament sincronitzats amb rellotges que pertanyen a un domini diferent.
banderes – Aquest camp conté diversos indicadors per identificar l'estat del missatge.
camp de correcció – conté el temps de retard en nanosegons. El temps de retard inclou el retard quan es transmet a través del rellotge transparent, així com el retard quan es transmet a través del canal quan s'utilitza el mode Peer-to-Peer.
sourcePortIdentity – aquest camp conté informació sobre quin port s'ha enviat originalment aquest missatge.
ID de seqüència – conté un número d'identificació per a missatges individuals.
controlField – camp d'artefacte =) Es manté de la primera versió de l'estàndard i conté informació sobre el tipus d'aquest missatge. Essencialment el mateix que MessageType, però amb menys opcions.
logMessageInterval – aquest camp ve determinat pel tipus de missatge.
Cos
Com hem comentat anteriorment, hi ha diversos tipus de missatges. Aquests tipus es descriuen a continuació:
Missatge d'anunci
El missatge d'anunci s'utilitza per "informar" dels seus paràmetres a altres rellotges del mateix domini. Aquest missatge us permet configurar una jerarquia de rellotge mestre - rellotge esclau.
Sincronitza el missatge
El missatge de sincronització l'envia el rellotge mestre i conté l'hora del rellotge mestre en el moment en què es va generar el missatge de sincronització. Si el rellotge mestre és de dues etapes, la marca de temps del missatge de sincronització es posarà a 0 i la marca de temps actual s'enviarà al missatge de seguiment associat. El missatge de sincronització s'utilitza per als dos mecanismes de mesura de latència.
El missatge es transmet mitjançant Multicast. Opcionalment, podeu utilitzar Unicast.
Missatge Delay_Req
El format del missatge Delay_Req és idèntic al missatge de sincronització. El rellotge esclau envia Delay_Req. Conté l'hora que el rellotge esclau va enviar Delay_Req. Aquest missatge només s'utilitza per al mecanisme de petició-resposta de retard.
El missatge es transmet mitjançant Multicast. Opcionalment, podeu utilitzar Unicast.
Missatge de seguiment
El missatge Follow_Up l'envia opcionalment el rellotge mestre i conté l'hora d'enviament Sincronitza missatges mestre. Només els rellotges mestres de dues etapes envien el missatge Follow_Up.
El missatge Follow_Up s'utilitza per als dos mecanismes de mesura de latència.
El missatge es transmet mitjançant Multicast. Opcionalment, podeu utilitzar Unicast.
Missatge Delay_Resp
El missatge Delay_Resp l'envia el rellotge mestre. Conté l'hora en què el rellotge mestre va rebre el Delay_Req. Aquest missatge només s'utilitza per al mecanisme de petició-resposta de retard.
El missatge es transmet mitjançant Multicast. Opcionalment, podeu utilitzar Unicast.
Missatge Pdelay_Req
El missatge Pdelay_Req l'envia un dispositiu que demana un retard. Conté l'hora en què s'ha enviat el missatge des del port d'aquest dispositiu. Pdelay_Req només s'utilitza per al mecanisme de mesura del retard veí.
Missatge Pdelay_Resp
El missatge Pdelay_Resp l'envia un dispositiu que ha rebut una sol·licitud de retard. Conté l'hora en què aquest dispositiu ha rebut el missatge Pdelay_Req. El missatge Pdelay_Resp només s'utilitza per al mecanisme de mesura del retard veí.
Missatge Pdelay_Resp_Follow_Up
El missatge Pdelay_Resp_Follow_Up l'envia opcionalment el dispositiu que ha rebut la sol·licitud de retard. Conté l'hora en què aquest dispositiu ha rebut el missatge Pdelay_Req. El missatge Pdelay_Resp_Follow_Up només s'envia mitjançant rellotges mestres de dues etapes.
Aquest missatge també es pot utilitzar per al temps d'execució en lloc d'una marca de temps. El temps d'execució és el temps des que es rep Pdelay-Req fins que s'envia Pdelay_Resp.
Pdelay_Resp_Follow_Up només s'utilitzen per al mecanisme de mesura del retard veí.
Missatges de gestió
Els missatges de control PTP són necessaris per transferir informació entre un o més rellotges i el node de control.
Trasllat a LV
Un missatge PTP es pot transmetre a dos nivells:
- Xarxa: com a part de les dades IP.
- Canal: com a part d'una trama Ethernet.
Transmissió de missatges PTP per UDP per IP a través d'Ethernet
PTP sobre UDP sobre Ethernet
Perfils
PTP té molts paràmetres flexibles que cal configurar. Per exemple:
- Opcions BMCA.
- Mecanisme de mesura de latència.
- Intervals i valors inicials de tots els paràmetres configurables, etc.
I malgrat que hem dit anteriorment que els dispositius PTPv2 són compatibles entre ells, això no és cert. Els dispositius han de tenir la mateixa configuració per poder comunicar-se.
Per això hi ha els anomenats perfils PTPv2. Els perfils són grups de paràmetres configurats i restriccions de protocol definides perquè la sincronització horària es pugui implementar per a una aplicació específica.
El propi estàndard IEEE 1588v2 només descriu un perfil: "Perfil predeterminat". La resta de perfils són creats i descrits per diverses organitzacions i associacions.
Per exemple, el Power Profile, o PTPv2 Power Profile, va ser creat pel Power Systems Relaying Committee i el Substation Committee de la IEEE Power and Energy Society. El perfil en si s'anomena IEEE C37.238-2011.
El perfil descriu que es pot transmetre PTP:
- Només mitjançant xarxes L2 (és a dir, Ethernet, HSR, PRP, no IP).
- Els missatges només es transmeten per emissió multicast.
- El mecanisme de mesura de retard entre iguals s'utilitza com a mecanisme de mesura de retard.
El domini predeterminat és 0, el domini recomanat és 93.
La filosofia de disseny de C37.238-2011 era reduir el nombre de funcions opcionals i conservar només les funcions necessàries per a una interacció fiable entre dispositius i augmentar l'estabilitat del sistema.
A més, es determina la freqüència de transmissió del missatge:
De fet, només hi ha un paràmetre disponible per a la selecció: el tipus de rellotge mestre (d'una sola etapa o de dues etapes).
La precisió no ha de ser superior a 1 μs. En altres paraules, un sol camí de sincronització pot contenir un màxim de 15 rellotges transparents o tres rellotges de límit.
Font: www.habr.com