Detaljer om implementeringen av tidsynkroniseringsprotokollet PTPv2

Introduktion

Konceptet för att bygga en "Digital transformation" inom elkraft kräver synkronisering med en noggrannhet på 1 μs. För att genomföra finansiella transaktioner krävs också noggrannhet i μs. I dessa applikationer är noggrannheten hos NTP redan otillräcklig.

Synkroniseringsprotokollet PTPv2, som beskrivs i standarden IEEE 1588v2, möjliggör synkronisering med en noggrannhet på flera tiotals nanosekunder. PTPv2 gör det möjligt att skicka synkroniseringspaket genom L2- och L3-nätverk.

De främsta områdena där PTPv2 tillämpas är:

• energiförsörjning;
• mät- och kontrollutrustning;
• försvarsindustri;
• telekommunikation;
• finanssektorn.

I detta inlägg går vi igenom hur synkroniseringsprotokollet PTPv2 fungerar.

Vi har stor erfarenhet inom industrin och möter ofta detta protokoll i energitillämpningar. Därför kommer vi att göra vår översikt med fokus på energiförsörjningen..

Varför behövs det?

För närvarande anges i STO 34.01-21-004-2019 av PJSC "Rosseti" och i STO 56947007-29.240.10.302-2020 av PJSC "FSK EES" krav på organiserandet av en processtång med tidssynkronisering genom PTPv2.

Detta beror på att terminalerna för reläskydd och mätutrustning kopplas till processtången och genom processtången, med hjälp av så kallade SV-flöden (multicast-flöden), överför aktuella värden av ström och spänning.

Terminalerna för reläskydd använder dessa värden för att genomföra skydd av anslutningarna. Om noggrannheten i tidsmätningarna är låg, kan vissa skydd utlösa falskt.

Till exempel kan skydd med "svag" tidsynkronisering drabbas. Ofta baseras logiken hos sådana skydd på att jämföra två storlekar. Om storlekarna avviker med ett tillräckligt stort värde utlöses skyddet. Om dessa storlekar mäts med en noggrannhet på 1 ms kan en stor skillnad uppstå där värdena egentligen ligger inom normen, om de mäts med en noggrannhet på 1 μs.

Versioner av PTP

PTP-protokollet beskrevs ursprungligen 2002 i standarden IEEE 1588-2002 och kallades "Standard för en Precision Clock Synchronization Protocol för Nätverksbaserade Mät- och Kontrollsystem". År 2008 släpptes en uppdaterad standard, IEEE 1588-2008, som beskriver PTP Version 2. I denna version av protokollet förbättrades noggrannheten och stabiliteten, men bakåtkompatibilitet med den första versionen av protokollet bevarades inte. Dessutom släpptes år 2019 versionen IEEE 1588-2019, som beskriver PTP v2.1. Denna version tillför små förbättringar till PTPv2 och är bakåtkompatibel med PTPv2.

Med andra ord har vi följande bild av versioner:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

—
Inkompatibla

Inkompatibla

PTPv2 (IEEE 1588-2008)

Inkompatibla

—
Kompatibla

PTPv2.1 (IEEE 1588-2019)

Inkompatibla

Kompatibla

—

Men, som alltid, finns det nyanser.

Inkompatibiliteten mellan PTPv1 och PTPv2 innebär att en enhet som stödjer PTPv1 inte kan synkronisera med exakta klockor som arbetar på PTPv2. För synkronisering använder de olika meddelandeformat.

Men det går fortfarande att kombinera enheter med PTPv1 och enheter med PTPv2 i samma nätverk. För detta tillåter vissa tillverkare att man på gränsklockornas portar väljer versionsprotokoll. Det vill säga, gränsklockor kan synkronisera enligt PTPv2 och samtidigt synkronisera andra anslutna klockor enligt både PTPv1 och PTPv2.

PTP-enheter. Vilka finns det och hur skiljer de sig åt?

Standarden IEEE 1588v2 beskriver flera typer av enheter. Alla dessa anges i tabellen.

PTP-enheter interagerar med varandra via LAN, med hjälp av PTP.

PTP-enheter kallas klockor. Alla klockor tar exakt tid från grandmaster-klockor.

Det finns 5 typer av klockor:

Grandmaster-klocka

Huvudsaklig källa för exakt tid. Ofta utrustad med gränssnitt för GPS-anslutning.

Ordinary Clock (Vanlig klocka)

En enhet med en port som kan vara master (ledande klocka) eller slave (efterföljande klocka)

Ledande klocka (master)

Är en källa till exakt tid på vilken andra klockor synkroniseras

Efterföljande klocka (slave)

Slutlig enhet som synkroniseras från ledande klockor

Boundary Clock (Gränsklocka)

En enhet med flera portar som kan vara master eller slave.

Det vill säga dessa klockor kan synkronisera från högre liggande ledande klockor och synkronisera lägre liggande efterföljande klockor.

End-to-end Transparent Clock (Transparent Clock som fungerar i End-to-End-läge)

En enhet med flera portar som varken är mästarur eller slavur. Den överför PTP-data mellan två ur.

Vid överföring av data justerar de transparenta klockorna alla PTP-meddelanden.

Justeringen sker genom att lägga till fördröjningstid på denna enhet i korrigeringsfältet i rubriken för det överförda meddelandet.

Peer-to-Peer Transparent Clock (Transparent Clock som fungerar i Peer-to-Peer-läge)

En enhet med flera portar som varken är mästarur eller slavur.
Den överför PTP-data mellan två ur.

Vid överföring av data justerar de transparenta klockorna alla PTP-meddelanden Sync och Follow_Up (mer om dem nedan).

Justeringen uppnås genom att lägga till fördröjningstid i korrigeringsfältet för det överförda paketet och fördröjning i dataöverföringskanalen.

Management Node (Hantera nod)

En enhet som konfigurerar och diagnostiserar andra ur.

Mästarur och slavur synkroniseras med hjälp av tidsstämplar i PTP-meddelanden. Det finns två typer av meddelanden i PTP-protokollet:

• Event Messages – dessa är synkroniserade meddelanden som innebär att en tidsstämpel genereras vid avsändning och mottagning av meddelandet.
• General Messages – dessa meddelanden kräver inga tidsstämplar men kan innehålla tidsstämplar för relaterade meddelanden.

Event Messages

General Messages

Sync
Delay_Req
Pdelay_Req
Pdelay_Resp

Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling

Näst ska alla meddelandetyper behandlas mer detaljerat.

Huvudproblem vid synkronisering

När ett synkroniseringspaket överförs över ett lokalt nätverk fördröjs det av en switch och i dataöverföringskanalen. Varje switch ger en fördröjning på cirka 10 mikrosekunder, vilket är oacceptabelt för PTPv2. Vi behöver uppnå en noggrannhet på 1 mikrosekund på slutenheten. (Detta gäller energisektorn. Andra applikationer kan kräva ännu högre noggrannhet.)

IEEE 1588v2 beskriver flera algoritmer för arbete som gör det möjligt att registrera tidsfördröjning och korrigera den.

Arbetsalgoritm
Under normal drift arbetar protokollet i två faser.

• Fas 1 – etablera hierarki av "Mästarur – Slavur".
• Fas 2 – synkronisering av ur med hjälp av End-to-End- eller Peer-to-Peer-mekanismen.

Fas 1 - Installera hierarkin "Master-Slave"

Varje port på vanliga eller gränsklockor har ett visst antal tillstånd (slavklockor och masterklockor). Standarden beskriver algoritmen för övergång mellan dessa tillstånd. Inom programmering kallas en sådan algoritm för en slutlig automat eller tillståndsmaskin (läs mer på Wiki).

Denna slutliga automat använder algoritmen Best Master Clock Algorithm (BMCA) för att fastställa mästaren vid anslutning av två klockor.

Denna algoritm möjliggör för klockorna att ta över ansvaret från masterklockor när överordnade masterklockor förlorar GPS-signal, kopplas från nätverket, osv.

Övergångarna mellan tillstånden enligt BMCA visas kortfattat i följande schema:


Information om klockorna i den andra änden av "ledningen" skickas i ett speciellt meddelande (Announce message). När denna information har mottagits, körs tillståndsmaskinsalgoritmen och en jämförelse görs för att avgöra vilka klockor som är bättre. Porten på de bästa klockorna blir masterklockor.

Den enkla hierarkin presenteras i schemat nedan. Vägar 1, 2, 3, 4, 5 kan innehålla transparenta klockor (Transparent clock), men de deltar inte i fastställandet av hierarkin "Masterklockor - Slavklockor".

Fas 2 - Synkronisering av vanliga och gränsklockor

Strax efter att hierarkin "Masterklockor - Slavklockor" har fastställts, inleds fasen för synkronisering av vanliga och gränsklockor.

För synkronisering skickar masterklockorna ett meddelande till slavklockorna som innehåller en tidsstämpel.

Masterklockorna kan vara:

• en-stegs;
• två-stegs.

En-stegs klockor skickar ett meddelande Sync för synkronisering.

Två-stegs klockor använder två meddelanden för synkronisering - Sync och Follow_Up.

För synkroniseringsfasen kan två mekanismer användas:

• Fördröjningsbegäran-svar mekanismen (Delay request-response mechanism).
• Mekanismen för mätning av fördröjning för angränsande nod (Peer delay measurement mechanism).

Låt oss först betrakta dessa mekanismer i det enklaste fallet - när inga transparenta klockor används.

Fördröjningsbegäran-svar mekanismen (Delay request-response mechanism)

Mekanismen innebär två steg:

1. Mätning av fördröjning vid överföring av meddelande mellan masterklockor och slavklockor. Utförs med hjälp av fördröjningsbegäran-svar mekanismen.
2. Genomför en justering av tidsförskjutningen.

Mätning av fördröjning


t1 – Tid för att skicka Sync-meddelandet från mästaruret; t2 – Tid för att ta emot Sync-meddelandet från slaven; t3 – Tid för att skicka Delay_Req från slaven; t4 – Tid för att ta emot Delay_Req från mästaruret.

När slavaruren känner till tiderna t1, t2, t3 och t4 kan de beräkna den genomsnittliga fördröjningen vid överföring av synkroniseringsmeddelandet (tmpd). Den beräknas enligt följande:

Vid överföring av Sync- och Follow_Up-meddelanden beräknas tidsfördröjningen från mästaren till slaven – t-ms.

Vid överföring av Delay_Req och Delay_Resp-meddelanden beräknas tidsfördröjningen från slaven till mästaren – t-sm.

Om det finns någon asymmetri mellan dessa två värden uppstår ett fel i justeringen av exakt tid. Felet beror på att den beräknade fördröjningen är medelvärdet av fördröjningarna t-ms och t-sm. Om fördröjningarna inte är lika kommer vi att justera tiden felaktigt.

Justering av exakt tidsskillnad

När fördröjningen mellan mästaruret och slavaruren är känd, utför slavaruren tidsjustering.

Slavaruren använder Sync-meddelandet och det valfria Follow_Up-meddelandet för att beräkna justeringen av exakt tid vid överföring av paket från mästaruret till slavaruren. Justeringen beräknas enligt följande formel:

Mekanism för mätning av fördröjning hos grannnod (Peer delay measurement mechanism)

Denna mekanism använder också två steg för synkronisering:

1. Enheter mäter tidsfördröjningen till alla grannar genom alla portar. För detta används peer delay-mechanismen.
2. Justering av exakt tidsskillnad.

Mätning av fördröjningen mellan enheter som stöder Peer-to-Peer-läget

Fördröjningen mellan portar som stöder peer-to-peer-mekanismen mäts med hjälp av följande meddelanden:

När port 1 känner till tiderna t1, t2, t3 och t4 kan den beräkna den genomsnittliga fördröjningen (tmld). Den beräknas enligt följande formel:

Därefter använder porten detta värde när den beräknar justeringsfältet för varje Sync-meddelande eller det valfria Follow_Up-meddelandet som passerar genom denna enhet.

Den totala fördröjningen kommer att vara summan av fördröjningen vid överföring genom denna enhet, den genomsnittliga fördröjningen vid överföring genom datakanalen och den redan befintliga fördröjningen i detta meddelande, som ingår i högre enheter.

Meddelanden Pdelay_Req, Pdelay_Resp och det valfria Pdelay_Resp_Follow_Up gör det möjligt att få fördröjningen från master till slav och från slav till master (cirkulär).

All eventuell asymmetri mellan dessa två värden kommer att introducera ett fel i korrigeringen av den exakta tiden.

Korrigering av den exakta tiden

Slavklockor använder Sync-meddelande och det valfria meddelandet Follow_Up för att beräkna fördröjningen av den exakta tiden vid överföring av paket från ledande klockor till slavar. Fördröjningen beräknas enligt följande formel:

Fördelarna med korrigeringsmekanismen peer-to-peer – fördröjningen av varje Sync- eller Follow_Up-meddelande beräknas under överföringen i nätverket. Därmed påverkar en förändring av överföringsvägen inte noggrannheten i korrigeringen.

Vid användning av denna mekanism kräver tidsynkronisering ingen beräkning av fördröjningen av tiden på den väg som synchroniseringspaketet har tagit, som det görs vid grundläggande utbyte. Det vill säga, meddelanden Delay_Req och Delay_Resp skickas inte. I denna metod summeras fördröjningen mellan ledande och slava bara i korrigeringsfältet för varje Sync- eller Follow_Up-meddelande.

Ytterligare en fördel är att ledande klockor avlastas från behovet av att behandla meddelanden Delay_Req.

Driftslägen för transparenta klockor

Därmed har vi gått igenom enkla exempel. Låt oss nu anta att det dyker upp switchar på vägen för synkronisering.

Om switchar används utan stöd för PTPv2, kommer synkroniseringspaketet att försenas på switchen med ungefär 10 µs.

Switchar med stöd för PTPv2 kallas i IEEE 1588v2-terminologi transparenta klockor (Transparent clock). Transparenta klockor synkroniseras inte från ledande klockor och deltar inte i hierarkin 'Ledande klockor - Slavklockor', men vid överföring av synkroniseringsmeddelanden minns de hur mycket meddelandet har försenats. Detta möjliggör justering av tidsfördröjningen.

Transparenta klockor kan fungera i två lägen:

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

End-to-End (E2E)

E2E-transparenta klockor överför Sync-meddelanden och relaterade Follow_Up-meddelanden till alla portar. Även till de som blockeras av vissa protokoll (t.ex. RSTP).

Switchen lagrar en tidsstämpel när Sync-paketet (Follow_Up) har tagits emot på porten och när det har skickats från porten. Baserat på dessa två tidsstämplar beräknas den tid det tar för switchen att behandla meddelandet. I standarden kallas denna tid för residence time.

Behandlingstiden läggs till i correctionField-fältet i Sync-meddelandet (enkla klockor) eller Follow_Up (dubbla klockor).

Transparenta E2E-klockor mäter behandlingstiden för Sync- och Delay_Req-meddelanden som passerar genom switchen. Men det är viktigt att förstå att tidsfördröjningen mellan de ledande klockorna och de följande klockorna beräknas med hjälp av en fördröjning av begär-svar-mekanism. Om de ledande klockorna ändras eller om vägen från de ledande klockorna till de följande klockorna förändras, mäts fördröjningen om. Detta ökar övergångstiden i händelse av nätverksändringar.

Transparenta P2P-klockor, förutom att mäta den tid det tar att behandla meddelandet av switchen, mäter fördröjningen på datakanalen till den närmaste granne genom att använda en mekanism för att mäta granngränsens fördröjning.

Fördröjning mäts på varje kanal i båda riktningarna, inklusive kanaler som blockeras av någon protokoll (till exempel RSTP). Det gör att den nya fördröjningen på synkroniseringsvägen kan beräknas omedelbart om mästarur ger ändras eller om nätverkstopologin förändras.

Behandlingstiden för meddelanden som hanteras av switchar och tiden för fördröjning ackumuleras vid överföring av Sync- eller Follow_Up-meddelanden.

Typer av PTPv2-stöd av switchar

Switchar kan stödja PTPv2:

• programvarubaserat;
• hårdvarubaserat.

Vid programvaruimplementation av PTPv2-protokollet begär switchen en tidsstämpel från firmware. Problemet är att firmware arbetar cykliskt, så man måste vänta till den har avslutat sin nuvarande cykel, tar emot begäran och i nästa cykel ger ut tidsstämpeln. Detta tar också tid, vilket ger en fördröjning, om än inte lika mycket som utan programvarustöd för PTPv2.

Bara hårdvarustöd för PTPv2 kan uppnå nödvändig noggrannhet. I detta fall utförs tidsstämpeln av en speciell ASIC som är installerad på porten.

Meddelandets format

Alla PTP-meddelanden består av följande fält:

• Header – 34 byte.
• Body – storleken beror på meddelandets typ.
• Suffix – valfritt.

Header

Header-fältet är detsamma för alla PTP-meddelanden. Störrelsen är 34 byte.

Formatet för Header-fältet:

messageType – innehåller typen av det skickade meddelandet, till exempel Sync, Delay_Req, PDelay_Req osv.

messageLength – innehåller den totala storleken på PTP-meddelandet, inklusive header, body och suffix (men exklusive fyllnadsbyte).

domainNumber – definierar vilket domän PTP-meddelande tillhör. Det är flera olika klockor som samlas i en logisk grupp och synkroniseras från en eller flera ledarklockor, men behöver inte vara synkroniserade med klockor som tillhör en annan domän.

Domän flags

– detta fält innehåller olika flaggor för att identifiera meddelandets status. correctionField

– innehåller fördröjningstid i nanosekunder. Fördröjningstiden inkluderar fördröjning vid överföring genom genomskinliga klockor samt fördröjningen vid överföring genom kanalen i Peer-to-Peer-läget. sourcePortIdentity

– detta fält innehåller information om vilken port det ursprungliga meddelandet skickades från. sequenceID

– innehåller ett identifieringsnummer för individuella meddelanden. controlField

– fältartefakt=) Det kvarstod från den första versionen av standarden och innehåller information om typen av meddelande. I praktiken är det samma som messageType, men med färre alternativ. logMessageInterval

– detta fält definieras av typ av meddelande. Som diskuterats ovan finns det flera typer av meddelanden. Dessa typer beskrivs nedan:

Body

Announce-meddelandet

Announce-meddelandet används för att "berätta" för andra klockor inom samma domän om sina parametrar. Detta meddelande möjliggör att etablera hierarkin "Ledarklockor – Undersåtar".
Sync-meddelandet


Sync-meddelandet skickas av ledarklockorna och innehåller tiden för ledarklockorna vid det ögonblick när Sync-meddelandet skapades. Om ledarklockorna är dubbla, kommer tidsstämpeln i Sync-meddelandet att sättas till 0, och den aktuella tidsstämpeln kommer att skickas i det paralliserade Follow_Up-meddelandet. Sync-meddelandet används för båda fördröjningsmätningarna.
Meddelandet skickas med Multicast. Det går även att använda Unicast som ett val.

Delay_Req-meddelandet

Formatet för Delay_Req-meddelandet är identiskt med Sync-meddelandet. Undersåtar skickar Delay_Req. Det innehåller tidpunkten för när Delay_Req skickades av undersåtarna. Detta meddelande används endast för fördröjningsförfrågnings- och svarsmekanismen.

Meddelandet Delay_Req har samma format som meddelandet Sync. De styrda klockorna skickar Delay_Req. Det innehåller tidpunkten för när Delay_Req skickades av de styrda klockorna. Detta meddelande används endast för fördröjningsmekanismen för begäran-svar.

Delay_Req-meddelandet

Follow_Up-meddelande

Follow_Up-meddelandet skickas valfritt av ledande klockor och innehåller tid för avsändning Sync-meddelanden av mästaren. Follow_Up-meddelandet skickas endast av tvåstegs ledande klockor.

Follow_Up-meddelandet används för båda mekanismerna för att mäta fördröjning.

Delay_Req-meddelandet

Delay_Resp-meddelande

Delay_Resp-meddelandet skickas av ledande klockor. Det innehåller mottagningstiden för Delay_Req av ledande klockor. Detta meddelande används endast för mekanismen för begäran-svar på fördröjning.

Delay_Req-meddelandet

Pdelay_Req-meddelande

Pdelay_Req-meddelandet skickas av den enhet som begär fördröjning. Det innehåller avsändningstiden för meddelandet från porten på den enheten. Pdelay_Req används endast för mekanismen för att mäta fördröjningen hos angränsande noder.

Pdelay_Resp-meddelande

Pdelay_Resp-meddelandet skickas av den enhet som fått begäran om fördröjning. Det innehåller mottagningstiden för Pdelay_Req-meddelandet av denna enhet. Pdelay_Resp-meddelanden används endast för mekanismen för att mäta fördröjningen hos angränsande noder.

Pdelay_Resp_Follow_Up-meddelande

Pdelay_Resp_Follow_Up-meddelandet skickas valfritt av den enhet som fått begäran om fördröjning. Det innehåller mottagningstiden för Pdelay_Req-meddelandet av denna enhet. Pdelay_Resp_Follow_Up-meddelandet skickas endast av tvåstegs ledande klockor.

Detta meddelande kan också användas för executionstid istället för tidsstämpel. Executionstiden är tiden från det att Pdelay-Req mottas till Pdelay_Resp skickas.

Pdelay_Resp_Follow_Up används endast för mekanismen för att mäta fördröjningen hos angränsande noder.

Styrmeddelanden (Management-meddelande)

PTP-styrmeddelanden är nödvändiga för att överföra information mellan en eller flera klockor och styrnoden.

Överföring i LV

PTP-meddelande kan överföras på två nivåer:

• Nätverksnivå – som del av IP-data.
• Länk nivå – som del av Ethernet-ramar.

Överföring av PTP-meddelande via UDP över IP över Ethernet

PTP via UDP över Ethernet

Profiler

PTP har en hel del "flexibla" parametrar som behöver konfigureras. Till exempel:

• BMCA-alternativ.
• Mekanism för att mäta fördröjning.
• Intervall och initialvärden för alla konfigurerbara parametrar, osv.

Och trots att vi tidigare har sagt att PTPv2-enheter är kompatibla med varandra, så är det egentligen inte så. Enheterna måste ha samma inställningar för att kunna interagera.

Därför finns det så kallade PTPv2-profiler. Profilerna är grupper av konfigurerade inställningar och specifika begränsningar av protokollet för att möjliggöra tidssynkronisering för en viss applikation.

Den officiella standarden IEEE 1588v2 beskriver endast en profil – "Default Profile". Alla andra profiler har skapats och beskrivits av olika organisationer och föreningar.

Till exempel, profilen för energiområdet eller PTPv2 Power Profile skapades av Power Systems Relaying Committee och Substation Committee inom IEEE Power and Energy Society. Profilen kallas IEEE C37.238-2011.

Profilen beskriver att PTP kan överföras:

• Endast via L2-nätverk (det vill säga Ethernet, HSR, PRP, ej IP).
• Meddelanden överförs endast via Multicast-sändningar.
• Peer delay measurement mechanism används som fördröjningsmätning.

Standarddomänen är 0, den rekommenderade domänen är 93.

I filosofin bakom skapandet av C37.238-2011 låg en önskan att minska antalet valfria egenskaper och behålla endast de nödvändiga funktionerna för pålitlig interaktion mellan enheter och ökad stabilitet i systemet.

Dessutom har frekvensen för meddelandeöverföringar definierats:

I princip finns det endast ett alternativ att välja – typ av masterur (enstegs eller tvåstegs).

Noggrannheten får inte överstiga 1 µs. Med andra ord kan det finnas maximalt 15 transparenta klockor eller tre gränsklockor i en synkroniseringsväg.

Källa: habr.com