🥇PTPv2 ajasünkroniseerimise protokolli rakendamise üksikasjad

Sissejuhatus

Elektroenergeetika "Digitaalne alajaam" ehituse kontseptsioon nõuab 1 µs täpsusega sünkroniseerimist. Ka finantstehingute tegemiseks on vajalik täpsus mikrosekundites. Nendes rakendustes ei piisa NTP ajasünkloonimise täpsusest enam.

Sünkroniseerimise protokoll PTPv2, mis on kirjeldatud standardis IEEE 1588v2, võimaldab saavutada sünkroniseerimistäpsust mitme kümne nanosekundi täpsusega. PTPv2 võimaldab saata sünkroniseerimise pakette L2 ja L3 võrkude kaudu.

Peamised valdkonnad, kus PTPv2 rakendatakse, on:

energeetika;
mõõtmise ja kontrollimise seadmed;
kaitsetööstus;
telekommunikatsioon;
finantssektor.

Selles postituses käsitletakse, kuidas PTPv2 sünkroniseerimisprotokoll töötab.

Meil on rohkem kogemusi tööstuses ja me kohtame sageli selle protokolliga seonduvat energeetikarakendustes. Seetõttu teeme ka ülevaate arvestades energeetikat..

Miks on see vajalik?

Praegu on standardites CТО 34.01-21-004-2019 ja CТО 56947007-29.240.10.302-2020 nõuded ajasünkroniseerimise tagamiseks PTPv2 kaudu.

See on seotud sellega, et protsessibussile on ühendatud releekaitse terminalid ja mõõtmisseadmed, mis edastavad protsessibussi kaudu, nn SV-voolude (multicast-voolud) abil koheseid voolu ja pinget,

Releekaitse terminalid kasutavad neid väärtusi kaitsemehhanismide rakendamiseks. Kui ajamõõtmiste täpsus on madal, võivad mõned kaitsed vääralt aktiveeruda.

Näiteks võivad „nõrga” aja sünkroniseerimise ohvriks langeda absoluutse selektiivsuse kaitsed. Sageli põhineb selliste kaitsete loogika kahe väärtuse võrdlemisel. Kui väärtused erinevad piisavalt suurelt, aktiveeritakse kaitse. Kui neid väärtusi mõõta 1 ms ajaga, võib tekkida suur erinevus seal, kus väärtused tegelikult on normis, kui neid mõõta 1 µs täpsusega.

PTP versioonid

PTP protokoll kirjeldati esmakordselt 2002. aastal standardis IEEE 1588-2002 ja selle nimi oli „Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems”. 2008. aastal ilmus uuendatud standard IEEE 1588-2008, mis kirjeldas PTP versiooni 2. Selles versioonis parandus täpsust ja stabiilsust, kuid tagasipööratav ühilduvus esimese versiooniga ei olnud säilinud. Samuti ilmus 2019. aastal standardi IEEE 1588-2019 versioon, mis kirjeldab PTP v2.1. See versioon toob PTPv2-le mõned täiendavad täiustused ja on PTPv2-ga tagasipööratavalt ühilduv.

Teisisõnu, me näeme versioonide järgmist pilti:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

—
Ühilduvad

Ühilduvad

PTPv2 (IEEE 1588-2008)

Ühilduvad

—
Ühilduvad

PTPv2.1 (IEEE 1588-2019)

Ühilduvad

—

Kuid, nagu alati, on nüansse.

Ühilduvusprobleem PTPv1 ja PTPv2 vahel tähendab, et PTPv1 toetav seade ei saa sünkroniseerida PTPv2 töötavate täpsete kelladega. Sünkroniseerimiseks kasutavad nad erinevaid sõnumiformaate.

Kuid PTPv1 ja PTPv2 seadmete kokkusobitamine samas võrgus on siiski võimalik. Selleks võimaldavad mõned tootjad piirikellade portidel valida protokolli versiooni. See tähendab, et piirikellad saavad sünkroniseerida PTPv2 kaudu ning samal ajal sünkroniseerida teisi ühendatud kellasid nii PTPv1 kui ka PTPv2 kaudu.

PTP seadmed. Milliseid tüüpe on ja kuidas nad erinevad?

IEEE 1588v2 standardis on kirjeldatud mitmeid seadme tüüpe. Kõik need on toodud tabelis.

Seadmed suhtlevad omavahel läbi LAN-i, kasutades PTP-d.

PTP seadmeid nimetatakse kelladeks. Kõik kellad saavad täpset aega grandmaster kelladelt.

On 5 tüüpi kellasid:

Grandmaster clock (Grandmaster kell)

Peamine täpse aja allikas. Sageli varustatud GPS-ühenduse võimalusega.

Ordinary Clock (Tavaline kell)

Seade, millel on üks port, mis võib olla master (juhtiv kell) või slave (aluseks kell).

Juhtiv kell (master)

On täpse aja allikas, mille alusel sünkroniseeritakse teised kellad.

Aluseks kell (slave)

Lõppseade, mis sünkroniseeritakse juhtivate kelladega.

Boundary Clock (Piirikell)

Seade, millel on mitu porti, mis võib olla master või slave.

Need kellad saavad sünkroniseerida kõrgemalt asuvate juhtivate kellade kaudu ja sünkroniseerida madalamale asuvaid aluseid kellede.

Lõpust lõpuni läbipaistvad kellad

Mitmeportiline seade, mis ei ole ei peamine kell ega aluskell. See edastab PTP andmeid kahe kella vahel.

Andmete edastamise ajal korrigeerivad läbipaistvad kellad kõik PTP teated.

Korrigeerimine toimub, lisades seadmes viivituse aja sätestatusele edastatava teate pealkirjas.

Peer-to-Peer läbipaistvad kellad

Mitmeportiline seade, mis ei ole ei peamine kell ega aluskell.
See edastab PTP andmeid kahe kella vahel.

Andmete edastamise ajal korrigeerivad läbipaistvad kellad kõik PTP teated Sync ja Follow_Up (millest allpool rohkem).

Korrigeerimine saavutatakse, lisades edastatava paketi täiendavale viivitusele saatvas seadmes ja edastamise kanalil.

Halduse node

Seade, mis konfigureerib ja diagnostiseerib teisi kellasid

Peamised ja aluskellad sünkroonitakse ajamärkide abil PTP teadetes. PTP protokollis on kaks tüüpi teateid:

Sündmuste teated – need on sünkroniseeritud teated, mis eeldavad ajamärgi genereerimist teate saatmise ja vastuvõtmise hetkel
Üldsündmuste teated – need teated ei nõua ajamärke, kuid võivad sisaldada ajamärke seotud teadetes

Sündmuste teated

Üldsündmuste teated

Sync
Delay_Req
Pdelay_Req
Pdelay_Resp

Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Halduse
Signaal

Järgnevalt käsitletakse kõiki teatetüüpe üksikasjalikult.

Peamised sünkroniseerimisprobleemid

Sync-paketi edastamisel kohaliku võrgu kaudu viibib see lüliti ja edastamiskanali tõttu. Iga lüliti põhjustab umbes 10 mikrosekundi viivituse, mis on PTPv2 jaoks vastuvõetamatu. Lõppseadmest on meil vajalik saada 1 mikrosekundi täpsus. (See kehtib energia kohta. Teised rakendused võivad nõuda veelgi suuremat täpsust.)

IEEE 1588v2-s on kirjeldatud mitmeid töötamisalgoritme, mis võimaldavad jälgida ajaviivitust ja seda korrigeerida.

Töö algoritm
Normaalses töökorralduses töötab protokoll kahes faasis.

Faas 1 — hierarchy määramine "Peamised kellad – Aluskellad".
Faas 2 — kellade sünkroniseerimine End-to-End või Peer-to-Peer mehhanismi abil.

Faas 1 - Hierarhia „Meister-Sklave” seadmine

Iga tavalise või piiraja kellaporti omad teatud seisundid (sõltuvad kella ja juhtiv kell). Standard määratleb ülemineku algoritmi nende seisundite vahel. Programmeerimises nimetatakse sellist algoritmi lõppautomaatiks või olekumasinaks (lisaks vt Wiki).

See lõppautomaat kasutab parima meistri kella algoritmi (BMCA) kahe kella ühendamisel meistri seadmiseks.

See algoritm võimaldab kelladel võtta endale suure kellamüüri kohustused, kui kõrgemad suuremad kellad kaotavad GPS-signaali, ühenduse katkestavad jne.

Seisundite üleminekud vastavalt BMCA-le on lühidalt kujutatud järgmises skeemis:

Informatsioon teiste kellade kohta „juhtme” teises otsas saadetakse spetsiaalses sõnumis (Announce message). Kui see informatsioon on saadud, käivitub olekumasina algoritm ja toimub võrreldamine, millised kellad on paremad. Parimate kellade port saab juhtivaks kellaks.

Lihtne hierarhia on esitatud allolevas skeemis. Teed 1, 2, 3, 4, 5 võivad sisaldada läbipaistvaid kelli (Transparent clock), kuid need ei osale hierarhia „Juhtivad kellad – Sõltuvad kellad” seadmisel.

Faas 2 - Tavaliste ja piiraja kellade sünkroniseerimine

Vahetult pärast hierarhia seadmist „Juhtivad kellad – Sõltuvad kellad” algab tavaliste ja piiraja kellade süknroniseerimise faas.

Sünkroniseerimise jaoks saadavad juhtivad kellad sõltuvatele kelladele sõnumi, mis sisaldab ajatemplit.

Juhtivad kellad võivad olla:

üheastmelised;
kaheastmelised.

Üheastmelised kellad saadavad sünkroniseerimiseks ühe sõnumi Sync.

Kaheastmelised kellad kasutavad sünkroniseerimiseks kahte sõnumit - Sync ja Follow_Up.

Sünkroniseerimise faasis võib kasutada kahte mehhanismi:

Viitamise nõudmise-mehhanism (Delay request-response mechanism).
Naabri viitamise mõõtmise mehhanism (Peer delay measurement mechanism).

Alguses vaatleme neid mehhanisme kõige lihtsamas juhtumis - kui ei kasutata läbipaistvaid kelli.

Viitamise nõudmise-mehhanism (Delay request-response mechanism)

Mehhanism eeldab kahte sammu:

Mõõdetakse viitamine sõnumi edastamisel juhtivate ja sõltuvate kellade vahel. Seda teostatakse viitamise nõudmise mehhanismi kaudu.
Teostatakse täpsete ajade nihke korrigeerimine.

Viitamise mõõtmine

t1 – Sõnumi saatmise aeg Sync pealekutsuvate kellade poolt; t2 – Sõnumi vastuvõtmise aeg Sync alluvate kellade poolt; t3 – Viivituse päringu (Delay_Req) saatmise aeg alluvate kellade poolt; t4 – Viivituse päringu vastuvõtmise aeg (Delay_Req) pealekutsuvate kellade poolt.

Kui alluvad kellad tunnevad aega t1, t2, t3 ja t4, saavad nad arvutada keskmise viivituse, kui vahetatakse sünkroonimisseadet (tmpd). See arvutatakse järgmisel viisil:

Sünkroonimise ja Follow_Up sõnumi saatmise ajal arvutatakse ajaviivitus meistrist orjale – t-ms.

Viivituse päringu ja vastuse saatmise ajal arvutatakse ajaviivitus orjalt meistrile – t-sm.

Kui nende kahe väärtuse vahel tekib mingisugune asümmeetria, siis ilmneb täpsete kellaaegade korrektsiooni viga. Viga tuleneb sellest, et arvutatud viivituse keskmine väärtus on t-ms ja t-sm viivitustest. Kui viivitused ei ole võrdsed, siis me ajastust õigesti ei korrigeeri.

Kellaaja korrektuur

Pärast seda, kui viivitust pealekutsuvate ja alluvate kellade vahel on teada, teevad alluvad kellad ajakorrektuuri.

Alluvad kellad kasutavad sõnumit Sync ja valikulist sõnumit Follow_Up, et arvutada täpsete kellaaegade nihkede korrektuur, kui pakett saadetakse pealekutsuvatest kelladest alluvatele. Nihke arvutamiseks kasutatakse järgmist valemit:

Naaberpuus olevate viivituste mõõtmise mehhanism

See mehhanism kasutab sünkroonimise saavutamiseks samuti kaht sammu:

Seadmed mõõdavad ajaviivitust kõikide naabritega kõiki porte kasutades. Selleks kasutatakse naaberpuudete mõõtmise mehhanismi.
Täpsete kellaaegade nihke korrektuur.

Viivituse mõõtmine seadmete vahel, mis toetavad Peer-to-Peer režiimi

Viivitust portide vahel, mis toetavad peer-to-peer mehhanismi, mõõdetakse järgmiste sõnumite abil:

Kui port 1 tunneb aega t1, t2, t3 ja t4, saab ta arvutada keskmise viivituse (tmld). See arvutatakse järgmise valemi abil:

Seejärel kasutab port seda väärtust iga Sync sõnumi või valikulise Follow_Up sõnumi korrektsiooni välja arvutamiseks, mis läbib antud seadet.

Lõplik viivitus on võrdne viivituse summaga, mis on seotud selle seadme kaudu toimetamisega, keskmise viivituse kogumi ja selle sõnumi sees juba sisaldunud viivitusega, mis on lisatud kõrgematel seadmetel.

Pdelay_Req, Pdelay_Resp ja valikuline Pdelay_Resp_Follow_Up sõnumid võimaldavad mõõta viivitust meistri ja orja vahel ning orjast meistrisse (ringikujuliselt).

Iga asümmeetria nende kahe väärtuse vahel toob kaasa täpse aja nihke korrigeerimise vea.

Täpse aja nihke korrigeerimine

Orjad kasutavad Sync-sõnumit ja valikulist Follow_Up sõnumit täpse aja nihke arvutamiseks, kui pakett edastatakse juhi kelladelt orjadele. Nihke arvutatakse järgmise valemi alusel:

Peer-to-peer mehhanismi korrigeerimise eelised – iga Sync või Follow_Up sõnumi viivitus arvutatakse selle edastamise käigus võrgus. Seetõttu ei mõjuta edastusteede muutmine korrigeerimise täpsust.

Selle mehhanismi kasutamisel ei ole aja sünkroniseerimine seotud viivituse arvutamisega, mis on vajalik sünkroniseerimise paketi läbitud teel, nagu seda tehakse põhivahetuses. St. Delay_Req ja Delay_Resp sõnumeid ei saadeta. Sel viisil liidetakse viivitus juhikellade ja orjade vahel lihtsalt iga Sync või Follow_Up sõnumi korrigeerimisvälja.

Veel üks eelis on see, et juhikellad vabastatakse Delay_Req sõnumite töötlemise kohustusest.

Läbipaistvate kellade töörežiimid

Seetõttu on need lihtsad näited juba käsitletud. Nüüd oletame, et sünkroniseerimise teel ilmuvad lülitid.

Kui kasutada PTPv2-t toetamata lüliteid, siis sünkroniseerimise pakett viibib lülitil umbes 10 μs.

PTPv2 toetavaid lüliteid, mida IEEE 1588v2 terminoloogias nimetatakse läbipaistvateks kelladeks (Transparent clock), ei sünkroniseerita juhikelladelt ja nad ei osale hierarhias 'Juhikellad – Orjakellad', kuid nad mäletavad, kui kaua sõnum edastamise ajal viibib. See võimaldab viivitust korrigeerida.

Läbipaistvad kellad võivad töötada kahes režiimis:

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

End-to-End (E2E)

E2E läbipaistvad kellad edastavad Sync sõnumeid ja seotud Follow_Up sõnumeid kõigile portidele. Isegi neile, mida blokeerivad mõned protokollid (nt RSTP).

Lüliti mäletab aega, mil Sync (Follow_Up) pakett porti vastuvõeti ja millal see sealt saadeti. Nende kahe ajamärgi alusel arvutatakse lüliti töötlemise aeg sõnumi jaoks. Standardis nimetatakse seda aega residence time.

Töötlemisaeg lisatakse Sync sõnumi correctionField väljarisse (üheastmelised kellad) või Follow_Up väljarisse (kaheastmelised kellad).

Läbipaistvad E2E kellad mõõdavad töötlemisaega Sync ja Delay_Req sõnumite jaoks, mis läbivad lüliti. Siiski on oluline mõista, et viivitus ajas, mis on juhtivate ja alluvate kellade vahel, arvutatakse viivituse päringu-vastuse mehhanismi abil. Kui juhtivad kellad muutuvad või kui tee juhtivatest kelladest alluvatesse muutub, mõõdetakse viivitus uuesti. See pikendab ülemineku aeg, kui võrgu tingimused muutuvad.

Läbipaistvad P2P kellad, välja arvatud lüliti sõnumi töötlemise aja mõõtmine, mõõdavad viivitust andmeedastuskanalis lähima naabri suunal, kasutades naaber sõlme viivituse mõõtmise mehhanismi.

Viivitus mõõdetakse igal kanali suunal, sealhulgas kanalitel, mis on blokeeritud mõne protokolli (nt RSTP) tõttu. See võimaldab kohe arvutada uue viivituse sünkroonimise teel, kui peegelduskellad või võrgu topoloogia on muutunud.

Lülitite sõnumite töötlemise aeg ja viivitusaeg kogunetakse Sync või Follow_Up sõnumite edastamisel.

PTPv2 toe tüübid lülitites

Lülitid võivad toetada PTPv2:

tarkvara kaudu;
riistvara kaudu.

PTPv2 protokolli tarkvaralise rakendamise korral küsib lüliti ajamärki püsivara käest. Probleem seisneb selles, et püsivara töötab tsükliliselt ja tuleb oodata, kuni see lõpetab hetke tsükli, võtab päringu töötlusele ja järgmise tsükli lõppedes annab ajamärgi välja. Selleks kulub samuti aega, ning saame viivituse, kuigi see ei ole nii märkimisväärne kui ilma PTPv2 tarkvaratuge.

Nõutud täpsuse tagamiseks on vajalik ainult PTPv2 riistvaraline toetus. Sel juhul väljastatakse ajamärk spetsiaalse ASIC'i poolt, mis on installeeritud porti.

Sõnumi formaat

Kõik PTP sõnumid koosnevad järgmistest väljadest:

Header – 34 baiti.
Body – suurus sõltub sõnumi tüübist.
Suffix – valikuline.

Header

Headeri väli on kõigi PTP sõnumite jaoks sama. Selle suurus on 34 bite.

Headeri väli formaat:

messageType – sisaldab edastatava sõnumi tüüpi, näiteks Sync, Delay_Req, PDelay_Req jne.

messageLength – sisaldab PTP sõnumi kogusuurust, sealhulgas headerit, body't ja suffiksi (kuid ilma täitmisbittideta).

domainNumber – määrab, millisele domeeniga PTP-le kuulub sõnum.

Domeen – need on mitmed erinevad kellad, mis on ühendatud üheks loogiliseks grupiks ja sünkroonitud ühe peamise kella kaudu, kuid ei pruugi olla sünkroonitud teiste domeenide kelladega.

flags – see väli sisaldab erinevaid lippe sõnumi staatuse identifitseerimiseks.

correctionField – sisaldab edasilükkamise aega nanosekundites. Edasilükkamise aeg sisaldab edastamise viivitust läbi läbipaistvate kellade ning edastamise viivitust kanali kaudu, kasutades Peer-to-Peer režiimi.

sourcePortIdentity – see väli sisaldab teavet selle kohta, milliselt pordilt see sõnum esmakordselt saadeti.

sequenceID – sisaldab individuaalsete sõnumite identifitseerimisnumbrit.

controlField – artefakti väli =) See jäi esimeselt standardiversioonilt ja sisaldab teavet antud sõnumi tüübi kohta. Sisuliselt on see sama, mis messageType, kuid vähemate valikutega.

logMessageInterval – seda väli määratakse sõnumi tüübi järgi.

Keha

Nagu ülalpool arutatud, on olemas mitu tüüpi sõnumeid. Need tüübid on allpool kirjeldatud:

Announce sõnum
Announce sõnumit kasutatakse selleks, et "teavitada" teisi kellasid ühe domeeni sees oma parameetritest. See sõnum võimaldab kehtestada hierarhiat "Pea kellad – Alluv kellad".

Sync sõnum
Sünkroniseerimise sõnum (Sync) saadetakse peakellade poolt ja sisaldab peakellade aega hetkel, kui Sync sõnum loodi. Kui peakellad on kaheastmelised, siis Sync sõnumis olev ajatempli väärtus seatakse 0-le, samas kui tegelik ajatempli väärtus saadetakse seotud Follow_Up sõnumis. Sync sõnumit kasutatakse mõlemas viivituse mõõtmise mehhanismis.

Sõnum edastatakse Multicast'i kaudu. Valikuliselt võib kasutada Unicast'i.

Delay_Req sõnum

Delay_Req sõnumi formaat on identne Sync sõnumiga. Alluvad kellad saadavad Delay_Req. See sisaldab Delay_Req'i edastamise aega alluvate kellade poolt. Seda sõnumit kasutatakse ainult viivituse päring-response mehhanismi jaoks.

Sõnum edastatakse Multicast'i kaudu. Valikuliselt võib kasutada Unicast'i.

Follow_Up sõnum

Follow_Up sõnum saadetakse vabatahtlikult juhtivate kellade poolt ja sisaldab saatmise aega Sync sõnumid meistrilt. Follow_Up sõnumit saadavad ainult kaheastmelised juhtivad kellad.

Follow_Up sõnumit kasutatakse mõlemas viivituse mõõtmise mehhanismis.

Sõnum edastatakse Multicast'i kaudu. Valikuliselt võib kasutada Unicast'i.

Delay_Resp sõnum

Delay_Resp sõnum saadetakse juhtivate kellade poolt. See sisaldab aega, millal juhtivad kellad said Delay_Req. Seda sõnumit kasutatakse ainult viivituse päring-vastus mehhanismis.

Sõnum edastatakse Multicast'i kaudu. Valikuliselt võib kasutada Unicast'i.

Pdelay_Req sõnum

Pdelay_Req sõnum saadetakse seadme poolt, mis küsib viivitust. See sisaldab sõnumi saatmise aega selle seadme portist. Pdelay_Req kasutatakse ainult naabriliste viivituste mõõtmise mehhanismis.

Pdelay_Resp sõnum

Pdelay_Resp sõnum saadetakse seadme poolt, mis sai viivituse päringu. See sisaldab aega, millal antud seade sai Pdelay_Req sõnumi. Pdelay_Resp sõnumit kasutatakse ainult naabriliste viivituste mõõtmise mehhanismis.

Pdelay_Resp_Follow_Up sõnum

Pdelay_Resp_Follow_Up sõnum saadetakse vabatahtlikult seadme poolt, mis sai viivituse päringu. See sisaldab aega, mil antud seade sai Pdelay_Req sõnumi. Pdelay_Resp_Follow_Up sõnumit saadavad ainult kaheastmelised juhtivad kellad.

Seda sõnumit võib kasutada ka teostamise aja määramiseks, mitte ajamärgina. Teostamise aeg on aeg alates Pdelay-Req saamisest kuni Pdelay_Resp saatmiseni.

Pdelay_Resp_Follow_Up kasutatakse ainult naabriliste viivituste mõõtmise mehhanismis.

Juhtivad sõnumid (Management sõnum)

PTP juhtivad sõnumid on vajalikud teabe edastamiseks ühe või mitme kellaga ja juhtimispunktiga.

Edastus LVs

PTP sõnumit saab edastada kahe tasandi kaudu:

Võrgutasandil – IP-andmete osana.
Kanalitasandil – Etherneti raami osana.

PTP sõnumi edastus UDP kaudu IP kaudu Etherneti kaudu

PTP üle UDP üle Ethernet

Profiilid

PTP-l on palju 'paindlikke' parameetreid, mis tuleb seadistada. Näiteks:

BMCA valikud.
Viivituse mõõtmise mehhanism.
Intervallid ja kõik konfigureeritavad parameetrid ning nende algväärtused jne.

Ja kuigi me varem rääkisime, et PTPv2 seadmed on omavahel ühilduvad, ei ole see tegelikult tõsi. Seadmetel peavad olema ühesugused seadistused, et nad saaksid omavahel suhelda.

Seetõttu eksisteerivad nn PTPv2 profiilid. Profiilid on konfigureeritud seadete ja teatud protokollipiirangute rühmad, et oleks võimalik rakendada ajasünkroniseerimist teatud rakenduse jaoks.

IEEE 1588v2 standard kirjeldab vaid ühte profiili – „Default Profile“. Kõik teised profiilid on loodud ja kirjeldatud erinevate organisatsioonide ja assotsiatsioonide poolt.

Näiteks, elektribrantsi jaoks loodud PTPv2 Power Profile loodi Power Systems Relaying Committee ja Substation Committee komitee poolt IEEE Power and Energy Society's. Profiil kannab nime IEEE C37.238-2011.

Profiil kirjeldab, et PTP võib edastada:

Ainult L2-võrkude kaudu (s.t. Ethernet, HSR, PRP, mitte IP).
Sõnumid edastatakse ainult Multicast-raadiosaatmisega.
Viivituse mõõtmise mehhanismina kasutatakse Peer delay measurement mechanism.

Vaikimisi domeen on 0, soovitatav domeen on 93.

C37.238-2011 loomise filosoofia põhines soovil vähendada valikute arvu ja jätta alles vaid vajalikud funktsioonid seadmete usaldusväärseks suhtlemiseks ning süsteemi stabiilsuse suurendamiseks.

Samuti on määratud sõnumite edastamise sagedus:

Sisuliselt on valida vaid üks parameeter – juhtivate kellade tüüp (üheastmelised või kaheastmelised).