A PTPv2 időszinkronizálási protokoll megvalósításának részletei

Bevezetés

A „Digitális Alállomás” építésének koncepciója a villamosenergia-iparban 1 μs pontosságú szinkronizálást igényel. A pénzügyi tranzakciókhoz mikroszekundumos pontosság is szükséges. Ezekben az alkalmazásokban az NTP időpontossága már nem elegendő.

Az IEEE 2v1588 szabvány által leírt PTPv2 szinkronizációs protokoll több tíz nanoszekundumos szinkronizálási pontosságot tesz lehetővé. A PTPv2 lehetővé teszi a szinkronizálási csomagok küldését L2 és L3 hálózatokon.

A PTPv2 használatának fő területei a következők:

• energia;
• ellenőrző és mérőberendezések;
• hadiipari komplexum;
• távközlés;
• pénzügyi szektor.

Ez a bejegyzés elmagyarázza a PTPv2 szinkronizálási protokoll működését.

Több tapasztalattal rendelkezünk az iparban, és gyakran találkozunk ezzel a protokollal az energetikai alkalmazásokban. Ennek megfelelően az áttekintést óvatosan fogjuk végezni energiáért.

Miért van rá szükség?

Jelenleg a PJSC Rosseti STO 34.01-21-004-2019 és a PJSC FGC UES STO 56947007-29.240.10.302-2020 követelményeket tartalmaz a PTPv2-n keresztüli időszinkronizálással rendelkező folyamatbusz megszervezésére.

Ez annak köszönhető, hogy a folyamatbuszra relévédelmi terminálok és mérőeszközök csatlakoznak, amelyek a folyamatbuszon keresztül a pillanatnyi áram- és feszültségértékeket úgynevezett SV-folyamok (multicast stream) segítségével továbbítják.

A relévédelmi terminálok ezeket az értékeket használják a relévédelem megvalósításához. Ha az időmérés pontossága kicsi, akkor egyes védelmek hibásan működhetnek.

Például az abszolút szelektivitás védelme áldozatul eshet a „gyenge” időszinkronizálásnak. Az ilyen védekezések logikája gyakran két mennyiség összehasonlításán alapul. Ha az értékek kellően nagy értékkel térnek el, akkor a védelem aktiválódik. Ha ezeket az értékeket 1 ms-os időpontossággal mérjük, akkor 1 μs-os pontossággal mérve nagy különbséget kaphatunk, ahol az értékek ténylegesen normálisak.

PTP verziók

A PTP protokollt eredetileg 2002-ben írták le az IEEE 1588-2002 szabványban, és „Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems”-nek nevezték. 2008-ban megjelent a frissített IEEE 1588-2008 szabvány, amely a PTP 2-es verzióját írja le. A protokoll ezen verziója javította a pontosságot és a stabilitást, de nem tartotta meg a visszamenőleges kompatibilitást a protokoll első verziójával. Ezenkívül 2019-ben megjelent az IEEE 1588-2019 szabvány verziója, amely a PTP v2.1-et írja le. Ez a verzió kisebb fejlesztéseket ad a PTPv2-höz, és visszafelé kompatibilis a PTPv2-vel.

Más szóval, a következő képünk van a verziókkal:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

-
következetlen

következetlen

PTPv2 (IEEE 1588-2008)

következetlen

-
összeegyeztethető

PTPv2.1 (IEEE 1588-2019)

következetlen

összeegyeztethető

-

De mint mindig, most is vannak árnyalatok.

A PTPv1 és a PTPv2 közötti inkompatibilitás azt jelenti, hogy a PTPv1-kompatibilis eszköz nem lesz képes szinkronizálni a PTPv2-n futó pontos órával. Különféle üzenetformátumokat használnak a szinkronizáláshoz.

De továbbra is lehetséges a PTPv1-vel rendelkező eszközök és a PTPv2-vel rendelkező eszközök kombinálása ugyanazon a hálózaton. Ennek elérése érdekében egyes gyártók lehetővé teszik a protokollverzió kiválasztását a peremóra-portokon. Vagyis egy határóra képes szinkronizálni a PTPv2 használatával, és továbbra is szinkronizálni tudja a hozzá csatlakoztatott többi órát mind a PTPv1, mind a PTPv2 használatával.

PTP eszközök. Mik ezek és miben különböznek?

Az IEEE 1588v2 szabvány többféle eszközt ír le. A táblázatban mindegyik látható.

Az eszközök LAN-on keresztül PTP-n keresztül kommunikálnak egymással.

A PTP-eszközöket óráknak nevezzük. Minden óra pontos időt vesz a nagymesteri órától.

5 féle óra létezik:

Nagymester óra

A pontos idő fő forrása. Gyakran fel van szerelve interfésszel a GPS csatlakoztatásához.

Közönséges óra

Egy portos eszköz, amely lehet mester (mester óra) vagy slave (szolga óra)

Mester óra (mester)

Ezek a források a pontos időnek, amellyel más órákat szinkronizálnak

Rabszolga óra

A fő órával szinkronizált végkészülék

Határ Óra

Több porttal rendelkező eszköz, amely lehet master vagy slave.

Ez azt jelenti, hogy ezek az órák szinkronizálhatnak a felsőbbrendű mesterórával, és szinkronizálhatják az alsóbbrendű szolgaórákat.

Végtől-végig átlátszó óra

Több porttal rendelkező eszköz, amely nem mesteróra és nem szolgaóra. PTP adatokat továbbít két óra között.

Adatátvitelkor az átlátszó óra minden PTP üzenetet kijavít.

A korrekció úgy történik, hogy az eszköz késleltetési idejét hozzáadjuk a továbbított üzenet fejlécében található javítási mezőhöz.

Peer-to-peer átlátszó óra

Több porttal rendelkező eszköz, amely nem mesteróra és nem szolgaóra.
PTP adatokat továbbít két óra között.

Adatátvitelkor az átlátszó óra korrigálja az összes Sync és Follow_Up PTP üzenetet (erről bővebben lentebb).

A korrekciót úgy érjük el, hogy az átvitt csomag korrekciós mezőjéhez hozzáadjuk az adóeszköz késleltetését és az adatátviteli csatorna késleltetését.

Menedzsment csomópont

Egy eszköz, amely más órákat konfigurál és diagnosztizál

A mester és a szolga órákat a PTP üzenetekben lévő időbélyegek segítségével szinkronizálják. A PTP protokollban kétféle üzenet található:

• Az eseményüzenetek olyan szinkronizált üzenetek, amelyek az üzenet küldésekor és fogadásakor időbélyeget generálnak.
• Általános üzenetek – Ezek az üzenetek nem igényelnek időbélyeget, de tartalmazhatnak időbélyeget a kapcsolódó üzenetekhez

Esemény üzenetek

Általános üzenetek

Szinkronizálás
Delay_Req
Pdelay_Req
Pdelay_Resp

bejelent
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Támogató
Jelzés

Az alábbiakban minden típusú üzenetről részletesebben lesz szó.

Alapvető szinkronizálási problémák

Ha egy szinkronizációs csomagot egy helyi hálózaton keresztül továbbítanak, az késleltetett a kapcsolónál és az adatkapcsolaton. Bármely kapcsoló körülbelül 10 mikroszekundumos késést produkál, ami elfogadhatatlan a PTPv2 esetében. Végül is 1 μs-os pontosságot kell elérnünk a végső eszközön. (Ez akkor van, ha az energiáról beszélünk. Más alkalmazások nagyobb pontosságot igényelhetnek.)

Az IEEE 1588v2 számos olyan működési algoritmust ír le, amelyek lehetővé teszik az időkésleltetés rögzítését és javítását.

A munka algoritmusa
Normál működés közben a protokoll két fázisban működik.

• 1. fázis – a „Master Clock – Slave Clock” hierarchia létrehozása.
• 2. fázis - óra ​​szinkronizálás végponttól végpontig vagy egyenrangú mechanizmussal.

1. fázis – A mester-szolga hierarchia felállítása

A normál vagy szélső óra minden portja bizonyos számú állapottal rendelkezik (szolga óra és mester óra). A szabvány leírja az ezen állapotok közötti átmenet algoritmust. A programozásban az ilyen algoritmust véges állapotú gépnek vagy állapotgépnek nevezik (további részletek a Wikiben).

Ez az állapotgép a Best Master Clock Algorithm (BMCA) segítségével állítja be a mastert két óra összekapcsolásakor.

Ez az algoritmus lehetővé teszi, hogy az óra átvegye a nagymesteri óra feladatait, ha a felfelé irányuló nagymesteri óra elveszti a GPS-jelet, offline állapotba kerül stb.

A BMCA szerinti állapotátmeneteket a következő diagram foglalja össze:


A „huzal” másik végén lévő órával kapcsolatos információkat speciális üzenetben küldik el (Üzenet bejelentése). Miután megkapta ezt az információt, az állapotgép algoritmusa lefut, és összehasonlításra kerül, hogy melyik óra jobb. A legjobb óra portja lesz a főóra.

Az alábbi diagramon egy egyszerű hierarchia látható. Az 1, 2, 3, 4, 5 útvonalak tartalmazhatnak átlátszó órát, de nem vesznek részt a Master Clock - Slave Clock hierarchia létrehozásában.

2. fázis - Szinkronizálja a normál és az élórákat

Közvetlenül a „Master Clock – Slave Clock” hierarchia felállítása után megkezdődik a szabályos és a határórák szinkronizálási fázisa.

A szinkronizáláshoz a mester óra időbélyeget tartalmazó üzenetet küld a szolga óráknak.

A fő óra lehet:

• egylépcsős;
• kétlépcsős.

Az egyfokozatú órák egy szinkronizálási üzenetet küldenek a szinkronizáláshoz.

A kétfokozatú óra két üzenetet használ a szinkronizáláshoz - Sync és Follow_Up.

A szinkronizálási fázishoz két mechanizmus használható:

• Késleltetett kérés-válasz mechanizmus.
• Peer késleltetés mérési mechanizmus.

Először is nézzük meg ezeket a mechanizmusokat a legegyszerűbb esetben - amikor nem használnak átlátszó órákat.

Késleltetett kérés-válasz mechanizmus

A mechanizmus két lépésből áll:

1. A mester óra és a szolga óra közötti üzenetátvitel késleltetésének mérése. Késleltetett kérés-válasz mechanizmussal hajtják végre.
2. Megtörténik a pontos időeltolás korrekciója.

Latencia mérése


t1 – A szinkronizálási üzenet elküldésének ideje a főóra által; t2 – A Sync üzenet szolga óra általi fogadásának ideje; t3 – A késleltetési kérelem (Delay_Req) ​​elküldésének ideje a slave óra által; t4 – Delay_Req vételi idő a master óra által.

Ha a slave óra ismeri a t1, t2, t3 és t4 időket, ki tudja számítani az átlagos késleltetést a szinkronizációs üzenet (tmpd) ​​továbbításakor. Kiszámítása a következőképpen történik:

Sync és Follow_Up üzenet küldésekor a rendszer kiszámítja a mastertől a slaveig tartó késleltetést - t-ms.

A Delay_Req és Delay_Resp üzenetek továbbításakor a szolga és a master közötti késleltetés kiszámítása - t-sm.

Ha a két érték között némi aszimmetria lép fel, akkor hiba lép fel a pontos idő eltérésének korrigálásakor. A hibát az okozza, hogy a számított késleltetés a t-ms és t-sm késések átlaga. Ha a késések nem egyenlőek egymással, akkor nem állítjuk be pontosan az időt.

Időeltolás korrekciója

Amint a mester óra és a szolga óra közötti késleltetés ismert, a szolga óra időkorrekciót hajt végre.

A slave órák a Sync üzenetet és az opcionális Follow_Up üzenetet használják a pontos időeltolás kiszámításához, amikor egy csomagot továbbítanak a mestertől a szolga órákhoz. Az eltolódást a következő képlet segítségével számítjuk ki:

Peer késleltetés mérési mechanizmus

Ez a mechanizmus két lépést is használ a szinkronizáláshoz:

1. Az eszközök mérik a késleltetést az összes szomszédhoz az összes porton keresztül. Ehhez peer késleltetési mechanizmust használnak.
2. A pontos időeltolás korrekciója.

A Peer-to-Peer módot támogató eszközök késésének mérése

A peer-to-peer mechanizmust támogató portok közötti késleltetés mérése a következő üzenetekkel történik:

Ha az 1. port ismeri a t1, t2, t3 és t4 időket, ki tudja számítani az átlagos késleltetést (tmld). Kiszámítása a következő képlettel történik:

A port ezután ezt az értéket használja az eszközön áthaladó minden egyes szinkronizálási üzenet vagy opcionális Follow_Up üzenet beállítási mezőjének kiszámításakor.

A teljes késleltetés megegyezik az ezen az eszközön keresztüli átviteli késleltetés, az adatcsatornán keresztüli átvitel közbeni átlagos késleltetés és az üzenetben már szereplő késleltetés összegével, amely engedélyezve van az upstream eszközökön.

A Pdelay_Req, Pdelay_Resp és az opcionális Pdelay_Resp_Follow_Up üzenetek lehetővé teszik a késleltetés lekérését mestertől szolgáig és szolgától masterig (kör alakú).

A két érték közötti bármilyen aszimmetria időeltolás korrekciós hibát okoz.

A pontos időeltolás beállítása

A slave órák egy Sync üzenetet és egy opcionális Follow_Up üzenetet használnak a pontos időeltolás kiszámításához, amikor egy csomagot továbbítanak a mastertől a slave órákhoz. Az eltolódást a következő képlet segítségével számítjuk ki:

A peer-to-peer mechanizmus beállításának előnyei – minden Sync vagy Follow_Up üzenet időkésleltetése a hálózaton történő továbbításkor kerül kiszámításra. Következésképpen az átviteli útvonal megváltoztatása semmilyen módon nem befolyásolja a beállítás pontosságát.

Ennek a mechanizmusnak a használatakor az időszinkronizálás nem igényli az időkésleltetés kiszámítását a szinkronizálási csomag által bejárt útvonalon, ahogy az az alapcserénél történik. Azok. A Delay_Req és Delay_Resp üzenetek nem kerülnek elküldésre. Ennél a módszernél a mester és a szolga óra közötti késleltetés egyszerűen összeadódik az egyes Sync vagy Follow_Up üzenetek beállítási mezőjében.

Egy másik előny, hogy a mesteróra mentesül a Delay_Req üzenetek feldolgozásának szükségességétől.

Átlátszó órák működési módjai

Ennek megfelelően ezek egyszerű példák voltak. Most tegyük fel, hogy kapcsolók jelennek meg a szinkronizálási útvonalon.

Ha PTPv2 támogatás nélküli switcheket használ, a szinkronizálási csomag körülbelül 10 µs-kal késik a kapcsolón.

A PTPv2-t támogató kapcsolókat az IEEE 1588v2 terminológiájában átlátszó óráknak nevezik. Az átlátszó órák nem szinkronizálódnak a mester órától, és nem vesznek részt a „Master Clock - Slave Clock” hierarchiában, de a szinkronizálási üzenetek továbbításakor emlékeznek arra, hogy mennyi ideig késleltették az üzenetet. Ez lehetővé teszi az időkésleltetés beállítását.

Az átlátszó órák két üzemmódban működhetnek:

• Végtől végig.
• Ponttól-pontig.

Végpontok (E2E)

Az E2E transzparens óra Sync üzeneteket és a kísérő Follow_Up üzeneteket sugározza az összes porton. Még azokat is, amelyeket bizonyos protokollok (például RSTP) blokkolnak.

A kapcsoló megjegyzi az időbélyeget, amikor szinkronizálási csomag (Follow_Up) érkezett a porton, és mikor küldték el a portról. E két időbélyeg alapján számítják ki azt az időt, amely alatt a kapcsoló feldolgozza az üzenetet. A szabványban ezt az időt tartózkodási időnek nevezik.

A feldolgozási idő hozzáadódik a Sync (egylépcsős óra) vagy Follow_Up (kétlépcsős óra) üzenet korrekciós mezőjéhez.

Az E2E transzparens óra a kapcsolón áthaladó Sync és Delay_Req üzenetek feldolgozási idejét méri. Fontos azonban megérteni, hogy a mester óra és a szolga óra közötti késleltetést a késleltetési kérés-válasz mechanizmus segítségével számítják ki. Ha a mester óra megváltozik, vagy a mester óra és a szolga óra közötti út megváltozik, a késleltetés újra megméri. Ez megnöveli az átállási időt hálózati változások esetén.

A P2P transzparens óra amellett, hogy méri azt az időt, amely alatt egy kapcsoló egy üzenetet feldolgoz, méri a legközelebbi szomszédhoz tartó adatkapcsolat késleltetését egy szomszéd késleltetési mechanizmus segítségével.

A késleltetést a rendszer minden hivatkozáson mindkét irányban méri, beleértve azokat a hivatkozásokat is, amelyeket valamilyen protokoll (például RSTP) blokkol. Ez lehetővé teszi, hogy azonnal kiszámítsa az új késleltetést a szinkronizálási útvonalon, ha a nagymester óra vagy a hálózati topológia megváltozik.

A kapcsolók általi üzenetfeldolgozási idő és a várakozási idő a Sync vagy Follow_Up üzenetek küldésekor halmozódik fel.

A PTPv2-támogatás típusai kapcsolókkal

A kapcsolók támogathatják a PTPv2-t:

• programozottan;
• hardver.

A PTPv2 protokoll szoftverben való implementálásakor a kapcsoló időbélyeget kér a firmware-től. A probléma az, hogy a firmware ciklikusan működik, és meg kell várnia, amíg befejezi az aktuális ciklust, elfogadja a feldolgozási kérelmet, és a következő ciklus után időbélyeget ad ki. Ez is időt vesz igénybe, és késést kapunk, bár nem olyan jelentős, mint a PTPv2 szoftveres támogatása nélkül.

Csak a PTPv2 hardveres támogatása teszi lehetővé a szükséges pontosság fenntartását. Ebben az esetben az időbélyeget egy speciális ASIC adja ki, amely a portra van telepítve.

Üzenet formátuma

Minden PTP üzenet a következő mezőket tartalmazza:

• Fejléc – 34 bájt.
• Törzs – a méret az üzenet típusától függ.
• Az utótag nem kötelező.

Fejléc

A Fejléc mező minden PTP-üzenetnél azonos. A mérete 34 bájt.

Fejléc mező formátuma:

üzenetTípus – tartalmazza a továbbított üzenet típusát, például Sync, Delay_Req, PDelay_Req stb.

üzenethossz – tartalmazza a PTP-üzenet teljes méretét, beleértve a fejlécet, a törzset és az utótagot (de nem tartalmazza a kitöltési bájtokat).

domainNumber – meghatározza, hogy az üzenet melyik PTP tartományhoz tartozik.

Домен - Ez több különböző óra egy logikai csoportba gyűjtve, és egy mesterórával szinkronizálva, de nem feltétlenül szinkronizálva egy másik tartományhoz tartozó órákkal.

zászlók – Ez a mező különféle zászlókat tartalmaz az üzenet állapotának azonosítására.

korrekcióMező – tartalmazza a késleltetési időt nanoszekundumban. A késleltetési idő magában foglalja a transzparens órajel átvitelének késleltetését, valamint a csatornán keresztüli átvitel késleltetését Peer-to-Peer mód használata esetén.

sourcePortIdentity – ez a mező azt tartalmazza, hogy az üzenet eredetileg melyik portról érkezett.

szekvenciaazonosító – azonosító számot tartalmaz az egyes üzenetekhez.

controlField – műtermékmező =) A szabvány első verziójából maradt meg, és az üzenet típusára vonatkozó információkat tartalmaz. Lényegében ugyanaz, mint a messageType, de kevesebb opcióval.

logMessageInterval – ezt a mezőt az üzenet típusa határozza meg.

Test

Mint fentebb tárgyaltuk, többféle üzenet létezik. Ezeket a típusokat az alábbiakban ismertetjük:

Bejelentés üzenet
Az Announce üzenetet arra használjuk, hogy az ugyanazon a tartományon belüli többi órát „megmondja” a paramétereiről. Ez az üzenet lehetővé teszi a Master Clock - Slave Clock hierarchia beállítását.


Üzenetszinkronizálás
A szinkronizálási üzenetet a mesteróra küldi, és tartalmazza a mester óra idejét a szinkronizálási üzenet generálásának időpontjában. Ha a fő óra kétfokozatú, akkor a szinkronizálási üzenet időbélyege 0 lesz, és az aktuális időbélyeg a kapcsolódó Follow_Up üzenetben kerül elküldésre. A Sync üzenet mindkét késleltetésmérési mechanizmushoz használatos.

Az üzenet továbbítása Multicast használatával történik. Opcionálisan használhatja az Unicastot.

Delay_Req üzenet

A Delay_Req üzenet formátuma megegyezik a Sync üzenetével. A slave óra küldi a Delay_Req. Tartalmazza azt az időt, amikor a Delay_Req-t a slave óra elküldte. Ez az üzenet csak a késleltetési kérés-válasz mechanizmushoz használatos.

Az üzenet továbbítása Multicast használatával történik. Opcionálisan használhatja az Unicastot.

Follow_Up üzenet

A Follow_Up üzenetet opcionálisan a mesteróra küldi, és tartalmazza a küldés időpontját Üzenetek szinkronizálása fő. Csak kétlépcsős mesterórák küldik a Follow_Up üzenetet.

A Follow_Up üzenet mindkét késleltetésmérési mechanizmushoz használatos.

Az üzenet továbbítása Multicast használatával történik. Opcionálisan használhatja az Unicastot.

Delay_Resp üzenet

A Delay_Resp üzenetet a mesteróra küldi. Tartalmazza azt az időt, amikor a Delay_Req-t a mesteróra fogadta. Ez az üzenet csak a késleltetési kérés-válasz mechanizmushoz használatos.

Az üzenet továbbítása Multicast használatával történik. Opcionálisan használhatja az Unicastot.

Pdelay_Req üzenet

A Pdelay_Req üzenetet egy késleltetést kérő eszköz küldi. Ez tartalmazza az üzenet küldésének időpontját az eszköz portjáról. A Pdelay_Req csak a szomszédos késleltetés mérési mechanizmushoz használatos.

Pdelay_Resp üzenet

A Pdelay_Resp üzenetet egy olyan eszköz küldi el, amely késleltetési kérést kapott. Azt az időpontot tartalmazza, amikor a Pdelay_Req üzenetet ez az eszköz megkapta. A Pdelay_Resp üzenet csak a szomszédos késleltetés mérési mechanizmushoz használatos.

Üzenet Pdelay_Resp_Follow_Up

A Pdelay_Resp_Follow_Up üzenetet opcionálisan a késleltetési kérelmet fogadó eszköz küldi el. Azt az időpontot tartalmazza, amikor a Pdelay_Req üzenetet ez az eszköz megkapta. A Pdelay_Resp_Follow_Up üzenetet csak kétlépcsős mesterórák küldik.

Ez az üzenet időbélyeg helyett végrehajtási időre is használható. A végrehajtási idő a Pdelay-Req vételétől a Pdelay_Resp elküldéséig eltelt idő.

A Pdelay_Resp_Follow_Up csak a szomszédos késleltetés mérési mechanizmushoz használatos.

Menedzsment üzenetek

PTP vezérlőüzenetekre van szükség ahhoz, hogy egy vagy több órajel és a vezérlő csomópont között információt továbbítsanak.

Transzfer LV-be

A PTP üzenet két szinten továbbítható:

• Hálózat – az IP adatok részeként.
• Csatorna – Ethernet keret részeként.

PTP üzenetátvitel UDP-n keresztül IP-n keresztül Etherneten keresztül

PTP UDP felett Etherneten keresztül

Profilok

A PTP meglehetősen sok rugalmas paraméterrel rendelkezik, amelyeket konfigurálni kell. Például:

• BMCA opciók.
• Latencia mérési mechanizmus.
• Az összes konfigurálható paraméter intervallumai és kezdeti értékei stb.

És annak ellenére, hogy korábban azt mondtuk, hogy a PTPv2 eszközök kompatibilisek egymással, ez nem igaz. Az eszközöknek azonos beállításokkal kell rendelkezniük a kommunikációhoz.

Ezért vannak úgynevezett PTPv2 profilok. A profilok konfigurált beállítások és protokollkorlátozások csoportjai, így az időszinkronizálás megvalósítható egy adott alkalmazáshoz.

Maga az IEEE 1588v2 szabvány csak egy profilt ír le – az „Alapértelmezett profilt”. Az összes többi profilt különböző szervezetek és egyesületek hozzák létre és írják le.

Például a Power Profile-t vagy a PTPv2 Power Profile-t az IEEE Power and Energy Society Power Systems Relaying Committee és Substation Committee hozta létre. Maga a profil neve IEEE C37.238-2011.

A profil leírja, hogy a PTP átvihető:

• Csak L2 hálózatokon keresztül (azaz Ethernet, HSR, PRP, nem IP).
• Az üzenetek továbbítása csak Multicast broadcast útján történik.
• A peer késleltetés mérési mechanizmus késleltetés mérési mechanizmusként használatos.

Az alapértelmezett domain a 0, az ajánlott domain a 93.

A C37.238-2011 tervezési filozófiája az volt, hogy csökkentse az opcionális funkciók számát, és csak az eszközök közötti megbízható interakcióhoz és a rendszer stabilitásának növeléséhez szükséges funkciókat tartsa meg.

Az üzenetküldés gyakoriságát is meghatározzák:

Valójában csak egy paraméter választható - a mesteróra típusa (egyfokozatú vagy kétfokozatú).

A pontosság nem lehet több 1 μs-nál. Más szavakkal, egy szinkronizálási útvonal legfeljebb 15 transzparens órát vagy három határórát tartalmazhat.

Forrás: will.com