Podrobnosti o implementaci protokolu časové synchronizace PTPv2

úvod

Koncepce výstavby „digitální rozvodny“ v elektroenergetice vyžaduje synchronizaci s přesností 1 μs. Finanční transakce také vyžadují mikrosekundovou přesnost. V těchto aplikacích již není dostatečná přesnost času NTP.

Synchronizační protokol PTPv2, popsaný standardem IEEE 1588v2, umožňuje přesnost synchronizace v řádu desítek nanosekund. PTPv2 umožňuje posílat synchronizační pakety přes sítě L2 a L3.

Hlavní oblasti, kde se používá PTPv2, jsou:

• energie;
• kontrolní a měřicí zařízení;
• vojensko-průmyslový komplex;
• telekomunikace;
• finanční sektor.

Tento příspěvek vysvětluje, jak funguje synchronizační protokol PTPv2.

Máme více zkušeností v průmyslu a často vidíme tento protokol v energetických aplikacích. Proto budeme recenzi provádět opatrně pro energii.

Proč je to nutné?

V současné době STO 34.01-21-004-2019 PJSC Rosseti a STO 56947007-29.240.10.302-2020 PJSC FGC UES obsahují požadavky na organizaci procesní sběrnice s časovou synchronizací přes PTPv2.

Je to dáno tím, že na procesní sběrnici jsou připojeny svorky reléových ochran a měřicí zařízení, které přenášejí okamžité hodnoty proudu a napětí po procesní sběrnici pomocí tzv. SV streamů (multicast streams).

Terminály ochrany relé používají tyto hodnoty k implementaci ochrany pozice. Pokud je přesnost měření času malá, mohou některé ochrany fungovat nesprávně.

Například obrana absolutní selektivity se může stát obětí „slabé“ časové synchronizace. Často je logika takové obrany založena na srovnání dvou veličin. Pokud se hodnoty rozcházejí o dostatečně velkou hodnotu, spustí se ochrana. Pokud jsou tyto hodnoty měřeny s časovou přesností 1 ms, pak můžete získat velký rozdíl, kde jsou hodnoty ve skutečnosti normální, pokud jsou měřeny s přesností 1 μs.

PTP verze

Protokol PTP byl původně popsán v roce 2002 ve standardu IEEE 1588-2002 a byl nazván „Standard pro protokol synchronizace přesných hodin pro síťové systémy měření a řízení“. V roce 2008 byla vydána aktualizovaná norma IEEE 1588-2008, která popisuje PTP verze 2. Tato verze protokolu zlepšila přesnost a stabilitu, ale nezachovala zpětnou kompatibilitu s první verzí protokolu. V roce 2019 byla také vydána verze standardu IEEE 1588-2019, která popisuje PTP v2.1. Tato verze přidává drobná vylepšení 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)

-
Nekompatibilní

Nekompatibilní

PTPv2 (IEEE 1588-2008)

Nekompatibilní

-
Kompatibilní

PTPv2.1 (IEEE 1588-2019)

Nekompatibilní

Kompatibilní

-

Ale jako vždy existují nuance.

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

Stále je však možné kombinovat zařízení s PTPv1 a zařízení s PTPv2 ve stejné síti. Aby toho dosáhli, někteří výrobci umožňují vybrat verzi protokolu na portech edge clock. To znamená, že hraniční hodiny se mohou synchronizovat pomocí PTPv2 a přesto synchronizovat další hodiny k nim připojené pomocí PTPv1 i PTPv2.

PTP zařízení. Jaké jsou a jak se liší?

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

Zařízení spolu komunikují přes LAN pomocí PTP.

Zařízení PTP se nazývají hodiny. Všechny hodinky berou přesný čas z velmistrových hodinek.

Existuje 5 typů hodinek:

Velmistrovské hodiny

Hlavním zdrojem přesného času. Často vybavený rozhraním pro připojení GPS.

Obyčejné hodiny

Zařízení s jedním portem, které může být hlavní (hlavní hodiny) nebo podřízené (podřízené hodiny)

Hlavní hodiny (master)

Jsou zdrojem přesného času, podle kterého jsou synchronizovány ostatní hodiny

Otrokářské hodiny

Koncové zařízení, které je synchronizováno z hlavních hodin

Hraniční hodiny

Zařízení s více porty, které může být master nebo slave.

To znamená, že tyto hodiny se mohou synchronizovat s nadřazenými hlavními hodinami a synchronizovat podřízené hodiny.

End-to-end transparentní hodiny

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

Při přenosu dat transparentní hodiny opravují všechny PTP zprávy.

K opravě dochází přidáním doby zpoždění na tomto zařízení do pole opravy v hlavičce přenášené zprávy.

Peer-to-Peer transparentní hodiny

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

Při přenosu dat transparentní hodiny opravují všechny PTP zprávy Sync a Follow_Up (více o nich níže).

Korekce je dosaženo přidáním do korekčního pole přenášeného paketu zpoždění na vysílacím zařízení a zpoždění na kanálu přenosu dat.

Management Node

Zařízení, které konfiguruje a diagnostikuje jiné hodinky

Hlavní a podřízené hodiny jsou synchronizovány pomocí časových razítek ve zprávách PTP. V protokolu PTP existují dva typy zpráv:

• Zprávy událostí jsou synchronizované zprávy, které zahrnují generování časového razítka v okamžiku odeslání zprávy a v okamžiku jejího přijetí.
• Obecné zprávy – Tyto zprávy nevyžadují časová razítka, ale mohou obsahovat časová razítka souvisejících zpráv

Zprávy událostí

Obecné zprávy

Sync
Delay_Req
Pdelay_Req
Pdelay_Resp

Oznámit
Následovat
Delay_Resp
Pdelay_Resp_Follow_Up
management
Signalizace

Všechny typy zpráv budou podrobněji popsány níže.

Základní problémy se synchronizací

Když je synchronizační paket přenášen přes místní síť, je zpožděn na přepínači a v datovém spoji. Jakýkoli přepínač způsobí zpoždění asi 10 mikrosekund, což je pro PTPv2 nepřijatelné. Na konečném zařízení totiž potřebujeme dosáhnout přesnosti 1 μs. (To je, pokud mluvíme o energii. Jiné aplikace mohou vyžadovat větší přesnost.)

IEEE 1588v2 popisuje několik provozních algoritmů, které umožňují zaznamenat časové zpoždění a opravit jej.

Algoritmus práce
Během normálního provozu protokol funguje ve dvou fázích.

• Fáze 1 - vytvoření hierarchie „Master Clock – Slave Clock“.
• Fáze 2 - synchronizace hodin pomocí mechanismu End-to-End nebo Peer-to-Peer.

Fáze 1 – Ustavení hierarchie Master-Slave

Každý port běžných nebo okrajových hodin má určitý počet stavů (slave hodiny a hlavní hodiny). Norma popisuje algoritmus přechodu mezi těmito stavy. V programování se takový algoritmus nazývá konečný automat nebo stavový automat (více podrobností na Wiki).

Tento stavový automat používá algoritmus Best Master Clock Algorithm (BMCA) k nastavení hlavního zařízení při propojení dvou hodin.

Tento algoritmus umožňuje hodinkám převzít povinnosti velmistrových hodinek, když nadřazené velmistrovské hodinky ztratí signál GPS, přejdou do režimu offline atd.

Stavové přechody podle BMCA jsou shrnuty v následujícím diagramu:


Informace o hodinkách na druhém konci „drátu“ jsou odeslány ve speciální zprávě (Hlášení). Jakmile je tato informace přijata, spustí se algoritmus stavového stroje a provede se porovnání, aby se zjistilo, které hodiny jsou lepší. Port na nejlepších hodinkách se stává mistrovskými hodinkami.

Jednoduchá hierarchie je znázorněna na obrázku níže. Cesty 1, 2, 3, 4, 5 mohou obsahovat Transparentní hodiny, ale nepodílejí se na vytváření hierarchie Master Clock - Slave Clock.

Fáze 2 – Synchronizujte běžné a okrajové hodiny

Ihned po ustavení hierarchie „Master Clock – Slave Clock“ začíná fáze synchronizace běžných a hraničních hodin.

Pro synchronizaci odešlou hlavní hodiny zprávu obsahující časové razítko do podřízených hodin.

Hlavní hodiny mohou být:

• jednostupňové;
• dvoustupňový.

Jednostupňové hodiny odesílají k synchronizaci jednu synchronizační zprávu.

Dvoufázové hodiny používají k synchronizaci dvě zprávy – Sync a Follow_Up.

Pro fázi synchronizace lze použít dva mechanismy:

• Mechanismus zpoždění požadavek-odpověď.
• Mechanismus měření vzájemného zpoždění.

Nejprve se podívejme na tyto mechanismy v nejjednodušším případě – když se nepoužívají průhledné hodinky.

Mechanismus zpoždění požadavek-odpověď

Mechanismus zahrnuje dva kroky:

1. Měření zpoždění při přenosu zprávy mezi hlavními hodinami a podřízenými hodinami. Provádí se pomocí mechanismu zpoždění požadavek-odpověď.
2. Provádí se korekce přesného časového posunu.

Měření latence


t1 – čas odeslání zprávy Sync hlavními hodinami; t2 – Čas přijetí zprávy Sync podřízenými hodinami; t3 – Čas odeslání požadavku na zpoždění (Delay_Req) ​​podřízenými hodinami; t4 – Čas příjmu Delay_Req hlavní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 synchronizační zprávy (tmpd). Vypočítá se následovně:

Při přenosu zprávy Sync and Follow_Up se počítá časové zpoždění mezi masterem a slave - t-ms.

Při přenosu zpráv Delay_Req a Delay_Resp se počítá časové zpoždění od podřízeného k nadřízenému – t-sm.

Pokud se mezi těmito dvěma hodnotami objeví nějaká asymetrie, pak se objeví chyba v korekci odchylky přesného času. Chyba je způsobena tím, že vypočtené zpoždění je průměrem zpoždění t-ms a t-sm. Pokud se zpoždění navzájem nerovnají, pak čas přesně neupravíme.

Korekce časového posunu

Jakmile je známé zpoždění mezi hlavními hodinami a podřízenými hodinami, provedou podřízené hodiny časovou korekci.

Slave hodiny používají zprávu Sync a volitelnou zprávu Follow_Up k výpočtu přesného časového posunu při přenosu paketu z master do slave hodin. Směna se vypočítá podle následujícího vzorce:

Mechanismus měření vzájemného zpoždění

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

1. Zařízení měří časovou prodlevu všem sousedům přes všechny porty. K tomu používají mechanismus peer delay.
2. Oprava přesného časového posunu.

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

Latence mezi porty podporujícími mechanismus peer-to-peer se měří pomocí následujících zpráv:

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

Port pak použije tuto hodnotu při výpočtu pole úprav pro každou zprávu Sync nebo volitelnou zprávu Follow_Up, která prochází zařízením.

Celkové zpoždění se bude rovnat součtu zpoždění během přenosu přes toto zařízení, průměrného zpoždění během přenosu přes datový kanál a zpoždění již obsaženého v této zprávě, povolené na upstream zařízeních.

Zprávy Pdelay_Req, Pdelay_Resp a volitelné Pdelay_Resp_Follow_Up vám umožňují získat zpoždění z master na slave a z slave na master (kruhové).

Jakákoli asymetrie mezi těmito dvěma hodnotami způsobí chybu korekce časového posunu.

Nastavení přesného časového posunu

Slave hodiny používají zprávu Sync a volitelnou zprávu Follow_Up k výpočtu přesného časového posunu při přenosu paketu z master do slave hodin. Směna se vypočítá podle následujícího vzorce:

Výhody přizpůsobení mechanismu peer-to-peer - časové zpoždění každé Sync nebo Follow_Up zprávy se počítá tak, jak je přenášena v síti. V důsledku toho změna přenosové cesty žádným způsobem neovlivní přesnost nastavení.

Při použití tohoto mechanismu nevyžaduje časová synchronizace výpočet časového zpoždění po cestě projeté synchronizačním paketem, jak je tomu u základní výměny. Tito. Zprávy Delay_Req a Delay_Resp se neodesílají. V této metodě se zpoždění mezi hlavními a podřízenými hodinami jednoduše sečte v poli nastavení každé zprávy Sync nebo Follow_Up.

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

Provozní režimy transparentních hodin

V souladu s tím to byly jednoduché příklady. Nyní předpokládejme, že se na cestě synchronizace objeví přepínače.

Pokud použijete přepínače bez podpory PTPv2, synchronizační paket se na přepínači zpozdí přibližně o 10 μs.

Přepínače, které podporují PTPv2, se v terminologii IEEE 1588v2 nazývají transparentní hodiny. Transparentní hodiny nejsou synchronizovány s hlavními hodinami a neúčastní se hierarchie „Master Clock - Slave Clock“, ale při přenosu synchronizačních zpráv si pamatují, jak dlouho jimi byla zpráva zpožděna. To vám umožní upravit časové zpoždění.

Transparentní hodiny mohou pracovat ve dvou režimech:

• End-to-End.
• Peer to peer.

End-to-End (E2E)

Transparentní hodiny E2E vysílají zprávy Sync a doprovodné zprávy Follow_Up na všech portech. I ty, které jsou blokovány některými protokoly (například RSTP).

Přepínač si pamatuje časové razítko, kdy byl na portu přijat synchronizační paket (Follow_Up) a kdy byl z portu odeslán. Na základě těchto dvou časových razítek se vypočítá doba, kterou přepínač potřebuje ke zpracování zprávy. Ve standardu se tato doba nazývá doba zdržení.

Doba zpracování se přidá do pole correctionField zprávy Sync (jednokrokové hodiny) nebo Follow_Up (dvoukrokové hodiny).

Transparentní hodiny E2E měří dobu zpracování zpráv Sync a Delay_Req procházejících přepínačem. Je však důležité pochopit, že časové zpoždění mezi hlavními hodinami a podřízenými hodinami se vypočítává pomocí mechanismu zpoždění požadavek-odpověď. Pokud se změní hlavní hodiny nebo se změní cesta od hlavních hodin k podřízeným hodinám, zpoždění se změří znovu. To prodlužuje dobu přechodu v případě změn sítě.

Transparentní hodiny P2P kromě měření času, který potřebuje přepínač ke zpracování zprávy, měří zpoždění na datovém spoji k nejbližšímu sousedovi pomocí mechanismu sousedské latence.

Latence se měří na každém spoji v obou směrech, včetně spojů, které jsou blokovány nějakým protokolem (např. RSTP). To vám umožní okamžitě vypočítat nové zpoždění v synchronizační cestě, pokud se změní hlavní hodiny nebo topologie sítě.

Doba zpracování zpráv přepínači a latence se sčítají při odesílání zpráv Sync nebo Follow_Up.

Typy podpory PTPv2 pomocí přepínačů

Přepínače mohou podporovat PTPv2:

• programově;
• Hardware.

Při implementaci protokolu PTPv2 v softwaru vyžaduje přepínač časové razítko z firmwaru. Problém je v tom, že firmware funguje cyklicky a budete muset počkat, až dokončí aktuální cyklus, vezme požadavek na zpracování a po dalším cyklu vydá časové razítko. To také zabere čas a dojde ke zpoždění, i když ne tak výraznému jako bez softwarové podpory PTPv2.

Pouze hardwarová podpora PTPv2 vám umožní zachovat požadovanou přesnost. Časové razítko v tomto případě vydává speciální ASIC, který je nainstalován na portu.

Formát zprávy

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

• Záhlaví – 34 bajtů.
• Tělo – velikost závisí na typu zprávy.
• Přípona je volitelná.

Hlavička

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

Formát pole záhlaví:

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

délka zprávy – obsahuje plnou velikost PTP zprávy, včetně hlavičky, těla a přípony (ale bez vyplňovacích bajtů).

domainNumber – určuje, do které PTP domény zpráva patří.

Domén - jedná se o několik různých hodin shromážděných v jedné logické skupině a synchronizovaných z jednoho hlavního hodin, ale ne nutně synchronizovaných s hodinami patřícími do jiné domény.

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

opravné pole – obsahuje dobu zpoždění v nanosekundách. Doba zpoždění zahrnuje zpoždění při přenosu přes transparentní hodiny a také zpoždění při přenosu kanálem při použití režimu Peer-to-Peer.

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

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

ovládací pole – pole artefaktu =) Zůstává z první verze standardu a obsahuje informace o typu této zprávy. V podstatě stejné jako messageType, ale s méně možnostmi.

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:

Oznamovací zpráva
Zpráva Announce se používá k „informování“ ostatních hodin ve stejné doméně o jejích parametrech. Tato zpráva vám umožňuje nastavit hierarchii Master Clock - Slave Clock.


Synchronizace zpráv
Zpráva Sync je odeslána hlavními hodinami a obsahuje čas hlavních hodin v době, kdy byla zpráva Sync vygenerována. Pokud jsou hlavní hodiny dvoustupňové, pak bude časové razítko ve zprávě Sync nastaveno na 0 a aktuální časové razítko bude odesláno v související zprávě Follow_Up. Zpráva Sync se používá pro oba mechanismy měření latence.

Zpráva je přenášena pomocí Multicast. Volitelně můžete použít Unicast.

Zpráva Delay_Req

Formát zprávy Delay_Req je shodný se zprávou Sync. Podřízené hodiny pošlou Delay_Req. Obsahuje čas, kdy byl požadavek Delay_Req odeslán podřízenými hodinami. Tato zpráva se používá pouze pro mechanismus zpoždění požadavek-odpověď.

Zpráva je přenášena pomocí Multicast. Volitelně můžete použít Unicast.

Následná zpráva

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

Zpráva Follow_Up se používá pro oba mechanismy měření latence.

Zpráva je přenášena pomocí Multicast. Volitelně můžete použít Unicast.

Zpráva Delay_Resp

Zprávu Delay_Resp odesílají hlavní hodiny. Obsahuje čas, kdy byl požadavek Delay_Req přijat hlavními hodinami. Tato zpráva se používá pouze pro mechanismus zpoždění požadavek-odpověď.

Zpráva je přenášena pomocí Multicast. Volitelně můžete použít Unicast.

Zpráva Pdelay_Req

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

Zpráva Pdelay_Resp

Zpráva Pdelay_Resp je odeslána zařízením, které přijalo požadavek na zpoždění. Obsahuje čas, kdy byla zpráva Pdelay_Req přijata tímto zařízením. Zpráva Pdelay_Resp se používá pouze pro mechanismus měření sousedního zpoždění.

Zpráva Pdelay_Resp_Follow_Up

Zprávu Pdelay_Resp_Follow_Up volitelně odesílá zařízení, které přijalo požadavek na zpoždění. Obsahuje čas, kdy byla zpráva Pdelay_Req přijata tímto zařízením. Zpráva Pdelay_Resp_Follow_Up je odesílána pouze dvoustupňovými hlavními hodinami.

Tuto zprávu lze také použít pro dobu provádění namísto časového razítka. Doba provedení je doba od okamžiku přijetí požadavku Pdelay-Req do odeslání Pdelay_Resp.

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

Zprávy pro správu

Řídicí zprávy PTP jsou vyžadovány pro přenos informací mezi jedním nebo více hodinami a řídicím uzlem.

Převod na LV

PTP zprávu lze přenášet na dvou úrovních:

• Síť – jako součást IP dat.
• Kanál – jako součást ethernetového rámce.

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

PTP přes UDP přes Ethernet

Profily

PTP má poměrně hodně flexibilních parametrů, které je třeba konfigurovat. Například:

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

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

Proto existují tzv. PTPv2 profily. Profily jsou skupiny konfigurovaných nastavení a definovaných omezení protokolu, takže lze pro konkrétní aplikaci implementovat časovou synchronizaci.

Samotný standard IEEE 1588v2 popisuje pouze jeden profil – „Výchozí profil“. Všechny ostatní profily vytvářejí a popisují různé organizace a sdružení.

Například Power Profile neboli PTPv2 Power Profile byl vytvořen Výborem pro přenos energetických systémů a Výborem pro rozvodny IEEE Power and Energy Society. Samotný profil se nazývá IEEE C37.238-2011.

Profil popisuje, že PTP lze přenést:

• Pouze prostřednictvím sítí L2 (tj. Ethernet, HSR, PRP, non-IP).
• Zprávy jsou přenášeny pouze vysíláním Multicast.
• Mechanismus měření vzájemného zpoždění se používá jako mechanismus měření zpoždění.

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

Filozofií návrhu C37.238-2011 bylo snížit počet volitelných funkcí a zachovat pouze funkce nezbytné pro spolehlivou interakci mezi zařízeními a zvýšenou stabilitu systému.

Také se určuje frekvence přenosu zpráv:

Ve skutečnosti je na výběr pouze jeden parametr – typ hlavních hodin (jednostupňové nebo dvoustupňové).

Přesnost by neměla být větší než 1 μs. Jinými slovy, jedna synchronizační cesta může obsahovat maximálně 15 transparentních hodin nebo tři hraniční hodiny.

Zdroj: www.habr.com