Indledning
Konceptet med at bygge en "digital understation" i elindustrien kræver synkronisering med en nøjagtighed på 1 μs. Finansielle transaktioner kræver også mikrosekunds nøjagtighed. I disse applikationer er NTP-tidsnøjagtigheden ikke længere tilstrækkelig.
PTPv2-synkroniseringsprotokollen, der er beskrevet af IEEE 1588v2-standarden, giver mulighed for en synkroniseringsnøjagtighed på adskillige snese af nanosekunder. PTPv2 giver dig mulighed for at sende synkroniseringspakker over L2- og L3-netværk.
De vigtigste områder, hvor PTPv2 bruges, er:
- energi;
- kontrol- og måleudstyr;
- militær-industrielt kompleks;
- telekommunikation;
- finanssektoren.
Dette indlæg forklarer, hvordan PTPv2-synkroniseringsprotokollen fungerer.
Vi har mere erfaring i industrien og ser ofte denne protokol i energiapplikationer. Derfor vil vi foretage gennemgangen med forsigtighed .
Hvorfor er det nødvendigt?
I øjeblikket indeholder STO 34.01-21-004-2019 af PJSC Rosseti og STO 56947007-29.240.10.302-2020 af PJSC FGC UES krav til organisering af en procesbus med tidssynkronisering via PTPv2.
Dette skyldes det faktum, at relæbeskyttelsesklemmer og måleapparater er forbundet til procesbussen, som transmitterer øjeblikkelige strøm- og spændingsværdier gennem procesbussen ved hjælp af såkaldte SV-streams (multicast-streams).
Relæbeskyttelsesterminaler bruger disse værdier til at implementere bugtbeskyttelse. Hvis nøjagtigheden af tidsmålinger er lille, kan nogle beskyttelser fungere forkert.
For eksempel kan forsvar af absolut selektivitet blive ofre for "svag" tidssynkronisering. Ofte er logikken i sådanne forsvar baseret på en sammenligning af to størrelser. Hvis værdierne afviger med en tilstrækkelig stor værdi, udløses beskyttelsen. Hvis disse værdier måles med en tidsnøjagtighed på 1 ms, så kan man få en stor forskel, hvor værdierne rent faktisk er normale, hvis de måles med en nøjagtighed på 1 μs.
PTP versioner
PTP-protokollen blev oprindeligt beskrevet i 2002 i IEEE 1588-2002-standarden og blev kaldt "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems." I 2008 blev den opdaterede IEEE 1588-2008-standard frigivet, som beskriver PTP Version 2. Denne version af protokollen forbedrede nøjagtighed og stabilitet, men bibeholdt ikke bagudkompatibilitet med den første version af protokollen. I 2019 blev der også frigivet en version af IEEE 1588-2019-standarden, der beskriver PTP v2.1. Denne version tilføjer mindre forbedringer til PTPv2 og er bagudkompatibel med PTPv2.
Vi har med andre ord følgende billede med versioner:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
—
inkonsekvent
inkonsekvent
PTPv2 (IEEE 1588-2008)
inkonsekvent
—
kompatibel
PTPv2.1 (IEEE 1588-2019)
inkonsekvent
kompatibel
—
Men som altid er der nuancer.
Inkompatibilitet mellem PTPv1 og PTPv2 betyder, at en PTPv1-aktiveret enhed ikke vil være i stand til at synkronisere med et nøjagtigt ur, der kører på PTPv2. De bruger forskellige meddelelsesformater til at synkronisere.
Men det er stadig muligt at kombinere enheder med PTPv1 og enheder med PTPv2 på samme netværk. For at opnå dette tillader nogle producenter dig at vælge protokolversionen på kantklokkeportene. Det vil sige, at et grænseur kan synkronisere ved hjælp af PTPv2 og stadig synkronisere andre ure, der er forbundet til det, ved hjælp af både PTPv1 og PTPv2.
PTP-enheder. Hvad er de, og hvordan er de forskellige?
IEEE 1588v2-standarden beskriver flere typer enheder. Alle er vist i tabellen.
Enhederne kommunikerer med hinanden over et LAN ved hjælp af PTP.
PTP-enheder kaldes ure. Alle ure tager den nøjagtige tid fra stormesteruret.
Der er 5 typer ure:
Stormester ur
Den vigtigste kilde til nøjagtig tid. Ofte udstyret med en grænseflade til tilslutning af GPS.
Almindelig Ur
En enkelt port enhed, der kan være en master (master clock) eller slave (slave clock)
Master ur (master)
De er kilden til det nøjagtige tidspunkt, hvormed andre ure synkroniseres
Slave ur
Slutenhed, der er synkroniseret fra masteruret
Grænse ur
En enhed med flere porte, der kan være en master eller en slave.
Det vil sige, at disse ure kan synkronisere fra det overordnede master-ur og synkronisere de ringere slave-ure.
Gennemsigtigt ur fra ende til ende
En enhed med flere porte, der hverken er et masterur eller en slave. Den transmitterer PTP-data mellem to ure.
Ved overførsel af data korrigerer det gennemsigtige ur alle PTP-meddelelser.
Korrektionen sker ved at tilføje forsinkelsestiden på denne enhed til korrektionsfeltet i overskriften på den transmitterede meddelelse.
Peer-to-Peer gennemsigtigt ur
En enhed med flere porte, der hverken er et masterur eller en slave.
Den transmitterer PTP-data mellem to ure.
Ved overførsel af data retter det gennemsigtige ur alle PTP-meddelelser Sync og Follow_Up (mere om dem nedenfor).
Korrektionen opnås ved at tilføje forsinkelsen på sendeindretningen og forsinkelsen på datatransmissionskanalen til korrektionsfeltet for den transmitterede pakke.
Management Node
En enhed, der konfigurerer og diagnosticerer andre ure
Master- og slave-ure synkroniseres ved hjælp af tidsstempler i PTP-meddelelser. Der er to typer meddelelser i PTP-protokollen:
- Hændelsesmeddelelser er synkroniserede meddelelser, der involverer generering af et tidsstempel på det tidspunkt, meddelelsen sendes, og på det tidspunkt, den modtages.
- Generelle meddelelser - Disse meddelelser kræver ikke tidsstempler, men kan indeholde tidsstempler for relaterede meddelelser
Begivenhedsmeddelelser
Generelle meddelelser
Synkroniser
Delay_Req
Pdelay_Req
Pdelay_Resp
Annoncere
Opfølgning
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling
Alle typer meddelelser vil blive diskuteret mere detaljeret nedenfor.
Grundlæggende synkroniseringsproblemer
Når en synkroniseringspakke transmitteres over et lokalt netværk, forsinkes den ved switchen og i datalinket. Enhver switch vil producere en forsinkelse på omkring 10 mikrosekunder, hvilket er uacceptabelt for PTPv2. Vi skal trods alt opnå en nøjagtighed på 1 μs på den endelige enhed. (Dette er, hvis vi taler om energi. Andre applikationer kan kræve større nøjagtighed.)
IEEE 1588v2 beskriver flere driftsalgoritmer, der giver dig mulighed for at registrere tidsforsinkelsen og rette den.
Arbejdsalgoritme
Under normal drift fungerer protokollen i to faser.
- Fase 1 - etablering af "Master Clock - Slave Clock" hierarkiet.
- Fase 2 - klokkesynkronisering ved hjælp af en End-to-End eller Peer-to-Peer mekanisme.
Fase 1 - Etablering af Master-Slave-hierarkiet
Hver port på et regulært eller kant-ur har et vist antal tilstande (slave-ur og master-ur). Standarden beskriver overgangsalgoritmen mellem disse tilstande. I programmering kaldes en sådan algoritme en finite state-maskine eller tilstandsmaskine (flere detaljer i Wiki).
Denne tilstandsmaskine bruger Best Master Clock Algorithm (BMCA) til at indstille masteren, når to ure forbindes.
Denne algoritme gør det muligt for uret at overtage ansvaret for stormesteruret, når upstream-stormesteruret mister GPS-signal, går offline osv.
Statsovergange i henhold til BMCA er opsummeret i følgende diagram:
Information om uret i den anden ende af "tråden" sendes i en særlig besked (Announce message). Når denne information er modtaget, kører tilstandsmaskinens algoritme, og der foretages en sammenligning for at se, hvilket ur der er bedst. Porten på det bedste ur bliver masteruret.
Et simpelt hierarki er vist i diagrammet nedenfor. Sti 1, 2, 3, 4, 5 kan indeholde et gennemsigtigt ur, men de deltager ikke i etableringen af Master Clock - Slave Clock hierarkiet.
Fase 2 - Synkroniser almindelige ure og kanture
Umiddelbart efter etablering af "Master Clock - Slave Clock"-hierarkiet begynder synkroniseringsfasen af almindelige ure og grænseure.
For at synkronisere sender master-uret en besked indeholdende et tidsstempel til slave-urene.
Hoveduret kan være:
- enkelt trin;
- to-trins.
Et-trins ure sender én synkroniseringsmeddelelse for at synkronisere.
Et to-trins ur bruger to beskeder til synkronisering - Sync og Follow_Up.
To mekanismer kan bruges til synkroniseringsfasen:
- Forsinket anmodning-svar-mekanisme.
- Peer forsinkelse målemekanisme.
Lad os først se på disse mekanismer i det enkleste tilfælde - når der ikke bruges gennemsigtige ure.
Forsinket anmodning-svar-mekanisme
Mekanismen involverer to trin:
- Måling af forsinkelsen i transmissionen af en besked mellem master-uret og slave-uret. Udført ved hjælp af en forsinkelsesanmodning-svar-mekanisme.
- Korrektion af den nøjagtige tidsforskydning udføres.
Latency måling
t1 – Tidspunkt for afsendelse af Sync-meddelelsen af masteruret; t2 – Tidspunkt for modtagelse af Sync-meddelelsen af slave-uret; t3 – Tidspunkt for afsendelse af forsinkelsesanmodningen (Delay_Req) af slaveuret; t4 – Delay_Req modtagelsestid af masteruret.
Når slaveuret kender tiderne t1, t2, t3 og t4, kan det beregne den gennemsnitlige forsinkelse ved transmission af synkroniseringsmeddelelsen (tmpd). Det beregnes som følger:
Når der sendes en Sync and Follow_Up besked, beregnes tidsforsinkelsen fra master til slave - t-ms.
Ved transmission af Delay_Req og Delay_Resp beskeder beregnes tidsforsinkelsen fra slaven til masteren - t-sm.
Hvis der opstår en vis asymmetri mellem disse to værdier, vises der en fejl ved korrektion af afvigelsen af det nøjagtige tidspunkt. Fejlen skyldes, at den beregnede forsinkelse er gennemsnittet af t-ms og t-sm forsinkelserne. Hvis forsinkelserne ikke er ens med hinanden, så justerer vi ikke tiden præcist.
Korrektion af tidsforskydning
Når forsinkelsen mellem master-uret og slave-uret er kendt, udfører slave-uret tidskorrektion.
Slave-ure bruger Sync-meddelelsen og en valgfri Follow_Up-meddelelse til at beregne den nøjagtige tidsforskydning, når der sendes en pakke fra master- til slave-urene. Skiftet beregnes ved hjælp af følgende formel:
Peer forsinkelse målemekanisme
Denne mekanisme bruger også to trin til synkronisering:
- Enhederne måler tidsforsinkelsen til alle naboer gennem alle porte. For at gøre dette bruger de en peer-forsinkelsesmekanisme.
- Korrektion af den nøjagtige tidsforskydning.
Måling af latens mellem enheder, der understøtter Peer-to-Peer-tilstand
Latenstiden mellem porte, der understøtter peer-to-peer-mekanismen, måles ved hjælp af følgende meddelelser:
Når port 1 kender tiderne t1, t2, t3 og t4, kan den beregne den gennemsnitlige forsinkelse (tmld). Det beregnes ved hjælp af følgende formel:
Porten bruger derefter denne værdi, når den beregner justeringsfeltet for hver Sync-meddelelse eller valgfri Follow_Up-meddelelse, der passerer gennem enheden.
Den samlede forsinkelse vil være lig med summen af forsinkelsen under transmissionen gennem denne enhed, den gennemsnitlige forsinkelse under transmissionen gennem datakanalen og den forsinkelse, der allerede er indeholdt i denne meddelelse, aktiveret på opstrømsenheder.
Meddelelser Pdelay_Req, Pdelay_Resp og valgfri Pdelay_Resp_Follow_Up giver dig mulighed for at få forsinkelsen fra master til slave og fra slave til master (cirkulær).
Enhver asymmetri mellem disse to værdier vil introducere en tidsforskydningsfejl.
Justering af den nøjagtige tidsforskydning
Slave-ure bruger en Sync-meddelelse og en valgfri Follow_Up-meddelelse til at beregne den nøjagtige tidsforskydning, når der sendes en pakke fra master- til slave-urene. Skiftet beregnes ved hjælp af følgende formel:
Fordele justering af peer-to-peer mekanismen - tidsforsinkelsen for hver Sync eller Follow_Up besked beregnes, efterhånden som den transmitteres i netværket. Som følge heraf vil ændring af transmissionsvejen ikke på nogen måde påvirke nøjagtigheden af justeringen.
Når man bruger denne mekanisme, kræver tidssynkronisering ikke beregning af tidsforsinkelsen langs den vej, som synkroniseringspakken gennemgår, som det gøres i den grundlæggende udveksling. De der. Delay_Req og Delay_Resp beskeder sendes ikke. I denne metode summeres forsinkelsen mellem master- og slave-urene simpelthen i justeringsfeltet for hver Sync- eller Follow_Up-meddelelse.
En anden fordel er, at masteruret er fritaget for behovet for at behandle Delay_Req-meddelelser.
Driftstilstande for gennemsigtige ure
Derfor var disse simple eksempler. Antag nu, at kontakter vises på synkroniseringsstien.
Hvis du bruger switches uden PTPv2-understøttelse, vil synkroniseringspakken blive forsinket på switchen med cirka 10 μs.
Switche, der understøtter PTPv2, kaldes transparente ure i IEEE 1588v2-terminologi. Gennemsigtige ure synkroniseres ikke fra masteruret og deltager ikke i "Master Clock - Slave Clock" hierarkiet, men når de transmitterer synkroniseringsmeddelelser, husker de, hvor længe beskeden blev forsinket af dem. Dette giver dig mulighed for at justere tidsforsinkelsen.
Gennemsigtige ure kan fungere i to tilstande:
- Ende til ende.
- Peer to peer.
End-to-End (E2E)
Det gennemsigtige E2E-ur udsender Sync-beskeder og ledsagende Follow_Up-meddelelser på alle porte. Selv dem, der er blokeret af nogle protokoller (f.eks. RSTP).
Switchen husker tidsstemplet, når en Sync-pakke (Follow_Up) blev modtaget på porten, og hvornår den blev sendt fra porten. Ud fra disse to tidsstempler beregnes den tid, det tager for skiftet at behandle beskeden. I standarden kaldes denne tid for opholdstid.
Behandlingstiden føjes til feltet CorrectionField i meddelelsen Sync (et-trins ur) eller Follow_Up (to-trins ur).
Det transparente E2E-ur måler behandlingstiden for Sync- og Delay_Req-meddelelser, der passerer gennem switchen. Men det er vigtigt at forstå, at tidsforsinkelsen mellem master-uret og slave-uret beregnes ved hjælp af forsinkelsesanmodning-svar-mekanismen. Hvis masteruret ændres, eller stien fra masteruret til slaveuret ændres, måles forsinkelsen igen. Dette øger overgangstiden i tilfælde af netværksændringer.
Det transparente P2P-ur måler, udover at måle den tid, det tager for en switch at behandle en besked, forsinkelsen på datalinket til dens nærmeste nabo ved hjælp af en nabolatensmekanisme.
Latency måles på hvert link i begge retninger, inklusive links, der er blokeret af en eller anden protokol (såsom RSTP). Dette giver dig mulighed for straks at beregne den nye forsinkelse i synkroniseringsstien, hvis grandmaster-uret eller netværkstopologien ændres.
Beskedbehandlingstid af switches og latens akkumuleres, når der sendes Sync- eller Follow_Up-beskeder.
Typer af PTPv2-understøttelse af switches
Switche kan understøtte PTPv2:
- programmatisk;
- hardware.
Når PTPv2-protokollen implementeres i software, anmoder switchen om et tidsstempel fra firmwaren. Problemet er, at firmwaren fungerer cyklisk, og du bliver nødt til at vente, indtil den afslutter den aktuelle cyklus, tager anmodningen om behandling og udsteder et tidsstempel efter næste cyklus. Dette vil også tage tid, og vi vil få en forsinkelse, dog ikke så betydelig som uden softwareunderstøttelse til PTPv2.
Kun hardwaresupport til PTPv2 giver dig mulighed for at opretholde den nødvendige nøjagtighed. I dette tilfælde udstedes tidsstemplet af en speciel ASIC, som er installeret på porten.
Meddelelsesformat
Alle PTP-meddelelser består af følgende felter:
- Header – 34 bytes.
- Brødtekst – størrelsen afhænger af typen af besked.
- Suffiks er valgfrit.
Header
Overskriftsfeltet er det samme for alle PTP-meddelelser. Dens størrelse er 34 bytes.
Overskriftsfeltformat:
beskedtype – indeholder den type besked, der sendes, for eksempel Sync, Delay_Req, PDelay_Req, osv.
beskedlængde – indeholder den fulde størrelse af PTP-meddelelsen, inklusive overskrift, brødtekst og suffiks (men eksklusive udfyldningsbytes).
domænenummer – bestemmer hvilket PTP-domæne meddelelsen tilhører.
Domænenavn - disse er flere forskellige ure samlet i en logisk gruppe og synkroniseret fra et masterur, men ikke nødvendigvis synkroniseret med ure, der tilhører et andet domæne.
flag – Dette felt indeholder forskellige flag for at identificere meddelelsens status.
korrektionsfelt – indeholder forsinkelsestiden i nanosekunder. Forsinkelsestiden inkluderer forsinkelsen ved transmission gennem det transparente ur, såvel som forsinkelsen ved transmission gennem kanalen, når der bruges Peer-to-Peer-tilstand.
sourcePortIdentity – dette felt indeholder information om, hvilken port denne besked oprindeligt blev sendt fra.
sekvens-ID – indeholder et identifikationsnummer for individuelle beskeder.
kontrolfelt – artefaktfelt =) Det forbliver fra den første version af standarden og indeholder information om typen af denne meddelelse. Grundlæggende det samme som messageType, men med færre muligheder.
logMessageInterval – dette felt bestemmes af meddelelsestypen.
Fylde
Som diskuteret ovenfor er der flere typer meddelelser. Disse typer er beskrevet nedenfor:
Meddelelsesmeddelelse
Annoncemeddelelsen bruges til at "fortælle" andre ure inden for samme domæne om dets parametre. Denne meddelelse giver dig mulighed for at opsætte et Master Clock - Slave Clock hierarki.
Synkroniser besked
Synkroniseringsmeddelelsen sendes af masteruret og indeholder tidspunktet for masteruret på det tidspunkt, hvor Synkroniseringsmeddelelsen blev genereret. Hvis masteruret er to-trins, så vil tidsstemplet i Sync-meddelelsen blive sat til 0, og det aktuelle tidsstempel vil blive sendt i den tilknyttede Follow_Up-meddelelse. Synkroniseringsmeddelelsen bruges til begge latensmålingsmekanismer.
Beskeden transmitteres ved hjælp af Multicast. Du kan eventuelt bruge Unicast.
Delay_Req besked
Formatet på Delay_Req-meddelelsen er identisk med Sync-meddelelsen. Slaveuret sender Delay_Req. Den indeholder det tidspunkt, hvor Delay_Req blev sendt af slaveuret. Denne meddelelse bruges kun til mekanismen for forsinkelse af anmodning-svar.
Beskeden transmitteres ved hjælp af Multicast. Du kan eventuelt bruge Unicast.
Opfølgningsmeddelelse
Opfølgningsmeddelelsen sendes valgfrit af masteruret og indeholder tidspunktet for afsendelsen Synkroniser beskeder mestre. Kun to-trins masterure sender Follow_Up-meddelelsen.
Follow_Up-meddelelsen bruges til begge latensmålingsmekanismer.
Beskeden transmitteres ved hjælp af Multicast. Du kan eventuelt bruge Unicast.
Delay_Resp besked
Delay_Resp-meddelelsen sendes af masteruret. Den indeholder det tidspunkt, hvor Delay_Req blev modtaget af masteruret. Denne meddelelse bruges kun til mekanismen for forsinkelse af anmodning-svar.
Beskeden transmitteres ved hjælp af Multicast. Du kan eventuelt bruge Unicast.
Pdelay_Req besked
Pdelay_Req-meddelelsen sendes af en enhed, der anmoder om en forsinkelse. Den indeholder det tidspunkt, hvor beskeden blev sendt fra porten på denne enhed. Pdelay_Req bruges kun til naboforsinkelsesmålemekanismen.
Pdelay_Resp besked
Pdelay_Resp-meddelelsen sendes af en enhed, der har modtaget en forsinkelsesanmodning. Den indeholder det tidspunkt, hvor Pdelay_Req-meddelelsen blev modtaget af denne enhed. Pdelay_Resp-meddelelsen bruges kun til målemekanismen for naboforsinkelse.
Besked Pdelay_Resp_Follow_Up
Pdelay_Resp_Follow_Up-meddelelsen sendes valgfrit af den enhed, der har modtaget forsinkelsesanmodningen. Den indeholder det tidspunkt, hvor Pdelay_Req-meddelelsen blev modtaget af denne enhed. Pdelay_Resp_Follow_Up-meddelelsen sendes kun af to-trins masterure.
Denne besked kan også bruges til udførelsestid i stedet for et tidsstempel. Udførelsestid er tiden fra det øjeblik Pdelay-Req modtages, indtil Pdelay_Resp er sendt.
Pdelay_Resp_Follow_Up bruges kun til målemekanismen for naboforsinkelse.
Ledelsesmeddelelser
PTP-kontrolmeddelelser er nødvendige for at overføre information mellem et eller flere ure og kontrolknudepunktet.
Overførsel til LV
En PTP-meddelelse kan transmitteres på to niveauer:
- Netværk – som en del af IP-data.
- Kanal – som en del af en Ethernet-ramme.
PTP-meddelelsestransmission over UDP over IP over Ethernet
PTP over UDP over Ethernet
Profiler
PTP har en hel del fleksible parametre, der skal konfigureres. For eksempel:
- BMCA muligheder.
- Latency måling mekanisme.
- Intervaller og startværdier for alle konfigurerbare parametre osv.
Og på trods af, at vi tidligere sagde, at PTPv2-enheder er kompatible med hinanden, er dette ikke sandt. Enheder skal have de samme indstillinger for at kunne kommunikere.
Derfor findes der såkaldte PTPv2-profiler. Profiler er grupper af konfigurerede indstillinger og definerede protokolbegrænsninger, så tidssynkronisering kan implementeres for en specifik applikation.
Selve IEEE 1588v2-standarden beskriver kun én profil - "Standardprofil". Alle andre profiler er oprettet og beskrevet af forskellige organisationer og foreninger.
For eksempel blev Power Profile eller PTPv2 Power Profile oprettet af Power Systems Relaying Committee og Substation Committee i IEEE Power and Energy Society. Selve profilen hedder IEEE C37.238-2011.
Profilen beskriver, at PTP kan overføres:
- Kun via L2-netværk (dvs. Ethernet, HSR, PRP, ikke-IP).
- Beskeder transmitteres kun ved multicast-udsendelse.
- Peer-forsinkelsesmålingsmekanisme bruges som en forsinkelsesmålemekanisme.
Standarddomæne er 0, anbefalet domæne er 93.
Designfilosofien bag C37.238-2011 var at reducere antallet af valgfrie funktioner og kun bevare de nødvendige funktioner for pålidelig interaktion mellem enheder og øget systemstabilitet.
Hyppigheden af meddelelsestransmission bestemmes også:
Faktisk er der kun én parameter tilgængelig for valg - typen af masterur (enkelt- eller to-trins).
Nøjagtigheden bør ikke være mere end 1 μs. Med andre ord kan én synkroniseringssti maksimalt indeholde 15 transparente ure eller tre grænseure.
Kilde: www.habr.com