🥇Podrobnosti o implementaci protokolu pro synchronizaci času PTPv2

Úvod

Koncept budování "Digitální podstanice" v elektroenergetice vyžaduje synchronizaci s přesností 1 μs. Pro provádění finančních transakcí je také potřebná přesnost v μs. V těchto aplikacích už není časová přesnost NTP dostatečná.

Protokol synchronizace PTPv2, popsaný standardem IEEE 1588v2, umožňuje dosáhnout přesnosti synchronizace na několik desítek nanosekund. PTPv2 umožňuje posílat synchronizační pakety přes L2 a L3 sítě.

Hlavními oblastmi, kde se PTPv2 uplatňuje, jsou:

energetika;
měřicí a řídicí zařízení;
obranný a průmyslový komplex;
telekomunikace;
finanční sektor.

V tomto příspěvku se zabýváme tím, jak pracuje protokol synchronizace PTPv2.

Máme více zkušeností v průmyslu a často se s tímto protokolem setkáváme v energetických aplikacích. Odpovídajícím způsobem provedeme přehled související s energetikou.

Proč je to nezbytné?

V současnosti obsahují normy STO 34.01-21-004-2019 PAO "Rosseti" a STO 56947007-29.240.10.302-2020 PAO "FSK EES" požadavky na organizaci procesní sběrnice s zajištěním synchronizace času pomocí PTPv2.

To souvisí s tím, že k procesní sběrnici se připojují terminály reléové ochrany a měřicí zařízení, které prostřednictvím procesní sběrnice pomocí takzvaných SV toků (multicast toky) přenášejí okamžité hodnoty proudu a napětí.

Terminály reléové ochrany používají tyto hodnoty k realizaci ochrany připojení. Pokud bude přesnost měření času nízká, některé ochrany mohou chybně reagovat.

Například obětí "slabé" synchronizace času mohou být ochrany absolutní selektivity. Často je logika podobných ochran postavena na srovnání dvou hodnot. Pokud se hodnoty dostatečně liší, ochrana se spustí. Pokud tyto hodnoty změříte s přesností 1 ms, můžete získat velký rozdíl tam, kde se hodnoty ve skutečnosti nacházejí v normě, pokud je změříte s přesností 1 μs.

Verze PTP

Protokol PTP byl poprvé popsán v roce 2002 ve standardu IEEE 1588-2002 a měl název „Standard pro protokol synchronizace přesného času pro síťové měření a řídící systémy“. V roce 2008 byl vydán aktualizovaný standard IEEE 1588-2008, který popisuje PTP verze 2. V této verzi protokolu byla vylepšena přesnost a stabilita, ale nebyla zachována zpětná kompatibilita s první verzí protokolu. Také v roce 2019 vyšla verze standardu IEEE 1588-2019, která popisuje PTP v2.1. Tato verze přidává drobná vylepšení k PTPv2 a je zpětně kompatibilní s PTPv2.

Jinými slovy, máme následující obrázek s verzemi:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

—
Nejsou kompatibilní

Nejsou kompatibilní

PTPv2 (IEEE 1588-2008)

Nejsou kompatibilní

—
Jsou kompatibilní

PTPv2.1 (IEEE 1588-2019)

Nejsou kompatibilní

Jsou kompatibilní

—

Ale, jak už to bývá, jsou tu nuance.

Nekompatibilita mezi PTPv1 a PTPv2 znamená, že zařízení podporující PTPv1 se nebude moci synchronizovat s přesnými hodinami, které běží na PTPv2. Pro synchronizaci používají různé formáty zpráv.

Ale propojit zařízení s PTPv1 a zařízení s PTPv2 v jedné síti je přesto možné. Někteří výrobci umožňují na portech hraničních hodin vybírat verzi protokolu. To znamená, že hraniční hodiny se mohou synchronizovat pomocí PTPv2 a zároveň synchronizovat další připojené hodiny jak s PTPv1, tak s PTPv2.

Zařízení PTP. Jaké jsou a v čem se liší?

Standard IEEE 1588v2 popisuje několik typů zařízení. Všechna jsou uvedena v tabulce.

Zařízení vzájemně komunikují přes LAN pomocí PTP.

Zařízení PTP se nazývají hodiny. Všechny hodiny získávají přesný čas od grandmaster hodin.

Existuje 5 typů hodin:

Grandmaster clock (Grandmaster hodiny)

Hlavní zdroj přesného času. Často jsou vybaveny rozhraním pro připojení GPS.

Ordinary Clock (Běžné hodiny)

Zařízení s jedním portem, které může být mistrem (vedoucími hodinami) nebo slávou (podřízenými hodinami)

Mistr (vedoucí hodiny)

Jsou zdrojem přesného času, podle kterého se synchronizují další hodiny

Podřízené hodiny (slave)

Konečné zařízení, které se synchronizuje s mistrovskými hodinami

Boundary Clock (Hraniční hodiny)

Zařízení s několika porty, které může být mistrem nebo slavným.

To znamená, že tyto hodiny se mohou synchronizovat s vyššími mistrovskými hodinami a synchronizovat nižší podřízené hodiny.

Průhledné hodiny fungující v režimu End-to-End

Zařízení s několika porty, které není ani hlavními hodinami, ani podřízenými hodinama. Přenáší data PTP mezi dvěma hodinami.

Při přenosu dat průhledné hodiny opravují všechny PTP zprávy.

Oprava probíhá přidáním časového zpoždění na tomto zařízení do pole korekce v hlavičce přenášené zprávy.

Průhledné hodiny fungující v režimu Peer-to-Peer

Zařízení s několika porty, které není ani hlavními hodinami, ani podřízenými hodinama.
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 kterých bude podrobněji řeč níže).

Oprava se dosahuje přidáním zpoždění na předávajícím zařízení a zpoždění na datovém kanálu do pole korekce přenášeného balíčku.

Řídicí uzel

Zařízení, které konfiguruje a diagnostikuje ostatní hodiny

Hlavní a podřízené hodiny se synchronizují pomocí časových značek v PTP zprávách. Existují dva typy zpráv v PTP protokolu:

Event Messages – jedná se o synchronizované zprávy, které předpokládají vygenerování časové značky při odeslání zprávy a při jejím přijetí
General Messages – tyto zprávy nemusí obsahovat č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

Nyní budou podrobněji probrány všechny typy zpráv.

Hlavní problémy synchronizace

Při přenosu synchronizačního balíčku přes místní síť je zpožděn na přepínači a v datovém kanálu. Každý přepínač vytvoří zpoždění okolo 10 μs, což je pro PTPv2 nepřijatelné. Na koncovém zařízení potřebujeme dosáhnout přesnosti 1 μs. (To se vztahuje na energetiku. Jiná aplikace mohou vyžadovat i větší přesnost.)

V IEEE 1588v2 je popsáno několik pracovních algoritmů, které umožňují měřit časové zpoždění a opravovat jej.

Algoritmus práce
Při normálním chodu protokol pracuje ve dvou fázích.

Fáze 1 — stanovení hierarchie „Hlavní hodiny – Podřízené hodiny“.
Fáze 2 — synchronizace hodin pomocí mechanismu End-to-End nebo Peer-to-Peer.

Fáze 1 — Instalace hierarchie „Master-Slave“

Každý port běžných nebo hraničních hodin má určité množství stavů (podřízené hodiny a vedoucí hodiny). Standard definuje algoritmus přechodu mezi těmito stavy. V programování se tento algoritmus nazývá konečný automat nebo stavový stroj (více v Wiki).

Tento konečný automat používá algoritmus Best Master Clock Algorithm (BMCA) na určení mistra při spojení dvou hodin.

Tento algoritmus umožňuje hodinám převzít povinnosti grandsmaster hodin, když vyšší grandsmaster hodin ztrácí signál GPS, odpojuje se od sítě atd.

Přechody mezi stavy podle BMCA jsou stručně znázorněny na následující schématu:

Informace o hodinách na druhém konci „kabelu“ jsou zasílány ve speciální zprávě (Announce message). Jakmile jsou tyto informace obdrženy, algoritmus stavového stroje vyhodnocuje a porovnává, které hodiny jsou lepší. Port na nejlepších hodinách se stává vedoucími hodinami.

Jednoduchá hierarchie je znázorněna na schématu níže. Cesty 1, 2, 3, 4, 5 mohou obsahovat transparentní hodiny (Transparent clock), ale neúčastní se ustavení hierarchie „Vedoucí hodiny – Podřízené hodiny“.

Fáze 2 — Synchronizace běžných a hraničních hodin

Ihned po instalaci hierarchie „Vedoucí hodiny – Podřízené hodiny“ začíná fáze synchronizace běžných a hraničních hodin.

Pro synchronizaci vedoucí hodiny posílají podřízeným hodinám zprávu obsahující časovou značku.

Vedoucí hodiny mohou být:

jednostupňové;
dvoustupňové.

Jednostupňové hodiny posílají pro synchronizaci jednu zprávu Sync.

Dvoustupňové hodiny pro synchronizaci používají dvě zprávy – Sync a Follow_Up.

Pro fázi synchronizace mohou být použity dva mechanizmy:

Mechanismus žádosti-o-většinu zpoždění (Delay request-response mechanism).
Mechanismus měření zpoždění sousedního uzlu (Peer delay measurement mechanism).

Nejprve se podíváme na tyto mechanizmy v nejjednodušším případě – když nejsou použity transparentní hodiny.

Mechanismus žádosti-o-většinu zpoždění (Delay request-response mechanism)

Mechanismus předpokládá dva kroky:

Měření zpoždění při přenosu zprávy mezi vedoucími a podřízenými hodinami. To se provádí pomocí mechanizmu žádosti-o-většinu zpoždění.
Provádí se korekce posunu přesného času.

Měření zpoždění

t1 – Čas odeslání zprávy Sync vedoucími hodinami; t2 – Čas přijetí zprávy Sync podřízenými hodinami; t3 – Čas odeslání dotazu na zpoždění (Delay_Req) podřízenými hodinami; t4 – Čas přijetí Delay_Req vedoucími hodinami.

Když podřízené hodiny znají časy t1, t2, t3 a t4, mohou vypočítat průměrné zpoždění při přenosu zprávy synchronizace (tmpd). Vypočítává se následujícím způsobem:

Při přenosu zprávy Sync a Follow_Up se vypočítává zpoždění času od masteru k slaveovi – t-ms.

Při přenosu zpráv Delay_Req a Delay_Resp se vypočítává zpoždění času od slavea k masteru – t-sm.

Pokud mezi těmito dvěma hodnotami vznikne nějaká asymetrie, objeví se chyba v korekci odchylek přesného času. Chyba je způsobena tím, že vypočítané zpoždění je průměrem zpoždění t-ms a t-sm. Pokud se zpoždění neshodují, budeme čas korigovat nepřesně.

Korekce odchylky přesného času

Jakmile je zpoždění mezi vedoucími hodinami a podřízenými hodinami známo, podřízené hodiny provádějí korekci času.

Podřízené hodiny používají zprávu Sync a volitelnou zprávu Follow_Up k výpočtu odchylky přesného času při přenosu paketu od vedoucích hodin k podřízeným. Odchylka se vypočítává podle následujícího vzorce:

Mechanismus měření zpoždění sousedního uzlu (Peer delay measurement mechanism)

Tento mechanismus také využívá dva kroky pro synchronizaci:

Zařízení měří zpoždění času do všech sousedů přes všechny porty. K tomu využívají mechanizmus měření zpoždění sousedů.
Korekce odchylky přesného času.

Měření zpoždění mezi zařízeními, která podporují režim Peer-to-Peer

Zpoždění mezi porty, které podporují mechanismus peer-to-peer, je měřeno pomocí následujících zpráv:

Když portu 1 je známo čas t1, t2, t3 a t4, může vypočítat průměrné zpoždění (tmld). Vypočítává se podle následujícího vzorce:

Následně port používá tuto hodnotu při výpočtu pole korekce pro každou zprávu Sync nebo volitelnou zprávu Follow_Up, které procházejí přes toto zařízení.

Konečné zpoždění bude rovno součtu zpoždění při přenosu přes toto zařízení, průměrnému zpoždění při přenosu přes datový kanál a již existujícímu zpoždění v této zprávě, zahrnutému na vyšších zařízeních.

Zprávy Pdelay_Req, Pdelay_Resp a volitelný Pdelay_Resp_Follow_Up umožňují získat zpoždění od masteru k slave a od slave k masteru (kruhové).

Jakákoli asymetrie mezi těmito dvěma hodnotami povede k chybě v korekci posunu přesného času.

Korekce posunu přesného času

Podřízené hodiny používají zprávu Sync a volitelnou zprávu Follow_Up k výpočtu posunu přesného času při přenosu paketu od hlavních hodin k podřízeným. Posun se vypočítává podle následujícího vzorce:

Výhody korekčního mechanismu peer-to-peer – zpoždění každé zprávy Sync nebo Follow_Up se vypočítává během jejího přenosu v síti. Proto změna cesty přenosu neovlivní přesnost korekce jakýmikoliv způsobem.

Při použití tohoto mechanismu synchronizace času není potřeba vypočítávat zpoždění času na cestě, kterou paket synchronizace prošel, jak je to obvyklé při základní výměně. Tzn. zprávy Delay_Req a Delay_Resp se neposílají. V této metodě se zpoždění mezi hlavními hodinami a podřízenými jednoduše sčítá do pole korekce každé zprávy Sync nebo Follow_Up.

Další výhodou je, že hlavní hodiny jsou zbaveny potřeby zpracovávat zprávy Delay_Req.

Režimy práce transparentních hodin

Odpovídajícím způsobem jsme rozebrali jednoduché příklady. A nyní předpokládejme, že na cestě synchronizace se objevují switche.

Pokud použijete switche bez podpory PTPv2, paket synchronizace bude zpožděn na switchi přibližně o 10 μs.

Switche s podporou PTPv2 v terminologii IEEE 1588v2 se nazývají transparentní hodiny. Transparentní hodiny se nesynchronizují od hlavních hodin a neúčastní se hierarchie „Hlavní hodiny – Podřízené hodiny“, ale při přenosu synchronizačních zpráv si pamatují, o kolik se zpráva na nich zpozdila. To umožňuje korigovat zpoždění času.

Transparentní hodiny mohou pracovat ve dvou režimech:

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

End-to-End (E2E)

Transparentní hodiny E2E přenášejí zprávy Sync a související zprávy Follow_Up na všechny porty. I na ty, které jsou blokovány jakýmikoli protokoly (například RSTP).

Přepínač si pamatuje časovou značku, kdy byl paket Sync (Follow_Up) přijat na portu a kdy byl odeslán z portu. Na základě těchto dvou časových značek se vypočítá doba zpracování zprávy přepínačem. Ve standardu se tato doba nazývá residence time.

Doba zpracování se přidává do pole correctionField zprávy Sync (jednostupňové hodiny) nebo Follow_Up (dvoustupňové hodiny).

Transparentní hodiny E2E měří dobu zpracování pro zprávy Sync a Delay_Req, které procházejí přepínačem. Je však důležité pochopit, že zpoždění mezi hlavními hodinami a podřízenými hodinami se vypočítává pomocí mechanismu požadavku-odezvy zpoždění. Pokud se mění hlavní hodiny nebo cesta od hlavních hodin k podřízeným, zpoždění se měří znovu. To zvyšuje dobu přechodného stavu v případě změn v síti.

Transparentní hodiny P2P, kromě měření doby zpracování zprávy přepínačem, měří zpoždění na kanálu přenosu dat k nejbližšímu sousedovi pomocí mechanismu měření zpoždění sousedního uzlu.

Zpoždění se měří na každém kanálu v obou směrech, včetně kanálů, které jsou blokovány nějakým protokolem (např. RSTP). To umožňuje okamžité vypočítání nového zpoždění na cestě synchronizace, pokud se změnily hlavní hodiny nebo topologie sítě.

Doba zpracování zpráv přepínači a doba zpoždění se akumulují při přenosu zpráv Sync nebo Follow_Up.

Typy podpory PTPv2 přepínači

Přepínače mohou podporovat PTPv2:

softwarově;
hardwarově.

Při softwarové implementaci protokolu PTPv2 přepínač požaduje časovou značku od firmwaru. Problém spočívá v tom, že firmware pracuje cyklicky, a bude nutné počkat, až dokončí aktuální cyklus, vezme požadavek k zpracování a po uplynutí dalšího cyklu vydá časovou značku. To vše také zabere čas a my dostaneme zpoždění, i když ne tak výrazné jako bez softwarové podpory PTPv2.

Zaručit potřebnou přesnost umožňuje pouze hardwarová podpora PTPv2. V tomto případě se vydání časové značky provádí speciálním ASICem, který je nainstalován na portu.

Formát zprávy

Všechny zprávy PTP se skládají z následujících polí:

Header – 34 bytů.
Body – velikost závisí na typu zprávy.
Suffix – volitelně.

Header

Pole Header je stejné pro všechny zprávy PTP. Jeho velikost je 34 bajtů.

Formát pole Header:

messageType – obsahuje typ přenášené zprávy, například Sync, Delay_Req, PDelay_Req atd.

messageLength – obsahuje celkovou velikost zprávy PTP, včetně hlavičky, těla a suffixu (ale bez vyplňujících bajtů).

domainNumber – určuje, ke kterému domain PTP zpráva patří.

Doména – to je několik různých hodin seskupených do jedné logické skupiny, synchronizovaných z jednoho hlavního hodin, ale není nutné, aby byly synchronizovány s hodinami patřícími k jinému doméně.

flags – toto pole obsahuje různé příznaky pro identifikaci stavu zprávy.

correctionField – obsahuje čas zpoždění v nanosekundách. Čas zpoždění zahrnuje zpoždění při přenosu přes transparentní hodiny, stejně jako zpoždění při přenosu přes kanál při použití režimu Peer-to-Peer.

sourcePortIdentity – toto pole obsahuje informace o tom, z jakého portu byla tato zpráva původně odeslána.

sequenceID – obsahuje identifikační číslo pro jednotlivé zprávy.

controlField – artefakt pole =). Zůstalo z první verze standardu a obsahuje informace o typu této zprávy. V podstatě je to totéž jako messageType, ale s menším počtem možností.

logMessageInterval – toto pole je určeno typem zprávy.

Tělo

Jak bylo uvedeno výše, existuje několik typů zpráv. Tyto typy jsou popsány níže:

Zpráva Announce
Zpráva Announce se používá k tomu, aby "řekla" ostatním hodinám uvnitř jednoho domény o svých parametrech. Tato zpráva umožňuje nastavit hierarchii "Hlavní hodiny – Podřízené hodiny."

Zpráva Sync
Zpráva synchronizace (Sync) je odesílána hlavními hodinami a obsahuje čas hlavních hodin v okamžiku, kdy byla zpráva Sync vytvořena. Pokud jsou hlavní hodiny dvoustupňové, bude časová značka ve zprávě Sync nastavena na 0 a aktuální časová značka bude odeslána v připojené zprávě Follow_Up. Zpráva Sync se používá pro oba mechanismy měření zpoždění.

Zpráva se přenáší pomocí Multicast. Volitelně je možné použít Unicast.

Zpráva Delay_Req

Formát zprávy Delay_Req je shodný se zprávou Sync. Podřízené hodiny posílají Delay_Req. Obsahuje čas odeslání Delay_Req podřízenými hodinami. Tato zpráva se používá pouze pro mechanismus žádosti o zpoždění.

Zpráva se přenáší pomocí Multicast. Volitelně je možné použít Unicast.

Zpráva Follow_Up

Zpráva Follow_Up je volitelně odesílána hlavními hodinami a obsahuje čas odeslání zprávy Sync mistrem. Zprávu Follow_Up odesílají pouze dvoustupňové hlavní hodiny.

Zpráva Follow_Up se používá pro oba mechanizmy měření zpoždění.

Zpráva se přenáší pomocí Multicast. Volitelně je možné použít Unicast.

Zpráva Delay_Resp

Zpráva Delay_Resp je odesílána hlavními hodinami. Obsahuje čas přijetí Delay_Req hlavními hodinami. Tato zpráva se používá pouze pro mechanizmus dotaz-odpověď zpoždění.

Zpráva se přenáší pomocí Multicast. Volitelně je možné použít Unicast.

Zpráva Pdelay_Req

Zpráva Pdelay_Req je odesílána zařízením, které požaduje zpoždění. Obsahuje čas odeslání zprávy z portu tohoto zařízení. Pdelay_Req se používá pouze pro mechanizmus měření zpoždění sousedního uzlu.

Zpráva Pdelay_Resp

Zpráva Pdelay_Resp je odesílána zařízením, které obdrželo žádost o zpoždění. Obsahuje čas přijetí zprávy Pdelay_Req tímto zařízením. Zprávy Pdelay_Resp se používají pouze pro mechanizmus měření zpoždění sousedního uzlu.

Zpráva Pdelay_Resp_Follow_Up

Zpráva Pdelay_Resp_Follow_Up je volitelně odesílána zařízením, které obdrželo žádost o zpoždění. Obsahuje čas přijetí zprávy Pdelay_Req tímto zařízením. Zpráva Pdelay_Resp_Follow_Up se odesílá pouze dvoustupňovými hlavními hodinami.

Tato zpráva může být také použita pro čas vykonání místo časové značky. Čas vykonání je čas od okamžiku přijetí Pdelay-Req po odeslání Pdelay_Resp.

Pdelay_Resp_Follow_Up se používají pouze pro mechanizmus měření zpoždění sousedního uzlu.

Řídicí zprávy (Zpráva Management)

Řídicí zprávy PTP jsou nezbytné pro přenos informací mezi jedněmi nebo více hodinami a řídicí uzlem.

Přenos v LV

PTP-zpráva může být přenášena na dvou úrovních:

Síťové – jako součást IP dat.
Linkové – jako součást Ethernetového rámce.

Přenos zprávy PTP přes UDP přes IP přes Ethernet

PTP přes UDP přes Ethernet

Profily

PTP má dostatek „flexibilních“ parametrů, které je třeba nastavit. Například:

Možnosti BMCA.
Mechanismus měření zpoždění.
Intervaly a počáteční hodnoty všech konfigurovatelných parametrů atd.

A přestože jsme již dříve říkali, že zařízení PTPv2 jsou vzájemně kompatibilní, tak to úplně není pravda. Zařízení musí mít shodná nastavení, aby mohla vzájemně komunikovat.

Proto existují takzvané profily PTPv2. Profily jsou skupiny nakonfigurovaných nastavení a specifikovaných omezení protokolu, které umožňují implementaci časové synchronizace pro konkrétní aplikaci.

Samotný standard IEEE 1588v2 popisuje pouze jeden profil – „Default Profile“. Všechny ostatní profily byly vytvořeny a popsány různými organizacemi a asociacemi.

Například profil pro elektroenergetiku nebo PTPv2 Power Profile byl vytvořen výborem Power Systems Relaying Committee a výborem Substation Committee společnosti IEEE Power and Energy Society. Tento profil nese název IEEE C37.238-2011.

Profil popisuje, jak může být PTP přenášen:

Pouze přes L2 sítě (tj. Ethernet, HSR, PRP, nikoli IP).
Zprávy se přenášejí pouze pomocí Multicast distribuce.
Jako mechanismus pro měření zpoždění se používá mechanismus měření zpoždění Peer.

Výchozí doména je 0, doporučená doména je 93.

V filozofii tvorby C37.238-2011 stálo přání snížit počet volitelných vlastností a ponechat pouze nezbytné funkce pro spolehlivou interakci mezi zařízeními a zvýšení stability systému.

Dále byla určena frekvence přenosu zpráv:

V podstatě je pro výběr k dispozici pouze jeden parametr – typ hlavních hodin (jednostupňové nebo dvoustupňové).