Time Sensitive Networking (TSN) - nowa jakość Ethernetu

Powszechnie uważa się, że inspiracją do prac nad TSN były systemy sieciowego streamingu oparte na AVB (Audio Video Bridging) oraz rozwiązania przemysłowe klasy QoS (Quality of Service). Zamykając sterowanie w pętli sprzężenia zwrotnego, stworzono predykcyjny mechanizm sterowania, pozwalający przewidywać stan w kolejnych chwilach i dopasowujący doń precyzyjnie parametry sterujące. To pozwoliło podzielić czas na równe ramki (interwały czasu), w których sterownik z usługą działała deterministycznie i może pracować autonomicznie.

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 na ramkach czasowych (time slots), których priorytetami można zarządzać, realizując w ten sposób efekt zrównoleglenia sterowania wieloma urządzeniami w fizycznie pojedynczej sieci. Tak powstał pierwszy TSN umożliwiający TCC (Time Coordinating Computing).

Sterowanie automatyką i synchronizacja w jednej sieci Ethernet TSN

Zauważono, że przez Ethernet można równolegle z danymi przesyłać telemetrię zegara referencyjnego, niezbędną do synchronizacji rozproszonych elementów sieci. Inspiracją stał się protokół NTP, w którym mechanizm synchronizacji oparto na predykcji. Dystrybucja wzorca czasu siecią różni się od klasycznego podejścia znanej nam regulacji zegarów, gdzie pytamy "która godzina" po czym ustawiamy swój zegarek.

W NTP zegar referencyjny Master przesyła obok wskazania UTC (Universal Time Coordinated) również statystykę błędów zegara wzorcowego, na podstawie której zegar synchronizowany Slave (podporządkowany) planuje korektę swojej pracy tak, aby w kolejnej chwili kontrolnej znaleźć się jak najbliżej wzorca. Czynność wymiany statystyk odbywa się cyklicznie, co pozwala wyliczyć średnie opóźnienie sieci nawet przy rozsynchronizowanych jeszcze zegarach.

W TSN zastąpiono NTP protokołem nowszej generacji PTP (Precision Time Protocol) - IEEE1588, który cechuje bardzo szybki rozruch oraz submikrosekundowe dokładności, dzięki zastosowaniu sprzętowego stemplowania ramek.

Innowacja. czyli istota wartości TSN

Ujmując krótko, TSN wprowadza do Ethernetu determinizm, czas rzeczywisty i inteligentne współdzielenie sieci między niezależne procesy. Umożliwia połącznie sieci kablowej, światłowodowej i radiowej jednym standardem. 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 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, z użyciem narzędzi takich jak Docker i Kubernetes do ich zarządzania. Umożliwi to na szybkie modyfikacje procesów w rozproszonych fabrykach Przemysłu 4.0, w tym zarządzanie tym 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 w zakresie możliwości projektowania i wdrażaniach całych linii produkcyjnych z domowego fotela i laptopa? 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.

W praktycznym ujęciu sieć TSN pozwala na duże oszczędności poprzez integrację sieci IT z OT, np. zmniejszenie liczby łączy kablowych. Opracowywanie rozwiązań opartych na TSN jest prostsze, szybsze, gdyż stosuje się jeden standard komunikacji niezależnie od producentów urządzeń pracujących w sieci. Ponadto 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). Jednak mimo tak daleko sięgającej automatyzacji, przygotowanie nowej aplikacji do pracy w środowisku TSN wymaga znajomości zasad i standardów. Podobnie jak przy tworzeniu oprogramowania Cloud Architect - aplikacja sama nie będzie działać optymalnie w środowisku 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ł 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 wersje. 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, switchy, bramek (gateways), komputerów do edge computingu. Właściwa integracja takiego sprzętu wymaga zmiana paradygmatu optymalizacji. Główną wartością jest dynamiczne zarządzanie priorytetami przesyłanych danych. Najważniejszymi elementami są:

• czas i synchronizacja,
• zarządzanie ruchem krytycznym OT oraz niekrytycznym IT (kształtowanie ruchu),
• zarządzanie połączeniami OT (planowanie).

Czas i synchronizacja w TSN

Pełnią one funkcję katalizatora dla pozostałych grup. Wszystkie urządzenia włączane do TSN muszą mieć zsynchronizowane zegary z dużą dokładnością, ale może co najistotniejsze synchronizacja i czas muszą pozostawać stabilne przez cały czas (24/7). Oznacza to, że zegary muszą zgodnie odmierzać czas pracując w tej samej dziedzinie - tzw. skali czasu i nie mogą zbytnio drżeć (jitter). Identyczne rozumienie czasu przez switche, bramki i roboty definiuje pracę w tzw. wspólnej domenie czasu (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 czasu w TSN. Niektóre urządzenia PLC, oparte na Linuksie, zaczynają liczyć czas od roku 1970. Systemy autonomicznych pojazdów używają swoich skal czasu liczonych od zera, które też zwykle interpretują początek jako rok 1970. Jednak inne sterowniki wbudowane mogą owe zero interpretować odmiennie jako arbitralny. Dlatego TSN używa do synchronizacji PTP protokołu opartego na skali atomowej TAI (Atomic Time Scale) i przesuniętej do skali UTC. Standard ten umożliwia też koordynacje różnych skal czasu (TAI, UTC, lokalnego). W przypadku nowszej wersji standardu 802.1AS-rev możliwe jest też wydzielenie domeny czasowej dla skali arbitralnej (ARB) liczonej od zera. Pozwala on dokładnie mierzyć opóźnienia istotne do zarządzania ruchem. Wspólny czas pełni w TSN rolę dyrygenta orkiestry złożonej z muzyków (roboty). Dyrygent (zegar Master) narzuca rytm niezbędny dla muzyki (proces produkcji). Dyrygent wskazuje zarówno kto gra, kto pauzuje. Określa w "symfonii" produkcji głośność gry uczestników (priorytety).

Zarządzanie ruchem

Zarządzanie siecią i kolejkowanie uwzględniają dynamiczne zarządzanie priorytetami obsługi przesyłanych siecią Ethernet danych. Dotychczas sterowanie klasyczne oparte było na mechanizmach kolejkowania, a priorytety możliwe do nadawania za pomocą QoS (tzw. podejście best effort). 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 (analogia do wydzielonych slotów czasowych 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

Zarządzanie połączeniami i rezerwacja slotów czasowych zapewnia redundancję połączeń (fault tolerance) na wypadek niespodziewanej awarii. Dotyczy to zarówno połączeń fizycznych, jak 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 (buspasy). Obejmuje to także zapewnienie dróg dojazdowych i objazdów, w przypadku systemów krytycznych, a nawet podwojenie autostrad. Do optymalizacji połączeń niezbędna jest znajomość opóźnień między elementami a urządzaniami końcowymi.

Problem synchronizacji GPS

 

Fot. 1. Widok dachu zakładu produkcyjnego zapełnionego antenami GPS

Najpowszechniejszym źródłem czasu jest sygnał satelitarny GPS. Od 1995 r. przemysł sukcesywnie wdrażał rozwiązania oparte na GPS (lub inny 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. Pojawiły się pierwsze anomalie synchronizacji opartej na GPS prowadzące do awarii. 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 (Grandmaster clock). Według 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 - typowo jest to właśnie serwer Grandmaster, a inne mogą kontynuować synchronizację sieci dla redundancji w przypadku utracenia serwera. To ułatwiło utrzymanie systemów przemysłowych we wspólnej domenie czasowej TAI z informacją o skali czasu UTC. Jako sieciowy protokół synchronizacyjny wybrano PTP IEEE1588, zastępując NTP. Serwery czasu ograniczyły również liczbę 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 na 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 (potencjalnie wspierając się systemami SBAS jak EGNOS) i przeskalowuje czas, prowadząc złożone operacje 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 (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 (leap second).

 

Fot. 2. Awaria telemetrii w tramwajach w dniu 7.04.2019 r spowodowana problemem przepełnienia i wyzerowania się licznika tygodni. Licznik jest częścią danych telemetrycznych przekazywanych z satelitów GPS i występuje raz na 19,7 lat (10321927 minut)

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 ma pełną informację o czasie UTC dopiero po 12,5 minuty i gdy informacja o sekundach przestępnych zaszyta w jego pamięci jest inna występuje skok czasu w danych 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. meacooning. 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 r. 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.

Co więcej, okazuje się, że czas UTC wcale nie jest taki uniwersalny, jak wskazuje jego nazwa - każda konstelacja GNSS ma swoją prywatną skalę czasu UTC i one się różnią. Na przykład rozbieżność UTC amerykańskiego systemu GPS i rosyjskiego GLONASS to 40 ns, a ich bazowe skale czasu GPST i GLONASST różnią się dziś aż o 19 s. Różna jest też numeracja dni tygodnia. Chińczycy w BEIDOU oznaczają dni w przedziale 0-6, podczas gdy pozostali nadają numerację 1-7. Wszystkich przypadków jest zbyt wiele, aby przetestować liczne kombinacje na symulatorach w laboratorium, zwłaszcza że ostateczny wynik różnicuje jeszcze jakość odbieranych sygnałów, a to zależy od instalacji anteny i jej dostępności do pełnego nieboskłonu. Zdarzyło się, że odbiornik, po latach stabilnej pracy, wykonał nieoczekiwanie operacje, wywołując fl uktuacje i niestabilność synchronizacji.

Dziś synchronizacja ściśle wiąże się z cyberbezpieczeństwem (powiązanie m.in. z przedziałem czasu ważności certyfi katów), ponieważ zamiast włamywać się do sieci wewnętrznej, prościej jest destabilizować pracę całej zautomatyzowanej fabryki poprzez zdalne zaburzenie synchronizacji. Reszta destrukcji wykona się praktycznie sama, jeżeli system nie jest na to przygotowany. Manipulując czasem, można zaburzyć chronologię zapisanych zdarzeń w logach. Traci się wtedy 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 hackerskie 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 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 odbierają 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ę (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ą funkcję 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

Coraz częściej mówi się o rosnącym znaczeniu czasu urzędowego, dostarczanego z narodowych instytutów metrologii za pomocą światłowodów. Za wyznaczanie dokładnego czasu UTC(k) odpowiada w każdym państwie narodowy instytut metrologii. W Polsce funkcję tę pełni Główny Urząd Miar. Czas urzędowy jest w Polsce chroniony prawnie. GUM udostępnia swoje wzorce publicznie za pomocą protokołu NTP i wkrótce również IEEE1588. Rodzima administracja, sektor finansowy, przemysł, a także telekomunikacja powinny opierać się na standardzie UTC(PL) lub na wzorcu GALILEO, który niebawem 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 polskiego dostarczane niezależnie z GALILEO, sygnału radiowego 225 kHz z Solca Kujawskiego i z sieci Głównego Urzędu Miar RP. 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 przemysł. 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.

Tomasz Widomski