🥇Detaljer om implementering av PTPv2-tidssynkroniseringsprotokoll

Inledning

Konceptet att bygga en "digital transformatorstation" inom kraftindustrin kräver synkronisering med en noggrannhet på 1 μs. Finansiella transaktioner kräver också noggrannhet i μs. I dessa tillämpningar är noggrannheten i NTP-tiden inte längre tillräcklig.

PTPv2-synkroniseringsprotokollet, som beskrivs av IEEE 1588v2-standarden, möjliggör synkroniseringsnoggrannhet inom tiotals nanosekunder. PTPv2 gör det möjligt att skicka synkroniseringspaket via L2- och L3-nätverk.

De huvudsakliga områdena där PTPv2 tillämpas är:

energi;
kontroll- och mätutrustning;
militärindustriella komplexet;
telekom;
finanssektorn.

Det här inlägget diskuterar hur PTPv2-synkroniseringsprotokollet fungerar.

Vi har mer erfarenhet inom industrin och stöter ofta på detta protokoll i energiapplikationer. Därför kommer vi att göra en granskning med försiktighet. för energi.

Varför är det nödvändigt?

För närvarande innehåller STO 34.01-21-004-2019 från PJSC Rosseti och STO 56947007-29.240.10.302-2020 från PJSC FGC UES krav för att organisera en processbuss med tidssynkronisering via PTPv2.

Detta beror på att reläskyddsterminaler och mätanordningar är anslutna till processbussen, vilka överför momentana ström- och spänningsvärden via processbussen med hjälp av så kallade SV-strömmar (multicast-strömmar).

Reläskyddsterminaler använder dessa värden för att implementera matarskydd. Om noggrannheten i tidsmätningarna är liten kan vissa skydd fungera felaktigt.

Till exempel kan absoluta selektivitetsskydd falla offer för "svag" tidssynkronisering. Ofta är logiken bakom sådana skydd baserad på att jämföra två värden. Om värdena skiljer sig åt med ett tillräckligt stort värde, utlöses skyddet. Om dessa värden mäts med en tidsnoggrannhet på 1 ms, kan en stor skillnad erhållas där värdena faktiskt är normala om de mäts med en noggrannhet på 1 μs.

PTP-versioner

PTP-protokollet beskrevs ursprungligen år 2002 i IEEE 1588-2002-standarden och kallades "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". År 2008 släpptes en uppdaterad IEEE 1588-2008-standard, som beskriver PTP version 2. Denna version av protokollet förbättrade noggrannhet och stabilitet, men bibehöll inte bakåtkompatibilitet med den första versionen av protokollet. År 2019 släpptes också IEEE 1588-2019-standarden, som beskriver PTP v2.1. Denna version lägger till mindre förbättringar av PTPv2 och är bakåtkompatibel med PTPv2.

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

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

-
Oförenlig

Oförenlig

PTPv2 (IEEE 1588-2008)

Oförenlig

-
Kompatibel

PTPv2.1 (IEEE 1588-2019)

Oförenlig

Kompatibel

Men, som alltid, finns det nyanser.

Inkompatibiliteten mellan PTPv1 och PTPv2 innebär att en PTPv1-kompatibel enhet inte kommer att kunna synkronisera med en korrekt klocka som körs på PTPv2. De använder olika meddelandeformat för att synkronisera.

Men det är fortfarande möjligt att kombinera enheter med PTPv1 och enheter med PTPv2 i ett nätverk. För detta ändamål tillåter vissa tillverkare att man väljer protokollversion på portarna för gränsklockor. Det vill säga att gränsklockor kan synkronisera via PTPv2 och samtidigt synkronisera andra klockor som är anslutna till dem via både PTPv1 och PTPv2.

PTP-enheter. Vad är de och hur skiljer de sig?

IEEE 1588v2 beskriver flera typer av enheter. Alla listas i tabellen.

Enheterna kommunicerar med varandra via LAN med hjälp av PTP.

PTP-enheter kallas klockor. Alla klockor tar sin exakta tid från Grandmaster Clock.

Det finns 5 typer av klockor:

Stormästareklocka

Den huvudsakliga källan för korrekt tid. Ofta utrustad med ett gränssnitt för anslutning av GPS.

Vanlig klocka

En enhet med en enda port som kan vara en master (masterklocka) eller en slav (slavklocka)

Huvudklocka (Master)

De är källan till exakt tid med vilken andra klockor synkroniseras.

Slavklocka

En slutenhet som är synkroniserad från en huvudklocka.

Gränsklocka

En enhet med flera portar som kan vara antingen en master eller en slav.

Det vill säga, dessa klockor kan synkroniseras från masterklockan på högre nivå och synkronisera slavklockorna på lägre nivå.

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

En enhet med flera portar som varken är en master- eller en slavklocka. Den skickar PTP-data mellan två klockor.

Vid dataöverföring justerar den transparenta klockan alla PTP-meddelanden.

Korrigeringen görs genom att lägga till fördröjningstiden på den här enheten i korrigeringsfältet i rubriken på det överförda meddelandet.

Peer-to-Peer Transparent Klocka

En enhet med flera portar som varken är en masterklocka eller en slavklocka.
Den överför PTP-data mellan två klockor.

Vid dataöverföring justerar den transparenta klockan alla PTP-synkroniserings- och uppföljningsmeddelanden (mer om dem nedan).

Korrigeringen uppnås genom att lägga till fördröjningen vid den sändande enheten och fördröjningen vid dataöverföringskanalen till korrigeringsfältet för det sända paketet.

Hanteringsnod

En enhet som konfigurerar och diagnostiserar andra klockor.

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

Händelsemeddelanden är synkroniserade meddelanden som genererar en tidsstämpel vid tidpunkten då meddelandet skickas och vid tidpunkten då det tas emot.
Allmänna meddelanden – Dessa meddelanden kräver inte tidsstämplar, men kan innehålla tidsstämplar för relaterade meddelanden.

Händelsemeddelanden

Allmänna meddelanden

Synkronisera
Fördröjningskrav
Pdelay_Req
Pdelay_Resp

Meddela
Uppföljning
Fördröjningssvar
Pdelay_Resp_Follow_Up
Verksamhetsledningen
Signalering

Nedan kommer vi att granska alla typer av meddelanden mer i detalj.

Grundläggande synkroniseringsproblem

När man skickar ett synkroniseringspaket via ett lokalt nätverk fördröjs det på switchen och i dataöverföringskanalen. En switch ger en fördröjning på cirka 10 µs, vilket är oacceptabelt för PTPv2. Vi behöver trots allt en noggrannhet på 1 µs på slutenheten. (Detta gäller om vi pratar om energi. Andra applikationer kan kräva större noggrannhet.)

IEEE 1588v2 beskriver flera driftsalgoritmer som gör det möjligt att registrera och justera tidsfördröjning.

Arbetsalgoritm
Under normal drift fungerar protokollet i två faser.

Fas 1 - Upprättande av hierarki mellan huvudklocka och slavklocka.
Fas 2 - klocksynkronisering med hjälp av End-to-End- eller Peer-to-Peer-mekanismen.

Fas 1 - Konfigurera master-slave-hierarkin

Varje port i en normalklocka eller gränsklocka har ett visst antal tillstånd (slavklocka och masterklocka). Standarden beskriver en algoritm för övergång mellan dessa tillstånd. Inom programmering kallas en sådan algoritm en finita tillståndsmaskin (mer information finns i Wiki).

Denna tillståndsmaskin använder algoritmen Best Master Clock (BMCA) för att upprätta en master när två klockor är anslutna.

Denna algoritm gör det möjligt för en klocka att ta över ansvaret för en stormästares klocka när en överlägsen stormästares klocka förlorar GPS-signal, går offline, etc.

Tillståndsövergångarna enligt BMCA sammanfattas i följande diagram:

Information om klockan i andra änden av "kabeln" skickas i ett särskilt meddelande (Announce message). När denna information tas emot körs tillståndsmaskinens algoritm och en jämförelse görs för att se vilken klocka som är bättre. Porten på den bästa klockan blir huvudklockan.

En enkel hierarki visas i diagrammet nedan. Banorna 1, 2, 3, 4, 5 kan innehålla transparenta klockor, men de deltar inte i upprättandet av hierarkin mellan huvudklocka och slavklocka.

Fas 2 - Synkronisering av normala och randklockor

Omedelbart efter att hierarkin mellan huvudklocka och slavklocka har upprättats börjar synkroniseringsfasen för normalklockorna och randklockorna.

För att synkronisera skickar huvudklockan ett meddelande som innehåller en tidsstämpel till slavklockan.

Den ledande klockan kan vara:

enstegs;
tvåstegs.

Enstegsklockor skickar ett synkroniseringsmeddelande för att synkronisera.

Tvåstegsklockor använder två meddelanden för synkronisering – Sync och Follow_Up.

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

Fördröjningsmekanism för begäran och svar.
Mekanism för mätning av peer-fördröjning.

Låt oss börja med att titta på dessa mekanismer i sin enklaste form – när genomskinliga klockor inte används.

Fördröjningsmekanism för begäran och svar

Mekanismen omfattar två steg:

Mätning av fördröjningen i överföringen av ett meddelande mellan en huvudklocka och slavar. Detta görs med hjälp av en mekanism för fördröjningsbegäran och -svar.
Den exakta tidsförskjutningen korrigeras.

Mätning av latens

t1 – Tidpunkt för sändning av synkroniseringsmeddelande av huvudklockan; t2 – Tidpunkt för mottagande av synkroniseringsmeddelande av slavklockan; t3 – Tidpunkt för sändning av fördröjningsbegäran (Delay_Req) av slavklockan; t4 – Tidpunkt för mottagande av Delay_Req av huvudklockan.

När slavklockan känner till tiderna t1, t2, t3 och t4 kan den beräkna den genomsnittliga fördröjningen vid sändning av ett synkroniseringsmeddelande (tmpd). Den beräknas enligt följande:

Vid sändning av Sync- och Follow_Up-meddelanden beräknas tidsfördröjningen från mastern till slaven – t-ms.

Vid sändning av meddelanden Delay_Req och Delay_Resp beräknas tidsfördröjningen från slaven till mastern – t-sm.

Om det finns någon asymmetri mellan dessa två värden uppstår ett fel i korrigeringen av den exakta tidsavvikelsen. Felet orsakas av 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 med varandra korrigerar vi tiden felaktigt.

Korrigering av exakt tidsförskjutning

När fördröjningen mellan huvudklockan och slavklockan är känd utför slavklockan tidskorrigering.

Slavklockor använder Sync-meddelandet och det valfria Follow_Up-meddelandet för att beräkna den exakta tidsförskjutningen när ett paket skickas från huvudklockan till slavklockan. Förskjutningen beräknas med följande formel:

Mekanism för mätning av peer delay

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

Enheter mäter tidsfördröjningen till alla grannar genom alla portar. För att göra detta använder de peer-fördröjningsmekanismen.
Korrigering av den exakta tidsförskjutningen.

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

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 med följande formel:

Porten använder sedan detta värde vid beräkning av justeringsfältet för varje synkroniseringsmeddelande eller valfritt uppföljningsmeddelande som passerar genom enheten.

Den resulterande fördröjningen kommer att vara lika med summan av fördröjningen i överföringen genom denna enhet, den genomsnittliga fördröjningen i överföringen genom datakanalen och fördröjningen som redan finns i detta meddelande, inkluderad på uppströmsenheter.

Meddelandena Pdelay_Req, Pdelay_Resp och de valfria Pdelay_Resp_Follow_Up gör det möjligt att få en fördröjning från master till slav och från slav till master (tur och retur).

Varje asymmetri mellan dessa två värden kommer att introducera ett korrigeringsfel för tidsförskjutning.

Korrigering av exakt tidsförskjutning

Fördelarna med justeringen av peer-to-peer-mekanismen är att tidsfördröjningen för varje Sync- eller Follow_Up-meddelande beräknas allt eftersom det överförs i nätverket. Därför kommer ändring av överföringsvägen inte att påverka justeringens noggrannhet på något sätt.

Med denna mekanism kräver tidssynkronisering inte att tidsfördröjningen beräknas på den väg som synkroniseringspaketet färdas, vilket görs i det grundläggande utbytet. Det vill säga, Delay_Req- och Delay_Resp-meddelanden skickas inte. I den här metoden summeras fördröjningen mellan huvudklockan och slavarna helt enkelt i justeringsfältet för varje Sync- eller Follow_Up-meddelande.

En annan fördel är att huvudklockan befrias från bördan av att hantera Delay_Req-meddelanden.

Driftlägen för transparenta klockor

Följaktligen var detta enkla exempel. Låt oss nu anta att switchar visas på synkroniseringsvägen.

Om du använder switchar som inte stöder PTPv2 kommer synkroniseringspaketet att fördröjas på switchen med cirka 10 µs.

Switchar som stöder PTPv2 kallas transparenta klockor i IEEE 1588v2-terminologi. Transparenta klockor synkroniseras inte från huvudklockan och deltar inte i hierarkin mellan huvudklocka och slavklocka, men när de skickar synkroniseringsmeddelanden kommer de ihåg hur länge meddelandet var försenat. Detta gör att du kan justera tidsfördröjningen.

Transparenta klockor kan fungera i två lägen:

Från början till slut.
Peer to peer.

Änd-till-änd (E2E)

Transparenta E2E-klockor sänder synkroniseringsmeddelanden och tillhörande Follow_Up-meddelanden på alla portar. Även de som blockeras av vissa protokoll (t.ex. RSTP).

Switchen kommer ihåg tidsstämpeln för när Sync (Follow_Up)-paketet mottogs på porten och när det skickades från porten. Baserat på dessa två tidsstämplar beräknas den tid det tog för switchen att bearbeta meddelandet. I standarden kallas denna tid för uppehållstid.

Bearbetningstiden läggs till i fältet correctionField i meddelandet Sync (enstegsklocka) eller Follow_Up (tvåstegsklocka).

Transparenta E2E-klockor mäter bearbetningstiden för Sync- och Delay_Req-meddelanden som passerar genom switchen. Det är dock viktigt att förstå att tidsfördröjningen mellan masterklockan och slavklockorna beräknas med hjälp av fördröjningsrequest-response-mekanismen. Om masterklockan ändras eller vägen från masterklockan till slavklockorna ändras, mäts fördröjningen igen. Detta ökar övergångstiden vid nätverksändringar.

Transparenta P2P-klockor mäter, förutom att mäta switchens meddelandebehandlingstid, fördröjningen på dataöverföringskanalen till närmaste granne med hjälp av grannfördröjningsmätningsmekanismen.

Fördröjningen mäts på varje länk i båda riktningarna, inklusive länkar som blockeras av något protokoll (t.ex. RSTP). Detta gör att den nya fördröjningen på synkroniseringsvägen kan beräknas omedelbart om grandmasterklockan eller nätverkstopologin har ändrats.

Meddelandebehandlingstiden för switchar och latenstiden ackumuleras vid sändning av Sync- eller Follow_Up-meddelanden.

Typer av PTPv2-stöd via switchar

Switchar kan stödja PTPv2:

programmatiskt;
hårdvara.

Med programvaruimplementering av PTPv2-protokollet begär switchen en tidsstämpel från firmware. Problemet är att firmware fungerar cykliskt, och du måste vänta tills den avslutar den aktuella cykeln, tar emot begäran för bearbetning och utfärdar en tidsstämpel efter nästa cykel. Detta kommer också att ta tid, och vi kommer att få en fördröjning, men inte lika betydande som utan programvarusupport för PTPv2.

Endast hårdvarustöd för PTPv2 möjliggör upprätthållande av den erforderliga noggrannheten. I detta fall utfärdas tidsstämpeln av en speciell ASIC installerad på porten.

Meddelandeformat

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

Rubrik – 34 byte.
Brödtext – storleken beror på meddelandetypen.
Suffix – valfritt.

Sidhuvud

Rubrikfältet är detsamma för alla PTP-meddelanden och är 34 byte stort.

Format för rubrikfält:

meddelandetyp – innehåller typen av meddelande som överförs, såsom Sync, Delay_Req, PDelay_Req, etc.

meddelandelängd – innehåller PTP-meddelandets fulla storlek, inklusive rubrik, brödtext och suffix (men exklusive utfyllnadsbyte).

domännummer – avgör vilken domän PTP äger meddelandet.

Домен – det här är flera olika klockor samlade i en logisk grupp och synkroniserade från en huvudklocka, men inte nödvändigtvis synkroniserade med klockor som tillhör en annan domän.

flaggorna – Det här fältet innehåller olika flaggor för att identifiera meddelandets status.

korrigeringsfält – innehåller fördröjningstiden i nanosekunder. Fördröjningstiden inkluderar fördröjningen vid sändning via en transparent klocka, såväl som fördröjningen vid sändning via en kanal när Peer-to-Peer-läge används.

källportidentitet – det här fältet innehåller information om porten från vilken meddelandet ursprungligen skickades.

sekvens-ID – innehåller ett identifieringsnummer för enskilda meddelanden.

kontrollfält – artefaktfält=) Det här är en överblivelse från den första versionen av standarden och innehåller information om meddelandets typ. I huvudsak är det samma sak som messageType, men med färre alternativ.

loggmeddelandeintervall – det här fältet bestäms av meddelandetypen.

Kaross

Som diskuterats ovan finns det flera typer av meddelanden. Dessa typer beskrivs nedan:

Meddelande
Meddelandet Announce används för att "informera" andra klockor inom samma domän om dess parametrar. Detta meddelande gör det möjligt att etablera en "Master - Slave"-hierarki.

Synkroniseringsmeddelande
Synkroniseringsmeddelandet skickas av huvudklockan och innehåller huvudklockans tidpunkt vid den tidpunkt då synkroniseringsmeddelandet genererades. Om huvudklockan är tvåstegs kommer tidsstämpeln i synkroniseringsmeddelandet att sättas till 0, och den faktiska tidsstämpeln kommer att skickas i det tillhörande Follow_Up-meddelandet. Synkroniseringsmeddelandet används för båda latensmätningsmekanismerna.

Meddelandet överförs med hjälp av multicast. Valfritt kan unicast användas.

Meddelandefördröjningskrav

Formatet för Delay_Req-meddelandet är identiskt med Sync-meddelandet. Slavklockan skickar en Delay_Req. Den innehåller den tidpunkt då slavklockan skickade Delay_Req. Detta meddelande används endast för mekanismen för fördröjningsbegäran och -svar.

Meddelandet överförs med hjälp av multicast. Valfritt kan unicast användas.

Uppföljningsmeddelande

Follow_Up-meddelandet skickas valfritt av huvudklockan och innehåller sändningstiden. Synkronisera meddelanden master. Follow_Up-meddelandet skickas endast av tvåstegs masterklockor.

Follow_Up-meddelandet används för båda mekanismerna för latensmätning.

Meddelandet överförs med hjälp av multicast. Valfritt kan unicast användas.

Meddelandefördröjning_svar

Meddelandet Delay_Resp skickas av huvudklockan. Det innehåller den tidpunkt då Delay_Req mottogs av huvudklockan. Detta meddelande används endast för mekanismen för fördröjningsbegäran och -svar.

Meddelandet överförs med hjälp av multicast. Valfritt kan unicast användas.

Meddelande Pdelay_Req

Meddelandet Pdelay_Req skickas av den enhet som begär en fördröjning. Det innehåller den tidpunkt då meddelandet skickades från porten på den här enheten. Pdelay_Req används endast för mekanismen för att mäta fördröjningen för en angränsande nod.

Meddelande Pdelay_Resp

Meddelandet Pdelay_Resp skickas av en enhet som har mottagit en fördröjningsbegäran. Det innehåller den tidpunkt då Pdelay_Req-meddelandet mottogs av enheten. Meddelandet Pdelay_Resp används endast för mätmekanismen för grannfördröjning.

Meddelande Pdelay_Resp_Follow_Up

Meddelandet Pdelay_Resp_Follow_Up skickas valfritt av en enhet som har mottagit en uppföljningsbegäran. Det innehåller den tidpunkt då Pdelay_Req-meddelandet mottogs av den enheten. Meddelandet Pdelay_Resp_Follow_Up skickas endast av tvåstegs huvudklockor.

Detta meddelande kan också användas för exekveringstid istället för tidsstämpel. Exekveringstiden är tiden från att Pdelay-Req tas emot till att Pdelay_Resp skickas.

Pdelay_Resp_Follow_Up används endast för mätmekanismen för grannfördröjning.

Meddelanden från ledningen

PTP-kontrollmeddelanden krävs för att överföra information mellan en eller flera klockor och en styrande nod.

Överföring till LV

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

Nätverk – som en del av IP-data.
Kanal – som en del av en Ethernet-ram.

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

PTP över UDP över Ethernet

Profiler

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

BMCA-alternativ.
Fördröjningsmätningsmekanism.
Intervall och initialvärden för alla konfigurerbara parametrar etc.

Och trots att vi tidigare sagt att PTPv2-enheter är kompatibla med varandra, så är det på ett bra sätt inte sant. Enheter måste ha samma inställningar för att kunna interagera.

Därför finns det så kallade PTPv2-profiler. Profiler är grupper av konfigurerade inställningar och vissa protokollrestriktioner för att implementera tidssynkronisering för en specifik applikation.

Själva IEEE 1588v2-standarden beskriver endast en profil – ”Standardprofilen”. Alla andra profiler skapas och beskrivs av olika organisationer och sammanslutningar.

Till exempel skapades Power Systems Profile eller PTPv2 Power Profile av Power Systems Relaying Committee och Substation Committee inom IEEE Power and Energy Society. Själva profilen heter IEEE C37.238-2011.

Profilen beskriver att PTP kan överföras:

Endast via L2-nätverk (dvs. Ethernet, HSR, PRP, inte IP).
Meddelanden överförs endast via multicast.
Peer-fördröjningsmätningsmekanism används som en fördröjningsmätningsmekanism.

Standarddomänen är 0, rekommenderad domän är 93.

Filosofin bakom skapandet av C37.238-2011 var att minska antalet valfria funktioner och endast lämna de nödvändiga funktionerna för tillförlitlig interaktion mellan enheter och ökad systemstabilitet.

Även frekvensen för meddelandeöverföring definieras:

Faktum är att det bara finns en parameter tillgänglig för val – typen av ledande klocka (enstegs eller tvåstegs).