Szczegóły realizacji protokołu synchronizacji czasu PTPv2

Wprowadzenie

Koncepcja budowy „Cyfrowej Stacji Transformatorowej” w energetyce wymaga synchronizacji z dokładnością 1 µs. W przypadku przeprowadzania transakcji finansowych również wymagana jest dokładność w µs. W tych aplikacjach dokładność czasu NTP już nie wystarcza.

Protokół synchronizacji PTPv2, opisany w standardzie IEEE 1588v2, pozwala osiągnąć dokładność synchronizacji na poziomie kilku dziesiątych nanosekund. PTPv2 umożliwia wysyłanie pakietów synchronizacji przez sieci L2 i L3.

Główne obszary, gdzie stosuje się PTPv2, to:

• energetyka;
• sprzęt pomiarowy;
• przemysł obronny;
• telekomunikacja;
• sektor finansowy.

W tym artykule omawiamy, jak działa protokół synchronizacji PTPv2.

Mamy większe doświadczenie w przemyśle i często spotykamy się z tym protokołem w aplikacjach energetycznych. Odpowiednio, przegląd wykonamy z uwzględnieniem energetyki.

Dlaczego jest to potrzebne?

Na chwilę obecną w STO 34.01-21-004-2019 PАО „Rosseti” oraz w STO 56947007-29.240.10.302-2020 PAO „FSK EES” znajdują się wymagania dotyczące organizacji szyny procesowej z zapewnieniem synchronizacji czasu zgodnie z PTPv2.

Jest to związane z tym, że do szyny procesowej podłączone są terminale ochrony relacyjnej i urządzenia pomiarowe, które za pomocą tak zwanych strumieni SV (strumienie multicast) przesyłają natychmiastowe wartości prądu i napięcia.

Terminale ochrony relacyjnej wykorzystują te wartości do realizacji zabezpieczeń połączenia. Jeśli dokładność pomiarów czasowych będzie zbyt mała, niektóre zabezpieczenia mogą działać fałszywie.

Na przykład ofiarą „słabej” synchronizacji czasu mogą paść zabezpieczenia absolutnej selektywności. Często logika takich zabezpieczeń opiera się na porównaniu dwóch wielkości. Jeśli wielkości różnią się na wystarczająco dużą wartość, wówczas zabezpieczenie się uruchamia. Jeśli te wielkości zmierzyć z dokładnością czasową 1 ms, można uzyskać dużą różnicę tam, gdzie wartości są w rzeczywistości w normie, jeśli zmierzyć je z dokładnością 1 µs.

Wersje PTP

Protokół PTP został pierwotnie opisany w 2002 roku w standardzie IEEE 1588-2002 i nosił nazwę „Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems”. W 2008 roku wydano zaktualizowany standard IEEE 1588-2008, który opisuje PTP Version 2. W tej wersji protokołu poprawiono dokładność i stabilność, jednak nie zachowano zgodności wstecznej z pierwszą wersją protokołu. W 2019 roku wydano wersję standardu IEEE 1588-2019, opisującą PTP v2.1. Ta wersja wprowadza niewielkie ulepszenia do PTPv2 i jest zgodna wstecznie z PTPv2.

Innymi słowy, mamy następujący obraz wersji:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

—
Niezgodne

Niezgodne

PTPv2 (IEEE 1588-2008)

Niezgodne

—
Zgodne

PTPv2.1 (IEEE 1588-2019)

Niezgodne

Zgodne

—

Ale, jak to zwykle bywa, są niuanse.

Niezgodność pomiędzy PTPv1 a PTPv2 oznacza, że urządzenie obsługujące PTPv1 nie będzie mogło synchronizować się z dokładnymi zegarami działającymi na PTPv2. Do synchronizacji korzystają z różnych formatów wiadomości.

Jednakże można połączyć urządzenia z PTPv1 i urządzenia z PTPv2 w jednej sieci. W tym celu niektórzy producenci umożliwiają na portach zegarów granicznych wybór wersji protokołu. Oznacza to, że zegary graniczne mogą synchronizować się za pomocą PTPv2 i jednocześnie synchronizować inne podłączone do nich zegary zarówno za pomocą PTPv1, jak i PTPv2.

Urządzenia PTP. Jakie są rodzaje i czym się różnią?

Standard IEEE 1588v2 opisuje kilka typów urządzeń. Wszystkie są przedstawione w tabeli.

Urządzenia komunikują ze sobą za pośrednictwem LAN, używając PTP.

Urządzenia PTP nazywane są zegarami. Wszystkie zegary czerpią dokładny czas z zegarów grandmaster.

Istnieje 5 typów zegarów:

Grandmaster clock (Zegar Grandmaster)

Główny źródło dokładnego czasu. Często wyposażone w interfejs do podłączenia GPS.

Ordinary Clock (Zegar Obyczajny)

Urządzenie z jednym portem, które może być mistrzem (zegarem prowadzącym) lub niewolnikiem (zegarem podporządkowanym).

Zegary prowadzące (mistrz)

Są źródłem dokładnego czasu, na którym synchronizują się inne zegary.

Zegary podporządkowane (niewolnik)

Końcowe urządzenie, które synchronizuje się z zegarami prowadzącymi.

Boundary Clock (Zegar Graniczny)

Urządzenie z wieloma portami, które może być mistrzem lub niewolnikiem.

Oznacza to, że te zegary mogą synchronizować się z wyższymi zegarami prowadzącymi i synchronizować niższe zegary podporządkowane.

Przezroczysty zegar End-to-End

Urządzenie z wieloma portami, które nie jest ani zegarem głównym, ani podrzędnym. Przekazuje dane PTP między dwoma zegarami.

Podczas przesyłania danych przezroczyste zegary korygują wszystkie wiadomości PTP.

Korekta odbywa się poprzez dodanie czasu opóźnienia na tym urządzeniu do pola korekty w nagłówku przesyłanej wiadomości.

Przezroczysty zegar Peer-to-Peer

Urządzenie z wieloma portami, które nie jest ani zegarem głównym, ani podrzędnym.
Przekazuje dane PTP między dwoma zegarami.

Podczas przesyłania danych przezroczyste zegary korygują wszystkie wiadomości PTP Sync i Follow_Up (więcej na ten temat poniżej).

Korekta osiągana jest poprzez dodanie do pola korekty przesyłanej paczki opóźnienia na urządzeniu nadawczym oraz opóźnienia na kanale transmisyjnym.

Węzeł zarządzający

Urządzenie, które konfiguruje i diagnozuje inne zegary.

Zegary główne i podrzędne synchronizują się za pomocą znaczników czasowych w wiadomościach PTP. W protokole PTP są dwa typy wiadomości:

• Wiadomości zdarzeń – są to synchronizowane wiadomości, które przewidują generację znacznika czasowego w momencie wysyłania wiadomości i w momencie jej odbioru.
• Wiadomości ogólne – te wiadomości nie wymagają znaczników czasowych, ale mogą zawierać znaczniki czasowe dla powiązanych wiadomości.

Wiadomości zdarzeń

Wiadomości ogólne

Sync
Delay_Req
Pdelay_Req
Pdelay_Resp

Ogłoszenie
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Zarządzanie
Sygnały

Poniżej omówione zostaną wszystkie typy wiadomości bardziej szczegółowo.

Główne problemy synchronizacji

Podczas przesyłania pakietu synchronizacji przez lokalną sieć, opóźnia się on w switche oraz w kanale transmisyjnym. Każdy switch generuje opóźnienie około 10 µs, co jest niedopuszczalne dla PTPv2. Na końcowym urządzeniu musimy uzyskać precyzję 1 µs. (To jest w przypadku energetyki. Inne aplikacje mogą wymagać jeszcze większej precyzji.)

W IEEE 1588v2 opisano kilka algorytmów, które pozwalają na pomiar opóźnienia czasowego i jego korekcję.

Algorytm działania
W normalnej pracy protokół działa w dwóch fazach.

• Faza 1 — ustalanie hierarchii 'Zegary główne - Zegary podrzędne'.
• Faza 2 — synchronizacja zegarów za pomocą mechanizmu End-to-End lub Peer-to-Peer.

Faza 1 — Ustawienie hierarchii „Mistrz-Podwładny”

Każdy port zwykłych lub brzegowych zegarów ma określoną liczbę stanów (zegar podwładny i zegar prowadzący). Standard opisuje algorytm przejścia między tymi stanami. W programowaniu taki algorytm nazywany jest automat końcowy lub maszyną stanów (szczegóły w Wiki).

Ten automat końcowy używa algorytmu Best Master Clock Algorithm (BMCA) do ustalenia mistrza podczas łączenia dwóch zegarów.

Ten algorytm umożliwia zegarom przejęcie obowiązków zegarów arcymistrzowskich, gdy wyższe zegary arcymistrzowskie tracą sygnał GPS, są odłączane od sieci itp.

Przejścia między stanami zgodnie z BMCA są krótko przedstawione na następnej schemacie:


Informacje o zegarze po drugiej stronie „przewodu” są wysyłane w specjalnej wiadomości (Wiadomość ogłoszenia). Gdy te informacje zostaną odebrane, algorytm maszyny stanów działa i porównuje, które zegary są lepsze. Port w najlepszym zegarze staje się zegarem prowadzącym.

Prosta hierarchia przedstawiona jest na schemacie poniżej. Ścieżki 1, 2, 3, 4, 5 mogą zawierać przezroczyste zegary (Transparent clock), ale nie biorą udziału w ustalaniu hierarchii „Zegary prowadzące – Zegary podwładne”.

Faza 2 — Synchronizacja zwykłych i brzegowych zegarów

Bezpośrednio po ustaleniu hierarchii „Zegary prowadzące – Zegary podwładne” rozpoczyna się faza synchronizacji zwykłych i brzegowych zegarów.

Aby zsynchronizować, zegary prowadzące wysyłają do zegarów podwładnych wiadomość zawierającą znacznik czasu.

Zegary prowadzące mogą być:

• jednoetapowe;
• dwuetapowe.

Jednoetapowe zegary w celu synchronizacji wysyłają jedną wiadomość Sync.

Dwuetapowe zegary w celu synchronizacji używają dwóch wiadomości – Sync i Follow_Up.

W fazie synchronizacji można zastosować dwa mechanizmy:

• Mechanizm zapytania-odpowiedzi opóźnienia (Delay request-response mechanism).
• Mechanizm pomiaru opóźnienia sąsiedniego węzła (Peer delay measurement mechanism).

Na początek rozważmy te mechanizmy w najprostszym przypadku – gdy nie są stosowane przezroczyste zegary.

Mechanizm zapytania-odpowiedzi opóźnienia (Delay request-response mechanism)

Mechanizm zakłada dwa kroki:

1. Pomiar opóźnienia przy przesyłaniu wiadomości między zegarami prowadzącymi a zegarami podwładnymi. Wykonywane jest za pomocą mechanizmu zapytania-odpowiedzi opóźnienia.
2. Wykonywana jest korekcja przesunięcia dokładnego czasu.

Pomiar opóźnienia


t1 – Czas wysyłania wiadomości Sync przez zegar główny; t2 – Czas odbierania wiadomości Sync przez zegar podrzędny; t3 – Czas wysyłania żądania opóźnienia (Delay_Req) przez zegar podrzędny; t4 – Czas odbierania Delay_Req przez zegar główny.

Kiedy zegary podrzędne znają czasy t1, t2, t3 i t4, mogą obliczyć średnie opóźnienie przy przekazywaniu wiadomości synchronizacji (tmpd). Oblicza się je w następujący sposób:

Przy przesyłaniu wiadomości Sync i Follow_Up oblicza się opóźnienie czasu od głównego do podrzędnego – t-ms.

Przy przesyłaniu wiadomości Delay_Req i Delay_Resp oblicza się opóźnienie czasu od podrzędnego do głównego – t-sm.

Jeśli pomiędzy tymi dwoma wartościami występuje jakaś asymetria, pojawia się błąd korekcji odchylenia dokładnego czasu. Błąd ten wynika z faktu, że obliczone opóźnienie jest średnią z opóźnień t-ms i t-sm. Jeśli opóźnienia nie są równe, będziemy korygować czas niedokładnie.

Korekcja przesunięcia dokładnego czasu.

Po tym jak opóźnienie między zegarami głównymi a podrzędnymi jest znane, zegary podrzędne wykonują korekcję czasu.

Zegary podrzędne korzystają z wiadomości Sync oraz opcjonalnej wiadomości Follow_Up do obliczenia przesunięcia dokładnego czasu podczas przesyłania pakietu z zegara głównego do podrzędnego. Przesunięcie oblicza się według poniższego wzoru:

Mechanizm pomiaru opóźnienia sąsiedniego węzła (Peer delay measurement mechanism).

Ten mechanizm także używa dwóch kroków do synchronizacji:

1. Urządzenia mierzą opóźnienie czasu do wszystkich sąsiadów przez wszystkie porty. W tym celu korzystają z mechanizmu opóźnienia sąsiedniego.
2. Korekcja przesunięcia dokładnego czasu.

Pomiar opóźnienia między urządzeniami wspierającymi tryb Peer-to-Peer.

Opóźnienie między portami obsługującymi mechanizm peer-to-peer jest mierzone za pomocą następujących wiadomości:

Kiedy port 1 zna czasy t1, t2, t3 i t4, może obliczyć średnie opóźnienie (tmld). Oblicza się je według poniższego wzoru:

Następnie port wykorzystuje tę wartość przy obliczaniu pola korekcji dla każdej wiadomości Sync lub opcjonalnej wiadomości Follow_Up, które przechodzą przez dane urządzenie.

Ostateczne opóźnienie będzie równe sumie opóźnienia przy przesyłaniu przez dane urządzenie, średniemu opóźnieniu przy przesyłaniu przez kanał danych oraz już istniejącemu opóźnieniu w danej wiadomości, uwzględnionemu na wyższych urządzeniach.

Wiadomości Pdelay_Req, Pdelay_Resp i opcjonalne Pdelay_Resp_Follow_Up pozwalają uzyskać opóźnienie od mastera do slave'a i od slave'a do mastera (okresowe).

Jakakolwiek asymetria między tymi dwoma wartościami wprowadzi błąd korekcji przesunięcia czasu.

Korekcja przesunięcia czasu

Zegary podrzędne używają wiadomości Sync oraz opcjonalnej wiadomości Follow_Up do obliczenia przesunięcia czasu przy przesyłaniu pakietu od zegarów głównych do podrzędnych. Przesunięcie oblicza się według następującego wzoru:

Zalety mechanizmu korekcji peer-to-peer polegają na tym, że opóźnienie każdego komunikatu Sync lub Follow_Up jest obliczane w czasie jego przesyłania w sieci. W związku z tym zmiana ścieżki przesyłu nie wpłynie w żaden sposób na dokładność korekcji.

Przy użyciu tego mechanizmu synchronizacja czasu nie wymaga obliczenia opóźnienia na ścieżce, którą pokonuje pakiet synchronizacji, jak ma to miejsce w podstawowej wymianie. To znaczy, wiadomości Delay_Req i Delay_Resp nie są wysyłane. W tej metodzie opóźnienie między zegarami głównymi a podrzędnymi po prostu sumuje się w polu korekcji każdej wiadomości Sync lub Follow_Up.

Kolejną zaletą jest to, że zegary główne są zwolnione z konieczności przetwarzania wiadomości Delay_Req.

Tryby pracy zegarów transparentnych

Odpowiednio, zostały omówione proste przykłady. A teraz załóżmy, że na ścieżce synchronizacji pojawiają się przełączniki.

Jeśli używać przełączników bez wsparcia PTPv2, pakiet synchronizacji będzie opóźniony na przełączniku o około 10 µs.

Przełączniki z obsługą PTPv2 w terminologii IEEE 1588v2 nazywane są zegarami transparentnymi. Zegary transparentne nie synchronizują się z zegarami głównymi i nie uczestniczą w hierarchii „Zegary główne – Zegary podrzędne”, ale podczas przesyłania wiadomości synchronizacji zapamiętują, o ile wiadomość się opóźniła. Pozwala to skorygować opóźnienie czasu.

Zegary transparentne mogą działać w dwóch trybach:

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

End-to-End (E2E)

Zegary transparentne E2E przesyłają wiadomości Sync i towarzyszące wiadomości Follow_Up do wszystkich portów. Nawet tych, które są zablokowane przez jakiekolwiek protokoły (na przykład RSTP).

Przełącznik zapamiętuje znacznik czasowy, kiedy pakiet Sync (Follow_Up) został przyjęty na port i kiedy został wysłany z portu. Na podstawie tych dwóch znaczników czasowych oblicza się czas przetwarzania wiadomości przez przełącznik. W standardzie czas ten nazywa się czasem rezydencji.

Czas przetwarzania jest dodawany do pola correctionField wiadomości Sync (jednostopniowe zegary) lub Follow_Up (dwustopniowe zegary).

Przezroczyste zegary E2E mierzą czas przetwarzania dla wiadomości Sync i Delay_Req przechodzących przez przełącznik. Ważne jest jednak, aby rozumieć, że opóźnienie czasowe między zegarami głównymi a zegarami podrzędnymi jest obliczane za pomocą mechanizmu zapytania-odpowiedzi opóźnienia. Jeśli zegary główne zmienią się lub zmieni się ścieżka od zegarów głównych do zegarów podrzędnych, opóźnienie jest mierzone na nowo. To zwiększa czas przejściowy w przypadku zmian w sieci.

Przezroczyste zegary P2P, poza pomiarem czasu przetwarzania wiadomości przez przełącznik, mierzą opóźnienie na kanale transmisyjnym do najbliższego sąsiada, wykorzystując mechanizm pomiaru opóźnienia sąsiedniego węzła.

Opóźnienie jest mierzone na każdym kanale w obu kierunkach, w tym na kanałach, które są zablokowane przez jakikolwiek protokół (np. RSTP). Umożliwia to natychmiastowe obliczenie nowego opóźnienia na drodze synchronizacji, jeśli zmieniły się zegary grandmastera lub topologia sieci.

Czas przetwarzania wiadomości przez przełączniki oraz czas opóźnienia są gromadzone podczas przesyłania wiadomości Sync lub Follow_Up.

Typy wsparcia PTPv2 przez przełączniki

Przełączniki mogą wspierać PTPv2:

• programowo;
• sprzętowo.

W przypadku programowej realizacji protokołu PTPv2 przełącznik żąda znacznika czasowego z oprogramowania układowego. Problem polega na tym, że oprogramowanie działa cyklicznie i trzeba poczekać, aż zakończy bieżący cykl, przetworzy żądanie, a po upływie następnego cyklu wyda znacznik czasowy. Na to wszystko również będzie potrzeba czasu, co spowoduje opóźnienie, chociaż nie tak znaczące jak w przypadku braku programowego wsparcia PTPv2.

Zachowanie niezbędnej dokładności jest możliwe tylko dzięki sprzętowemu wsparciu PTPv2. W tym przypadku wydawanie znacznika czasowego odbywa się za pomocą specjalnego układu ASIC, który jest zainstalowany na porcie.

Format wiadomości

Wszystkie wiadomości PTP składają się z następujących pól:

• Nagłówek – 34 bajty.
• Ciało – rozmiar zależy od typu wiadomości.
• Suffix – opcjonalnie.

Nagłówek

Pole Header jest takie samo dla wszystkich komunikatów PTP. Jego rozmiar wynosi 34 bajty.

Format pola Header:

messageType – zawiera typ przesyłanego komunikatu, na przykład Sync, Delay_Req, PDelay_Req itd.

messageLength – zawiera całkowity rozmiar komunikatu PTP, w tym header, body i suffix (z wyjątkiem bajtów wypełniających).

domainNumber – określa, do którego domeny PTP należy komunikat.

Domena – to kilka różnych zegarów zebranych w jedną logiczną grupę i synchronizowanych od jednego zegara głównego, ale niekoniecznie zsynchronizowanych z zegarami należącymi do innej domeny.

flags – to pole zawiera różne flagi do identyfikacji statusu komunikatu.

correctionField – zawiera czas opóźnienia w nanosekundach. Czas opóźnienia obejmuje opóźnienie przy przesyłaniu przez przezroczyste zegary, a także opóźnienie przy przesyłaniu przez kanał w trybie Peer-to-Peer.

sourcePortIdentity – to pole zawiera informacje o tym, z którego portu pierwotnie wysłano dany komunikat.

sequenceID – zawiera identyfikacyjny numer dla poszczególnych komunikatów.

controlField – pole-artefakt=) Pozostało z pierwszej wersji standardu i zawiera informacje o typie wiadomości. W zasadzie to samo co messageType, ale z mniejszą liczbą opcji.

logMessageInterval – to pole jest określane przez typ komunikatu.

Treść

Jak omówiono powyżej, istnieje kilka typów komunikatów. Te typy są opisane poniżej:

Komunikat Announce
Komunikat Announce służy do "opowiadania" innym zegarom w obrębie jednej domeny o swoich parametrach. Ten komunikat pozwala ustalić hierarchię "Zegary główne – Zegary podrzędne".


Komunikat Sync
Komunikat synchronizacji (Sync) jest wysyłany przez zegary główne i zawiera czas zegarów głównych w momencie, gdy komunikat Sync został stworzony. Jeśli zegary główne są dwustopniowe, znacznik czasu w komunikacie Sync będzie równy 0, a aktualny znacznik czasu będzie wysyłany w powiązanym komunikacie Follow_Up. Komunikat Sync jest używany dla obu mechanizmów pomiaru opóźnienia.

Komunikat jest przesyłany za pomocą Multicast. Opcjonalnie można używać Unicast.

Komunikat Delay_Req

Format komunikatu Delay_Req jest taki sam jak komunikatu Sync. Zegary podrzędne wysyłają Delay_Req. Zawiera czas wysłania Delay_Req przez zegary podrzędne. Ten komunikat jest używany tylko w mechanizmie żądania-odpowiedzi opóźnienia.

Komunikat jest przesyłany za pomocą Multicast. Opcjonalnie można używać Unicast.

Wiadomość Follow_Up

Wiadomość Follow_Up jest opcjonalnie wysyłana przez prowadzące zegary i zawiera czas wysłania wiadomości Sync mistrzem. Wiadomość Follow_Up wysyłają tylko dwustopniowe prowadzące zegary.

Wiadomość Follow_Up jest używana do obu mechanizmów pomiaru opóźnienia.

Komunikat jest przesyłany za pomocą Multicast. Opcjonalnie można używać Unicast.

Wiadomość Delay_Resp

Wiadomość Delay_Resp jest wysyłana przez prowadzące zegary. Zawiera czas przyjęcia Delay_Req przez prowadzące zegary. Ta wiadomość jest używana tylko w mechanizmie zapytania-odpowiedzi opóźnienia.

Komunikat jest przesyłany za pomocą Multicast. Opcjonalnie można używać Unicast.

Wiadomość Pdelay_Req

Wiadomość Pdelay_Req jest wysyłana przez urządzenie, które żąda opóźnienia. Zawiera czas wysłania wiadomości z portu tego urządzenia. Pdelay_Req jest używana tylko w mechanizmie pomiaru opóźnienia sąsiedniego węzła.

Wiadomość Pdelay_Resp

Wiadomość Pdelay_Resp jest wysyłana przez urządzenie, które otrzymało żądanie opóźnienia. Zawiera czas przyjęcia wiadomości Pdelay_Req przez to urządzenie. Wiadomości Pdelay_Resp są używane tylko w mechanizmie pomiaru opóźnienia sąsiedniego węzła.

Wiadomość Pdelay_Resp_Follow_Up

Wiadomość Pdelay_Resp_Follow_Up jest opcjonalnie wysyłana przez urządzenie, które otrzymało żądanie opóźnienia. Zawiera czas przyjęcia wiadomości Pdelay_Req przez to urządzenie. Wiadomość Pdelay_Resp_Follow_Up jest wysyłana tylko przez dwustopniowe prowadzące zegary.

Ta wiadomość może być również używana dla czasu wykonania zamiast znacznika czasu. Czas wykonania to czas od momentu otrzymania Pdelay-Req do wysłania Pdelay_Resp.

Pdelay_Resp_Follow_Up są używane tylko w mechanizmie pomiaru opóźnienia sąsiedniego węzła.

Wiadomości zarządzające (Wiadomość Management)

Wiadomości zarządzające PTP są niezbędne do przesyłania informacji między jednym lub wieloma zegarami a węzłem zarządzającym.

Przesyłanie w LV

Wiadomość PTP może być przesyłana na dwóch poziomach:

• Sieciowym – jako część danych IP.
• Liniowym – jako część ramki Ethernet.

Przesyłanie wiadomości PTP przez UDP przez IP przez Ethernet

PTP przez UDP przez Ethernet

Profile

PTP ma dość dużo «elastycznych» parametrów, które należy skonfigurować. Na przykład:

• Opcje BMCA.
• Mechanizm pomiaru opóźnienia.
• Interwały i początkowe wartości wszystkich konfigurowalnych parametrów itp.

I mimo że wcześniej mówiliśmy, że urządzenia PTPv2 są między sobą zgodne, w rzeczywistości tak nie jest. Urządzenia muszą mieć takie same ustawienia, aby mogły ze sobą współpracować.

Dlatego istnieją tzw. profile PTPv2. Profile to grupy skonfigurowanych ustawień oraz określonych ograniczeń protokołu, które umożliwiają realizację synchronizacji czasu dla konkretnej aplikacji.

Sam standard IEEE 1588v2 opisuje tylko jeden profil - „Profil domyślny”. Wszystkie pozostałe profilu zostały stworzone i opisane przez różne organizacje i stowarzyszenia.

Na przykład, profil dla elektroenergetyki lub PTPv2 Power Profile został stworzony przez Komitet Systemów Przesyłowych oraz Komitet Stacji Transformacyjnych Towarzystwa IEEE Power and Energy Society. Sam profil nosi nazwę IEEE C37.238-2011.

Profil opisuje, w jaki sposób PTP może być przesyłany:

• Wyłącznie przez sieci L2 (tj. Ethernet, HSR, PRP, nie IP).
• Wiadomości są przesyłane tylko w sposób Multicast.
• Jako mechanizm pomiaru opóźnienia wykorzystuje się mechanizm pomiaru opóźnienia pomiędzy portami.

Domyślny domen to 0, zalecany domen to 93.

Filozofią stworzenia C37.238-2011 było pragnienie zmniejszenia liczby opcjonalnych cech i pozostawienie tylko niezbędnych funkcji zapewniających niezawodną współpracę pomiędzy urządzeniami oraz zwiększających stabilność systemu.

Określono również częstotliwość przesyłania wiadomości:

W zasadzie dostępny jest tylko jeden parametr - typ głównych zegarów (jednoetapowe lub dwuetapowe).

Dokładność nie powinna przekraczać 1 μs. Innymi słowy, w jednej ścieżce synchronizacji może znajdować się maksymalnie 15 przezroczystych zegarów lub trzy zegary brzeżne.

Źródło: habr.com