Implementeringsdetaljer for PTPv2-tidssynkroniseringsprotokollen

Innledning

Konseptet med å bygge en "digital understasjon" i den elektriske kraftindustrien krever synkronisering med en nøyaktighet på 1 μs. Finansielle transaksjoner krever også mikrosekunders nøyaktighet. I disse applikasjonene er NTP-tidsnøyaktigheten ikke lenger tilstrekkelig.

PTPv2-synkroniseringsprotokollen, beskrevet av IEEE 1588v2-standarden, tillater synkroniseringsnøyaktighet på flere titalls nanosekunder. PTPv2 lar deg sende synkroniseringspakker over L2- og L3-nettverk.

Hovedområdene der PTPv2 brukes er:

• energi;
• kontroll- og måleutstyr;
• militær-industrielt kompleks;
• telekom;
• finanssektoren.

Dette innlegget forklarer hvordan PTPv2-synkroniseringsprotokollen fungerer.

Vi har mer erfaring i industrien og ser ofte denne protokollen i energiapplikasjoner. Følgelig vil vi gjøre gjennomgangen med forsiktighet for energi.

Hvorfor er det nødvendig?

For øyeblikket inneholder STO 34.01-21-004-2019 av PJSC Rosseti og STO 56947007-29.240.10.302-2020 av PJSC FGC UES krav for organisering av en prosessbuss med tidssynkronisering via PTPv2.

Dette skyldes det faktum at relébeskyttelsesterminaler og måleenheter er koblet til prosessbussen, som overfører øyeblikkelige strøm- og spenningsverdier gjennom prosessbussen, ved bruk av såkalte SV-strømmer (multicast-strømmer).

Relébeskyttelsesterminaler bruker disse verdiene for å implementere buktbeskyttelse. Hvis nøyaktigheten av tidsmålinger er liten, kan noen beskyttelser fungere feilaktig.

For eksempel kan forsvar av absolutt selektivitet bli offer for "svak" tidssynkronisering. Ofte er logikken i slike forsvar basert på en sammenligning av to størrelser. Hvis verdiene avviker med en tilstrekkelig stor verdi, utløses beskyttelsen. Hvis disse verdiene måles med en tidsnøyaktighet på 1 ms, kan du få en stor forskjell der verdiene faktisk er normale hvis de måles med en nøyaktighet på 1 μs.

PTP-versjoner

PTP-protokollen ble opprinnelig beskrevet i 2002 i IEEE 1588-2002-standarden og ble kalt "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems." I 2008 ble den oppdaterte IEEE 1588-2008-standarden utgitt, som beskriver PTP versjon 2. Denne versjonen av protokollen forbedret nøyaktighet og stabilitet, men opprettholdt ikke bakoverkompatibilitet med den første versjonen av protokollen. I 2019 ble også en versjon av IEEE 1588-2019-standarden utgitt, som beskriver PTP v2.1. Denne versjonen legger til mindre forbedringer til PTPv2 og er bakoverkompatibel med PTPv2.

Vi har med andre ord følgende bilde med versjoner:

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 er det nyanser.

Inkompatibilitet mellom PTPv1 og PTPv2 betyr at en PTPv1-aktivert enhet ikke vil kunne synkronisere med en nøyaktig klokke som kjører på PTPv2. De bruker forskjellige meldingsformater for å synkronisere.

Men det er fortsatt mulig å kombinere enheter med PTPv1 og enheter med PTPv2 på samme nettverk. For å oppnå dette lar noen produsenter deg velge protokollversjonen på kantklokkeportene. Det vil si at en grenseklokke kan synkronisere ved hjelp av PTPv2 og fortsatt synkronisere andre klokker koblet til den ved å bruke både PTPv1 og PTPv2.

PTP-enheter. Hva er de og hvordan er de forskjellige?

IEEE 1588v2-standarden beskriver flere typer enheter. Alle er vist i tabellen.

Enhetene kommuniserer med hverandre over et LAN ved hjelp av PTP.

PTP-enheter kalles klokker. Alle klokker tar nøyaktig tid fra stormesterklokken.

Det er 5 typer klokker:

Stormesterklokke

Hovedkilden til nøyaktig tid. Ofte utstyrt med grensesnitt for tilkobling av GPS.

Vanlig klokke

En enkeltportenhet som kan være en master (masterklokke) eller slave (slaveklokke)

Master klokke (master)

De er kilden til den nøyaktige tiden som andre klokker synkroniseres med

Slave klokke

Sluttenhet som er synkronisert fra hovedklokken

Grenseklokke

En enhet med flere porter som kan være en master eller en slave.

Det vil si at disse klokkene kan synkronisere fra den overordnede hovedklokken og synkronisere de underordnede slaveklokkene.

Gjennomsiktig klokke fra ende til ende

En enhet med flere porter som verken er en masterklokke eller en slave. Den overfører PTP-data mellom to klokker.

Ved overføring av data korrigerer den gjennomsiktige klokken alle PTP-meldinger.

Korrigeringen skjer ved å legge til forsinkelsestiden på denne enheten til korreksjonsfeltet i overskriften på den overførte meldingen.

Peer-to-Peer transparent klokke

En enhet med flere porter som verken er en masterklokke eller en slave.
Den overfører PTP-data mellom to klokker.

Ved overføring av data korrigerer den gjennomsiktige klokken alle PTP-meldinger Sync og Follow_Up (mer om dem nedenfor).

Korrigeringen oppnås ved å legge til korreksjonsfeltet til den overførte pakken forsinkelsen på sendeinnretningen og forsinkelsen på dataoverføringskanalen.

Management Node

En enhet som konfigurerer og diagnostiserer andre klokker

Master- og slaveklokker synkroniseres ved hjelp av tidsstempler i PTP-meldinger. Det er to typer meldinger i PTP-protokollen:

• Hendelsesmeldinger er synkroniserte meldinger som involverer generering av et tidsstempel på det tidspunktet meldingen sendes og på det tidspunktet den mottas.
• Generelle meldinger - Disse meldingene krever ikke tidsstempler, men kan inneholde tidsstempler for relaterte meldinger

Hendelsesmeldinger

Generelle meldinger

Synkroniser
Delay_Req
Pdelay_Req
Pdelay_Resp

Kunngjøre
Følge opp
Delay_Resp
Pdelay_Resp_Follow_Up
Administrasjon
Signalering

Alle typer meldinger vil bli diskutert mer detaljert nedenfor.

Grunnleggende synkroniseringsproblemer

Når en synkroniseringspakke sendes over et lokalt nettverk, blir den forsinket ved svitsjen og i datalinken. Enhver svitsj vil gi en forsinkelse på omtrent 10 mikrosekunder, noe som er uakseptabelt for PTPv2. Tross alt må vi oppnå en nøyaktighet på 1 μs på den endelige enheten. (Dette er hvis vi snakker om energi. Andre applikasjoner kan kreve større nøyaktighet.)

IEEE 1588v2 beskriver flere driftsalgoritmer som lar deg registrere tidsforsinkelsen og korrigere den.

Arbeidsalgoritme
Under normal drift opererer protokollen i to faser.

• Fase 1 - etablering av "Master Clock - Slave Clock" hierarkiet.
• Fase 2 - klokkesynkronisering ved hjelp av en ende-til-ende- eller node-til-node-mekanisme.

Fase 1 - Etablering av mester-slave-hierarkiet

Hver port av en vanlig klokke eller kantklokke har et visst antall tilstander (slaveklokke og masterklokke). Standarden beskriver overgangsalgoritmen mellom disse tilstandene. I programmering kalles en slik algoritme en endelig tilstandsmaskin eller tilstandsmaskin (mer detaljer i Wiki).

Denne tilstandsmaskinen bruker Best Master Clock Algorithm (BMCA) for å stille inn masteren når to klokker kobles til.

Denne algoritmen lar klokken overta ansvaret til stormesterklokken når oppstrøms stormesterklokke mister GPS-signal, går offline osv.

Tilstandsoverganger i henhold til BMCA er oppsummert i følgende diagram:


Informasjon om klokken i den andre enden av "ledningen" sendes i en spesiell melding (Annonser melding). Når denne informasjonen er mottatt, kjører tilstandsmaskinalgoritmen og en sammenligning gjøres for å se hvilken klokke som er best. Porten på den beste klokken blir masterklokken.

Et enkelt hierarki er vist i diagrammet nedenfor. Baner 1, 2, 3, 4, 5 kan inneholde en gjennomsiktig klokke, men de deltar ikke i etableringen av Master Clock - Slave Clock hierarkiet.

Fase 2 - Synkroniser vanlige klokker og kantklokker

Umiddelbart etter etablering av "Master Clock - Slave Clock"-hierarkiet, begynner synkroniseringsfasen for vanlige klokker og grenseklokker.

For å synkronisere sender masterklokken en melding som inneholder et tidsstempel til slaveklokkene.

Hovedklokken kan være:

• enkelt trinn;
• to-trinns.

Etttrinns klokker sender én synkroniseringsmelding for å synkronisere.

En to-trinns klokke bruker to meldinger for synkronisering - Sync og Follow_Up.

To mekanismer kan brukes for synkroniseringsfasen:

• Forsinket forespørsel-svar-mekanisme.
• Målemekanisme for peer-forsinkelse.

Først, la oss se på disse mekanismene i det enkleste tilfellet - når gjennomsiktige klokker ikke brukes.

Forsinket forespørsel-svar-mekanisme

Mekanismen involverer to trinn:

1. Måler forsinkelsen i sending av en melding mellom masterklokken og slaveklokken. Utført ved hjelp av en forsinkelsesforespørsel-svar-mekanisme.
2. Korrigering av den nøyaktige tidsforskyvningen utføres.

Latensmåling


t1 – Tidspunkt for sending av synkroniseringsmeldingen med hovedklokken; t2 – Tidspunkt for mottak av synkroniseringsmeldingen av slaveklokken; t3 – Tidspunkt for sending av forsinkelsesforespørselen (Delay_Req) ​​av slaveklokken; t4 – Delay_Req mottakstid av hovedklokken.

Når slaveklokken kjenner tidene t1, t2, t3 og t4, kan den beregne gjennomsnittlig forsinkelse ved overføring av synkroniseringsmeldingen (tmpd). Det beregnes som følger:

Når du sender en Sync and Follow_Up melding, beregnes tidsforsinkelsen fra master til slave - t-ms.

Ved sending av Delay_Req og Delay_Resp meldinger beregnes tidsforsinkelsen fra slaven til masteren - t-sm.

Hvis det oppstår en viss asymmetri mellom disse to verdiene, vises en feil ved å korrigere avviket til det nøyaktige tidspunktet. Feilen er forårsaket av at den beregnede forsinkelsen er gjennomsnittet av t-ms og t-sm forsinkelsene. Hvis forsinkelsene ikke er lik hverandre, vil vi ikke justere tiden nøyaktig.

Korrigering av tidsforskyvning

Når forsinkelsen mellom hovedklokken og slaveklokken er kjent, utfører slaveklokken tidskorrigering.

Slaveklokker bruker Sync-meldingen og en valgfri Follow_Up-melding for å beregne den nøyaktige tidsforskyvningen ved overføring av en pakke fra master- til slaveklokkene. Skiftet beregnes ved hjelp av følgende formel:

Målemekanisme for peer-forsinkelse

Denne mekanismen bruker også to trinn for synkronisering:

1. Enhetene måler tidsforsinkelsen til alle naboer gjennom alle porter. For å gjøre dette bruker de en peer-forsinkelsesmekanisme.
2. Korrigering av nøyaktig tidsforskyvning.

Måling av ventetid mellom enheter som støtter node-til-node-modus

Latensen mellom porter som støtter node-til-node-mekanismen måles ved hjelp av følgende meldinger:

Når port 1 kjenner tidene t1, t2, t3 og t4, kan den beregne gjennomsnittlig forsinkelse (tmld). Det beregnes ved hjelp av følgende formel:

Porten bruker deretter denne verdien når den beregner justeringsfeltet for hver synkroniseringsmelding eller valgfri oppfølgingsmelding som går gjennom enheten.

Den totale forsinkelsen vil være lik summen av forsinkelsen under overføringen gjennom denne enheten, den gjennomsnittlige forsinkelsen under overføringen gjennom datakanalen og forsinkelsen som allerede finnes i denne meldingen, aktivert på oppstrømsenheter.

Meldinger Pdelay_Req, Pdelay_Resp og valgfri Pdelay_Resp_Follow_Up lar deg få forsinkelsen fra master til slave og fra slave til master (sirkulær).

Enhver asymmetri mellom disse to verdiene vil introdusere en korrigeringsfeil for tidsforskyvning.

Justering av den nøyaktige tidsforskyvningen

Slaveklokker bruker en synkroniseringsmelding og en valgfri oppfølgingsmelding for å beregne den nøyaktige tidsforskyvningen ved overføring av en pakke fra master- til slaveklokkene. Skiftet beregnes ved hjelp av følgende formel:

Fordeler justering av peer-to-peer-mekanismen - tidsforsinkelsen for hver Sync- eller Follow_Up-melding beregnes etter hvert som den overføres i nettverket. Følgelig vil endring av overføringsveien ikke på noen måte påvirke nøyaktigheten av justeringen.

Når du bruker denne mekanismen, krever ikke tidssynkronisering å beregne tidsforsinkelsen langs banen som synkroniseringspakken går gjennom, slik det gjøres i den grunnleggende sentralen. De. Delay_Req og Delay_Resp meldinger sendes ikke. I denne metoden summeres forsinkelsen mellom master- og slaveklokkene ganske enkelt i justeringsfeltet for hver Sync- eller Follow_Up-melding.

En annen fordel er at hovedklokken slipper behovet for å behandle Delay_Req-meldinger.

Driftsmoduser for gjennomsiktige klokker

Følgelig var dette enkle eksempler. Anta nå at brytere vises på synkroniseringsbanen.

Hvis du bruker brytere uten PTPv2-støtte, vil synkroniseringspakken bli forsinket på switchen med omtrent 10 μs.

Brytere som støtter PTPv2 kalles Transparente klokker i IEEE 1588v2-terminologi. Transparente klokker synkroniseres ikke fra hovedklokken og deltar ikke i "Master Clock - Slave Clock" hierarkiet, men når de sender synkroniseringsmeldinger, husker de hvor lenge meldingen ble forsinket av dem. Dette lar deg justere tidsforsinkelsen.

Gjennomsiktige klokker kan fungere i to moduser:

• Ende til ende.
• Peer to peer.

End-to-end (E2E)

Den gjennomsiktige E2E-klokken sender synkroniseringsmeldinger og tilhørende oppfølgingsmeldinger på alle porter. Selv de som er blokkert av noen protokoller (for eksempel RSTP).

Switchen husker tidsstemplet når en Sync-pakke (Follow_Up) ble mottatt på porten og når den ble sendt fra porten. Basert på disse to tidsstemplene, beregnes tiden det tar for bryteren å behandle meldingen. I standarden kalles denne tiden oppholdstid.

Behandlingstiden legges til i korreksjonsfeltet i meldingen Sync (ett-trinns klokke) eller Follow_Up (to-trinns klokke).

Den transparente E2E-klokken måler behandlingstiden for Sync- og Delay_Req-meldinger som går gjennom bryteren. Men det er viktig å forstå at tidsforsinkelsen mellom masterklokken og slaveklokken beregnes ved hjelp av forsinkelsesforespørsel-svar-mekanismen. Hvis masterklokken endres eller banen fra masterklokken til slaveklokken endres, måles forsinkelsen på nytt. Dette øker overgangstiden ved nettverksendringer.

Den transparente P2P-klokken, i tillegg til å måle tiden det tar for en svitsj å behandle en melding, måler forsinkelsen på datalinken til nærmeste nabo ved hjelp av en nabolatensmekanisme.

Latency måles på hver lenke i begge retninger, inkludert lenker som er blokkert av en eller annen protokoll (som RSTP). Dette lar deg umiddelbart beregne den nye forsinkelsen i synkroniseringsbanen hvis stormesterklokken eller nettverkstopologien endres.

Behandlingstid for meldinger etter brytere og ventetid akkumuleres når du sender Sync- eller Follow_Up-meldinger.

Typer PTPv2-støtte med brytere

Brytere kan støtte PTPv2:

• programmatisk;
• maskinvare.

Når PTPv2-protokollen implementeres i programvare, ber bryteren om et tidsstempel fra fastvaren. Problemet er at fastvaren fungerer syklisk, og du må vente til den er ferdig med gjeldende syklus, tar forespørselen om behandling og utsteder et tidsstempel etter neste syklus. Dette vil også ta tid, og vi vil få en forsinkelse, om enn ikke så betydelig som uten programvarestøtte for PTPv2.

Bare maskinvarestøtte for PTPv2 lar deg opprettholde den nødvendige nøyaktigheten. I dette tilfellet utstedes tidsstemplet av en spesiell ASIC, som er installert på porten.

Meldingsformat

Alle PTP-meldinger består av følgende felt:

• Overskrift – 34 byte.
• Brødtekst – størrelsen avhenger av typen melding.
• Suffiks er valgfritt.

Header

Overskriftsfeltet er det samme for alle PTP-meldinger. Størrelsen er 34 byte.

Overskriftsfeltformat:

meldingstype – inneholder typen melding som sendes, for eksempel Sync, Delay_Req, PDelay_Req, etc.

meldingslengde – inneholder full størrelse på PTP-meldingen, inkludert topptekst, brødtekst og suffiks (men unntatt utfyllingsbytes).

domenenummer – bestemmer hvilket PTP-domene meldingen tilhører.

Domenenavn - Dette er flere forskjellige klokker samlet i en logisk gruppe og synkronisert fra en hovedklokke, men ikke nødvendigvis synkronisert med klokker som tilhører et annet domene.

flagg – Dette feltet inneholder ulike flagg for å identifisere statusen til meldingen.

korreksjonsfelt – inneholder forsinkelsestiden i nanosekunder. Forsinkelsestiden inkluderer forsinkelsen ved sending gjennom den transparente klokken, samt forsinkelsen ved overføring gjennom kanalen ved bruk av node-til-node-modus.

sourcePortIdentity – dette feltet inneholder informasjon om hvilken port denne meldingen opprinnelig ble sendt fra.

sekvensID – inneholder et identifikasjonsnummer for individuelle meldinger.

kontrollfelt – artefaktfelt =) Det gjenstår fra den første versjonen av standarden og inneholder informasjon om typen av denne meldingen. I hovedsak det samme som messageType, men med færre alternativer.

logMessageInterval – dette feltet bestemmes av meldingstypen.

Body

Som diskutert ovenfor, er det flere typer meldinger. Disse typene er beskrevet nedenfor:

Kunngjøringsmelding
Meldingen brukes til å "fortelle" andre klokker innenfor samme domene om parameterne. Denne meldingen lar deg sette opp et Master Clock - Slave Clock hierarki.


Synkroniser melding
Synkroniseringsmeldingen sendes av hovedklokken og inneholder tiden for hovedklokken på tidspunktet synkroniseringsmeldingen ble generert. Hvis hovedklokken er to-trinns, vil tidsstemplet i Sync-meldingen bli satt til 0, og gjeldende tidsstempel vil bli sendt i den tilhørende Follow_Up-meldingen. Synkroniseringsmeldingen brukes for begge mekanismene for måling av ventetid.

Meldingen overføres ved hjelp av Multicast. Eventuelt kan du bruke Unicast.

Delay_Req melding

Formatet på Delay_Req-meldingen er identisk med Sync-meldingen. Slaveklokken sender Delay_Req. Den inneholder tiden Delay_Req ble sendt av slaveklokken. Denne meldingen brukes kun for forsinkelsesforespørsel-svar-mekanismen.

Meldingen overføres ved hjelp av Multicast. Eventuelt kan du bruke Unicast.

Oppfølgingsmelding

Oppfølgingsmeldingen sendes valgfritt av hovedklokken og inneholder tidspunktet for sending Synkroniser meldinger herre. Bare to-trinns masterklokker sender oppfølgingsmeldingen.

Oppfølgingsmeldingen brukes for begge mekanismene for måling av ventetid.

Meldingen overføres ved hjelp av Multicast. Eventuelt kan du bruke Unicast.

Delay_Resp melding

Delay_Resp-meldingen sendes av hovedklokken. Den inneholder tiden da Delay_Req ble mottatt av hovedklokken. Denne meldingen brukes kun for forsinkelsesforespørsel-svar-mekanismen.

Meldingen overføres ved hjelp av Multicast. Eventuelt kan du bruke Unicast.

Pdelay_Req melding

Pdelay_Req-meldingen sendes av en enhet som ber om en forsinkelse. Den inneholder tiden meldingen ble sendt fra porten til denne enheten. Pdelay_Req brukes bare for målemekanismen for naboforsinkelse.

Pdelay_Resp melding

Pdelay_Resp-meldingen sendes av en enhet som har mottatt en forsinkelsesforespørsel. Den inneholder tiden Pdelay_Req-meldingen ble mottatt av denne enheten. Pdelay_Resp-meldingen brukes bare for målemekanismen for naboforsinkelse.

Melding Pdelay_Resp_Follow_Up

Pdelay_Resp_Follow_Up-meldingen sendes valgfritt av enheten som har mottatt forsinkelsesforespørselen. Den inneholder tiden Pdelay_Req-meldingen ble mottatt av denne enheten. Pdelay_Resp_Follow_Up-meldingen sendes kun av to-trinns masterklokker.

Denne meldingen kan også brukes for utførelsestid i stedet for et tidsstempel. Utførelsestid er tiden fra øyeblikket Pdelay-Req mottas til Pdelay_Resp sendes.

Pdelay_Resp_Follow_Up brukes kun for målemekanismen for naboforsinkelse.

Administrasjonsmeldinger

PTP-kontrollmeldinger kreves for å overføre informasjon mellom en eller flere klokker og kontrollnoden.

Overfør til LV

En PTP-melding kan overføres på to nivåer:

• Nettverk – som en del av IP-data.
• Kanal – som en del av en Ethernet-ramme.

PTP-meldingsoverføring over UDP over IP over Ethernet

PTP over UDP over Ethernet

Profiler

PTP har ganske mange fleksible parametere som må konfigureres. For eksempel:

• BMCA-alternativer.
• Mekanisme for måling av latens.
• Intervaller og startverdier for alle konfigurerbare parametere osv.

Og til tross for at vi tidligere sa at PTPv2-enheter er kompatible med hverandre, er dette ikke sant. Enheter må ha de samme innstillingene for å kunne kommunisere.

Derfor finnes det såkalte PTPv2-profiler. Profiler er grupper med konfigurerte innstillinger og definerte protokollbegrensninger slik at tidssynkronisering kan implementeres for en spesifikk applikasjon.

Selve IEEE 1588v2-standarden beskriver bare én profil - "Standardprofil". Alle andre profiler er opprettet og beskrevet av ulike organisasjoner og foreninger.

For eksempel ble Power Profile, eller PTPv2 Power Profile, opprettet av Power Systems Relaying Committee og substation Committee i IEEE Power and Energy Society. Selve profilen heter IEEE C37.238-2011.

Profilen beskriver at PTP kan overføres:

• Kun via L2-nettverk (dvs. Ethernet, HSR, PRP, ikke-IP).
• Meldinger overføres kun ved multicast-kringkasting.
• Peer-forsinkelsesmålingsmekanisme brukes som en forsinkelsesmålemekanisme.

Standarddomene er 0, anbefalt domene er 93.

Designfilosofien til C37.238-2011 var å redusere antall valgfrie funksjoner og bare beholde de nødvendige funksjonene for pålitelig interaksjon mellom enheter og økt systemstabilitet.

Frekvensen for meldingsoverføring bestemmes også:

Faktisk er bare én parameter tilgjengelig for valg - typen masterklokke (en-trinns eller to-trinns).

Nøyaktigheten bør ikke være mer enn 1 μs. Med andre ord kan én synkroniseringsbane inneholde maksimalt 15 transparente klokker eller tre grenseklokker.

Kilde: www.habr.com