Úvod
Koncepcia budovania „Digitálnej podsubstanice“ v elektroenergetike vyžaduje synchronizáciu s presnosťou 1 μs. Na vykonávanie finančných transakcií je taktiež potrebná presnosť v μs. V týchto aplikáciách už presnosť času NTP nestačí.
Protokol synchronizácie PTPv2, popísaný štandardom IEEE 1588v2, umožňuje dosiahnuť presnosť synchronizácie v niekoľkých desiatkach nanosekúnd. PTPv2 umožňuje posielať synchronizačné pakety cez L2 a L3 siete.
Hlavnými oblasťami, kde sa PTPv2 používa, sú:
- energetika;
- meracie a kontrolné zariadenia;
- obranný a priemyselný komplex;
- telekomunikácie;
- finančný sektor.
V tomto príspevku sa zaoberáme tým, ako funguje protokol synchronizácie PTPv2.
Máme viac skúseností v priemysle a často sa stretávame s týmto protokolom v energetických aplikáciách. Preto aj prehľad vypracujeme s ohľadom na energetiku. .
Prečo je potrebný?
V súčasnosti obsahujú STQ 34.01-21-004-2019 PJSC „Rosseti“ a STQ 56947007-29.240.10.302-2020 PJSC „FSK EES“ požiadavky na organizáciu procesu zberu údajov so zabezpečením synchronizácie času podľa PTPv2.
Je to spôsobené tým, že k procesnej zbernici sú pripojené terminály reléovej ochrany a meracie zariadenia, ktoré prostredníctvom procesnej zbernice, pomocou tzv. SV-prúdov (multicast prúdy), prenášajú okamžité hodnoty prúdu a napätia.
Terminály reléovej ochrany využívajú tieto hodnoty na realizáciu ochrany pripojení. Ak bude presnosť meraní v čase nízka, niektoré ochrany môžu falošne reagovať.
Napríklad obeťou „slabej“ synchronizácie času môžu byť ochrany absolútnej selektivity. Často sa logika takýchto ochrán zakladá na porovnaní dvoch hodnôt. Ak sa hodnoty značne líšia, ochrana sa aktivuje. Ak sa tieto hodnoty zmerajú s presnosťou 1 ms, môžu sa získať veľké rozdiely tam, kde sú hodnoty v skutočnosti normálne, ak by sa merali s presnosťou 1 μs.
Verzie PTP
Protokol PTP bol pôvodne opísaný v roku 2002 v štandarde IEEE 1588-2002 a jeho názov bol „Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems“. V roku 2008 bol vydaný aktualizovaný štandard IEEE 1588-2008, ktorý popisuje PTP verzia 2. V tejto verzii protokolu bola vylepšená presnosť a stabilita, ale nebola zachovaná spätná kompatibilita s prvou verziou protokolu. Taktiež, v roku 2019 vyšla verzia štandardu IEEE 1588-2019, popisujúca PTP v2.1. Táto verzia pridáva malé vylepšenia k PTPv2 a je spätne kompatibilná s PTPv2.
Inými slovami, máme nasledujúci prehľad verzií:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
—
Nezlučiteľné
Nezlučiteľné
PTPv2 (IEEE 1588-2008)
Nezlučiteľné
—
Zlučiteľné
PTPv2.1 (IEEE 1588-2019)
Nezlučiteľné
Zlučiteľné
—
Ale, ako vždy, existujú nuansy.
Nezlučiteľnosť medzi PTPv1 a PTPv2 predpokladá, že zariadenie s podporou PTPv1 sa nebude môcť synchronizovať s presnými hodinami, ktoré pracujú na PTPv2. Na synchronizáciu používajú rôzne formáty správ.
Ale skombinovať zariadenia s PTPv1 a zariadenia s PTPv2 v jednej sieti je predsa možné. Na to niektorí výrobcovia umožňujú na portoch hraničných hodín vyberať verziu protokolu. To znamená, že hraničné hodiny sa môžu synchronizovať cez PTPv2 a pritom synchronizovať iné pripojené hodiny aj cez PTPv1 a PTPv2.
Zariadenia PTP. Aké existujú a čím sa líšia?
Štandard IEEE 1588v2 popisuje niekoľko typov zariadení. Všetky sú uvedené v tabuľke.
Zariadenia komunikujú medzi sebou prostredníctvom LAN pomocou PTP.
Zariadenia PTP sa nazývajú hodiny. Všetky hodiny berú presný čas z grandmaster hodin.
Existuje 5 typov hodín:
Grandmaster clock (Grandmaster hodiny)
Hlavný zdroj presného času. Často sú vybavené rozhraním na pripojenie GPS.
Ordinary Clock (Obyčajné hodiny)
Zariadenie s jedným portom, ktoré môže byť majstrom (vedúcimi hodinami) alebo slávom (podriadenými hodinami).
Vedúce hodiny (majster)
Sú zdrojom presného času, podľa ktorého sa synchronizujú iné hodiny.
Podriadené hodiny (sláv)
Konečné zariadenie, ktoré sa synchronizuje s vedúcimi hodinami.
Boundary Clock (Hraničné hodiny)
Zariadenie s viacerými portami, ktoré môže byť majstrom alebo slávom.
To znamená, že tieto hodiny sa môžu synchronizovať s vyššími vedúcimi hodinami a naviac synchronizovať nižšie podriadené hodiny.
End-to-End Transparent Clock (Průhledné hodiny fungující v režimu End-to-End)
Zařízení s několika porty, které není ani vedoucími hodinami, ani hodinami sledovacími. Přenáší data PTP mezi dvěma hodinami.
Při přenosu dat průhledné hodiny opravují všechna PTP zprávy.
Oprava probíhá přidáním zpoždění času na tomto zařízení do pole korekce v hlavičce přenášené zprávy.
Peer-to-Peer Transparent Clock (Průhledné hodiny fungující v režimu Peer-to-Peer)
Zařízení s několika porty, které není ani vedoucími hodinami, ani hodinami sledovacími.
Přenáší data PTP mezi dvěma hodinami.
Při přenosu dat průhledné hodiny opravují všechny PTP zprávy Sync a Follow_Up (o nichž bude níže více informací).
Oprava se dosahuje přidáním zpoždění do pole korekce přenášeného paketu na přenášejícím zařízení a zpoždění na kanálu přenosu dat.
Management Node (Řídicí uzel)
Zařízení, které konfiguruje a diagnostikuje jiné hodiny.
Vedoucí a sledovací hodiny se synchronizují pomocí časových značek v PTP zprávách. Existují dva typy zpráv v PTP protokolu:
- Event Messages – to jsou synchronizované zprávy, které předpokládají generaci časové značky v okamžiku odeslání zprávy a v okamžiku jejího přijetí.
- General Messages – tyto zprávy nevyžadují časové značky, ale mohou obsahovat časové značky pro související zprávy.
Event Messages
General Messages
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling
Dále budou diskutovány všechny typy zpráv podrobněji.
Hlavní problémy synchronizace
Při přenosu synchronizačního paketu přes místní síť se zpožďuje na přepínači a v kanálu přenosu dat. Každý přepínač bude mít zpoždění kolem 10 μs, což je nepřijatelné pro PTPv2. Na koncovém zařízení potřebujeme dosáhnout přesnosti 1 μs. (Pokud jde o energetiku. Jiná aplikace mohou vyžadovat i větší přesnost.)
V IEEE 1588v2 je popsáno několik algoritmů, které umožňují zaznamenat časové zpoždění a opravit jej.
Algoritmus práce
Při normálním provozu protokol funguje ve dvou fázích.
- Fáze 1 — nastavení hierarchie 'Vedoucí hodiny – Sledovací hodiny'.
- Fáze 2 — synchronizace hodin pomocí mechanismu End-to-End nebo Peer-to-Peer.
Fáza 1 — Nastavenie hierarchie „Master-Slave“
Každý port obyčajných alebo hraničných hodín má určité množstvo stavov (vedúce hodiny a nasledujúce hodiny). Štandard opisuje algoritmus prechodu medzi týmito stavmi. V programovaní sa takýto algoritmus nazýva konečný automat alebo stavový stroj (viac v Wiki).
Tento konečný automat používa algoritmus Najlepší hodiny Master Clock Algorithm (BMCA) na určenie vedúceho pri pripojení dvoch hodín.
Tento algoritmus umožňuje hodinám prebrať záväzky majstrovských hodín, keď nadriadené majstrovské hodiny strata signálu GPS, odpojili sa od siete atď.
Prechody medzi stavmi podľa BMCA sú stručne zobrazené na nasledujúcom schéme:
Informácie o hodinách na druhom konci „kábla“ sú posielané v špeciálnej správe (Announce message). Keď sú tieto informácie prijaté, algoritmus stavu stroja spracováva a vykonáva porovnanie, ktoré hodiny sú lepšie. Port na najlepších hodinách sa stáva vedúcimi hodinami.
Jednoduchá hierarchia je zobrazená na schéme nižšie. Cesty 1, 2, 3, 4, 5 môžu obsahovať transparentné hodiny (Transparent clock), ale nezúčastňujú sa na ustanovení hierarchie „Vedúce hodiny – Nasledujúce hodiny“.
Fáza 2 — Synchronizácia obyčajných a hraničných hodín
Ihneď po nastavení hierarchie „Vedúce hodiny – Nasledujúce hodiny“ začína fáza synchronizácie obyčajných a hraničných hodín.
Na synchronizáciu vedúce hodiny posielajú nasledujúcim hodinám správu obsahujúcu časovú pečiatku.
Vedúce hodiny môžu byť:
- jednostupňové;
- dvochstupňové.
Jednostupňové hodiny pre synchronizáciu posielajú jednu správu Sync.
Dvochstupňové hodiny pre synchronizáciu používajú dve správy – Sync a Follow_Up.
Na fázu synchronizácie môžu byť použité dva mechanizmy:
- Mechanizmus požiadavky a odpovede oneskorenia (Delay request-response mechanism).
- Mechanizmus merania oneskorenia susedného uzla (Peer delay measurement mechanism).
Najprv preskúmame tieto mechanizmy v najjednoduchšom prípade – keď nie sú použité transparentné hodiny.
Mechanizmus požiadavky a odpovede oneskorenia (Delay request-response mechanism)
Mechanizmus predpokladá dva kroky:
- Meranie oneskorenia pri prenose správy medzi vedúcimi hodinami a nasledujúcimi. Vykonáva sa pomocou mechanizmu požiadavky a odpovede oneskorenia.
- Vykonáva sa korekcia posunu presného času.
Meranie oneskorenia
t1 – Čas odoslania správy Sync s vedúcimi hodinami; t2 – Čas prijatia správy Sync so sledujúcimi hodinami; t3 – Čas odoslania požiadavky na oneskorenie (Delay_Req) so sledujúcimi hodinami; t4 – Čas prijatia Delay_Req s vedúcimi hodinami.
Ak sledujúce hodiny poznajú čas t1, t2, t3 a t4, môžu vypočítať priemerné oneskorenie pri prenose správy synchronizácie (tmpd). Vypočíta sa nasledovne:
Pri prenose správy Sync a Follow_Up sa vypočíta oneskorenie času od majstra k pasívnemu uzlu – t-ms.
Pri prenose správ Delay_Req a Delay_Resp sa vypočíta oneskorenie času od pasívneho uzla k majstrovi – t-sm.
Ak medzi týmito dvoma hodnotami vznikne nejaká asymetria, vznikne chyba korekcie presného času. Chyba je podmienená tým, že vypočítané oneskorenie je priemerné z oneskorení t-ms a t-sm. Ak sa oneskorenia nezhodujú, čas budeme korigovať nepresne.
Korekcia posunu presného času
Po tom, čo je známe oneskorenie medzi vedúcimi a sledujúcimi hodinami, sledujúce hodiny vykonajú korekciu času.
Sledujúce hodiny používajú správu Sync a voliteľnú správu Follow_Up na výpočet posunu presného času pri prenose paketu z vedúcich hodín na sledujúce hodiny. Posun sa vypočíta podľa nasledujúceho vzorca:
Mechanizmus merania oneskorenia susedného uzla (Peer delay measurement mechanism)
Tento mechanizmus tiež využíva dva kroky na synchronizáciu:
- Zariadenia merajú oneskorenie času ku všetkým susedom cez všetky porty. Na to používajú mechanizmus peer delay.
- Korekcia posunu presného času.
Meranie oneskorenia medzi zariadeniami, ktoré podporujú režim peer-to-peer
Oneskorenie medzi portami, ktoré podporujú mechanizmus peer-to-peer, sa meria pomocou nasledujúcich správ:
Keď portu 1 známy čas t1, t2, t3 a t4, môže vypočítať priemerné oneskorenie (tmld). Vypočíta sa podľa nasledujúceho vzorca:
Potom port použije túto hodnotu pri výpočte poľa korekcie pre každú správu Sync alebo voliteľnú správu Follow_Up, ktoré prechádzajú cez toto zariadenie.
Konečné oneskorenie bude rovné súčtu oneskorenia pri prenose cez toto zariadenie, priemernému oneskoreniu pri prenose cez dátový kanál a už existujúcemu oneskoreniu v danej správe, zahrnutému na nadriadených zariadeniach.
Správy Pdelay_Req, Pdelay_Resp a voliteľný Pdelay_Resp_Follow_Up umožňujú získať oneskorenie od mastera k slave a od slave k masterovi (cirkulárne).
Akákoľvek asymetria medzi týmito dvoma hodnotami prinesie chybu korekcie posunu presného času.
Korekcia posunu presného času
Vedúce hodiny používajú Sync správu a voliteľnú Follow_Up správu na výpočet posunu presného času pri prenose paketu z vedúcich hodín na vedúce. Posun sa vypočítava podľa nasledujúceho vzorca:
Výhody korekcie mechanizmu peer-to-peer – oneskorenie času každej správy Sync alebo Follow_Up sa vypočítava počas jej prenosu v sieti. Preto zmena trasy prenosu nijako neovplyvní presnosť korekcie.
Pri použití tohto mechanizmu synchronizácia času nevyžaduje výpočet oneskorenia času na prechádzajúcej ceste synchronizačného paketu, ako sa to deje pri základnej výmene. T.j. správy Delay_Req a Delay_Resp sa neodosielajú. V tejto metóde sa oneskorenie medzi vedúcimi hodinami a vedúcimi jednoducho sčíta do poľa korekcie každej správy Sync alebo Follow_Up.
Ďalšou výhodou je, že vedúce hodiny sú zbavené nutnosti spracovávať správy Delay_Req.
Režimy prevádzky transparentných hodín
Zodpovedajúco, toto boli rozobraté jednoduché príklady. A teraz predpokladajme, že na ceste synchronizácie sa objavia prepínače.
Ak sa použijú prepínače bez podpory PTPv2, paket synchronizácie sa oneskorí na prepínači o približne 10 µs.
Prepínače s podporou PTPv2 v terminológii IEEE 1588v2 sa nazývajú transparentné hodiny (Transparent clock). Transparentné hodiny sa nesynchronizujú od vedúcich hodín a neparticipujú v hierarchii „Vedúce hodiny – Vedúce hodiny“, ale pri prenose správ synchronizácie si zapamätajú, o koľko sa správa oneskorila na nich. To umožňuje korigovať oneskorenie času.
Transparentné hodiny môžu pracovať v dvoch režimoch:
- End-to-End.
- Peer-to-Peer.
End-to-End (E2E)
Transparentné hodiny E2E prenášajú správy Sync a sprievodné správy Follow_Up na všetky porty. Dokonca aj na tie, ktoré sú zablokované akýmikoľvek protokolmi (napríklad RSTP).
Prepínač si pamätá časovú pečiatku, keď bol paket Sync (Follow_Up) prijatý na port a keď bol odoslaný z portu. Na základe týchto dvoch časových pečiatok sa vypočíta čas spracovania správy prepínačom. V štandarde sa tento čas nazýva residence time.
Čas spracovania sa pridáva do poľa correctionField správy Sync (jednostupňové hodiny) alebo Follow_Up (dvojstupňové hodiny).
Priehľadné hodiny E2E merajú čas spracovania pre správy Sync a Delay_Req prechádzajúce cez prepínač. Pri tom je však dôležité pochopiť, že oneskorenie medzi vedúcimi hodinami a nasledovníkmi sa vypočítava pomocou mechanizmu systému požiadaviek a odpovedí na oneskorenie. Ak sa vedúce hodiny zmenia alebo sa zmení cesta od vedúcich hodín k nasledovníkom, oneskorenie sa meria znova. To zvyšuje čas prechodného stavu v prípade zmien v sieti.
Priehľadné hodiny P2P, okrem merania času spracovania správy prepínačom, merajú oneskorenie na kanáli prenosu dát do najbližšieho suseda, pričom využívajú mechanizmus merania oneskorenia susedného uzla.
Oneskorenie sa meria na každom kanáli v oboch smeroch, vrátane kanálov, ktoré sú zablokované akýmkoľvek protokolom (napríklad RSTP). To umožňuje okamžite vypočítať nové oneskorenie na ceste synchronizácie, ak sa zmenili grandsmasterské hodiny alebo topológia siete.
Čas spracovania správ prepínačmi a čas oneskorenia sa akumulujú pri prenose správ Sync alebo Follow_Up.
Typy podpory PTPv2 pre prepínače
Prepínače môžu podporovať PTPv2:
- softvérovo;
- hardvérovo.
Pri softvérovej implementácii protokolu PTPv2 prepínač žiada časovú pečiatku od firmvéru. Problém spočíva v tom, že firmvér pracuje cyklicky a bude potrebné počkať, kým dokončí aktuálny cyklus, spracuje žiadosť a na konci nasledujúceho cyklu vygeneruje časovú pečiatku. Na to všetko tiež dôjde čas a my získame oneskorenie, aj keď nie také významné ako bez softvérovej podpory PTPv2.
Zabezpečiť potrebnú presnosť dokáže len hardvérová podpora PTPv2. V tomto prípade sa vydávanie časovej pečiatky vykonáva špeciálnym ASIC-om, ktorý je umiestnený na porte.
Formát správy
Všetky správy PTP pozostávajú z nasledujúcich polí:
- Header – 34 bajtov.
- Telo – veľkosť závisí od typu správy.
- Suffix – voliteľné.
Header
Pole Header je rovnaké pre všetky správy PTP. Jeho veľkosť je 34 bajtov.
Formát poľa Header:
messageType – obsahuje typ prenášanej správy, napríklad Sync, Delay_Req, PDelay_Req atď.
messageLength – obsahuje celkovú veľkosť správy PTP, vrátane header, body a suffix (ale bez vyplňujúcich bajtov).
domainNumber – určuje, ku ktorému doméne PTP patrí správa.
Doména – ide o niekoľko rôznych hodín, ktoré sú zoskupené do jednej logickej skupiny a synchronizované od jedného vedúceho časového počítadla, ale nemusia byť synchronizované s hodinami patriacimi k inému doménu.
flags – toto pole obsahuje rôzne vlajky na identifikáciu stavu správy.
correctionField – obsahuje časové oneskorenie v nanosekundách. Časové oneskorenie zahŕňa oneskorenie pri prenose cez priehľadné hodiny, ako aj oneskorenie pri prenose cez kanál pri použití režimu Peer-to-Peer.
sourcePortIdentity – toto pole obsahuje informácie o tom, z ktorého portu bola správa pôvodne odoslaná.
sequenceID – obsahuje identifikačné číslo pre individuálne správy.
controlField – pole-artefakt=) Zostalo z prvej verzie štandardu a obsahuje informácie o type tejto správy. V podstate to isté ako messageType, ale s menším počtom možností.
logMessageInterval – toto pole je definované typom správy.
Telo
Ako bolo diskutované vyššie, existuje niekoľko typov správ. Tieto typy sú popísané nižšie:
Správa Announce
Správa Announce slúži na to, aby "povedala" iným hodinám v rámci jednej domény o svojich parametroch. Táto správa umožňuje stanoviť hierarchiu "Vedúce hodiny – Vedené hodiny".
Správa Sync
Správa synchronizácie (Sync) sa odosiela vedúcimi hodinami a obsahuje čas vedúcich hodín v momente, keď bola správa Sync vytvorená. Ak sú vedúce hodiny dvojstupňové, časová pečiatka v správe Sync bude priradená k 0, a aktuálna časová pečiatka bude poslaná v sprievodnej správe Follow_Up. Správa Sync sa používa pre oba mechanizmy merania oneskorenia.
Správa sa prenáša pomocou Multicast. Voliteľne je možné použiť Unicast.
Správa Delay_Req
Formát správy Delay_Req je identický so správou Sync. Vedené hodiny posielajú Delay_Req. Obsahuje čas odoslania Delay_Req vedenými hodinami. Táto správa sa používa iba pre mechanizmus požiadavky-odpovede na oneskorenie.
Správa sa prenáša pomocou Multicast. Voliteľne je možné použiť Unicast.
Správa Follow_Up
Správa Follow_Up sa voliteľne odosiela vedúcimi hodinami a obsahuje čas odoslania správy Sync majstrom. Správu Follow_Up odosielajú len dvojúrovňové vedúce hodiny.
Správa Follow_Up sa používa pre oba mechanizmy merania oneskorenia.
Správa sa prenáša pomocou Multicast. Voliteľne je možné použiť Unicast.
Správa Delay_Resp
Správa Delay_Resp sa odosiela vedúcimi hodinami. Obsahuje čas prijatia Delay_Req vedúcimi hodinami. Táto správa sa používa iba pre mechanizmus žiadosti-o-vrátanie oneskorenia.
Správa sa prenáša pomocou Multicast. Voliteľne je možné použiť Unicast.
Správa Pdelay_Req
Správa Pdelay_Req sa odosiela zariadením, ktoré žiada o oneskorenie. Obsahuje čas odoslania správy z portu tohto zariadenia. Pdelay_Req sa používa iba pre mechanizmus merania oneskorenia susedného uzla.
Správa Pdelay_Resp
Správa Pdelay_Resp sa odosiela zariadením, ktoré prijalo žiadosť o oneskorenie. Obsahuje čas prijatia správy Pdelay_Req týmto zariadením. Správy Pdelay_Resp sa používajú iba pre mechanizmus merania oneskorenia susedného uzla.
Správa Pdelay_Resp_Follow_Up
Správa Pdelay_Resp_Follow_Up sa voliteľne odosiela zariadením, ktoré prijalo žiadosť o oneskorenie. Obsahuje čas prijatia správy Pdelay_Req týmto zariadením. Správa Pdelay_Resp_Follow_Up sa odosiela len dvojúrovňovými vedúcimi hodinami.
Taktiež sa táto správa môže používať pre čas vykonávania namiesto časovej pečiatky. Čas vykonávania je čas od prijatia Pdelay-Req do odoslania Pdelay_Resp.
Pdelay_Resp_Follow_Up sa používajú iba pre mechanizmus merania oneskorenia susedného uzla.
Riadiace správy (Správa Management)
Riadiace správy PTP sú potrebné na prenos informácií medzi jednými alebo viacerými hodinami a riadiacim uzlom.
Prenos v LV
PTP správa môže byť prenášaná na dvoch úrovniach:
- Sieťovej – ako súčasť IP dát.
- Kanaľovej – ako súčasť Ethernet rámca.
Prenos správy PTP cez UDP cez IP cez Ethernet
PTP cez UDP cez Ethernet
Profily
PTP má dosť „flexibilných“ parametrov, ktoré je potrebné nastaviť. Napríklad:
- Možnosti BMCA.
- Mechanizmus merania oneskorenia.
- Intervaly a počiatočné hodnoty všetkých konfigurovateľných parametrov a pod.
A napriek tomu, že sme predtým hovorili, že zariadenia PTPv2 sú medzi sebou kompatibilné, v skutočnosti to tak nie je. Zariadenia musia mať rovnaké nastavenia, aby mohli spolupracovať.
Preto existujú tzv. profily PTPv2. Profily sú skupiny nakonfigurovaných nastavení a určených obmedzení protokolu, ktoré umožňujú implementáciu synchronizácie času pre konkrétnu aplikáciu.
Samotný štandard IEEE 1588v2 popisuje iba jeden profil - „Default Profile“. Všetky ostatné profily vytvorili a opísali rôzne organizácie a asociácie.
Napríklad profil pre energetiku alebo PTPv2 Power Profile bol vytvorený výborom Power Systems Relaying Committee a výborom Substation Committee spoločnosti IEEE Power and Energy Society. Samotný profil má názov IEEE C37.238- 2011.
Profil popisuje, že PTP môže byť prenášaný:
- Iba prostredníctvom L2 sietí (t.j. Ethernet, HSR, PRP, nie IP).
- Správy sú prenášané iba multicastovým vysielaním.
- Ako mechanizmus na meranie oneskorenia sa používa peer delay measurement mechanism.
Predvolená doména je 0, doporučená doména je 93.
Vo filozofii vytvárania C37.238- 2011 bolo želanie znížiť počet voliteľných charakteristík a nechať iba nevyhnutné funkcie pre spoľahlivú interakciu medzi zariadeniami a zlepšenie stability systému.
Taktiež bola určená frekvencia prenosu správ:
V podstate je k dispozícii iba jeden parameter - typ vedúcich hodín (jednostupňové alebo dvojstupňové).
Presnosť musí byť maximálne 1 μs. Inými slovami, v jednom synchronizačnom reťazci môžu byť maximálne 15 transparentných hodín alebo tri hraničné hodiny.
Zdroj: habr.com
