Details over de implementatie van het tijdsynchronisatieprotocol PTPv2

Inleiding

Het concept van het bouwen van een 'Digitale Onderstation' in de elektriciteitssector vereist synchronisatie met een nauwkeurigheid van 1 µs. Voor financiële transacties is ook een nauwkeurigheid in µs vereist. In deze toepassingen is de tijdsprecisie van NTP al onvoldoende.

Het synchronisatieprotocol PTPv2, beschreven in de standaard IEEE 1588v2, maakt synchronisatie met een nauwkeurigheid van enkele tientallen nanoseconden mogelijk. PTPv2 stelt in staat synchroniciteitspakketten via L2 en L3-netwerken te verzenden.

De belangrijkste gebieden waar PTPv2 wordt toegepast, zijn:

• energie;
• meet- en regelsystemen;
• de defensie-industrie;
• telecom;
• de financiële sector.

In deze post wordt uitgelegd hoe het synchronisatieprotocol PTPv2 werkt.

Wij hebben meer ervaring in de industrie en komen dit protocol vaak tegen in energieapplicaties. Daarom zullen we de bespreking richten op energie.

Waarom is dit nodig?

Op dit moment bevat de STO 34.01-21-004-2019 van PJSC 'Rosseti' en de STO 56947007-29.240.10.302-2020 van PJSC 'FSK EES' eisen voor de organisatie van de procestechniek met tijdssynchronisatie via PTPv2.

Dit heeft te maken met het feit dat de procesbus terminals voor relaisbescherming en meetapparatuur aansluit die via de procesbus, met behulp van zogenaamde SV-stromen (multicast-stromen), onmiddellijke waarden van stroom en spanning verzenden.

De terminals voor relaisbescherming gebruiken deze waarden om de bescherming van aansluitingen uit te voeren. Als de nauwkeurigheid van de tijdmetingen laag is, kunnen sommige beschermingen onterecht in werking treden.

Bijvoorbeeld, het slachtoffer van 'zwakke' tijdssynchronisatie kunnen de protectie met absolute selectiviteit zijn. Vaak is de logica van dergelijke protecties gebaseerd op de vergelijking van twee grootheden. Als de grootheden aanzienlijk verschillen, treedt de bescherming in werking. Wanneer deze grootheden met een tijdsperspectief van 1 ms worden gemeten, kan er een grote afwijking optreden, terwijl de waarden in werkelijkheid normaal zijn als ze met een precisie van 1 µs worden gemeten.

Versies van PTP

Het PTP-protocol werd oorspronkelijk beschreven in 2002 in de IEEE-standaard 1588-2002 en heette "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". In 2008 werd de bijgewerkte standaard IEEE 1588-2008 uitgebracht, die PTP versie 2 beschrijft. In deze versie van het protocol zijn de nauwkeurigheid en stabiliteit verbeterd, maar de achterwaartse compatibiliteit met de eerste versie van het protocol is niet behouden. Ook werd in 2019 versie IEEE 1588-2019 uitgebracht, die PTP v2.1 beschrijft. Deze versie voegt enkele kleine verbeteringen toe aan PTPv2 en is achterwaarts compatibel met PTPv2.

Met andere woorden, we hebben het volgende overzicht van versies:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

—
Incompatible

Incompatible

PTPv2 (IEEE 1588-2008)

Incompatible

—
Compatibel

PTPv2.1 (IEEE 1588-2019)

Incompatible

Compatibel

—

Maar, zoals altijd, zijn er nuances.

De incompatible tussen PTPv1 en PTPv2 betekent dat een apparaat dat PTPv1 ondersteunt niet kan synchroniseren met nauwkeurige klokken die op PTPv2 werken. Voor synchronisatie gebruiken ze verschillende berichtformaten.

Maar het is toch mogelijk om apparaten met PTPv1 en apparaten met PTPv2 in hetzelfde netwerk te combineren. Hiervoor stellen sommige fabrikanten in staat om op de poorten van grensklokken de versie van het protocol te kiezen. Dit betekent dat grensklokken kunnen synchroniseren via PTPv2 en tegelijkertijd andere aangesloten klokken kunnen synchroniseren via zowel PTPv1 als PTPv2.

PTP-apparaten. Welke types zijn er en hoe verschillen ze?

De standaard IEEE 1588v2 beschrijft verschillende types apparaten. Alle worden in de tabel weergegeven.

Apparaten communiceren met elkaar via een LAN met behulp van PTP.

PTP-apparaten worden klokken genoemd. Alle klokken nemen de exacte tijd van de grandmasterklok.

Er zijn 5 types klokken:

Grandmaster klok

De primaire bron van exacte tijd. Vaak uitgerust met een interface voor GPS-aansluiting.

Ordinary Clock

Een apparaat met één poort dat master (leidende klok) of slave (volgende klok) kan zijn.

Leidende klok (master)

Zij zijn de bron van exacte tijd waar andere klokken op synchroniseren.

Volgende klok (slave)

Het uiteindelijke apparaat dat synchroniseert met leidende klokken.

Boundary Clock

Een apparaat met meerdere poorten dat master of slave kan zijn.

Dit betekent dat deze klokken kunnen synchroniseren met hogere leidende klokken en lagere volgende klokken kunnen synchroniseren.

End-to-end Transparante Klok

Een apparaat met meerdere poorten dat geen meester- of slavenklok is. Het verzendt PTP-gegevens tussen twee klokken.

Bij het verzenden van gegevens corrigeren transparante klokken alle PTP-berichten.

De correctie gebeurt door het toevoegen van vertragingstijd aan dit apparaat in het correctieveld in de header van het verzonden bericht.

Peer-to-Peer Transparante Klok

Een apparaat met meerdere poorten dat geen meester- of slavenklok is.
Het verzendt PTP-gegevens tussen twee klokken.

Bij het verzenden van gegevens corrigeren transparante klokken alle PTP Sync- en Follow_Up-berichten.

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

Beheernode

Een apparaat dat andere klokken configureert en diagnosticeert.

Meester- en slavenklokken worden gesynchroniseerd met behulp van timestamps in PTP-berichten. Er zijn twee soorten berichten in het PTP-protocol:

• Event Messages – dit zijn gesynchroniseerde berichten die een timestamp genereren op het moment van verzending en ontvangst.
• General Messages – deze berichten vereisen geen timestamps, maar kunnen timestamps bevatten voor gerelateerde berichten.

Event Messages

General Messages

Sync
Delay_Req
Pdelay_Req
Pdelay_Resp

Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling

Vervolgens worden alle berichttypes in detail besproken.

Belangrijkste synchronisatieproblemen

Bij het verzenden van een synchronisatiepakket via het lokale netwerk ontstaat vertraging op de switch en in de datatransmissiekanaal. Elke switch veroorzaakt ongeveer 10 μs vertraging, wat onacceptabel is voor PTPv2. We hebben op het eindapparaat een precisie van 1 μs nodig. (Dit geldt voor de energiesector. Andere toepassingen kunnen mogelijk nog hogere precisie vereisen.)

In IEEE 1588v2 worden verschillende werkalgoritmen beschreven die de tijdvertraging kunnen vastleggen en corrigeren.

Werkwijze
Bij normale werking werkt het protocol in twee fasen.

• Fase 1 - het instellen van de hiërarchie 'Meesterklokken - Slavenklokken'.
• Fase 2 - synchronisatie van klokken met behulp van het End-to-End of Peer-to-Peer mechanisme.

Fase 1 - Installatie van de "Master-Slave" hiërarchie

Elke poort van gewone of grensklokken heeft een bepaald aantal toestanden (slave klokken en master klokken). De standaard beschrijft het algoritme voor de overgang tussen deze toestanden. In de programmering wordt zo'n algoritme een eindige automaat of toestandsmachine genoemd (meer hierover in Wiki).

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

Dit algoritme stelt klokken in staat om de verantwoordelijkheden van de grandmaster klokken over te nemen wanneer de bovenliggende grandmaster klokken het GPS-signaal verliezen, van de netstroom worden gehaald, enzovoort.

De overgangen tussen toestanden volgens BMCA zijn kort weergegeven in het volgende schema:


Informatie over de klokken aan de andere kant van de "draad" wordt verzonden in een speciaal bericht (Announce message). Wanneer deze informatie is ontvangen, wordt het algoritme van de toestandsmachine geactiveerd en vindt er een vergelijking plaats om te bepalen welke klok beter is. De poort op de beste klok wordt de master klok.

Een eenvoudige hiërarchie is weergegeven in het onderstaande schema. De paden 1, 2, 3, 4, 5 kunnen transparante klokken (Transparent clock) bevatten, maar zij nemen niet deel aan de opzet van de hiërarchie "Master klokken - Slave klokken".

Fase 2 - Synchronisatie van gewone en grensklokken

Direct na de installatie van de hiërarchie "Master klokken - Slave klokken" begint de fase van synchronisatie van gewone en grensklokken.

Voor de synchronisatie sturen de master klokken een bericht naar de slave klokken, dat een tijdstempel bevat.

Master klokken kunnen zijn:

• ééntraps;
• tweetraps.

Ééntraps klokken sturen één bericht Sync voor synchronisatie.

Tweetraps klokken maken gebruik van twee berichten - Sync en Follow_Up voor synchronisatie.

Voor de synchronisatiefase kunnen twee mechanismen worden gebruikt:

• Mechanisme voor vertraging-aanvraag en antwoord (Delay request-response mechanism).
• Mechanisme voor het meten van de vertraging van de buurknop (Peer delay measurement mechanism).

Laten we deze mechanismen eerst bekijken in de eenvoudigste situatie - wanneer er geen transparante klokken worden gebruikt.

Mechanisme voor vertraging-aanvraag en antwoord (Delay request-response mechanism)

Het mechanisme veronderstelt twee stappen:

1. Het meten van de vertraging bij het verzenden van een bericht tussen de master- en slaveklokken. Dit gebeurt via het mechanisme voor vertraging-aanvraag en antwoord.
2. Er wordt een correctie aangebracht op de verschuiving van de exacte tijd.

Meting van de vertraging


t1 – Verzendetijd van het Sync-bericht van de masterklok; t2 – Ontvangsttijd van het Sync-bericht door de slaveklok; t3 – Verzendetijd van het vertraging verzoek (Delay_Req) door de slaveklok; t4 – Ontvangsttijd van Delay_Req door de masterklok.

Wanneer de slaveklokken de tijden t1, t2, t3 en t4 weten, kunnen zij de gemiddelde vertraging bij de overdracht van het synchronisatiebericht (tmpd) berekenen. Dit wordt als volgt berekend:

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

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

Als er een asymmetrie tussen deze twee waarden ontstaat, ontstaat er een fout in de correctie van de exacte tijd. De fout komt voort uit het feit dat de berekende vertraging het gemiddelde is van de vertragingen t-ms en t-sm. Als de vertragingen niet gelijk zijn, zullen we de tijd onnauwkeurig corrigeren.

Correctie van de verschuiving van de exacte tijd

Nadat de vertraging tussen de masterklokken en de slaveklokken bekend is, voeren de slaveklokken de tijdcorrectie uit.

De slaveklokken gebruiken het Sync-bericht en het optionele Follow_Up-bericht om de verschuiving van de exacte tijd tijdens de overdracht van pakketten van de masterklokken naar de slaveklokken te berekenen. De verschuiving wordt berekend met de volgende formule:

Mechanisme voor het meten van de vertraging van een buurknooppunt (Peer delay measurement mechanism)

Dit mechanisme maakt ook gebruik van twee stappen voor synchronisatie:

1. Apparaten meten de tijdsvertraging naar alle buren via alle poorten. Hiervoor gebruiken ze het peer delay mechanism.
2. Correctie van de verschuiving van de exacte tijd.

Meting van de vertraging tussen apparaten die de Peer-to-Peer-modus ondersteunen

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

Wanneer poort 1 de tijden t1, t2, t3 en t4 weet, kan hij de gemiddelde vertraging (tmld) berekenen. Dit wordt berekend met de volgende formule:

Vervolgens gebruikt de poort deze waarde bij het berekenen van het correctieveld voor elk Sync-bericht of het optionele Follow_Up-bericht dat door dit apparaat gaat.

De uiteindelijke vertraging is gelijk aan de som van de vertraging bij de overdracht via dit apparaat, de gemiddelde vertraging bij de overdracht via de gegevenskanaal en de reeds aanwezige vertraging in dit bericht, zoals opgenomen op de bovenliggende apparaten.

De berichten Pdelay_Req, Pdelay_Resp en de optionele Pdelay_Resp_Follow_Up stellen ons in staat om de vertraging van master naar slave en van slave naar master (rond) te verkrijgen.

Elke asymmetrie tussen deze twee waarden zal een fout in de tijdschaalcorrectie introduceren.

Tijdschaalcorrectie

De slave-klokken gebruiken het Sync-bericht en het optionele Follow_Up-bericht om de tijdschaalcorrectie te berekenen bij het verzenden van een pakket van de masterklok naar de slaveklokken. De correctie wordt berekend met de volgende formule:

De voordelen van de peer-to-peer correctiemechanisme – de vertraging van elk Sync- of Follow_Up-bericht wordt berekend tijdens de verzending in het netwerk. Daarom zal een wijziging van de verzendroute geen invloed hebben op de nauwkeurigheid van de correctie.

Bij het gebruik van dit mechanisme vereist de tijdsynchronisatie geen berekening van de tijdsvertraging over de route die het synchronisatiepakket heeft genomen, zoals bij basale uitwisselingen. Dat wil zeggen, de berichten Delay_Req en Delay_Resp worden niet verzonden. In deze methode wordt de vertraging tussen de masterklokken en de slaveklokken simpelweg opgeteld in het correctieveld van elk Sync- of Follow_Up-bericht.

Een ander voordeel is dat de masterklokken ontlast worden van de noodzaak om Delay_Req-berichten te verwerken.

Modi van werking van transparante klokken

Bijgevolg werden hier eenvoudige voorbeelden besproken. Laten we nu veronderstellen dat er switches op de synchronisatieroute verschijnen.

Als we switches zonder PTPv2-ondersteuning gebruiken, zal het synchronisatiepakket ongeveer 10 µs op de switch worden vertraagd.

Switches met PTPv2-ondersteuning worden in de terminologie van IEEE 1588v2 transparante klokken (Transparent clock) genoemd. Transparante klokken synchroniseren niet met de masterklokken en maken geen deel uit van de hiërarchie ‘Masterklok - Slaveklok’, maar tijdens de overdracht van synchronisatieberichten onthouden ze hoe lang het bericht op hen is vertraagd. Dit maakt het mogelijk om de tijdsvertraging te corrigeren.

Transparante klokken kunnen in twee modi werken:

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

End-to-End (E2E)

E2E-transparante klokken verzenden Sync-berichten en bijbehorende Follow_Up-berichten naar alle poorten. Zelfs naar die welke door bepaalde protocollen (bijvoorbeeld RSTP) zijn geblokkeerd.

De switch onthoudt de tijdstempel wanneer het Sync-pakket (Follow_Up) op de poort is ontvangen en wanneer het van de poort is verzonden. Op basis van deze twee tijdstempels wordt de verwerkingstijd van het bericht door de switch berekend. In de standaard wordt deze tijd de residence time genoemd.

De verwerkingstijd wordt toegevoegd in het correctionField van het Sync-bericht (ééntrap-horra) of Follow_Up (tweedegraads-horra).

Transparante E2E-horloges meten de verwerkingstijd voor Sync- en Delay_Req-berichten die door de switch gaan. Het is echter belangrijk om te begrijpen dat de vertragingstijd tussen de masterhorloges en de slavehorloges wordt berekend met behulp van een delay-request responsmechanisme. Als de masterhorloges veranderen of als het pad van de masterhorloges naar de slavehorloges verandert, wordt de vertraging opnieuw gemeten. Dit verhoogt de transitietijd in het geval van netwerkwijzigingen.

Transparante P2P-horloges meten, naast de verwerkingstijd van het bericht door de switch, ook de vertraging op de dataverbinding naar de dichtstbijzijnde buur, met behulp van een mechanisme voor het meten van de vertraging van de naburige knoop.

De vertraging wordt op elk kanaal in beide richtingen gemeten, inclusief kanalen die door een protocol zijn geblokkeerd (bijvoorbeeld RSTP). Dit maakt het mogelijk om onmiddellijk de nieuwe vertraging op het synchronisatiepad te berekenen, als de grandmaster-horloges of de netwerktopologie zijn gewijzigd.

De verwerkingstijden van berichten door switches en de vertragingstijden worden verzameld bij het verzenden van Sync- of Follow_Up-berichten.

Type ondersteuning voor PTPv2 door switches

Switches kunnen PTPv2 ondersteunen:

• softwarematig;
• hardwarematig.

Bij de softwarematige implementatie van het PTPv2-protocol vraagt de switch om een tijdstempel van de firmware. Het probleem is dat de firmware cyclisch werkt, en je moet wachten tot deze de huidige cyclus heeft voltooid, het verzoek heeft verwerkt en in de volgende cyclus de tijdstempel heeft afgegeven. Dit kost ook tijd en we krijgen een vertraging, zij het minder significant dan zonder softwarematige ondersteuning van PTPv2.

De benodigde nauwkeurigheid kan alleen worden bereikt met hardwarematige ondersteuning van PTPv2. In dit geval wordt de tijdstempel geleverd door een speciale ASIC die op de poort is geïnstalleerd.

Berichtformaat

Alle PTP-berichten bestaan uit de volgende velden:

• Header – 34 bytes.
• Body – grootte hangt af van het type bericht.
• Suffix – optioneel.

Header

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

Header-veld formaat:

messageType – geeft het type van het overgedragen bericht aan, bijvoorbeeld Sync, Delay_Req, PDelay_Req, enzovoorts.

messageLength – geeft de totale grootte van het PTP-bericht aan, inclusief header, body en suffix (maar exclusief vulbytes).

domainNumber – bepaalt tot welk een domein. PTP het bericht behoort.

Domein – dit zijn verschillende klokken die in één logische groep zijn samengebracht en gesynchroniseerd worden vanaf een enkele masterklok, maar niet noodzakelijk gesynchroniseerd zijn met klokken die tot een ander domein behoren.

flags – dit veld bevat verschillende vlaggen voor het identificeren van de status van het bericht.

correctionField – bevat de vertraging in nanoseconden. De vertraging omvat de transmissievertraging via transparante klokken, evenals de vertraging bij de overdracht via het kanaal in Peer-to-Peer-modus.

sourcePortIdentity – dit veld bevat informatie over de poort van waaruit het bericht oorspronkelijk is verzonden.

sequenceID – bevat het identificatienummer voor individuele berichten.

controlField – een artifact-veld=) Het is overgebleven van de eerste versie van de standaard en bevat informatie over het type van dit bericht. Het is in wezen hetzelfde als messageType, maar met minder opties.

logMessageInterval – dit veld wordt bepaald door het type bericht.

Body

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

Announce-bericht
Het Announce-bericht wordt gebruikt om andere klokken binnen hetzelfde domein te informeren over zijn parameters. Dit bericht stelt de hiërarchie "Masterklokken - Slaveklokken" in.


Sync-bericht
Het synchronisatiebericht (Sync) wordt verzonden door masterklokken en bevat de tijd van de masterklok op het moment dat het Sync-bericht is aangemaakt. Als de masterklokken tweestaps zijn, wordt de tijdstempel in het Sync-bericht gelijkgesteld aan 0, en de actuele tijdstempel wordt verzonden in het gekoppelde Follow_Up-bericht. Het Sync-bericht wordt gebruikt voor beide mechanismen voor het meten van vertraging.

Het bericht wordt verzonden via Multicast. Optioneel kan Unicast worden gebruikt.

Delay_Req-bericht

Het formaat van het Delay_Req-bericht is identiek aan dat van het Sync-bericht. Slaveklokken sturen Delay_Req. Dit bevat de verzendtijd van Delay_Req door de slaveklokken. Dit bericht wordt alleen gebruikt voor het delay-request-response-mechanisme.

Het bericht wordt verzonden via Multicast. Optioneel kan Unicast worden gebruikt.

Follow_Up Bericht

Het Follow_Up Bericht wordt optioneel verzonden door de masterklokken en bevat het verzendmoment. Sync berichten door de master. Het Follow_Up Bericht wordt alleen verzonden door tweelagen masterklokken.

Het Follow_Up Bericht wordt gebruikt voor beide mechanismen van latenciemeting.

Het bericht wordt verzonden via Multicast. Optioneel kan Unicast worden gebruikt.

Delay_Resp Bericht

Het Delay_Resp Bericht wordt verzonden door de masterklokken. Het bevat de ontvangsttijd van Delay_Req door de masterklokken. Dit bericht wordt alleen gebruikt voor het verzoek-antwoordmechanisme van vertraging.

Het bericht wordt verzonden via Multicast. Optioneel kan Unicast worden gebruikt.

Pdelay_Req Bericht

Het Pdelay_Req Bericht wordt verzonden door het apparaat dat de vertraging aanvraagt. Het bevat de verzendtijd van het bericht vanaf de poort van dit apparaat. Pdelay_Req wordt alleen gebruikt voor het mechanism van latenciemeting van de buren.

Pdelay_Resp Bericht

Het Pdelay_Resp Bericht wordt verzonden door het apparaat dat het verzoek om vertraging heeft ontvangen. Het bevat de ontvangsttijd van het Pdelay_Req bericht door dit apparaat. Pdelay_Resp berichten worden alleen gebruikt voor het mechanisme van latenciemeting van de buren.

Pdelay_Resp_Follow_Up Bericht

Het Pdelay_Resp_Follow_Up Bericht wordt optioneel verzonden door het apparaat dat het verzoek om vertraging heeft ontvangen. Het bevat de ontvangsttijd van het Pdelay_Req bericht door dit apparaat. Het Pdelay_Resp_Follow_Up Bericht wordt alleen verzonden door tweelagen masterklokken.

Daarnaast kan dit bericht worden gebruikt voor de uitvoeringstijd in plaats van de tijdstempel. De uitvoeringstijd is de tijd van ontvangst van Pdelay-Req tot het verzenden van Pdelay_Resp.

Pdelay_Resp_Follow_Up wordt alleen gebruikt voor het mechanisme van latenciemeting van de buren.

Beheerders berichten (Management Bericht)

Beheerdersberichten PTP zijn noodzakelijk voor de overdracht van informatie tussen een of meerdere klokken en een beheersnode.

Overdracht op LV

PTP-berichten kunnen op twee niveaus worden verzonden:

• Netwerkniveau – als onderdeel van IP-gegevens.
• Kanaalniveau – als onderdeel van een Ethernet-frame.

Overdracht van PTP-berichten via UDP via IP via Ethernet

PTP via UDP via Ethernet

Profielen

PTP heeft veel 'flexibele' parameters die moeten worden ingesteld. Bijvoorbeeld:

• BMCA-opties.
• Mechanisme van latenciemeting.
• Intervallen en beginwaarden van alle configureerbare parameters, enz.

En hoewel we eerder zeiden dat PTPv2-apparaten compatibel zijn met elkaar, is dat in feite niet zo. Apparaten moeten dezelfde instellingen hebben om met elkaar te kunnen communiceren.

Daarom bestaan er zogenaamde PTPv2-profielen. Profielen zijn groepen van geconfigureerde instellingen en specifieke beperkingen van het protocol, zodat tijdsynchronisatie voor een bepaalde toepassing kan worden gerealiseerd.

De standaard IEEE 1588v2 beschrijft slechts één profiel – het 'Default Profile'. Alle andere profielen zijn gemaakt en beschreven door verschillende organisaties en verenigingen.

Bijvoorbeeld, het profiel voor de elektriciteitssector of PTPv2 Power Profile is ontwikkeld door de Power Systems Relaying Committee en de Substation Committee van de IEEE Power and Energy Society. Het profiel is genoemd naar IEEE C37.238-2011.

Het profiel beschrijft wat PTP kan verzenden:

• Alleen via L2-netwerken (d.w.z. Ethernet, HSR, PRP, niet IP).
• Berichten worden alleen via Multicast-verzending verzonden.
• Als mechanisme voor vertragingmeting wordt het Peer delay measurement mechanism gebruikt.

De standaard domein is 0, de aanbevolen domein is 93.

De filosofie achter de creatie van C37.238-2011 was de wens om het aantal optionele kenmerken te verminderen en alleen de noodzakelijke functies voor betrouwbare communicatie tussen apparaten te behouden en de stabiliteit van het systeem te verhogen.

Er is ook een frequentie voor het verzenden van berichten gedefinieerd:

In wezen is er slechts één parameter beschikbaar voor selectie – het type masterklok (eentrap of tweetrap).

De nauwkeurigheid mag niet meer dan 1 µs zijn. Met andere woorden, in één synchronisatiepad kunnen maximaal 15 transparante klokken of drie grensklokken worden opgenomen.

Bron: habr.com