🥇PTPv2 aja sünkroonimise protokolli rakenduse detailid

Sissejuhatus

Elektroenergeetika 'Digitaalne alajaam' ehitamise konseptsioon nõuab 1 μs täpsusega sünkroniseerimist. Finantstehingute läbiviimiseks on samuti vajalik täpsus μs-s. Nendes rakendustes ei piisa enam NTP ajatahusest.

IEEE 1588v2 standardis kirjeldatud PTPv2 sünkroonimisprotokoll võimaldab saavutada sünkroniseerimise täpsust kuni mõne kümne nanosekundini. PTPv2 võimaldab saata sünkroonsed paketid L2 ja L3 võrkude kaudu.

PTPv2 peamised rakendusalad on:

energeetika;
kontroll- ja mõõteseadmed;
kaitse- ja tööstussektor;
telekommunikatsioon;
finantsteenused.

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

Meil on selles valdkonnas rohkem kogemusi ja me puutume sageli kokku selle protokolliga energeetika rakendustes. Seega teeme ülevaate, energeetika kontekstis..

Miks on see vajalik?

Praeguseks on PPA 'Rosseti' ja PPA 'FSK EES' dokumentides SТО 34.01-21-004-2019 ja SТО 56947007-29.240.10.302-2020 sätestatud nõuded protsessi busside korraldamiseks PTPv2 sünkroniseerimise ajaga.

See põhjustab selle, et protsessi bussile on ühendatud releekaitse terminalid ja mõõteseadmed, mis edastavad protsessi bussi kaudu, kasutades nn SV-vooge (multicast-voogude), koheseid vooluharu ja pingete väärtusi.

Releekaitse terminalid kasutavad neid väärtusi kaitsemehhanismide rakendamiseks. Kui mõõtmise täpsus ajas on väike, võivad mõned kaitsemehhanismid valehäireid anda.

Näiteks võivad «nõrga» ajasünkroniseerimise ohvriks olla absoluutse selektiivsuse kaitsed. Tihti põhineb selliste kaitsete loogika kahe suuruse võrdlemisel. Kui suurused erinevad piisavalt, siis kaitse käivitub. Kui neid suurusi mõõta ajata täpsusega 1 ms, võib ilmneda suur erinevus seal, kus väärtused tegelikult normaalsed, kui neid mõõta täpsusega 1 µs.

PTP versioonid

PTP protokoll kirjeldati esmakordselt 2002. aastal IEEE 1588-2002 standardis, mille nimi oli "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". 2008. aastal avaldati uuendatud standard IEEE 1588-2008, mis kirjeldab PTP versiooni 2. Selles protokolli versioonis on saavutatud parem täpsus ja stabiilsus, kuid tagasipööratav ühilduvus esimesega pole säilinud. Samuti avaldati 2019. aastal IEEE 1588-2019 versioon, mis kirjeldab PTP v2.1. See versioon toob PTPv2-le väikeseid parandusi ja on tagasipööratavalt ühilduv PTPv2-ga.

Teisisõnu, saame versioonide ülevaate:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

—
Ei ühildu

Ei ühildu

PTPv2 (IEEE 1588-2008)

Ei ühildu

—
Ühilduvad

PTPv2.1 (IEEE 1588-2019)

Ei ühildu

Ühilduvad

—

Kuid, nagu alati, on nüansse.

PTPv1 ja PTPv2 vahelise ühilduvuse puudumine tähendab, et seade, mis toetab PTPv1, ei saa sünkroniseerida täpsete kelladega, mis töötavad PTPv2 peal. Sünkroniseerimiseks kasutatakse erinevaid sõnumiformaate.

Kuid seadmete ühendamine PTPv1 ja PTPv2 vahel ühes võrgus on siiski võimalik. Selleks võimaldavad mõned tootjad piiripealsetel kelladel valida protokolli versiooni sadamates. See tähendab, et piiripealsed kellad saavad sünkroonida PTPv2 kaudu ja samal ajal sünkroonida teised nendega ühendatud kellad nii PTPv1 kui ka PTPv2 kaudu.

PTP seadmed. Milliseid neist on ja kuidas nad eristuvad?

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

Seadmed suhtlevad üksteisega läbi kohaliku võrgu, kasutades PTP-d.

PTP seadmeid nimetatakse kelladeks. Kõik kellad võtavad täpset aega suurmeistri kelladelt.

On olemas 5 kellatüüpi:

Grandmaster clock (Suurmeistri kell)

Peamine täpse aja allikas. Sageli on varustatud GPS-ühenduse liidesega.

Ordinary Clock (Tavaline kell)

Seade ühes portis, mis võib olla meister (peamine kell) või slave (järgnev kell)

Peamine kell (meister)

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

Järgnev kell (slave)

Lõppseade, mis sünkroonitakse peamistelt kelladelt.

Boundary Clock (Piiripealne kell)

Mitmeportiline seade, mis võib olla meister või ori.

See tähendab, et need kellad saavad sünkroniseerida kõrgemalt tasemelt tulenevaid kellasid ja sünkroniseerida allpool olevaid ori kellasid.

End-to-end läbipaistev kell (End-to-End läbipaistvad kellad)

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

Andmete edastamise ajal muudavad läbipaistvad kellad kõiki PTP sõnumeid.

Kohandamine toimub, lisades viivituse aja selle seadme korrektsiooniväljale edastatava sõnumi pealkirjas.

Peer-to-Peer läbipaistev kell (Peer-to-Peer läbipaistvad kellad)

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

Andmete edastamise ajal muudavad läbipaistvad kellad kõiki PTP sõnumeid Sync ja Follow_Up (neist räägitakse lähemalt allpool).

Kohandamine saavutatakse, lisades edastatava paketi korrektsiooniväljale saatva seadme viivitust ja edastuskanali viivitust.

Halduspunkt

Seade, mis konfigureerib ja diagnostiseerib teisi kelli

Juht- ja alluvat kellad sünkroniseeritakse ajatempleid kasutades PTP sõnumites. PTP protokollis on kaks tüüpi sõnumeid:

Event Messages – need on sünkroniseeritud sõnumid, mis eeldavad ajatempli genereerimist sõnumi saatmise ja vastuvõtmise hetkel
General Messages – need sõnumid ei nõua ajatempleid, kuid võivad sisaldada ajatempleid seotud sõnumite jaoks

Event Messages

General Messages

Sync
Delay_Req
Pdelay_Req
Pdelay_Resp

Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling

Järgnevalt käsitletakse kõiki sõnumite tüüpe üksikasjalikumalt.

Peamised sünkroniseerimise probleemid

Sünkroonimispaketi saatmisel kohaliku võrgu kaudu tekib viivitus lülitil ja edastuskanalis. Igal lülitil on viivitus umbes 10 μs, mis on PTPv2 jaoks vastuvõetamatu. Lõppseadmest on vajalik täpsus 1 μs. (See kehtib energia jaoks. Teised rakendused võivad nõuda veelgi suuremat täpsust.)

IEEE 1588v2-s on kirjeldatud mitmeid tööalgoritme, mis võimaldavad aja viivitust fikseerida ja kohandada.

Tööalgoritm
Normaalses töökorralduses töötleb protokoll kahes etapis.

Etapp 1 — hierarhia seadmine „Peajuhid - Juhitud kellad.”
Etapp 2 — kellade sünkroniseerimine End-to-End või Peer-to-Peer mehhanismi abil.

Etapp 1 — hierarhia seadmine „Master-Slave.”

Iga tavalise või piirikella port omab kindlat hulka olekuid (juhitud kellad ja peajuhid). Standard kirjeldab üleminekute algoritmi nende olekute vahel. Programmeerimises nimetatakse sedalaadi algoritmi lõppautomaatideks või oleku masinateks (täiendav info Wiki's).

See lõppautomaat kasutab parima meistrikella algoritmi (BMCA) meistri kokkuliitmiseks kahe kella vahel.

See algoritm võimaldab kelladel võtta endale suuremeistrite kellade kohustusi, kui ülemised suuremeistrite kellad kaotavad GPS-signaali, eemaldavad end võrgust jne.

Üleminekud olekute vahel vastavalt BMCA-le on lühidalt esitatud järgmises skeemis:

Teave kellede kohta, mis on „juhtme“ teises otsas, saadetakse spetsiaalses teadetes (Announce message). Kui see teave on saadud, käivitub olekumasina algoritm ja võrreldakse, millised kellad on paremad. Parimate kellade port saab juhtivate kelladeks.

Lihtne hierarhiat on esitatud alloleval skeemil. Teed 1, 2, 3, 4, 5 võivad sisaldada läbipaistvaid kellasid (Transparent clock), kuid need ei osale hierarhia seadistamises 'Juhtivad kellad – Alluvad kellad'.

Faasi 2 — Tavaliste ja piiride kellade sünkroniseerimine.

Otse pärast hieraaria seadistamist 'Juhtivad kellad – Alluvad kellad' algab tavaliste ja piiride kellade sünkroniseerimise faas.

Juhtivad kellad saadavad alluvatele kelladele sõnumi, mis sisaldab ajamärki.

Juhtivad kellad võivad olla:

üheastmelised;
kaheastmelised.

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

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

Sünkroniseerimise faasis võivad kasutada kahte mehhanismi:

Viivituse päringu-vastuse mehhanism (Delay request-response mechanism).
Naabri viivituse mõõtmise mehhanism (Peer delay measurement mechanism).

Alustuseks vaatame neid mehhanisme kõige lihtsamal juhul – kui läbipaistvaid tunde ei rakendata.

Viivitusetaotluse-mehhanism

Mehhanism hõlmab kahte sammu:

Viivituse mõõtmine sõnumi edastamisel juhtivalt kellalt alluvatele. Seda teostatakse viivitusetaotluse mehhanismi abil.
Toimub täpsete kellaaegade nihke korrigeerimine.

Viivituse mõõtmine

t1 – Sõnumi Sync saatmise aeg juhtivatelt kelladelt; t2 – Sõnumi Sync vastuvõtmise aeg alluvatelt kelladelt; t3 – Viivituse taotluse (Delay_Req) saatmise aeg alluvatelt kelladelt; t4 – Delay_Req vastuvõtmise aeg juhtivatelt kelladelt.

Kui alluvad kellad tunnevad aegu t1, t2, t3 ja t4, saavad nad arvutada keskmise viivituse sõnumi sünkroniseerimise edastamisel (tmpd). See arvutatakse järgmiselt:

Sõnumi Sync ja Follow_Up edastamisel arvutatakse aja viivitus meistrilt orjaks – t-ms.

Viivituse taotluse ja vastuse edastamisel arvutatakse aja viivitus orjalt meistrile – t-sm.

Kui nende kahe väärtuse vahel tekib mingi asümmeetri, ilmneb täpsete aegade korrigeerimise viga. Viga on tingitud sellest, et arvutatud viivitus on t-ms ja t-sm viivituste keskmine. Kui viivitused ei ole üksteisega võrreldavad, siis ei oska me aega täpselt korrigeerida.

Täpsete aegade nihke korrigeerimine

Pärast seda, kui viivitus pea- ja järgnevate kellade vahel on teada, korrigeerivad järgnevate kellade aega.

Järgnevate kellade aeg kasutab Sync-sõnumit ja valikulist Follow_Up sõnumit täpsete aegade nihke arvutamiseks paketi edastamisel juhtivate kellade poolt. Nihke arvutatakse järgmise valemi abil:

Naaberkõrvalise viivituse mõõtmise mehhanism

See mehhanism kasutab samuti kahte sammu sünkroonimiseks:

Seadmed mõõdavad aega kõigi naabritega kõigi portide kaudu. Selleks kasutavad nad peer delay mechanism.
Täpsete aegade nihke korrigeerimine.

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

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

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

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

Lõplik viivitus on võrdne viivituse summa, mis tuleneb edastamisest antud seadmest, keskmise viivituse kanalist ja juba olemasoleva viivitusega antud sõnumis, mis onitatud ülemistes seadmetes.

Pdelay_Req, Pdelay_Resp ja vabatahtlik Pdelay_Resp_Follow_Up sõnumid võimaldavad mõõta viivitust meistrist orja ja orjast meesteri, luues ringkäigu.

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

Täpse aja nihke korrigeerimine

Järeltunnid kasutavad Sync-sõnumit ja vabatahtlikku Follow_Up sõnumit täpse aja nihke arvutamiseks, kui pakett edastatakse juhtivate kellade poolt järeltundide juurde. Nihke arvutatakse järgmise valemi järgi:

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

Selle mehhanismi kasutamisel ei nõua aja sünkroniseerimine viivituse arvutamist, nagu toimub baasarkanalis. St. sõnumeid Delay_Req ja Delay_Resp ei saadeta. Selle meetodi puhul liidetakse viivitus peajõudude ja alamjõudude vahel lihtsalt iga Sync või Follow_Up sõnumi täienduspinkude väljal.

Veel üks eelis on see, et peajõud vabaneb Delay_Req sõnumite töötlemise vajadusest.

Läbipaistvate kellade töörežiimid

Seega oleme uurinud lihtsaid näiteid. Nüüd oletame, et sünkroniseerimise teele ilmuvad lülitid.

Kui kasutada lüliteid, mis ei toeta PTPv2, siis sünnituspakett viibib lülitis umbes 10 mikrosekundit.

PTPv2 toetavad lülitid IEEE 1588v2 terminoloogias nimetatakse läbipaistvateks kelladeks (Transparent clock). Läbipaistvad kellad ei sünkroniseeru juhtkelladega ega osale hierarhias 'Juhtkellad – Alluvad kellad', kuid need salvestavad, kui kaua sõnum viibis nendes, edastades sünkroonimise sõnumeid. See võimaldab ajaviivitust korrigeerida.

Läbipaistvad kellad saavad töötada kahes režiimis:

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

End-to-End (E2E)

Läbipaistvad E2E kellad edastavad Sync sõnumid ja seotud Follow_Up sõnumid kõigile portidele. Isegi neile, mis on blokeeritud mõne protokolli (nt RSTP) tõttu.

Lüliti salvestab ajamärgi, kui Sync (Follow_Up) pakett oli porti vastu võetud ja kui see saadeti portist välja. Nende kahe ajamärgi põhjal arvutatakse lüliti poolt sõnumi töötlemise aeg. Standardis nimetatakse seda aega residence time.

Töötlemise aeg lisatakse Sync sõnumi correctionField (ühe sammuga kellad) või Follow_Up (kahe sammuga kellad) väljale.

Läbipaistvad E2E kellaajad mõõdavad töötlemisaega Sync ja Delay_Req sõnumite jaoks, mis läbivad lülitit. Oluline on mõista, et edasiminek kellade ja järgneva kellaaja vahel arvutatakse viivituse päring- ja vastussüsteemi kaudu. Kui juhtivad kellad muutuvad või muutub tee juhtivatest kelladest järgnevatele kelladele, mõõdetakse viivitus uuesti. See pikendab ülemineku aega, kui võrgus on muudatusi.

Läbipaistvad P2P kellaajad, peale lüliti sõnumitöötlemise ajastuse mõõtmise, mõõdavad viivitust andmeedastuskanalil lähima naabri juurde, kasutades naaberkella viivituse mõõtmise mehhanismi.

Viivitus mõõdetakse igas suunas igas kanalis, sealhulgas kanalites, mis on mõne protokolli (nt RSTP) poolt blokeeritud. See võimaldab kohe arvutada uue ajaviivituse sünkroonimisteel, kui suurmeistrikellad või võrgu topoloogia on muutunud.

Sõnumite töötlemise ajad lülitites ja viivituse ajad akumuleeruvad Sync või Follow_Up sõnumite edastamisel.

PTPv2 turvatoed lülitites

Lülitid võivad toetada PTPv2:

tarkvara kaudu;
riistvara kaudu.

PTPv2 protokolli tarkvaralise rakendamise korral nõuab lüliti ajamärki püsivara käest. Probleem seisneb selles, et püsivara töötab tsükliliselt, mistõttu tuleb oodata, kuni see lõpetab käimasoleva tsükli, töötleb päringu ja järgmisel tsüklil väljastab ajamärgi. See võtab samuti aega, mis toob kaasa viivituse, kuigi mitte nii olulise kui ilma PTPv2 tarkvaratoeta.

Nõutava täpsuse saavutamiseks on vajalik ainult PTPv2 riistvara tugi. Sellisel juhul väljastatakse ajamärk spetsiaalse ASIC'i poolt, mis on paigaldatud 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

Header väli on kõigi PTP sõnumite puhul identne. Selle suurus on 34 baiti.

Header välja formaat:

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

messageLength – sisaldab PTP sõnumi kogumahtu, sh header, body ja suffix (kuid ilma täitebaiti).

domainNumber – määrab, kellele domaadi kuulub PTP sõnum.

Domeen – see on mitu erinevat kellaaega, mis on kokku koondatud ühte loogilisse gruppi ja sünkroniseeritud ühtede peamiste kelladega, kuid mitte tingimata sünkroniseeritud teiste domeeni kelladega.

lipud – see väli sisaldab erinevaid lippe sõnumi staatuse tuvastamiseks.

korrigeerimisväli – sisaldab viivitust nanosekundites. Viivitus hõlmab viivitust edastamisel läbi läbipaistvate kellade, samuti viivitust edastamisel kanali kaudu Peer-to-Peer režiimis.

allika sadama identiteet – see väli sisaldab teavet selle kohta, milliselt sadamalt see sõnum algselt saadeti.

järjekorra ID – sisaldab individuaalsete sõnumite identifitseerimisnumber.

kontrollväli – artefakt-väli=) See jäi esimesest versioonist ja sisaldab teavet selle sõnumi tüübi kohta. Sisuliselt sama, mis messageType, kuid vähemate valikute jaotustega.

logi sõnumi intervall – see väli määratakse sõnumi tüübi järgi.

Keha

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

Teade Announce
Announce sõnumit kasutatakse selleks, et "rääkida" teistele kelladele sama domeeni piires oma parameetritest. See sõnum võimaldab seadistada hierarhiat "Peamised kellad - Alluvat kellad".

Sync sõnum
Sünkroniseerimise (Sync) sõnum saadetakse peamistelt kelladelt ja sisaldab peamiste kellade aega hetkel, mil Sync sõnum loodi. Kui peamised kellad on kahetasandilised, siis sünnikella ajatempli väärtus seatakse 0-le ja tegelik ajatempli väärtus saadetakse kaasatud Follow_Up sõnumiga. Sync sõnumit kasutatakse mõlema viivituse mõõtmise mehhanismi puhul.

Sõnum saadetakse Multicast'i kaudu. Soovitatav on kasutada Unicast'i.

Delay_Req sõnum

Delay_Req sõnumi formaat on sarnane Sync sõnumiga. Alluvad kellad saadavad Delay_Req. See sisaldab alluva kellade saatmise aega Delay_Req. Seda sõnumit kasutatakse ainult viivituse päringu-vastuse mehhanismi jaoks.

Sõnum saadetakse Multicast'i kaudu. Soovitatav on kasutada Unicast'i.

Follow_Up sõnum

Follow_Up sõnum saadetakse kas peamistelt kelladelt ja sisaldab saatmise aega Sync sõnum peamees. Follow_Up sõnumit saadavad ainult kahetasandilised peamised kellad.

Follow_Up sõnumit kasutatakse mõlema viivituse mõõtmise mehhanismi jaoks.

Sõnum saadetakse Multicast'i kaudu. Soovitatav on kasutada Unicast'i.

Delay_Resp sõnum

Delay_Resp sõnum saadetakse peamistelt kelladelt. See sisaldab Delay_Req vastuvõtmise aega peamistelt kelladelt. Seda sõnumit kasutatakse ainult päring-vastus viivituse mehhanismi jaoks.

Sõnum saadetakse Multicast'i kaudu. Soovitatav on kasutada Unicast'i.

Pdelay_Req sõnum

Pdelay_Req sõnum saadetakse seadme poolt, mis küsib viivitust. See sisaldab selle seadme porti kaudu saadetud sõnumi saatmise aega. Pdelay_Req kasutatakse ainult naaberknoti viivituse mõõtmise mehhanismi jaoks.

Pdelay_Resp sõnum

Pdelay_Resp sõnum saadetakse seadme poolt, mis sai viivituse päringu. See sisaldab Pdelay_Req sõnumi vastuvõtmise aega selle seadme poolt. Pdelay_Resp sõnumit kasutatakse ainult naaberknoti viivituse mõõtmise mehhanismi jaoks.

Pdelay_Resp_Follow_Up sõnum

Pdelay_Resp_Follow_Up sõnum saadetakse valikuliselt seadme poolt, mis sai viivituse päringu. See sisaldab Pdelay_Req sõnumi vastuvõtmise aega selle seadme poolt. Pdelay_Resp_Follow_Up sõnum saadetakse ainult kaheastmeliste peamiste kellade poolt.

Seda sõnumit saab kasutada ka läbimise aja tähistamiseks ajatempli asemel. Läbimise aeg on aeg alates Pdelay-Req saamisest kuni Pdelay_Resp saatmiseni.

Pdelay_Resp_Follow_Up kasutatakse vaid naaberühe latentsuse mõõtmise mehhanismi jaoks.

Juhtimis sõnumid (Management Message)

PTP juhtimis sõnumid on vajalikud teabe edastamiseks ühe või mitme kella ja juhtnõlva vahel.

Edastamine LV-s

PTP sõnumit saab edastada kahel tasemel:

Võrgutasemel – osana IP-andmetest.
Kanalitasemel – osana Ethernet-i raamist.

PTP sõnumi edastamine UDP kaudu IP kaudu Etherneti

PTP UDP kaudu Etherneti

Profiilid

PTP-l on piisavalt palju „paindlikke“ parameetreid, mida tuleb seadistada. Näiteks:

BMCA valikud.
Latentsuse mõõtmise mehhanism.
Kõigi konfigureeritavate parameetrite intervallid ja algväärtused jne.

Kuigi me ütlesime varem, et PTPv2 seadmed on üksteisega ühilduvad, pole see päris tõsi. Seadmetel peavad olema samad seadistused, et nad saaksid omavahel suhelda.

Seetõttu on olemas nn PTPv2 profiilid. Profiilid on konfigureeritud seadete ja protokolli teatud piirangute rühmad, et võimaldada aja sünkroniseerimist konkreetse rakenduse jaoks.

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

Näiteks, energia jaotuse profiil ehk PTPv2 Power Profile loodi Power Systems Relaying Committee ja Substation Committee, mis kuuluvad IEEE Power and Energy Society alla. Profili nimi on IEEE C37.238-2011.

Profiil kirjeldab, et PTP-d võib edastada:

Ainult L2-võrkudes (st Ethernet, HSR, PRP, mitte IP).
Sõnumid edastatakse ainult Multicast-ülekandega.
Viivitusmehanismi mõõtmiseks kasutatakse Peer delay measurement mechanism.

Vaikimisi domeen on 0, soovitatav domeen on 93.

C37.238-2011 loomise filosoofias peitus soov vähendada valiklike omaduste arvu, säilitades ainult vajalikud funktsioonid seadmete usaldusväärseks suhtlemiseks ja süsteemi stabiilsuse suurendamiseks.

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

Valikute hulgas on põhjuslikult ainult üks parameeter – juhtivate kellade tüüp (üheastmelised või kaheastmelised).