🥇Detaljer om implementeringen af PTPv2 tids-synkroniseringsprotokollen

Introduktion

Konceptet for opbygning af "Digitale Transformatorstationer" inden for elforsyning kræver synkronisering med en nøjagtighed på 1 µs. For finansielle transaktioner kræves der også nøjagtighed i µs. I disse applikationer er NTP's tidsnøjagtighed ikke længere tilstrækkelig.

PTPv2 synkroniseringsprotokollen, beskrevet i standarden IEEE 1588v2, muliggør en synkroniseringspræcision på flere titusinder af nanosekunder. PTPv2 tillader sending af synkroniseringspakker gennem L2 og L3-netværk.

De primære områder, hvor PTPv2 anvendes, er:

elforsyning;
måle- og kontroludstyr;
forsvarsindustrien;
telekommunikation;
finanssektoren.

I dette indlæg analyseres, hvordan PTPv2 synkroniseringsprotokollen fungerer.

Vi har mere erfaring i branchen, og vi møder ofte denne protokol i energiapplikationer. Derfor vil vi også lave vores gennemgang med fokus på elforsyning..

Hvorfor er det nødvendigt?

I øjeblikket indeholder STO 34.01-21-004-2019 fra PJSC "Rosseti" og STO 56947007-29.240.10.302-2020 fra PJSC "FSK EES" krav til organisationen af procesbussen med sikring af tidsynkronisering via PTPv2.

Dette skyldes, at der til procesbussen tilsluttes terminaler til relæbeskyttelse og måleinstrumenter, som via procesbussen, ved hjælp af de såkaldte SV-strømme (multicast-strømme), transmitterer øjeblikke værdier for strøm og spænding.

Terminalerne til relæbeskyttelse bruger disse værdier til at implementere beskyttelse af tilslutninger. Hvis tidsmålingens nøjagtighed er lav, kan nogle beskyttelsesforanstaltninger udløses fejlagtigt.

For eksempel kan beskyttelsen mod absolut selektivitet blive offer for "svag" tidsynkronisering. Logikken i sådanne beskyttelser er ofte baseret på sammenligning af to størrelser. Hvis størrelserne adskiller sig med en betydelig værdi, træder beskyttelsen i kraft. Hvis disse størrelser måles med en tidspræcision på 1 ms, kan der opstå en stor forskel, hvor værdierne faktisk ligger inden for normen, hvis de måles med en præcision på 1 µs.

Versioner af PTP

PTP-protokollen blev oprindeligt beskrevet i 2002 i standarden IEEE 1588-2002 og havde navnet «Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems». I 2008 blev den opdaterede standard IEEE 1588-2008 udgivet, som beskriver PTP Version 2. I denne version af protokollen blev præcisionen og stabiliteten forbedret, men der blev ikke bevaret bagudkompatibilitet med den første version af protokollen. Derudover blev versionen IEEE 1588-2019 udgivet i 2019, der beskriver PTP v2.1. Denne version tilføjer små forbedringer til PTPv2 og er bagudkompatibel med PTPv2.

Med andre ord, har vi følgende billede med versionerne:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

—
Ikke kompatible

Ikke kompatible

PTPv2 (IEEE 1588-2008)

Ikke kompatible

—
Kompatible

PTPv2.1 (IEEE 1588-2019)

Ikke kompatible

Kompatible

—

Men som altid er der nuancer.

Ikke-kompatibilitet mellem PTPv1 og PTPv2 betyder, at en enhed med PTPv1-understøttelse ikke vil kunne synkronisere fra præcise ure, der arbejder på PTPv2. De bruger forskellige meddelelsesformater til synkronisering.

Men det er muligt at kombinere enheder med PTPv1 og enheder med PTPv2 i det samme netværk. Nogle producenter tillader, at man vælger versionsprotokollen på grænseurens porte. Det vil sige, at grænseure kan synkronisere via PTPv2 og samtidig synkronisere andre ure, der er tilsluttet dem, både via PTPv1 og PTPv2.

PTP-enheder. Hvilke findes og hvad adskiller dem?

Standarden IEEE 1588v2 beskriver flere typer enheder. Alle er vist i tabellen.

Enheder interagerer med hinanden via LAN ved at bruge PTP.

PTP-enheder kaldes ure. Alle ure får præcist tidsstempel fra grandmaster ure.

Der er 5 typer ure:

Grandmaster clock (Grandmaster-ur)

Primær kilde til præcist tid. Ofte udstyret med interface til GPS-forbindelse.

Ordinary Clock (Almindeligt ur)

En enhed med én port, som kan være master (førende ur) eller slave (efterfølgende ur)

Master-ur

Er kilden til præcis tid, som andre ure synkroniserer sig med

Slave-ur

Den slutelige enhed, der synkroniserer fra master-urene

Boundary Clock (Grænse-ur)

En enhed med flere porte, som kan være master eller slave.

Det betyder, at disse ure kan synkronisere fra overordnede master-ure og synkronisere underordnede slave-ure.

End-to-end Transparent Clock (Gennemsigtige ure, der arbejder i End-to-End-tilstand)

En flerportsenhed, der hverken er en Master- eller Slave-ur. Den transmitterer PTP-data mellem to ure.

Ved overførsel af data justerer de gennemsigtige ure alle PTP-meddelelser.

Justeringsprocessen sker ved at tilføje ventetid på denne enhed i justeringsfeltet i overskriften af den sendte meddelelse.

Peer-to-Peer Transparent Clock (Gennemsigtige ure, der arbejder i Peer-to-Peer-tilstand)

En flerportsenhed, der hverken er en Master- eller Slave-ur.
Den transmitterer PTP-data mellem to ure.

Ved overførsel af data justerer de gennemsigtige ure alle PTP Sync- og Follow_Up-meddelelser (mere om dem nedenfor).

Justeringsprocessen opnås ved at tilføje ventetid til justeringsfeltet i den sendte pakke og forsinkelsen i datatransmissionen.

Management Node (Ledelsesnoden)

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 af meddelelser i PTP-protokollen:

Event Messages – disse er synkroniserede meddelelser, der indebærer generation af et tidsstempel på tidspunktet for afsendelse af meddelelsen og på tidspunktet for modtagelse.
General Messages – disse meddelelser kræver ikke tidsstempler, men kan indeholde tidsstempler for relaterede meddelelser.

Event Messages

General Messages

Sync
Delay_Req
Pdelay_Req
Pdelay_Resp

Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling

Nedenfor gennemgås alle meddelelsestyper mere detaljeret.

De vigtigste synkroniseringsproblemer

Når synkroniseringspakken overføres gennem netværket, forsinkes den i switchen og i datakanalen. Enhver switch vil give en forsinkelse på omkring 10 µs, hvilket er uacceptabelt for PTPv2. For vores slutindretning er det nødvendigt at opnå en nøjagtighed på 1 µs. (Dette gælder, hvis vi taler om energi. Andre applikationer kan kræve endnu større nøjagtighed.)

IEEE 1588v2 beskriver flere arbejdsalgoritmer, der muliggør registrering af ventetid og justering heraf.

Arbejdsmåde
Under normal drift fungerer protokollen i to faser.

Fase 1 – etablering af hierarkiet 'Master-ur – Slave-ur'.
Fase 2 – synkronisering af ure ved hjælp af End-to-End- eller Peer-to-Peer-mekanismer.

Fase 1 — Installation af hierarkiet "Master-Slave"

Hver port for almindelige eller grænseur har en bestemt mængde tilstande (slavur og masterur). Standarden beskriver algoritmen for overgangen mellem disse tilstande. I programmering kaldes en sådan algoritme for en endelig automat eller tilstandsmodel (læs mere i Wiki).

Denne endelige automat bruger algoritmen Best Master Clock Algorithm (BMCA) til at etablere masteren ved forbindelse mellem to ure.

Denne algoritme giver urene mulighed for at påtage sig forpligtelserne fra grandmasterurene, når de højere grandmasterure mister GPS-signalet, frakobles netværket osv.

Overgange mellem tilstande i henhold til BMCA er kortlagt i det følgende diagram:

Information om urene i den anden ende af "ledningen" sendes i en særlig meddelelse (Announce message). Når denne information er modtaget, arbejder tilstandsalgoritmen, og der udføres en sammenligning af, hvilke ure der er bedst. Porten på de bedste ure bliver masterure.

Den enkle hierarki er præsenteret i diagrammet nedenfor. Stierne 1, 2, 3, 4, 5 kan indeholde transparente ure (Transparent clock), men de deltager ikke i etableringen af hierarkiet "Master ure – Slave ure".

Fase 2 — Synchronisering af almindelige og grænseur

Umiddelbart efter etableringen af hierarkiet "Master ure – Slave ure" begynder synkroniseringsfasen for almindelige og grænseur.

For synkronisering sender masterurene en besked til slaveurene, der indeholder et tidsstempel.

Masterurene kan være:

enkelt-trins;
dobbelt-trins.

Enkelt-trins ure sender en besked Sync for synkronisering.

Dobbelt-trins ure bruger to beskeder til synkronisering – Sync og Follow_Up.

To mekanismer kan anvendes til synkroniseringsfasen:

Delay request-response mekanisme.
Peer delay measurement mekanisme.

Lad os først se på disse mekanismer i det enkleste tilfælde – når der ikke anvendes transparente ure.

Delay request-response mekanisme

Mekanismen indebærer to trin:

Måling af forsinkelse ved overførsel af beskeden mellem masterurene og slaveurene udføres ved hjælp af delay request-response mekanismen.
Der udføres en korrektion for præcisionsforskydningen.

Måling af forsinkelse

t1 – Tidspunkt for afsendelse af sync-besked fra masterklokker; t2 – Tidspunkt for modtagelse af sync-besked af slaveklokker; t3 – Tidspunkt for afsendelse af delay-anmodning (Delay_Req) fra slaveklokker; t4 – Tidspunkt for modtagelse af Delay_Req af masterklokker.

Når slaveklokkerne kender tidspunkterne t1, t2, t3 og t4, kan de beregne den gennemsnitlige forsinkelse ved overførsel af synkroniseringsbeskeden (tmpd). Den beregnes som følger:

Ved overførsel af sync-besked og Follow_Up beregnes tidens forsinkelse fra master til slave – t-ms.

Ved overførsel af beskederne Delay_Req og Delay_Resp beregnes tidens forsinkelse fra slave til master – t-sm.

Hvis der opstår en asymmetri mellem disse to værdier, opstår der en fejl i korrektionen af den præcise tid. Fejlen skyldes, at den beregnede forsinkelse er gennemsnittet af forsinkelserne t-ms og t-sm. Hvis forsinkelserne ikke er lige, vil vi korrigere tiden unøjagtigt.

Korrektion af skift i præcise tid

Når forsinkelsen mellem masterklokkerne og slaveklokkerne er kendt, udfører slaveklokkerne tidskorrektionen.

Slaveklokkerne bruger sync-beskeden og den valgfrie Follow_Up-besked til at beregne skiftet i præcise tid ved overførsel af pakker fra masterklokkerne til slaveklokkerne. Skiftet beregnes ved hjælp af følgende formel:

Mekanisme til måling af forsinkelse fra naboen (Peer delay measurement mechanism)

Denne mekanisme bruger også to trin til synkronisering:

Enhederne måler tidens forsinkelse til alle naboer gennem alle porte. Til dette bruger de peer delay-mechanismen.
Korrigering af skift i præcise tid.

Måling af forsinkelsen mellem enheder, der understøtter Peer-to-Peer-tilstand

Forsinkelsen mellem porte, der understøtter peer-to-peer-mekanismen, måles ved hjælp af følgende beskeder:

Når port 1 kender tidspunkterne t1, t2, t3 og t4, kan den beregne den gennemsnitlige forsinkelse (tmld). Den beregnes efter følgende formel:

Derefter bruger porten denne værdi ved beregningen af korrekteringsfeltet for hver sync-besked eller den valgfrie Follow_Up-besked, der passerer gennem denne enhed.

Den samlede forsinkelse vil være lig med summen af forsinkelsen ved overførsel gennem denne enhed, den gennemsnitlige forsinkelse ved overførsel gennem datakanalen og den allerede eksisterende forsinkelse i denne besked, der er inkluderet i de overordnede enheder.

Pdelay_Req, Pdelay_Resp og det valgfrie Pdelay_Resp_Follow_Up-meddelender muliggør at få forsinkelsen fra master til slave og fra slave til master (cirkulært).

Enhver asymmetri mellem disse to værdier vil introducere en fejl i korrektionen af den præcise tid.

Korrektion af den præcise tid

Slavurens ure bruger Sync-meddelender og det valgfrie Follow_Up-meddelende til at beregne forskydningen af den præcise tid ved overførsel af pakker fra master til slaver. Forskydningen beregnes ved hjælp af følgende formel:

Fordele ved peer-to-peer korrektion – forsinkelsen ved hver Sync- eller Follow_Up-meddelender beregnes løbende under dens overførsel i netværket. Følgelig vil ændringen af overførselsvejen ikke på nogen måde påvirke nøjagtigheden af korrektionen.

Ved anvendelse af denne mekanisme kræver tidsynkronisering ikke beregning af forsinkelsen af den overførte synkroniseringspakkevej, som det gøres ved grundlæggende udveksling. Dvs. Delay_Req- og Delay_Resp-meddelender sendes ikke. I denne metode summeres forsinkelsen mellem master- og slaveure simpelthen i korrektionsfeltet for hver Sync- eller Follow_Up-meddelender.

En anden fordel er, at masteruren aflastes fra nødvendigheden af at behandle Delay_Req-meddelender.

Driftsformer for transparente ure

Mere konkrete eksempler er blevet gennemgået. Lad os nu antage, at der dukker switcher op på synkroniseringsvejen.

Hvis der anvendes switcher uden støtte for PTPv2, vil synkroniseringspakken være forsinket på switchen med omtrent 10 µs.

Switchere med PTPv2-understøttelse kaldes i IEEE 1588v2-terminologi transparente ure (Transparent clock). Transparente ure synkroniseres ikke fra masterure og deltager ikke i hierarkiet 'Masterur – Slaveur', men husker, hvor meget tid der er blevet forsinket på dem under overførslen af synkroniseringsmeddelelser. Dette muliggør justering af tidsforsinkelsen.

Transparente ure kan arbejde i to tilstande:

End-to-End.
Peer-to-Peer.

End-to-End (E2E)

E2E transparente ure sender Sync-meddelender og tilhørende Follow_Up-meddelender til alle porte. Selv til dem, der er blokeret af bestemte protokoller (f.eks. RSTP).

Switches remember the timestamp when the Sync (Follow_Up) packet was received on the port and when it was sent from the port. Based on these two timestamps, the processing time of the switch for the message is calculated. This time is referred to as residence time in the standard.

The processing time is added to the correctionField of the Sync message (one-step clocks) or the Follow_Up message (two-step clocks).

Transparent E2E clocks measure processing time for Sync and Delay_Req messages passing through the switch. However, it is important to understand that the time delay between the master clocks and the slave clocks is calculated using the delay request-response mechanism. If the master clocks change or the path from the master clocks to the slave clocks changes, the delay is measured anew. This increases the transition state time in case of network changes.

Transparent P2P clocks, in addition to measuring the processing time of the message by the switch, measure the delay on the data transmission link to the nearest neighbor using the neighboring node delay measurement mechanism.

The delay is measured on each channel in both directions, including channels blocked by any protocol (e.g., RSTP). This allows for the immediate calculation of new delay on the synchronization path if the grandmaster clocks or network topology have changed.

The processing times of messages by switches and the delay times are accumulated when transmitting Sync or Follow_Up messages.

Types of PTPv2 support by switches

Switches can support PTPv2:

in software;
in hardware.

In a software implementation of the PTPv2 protocol, the switch requests a timestamp from the firmware. The problem is that the firmware operates cyclically, and it will have to wait until it finishes the current cycle, processes the request, and outputs the timestamp at the end of the next cycle. This will also take time, resulting in a delay, albeit not as significant as without PTPv2 software support.

Only hardware support for PTPv2 can ensure the necessary accuracy. In this case, the timestamp is generated by a specialized ASIC installed on the port.

Message format

All PTP messages consist of the following fields:

Header – 34 bytes.
Body – the size depends on the message type.
Suffix – optional.

Header

Header-feltet er det samme for alle PTP-beskeder. Det er 34 bytes stort.

Formatet for Header-feltet:

messageType – angiver typen af den sendte besked, fx Sync, Delay_Req, PDelay_Req osv.

messageLength – angiver den samlede størrelse af PTP-beskeden, inklusive header, body og suffix (men ekskluderer fyldbytes).

domainNumber – bestemmer, hvilken domænet PTP beskeden tilhører.

Domæne – dette er flere forskellige ure samlet i en logisk gruppe og synkroniseret fra en enkelt masterklokke, men ikke nødvendigvis synkroniseret med ure, der tilhører en anden domæne.

flags – dette felt indeholder forskellige flag til identifikation af beskedens status.

correctionField – indeholder forsinkelsestiden i nanosekunder. Forsinkelsestiden inkluderer både transmissionstid gennem transparente ure og forsinkelse i kanalen ved brug af Peer-to-Peer-tilstand.

sourcePortIdentity – dette felt indeholder oplysninger om, hvilken port beskeden oprindeligt blev sendt fra.

sequenceID – indeholder et identifikationsnummer for individuelle beskeder.

controlField – feltet er et artefakt=) Det stammer fra den første version af standarden og indeholder oplysninger om typen af denne besked. I princippet det samme som messageType, men med færre muligheder.

logMessageInterval – dette felt bestemmes af beskedtypen.

Krop

Som nævnt tidligere, er der flere typer beskeder. Disse typer er beskrevet nedenfor:

Announce-besked
Announce-beskeden bruges til at "informere" andre ure inden for et domæne om sine parametre. Denne besked gør det muligt at etablere en hierarki mellem "Masterklokker - Slaveure".

Sync-besked
Sync-beskeden sendes af masterklokkerne og indeholder masterklokkens tid på det tidspunkt, hvor Sync-beskeden blev oprettet. Hvis masterklokkerne er to-trins, vil tidsstemplet i Sync-beskeden blive sat til 0, og den aktuelle tidsstempel vil blive sendt i det tilsvarende Follow_Up-besked. Sync-beskeden anvendes til begge mekanismer til måling af forsinkelse.

Beskeden sendes ved hjælp af multicast. Det er valgfrit at bruge unicast.

Delay_Req-besked

Formatet for Delay_Req-beskeden er identisk med Sync-beskeden. Slaveurene sender Delay_Req. Den indeholder tidspunktet for, hvornår Delay_Req blev sendt af slaveurene. Denne besked bruges kun til mekanismen til anmodning-svar forsinkelse.

Beskeden sendes ved hjælp af multicast. Det er valgfrit at bruge unicast.

Follow_Up-besked

Follow_Up-besked sendes valgfrit af de ledende ure og indeholder tidspunktet for afsendelse Sync-beskeder mesteren. Follow_Up-besked sendes kun af to-trins ledende ure.

Follow_Up-beskeddet bruges til begge målemetoder for forsinkelse.

Beskeden sendes ved hjælp af multicast. Det er valgfrit at bruge unicast.

Delay_Resp-besked

Delay_Resp-besked sendes af de ledende ure. Det indeholder modtagelsestidspunktet for Delay_Req fra de ledende ure. Dette besked bruges kun til request-response forsinkelsesmekanismen.

Beskeden sendes ved hjælp af multicast. Det er valgfrit at bruge unicast.

Pdelay_Req-besked

Pdelay_Req-besked sendes af en enhed, der anmoder om forsinkelse. Det indeholder tidspunktet for meddelelsens afsendelse fra denne enheds port. Pdelay_Req bruges kun til målemetoden for nabobucklers forsinkelse.

Pdelay_Resp-besked

Pdelay_Resp-besked sendes af enheden, der modtog forespørgslen om forsinkelse. Det indeholder modtagelsestidspunktet for Pdelay_Req-beskeddet fra denne enhed. Pdelay_Resp-beskeder bruges kun til nabobucklers målemetoden for forsinkelse.

Pdelay_Resp_Follow_Up-besked

Pdelay_Resp_Follow_Up-besked sendes valgfrit af enheden, der modtog forespørgslen om forsinkelse. Det indeholder modtagelsestidspunktet for Pdelay_Req-beskeddet fra denne enhed. Pdelay_Resp_Follow_Up-beskedsendes kun af to-trins ledende ure.

Dette besked kan også bruges til udførelsestid i stedet for tidsstempel. Udførelsestid er tidspunktet fra modtagelsen af Pdelay-Req til afsendelse af Pdelay_Resp.

Pdelay_Resp_Follow_Up bruges kun til målemetoden for nabobucklers forsinkelse.

Styringsmeddelelser (Management-besked)

PTP-styringsmeddelelser er nødvendige for at overføre information mellem en eller flere ure og styringsnoden.

Overførsel i LV

PTP-besked kan overføres på to niveauer:

Netværksniveau – som del af IP-data.
Kanalniveau – som del af Ethernet-ramme.

PTP-beskedoverførsel via UDP over IP over Ethernet

PTP via UDP over Ethernet

Profiler

PTP har mange "fleksible" parametre, der skal konfigureres. For eksempel:

BMCA-indstillinger.
Målemetode for forsinkelse.
Intervaller og startværdier for alle konfigurerbare parametre osv.

Og selvom vi tidligere har sagt, at PTPv2-enheder er kompatible med hinanden, er det ikke helt korrekt. Enhederne skal have de samme indstillinger for at interagere.

Derfor eksisterer der såkaldte PTPv2-profiler. Profiler er grupper af konfigurerede indstillinger og specifikke protokolbegrænsninger, så tids-synkronisering kan implementeres til en bestemt applikation.

Den officielle standard IEEE 1588v2 beskriver kun én profil – "Standardprofilen". Alle andre profiler er skabt og beskrevet af forskellige organisationer og foreninger.

For eksempel blev profilen for elforsyning eller PTPv2 Power Profile skabt af Power Systems Relaying Committee og Substation Committee i IEEE Power and Energy Society. Selve profilen kaldes IEEE C37.238-2011.

Profilen beskriver, at PTP kan overføres:

Kun gennem L2-netværk (dvs. Ethernet, HSR, PRP, ikke IP).
Meddelinger sendes kun via multicast.
Peer delay measurement mechanism bruges som målemetode til forsinkelse.

Standarddomænet er 0, det anbefalede domæne er 93.

I filosofi om oprettelse af C37.238-2011 lå ønsket om at reducere antallet af valgfri egenskaber og kun bevare de nødvendige funktioner for pålidelig interaktion mellem enheder og forbedring af systemets stabilitet.

Derudover er meddelelsesoverførselsfrekvensen defineret:

I praksis er der kun én parameter til valg – typen af styrende ur (enkelttrin eller to-trins).