Po co robotom 5G i skąd całe zamieszanie z URLLC
Dlaczego komunikacja z robotami jest tak wymagająca
Robot przemysłowy nie wybacza spóźnień. Jeśli sygnał sterujący przyjdzie za późno, ramię ominie element, zatrzyma się w złym miejscu albo uaktywni stop bezpieczeństwa. Liczy się nie tylko to, ile wynosi latencja w 5G dla robotów, ale też czy jest przewidywalna.
W automatyce kluczowe są trzy parametry: opóźnienie, niezawodność i deterministyczność. Opóźnienie mówi, jak szybko dociera komenda. Niezawodność – z jakim prawdopodobieństwem pakiet dotrze. Deterministyczność – jak bardzo te opóźnienia „pływają” w czasie. Robot może pracować z opóźnieniem rzędu kilku milisekund, ale dużo gorzej znosi sytuację, gdy raz jest to 3 ms, a za chwilę 30 ms.
W klasycznych liniach produkcyjnych ten problem rozwiązywano przewodowymi magistralami czasu rzeczywistego, jak PROFINET IRT, EtherCAT, Sercos czy POWERLINK. Zapewniają one cykle sterowania rzędu setek mikrosekund i bardzo niski jitter. Jednak są sztywne, trudne do rekonfiguracji i wymagają ciągnięcia kabli do każdego robota.
Ograniczenia przewodu i Wi‑Fi w nowoczesnej fabryce
Przy kilku robotach na stałych stanowiskach okablowanie nie jest dramatem. Problem zaczyna się, gdy pojawiają się mobilne roboty, AGV/AMR, zmienne konfiguracje stanowisk i linie produkcyjne, które trzeba często przezbrajać. Każdy dodatkowy kabel to koszt, czas postoju i ograniczenie elastyczności.
Wi‑Fi rozwiązuje tylko część problemu. Dobrze skonfigurowane Wi‑Fi może obsłużyć monitoring, HMI czy diagnostykę, ale przy trudniejszych zastosowaniach sterowania ruchem zaczyna brakować deterministyczności. Pasmo jest współdzielone, priorytety są miękkie, a jitter potrafi skoczyć o rząd wielkości, gdy pojawi się kilkanaście dodatkowych urządzeń w sieci.
W rozbudowanych halach produkcyjnych pojawiają się też odbicia sygnału, ekranowanie przez konstrukcje stalowe, przejazdy wózków widłowych, zgrzewarki czy spawarki powodujące zakłócenia. To wszystko utrudnia spełnienie wymagań URLLC w automatyce przemysłowej na standardowym Wi‑Fi.
Obietnica URLLC: ultra‑niska latencja i bardzo wysoka dostępność
URLLC (Ultra-Reliable Low Latency Communications) w 5G powstało jako odpowiedź na te potrzeby. Standard 3GPP definiuje mechanizmy, które mają umożliwić:
- opóźnienia rzędu pojedynczych milisekund end-to-end przy krótkich pakietach,
- niezawodność przekazu pojedynczego pakietu na poziomie „piątek” (np. 99,999%),
- priorytetyzację ruchu krytycznego nad typowym ruchem danych.
Przekładając to na język fabryki: komunikaty sterujące ruchem maszyn powinny mieć pierwszeństwo przed ruchem biurowym, streamingiem wideo czy aktualizacjami systemów. Sieć 5G ma dać możliwość budowy prywatnej infrastruktury komunikacyjnej, która zastąpi część przewodowych magistral tam, gdzie potrzebna jest mobilność lub elastyczność.
Przykład: linia montażowa z wieloma robotami w milisekundowych oknach czasowych
Wyobraźmy sobie linię, gdzie kilkanaście ramion robotycznych przenosi i pozycjonuje detale w sekwencjach liczonych w milisekundach. Każdy robot ma własny sterownik, ale ruchy są ściśle zsynchronizowane, bo części „podajnik–robot–robot–pakowanie” muszą zgrać się co do ułamków milimetra i milisekund.
Klasyczne rozwiązanie to gęsta sieć przewodowa w topologii gwiazdy lub ringu, sporo przełączników przemysłowych i staranne planowanie kabli. Przy każdej modyfikacji: zmiana layoutu, dołożenie robota, nowa stacja – trzeba przerabiać infrastrukturę.
Sieć 5G z obsługą URLLC umożliwia inny model: roboty (także mobilne) podłączają się bezprzewodowo do komórek 5G, a sterowanie wysokiego poziomu i synchronizacja czasowa przechodzą przez warstwę radiową. Kable zostają tylko tam, gdzie konieczny jest twardy real time submilisekundowy lub gdzie wymagana jest najwyższa niezawodność bezpieczeństwa funkcjonalnego.
Czym jest latencja w 5G – nie tylko jedna liczba w milisekundach
Latencja end‑to‑end, radiowa i rdzenia sieci
Latencja w 5G w kontekście robotów jest często upraszczana do jednej liczby „X ms”. W praktyce trzeba rozróżnić kilka poziomów:
- latencja radiowa – czas przejścia pakietu przez interfejs radiowy UE ↔ gNB (od wysłania do odebrania na stacji bazowej),
- latencja rdzenia sieci (core) – opóźnienie wprowadzane przez funkcje sieciowe (UPF, SMF itp.) i routing do sieci lokalnej lub edge,
- latencja end-to-end – całość: od aplikacji w sterowniku robota do aplikacji w drugim końcu komunikacji (np. kontroler ruchu, PLC, serwer edge).
Dla inżyniera automatyka liczy się ostatni parametr, ale żeby go świadomie zaplanować, trzeba wiedzieć, jak składa się na niego radio, przetwarzanie w gNB, transport IP oraz miejsce, gdzie działa logika sterowania.
Różnica między opóźnieniem a jitterem
Opóźnienie to średni czas dotarcia pakietu. Jitter to zmienność tego czasu. Dla robotyki kluczowe jest, by latencja była nie tylko niska, ale też stabilna. Jeśli wszystkie pakiety przychodzą w 8–9 ms, system może to skompensować. Jeśli raz w 3 ms, raz w 25 ms, a od czasu do czasu w 60 ms, algorytmy sterowania ruchem zaczynają się „rozjeżdżać”.
W praktyce jitter powoduje konieczność wprowadzania buforowania i predykcji w sterownikach. To zwiększa złożoność oprogramowania i opóźnia reakcję na zdarzenia awaryjne. W systemach z robotami współpracującymi z człowiekiem margines bezpieczeństwa zależy bezpośrednio od najgorszego przypadku latencji i jitteru, a nie tylko od wartości średniej.
Jednokierunkowe i dwukierunkowe opóźnienie w sterowaniu robotami
W robotyce występują dwa rodzaje cykli:
- cykl komend – sterownik wysyła polecenie ruchu lub korekty trajektorii do robota,
- cykl sprzężenia zwrotnego – robot wysyła informację o stanie, pozycjach osi, błędach.
W wielu zastosowaniach pakiety idą w obie strony. Znaczenie ma zarówno opóźnienie jednokierunkowe (komenda→robot), jak i całkowity czas pętli (komenda→robot→odpowiedź→sterownik). Dla niektórych algorytmów kluczowy jest czas zamknięcia pętli, dla innych – spójne znaczniki czasu i synchronizacja zegarów.
W komunikacji diagnostycznej wystarczy znajomość przybliżonej latencji end-to-end. W sterowaniu deterministycznym ważne jest, by pakiety w obu kierunkach miały przewidywalne opóźnienia i by można je było jednoznacznie związać z konkretnymi slotami czasowymi zegara systemu.
Składowe opóźnienia w 5G używanym przez roboty
Na praktyczne opóźnienie w sieci 5G składają się:
- czas dostępu do medium radiowego (alokacja zasobów, TTI, harmonogram w gNB),
- przetwarzanie pakietu w UE (modem 5G w robocie lub sterowniku),
- przetwarzanie w gNB (warstwa MAC, RLC, PDCP, SDAP),
- transport IP z gNB do UPF i dalej do sieci zakładowej lub serwera edge,
- przetwarzanie w UPF / funkcjach sieciowych (routing, QoS),
- transport w sieci LAN zakładu (przełączniki, TSN, routery),
- logika aplikacyjna w sterowniku ruchu lub PLC (czas cyklu, buforowanie, filtry).
Przy projektowaniu prywatnej sieci 5G dla robotyki trzeba przypisać każdej z tych składowych realistyczne wartości i dodać zapas bezpieczeństwa. Tylko wtedy cel typu „do 10 ms end-to-end w 99,999% przypadków” ma sens techniczny.
URLLC w 5G w prostych słowach: co obiecuje standard
Co oznacza URLLC i jakie są deklarowane parametry
URLLC to skrót od Ultra-Reliable Low Latency Communications. W standardach 5G oznacza to profil usług, który ma wspierać:
- latencję jednokierunkową rzędu około 1 ms w warstwie radiowej przy krótkich pakietach,
- niezawodność dostarczenia pakietu (BLER) na poziomie bardzo niskim, rzędu „piątek” (np. 99,999%),
- priorytetowe traktowanie ruchu krytycznego względem innych klas usług.
Są to wartości odnoszące się głównie do warstwy radiowej i przy założeniu odpowiedniej konfiguracji sieci, krótkich odległości i niewielkich zakłóceń. W praktyce, w środowisku przemysłowym, liczby te trzeba przeliczyć z uwzględnieniem całej ścieżki end-to-end.
Mechanizmy URLLC: krótkie TTI, pre-empcja, wielokrotne transmisje
Aby osiągnąć niski czas dostępu do medium, 5G URLLC korzysta z kilku kluczowych mechanizmów:
- krótsze jednostki czasu transmisji (TTI) – możliwość dzielenia ramki na mniejsze sloty, co pozwala szybciej przydzielać zasoby dla pakietów krytycznych,
- pre-empcja zasobów – ruch URLLC może przerwać lub przesunąć transmisje mniej krytycznego ruchu (np. eMBB),
- wielokrotne transmisje (retransmisje redundantne) – wysłanie tego samego pakietu kilkukrotnie, równolegle lub w krótkim odstępie, aby zwiększyć prawdopodobieństwo, że przynajmniej jedna kopia dotrze,
- priorytetyzacja w schedulerze – planista w gNB rezerwuje część zasobów radiowych tylko dla URLLC.
Każdy z tych mechanizmów ma skutki uboczne. Krótsze TTI mogą zwiększać sygnalizację. Pre-empcja podnosi jitter dla usług niższego priorytetu. Redundantne transmisje zwiększają zużycie pasma. Dlatego wdrażając URLLC w automatyce przemysłowej, trzeba równoważyć potrzeby krytycznych aplikacji z resztą ruchu.
eMBB, mMTC i URLLC – różne profile 5G
5G definiuje trzy główne rodzaje usług:
- eMBB (enhanced Mobile Broadband) – duże przepływności, np. wideo 4K, VR, transmisje strumieniowe,
- mMTC (massive Machine Type Communications) – obsługa ogromnej liczby prostych urządzeń IoT o niskim ruchu,
- URLLC – ruch krytyczny z punktu widzenia czasu i niezawodności, jak sterowanie robotami czy systemy bezpieczeństwa.
Te profile mają odmienne cele, a tym samym inne kompromisy. eMBB optymalizuje przepływność kosztem opóźnień, mMTC – efektywność energetyczną i skalę, a URLLC – minimalne opóźnienie i niezawodność, nawet kosztem przepustowości oraz złożoności implementacji.
Projektując sieć 5G w fabryce, trzeba z góry określić, które usługi mają mieć charakter URLLC, a które mogą pozostać w profilach eMBB lub mMTC. Ruch kamer diagnostycznych może być eMBB, sensory środowiskowe – mMTC, a komendy sterujące robotami – URLLC.
Standard 3GPP vs. wdrożenia komercyjne
3GPP opisuje pełny zestaw funkcji URLLC, ale nie każdy dostawca sprzętu i oprogramowania wdraża je w całości, szczególnie w pierwszych generacjach produktów. W praktyce można spotkać rozwiązania, które deklarują „obsługę URLLC”, ale:
- działają tylko w określonych pasmach lub konfiguracjach,
- ograniczają liczbę jednoczesnych użytkowników URLLC,
- nie wspierają jeszcze pełnej integracji z TSN,
- mają część funkcji dostępnych tylko w wersjach „enterprise” lub przy określonych licencjach.
Dlatego przy planowaniu sieci dla robotyki trzeba pytać nie o hasło URLLC, ale o konkretne parametry: gwarantowane TTI, obsługiwane klasy QoS, integrację z TSN, dostępne mechanizmy redundantnej transmisji oraz realne wyniki testów w środowisku przemysłowym.
Jakie opóźnienia są naprawdę potrzebne do precyzyjnej synchronizacji robotów
Klasyczne wymagania czasowe w robotyce
Większość robotów przemysłowych opiera się na wewnętrznych pętlach sterowania o częstotliwościach 250 Hz, 500 Hz, 1 kHz lub wyższych. To oznacza czasy cykli od 4 ms w dół do 1 ms i mniej. Te pętle działają lokalnie na sterowniku robota, zazwyczaj poza siecią 5G.
Sieć pojawia się zwykle na dwóch poziomach:
- komendy wysokiego poziomu (trajektoria, punkty, zadania) – czasy rzędu dziesiątek lub setek milisekund,
Cykle komunikacji międzyrobotycznej a graniczne opóźnienia
Gdy kilka robotów współdzieli przestrzeń roboczą, pojawia się wymóg synchronizacji ich ruchu w skalach 5–10 ms, a w bardziej wymagających aplikacjach niżej. Chodzi o korelację ruchów, a niekoniecznie o przeniesienie całej pętli sterowania na sieć.
W typowej linii montażowej roboty wymieniają informacje o stanach, punktach zatrzymania, potwierdzeniach pozycji. Często wystarczy, aby opóźnienie pętli sieć→sterownik→sieć mieściło się w 20–30 ms przy małym jitterze, np. <5 ms.
Przy synchronicznym ruchu kilku osi z różnych kontrolerów (np. przenoszenie dużego elementu przez dwa roboty) wymagania się zaostrzają. Tam dla bezpieczeństwa i jakości trajektorii potrzebne są opóźnienia deterministyczne, rzędu pojedynczych milisekund zamkniętej pętli lub spójne znaczniki czasu przy nieco większym opóźnieniu.
Kiedy 1 ms ma sens, a kiedy jest sztuką dla sztuki
Opóźnienie 1 ms jest potrzebne przede wszystkim tam, gdzie pętla sterowania faktycznie przechodzi przez sieć: np. rozproszone napędy, zdalne moduły I/O o krytycznym znaczeniu czasowym, funkcje bezpieczeństwa realizowane centralnie.
W wielu systemach robotycznych sieć 5G przenosi tylko warstwę nadzorczą lub koordynację między wyspami autonomii. Wtedy wymagania czasowe są wyraźnie łagodniejsze, a kluczowa staje się przewidywalność, nie absolutne minimum milisekund.
Projekt zaczyna być nieracjonalny, gdy deklaruje się „1 ms end-to-end”, a cała logika sterowania działa w cyklu 10 ms i korzysta z szerokich buforów. W takim przypadku sensowniej wykorzystać rezerwę na zwiększenie niezawodności i prostoty architektury.
Zapas bezpieczeństwa a budżet opóźnień
Przy definiowaniu wymagań czasowych dla robotyki pomocne jest tworzenie budżetu opóźnień. Określa się maksymalny dopuszczalny czas dla pętli sterowania lub koordynacji, a następnie dzieli go na elementy: radio, sieć transportową, edge, aplikację.
Jeżeli dla danej funkcji koordynacji robotów maksymalny czas reakcji wynosi 25 ms, można założyć np. 5 ms na radio (w obie strony), 5 ms na transport IP, 5 ms na edge i 10 ms na logikę aplikacji wraz z buforowaniem i filtracją.
Zapas bezpieczeństwa powinien wynikać z wymagań bezpieczeństwa maszynowego i analizy ryzyka, a nie z arbitralnej „rezerwy” kilku milisekund. W systemach z robotami współpracującymi z człowiekiem ten margines bywa większy niż sama średnia latencja.
Synchronizacja czasu i zegarów: 5G, PTP, TSN i reszta układanki
Po co w ogóle synchronizować zegary w robotyce
Przy niskich opóźnieniach można teoretycznie obejść się bez globalnej synchronizacji czasu, opierając się na samej pętli polecenie–odpowiedź. Jednak przy kilku robotach, sensorach wizyjnych i sterownikach PLC potrzeba wspólnego odniesienia czasowego.
Wspólny zegar upraszcza korelację zdarzeń (np. kolizji, zatrzymań awaryjnych), pozwala zsynchronizować trajektorie oraz ułatwia integrację systemów bezpieczeństwa. Bez tego inżynierom trudniej diagnozować nieregularne błędy i „dziury” w ruchu.
PTP / IEEE 1588 jako punkt odniesienia
W sieciach przemysłowych od lat stosuje się Precision Time Protocol (PTP, IEEE 1588). Pozwala on osiągać synchronizację zegarów z dokładnością pojedynczych mikrosekund, jeśli infrastruktura sieciowa jest do tego przygotowana.
W typowej fabryce rolę grandmastera pełni zegar sprzętowy w jednym z przełączników lub specjalizowany serwer czasu. Przełączniki pośredniczące muszą wspierać mechanizmy transparent clock lub boundary clock, inaczej precyzja jest tracona.
Dla robotyki synchronizacja PTP jest kluczowa tam, gdzie różne urządzenia muszą interpretować znaczniki czasu tak samo: np. w koordynacji ruchu z kamerami, w rozproszonej kontroli napędów czy przy łączeniu domen TSN z klasycznym Ethernetem.
TSN – Ethernet deterministyczny
Time-Sensitive Networking (TSN) to zestaw rozszerzeń dla Ethernetu, które umożliwiają deterministyczną transmisję z gwarantowanymi opóźnieniami i rezerwacją pasma. TSN korzysta z PTP do synchronizacji czasu, a następnie planuje okna transmisji.
W praktyce TSN tworzy „szynę czasową” dla ruchu czasu rzeczywistego między sterownikami, napędami, I/O. Pakiety krytyczne są wysyłane w wyznaczonych slotach, pozostały ruch korzysta z okien best effort.
W wielu projektach robotycznych TSN jest rdzeniem sieci przewodowej, a 5G ma stać się jej przedłużeniem bezprzewodowym. Tu pojawia się pytanie, jak dobrze 5G potrafi „wejść” w cykl czasu TSN.
Synchronizacja czasu przez 5G
Standardy 5G przewidują dystrybucję synchronizacji czasu do urządzeń końcowych. Stacja bazowa może otrzymywać referencję czasu (np. z PTP, GPS lub innego źródła), a następnie przekazywać ją do UE (roboty, sterowniki) poprzez sygnały radiowe.
W wariantach przemysłowych (np. 5G-ACIA) zakłada się, że modem 5G w urządzeniu będzie w stanie udostępniać aplikacji lokalnej zegar zsynchronizowany z siecią z dokładnością rzędu mikrosekund do dziesiątek mikrosekund, zależnie od konfiguracji.
To otwiera drogę do wykorzystania 5G jako medium transportującego zarówno dane sterujące, jak i wspólny zegar systemowy. Ostateczna dokładność zależy jednak od implementacji modemu, stacji bazowej i tego, jak producent urządzenia udostępnia ten zegar systemowi operacyjnemu.
Integracja 5G z TSN w fabryce
3GPP definiuje mechanizmy, dzięki którym sieć 5G może współpracować z domeną TSN. Funkcje sieciowe (np. TSN Translator) mapują strumienie TSN na przepływy 5G QoS i odwrotnie, dbając o zachowanie parametrów czasowych.
W praktyce oznacza to, że sterownik ruchu w sieci TSN widzi urządzenie za 5G (np. robota mobilnego) jak kolejny węzeł TSN z określonym budżetem opóźnienia. Sieć 5G musi zagwarantować, że ten budżet nie zostanie przekroczony.
Bez tej integracji robot podłączony przez 5G byłby „obcym” elementem w domenie deterministycznej. Z TSN-aware 5G może stać się równorzędnym uczestnikiem synchronizowanego planu czasowego.
Architektura sieci 5G dla robotyki: od komórki do edge computingu
Prywatne sieci 5G (non-public networks) w zakładach
Dla zastosowań robotycznych kluczowe są prywatne sieci 5G uruchamiane na terenie zakładu. Pozwalają one na kontrolę pasma, mocy nadawczej, planu komórek i konfiguracji URLLC bez kompromisów typowych dla sieci publicznych.
Operator zakładowy może dobrać pasmo (np. lokalne licencjonowane), zaprojektować pokrycie hal, tak aby minimalizować ręover’y i cienie radiowe, a także zamknąć ruch w lokalnym core 5G. To ostatnie jest ważne, bo tranzyt do zewnętrznego core’u operatora zjada cenne milisekundy.
Lokalny core 5G i jego wpływ na opóźnienia
Umieszczenie funkcji core 5G (AMF, SMF, UPF) w serwerowni zakładowej znacząco zmniejsza opóźnienia transportowe. Pakiety nie wychodzą poza sieć zakładu, a routing do sterowników i serwerów edge odbywa się lokalnie.
W architekturze dla robotyki UPF powinien być możliwie blisko gNB, najlepiej w tej samej serwerowni lub nawet jako funkcja współlokowana. Każdy dodatkowy router i odcinek WAN to kolejne niepotrzebne milisekundy i wzrost jitteru.
W wielu wdrożeniach UPF pełni też rolę punktu egzekwowania QoS i segmentacji ruchu (slicing). Dla ruchu URLLC do robotów można wydzielić oddzielny slice z własnym profilem QoS i ścisłą kontrolą tras.
Edge computing jako „mózg blisko robotów”
Edge computing pozwala przenieść część logiki sterowania i analizy blisko robotów. Zamiast wysyłać dane do chmury centralnej, aplikacje działają na serwerach w hali lub w tej samej serwerowni, gdzie core 5G.
Takie rozwiązanie skraca ścieżkę danych: radio→gNB→UPF→edge→UPF→gNB→radio. Eliminowany jest długi odcinek do chmury centralnej. W praktyce różnica może wynosić od kilku do kilkudziesięciu milisekund.
Na edge można umieszczać m.in. koordynację międzyrobotyczną, analizę kolizji w czasie zbliżonym do rzeczywistego, fuzję danych z kamer i lidarów oraz bramy integrujące z systemami MES/ERP bez wpływu na ścieżkę krytycznych pakietów sterowania.
Topologia radiowa dla URLLC w hali produkcyjnej
Projektując sieć radiową, trzeba pogodzić wysoką dostępność, małe opóźnienia i zmienne środowisko (metalowe konstrukcje, ruchome maszyny, ludzie). Zwykle stosuje się kilka komórek o ograniczonym zasięgu zamiast jednej stacji „na całą halę”.
Więcej, gęściej rozmieszczonych punktów dostępowych (gNB) pozwala obniżyć moc nadawczą, ograniczyć interferencje i skrócić ścieżkę radiową. Ułatwia to utrzymanie stabilnego SINR, co z kolei zmniejsza potrzebę retransmisji i poprawia przewidywalność opóźnień.
Przy robotach mobilnych trzeba świadomie zaplanować granice komórek, tak aby handover’y nie wypadały w krytycznych fazach ruchu lub były realizowane w sposób ściśle kontrolowany (np. make-before-break z odpowiednim zapasem czasu).
Sieć 5G a istniejąca infrastruktura sterowania
W zakładach, gdzie działają już sieci Profinet, EtherCAT, EtherNet/IP czy TSN, 5G musi się w nie wpasować. Zwykle robi to poprzez bramy (gateway’e) pełniące funkcję konwertera protokołów i domen czasu.
Robot lub sterownik podłączony przez 5G widzi po swojej stronie interfejs Ethernet lub magistralę przemysłową, natomiast brama mapuje ruch do odpowiednich QoS flow w 5G, pilnując, by opóźnienia i jitter mieściły się w budżecie danej magistrali.
Dla URLLC krytyczne jest, aby te bramy nie wprowadzały dużego własnego jitteru, np. przez nadmierne buforowanie. W wielu nowoczesnych rozwiązaniach stawia się na implementacje sprzętowe lub silnie zoptymalizowane stosy czasu rzeczywistego.
Co URLLC daje realnie, a co jest marketingiem
Scenariusze, gdzie URLLC naprawdę zmienia zasady gry
URLLC ma sens wszędzie tam, gdzie wymagana jest deterministyczna komunikacja o małym opóźnieniu i wysokiej niezawodności, a jednocześnie połączenia przewodowe są trudne lub niemożliwe.
Przykładem jest zdalne sterowanie mobilnych robotów transportowych, kt