TSN (Time Sensitive Networking) – wschodząca nowa jakość Ethernetu

TSN i jego standardy umożliwiają przesyłanie w tle siecią Ethernet ruchu o niskim priorytecie w sposób nie wpływający na ruch krytyczny czasowo.

Używając przykładu z telemedycyny, sieć TSN umożliwia zdalną operację chirurgiczną z użyciem robota, którego sterowanie odbywa się tym samym Ethernetem, z którego jednocześnie korzystają wszyscy.

W przemyśle procedury krytyczne czasowo dotyczą sterowania w czasie rzeczywistym np. robotami na produkcji (OT – ang. Operation Technology), podczas gdy poprzez operacje o niskim priorytecie rozumie się klasyczne operacje IT związane z przetwarzaniem danych, obsługą poczty, Internetu, baz danych SQL, obiegiem e-dokumentów, archiwizacją itp.

Kartka z historii

Inspiracją do prac nad TSN były systemy sieciowego streamingu AVB (ang. Audio Video Bridging) oraz rozwiązania przemysłowe klasy QoS (ang. Quality Of Service). Zamykając sterowanie w samouczącej się pętli sprzężenia zwrotnego (ang. Locked Loop), stworzono nowy predykcyjny mechanizm sterowania, pozwalający przewidywać stan jaki wystąpi w kolejnych chwilach i dopasowujący doń precyzyjnie parametry sterujące.

To pozwoliło podzielić czas na równe interwały (ramki czasu), w których sterownik przemysłowy z usługą działała deterministycznie i może pracować całkowicie autonomicznie, samemu podejmując decyzje. Tym samym zmniejsza on ilość przesyłanej siecią informacji do minimum i jest bardziej samodzielny. A skoro można powierzyć samodzielność procesowi i „spuścić go z oka” na chwilę, to nie wymaga on też ciągłości transmisji sterującej przekazywanej siecią. Pozwoliło to wydzielić odseparowane zsynchronizowane pasma, oparte o przedziały ramek czasowych (ang. time slots), których priorytetami można zarządzać, realizując w ten sposób efekt zrównoleglenia sterowania, spostrzegany jako współbieżność (jednoczesność) pracy wielu różnych urządzeń włączonych fizycznie do tej samej pojedynczej sieci Ethernet. Tak powstał pierwszy TSN umożliwiający TCC (ang. Time Coordinating Computing).

Sterowanie automatyką i synchronizacja w jednej sieci Ethernet TSN

Przy okazji zauważono, że przez Ethernet można równolegle z danymi przesyłać telemetrię (dane) zegara referencyjnego odniesienia, niezbędną do synchronizacji rozproszonych elementów sieci. Inspiracją stał się protokół NTP (ang. Network Time Protocol), w którym mechanizm synchronizacji oparto właśnie o predykcję wskazań zegara w kolejnych momentach przyszłości i udało się taką techniką osiągnąć niebywały stopień dokładności. Parafrazując, dystrybucja wzorca czasu NTP siecią Ethernet TCP/IP, różni się od klasycznego podejścia znanej nam regulacji zegarów, gdzie pytamy „która godzina” po czym ustawiamy swój zegarek. Tę różnicę stanowi predykcja ustawień parametrów chodu zegara (np. krok pracy sekundnika wyznaczającego wzorzec częstotliwości) tak, aby ten osiągnął w oczekiwanym momencie przyszłości zakładaną dokładność wskazań czasu zgodną z wzorcem UTC. To nowe podejście początkowo wydaje się trudne koncepcyjnie, ale spróbujmy wyobrazić sobie to samo na przykładzie pomiaru odległości w oparciu o chód. Chcemy pokonać 100m w 100 krokach, więc staramy się tak dobrać (w oparciu o doświadczenia) długość kroku, aby po wykonaniu 100 kroków znaleźć się u celu. W użytym porównaniu nasz krok powinien pokonywać dystans dokładnie 1 metra.

W NTP zegar referencyjny MASTER (często używa się angielskiego terminu TIME-SERVER – w języku polskim SERWER CZASU) przesyła obok wskazania UTC (ang. Universal Time Coordinated) również statystykę błędów zegara wzorcowego, na podstawie której to zegar synchronizowany SUB-MASTER (SLAVE) planuje korektę swojej pracy tak, aby w kolejnej chwili kontrolnej znaleźć się jak najbliżej wzorca UTC. Czynność wymiany statystyk odbywa się cyklicznie co pozwala wyliczyć średnie opóźnienie sieci nawet przy rozsynchronizowanych jeszcze zegarach.

Ostatecznie w TSN zastąpiono NTP protokołem nowszej generacji PTP IEEE1588 (ang. Precision Time Protocol), który cechuje bardzo szybki rozruch po włączeniu zasilania oraz sub-mikrosekundowe dokładności, dzięki zastosowaniu sprzętowego stemplowania ramek czasowych z korektą opóźnienia, jaką wnosi komputer i karta sieciowa.

Innowacja – istota wartości TSN

Ujmując krótko, TSN wprowadza do Ethernetu determinizm, czas rzeczywisty (RT – Real Time) i inteligentne współdzielenie sieci między niezależne procesy (urządzenia i użytkowników). Umożliwia połączenie sieci kablowej, światłowodowej i radiowej jednym standardem, dziś określanym jako TSN. Dostarcza narzędzia niezbędne do parametryzacji oraz oceny wydajności. Otwiera możliwość skalowalności, a nawet wirtualizacji TSN VLAN – od rozbudowy sterowania lokalną produkcją, po łączenie rozproszonych systemów telemetrii M2M, a nawet całych inteligentnych fabryk przemysłu 4.0.

W przyszłości, TSN umożliwi zdalne projektowanie i wdrażanie sterowania robotami bez ryzyka destabilizacji środowiska produkcyjnego. Sieci TSN są już przygotowywane do integracji i współpracy z CLOUD/EDGE/FOG-computing, co pozwala przenieść część obliczeń do chmury po to, aby uzyskać wsparcie narzędzi Big Data, Machine Learning (ML), Artificial Intelligence (AI). Rozważane są transfery całych kontenerów, stosując narzędzia typu Docker i Kubernetes do ich zarządzania. Pozwoli to na szybkie modyfikacje procesów w rozproszonych fabrykach przemysłu 4.0,  którymi można zarządzać z jednego miejsca w sposób zwirtualizowany, również z domu. Czyżby więc czekała nas w niedalekiej przyszłości nowa era możliwości projektowania i wdrażaniach całych linii produkcyjnych pracując wygodnie w domu w fotelu na laptopie? Technicznie ujmując będzie to możliwe. Transformacja cyfrowa pociąga za sobą również zmiany kulturowe naszego podejścia do wykonywanej pracy. Bardziej niż o naszą ludzką wygodę i komfort, chodzi tu o zapewnienie płynności produkcji, szczególnie w sytuacjach kryzysowych, jakich już doświadczyliśmy w dobie pandemii COVID-19. 

W praktycznym ujęciu sieć TSN pozwala na duże oszczędności poprzez integrację sieci IT z OT, np. zmniejszając ilości łącz kablowych. Opracowywanie rozwiązań opartych o TSN jest prostsze i szybsze, gdyż stosuje się jeden standard komunikacji Ethernet niezależnie od producentów urządzeń pracujących w sieci. Przy czym oprócz sieci TSN przewidywana jest tu unifikacja w ramach standardu OPC UA. Bezpieczeństwo jest z założenia uwzględniane w sprzęcie realizującym TSN (podpisany cyfrowo firmware, update poprzez bezpieczny zabezpieczony kryptograficznie kanał taki jak TLS itp.). Jednak mimo tak daleko sięgającej automatyzacji, przygotowanie nowej aplikacji do pracy w środowisku TSN wymaga znajomości zasad. Podobnie jak przy tworzeniu oprogramowania CLOUD Architect – aplikacja sama nie zaadoptuje się optymalnie do migracji w środowisko TSN. Pojawia się więc nowa dziedzina wymagająca już dziś edukacji przyszłych inżynierów w Polsce. To ważne, o ile chcemy sami budować własny przemysł 4.0 i mieć wpływ na szybkość rozwijającej się w naszym kraju zautomatyzowanej gospodarki.

TSN – stary czy nowy standard

Bardziej niż tworzenie nowego standardu, TSN unifikuje już istniejące. Bierze z nich to, co najlepsze i odsuwa te mniej użyteczne dziś sprawdzone doświadczalnie standardy. Tym samym TSN wprowadza uniwersalność, w której składowe (sprzęt) pochodzić mogą od różnych, często konkurujących ze sobą dostawców sterowników PLC/kontrolerów, switch’y, bramek (gateways), komputerów do EDGE-computing.

Zmiana paradygmatu optymalizacji – zarządzanie priorytetami TSN

Główną wartością jest nowy wymiar optymalizacji jaki TSN wnosi do przemysłu poprzez dynamiczne zarządzanie priorytetami przesyłanych danych. Najważniejszymi elementami są tu:

• czas i synchronizacja
• kształtowanie ruchu
    (zarządzanie ruchem krytycznym OT oraz niekrytycznym IT) 
• planowanie połączeń i dynamiczne zarządzanie nimi

Czas i synchronizacja w TSN

Pełni to rolę katalizatora dla pozostałych grup kształtowania ruchu i planowanie połączeń. Wszystkie urządzenia włączane do TSN muszą mieć własne zsynchronizowane zegary i to z dużą dokładnością, ale może co najistotniejsze, synchronizacja i czas muszą pozostawać stabilne przez cały czas pracy urządzeń 24/7. Oznacza to, że zegary muszą zgodnie odmierzać czas pracując w tej samej skali. Identyczne rozumienie czasu przez switche Ethernet, bramki i roboty definiuje pracę w tzw. wspólnej domenie czasu (ang. Time Domain). Najczęściej używana jest skala czasu UTC, ale nie tylko. Dlatego tak ważne jest zrozumienie idei skal czasu, wad już istniejących skal, jak i pilne uporządkowanie norm odmierzania chodu zegarów w TSN. Niektóre urządzenia PLC oparte na Linuxie, zaczynają liczyć czas od roku 1970. Systemy autonomicznych pojazdów używają swoich skal czasu liczonych od 0 (zera), które też zwykle interpretują jako rok 1970. Ważnym problemem jest to że np. chwila włączenia pojazdu (robota) w garażu uniemożliwia synchronizację do popularnego dziś źródła jakim jest GPS.
Z kolei systemy satelitarne GNSS różnie odmierzają czas. Np. chiński Beidou liczy dni tygodni w przedziale 0..6 podczas gdy pozostałe systemy GPS, GALILEO, GLONASS liczą od 1..7. Pojawia się sporo kwestii spornych wymagających ujednolicenia i standaryzacji.

Polski wkład do ITU-R ujednolicenia skali czasu UTC dla przemysłu 4.0

W latach 2021-2023, polska delegacja KPRM wniosła pierwszy w 100-letniej historii wkład do ITU-R obradujący przy ONZ w Genewie. Eksperci z firmy Elproma (www.elpromaelectronics.com) opracowali propozycję zmian w skali UTC, uzasadniając niebezpieczeństwo jakie wnosi dla TSN skokowa natura skali czasu UTC i obecność tzw. sekund przestępnych. Polską pracę wysoko ocenili eksperci grupy państw skupionych w G7. Ze streszczeniem pracy Polaków można się zapoznać w kwietniowym numerze 02/2023 ITU-News (str. 28)

Zarządzanie ruchem

Zarządzanie sieci i kolejkowanie uwzględniają dynamiczne zarządzanie priorytetami obsługi danych przesyłanych siecią Ethernet. Dotychczas sterowanie klasyczne oparte było o mechanizmy kolejkowania, a priorytety możliwe do nadawania za pomocą QoS (tzw. podejście “best efford”). Małe bufory kolejkujące mogą prowadzić do utraty pakietów.Z kolei zbyt duże bufory wprowadzają niepożądane opóźnienia (latencje). Istotę zarządzania porównuje się do ruchu samochodów. Autostrada dzieli się na pasy ruchu (wydzielone sloty czasowe transmisji sieci TSN) zróżnicowane dozwoloną minimalną prędkością. Są tutaj pasy do szybkiej i wolnej jazdy. Są też ustalone procedury tworzenia „pasów życia” dla przejazdów uprzywilejowanych. Samochody (pakiety z danymi) ustawiane są na odpowiednich pasach zapewniając optymalny, przewidywalny, płynny ruch sieci TSN, gdzie zapewnione jest maksymalne możliwe opóźnienie pakietu.

Zarządzanie połączeniami sieci

Zarządzanie połączeniami i rezerwacja slotów czasowych zapewnia redundancję połączeń (ang. fault-tolerance) na wypadek niespodziewanej awarii. Dotyczy to zarówno połączeń fizycznych, jak  i pasm logicznych (slotów czasowych) przydzielanych transmisji pakietów. W przykładzie porównania do autostrady, zarządzanie połączeniami zapewnia wydzielenie pasów, ich rezerwacje (buspas w godzinach szczytu). Obejmuje to także zapewnienie dróg dojazdowych i objazdów, w przypadku systemów krytycznych, a nawet podwojenie autostrad. Dla optymalizacji połączeń niezbędna jest znajomość opóźnień między elementami a urządzaniami końcowymi, a więc ważny jest ponownie czas i synchronizacja.

Problem synchronizacji z GPS

Najpowszechniejszym źródłem czasu jest sygnał satelitarny GPS. Od roku 1995 przemysł sukcesywnie wdrażał rozwiązania oparte o GPS (lub inny system z grupy GNSS), uzależniając się od niego. Z czasem odbiorników w przemyśle pojawiło się tak dużo, że zaczęły się wzajemnie zakłócać (za sprawą anten aktywnych). Trudne stało się też administrowanie tak dużą liczbą odbiorników GPS. Pojawiły się pierwsze anomalia synchronizacji opartej o GPS prowadzące do awarii przemysłowych. Coraz częściej okazywało się, że skorelowane systemy przemysłowe, synchronizowane dwoma niezależnymi od siebie odbiornikami GPS wykazują rozbieżności czasowe. Takie zjawisko uznano za niebezpieczne w erze TSN, dlatego zastąpiono odbiorniki specjalizowanymi serwerami czasu, zwanymi również zegarami grandmaster (ang. grandmaster clock). Wg standardu w sieci TSN każdy element sieci typu zegar może stać się serwerem master pod warunkiem rozgłoszenia posiadania najlepszych parametrów czasowych jak dokładność czy ustawionego najwyższego priorytetu dla algorytmu BMCA (Best Master Clock Algorythm) – typowo jest to właśnie serwer Grandmaster, podczas gdy inne serwery mogą kontynuować synchronizację sieci dla zapewnienia redundancji w przypadku utracenia serwera Grandmaster. Jako sieciowy protokół synchronizacyjny wybrano PTP IEEE1588 zastępując NTP. Serwery czasu ograniczyły również ilość odbiorników GPS, ale nie rozwiązywały do końca problemów związanych z używaniem czasu z satelitów.

Do synchronizacji używane są specjalne wersje odbiorników GNSS różniące się od geodezyjnych (RTK) i tych mobilnych, jakie mamy w telefonach komórkowych oraz w samochodach. Głównym problem synchronizacji opartej o GNSS jest błędne domniemanie, że czas i pozycja napływają automatycznie z satelity. Jednakże czas wyliczany jest w odbiornikach GNSS na Ziemi. Każdy odbiornik robi to inaczej – ma własne algorytmy, a poszczególne systemy GNSS (GPS, GLONASS, GALILEO, BEIDOU, IRNSS) różnią się wskazaniami wewnętrznych zegarów systemowych o całe sekundy. Odbiornik musi uwzględniać odebraną z satelitów telemetrię, korygując efekty relatywistyczne, wyliczając opóźnienie w jonosferze i przeskalowuje czas, prowadząc złożone operacje arytmetyczne na macierzach. Musi on sporo policzyć i poprzez to ma wiele okazji do popełniania błędów, zwłaszcza w zakresie przepełnień, ponieważ upływ czasu w jego wnętrzu reprezentowany jest numerycznie. Wiele odbiorników GNSS ze słabymi procesorami oraz małą ilością pamięci, przechowuje w jednym bajcie sąsiadujące ze sobą bity reprezentujące czas i datę. To bardzo niebezpieczne. Podczas obliczeń mogą występować przepełnienia, błędy sumy kontrolnej, wywołujące duże skoki w czasie (ang. peak time). Takie ryzyko występuje szczególnie podczas złych warunków odbioru sygnału GNSS oraz w okresie zapowiedzi i obsługi tzw. sekundy przestępnej UTC (ang. leap second).

W przypadku PTP, bazującego na skali TAI, czas należy przeliczyć ze skali UTC czy też GPS, co powoduje dodatkowe ryzyko błędu, zwłaszcza przy występowaniu sekundy przestępnej oraz przy starcie urządzenia (odbiornik GPS posiada pełną informację o czasie UTC dopiero po 12.5 minuty i gdy informacja o sekundach przestępnych zaszyta w jego firmware jest inna występuje skok czasu w ramce NMEA).

Ponadto, z wyjątkiem europejskiego GALILEO, wszystkie pozostałe systemy GNSS (GPS, GLONASS, BEIDOU, IRNSS) są systemami wojskowymi i nie dają gwarancji odbioru ich sygnału w zależności od sytuacji geopolitycznej. Danymi odbieranymi z GNSS można też łatwo manipulować, tworząc fałszywą emisję tu na Ziemi. Nazywa się to spoofingiem. Można też zagłuszać oryginalny sygnał satelitarny, co nazywamy jammingiem. Czy też retransmitować z celowym (tym różni się od interferencji czy odbić sygnału) opóźnieniem, tzw. meaconing. Obecnie sygnały GNSS w przemyśle są bardzo narażone na takie manipulacje i celowe cyberataki. Coraz częściej zdarzają się ataki na całe infrastruktury przemysłowe, a nawet na infrastruktury krytyczne państw. W 2019 roku Izrael odnotował zagłuszanie GPS, co wymusiło podjęcie procedur awaryjnych sterowania ruchem lotniczym nad tym państwem. Znane są też przypadki podobnych awarii systemów telekomunikacyjnych w Wielkiej Brytanii i Japonii i innych krajach.

Dziś synchronizacja ściśle wiąże się z cyberbezpieczeństwem TSN, ponieważ zamiast włamywać się do sieci wewnętrznej, prościej jest destabilizować pracę całej zautomatyzowanej fabryki poprzez zdalne zaburzenie synchronizacji rozproszonych elementów sieci. Reszta destrukcji wykona się praktycznie sama, jeżeli system nie jest na to przygotowany. Manipulując czasem można zaburzyć chronologię zapisanych zdarzeń w dziennikach LOG. Traci się wtenczas bezpowrotnie szansę analizy błędów i ustalenia przyczyny awarii.To idealne warunki dla hakerów, którzy odwracają w ten sposób uwagę od rzeczywistej przyczyny ataku wywołującego awarię. Dziś zmianie uległ cały paradygmat cyberbezpieczeństwa, a ataki hakerskie klasy „Time synchronization attack” i „Time delay attack” są jednymi z prawdopodobnych i najniebezpieczniejszych dla silnie zautomatyzowanego, zależnego od GNSS, przemysłu.

Synchronizacja TSN z dedykowanych serwerów PTP IEEE1588

Z powyższych powodów możliwości manipulacji GNSS, sieci TSN używają do synchronizacji wyspecjalizowane serwery czasu, które mogą pobierać czas jednocześnie z wielu źródeł. Są one skonstruowane pod kątem cyberbezpieczeństwa i stabilności dostaw skali czasu. Serwery czasu IEEE1588 nie tylko obierają sygnał z wybranych systemów GNSS, ale są z reguły wyposażone w specjalne wewnętrzne oscylatory o długoterminowej wysokiej stabilności częstotliwości, podtrzymujące synchronizację (tzw. holdover) podczas problemów z GNSS. Urządzenia mogą być konfigurowane do współpracy z konkretnymi systemami satelitarnymi, co pozwala realizować uwarunkowania geopolityczne. Trudno sobie wyobrazić, aby amerykański przemysł pozostawał zależny od chińskich satelitów BEIDOU, czy rosyjskiego systemu GLONASS i zasada ta działa w obie strony. W przypadku Europy ważną rolę pełni europejski system GALILEO opcjonalnie wspierany jedynie pracą amerykańskiego GPS. Serwery czasu IEEE1588 mogą też uzyskiwać precyzyjny czas siecią z zegarów atomowych z odległych centrów czasu.

Czas urzędowy RP

Coraz częściej mówi się o rosnącym znaczeniu czasu urzędowego, dostarczanego z narodowych instytutów metrologii przy pomocy światłowodów. W Polsce rolę tę pełni Główny Urząd Miar RP. Czas urzędowy jest w Polsce chroniony prawnie, a sposób jego rozpowszechniania określa rozporządzenie (Dz.U.04.56.548). GUM udostępnia swoje wzorce publicznie przy pomocy protokołu NTP i wkrótce również IEEE1588. Rodzima administracja, sektor finansowy, przemysł, a także telekomunikacja powinny opierać się na standardzie skali czasu UTC(PL) lub na wzorcu GALILEO, który z czasem uzyska status oficjalnego czasu Unii Europejskiej. W przyszłości należy pamiętać, że aby unikać awarii konieczne jest zadbanie o zaopatrzenie serwerów w oficjalne źródła czasu. Z czasem powstawać będą zapasowe centra czasu urzędowego, jakie dziś można już spotkać w USA i w niektórych innych krajach.

Podsumowując warto podkreślić bardzo dobrą perspektywę rozwoju sieci TSN, których zasięg z czasem wykroczy poza xsł. Idea deterministycznego Ethernetu, kusi coraz bardziej producentów rozwiązań konsumenckich. Niewykluczone, że pewnego dnia TSN zawita też w naszych domach tak samo jak sieć 5G czy powszechność łączy światłowodowych “na ostatniej mili”. Ethernet zapewniający określoną z góry nie tylko przepustowość, ale także opóźnienie, każdemu urządzeniu jest bardzo kuszącą propozycją. Jest to idealny partner dla 5G New Radio oraz IoT Critical. Realizując synchronizację należy pamiętać o roli czasu, który stał się dziedziną cyberbezpieczeństwa. Używanie wzorców GNSS wymaga uwzględnienia geopolityki i dlatego realizacja przemysłu 4.0 będzie się różnić w poszczególnych państwach właśnie podejściem do synchronizacji w TSN. Cieszy też wzrost aktywności Polski w obszarze rekomendacji i standaryzacji ITU-R. Daje to dobre perspektywy, że nasz kraj będzie w przyszłości sam wytwarzał więcej rozwiązań dla przemysłu 4.0.