Implementeringsdetaljer för PTPv2-tidssynkroniseringsprotokollet

Inledning

Konceptet att bygga en "digital transformatorstation" inom elkraftindustrin kräver synkronisering med en noggrannhet på 1 μs. Finansiella transaktioner kräver också mikrosekunders noggrannhet. I dessa applikationer är NTP-tidsnoggrannheten inte längre tillräcklig.

PTPv2-synkroniseringsprotokollet, som beskrivs av IEEE 1588v2-standarden, tillåter en synkroniseringsnoggrannhet på flera tiotals nanosekunder. PTPv2 låter dig skicka synkroniseringspaket över L2- och L3-nätverk.

De huvudsakliga områdena där PTPv2 används är:

• energi;
• kontroll- och mätutrustning;
• militär-industriellt komplex;
• telekom;
• finansiell sektor.

Det här inlägget förklarar hur PTPv2-synkroniseringsprotokollet fungerar.

Vi har mer erfarenhet inom industrin och ser ofta detta protokoll i energitillämpningar. Därför kommer vi att göra granskningen 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 av PJSC Rosseti och STO 56947007-29.240.10.302-2020 av PJSC FGC UES krav för att organisera en processbuss med tidssynkronisering via PTPv2.

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

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

Till exempel kan försvar av absolut selektivitet falla offer för "svag" tidssynkronisering. Ofta bygger logiken i sådana försvar på en jämförelse av två kvantiteter. Om värdena avviker med ett tillräckligt stort värde, utlöses skyddet. Om dessa värden mäts med en tidsnoggrannhet på 1 ms, så kan man få en stor skillnad där värdena faktiskt är normala om de mäts med en noggrannhet på 1 μs.

PTP-versioner

PTP-protokollet beskrevs ursprungligen 2002 i IEEE 1588-2002-standarden och kallades "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems." 2008 släpptes den uppdaterade IEEE 1588-2008-standarden, som beskriver PTP version 2. Denna version av protokollet förbättrade noggrannheten och stabiliteten, men bibehöll inte bakåtkompatibilitet med den första versionen av protokollet. Under 2019 släpptes också en version av 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)

-
inkonsekvent

inkonsekvent

PTPv2 (IEEE 1588-2008)

inkonsekvent

-
kompatibel

PTPv2.1 (IEEE 1588-2019)

inkonsekvent

kompatibel

-

Men som alltid finns det nyanser.

Inkompatibilitet mellan PTPv1 och PTPv2 innebär att en PTPv1-aktiverad enhet inte kommer att kunna synkronisera med en exakt 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 samma nätverk. För att uppnå detta tillåter vissa tillverkare att du väljer protokollversionen på kantklockportarna. Det vill säga, en gränsklocka kan synkronisera med PTPv2 och fortfarande synkronisera andra klockor som är anslutna till den med både PTPv1 och PTPv2.

PTP-enheter. Vad är de och hur är de olika?

IEEE 1588v2-standarden beskriver flera typer av enheter. Alla visas i tabellen.

Enheterna kommunicerar med varandra över ett LAN med hjälp av PTP.

PTP-enheter kallas klockor. Alla klockor tar den exakta tiden från stormästarklockan.

Det finns 5 typer av klockor:

Stormästarklocka

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

Vanlig klocka

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

Master clock (master)

De är källan till den exakta tiden med vilken andra klockor synkroniseras

Slav klocka

Slutenhet som är synkroniserad från masterklockan

Gränsklocka

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

Det vill säga, dessa klockor kan synkronisera från den överlägsna masterklockan och synkronisera de sämre slavklockorna.

Transparent klocka från ände till ände

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

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

Korrigeringen sker genom att lägga till fördröjningstiden på denna enhet till 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 slav.
Den överför PTP-data mellan två klockor.

Vid överföring av data korrigerar den transparenta klockan alla PTP-meddelanden Sync och Follow_Up (mer om dem nedan).

Korrigeringen uppnås genom att addera till korrigeringsfältet för det överförda paketet fördröjningen på den sändande anordningen och fördröjningen på dataöverföringskanalen.

Management Node

En enhet som konfigurerar och diagnostiserar andra klockor

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

• Händelsemeddelanden är synkroniserade meddelanden som involverar generering av en tidsstämpel vid den tidpunkt då meddelandet skickas och vid den tidpunkt då det tas emot.
• Allmänna meddelanden - Dessa meddelanden kräver inga tidsstämplar, men kan innehålla tidsstämplar för relaterade meddelanden

Händelsemeddelanden

Allmänna meddelanden

Synkronisera
Delay_Req
Pdelay_Req
Pdelay_Resp

Meddela
Uppföljning
Delay_Resp
Pdelay_Resp_Follow_Up
Verksamhetsledningen
Signalering

Alla typer av meddelanden kommer att diskuteras mer i detalj nedan.

Grundläggande synkroniseringsproblem

När ett synkroniseringspaket sänds över ett lokalt nätverk fördröjs det vid switchen och i datalänken. Varje switch ger en fördröjning på cirka 10 mikrosekunder, vilket är oacceptabelt för PTPv2. När allt kommer omkring måste vi uppnå en noggrannhet på 1 μs på den slutliga enheten. (Detta är om vi pratar om energi. Andra applikationer kan kräva större noggrannhet.)

IEEE 1588v2 beskriver flera driftsalgoritmer som låter dig registrera tidsfördröjningen och korrigera den.

Arbetsalgoritm
Under normal drift fungerar protokollet i två faser.

• Fas 1 - upprättande av hierarkin "Master Clock - Slave Clock".
• Fas 2 - klocksynkronisering med en End-to-End- eller Peer-to-Peer-mekanism.

Fas 1 - Etablering av Mästar-Slav-hierarkin

Varje port av en vanlig klocka eller kantklocka har ett visst antal tillstånd (slavklocka och masterklocka). Standarden beskriver övergångsalgoritmen mellan dessa tillstånd. Inom programmering kallas en sådan algoritm för en finit tillståndsmaskin eller tillståndsmaskin (mer detaljer i Wiki).

Denna tillståndsmaskin använder Best Master Clock Algorithm (BMCA) för att ställa in mastern när två klockor ansluts.

Denna algoritm låter klockan ta över ansvaret för stormästarklockan när uppströms stormästarklockan tappar GPS-signal, går offline, etc.

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


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

En enkel hierarki visas i diagrammet nedan. Sökvägarna 1, 2, 3, 4, 5 kan innehålla en transparent klocka, men de deltar inte i upprättandet av hierarkin Master Clock - Slave Clock.

Fas 2 - Synkronisera vanliga klockor och kantklockor

Omedelbart efter att ha upprättat hierarkin "Master Clock - Slave Clock" börjar synkroniseringsfasen för vanliga klockor och gränsklockor.

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

Masterklockan kan vara:

• enstegs;
• tvåsteg.

Enstegsklockor skickar ett synkroniseringsmeddelande för att synkronisera.

En tvåstegsklocka använder två meddelanden för synkronisering - Sync och Follow_Up.

Två mekanismer kan användas för synkroniseringsfasen:

• Mekanism för fördröjning av begäran-svar.
• Mätmekanism för peer-fördröjning.

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

Mekanism för fördröjning av begäran-svar

Mekanismen innefattar två steg:

1. Mätning av fördröjningen vid sändning av ett meddelande mellan masterklockan och slavklockan. Utförs med hjälp av en fördröjningsförfrågan-svarsmekanism.
2. Korrigering av den exakta tidsförskjutningen utförs.

Latensmätning


t1 – Tidpunkt då synkroniseringsmeddelandet skickades av masterklockan; t2 – Tid för mottagning av Sync-meddelandet av slavklockan; t3 – Tid för sändning av fördröjningsbegäran (Delay_Req) ​​av slavklockan; t4 – Delay_Req mottagningstid av masterklockan.

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

Vid sändning av ett Sync and Follow_Up-meddelande beräknas tidsfördröjningen från mastern till slaven - t-ms.

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

Om viss asymmetri uppstår mellan dessa två värden, uppstår ett fel vid korrigering av avvikelsen för den exakta tiden. Felet orsakas av att den beräknade fördröjningen är medelvärdet av t-ms- och t-sm-fördröjningarna. Om förseningarna inte är lika med varandra kommer vi inte att justera tiden exakt.

Korrigering av tidsförskjutning

När väl fördröjningen mellan masterklockan och slavklockan är känd, utför slavklockan tidskorrigering.

Slavklockor använder Sync-meddelandet och ett valfritt Follow_Up-meddelande för att beräkna den exakta tidsförskjutningen vid överföring av ett paket från master- till slavklockorna. Skiftet beräknas med följande formel:

Mätmekanism för peer-fördröjning

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

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

Mätning av latens mellan enheter som stöder Peer-to-Peer-läge

Latensen 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 medelfördröjningen (tmld). Det beräknas med följande formel:

Porten använder sedan detta värde när man beräknar justeringsfältet för varje Sync-meddelande eller valfritt Follow_Up-meddelande som passerar genom enheten.

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

Meddelanden Pdelay_Req, Pdelay_Resp och valfri Pdelay_Resp_Follow_Up låter dig få fördröjningen från master till slav och från slav till master (cirkulär).

All asymmetri mellan dessa två värden kommer att introducera ett tidsförskjutningskorrigeringsfel.

Justera den exakta tidsförskjutningen

Slavklockor använder ett Sync-meddelande och ett valfritt Follow_Up-meddelande för att beräkna den exakta tidsförskjutningen vid överföring av ett paket från master- till slavklockorna. Skiftet beräknas med följande formel:

Fördelar justering av peer-to-peer-mekanismen - tidsfördröjningen för varje Sync- eller Follow_Up-meddelande beräknas när det sänds i nätverket. Följaktligen kommer att ändra överföringsvägen inte på något sätt påverka noggrannheten i justeringen.

När man använder denna mekanism kräver tidssynkronisering inte att man beräknar tidsfördröjningen längs vägen som korsas av synkroniseringspaketet, vilket görs i den grundläggande växeln. De där. Delay_Req och Delay_Resp meddelanden skickas inte. I denna metod summeras fördröjningen mellan master- och slavklockorna helt enkelt i justeringsfältet för varje Sync- eller Follow_Up-meddelande.

En annan fördel är att masterklockan är befriad från behovet av att behandla Delay_Req-meddelanden.

Driftlägen för transparenta klockor

Följaktligen var dessa enkla exempel. Anta nu att omkopplare visas på synkroniseringsvägen.

Om du använder switchar utan PTPv2-stöd kommer synkroniseringspaketet att försenas 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 "Master Clock - Slave Clock", men när de sänder synkroniseringsmeddelanden kommer de ihåg hur länge meddelandet försenades av dem. Detta låter dig justera tidsfördröjningen.

Transparenta klockor kan fungera i två lägen:

• Början till slut.
• Peer to peer.

End-to-end (E2E)

Den genomskinliga E2E-klockan sänder Sync-meddelanden och medföljande uppföljningsmeddelanden på alla portar. Även de som är blockerade av vissa protokoll (till exempel RSTP).

Switchen kommer ihåg tidsstämpeln när ett Sync-paket (Follow_Up) togs emot på porten och när det skickades från porten. Baserat på dessa två tidsstämplar beräknas tiden det tar för växeln att bearbeta meddelandet. I standarden kallas denna tid för uppehållstid.

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

Den transparenta E2E-klockan 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 masterklockan och slavklockan beräknas med hjälp av fördröjningsförfrågan-svarsmekanismen. Om masterklockan ändras eller vägen från masterklockan till slavklockan ändras, mäts fördröjningen igen. Detta ökar övergångstiden vid nätverksändringar.

Den transparenta P2P-klockan, förutom att mäta tiden det tar för en switch att bearbeta ett meddelande, mäter fördröjningen på datalänken till sin närmaste granne med hjälp av en grannlatensmekanism.

Latensen mäts på varje länk i båda riktningarna, inklusive länkar som blockeras av något protokoll (som RSTP). Detta gör att du omedelbart kan beräkna den nya fördröjningen i synkroniseringsvägen om stormästarklockan eller nätverkstopologin ändras.

Meddelandebehandlingstid genom switchar och latens ackumuleras när Sync- eller Follow_Up-meddelanden skickas.

Typer av PTPv2-stöd med switchar

Switchar kan stödja PTPv2:

• programmatiskt;
• hårdvara.

När PTPv2-protokollet implementeras i programvaran begär switchen en tidsstämpel från den fasta programvaran. Problemet är att den fasta programvaran fungerar cykliskt, och du måste vänta tills den avslutar den aktuella cykeln, tar begäran om 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, om än inte lika betydande som utan mjukvarustöd för PTPv2.

Endast hårdvarustöd för PTPv2 låter dig bibehålla den nödvändiga noggrannheten. I det här fallet utfärdas tidsstämpeln av en speciell ASIC, som är installerad på porten.

Meddelandeformat

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

• Rubrik – 34 byte.
• Kropp – storleken beror på typen av meddelande.
• Suffix är valfritt.

Sidhuvud

Rubrikfältet är detsamma för alla PTP-meddelanden. Dess storlek är 34 byte.

Rubrikfältformat:

meddelandeTyp – innehåller typen av meddelande som sänds, till exempel Sync, Delay_Req, PDelay_Req, etc.

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

domännummer – bestämmer vilken PTP-domän meddelandet tillhör.

Домен - dessa är flera olika klockor samlade i en logisk grupp och synkroniserade från en masterklocka, 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 genom den transparenta klockan, såväl som fördröjningen vid sändning genom kanalen vid användning av Peer-to-Peer-läge.

sourcePortIdentity – detta fält innehåller information om vilken port detta meddelande ursprungligen skickades från.

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

kontrollfält – artefaktfält =) Det finns kvar från den första versionen av standarden och innehåller information om typen av detta meddelande. I huvudsak samma som messageType, men med färre alternativ.

logMessageInterval – detta fält bestäms av meddelandetypen.

Kaross

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

Tillkännagivande meddelande
Meddelandet Announce används för att "berätta" för andra klockor inom samma domän om dess parametrar. Detta meddelande låter dig ställa in en hierarki för masterklocka - slavklocka.


Meddelandesynkronisering
Synkroniseringsmeddelandet skickas av huvudklockan och innehåller tiden för huvudklockan vid den tidpunkt då synkmeddelandet genererades. Om masterklockan är tvåstegs kommer tidsstämpeln i Sync-meddelandet att ställas till 0, och den aktuella tidsstämpeln kommer att skickas i det associerade Follow_Up-meddelandet. Synkroniseringsmeddelandet används för båda latensmätningsmekanismerna.

Meddelandet sänds med Multicast. Alternativt kan du använda Unicast.

Delay_Req meddelande

Formatet för Delay_Req-meddelandet är identiskt med Sync-meddelandet. Slavklockan skickar Delay_Req. Den innehåller tiden som Delay_Req skickades av slavklockan. Detta meddelande används endast för mekanismen för fördröjning av begäran och svar.

Meddelandet sänds med Multicast. Alternativt kan du använda Unicast.

Uppföljningsmeddelande

Uppföljningsmeddelandet skickas valfritt av huvudklockan och innehåller sändningstiden Synkronisera meddelanden bemästra. Endast tvåstegs masterklockor skickar uppföljningsmeddelandet.

Uppföljningsmeddelandet används för båda latensmätningsmekanismerna.

Meddelandet sänds med Multicast. Alternativt kan du använda Unicast.

Delay_Resp meddelande

Delay_Resp-meddelandet skickas av masterklockan. Den innehåller tiden när Delay_Req togs emot av masterklockan. Detta meddelande används endast för mekanismen för fördröjning av begäran och svar.

Meddelandet sänds med Multicast. Alternativt kan du använda Unicast.

Pdelay_Req meddelande

Pdelay_Req-meddelandet skickas av en enhet som begär en fördröjning. Den innehåller tiden då meddelandet skickades från porten på den här enheten. Pdelay_Req används endast för grannfördröjningsmätningsmekanismen.

Pdelay_Resp meddelande

Pdelay_Resp-meddelandet skickas av en enhet som har tagit emot en fördröjningsbegäran. Den innehåller den tid då Pdelay_Req-meddelandet togs emot av den här enheten. Pdelay_Resp-meddelandet används endast för grannfördröjningsmätningsmekanismen.

Meddelande Pdelay_Resp_Follow_Up

Pdelay_Resp_Follow_Up-meddelandet skickas valfritt av enheten som har tagit emot fördröjningsbegäran. Den innehåller den tid då Pdelay_Req-meddelandet togs emot av den här enheten. Pdelay_Resp_Follow_Up-meddelandet skickas endast av tvåstegs masterklockor.

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

Pdelay_Resp_Follow_Up används endast för grannfördröjningsmätningsmekanismen.

Managementmeddelanden

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

Överföring till LV

Ett PTP-meddelande kan sändas på två nivåer:

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

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

PTP över UDP över Ethernet

Profiler

PTP har en hel del flexibla parametrar som måste konfigureras. Till exempel:

• BMCA-alternativ.
• Latensmätningsmekanism.
• Intervaller och initiala värden för alla konfigurerbara parametrar, etc.

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

Det är därför det finns så kallade PTPv2-profiler. Profiler är grupper av konfigurerade inställningar och definierade protokollbegränsningar så att tidssynkronisering kan implementeras för en specifik applikation.

Själva IEEE 1588v2-standarden beskriver endast en profil – "Standardprofil". Alla andra profiler skapas och beskrivs av olika organisationer och föreningar.

Till exempel skapades Power Profile, eller PTPv2 Power Profile, av Power Systems Relaying Committee och Substation Committee i 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, icke-IP).
• Meddelanden sänds endast via multicast-sändning.
• Peer fördröjningsmätningsmekanism används som en fördröjningsmätningsmekanism.

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

Designfilosofin för C37.238-2011 var att minska antalet valfria funktioner och endast behålla de nödvändiga funktionerna för pålitlig interaktion mellan enheter och ökad systemstabilitet.

Frekvensen för meddelandeöverföring bestäms också:

Faktum är att endast en parameter är tillgänglig för val - typen av masterklocka (enstegs eller tvåstegs).

Noggrannheten bör inte vara mer än 1 μs. Med andra ord kan en synkroniseringsväg innehålla maximalt 15 transparenta klockor eller tre gränsklockor.

Källa: will.com