Implementatiedetails van het PTPv2-tijdsynchronisatieprotocol

Introductie

Het concept van het bouwen van een “digitaal substation” in de elektriciteitssector vereist synchronisatie met een nauwkeurigheid van 1 μs. Financiële transacties vereisen ook nauwkeurigheid op microseconden. In deze toepassingen is de NTP-tijdnauwkeurigheid niet langer voldoende.

Het PTPv2-synchronisatieprotocol, beschreven door de IEEE 1588v2-standaard, maakt een synchronisatienauwkeurigheid van enkele tientallen nanoseconden mogelijk. Met PTPv2 kunt u synchronisatiepakketten verzenden via L2- en L3-netwerken.

De belangrijkste gebieden waar PTPv2 wordt gebruikt zijn:

• energie;
• controle- en meetapparatuur;
• militair-industrieel complex;
• telecommunicatie;
• financiële sector.

In dit bericht wordt uitgelegd hoe het PTPv2-synchronisatieprotocol werkt.

Wij hebben meer ervaring in de industrie en zien dit protocol vaak terug in energietoepassingen. Daarom zullen we de beoordeling met de nodige voorzichtigheid uitvoeren voor energie.

Waarom is het nodig?

Op dit moment bevatten STO 34.01-21-004-2019 van PJSC Rosseti en STO 56947007-29.240.10.302-2020 van PJSC FGC UES vereisten voor het organiseren van een procesbus met tijdsynchronisatie via PTPv2.

Dit komt door het feit dat relaisbeschermingsterminals en meetapparatuur zijn aangesloten op de procesbus, die momentane stroom- en spanningswaarden via de procesbus verzenden, met behulp van zogenaamde SV-streams (multicast-streams).

Relaisbeschermingsterminals gebruiken deze waarden om baaibescherming te implementeren. Als de nauwkeurigheid van tijdmetingen klein is, kunnen sommige beveiligingen onjuist werken.

Verdedigingen van absolute selectiviteit kunnen bijvoorbeeld het slachtoffer worden van ‘zwakke’ tijdsynchronisatie. Vaak is de logica van dergelijke verdedigingen gebaseerd op een vergelijking van twee grootheden. Als de waarden een voldoende grote waarde afwijken, wordt de beveiliging geactiveerd. Als deze waarden worden gemeten met een tijdsnauwkeurigheid van 1 ms, dan kun je een groot verschil krijgen waarbij de waarden eigenlijk normaal zijn als ze worden gemeten met een nauwkeurigheid van 1 μs.

PTP-versies

Het PTP-protocol werd oorspronkelijk in 2002 beschreven in de IEEE 1588-2002-standaard en heette "Standaard voor een precisiekloksynchronisatieprotocol voor netwerkmeet- en regelsystemen." In 2008 werd de bijgewerkte IEEE 1588-2008-standaard uitgebracht, die PTP-versie 2 beschrijft. Deze versie van het protocol verbeterde de nauwkeurigheid en stabiliteit, maar behield geen achterwaartse compatibiliteit met de eerste versie van het protocol. Ook werd in 2019 een versie van de IEEE 1588-2019-standaard uitgebracht, waarin PTP v2.1 wordt beschreven. Deze versie voegt kleine verbeteringen toe aan PTPv2 en is achterwaarts compatibel met PTPv2.

Met andere woorden, we hebben de volgende afbeelding met versies:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

-
inconsequent

inconsequent

PTPv2 (IEEE 1588-2008)

inconsequent

-
verenigbaar

PTPv2.1 (IEEE 1588-2019)

inconsequent

verenigbaar

-

Maar zoals altijd zijn er nuances.

Incompatibiliteit tussen PTPv1 en PTPv2 betekent dat een PTPv1-apparaat niet in staat zal zijn om te synchroniseren met een nauwkeurige klok die op PTPv2 draait. Ze gebruiken verschillende berichtformaten om te synchroniseren.

Maar het is nog steeds mogelijk om apparaten met PTPv1 en apparaten met PTPv2 op hetzelfde netwerk te combineren. Om dit te bereiken staan ​​sommige fabrikanten toe dat u de protocolversie op de edge-klokpoorten selecteert. Dat wil zeggen dat een grensklok kan synchroniseren met behulp van PTPv2 en nog steeds andere klokken kan synchroniseren die erop zijn aangesloten met behulp van zowel PTPv1 als PTPv2.

PTP-apparaten. Wat zijn ze en hoe verschillen ze?

De IEEE 1588v2-standaard beschrijft verschillende soorten apparaten. Ze worden allemaal weergegeven in de tabel.

De apparaten communiceren met elkaar via een LAN met behulp van PTP.

PTP-apparaten worden klokken genoemd. Alle horloges geven de exacte tijd weer van het grootmeesterhorloge.

Er zijn 5 soorten horloges:

Grootmeester klok

De belangrijkste bron van nauwkeurige tijd. Vaak voorzien van een interface voor het aansluiten van GPS.

Gewone klok

Een apparaat met één poort dat een master (masterklok) of slave (slaveklok) kan zijn

Hoofdklok (master)

Ze zijn de bron van de exacte tijd waarmee andere klokken worden gesynchroniseerd

Slavenklok

Eindapparaat dat wordt gesynchroniseerd vanaf de hoofdklok

Grensklok

Een apparaat met meerdere poorten die master of slave kunnen zijn.

Dat wil zeggen dat deze klokken kunnen synchroniseren vanaf de superieure hoofdklok en de inferieure slaafklokken kunnen synchroniseren.

End-to-end transparante klok

Een apparaat met meerdere poorten dat noch een masterklok, noch een slave is. Het verzendt PTP-gegevens tussen twee horloges.

Bij het verzenden van gegevens corrigeert de transparante klok alle PTP-berichten.

De correctie vindt plaats door de vertragingstijd op dit apparaat toe te voegen aan het correctieveld in de header van het verzonden bericht.

Peer-to-peer transparante klok

Een apparaat met meerdere poorten dat noch een masterklok, noch een slave is.
Het verzendt PTP-gegevens tussen twee horloges.

Bij het verzenden van gegevens corrigeert de transparante klok alle PTP-berichten Sync en Follow_Up (meer daarover hieronder).

De correctie wordt bereikt door aan het correctieveld van het verzonden pakket de vertraging op het verzendende apparaat en de vertraging op het datatransmissiekanaal toe te voegen.

Beheer knooppunt

Een apparaat dat andere horloges configureert en diagnosticeert

Master- en slave-klokken worden gesynchroniseerd met behulp van tijdstempels in PTP-berichten. Er zijn twee soorten berichten in het PTP-protocol:

• Gebeurtenisberichten zijn gesynchroniseerde berichten waarbij een tijdstempel wordt gegenereerd op het moment dat het bericht wordt verzonden en op het moment dat het wordt ontvangen.
• Algemene berichten - Deze berichten vereisen geen tijdstempels, maar kunnen tijdstempels bevatten voor gerelateerde berichten

Gebeurtenisberichten

Algemene berichten

Synchroniseren
Vertraging_Verzoek
Pdelay_Req
Pdelay_Resp

aankondigen
Opvolgen
Vertraging_Resp
Pdelay_Resp_Follow_Up
Management
signalering

Hieronder worden alle soorten berichten nader besproken.

Basissynchronisatieproblemen

Wanneer een synchronisatiepakket over een lokaal netwerk wordt verzonden, wordt het vertraagd bij de switch en in de datalink. Elke schakelaar produceert een vertraging van ongeveer 10 microseconden, wat onaanvaardbaar is voor PTPv2. Op het uiteindelijke apparaat moeten we immers een nauwkeurigheid van 1 μs bereiken. (Dit is als we het over energie hebben. Andere toepassingen vereisen mogelijk een grotere nauwkeurigheid.)

IEEE 1588v2 beschrijft verschillende bedieningsalgoritmen waarmee u de tijdsvertraging kunt registreren en corrigeren.

Algoritme van het werk
Tijdens normaal gebruik werkt het protocol in twee fasen.

• Fase 1 - het opzetten van de hiërarchie “Master Clock – Slave Clock”.
• Fase 2 - kloksynchronisatie met behulp van een end-to-end- of peer-to-peer-mechanisme.

Fase 1 – Het tot stand brengen van de meester-slaafhiërarchie

Elke poort van een reguliere of edge-klok heeft een bepaald aantal toestanden (slaveklok en masterklok). De standaard beschrijft het overgangsalgoritme tussen deze toestanden. Bij het programmeren wordt zo'n algoritme een eindige toestandsmachine of toestandsmachine genoemd (meer details in Wiki).

Deze toestandsmachine gebruikt het Best Master Clock Algorithm (BMCA) om de master in te stellen bij het verbinden van twee klokken.

Met dit algoritme kan het horloge de verantwoordelijkheden van het grootmeesterhorloge overnemen wanneer het stroomopwaartse grootmeesterhorloge het GPS-signaal verliest, offline gaat, enz.

Toestandsovergangen volgens de BMCA zijn samengevat in het volgende diagram:


Informatie over het horloge aan het andere uiteinde van de “draad” wordt verzonden in een speciaal bericht (aankondigingsbericht). Zodra deze informatie is ontvangen, wordt het algoritme van de toestandsmachine uitgevoerd en wordt er een vergelijking gemaakt om te zien welke klok beter is. De poort op het beste horloge wordt het hoofdhorloge.

In het onderstaande diagram wordt een eenvoudige hiërarchie weergegeven. Paden 1, 2, 3, 4, 5 kunnen een transparante klok bevatten, maar nemen niet deel aan het vaststellen van de hiërarchie Master Clock - Slave Clock.

Fase 2 - Synchroniseer reguliere en edge-klokken

Onmiddellijk na het vaststellen van de hiërarchie “Master Clock – Slave Clock” begint de synchronisatiefase van reguliere klokken en grensklokken.

Om te synchroniseren stuurt de masterklok een bericht met een tijdstempel naar de slaveklokken.

De hoofdklok kan zijn:

• enkele fase;
• tweetraps.

Eentrapsklokken sturen één synchronisatiebericht om te synchroniseren.

Een tweetrapsklok gebruikt twee berichten voor synchronisatie: Sync en Follow_Up.

Voor de synchronisatiefase kunnen twee mechanismen worden gebruikt:

• Vertragingsverzoek-antwoordmechanisme.
• Mechanisme voor het meten van peer-vertraging.

Laten we eerst deze mechanismen in het eenvoudigste geval bekijken: wanneer transparante horloges niet worden gebruikt.

Vertragingsverzoek-antwoordmechanisme

Het mechanisme omvat twee stappen:

1. Het meten van de vertraging bij het verzenden van een bericht tussen de masterklok en de slaveklok. Uitgevoerd met behulp van een vertragingsverzoek-responsmechanisme.
2. Correctie van de exacte tijdverschuiving wordt uitgevoerd.

Latentiemeting


t1 – Tijdstip waarop het synchronisatiebericht door de hoofdklok wordt verzonden; t2 – Tijdstip van ontvangst van het Sync-bericht door de slaafklok; t3 – Tijdstip van verzending van het vertragingsverzoek (Delay_Req) ​​door de slaafklok; t4 – Delay_Req ontvangsttijd door de hoofdklok.

Wanneer de slaafklok de tijden t1, t2, t3 en t4 kent, kan hij de gemiddelde vertraging berekenen bij het verzenden van het synchronisatiebericht (tmpd). Het wordt als volgt berekend:

Bij het verzenden van een Sync- en Follow_Up-bericht wordt de tijdsvertraging van de master naar de slave berekend - t-ms.

Bij het verzenden van Delay_Req- en Delay_Resp-berichten wordt de tijdsvertraging van de slave naar de master berekend - t-sm.

Als er enige asymmetrie optreedt tussen deze twee waarden, verschijnt er een fout bij het corrigeren van de afwijking van de exacte tijd. De fout wordt veroorzaakt door het feit dat de berekende vertraging het gemiddelde is van de t-ms- en t-sm-vertragingen. Zijn de vertragingen niet gelijk aan elkaar, dan passen wij de tijd niet nauwkeurig aan.

Correctie van tijdverschuiving

Zodra de vertraging tussen de hoofdklok en de slaafklok bekend is, voert de slaafklok tijdcorrectie uit.

Slaveklokken gebruiken het Sync-bericht en een optioneel Follow_Up-bericht om de exacte tijdsverschuiving te berekenen bij het verzenden van een pakket van de master naar de slaveklokken. De verschuiving wordt berekend met behulp van de volgende formule:

Mechanisme voor het meten van peer-vertraging

Dit mechanisme gebruikt ook twee stappen voor synchronisatie:

1. De apparaten meten de tijdsvertraging naar alle buren via alle poorten. Om dit te doen gebruiken ze een peer delay-mechanisme.
2. Correctie van de exacte tijdverschuiving.

Het meten van de latentie tussen apparaten die de peer-to-peer-modus ondersteunen

De latentie tussen poorten die het peer-to-peer-mechanisme ondersteunen, wordt gemeten met behulp van de volgende berichten:

Wanneer poort 1 de tijden t1, t2, t3 en t4 kent, kan deze de gemiddelde vertraging (tmld) berekenen. Het wordt berekend met behulp van de volgende formule:

De poort gebruikt deze waarde vervolgens bij het berekenen van het aanpassingsveld voor elk synchronisatiebericht of optioneel vervolgbericht dat door het apparaat gaat.

De totale vertraging zal gelijk zijn aan de som van de vertraging tijdens verzending via dit apparaat, de gemiddelde vertraging tijdens verzending via het datakanaal en de vertraging die al in dit bericht zit, mogelijk gemaakt op upstream-apparaten.

Met de berichten Pdelay_Req, Pdelay_Resp en optioneel Pdelay_Resp_Follow_Up kunt u de vertraging van master naar slave en van slave naar master krijgen (circulair).

Elke asymmetrie tussen deze twee waarden zal een correctiefout in de tijdsverschuiving introduceren.

De exacte tijdverschuiving aanpassen

Slaveklokken gebruiken een Sync-bericht en een optioneel Follow_Up-bericht om de exacte tijdsverschuiving te berekenen bij het verzenden van een pakket van de master naar de slaveklokken. De verschuiving wordt berekend met behulp van de volgende formule:

Voordelen aanpassing van het peer-to-peer-mechanisme - de tijdsvertraging van elk Sync- of Follow_Up-bericht wordt berekend terwijl het in het netwerk wordt verzonden. Bijgevolg zal het veranderen van het transmissiepad op geen enkele manier de nauwkeurigheid van de aanpassing beïnvloeden.

Wanneer dit mechanisme wordt gebruikt, vereist tijdsynchronisatie niet het berekenen van de tijdvertraging langs het pad dat door het synchronisatiepakket wordt doorlopen, zoals gebeurt bij de basisuitwisseling. Die. Delay_Req- en Delay_Resp-berichten worden niet verzonden. Bij deze methode wordt de vertraging tussen de master- en slave-klok eenvoudigweg opgeteld in het aanpassingsveld van elk Sync- of Follow_Up-bericht.

Een ander voordeel is dat de hoofdklok niet langer Delay_Req-berichten hoeft te verwerken.

Bedrijfsmodi van transparante klokken

Het waren dus eenvoudige voorbeelden. Stel nu dat er schakelaars verschijnen op het synchronisatiepad.

Als u switches zonder PTPv2-ondersteuning gebruikt, wordt het synchronisatiepakket op de switch met ongeveer 10 μs vertraagd.

Switches die PTPv2 ondersteunen worden in de IEEE 1588v2-terminologie transparante klokken genoemd. Transparante klokken worden niet gesynchroniseerd vanaf de masterklok en nemen niet deel aan de hiërarchie “Master Clock – Slave Clock”, maar onthouden bij het verzenden van synchronisatieberichten hoe lang het bericht door hen is vertraagd. Hiermee kunt u de tijdsvertraging aanpassen.

Transparante klokken kunnen in twee modi werken:

• Eind tot eind.
• Peer naar peer.

End-to-end (E2E)

De transparante E2E-klok zendt Sync-berichten en bijbehorende Follow_Up-berichten uit op alle poorten. Zelfs degenen die worden geblokkeerd door sommige protocollen (bijvoorbeeld RSTP).

De switch onthoudt de tijdstempel wanneer een Sync-pakket (Follow_Up) op de poort werd ontvangen en wanneer het vanaf de poort werd verzonden. Op basis van deze twee tijdstempels wordt de tijd berekend die de switch nodig heeft om het bericht te verwerken. In de norm wordt deze tijd verblijftijd genoemd.

De verwerkingstijd wordt toegevoegd aan het veld correctionField van het bericht Sync (klok in één stap) of Follow_Up (klok in twee stappen).

De transparante E2E-klok meet de verwerkingstijd voor Sync- en Delay_Req-berichten die door de switch gaan. Maar het is belangrijk om te begrijpen dat de tijdsvertraging tussen de hoofdklok en de slaafklok wordt berekend met behulp van het vertragingsverzoek-antwoordmechanisme. Als de masterklok verandert of het pad van de masterklok naar de slaveklok verandert, wordt de vertraging opnieuw gemeten. Dit verlengt de overgangstijd bij netwerkwijzigingen.

De transparante P2P-klok meet niet alleen de tijd die een switch nodig heeft om een ​​bericht te verwerken, maar meet ook de vertraging op de datalink naar de dichtstbijzijnde buur met behulp van een latentiemechanisme van de buurman.

De latentie wordt gemeten op elke link in beide richtingen, inclusief links die worden geblokkeerd door een bepaald protocol (zoals RSTP). Hierdoor kunt u onmiddellijk de nieuwe vertraging in het synchronisatiepad berekenen als de grootmeesterklok of de netwerktopologie verandert.

Berichtverwerkingstijd door schakelaars en latentie worden opgeteld bij het verzenden van Sync- of Follow_Up-berichten.

Soorten PTPv2-ondersteuning door switches

Switches kunnen PTPv2 ondersteunen:

• programmatisch;
• hardware.

Bij implementatie van het PTPv2-protocol in software vraagt ​​de switch om een ​​tijdstempel van de firmware. Het probleem is dat de firmware cyclisch werkt en dat je moet wachten tot deze de huidige cyclus heeft voltooid, het verzoek voor verwerking heeft aangenomen en na de volgende cyclus een tijdstempel afgeeft. Dit zal ook tijd vergen, en we zullen een vertraging krijgen, hoewel niet zo groot als zonder softwareondersteuning voor PTPv2.

Alleen hardware-ondersteuning voor PTPv2 zorgt ervoor dat u de vereiste nauwkeurigheid kunt behouden. In dit geval wordt de tijdstempel uitgegeven door een speciale ASIC, die op de poort is geïnstalleerd.

Berichtformaat

Alle PTP-berichten bestaan ​​uit de volgende velden:

• Koptekst – 34 bytes.
• Body – grootte is afhankelijk van het type bericht.
• Achtervoegsel is optioneel.

Voorvoegsel

Het veld Koptekst is hetzelfde voor alle PTP-berichten. De grootte is 34 bytes.

Formaat kopveld:

berichtType – bevat het type bericht dat wordt verzonden, bijvoorbeeld Sync, Delay_Req, PDelay_Req, enz.

berichtLengte – bevat de volledige grootte van het PTP-bericht, inclusief koptekst, hoofdtekst en achtervoegsel (maar exclusief opvulbytes).

domeinNummer – bepaalt tot welk PTP-domein het bericht behoort.

domein - dit zijn verschillende klokken verzameld in één logische groep en gesynchroniseerd vanaf één hoofdklok, maar niet noodzakelijkerwijs gesynchroniseerd met klokken die tot een ander domein behoren.

vlaggen – Dit veld bevat verschillende vlaggen om de status van het bericht te identificeren.

correctieVeld – bevat de vertragingstijd in nanoseconden. De vertragingstijd omvat de vertraging bij het verzenden via de transparante klok, evenals de vertraging bij het verzenden via het kanaal bij gebruik van de peer-to-peer-modus.

bronPortIdentity – dit veld bevat informatie over vanaf welke poort dit bericht oorspronkelijk is verzonden.

sequentie-ID – bevat een identificatienummer voor individuele berichten.

controleVeld – artefactveld =) Het komt uit de eerste versie van de standaard en bevat informatie over het type van dit bericht. In wezen hetzelfde als messageType, maar met minder opties.

logBerichtInterval – dit veld wordt bepaald door het berichttype.

Lichaam

Zoals hierboven besproken, zijn er verschillende soorten berichten. Deze typen worden hieronder beschreven:

Aankondiging bericht
Het Announce-bericht wordt gebruikt om andere klokken binnen hetzelfde domein te “vertellen” over de parameters ervan. Met dit bericht kunt u een Master Clock - Slave Clock-hiërarchie instellen.


Berichtsynchronisatie
Het Sync-bericht wordt verzonden door de hoofdklok en bevat de tijd van de hoofdklok op het moment dat het Sync-bericht werd gegenereerd. Als de hoofdklok tweetraps is, wordt de tijdstempel in het Sync-bericht ingesteld op 0 en wordt de huidige tijdstempel verzonden in het bijbehorende Follow_Up-bericht. Het synchronisatiebericht wordt gebruikt voor beide latentiemeetmechanismen.

Het bericht wordt verzonden met behulp van Multicast. Optioneel kunt u Unicast gebruiken.

Delay_Req-bericht

Het formaat van het Delay_Req-bericht is identiek aan het Sync-bericht. De slaafklok verzendt Delay_Req. Het bevat de tijd waarop het Delay_Req door de slaafklok is verzonden. Dit bericht wordt alleen gebruikt voor het vertragingsverzoek-antwoordmechanisme.

Het bericht wordt verzonden met behulp van Multicast. Optioneel kunt u Unicast gebruiken.

Berichtopvolging

Het Follow_Up-bericht wordt optioneel verzonden door de hoofdklok en bevat het tijdstip van verzending Synchroniseer berichten meester. Alleen tweetraps hoofdklokken verzenden het Follow_Up-bericht.

Het Follow_Up-bericht wordt gebruikt voor beide mechanismen voor latentiemeting.

Het bericht wordt verzonden met behulp van Multicast. Optioneel kunt u Unicast gebruiken.

Delay_Resp-bericht

Het Delay_Resp-bericht wordt verzonden door de hoofdklok. Het bevat het tijdstip waarop de Delay_Req werd ontvangen door de hoofdklok. Dit bericht wordt alleen gebruikt voor het vertragingsverzoek-antwoordmechanisme.

Het bericht wordt verzonden met behulp van Multicast. Optioneel kunt u Unicast gebruiken.

Pdelay_Req-bericht

Het Pdelay_Req-bericht wordt verzonden door een apparaat dat om vertraging vraagt. Het bevat het tijdstip waarop het bericht is verzonden vanaf de poort van dit apparaat. Pdelay_Req wordt alleen gebruikt voor het meetmechanisme voor de buurvertraging.

Pdelay_Resp-bericht

Het Pdelay_Resp-bericht wordt verzonden door een apparaat dat een vertragingsverzoek heeft ontvangen. Het bevat het tijdstip waarop het Pdelay_Req-bericht door dit apparaat is ontvangen. Het Pdelay_Resp-bericht wordt alleen gebruikt voor het meetmechanisme voor de buurvertraging.

Bericht Pdelay_Resp_Follow_Up

Het Pdelay_Resp_Follow_Up-bericht wordt optioneel verzonden door het apparaat dat het vertragingsverzoek heeft ontvangen. Het bevat het tijdstip waarop het Pdelay_Req-bericht door dit apparaat is ontvangen. Het Pdelay_Resp_Follow_Up-bericht wordt alleen verzonden door tweetraps hoofdklokken.

Dit bericht kan ook worden gebruikt voor de uitvoeringstijd in plaats van een tijdstempel. De uitvoeringstijd is de tijd vanaf het moment dat Pdelay-Req wordt ontvangen totdat Pdelay_Resp wordt verzonden.

Pdelay_Resp_Follow_Up wordt alleen gebruikt voor het meetmechanisme voor de buurvertraging.

Beheerberichten

PTP-besturingsberichten zijn vereist om informatie over te dragen tussen een of meer klokken en het besturingsknooppunt.

Overstappen naar LV

Een PTP-bericht kan op twee niveaus worden verzonden:

• Netwerk – als onderdeel van IP-gegevens.
• Kanaal – als onderdeel van een Ethernet-frame.

PTP-berichtoverdracht via UDP over IP via Ethernet

PTP via UDP via Ethernet

офили

PTP heeft behoorlijk wat flexibele parameters die moeten worden geconfigureerd. Bijvoorbeeld:

• BMCA-opties.
• Mechanisme voor latentiemeting.
• Intervallen en initiële waarden van alle configureerbare parameters, enz.

En ondanks het feit dat we eerder zeiden dat PTPv2-apparaten compatibel zijn met elkaar, is dit niet waar. Apparaten moeten dezelfde instellingen hebben om te kunnen communiceren.

Daarom zijn er zogenaamde PTPv2-profielen. Profielen zijn groepen geconfigureerde instellingen en gedefinieerde protocolbeperkingen, zodat tijdsynchronisatie voor een specifieke toepassing kan worden geïmplementeerd.

De IEEE 1588v2-standaard zelf beschrijft slechts één profiel: “Standaardprofiel”. Alle overige profielen worden door diverse organisaties en verenigingen aangemaakt en beschreven.

Het Power Profile, of PTPv2 Power Profile, is bijvoorbeeld gemaakt door het Power Systems Relaying Committee en het Substation Committee van de IEEE Power and Energy Society. Het profiel zelf heet IEEE C37.238-2011.

Het profiel beschrijft dat PTP kan worden overgedragen:

• Alleen via L2-netwerken (dwz Ethernet, HSR, PRP, niet-IP).
• Berichten worden alleen verzonden via Multicast-uitzending.
• Peer-vertragingsmeetmechanisme wordt gebruikt als vertragingsmeetmechanisme.

Standaarddomein is 0, aanbevolen domein is 93.

De ontwerpfilosofie van C37.238-2011 was om het aantal optionele functies te verminderen en alleen de noodzakelijke functies te behouden voor betrouwbare interactie tussen apparaten en verhoogde systeemstabiliteit.

Ook wordt de frequentie van berichtoverdracht bepaald:

In feite is er slechts één parameter beschikbaar voor selectie: het type hoofdklok (eentraps of tweetraps).

De nauwkeurigheid mag niet meer dan 1 μs bedragen. Met andere woorden, één synchronisatiepad kan maximaal 15 transparante klokken of drie grensklokken bevatten.

Bron: www.habr.com