Szczegóły implementacji protokołu synchronizacji czasu PTPv2

Wprowadzenie

Koncepcja budowy „Cyfrowej Podstacji” w elektroenergetyce wymaga synchronizacji z dokładnością do 1 μs. Transakcje finansowe również wymagają dokładności rzędu mikrosekund. W tych zastosowaniach dokładność czasu NTP nie jest już wystarczająca.

Protokół synchronizacji PTPv2, opisany standardem IEEE 1588v2, pozwala na dokładność synchronizacji rzędu kilkudziesięciu nanosekund. PTPv2 umożliwia wysyłanie pakietów synchronizacji przez sieci L2 i L3.

Główne obszary zastosowania protokołu PTPv2 to:

• energia;
• sprzęt kontrolno-pomiarowy;
• kompleks wojskowo-przemysłowy;
• telekomunikacja;
• sektor finansowy.

W tym poście wyjaśniono, jak działa protokół synchronizacji PTPv2.

Mamy większe doświadczenie w przemyśle i często spotykamy ten protokół w zastosowaniach energetycznych. W związku z tym dokonamy przeglądu z ostrożnością dla energii.

Dlaczego jest to konieczne?

W tej chwili STO 34.01-21-004-2019 firmy PJSC Rosseti i STO 56947007-29.240.10.302-2020 firmy PJSC FGC UES zawierają wymagania dotyczące organizacji magistrali procesowej z synchronizacją czasu poprzez PTPv2.

Wynika to z faktu, że do szyny procesowej podłączone są zaciski zabezpieczeń przekaźnikowych oraz urządzenia pomiarowe, które poprzez szynę procesową przesyłają chwilowe wartości prądów i napięć, wykorzystując tzw. strumienie SV (strumienie multicast).

Zaciski zabezpieczające przekaźnika wykorzystują te wartości do realizacji zabezpieczenia pola. Jeżeli dokładność pomiaru czasu jest mała, wówczas niektóre zabezpieczenia mogą działać fałszywie.

Na przykład mechanizmy obronne absolutnej selektywności mogą paść ofiarą „słabej” synchronizacji czasu. Często logika takiej obrony opiera się na porównaniu dwóch wielkości. Jeśli wartości różnią się o wystarczająco dużą wartość, następuje zadziałanie zabezpieczenia. Jeśli wartości te są mierzone z dokładnością czasową 1 ms, to można uzyskać dużą różnicę tam, gdzie wartości są rzeczywiście normalne, jeśli są mierzone z dokładnością do 1 μs.

wersje PTP

Protokół PTP został pierwotnie opisany w 2002 roku w standardzie IEEE 1588-2002 i nosił nazwę „Standard dla protokołu precyzyjnej synchronizacji zegara dla sieciowych systemów pomiarowych i sterujących”. W 2008 roku wydano zaktualizowany standard IEEE 1588-2008, który opisuje wersję 2 PTP. Ta wersja protokołu poprawiła dokładność i stabilność, ale nie zachowała kompatybilności wstecznej z pierwszą wersją protokołu. Ponadto w 2019 roku ukazała się wersja standardu IEEE 1588-2019 opisująca PTP v2.1. Ta wersja dodaje drobne ulepszenia do PTPv2 i jest wstecznie kompatybilna z PTPv2.

Inaczej mówiąc, mamy następujący obrazek z wersjami:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

-
Niekompatybilny

Niekompatybilny

PTPv2 (IEEE 1588-2008)

Niekompatybilny

-
Zgodny

PTPv2.1 (IEEE 1588-2019)

Niekompatybilny

Zgodny

-

Ale jak zawsze są niuanse.

Niezgodność między protokołami PTPv1 i PTPv2 oznacza, że ​​urządzenie obsługujące protokół PTPv1 nie będzie w stanie zsynchronizować się z dokładnym zegarem działającym w trybie PTPv2. Do synchronizacji używają różnych formatów wiadomości.

Jednak nadal możliwe jest łączenie urządzeń z protokołem PTPv1 i urządzeniami z protokołem PTPv2 w tej samej sieci. Aby to osiągnąć, niektórzy producenci umożliwiają wybranie wersji protokołu na portach zegara brzegowego. Oznacza to, że zegar graniczny może synchronizować się przy użyciu protokołu PTPv2 i nadal synchronizować inne podłączone do niego zegary przy użyciu zarówno protokołu PTPv1, jak i PTPv2.

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

Standard IEEE 1588v2 opisuje kilka typów urządzeń. Wszystkie zostały pokazane w tabeli.

Urządzenia komunikują się ze sobą poprzez sieć LAN za pomocą protokołu PTP.

Urządzenia PTP nazywane są zegarami. Wszystkie zegarki odmierzają dokładny czas z zegarka arcymistrzowskiego.

Istnieje 5 rodzajów zegarków:

Zegar arcymistrzowski

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

Zwykły zegar

Urządzenie z jednym portem, które może być urządzeniem nadrzędnym (zegar główny) lub podrzędnym (zegar podrzędny)

Zegar główny (główny)

Są źródłem dokładnego czasu synchronizacji innych zegarów

Zegar niewolnik

Urządzenie końcowe synchronizowane z zegarem głównym

Zegar graniczny

Urządzenie z wieloma portami, które może być urządzeniem nadrzędnym lub podrzędnym.

Oznacza to, że zegary te mogą synchronizować się z nadrzędnym zegarem głównym i synchronizować podrzędne zegary podrzędne.

Kompleksowy przezroczysty zegar

Urządzenie z wieloma portami, które nie jest ani zegarem głównym, ani urządzeniem podrzędnym. Przesyła dane PTP pomiędzy dwoma zegarkami.

Podczas transmisji danych przezroczysty zegar koryguje wszystkie komunikaty PTP.

Korekta następuje 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 urządzeniem podrzędnym.
Przesyła dane PTP pomiędzy dwoma zegarkami.

Podczas transmisji danych przezroczysty zegar koryguje wszystkie komunikaty PTP Sync i Follow_Up (więcej o nich poniżej).

Korektę uzyskuje się poprzez dodanie do pola korekcji przesyłanego pakietu opóźnienia w urządzeniu nadawczym i opóźnienia w kanale transmisji danych.

Węzeł zarządzający

Urządzenie konfigurujące i diagnozujące inne zegarki

Zegary główne i podrzędne są synchronizowane przy użyciu znaczników czasu w wiadomościach PTP. W protokole PTP występują dwa typy komunikatów:

• Wiadomości o zdarzeniach to zsynchronizowane wiadomości, które wymagają wygenerowania znacznika czasu w chwili wysłania wiadomości i w chwili jej odebrania.
• Wiadomości ogólne — te wiadomości nie wymagają znaczników czasu, ale mogą zawierać znaczniki czasu dla powiązanych wiadomości

Wiadomości o wydarzeniach

Wiadomości ogólne

Sync
Opóźnienie_Wymaganie
Pdelay_Req
Pdelay_Resp

Ogłosić
Podejmować właściwe kroki
Opóźnienie_Resp
Pdelay_Resp_Follow_Up
Zarządzanie
Sygnalizacja

Wszystkie rodzaje wiadomości zostaną omówione bardziej szczegółowo poniżej.

Podstawowe problemy z synchronizacją

Gdy pakiet synchronizacji jest przesyłany przez sieć lokalną, jest opóźniany na przełączniku i łączu danych. Każdy przełącznik spowoduje opóźnienie wynoszące około 10 mikrosekund, co jest niedopuszczalne w przypadku protokołu PTPv2. W końcu na urządzeniu końcowym musimy osiągnąć dokładność 1 μs. (To dotyczy energii. Inne zastosowania mogą wymagać większej dokładności.)

IEEE 1588v2 opisuje kilka algorytmów działania, które pozwalają rejestrować opóźnienie czasowe i korygować je.

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

• Faza 1 - ustalenie hierarchii „Zegar główny – zegar podrzędny”.
• Faza 2 - synchronizacja zegara z wykorzystaniem mechanizmu End-to-End lub Peer-to-Peer.

Faza 1 – Ustanawianie hierarchii master-slave

Każdy port zegara zwykłego lub brzegowego ma określoną liczbę stanów (zegar podrzędny i zegar główny). Norma opisuje algorytm przejścia pomiędzy tymi stanami. W programowaniu taki algorytm nazywany jest skończoną maszyną stanów lub maszyną stanów (więcej szczegółów na Wiki).

Ta maszyna stanu wykorzystuje algorytm Best Master Clock Algorithm (BMCA) do ustawiania mastera podczas podłączania dwóch zegarów.

Algorytm ten pozwala zegarkowi przejąć obowiązki zegarka arcymistrzowskiego, gdy zegarek arcymistrzowski znajdujący się wcześniej utraci sygnał GPS, przejdzie w tryb offline itp.

Przejścia stanów zgodnie z BMCA podsumowano na poniższym schemacie:


Informacja o zegarku na drugim końcu „drutu” przesyłana jest w specjalnej wiadomości (Wiadomość announce). Po otrzymaniu tych informacji uruchamiany jest algorytm maszyny stanowej i przeprowadzane jest porównanie, aby sprawdzić, który zegar jest lepszy. Port najlepszego zegarka staje się zegarkiem głównym.

Prostą hierarchię pokazano na poniższym schemacie. Ścieżki 1, 2, 3, 4, 5 mogą zawierać zegar przezroczysty, ale nie biorą one udziału w ustanawianiu hierarchii Zegar główny - Zegar podrzędny.

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

Natychmiast po ustaleniu hierarchii „Zegar Główny – Zegar Podrzędny” rozpoczyna się faza synchronizacji zegarów regularnych i brzegowych.

Aby zsynchronizować, zegar główny wysyła wiadomość zawierającą znacznik czasu do zegarów podrzędnych.

Zegar główny może być:

• Pojedyncza scena;
• dwuetapowy.

Zegary jednostopniowe wysyłają jeden komunikat synchronizacji w celu synchronizacji.

Zegar dwustopniowy wykorzystuje do synchronizacji dwa komunikaty – Sync i Follow_Up.

W fazie synchronizacji można zastosować dwa mechanizmy:

• Opóźnienie mechanizmu żądanie-odpowiedź.
• Mechanizm pomiaru opóźnienia równorzędnego.

Najpierw przyjrzyjmy się tym mechanizmom w najprostszym przypadku - gdy nie używa się przezroczystych zegarków.

Opóźnienie mechanizmu żądanie-odpowiedź

Mechanizm składa się z dwóch etapów:

1. Pomiar opóźnienia w transmisji komunikatu pomiędzy zegarem głównym a zegarem podrzędnym. Wykonywane przy użyciu mechanizmu opóźnienia żądanie-odpowiedź.
2. Następuje korekta dokładnego przesunięcia czasowego.

Pomiar opóźnienia


t1 – Czas wysłania wiadomości Sync przez zegar główny; t2 – Czas odebrania komunikatu Sync przez zegar slave; t3 – Czas wysłania żądania opóźnienia (Delay_Req) ​​przez zegar slave; t4 – Czas odbioru Delay_Req przez zegar główny.

Gdy zegar podrzędny zna czasy t1, t2, t3 i t4, może obliczyć średnie opóźnienie podczas przesyłania komunikatu synchronizacji (tmpd). Oblicza się go w następujący sposób:

Podczas transmisji komunikatu Sync i Follow_Up obliczane jest opóźnienie czasowe od urządzenia nadrzędnego do urządzenia podrzędnego - t-ms.

Podczas transmisji komunikatów Delay_Req i Delay_Resp obliczane jest opóźnienie czasowe od urządzenia slave do urządzenia master - t-sm.

Jeśli pomiędzy tymi dwiema wartościami wystąpi asymetria, pojawia się błąd w korygowaniu odchylenia dokładnego czasu. Błąd wynika z faktu, że obliczone opóźnienie jest średnią opóźnień t-ms i t-sm. Jeśli opóźnienia nie są sobie równe, nie dostosujemy dokładnie czasu.

Korekta przesunięcia czasowego

Gdy znane jest opóźnienie pomiędzy zegarem głównym a zegarem podrzędnym, zegar podrzędny przeprowadza korektę czasu.

Zegary slave wykorzystują komunikat Sync i opcjonalny komunikat Follow_Up do obliczenia dokładnego przesunięcia czasowego podczas przesyłania pakietu od zegarów master do zegarów slave. Przesunięcie oblicza się za pomocą następującego wzoru:

Mechanizm pomiaru opóźnienia równorzędnego

Mechanizm ten wykorzystuje również dwa etapy synchronizacji:

1. Urządzenia mierzą opóźnienie czasowe do wszystkich sąsiadów poprzez wszystkie porty. Aby to zrobić, używają mechanizmu opóźnienia równorzędnego.
2. Korekta dokładnego przesunięcia czasowego.

Pomiar opóźnień między urządzeniami obsługującymi tryb peer-to-peer

Opóźnienie pomiędzy portami obsługującymi mechanizm peer-to-peer mierzone jest za pomocą następujących komunikatów:

Gdy port 1 zna czasy t1, t2, t3 i t4, może obliczyć średnie opóźnienie (tmld). Oblicza się go za pomocą następującego wzoru:

Następnie port wykorzystuje tę wartość podczas obliczania pola regulacji dla każdego komunikatu synchronizacji lub opcjonalnego komunikatu Follow_Up, który przechodzi przez urządzenie.

Całkowite opóźnienie będzie równe sumie opóźnienia podczas transmisji przez to urządzenie, średniego opóźnienia podczas transmisji przez kanał danych i opóźnienia już zawartego w tej wiadomości, włączonego na urządzeniach nadrzędnych.

Komunikaty Pdelay_Req, Pdelay_Resp i opcjonalnie Pdelay_Resp_Follow_Up pozwalają uzyskać opóźnienie od urządzenia master do slave i od urządzenia slave do master (okrągłe).

Jakakolwiek asymetria pomiędzy tymi dwoma wartościami spowoduje błąd korekcji przesunięcia czasowego.

Regulacja dokładnego przesunięcia czasowego

Zegary slave wykorzystują komunikat Sync i opcjonalny komunikat Follow_Up do obliczenia dokładnego przesunięcia czasowego podczas przesyłania pakietu od zegarów master do zegarów slave. Przesunięcie oblicza się za pomocą następującego wzoru:

Zalety dostosowania mechanizmu peer-to-peer - opóźnienie czasowe każdego komunikatu Sync lub Follow_Up liczone jest w miarę jego transmisji w sieci. W związku z tym zmiana ścieżki transmisji nie wpłynie w żaden sposób na dokładność regulacji.

Przy zastosowaniu tego mechanizmu synchronizacja czasu nie wymaga obliczania opóźnienia czasowego na drodze, którą przebywa pakiet synchronizacyjny, jak ma to miejsce w wymianie podstawowej. Te. Komunikaty Delay_Req i Delay_Resp nie są wysyłane. W tej metodzie opóźnienie pomiędzy zegarami głównym i podrzędnym jest po prostu sumowane w polu regulacji każdego komunikatu Sync lub Follow_Up.

Kolejną zaletą jest to, że zegar główny jest zwolniony z konieczności przetwarzania komunikatów Delay_Req.

Tryby pracy zegarów przezroczystych

W związku z tym były to proste przykłady. Załóżmy teraz, że na ścieżce synchronizacji pojawiają się przełączniki.

Jeśli używasz przełączników bez obsługi PTPv2, pakiet synchronizacji będzie opóźniony na przełączniku o około 10 μs.

Przełączniki obsługujące PTPv2 nazywane są zegarami przezroczystymi w terminologii IEEE 1588v2. Zegary przezroczyste nie są synchronizowane z zegarem głównym i nie uczestniczą w hierarchii „Zegar główny - Zegar podrzędny”, ale przesyłając komunikaty synchronizacyjne, pamiętają, jak długo komunikat był przez nie opóźniony. Dzięki temu można dostosować opóźnienie czasowe.

Przezroczyste zegary mogą pracować w dwóch trybach:

• Koniec końców.
• Każdy z każdym.

Kompleksowo (E2E)

Przezroczysty zegar E2E transmituje komunikaty Sync i towarzyszące im komunikaty Follow_Up na wszystkich portach. Nawet te, które są blokowane przez niektóre protokoły (na przykład RSTP).

Przełącznik zapamiętuje znacznik czasu odebrania pakietu Sync (Follow_Up) na porcie i chwili wysłania go z portu. Na podstawie tych dwóch znaczników czasu obliczany jest czas potrzebny przełącznikowi na przetworzenie komunikatu. W standardzie czas ten nazywany jest czasem przebywania.

Czas przetwarzania jest dodawany do pola CorrectField komunikatu Sync (zegar jednoetapowy) lub Follow_Up (zegar dwuetapowy).

Przezroczysty zegar E2E mierzy czas przetwarzania komunikatów Sync i Delay_Req przechodzących przez przełącznik. Ważne jest jednak, aby zrozumieć, że opóźnienie czasowe pomiędzy zegarem głównym a zegarem podrzędnym jest obliczane przy użyciu mechanizmu opóźnienia żądanie-odpowiedź. Jeśli zmieni się zegar główny lub zmieni się ścieżka od zegara głównego do zegara podrzędnego, opóźnienie jest mierzone ponownie. Wydłuża to czas przejścia w przypadku zmian w sieci.

Transparentny zegar P2P oprócz pomiaru czasu potrzebnego przełącznikowi na przetworzenie komunikatu, mierzy także opóźnienie łącza danych do najbliższego sąsiada, korzystając z mechanizmu opóźnień sąsiadów.

Opóźnienie jest mierzone na każdym łączu w obu kierunkach, łącznie z łączami blokowanymi przez jakiś protokół (taki jak RSTP). Pozwala to na natychmiastowe obliczenie nowego opóźnienia na ścieżce synchronizacji w przypadku zmiany zegara głównego lub topologii sieci.

Czas przetwarzania wiadomości według przełączników i opóźnienia są kumulowane podczas wysyłania wiadomości Sync lub Follow_Up.

Rodzaje obsługi PTPv2 przez przełączniki

Przełączniki obsługują PTPv2:

• programowo;
• sprzęt komputerowy.

Podczas implementowania protokołu PTPv2 w oprogramowaniu przełącznik żąda znacznika czasu z oprogramowania sprzętowego. Problem w tym, że firmware działa cyklicznie i trzeba będzie poczekać aż zakończy bieżący cykl, przyjmie żądanie do przetworzenia i wystawi znacznik czasu po kolejnym cyklu. To również zajmie trochę czasu i otrzymamy opóźnienie, choć nie tak znaczące, jak bez obsługi oprogramowania dla PTPv2.

Tylko sprzętowa obsługa PTPv2 pozwala zachować wymaganą dokładność. W tym przypadku znacznik czasu jest wydawany przez specjalny układ ASIC zainstalowany na porcie.

Format wiadomości

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

• Nagłówek – 34 bajty.
• Treść – rozmiar zależy od rodzaju wiadomości.
• Przyrostek jest opcjonalny.

Nagłówek

Pole Nagłówek jest takie samo dla wszystkich wiadomości PTP. Jego rozmiar to 34 bajty.

Format pola nagłówka:

typ wiadomości – zawiera typ przesyłanej wiadomości, na przykład Sync, Delay_Req, PDelay_Req itp.

długość wiadomości – zawiera pełny rozmiar wiadomości PTP, łącznie z nagłówkiem, treścią i przyrostkiem (ale z wyłączeniem bajtów dopełniających).

numer domeny – określa do jakiej domeny PTP należy dana wiadomość.

Домен - to kilka różnych zegarów zebranych w jedną grupę logiczną i zsynchronizowanych z jednego zegara głównego, ale niekoniecznie zsynchronizowanych z zegarami należącymi do innej domeny.

Flagi – To pole zawiera różne flagi identyfikujące status wiadomości.

Pole korekcyjne – zawiera czas opóźnienia w nanosekundach. Czas opóźnienia obejmuje opóźnienie podczas transmisji przez przezroczysty zegar, a także opóźnienie podczas transmisji przez kanał w trybie Peer-to-Peer.

tożsamośćportu źródłowego – w tym polu znajduje się informacja z jakiego portu została pierwotnie wysłana dana wiadomość.

identyfikator sekwencji – zawiera numer identyfikacyjny poszczególnych komunikatów.

Pole kontrolne – pole artefaktu =) Pozostaje z pierwszej wersji standardu i zawiera informację o typie tego komunikatu. Zasadniczo taki sam jak MessageType, ale z mniejszą liczbą opcji.

logMessageInterwał – pole to jest zależne od rodzaju wiadomości.

Ciało

Jak omówiono powyżej, istnieje kilka typów wiadomości. Typy te opisano poniżej:

Wiadomość ogłoszeniowa
Komunikat Announce służy do „informowania” innych zegarów w tej samej domenie o jego parametrach. Ten komunikat umożliwia ustawienie hierarchii Zegar główny - Zegar podrzędny.


Synchronizuj wiadomość
Komunikat Sync jest wysyłany przez zegar główny i zawiera czas zegara głównego w chwili wygenerowania komunikatu Sync. Jeśli zegar główny jest dwustopniowy, wówczas znacznik czasu w wiadomości Sync zostanie ustawiony na 0, a bieżący znacznik czasu zostanie wysłany w powiązanej wiadomości Follow_Up. Wiadomość Sync jest używana w obu mechanizmach pomiaru opóźnienia.

Wiadomość jest przesyłana przy użyciu metody Multicast. Opcjonalnie możesz użyć Unicast.

Komunikat Opóźnienie_Wymagania

Format wiadomości Delay_Req jest identyczny z wiadomością Sync. Zegar slave wysyła Delay_Req. Zawiera czas wysłania Delay_Req przez zegar slave. Ten komunikat jest używany tylko w mechanizmie opóźnienia żądanie-odpowiedź.

Wiadomość jest przesyłana przy użyciu metody Multicast. Opcjonalnie możesz użyć Unicast.

Wiadomość uzupełniająca

Wiadomość Follow_Up jest opcjonalnie wysyłana przez zegar główny i zawiera czas wysłania Synchronizuj wiadomości gospodarz. Tylko dwustopniowe zegary główne wysyłają komunikat Follow_Up.

Komunikat Follow_Up jest używany w obu mechanizmach pomiaru opóźnienia.

Wiadomość jest przesyłana przy użyciu metody Multicast. Opcjonalnie możesz użyć Unicast.

Komunikat Opóźnienie_Resp

Komunikat Delay_Resp jest wysyłany przez zegar główny. Zawiera czas, w którym zegar główny odebrał Delay_Req. Ten komunikat jest używany tylko w mechanizmie opóźnienia żądanie-odpowiedź.

Wiadomość jest przesyłana przy użyciu metody Multicast. Opcjonalnie możesz użyć Unicast.

Komunikat Pdelay_Req

Komunikat Pdelay_Req jest wysyłany przez urządzenie żądające opóźnienia. Zawiera godzinę wysłania wiadomości z portu tego urządzenia. Pdelay_Req jest używany tylko w mechanizmie pomiaru opóźnienia sąsiada.

Komunikat Pdelay_Resp

Komunikat Pdelay_Resp jest wysyłany przez urządzenie, które odebrało żądanie opóźnienia. Zawiera godzinę odebrania wiadomości Pdelay_Req przez to urządzenie. Komunikat Pdelay_Resp jest używany tylko w mechanizmie pomiaru opóźnienia sąsiada.

Wiadomość Pdelay_Resp_Follow_Up

Komunikat Pdelay_Resp_Follow_Up jest opcjonalnie wysyłany przez urządzenie, które odebrało żądanie opóźnienia. Zawiera godzinę odebrania wiadomości Pdelay_Req przez to urządzenie. Komunikat Pdelay_Resp_Follow_Up wysyłany jest wyłącznie przez dwustopniowe zegary główne.

Komunikatu tego można również użyć do określenia czasu wykonania zamiast znacznika czasu. Czas wykonania to czas od momentu odebrania Pdelay-Req do wysłania Pdelay_Resp.

Pdelay_Resp_Follow_Up są używane tylko w mechanizmie pomiaru opóźnienia sąsiada.

Wiadomości Zarządu

Komunikaty sterujące PTP są wymagane do przesyłania informacji pomiędzy jednym lub większą liczbą zegarów a węzłem sterującym.

Przejazd do LV

Komunikat PTP może być przesyłany na dwóch poziomach:

• Sieć – w ramach danych IP.
• Kanał – jako część ramki Ethernet.

Transmisja komunikatów PTP przez UDP przez IP przez Ethernet

PTP przez UDP przez Ethernet

Profile

PTP ma sporo elastycznych parametrów, które należy skonfigurować. Na przykład:

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

I pomimo tego, że już wcześniej powiedzieliśmy, że urządzenia PTPv2 są ze sobą kompatybilne, nie jest to prawdą. Aby urządzenia mogły się komunikować, muszą mieć te same ustawienia.

Dlatego istnieją tak zwane profile PTPv2. Profile to grupy skonfigurowanych ustawień i zdefiniowanych ograniczeń protokołu, dzięki którym można wdrożyć synchronizację czasu dla konkretnej aplikacji.

Sam standard IEEE 1588v2 opisuje tylko jeden profil – „Profil domyślny”. Wszystkie pozostałe profile są tworzone i opisywane przez różne organizacje i stowarzyszenia.

Na przykład profil zasilania lub profil zasilania PTPv2 został stworzony przez Komitet ds. przekaźników systemów zasilania i Komitet ds. podstacji stowarzyszenia IEEE Power and Energy Society. Sam profil nosi nazwę IEEE C37.238-2011.

W profilu opisano, że PTP można przenieść:

• Tylko poprzez sieci L2 (tj. Ethernet, HSR, PRP, inne niż IP).
• Wiadomości są przesyłane wyłącznie w trybie multiemisji.
• Mechanizm pomiaru opóźnienia równorzędnego jest używany jako mechanizm pomiaru opóźnienia.

Domyślna domena to 0, zalecana domena to 93.

Filozofia projektowania C37.238-2011 polegała na zmniejszeniu liczby opcjonalnych funkcji i zachowaniu jedynie niezbędnych funkcji dla niezawodnej interakcji pomiędzy urządzeniami i zwiększonej stabilności systemu.

Określana jest również częstotliwość transmisji komunikatów:

W rzeczywistości do wyboru dostępny jest tylko jeden parametr - typ zegara głównego (jednostopniowy lub dwustopniowy).

Dokładność nie powinna przekraczać 1 μs. Innymi słowy, jedna ścieżka synchronizacji może zawierać maksymalnie 15 zegarów przezroczystych lub trzy zegary graniczne.

Źródło: www.habr.com