Autonomiczna mobilność i 5G – o czym mówimy konkretnie
Autonomia, zdalne sterowanie i pojazdy „connected” – nie mieszać pojęć
Autonomiczna mobilność nie oznacza, że każde auto, dron czy robot jest stale sterowany przez sieć 5G. W praktyce funkcjonują trzy główne modele:
- Autonomia pokładowa – pojazd sam podejmuje decyzje na podstawie własnych sensorów (kamery, lidar, radar, GPS, IMU). Sieć jest dodatkiem: aktualizacje map, zdalna diagnostyka, raporty.
- Zdalne sterowanie (teleoperation) – człowiek steruje pojazdem na odległość, sieć jest krytyczna, bo każda przerwa łączy oznacza utratę kontroli.
- Connected (pojazd połączony) – pojazd komunikuje się z innymi pojazdami i infrastrukturą (V2X), wymienia dane o sytuacji na drodze, ruchu pieszych, stanie sygnalizacji.
Autonomiczny samochód może być jednocześnie „connected”, ale nie musi. Możliwy jest też scenariusz odwrotny: auto podłączone do sieci, ale bez funkcji samodzielnej jazdy (np. tylko infotainment i podstawowe V2X). W dyskusji o 5G i mobilności te pojęcia bywają wrzucane do jednego worka, co prowadzi do błędnych założeń przy projektowaniu systemów.
Gdzie 5G jest kluczowe, a gdzie staje się wyłącznie hasłem marketingowym
Nie każde wdrożenie autonomii potrzebuje 5G. Autonomia poziomu 4 w ograniczonej strefie (np. zamknięty kampus, magazyn, port) może działać głównie na sensorach pokładowych i lokalnej sieci Wi-Fi/5G kampusowej. W takich środowiskach najważniejsza bywa precyzyjna mapa, dobre oznaczenia i przewidywalne otoczenie, a nie koniecznie publiczna sieć 5G.
5G nabiera znaczenia tam, gdzie:
- potrzebna jest wysoka gęstość połączeń – wiele pojazdów i robotów na małej przestrzeni (centra miast, kampusy uczelni, duże magazyny miejskie),
- konieczne jest zdalne wsparcie lub przejęcie sterowania – operator monitoruje flotę i może w razie problemu przejąć kontrolę nad pojazdem lub dronem,
- kluczowa jest koordynacja między wieloma typami urządzeń – samochody, drony i roboty miejskie w jednym obszarze, dzielące tę samą infrastrukturę.
W tych przypadkach 5G może realnie podnieść bezpieczeństwo i efektywność. Natomiast w pojedynczych projektach pilotażowych, gdzie jeździ kilka pojazdów w małej strefie, 5G bywa wykorzystywane głównie jako element „innowacyjnego wizerunku”. Tam równie dobrze wystarczyłaby dobrze zaprojektowana sieć Wi-Fi, LTE lub dedykowany system łączności.
Granica między mobilnością „na sensorach” a mobilnością „na sieci”
Autonomiczny system mobilności można ustawić na skali od modelu „niemal wszystko na pokładzie” do modelu „silnie zależny od sieci”. W praktyce spotyka się trzy podejścia:
- Model sensor-centric – pojazd posiada bogaty zestaw sensorów i mocne komputery pokładowe. Sieć służy głównie do aktualizacji oprogramowania, map HD i przesyłu logów. Zaleta: mniejsza zależność od zasięgu; wada: wyższy koszt pojazdu i większe zużycie energii na obliczenia.
- Model network-assisted – pełna autonomia na pokładzie, ale z dodatkowymi danymi z sieci: ostrzeżenia V2X, informacje o korkach, pracach drogowych, priorytetyzacja pojazdów uprzywilejowanych. 5G zwiększa „świadomość sytuacyjną”, ale awaria sieci nie zatrzymuje od razu ruchu.
- Model network-dependent – część lub większość „inteligencji” jest w edge cloud lub chmurze. Pojazd ma prostszą elektronikę, a decydujące algorytmy działają poza nim. To podejście wymaga bardzo stabilnej i szybkiej sieci (5G URLLC lub sieci kampusowej), bo przerwa w transmisji może być krytyczna.
Obecnie w ruchu drogowym i miejskim dominują podejścia sensor-centric i network-assisted. Rozwiązania network-dependent pojawiają się punktowo, głównie w kontrolowanych środowiskach (magazyny, terminale, kampusy), gdzie sieć 5G jest prywatna i dobrze zaprojektowana.
Przekrój urządzeń: od ciężarówki po robota sprzątającego
Autonomiczna mobilność w mieście to nie tylko samochody osobowe typu robotaxi. Sieć 5G ma potencjał łączyć różne klasy urządzeń:
- Samochody osobowe – asystenci jazdy, autonomiczne parkowanie, robotaxi, współdzielenie danych o warunkach na drodze.
- Pojazdy ciężarowe – platooning (jazda w kolumnie), zdalne zarządzanie flotą, precyzyjne dokowanie w centrach logistycznych.
- Drony – inspekcje infrastruktury, monitoring, dostawy medyczne i kurierskie, zdalny podgląd dla służb ratunkowych.
- Roboty dostawcze – małe pojazdy na chodnikach lub ścieżkach rowerowych, obsługujące „ostatnią milę” dostaw.
- Roboty komunalne – autonomiczne zamiatarki, kosiarki, roboty do kontroli stanu dróg, oświetlenia czy torowisk.
Każda z tych klas ma inne wymagania co do pasma, opóźnień i niezawodności. Próba „uśrednienia” pod jedną konfigurację sieci prowadzi do konfliktów: dron potrzebuje często stabilnego uplinku wideo, robot miejski – niskich opóźnień w gęstym otoczeniu, a ciężarówka – niezawodnego handoveru przy wyższych prędkościach. Stąd znaczenie mechanizmów 5G, które pozwalają w jednej infrastrukturze wydzielać logicznie różne „kawałki” sieci.
Kluczowe cechy 5G ważne dla ruchu autonomicznego
Opóźnienia, niezawodność i przepustowość – co oznaczają dla konkretnych scenariuszy
5G obiecuje niski czas opóźnienia (latency), dużą przepustowość i wysoką niezawodność. Bez konkretów te hasła mało znaczą. Przekładając je na przykładowe scenariusze:
- Zdalne hamowanie lub przejęcie sterowania – w trybie teleoperation operator widzi obraz z kamer i podejmuje decyzje sterujące. Opóźnienia rzędu kilkudziesięciu milisekund robią różnicę między płynną reakcją a zauważalnym „lagiem”. 5G w trybach URLLC jest projektowane pod opcjonalne opóźnienia rzędu kilku–kilkunastu milisekund, ale uzyskanie takich parametrów w realnej, publicznej sieci komórkowej nie jest jeszcze normą.
- Streaming z kamer i lidarów – przesył wideo HD lub 4K z kilku kamer oraz danych z sensorów do edge cloud wymaga stabilnej przepustowości uplink. 5G oferuje znacznie lepszy uplink niż 4G, ale w gęstych lokalizacjach miejskich przy setkach urządzeń na komórkę znowu liczy się realne planowanie sieci, a nie teoretyczna maksymalna prędkość.
- Sygnalizacja V2X – komunikaty ostrzegawcze (nagłe hamowanie, pojazd uprzywilejowany) to małe pakiety danych, ale wymagają wysokiej niezawodności i niewielkich opóźnień. Tu kluczowa jest priorytetyzacja ruchu krytycznego nad less-critical (np. nadawanie reklam na ekrany w pojazdach).
W praktyce opóźnienia i niezawodność zależą od wielu czynników: pasma, obciążenia sieci, odległości od stacji bazowej, jakości implementacji w urządzeniach. Ślepa wiara w „milisekundowe latency z ulotki” przy projektowaniu systemów bezpieczeństwa jest prostą drogą do błędów architektonicznych.
Pasma niskie, średnie i mmWave – wpływ na mobilność
5G korzysta z trzech klas pasma:
- Pasma niskie (sub-1 GHz) – duży zasięg, dobra penetracja budynków, mniejsza przepustowość. Przydatne dla komunikacji szerokoobszarowej (np. podstawowa telemetria pojazdów na dużych odległościach, w tym poza miastem).
- Pasma średnie (ok. 1–6 GHz) – kompromis między zasięgiem a przepustowością. To one często stanowią „kręgosłup” miejskich wdrożeń 5G dla mobilności, bo dają względnie dobre parametry zarówno prędkości, jak i zasięgu.
- mmWave (pasma milimetrowe) – bardzo duża przepustowość, ale krótki zasięg i duża wrażliwość na przeszkody. Nadają się do punktów o wysokiej gęstości ruchu: węzły komunikacyjne, stacje ładowania flot, terminale logistyczne, gdzie trzeba „wyssać” dużo danych z pojazdu w krótkim czasie (np. logi, dane z sensorów).
Dla pojazdów w ruchu (samochody, ciężarówki) nadmierne poleganie na mmWave jest ryzykowne – wystarczy budynek lub drzewo, by sygnał znacznie osłabł. Z drugiej strony drony, które poruszają się powyżej zabudowy, mogą lokalnie korzystać z mmWave z dużo lepszym skutkiem, o ile operator odpowiednio zaprojektuje siatkę stacji bazowych. Roboty miejskie zwykle poruszają się wolno, często w określonych korytarzach, więc można dla nich precyzyjnie zaplanować obszary silnego zasięgu.
Slicing, QoS, URLLC, mMTC – teoria kontra realne wdrożenia
5G oferuje zestaw zaawansowanych mechanizmów:
- Network slicing – logiczny podział jednej fizycznej sieci na wiele „wycinków” (slice), np. osobno dla służb ratunkowych, flot miejskich, konsumentów indywidualnych.
- QoS (Quality of Service) – priorytetyzacja ruchu, gwarantowane parametry opóźnień i przepustowości dla wybranych usług.
- URLLC (Ultra-Reliable Low Latency Communications) – tryb dla krytycznych zastosowań z niskimi opóźnieniami i wysoką niezawodnością.
- mMTC (massive Machine-Type Communications) – obsługa bardzo dużej liczby urządzeń IoT na niewielkim obszarze.
W materiałach marketingowych często zakłada się, że wszystkie te funkcje są dostępne od ręki w każdej sieci 5G. Rzeczywistość jest bardziej zachowawcza:
- network slicing jest wdrażany stopniowo i zwykle najpierw w zastosowaniach B2B (np. dla przemysłu, portów, lotnisk),
- pełne URLLC bywa ograniczone do wybranych obszarów lub prywatnych sieci kampusowych,
- mechanizmy QoS działają, ale sposób, w jaki można z nich korzystać jako klient (miasto, operator floty), zależy od modelu biznesowego i umów z operatorem.
Przy planowaniu systemu autonomicznej mobilności trzeba weryfikować, które z funkcji 5G są dostępne u danego operatora i na danym obszarze. Zakładanie pełnego pakietu 5G-standalone, gdy w praktyce jest wdrożone 5G NSA (Non-Standalone) z ograniczonym wsparciem URLLC, to typowy błąd.
Ograniczenia: zasięg, przełączanie komórek, przeciążenia
Autonomiczne pojazdy w ruchu generują specyficzne obciążenie dla sieci. Pojawiają się trzy kluczowe wyzwania:
- Handover przy dużej prędkości – samochód lub ciężarówka jadąca z prędkością autostradową musi płynnie przełączać się między komórkami. Każde „szarpnięcie” w połączeniu wpływa na jakość zdalnego sterowania i transmisji danych z sensorów.
- Przeciążenie komórek w centrach miast – gęsta zabudowa, duża liczba użytkowników indywidualnych, reklamy DOOH, systemy miejskie, roboty, drony – wszystko walczy o pasmo. Bez odpowiedniej konfiguracji priorytetów krytyczny ruch V2X może się „dusić” obok ruchu rozrywkowego.
- „Cienie” zasięgu – tunele, podziemia, wąskie uliczki, głębokie podcienia. Autonomiczne pojazdy muszą sobie radzić w miejscach, gdzie sieć jest słabsza lub zanika. To wymusza projektowanie trybów awaryjnych i buforowanie danych.
Sieć 5G nie usuwa magicznie problemów radiowych – zmienia jedynie zestaw narzędzi do ich obsługi. Im bardziej system mobilności jest zależny od ciągłej łączności, tym więcej uwagi trzeba poświęcić analizie realnego pokrycia i marginesu bezpieczeństwa.
Architektura „auta, drona i robota” w jednej sieci
Różne profile komunikacji: auto, dron, robot miejski
Pojazdy drogowe, drony i roboty miejskie mają różne „charaktery komunikacyjne”:
- Auto/autobus/ciężarówka – korzysta z kanałów V2X (V2V, V2I), wymienia dane z chmurą (aktualizacje map, diagnostyka), obsługuje infotainment pasażerów. Ruch jest mieszany: czasem krytyczny (ostrzeżenia kolizyjne), częściej zwykły (nawigacja, multimedia).
Wspólny „mózg” czy lokalna autonomiczność – jak rozkładać odpowiedzialność
Przy projektowaniu komunikacji między autem, dronem i robotem trzeba zdecydować, które funkcje są lokalne, a które zależne od sieci. Ideologiczne skrajności („wszystko w chmurze” kontra „pełna autonomia offline”) rzadko działają dobrze w praktyce.
- Lokalnie (on-board) powinny działać funkcje bezpieczeństwa wymagające reakcji w milisekundach: unikanie kolizji, utrzymanie pasa ruchu, lądowanie awaryjne drona, zatrzymanie robota przy wykryciu pieszego na torze ruchu.
- Zależne od sieci mogą być funkcje koordynacji i optymalizacji: przydział zadań flotowych, planowanie tras z uwzględnieniem ruchu i robót drogowych, aktualizacje map HD, analizowanie logów z sensorów.
5G ma ułatwiać koordynację i nadzór, a nie zastępować podstawowe algorytmy bezpieczeństwa na pokładzie. Każdy projekt, który zakłada, że pojazd „nie musi dużo umieć, bo wszystko zrobi chmura po 5G”, przy pierwszym poważniejszym blackoutcie sieci pokaże swoje słabe punkty.
Edge computing jako „lokalna chmura” dla mobilności
Jednym z realnych atutów 5G jest możliwość ścisłej integracji z edge computing – serwerami obliczeniowymi umieszczonymi blisko stacji bazowych. To dobre miejsce na logikę, która:
- wymaga większej mocy obliczeniowej niż komputer pokładowy,
- nie jest krytyczna w skali pojedynczych milisekund,
- korzysta z danych z wielu pojazdów jednocześnie.
Przykładowo, flota robotów sprzątających może przesyłać do edge zanonimizowane dane z lidarów, a lokalny serwer generuje tymczasową „mapę przeszkód” dla całego kwartału miejskiego. Gdy jeden robot zauważy nagłą zmianę (rozstawione barierki), reszta otrzymuje informację już z edge, bez konieczności „odkrywania” przeszkody samodzielnie.
Kluczowy problem: lokalizacja edge względem obszaru działania. Jeżeli drony i pojazdy przemieszczają się między dzielnicami pod różnymi stacjami bazowymi i różnymi regionami edge, pojawiają się pytania o migrację sesji, replikację danych i spójność. To nie jest wyłącznie temat telekomunikacyjny – wpływa bezpośrednio na architekturę oprogramowania flotowego.
Bezpieczeństwo i aktualizacje OTA w środowisku 5G
Wspólna sieć dla aut, dronów i robotów oznacza wspólne wektory ataku. 5G samo w sobie ma rozbudowane mechanizmy bezpieczeństwa, ale:
- pojazd jest zbiorem różnych interfejsów (CAN, Ethernet, Wi-Fi, Bluetooth),
- często korzysta z więcej niż jednego modemu (5G, Wi-Fi miejskie, prywatny link),
- komunikuje się z wieloma systemami backendowymi (flota, miasto, producenci komponentów).
Realny problem to zarządzanie aktualizacjami OTA (Over-The-Air) w środowisku, gdzie:
- część pojazdów jest stale online, część tylko okresowo,
- zasięg i przepustowość zmieniają się dynamicznie,
- nie można „zawiesić” krytycznych funkcji na czas update’u.
5G ułatwia dystrybucję dużych pakietów (np. nowych modeli AI dla percepcji), ale konieczne są mechanizmy:
- dzielenia aktualizacji na małe segmenty przesyłane „przy okazji” (np. na postoju, podczas ładowania),
- walidacji kryptograficznej na pokładzie przed instalacją,
- bezpiecznego rollbacku, jeżeli po aktualizacji system zachowuje się nieprawidłowo.
Scenariusz, w którym wszystkie pojazdy określonego typu dostają jednocześnie wadliwy update, jest gorszy niż incydentalny brak zasięgu. Stąd rola 5G jako kanału dystrybucji musi iść w parze z konserwatywnym podejściem do zarządzania wersjami oprogramowania.
Interoperacyjność i standardy – jak „dogadać” różnych producentów
„Auto, dron i robot” rzadko pochodzą od jednego dostawcy. Jeden producent stosuje własne protokoły, drugi inne, trzeci dodaje zamknięte API. Bez wspólnej warstwy komunikacyjnej cała idea współdziałania w jednej sieci kończy się integracyjnym chaosem.
Na poziomie telekomunikacyjnym standardy 3GPP definiują sposoby transmisji (w tym C-V2X), ale:
- format komunikatów (np. ostrzeżenia, status zadania, priorytet) bywa zależny od branżowych standardów ITS,
- miasta często wprowadzają swoje API i modele danych,
- dostawcy platform mobilności próbują „zamykać” klienta w swoim ekosystemie.
Praktyczny kompromis to zdefiniowanie lokalnego „języka mobilności” (np. na poziomie miasta czy regionu), opartego na istniejących standardach (ETSI ITS-G5, SAE J2735/J2945, specyfikacje U-space/UTM dla dronów) i dopiero potem mapowanie go na konkretne kanały 5G. Bez tego każdy nowy typ robota wymaga kosztownej integracji punkt-punkt.
Komunikacja V2X w ekosystemie 5G – gdzie kończy się hype
V2X (Vehicle-to-Everything) a w szczególności C-V2X (Cellular-V2X) są często przedstawiane jako lekarstwo na wszystkie problemy ruchu drogowego. W praktyce ich rola jest istotna, ale ograniczona przez kilka czynników:
- stopień nasycenia flot – dopóki tylko niewielki odsetek pojazdów wysyła i odbiera komunikaty V2X, korzyści są fragmentaryczne,
- kompatybilność – różne generacje sprzętu, różne implementacje stosu,
- spójność z infrastrukturą miejską – sygnalizacje świetlne, czujniki na skrzyżowaniach, systemy zarządzania ruchem dodatkowo komplikują obraz.
5G wnosi do V2X:
- lepszy uplink i możliwość przesyłania danych bogatszych niż klasyczne komunikaty CAM/DENM (np. skrócone chmury punktów, status czujników),
- mechanizmy priorytetyzacji dla ruchu krytycznego (w ramach QoS),
- łatwiejszą integrację z usługami edge, które mogą agregować i przetwarzać informacje od wielu pojazdów.
Jednocześnie autoproducenci, którzy projektują pojazdy tak, jakby kluczowe decyzje miały zależeć od V2X, wchodzą na grząski grunt. Obecnie V2X to wsparcie (dodatkowe źródło informacji), a nie jedyna baza do podejmowania decyzji o hamowaniu czy skręcie. Ten paradygmat raczej utrzyma się jeszcze długo, bo pełne pokrycie V2X na poziomie floty i infrastruktury rośnie powoli.
Tryby bezpośrednie i sieciowe C-V2X
C-V2X obejmuje dwa podstawowe sposoby komunikacji:
- tryb bezpośredni (PC5) – pojazdy komunikują się między sobą oraz z infrastrukturą bez pośrednictwa stacji bazowej,
- tryb sieciowy (Uu) – komunikacja odbywa się poprzez sieć komórkową, z udziałem stacji bazowych i core 5G.
Tryb bezpośredni jest mniej zależny od pokrycia siecią, ale opiera się na dedykowanym paśmie i wymaga kompatybilnych modułów w pojazdach. Tryb sieciowy korzysta z benefitów 5G (slicing, QoS, edge), lecz jest wrażliwy na zasięg, przeciążenia i opóźnienia.
Dobrze zaprojektowany system mobilności traktuje je komplementarnie:
- informacje typu „nagłe hamowanie, pojazd poprzedzający” – PC5,
- dane typu „korek 2 km dalej, przewidywany czas przejazdu” – sieć komórkowa z dostępem do danych z wielu źródeł,
- nadzór flotowy, raportowanie, planowanie – niemal wyłącznie kanał sieciowy.
To rozdzielenie pomaga ograniczyć ryzyko, że pojedyncza awaria (np. awaria sieci komórkowej w rejonie) pozbawi system kluczowych sygnałów bezpieczeństwa.
Infrastruktura drogowa „pod 5G” – nie tylko maszt przy autostradzie
Mówiąc o 5G dla ruchu drogowego, większość osób wyobraża sobie maszt przy drodze. Rzeczywistość bywa bardziej rozproszona:
- stacje bazowe zintegrowane z latarniami ulicznymi,
- małe komórki wbudowane w wiaty przystankowe,
- urządzenia roadside units (RSU) pełniące rolę bram V2X->5G.
W gęstej zabudowie system projektuje się pod kątem:
- minimalizacji „dziur” zasięgu na skrzyżowaniach o skomplikowanej geometrii,
- obsługi szczytowego ruchu (eventy, mecze, manifestacje),
- koordynacji z miejskimi systemami ITS (np. sygnalizacją SCATS, SCOOT).
Problemem są odcinki „szczególne”: tunele, estakady, wielopoziomowe skrzyżowania. Tu często stosuje się hybrydę:
- lokalne systemy ITS w tunelu (czujniki, kamery, sterowniki),
- wewnętrzne repeatery/komórki 5G,
- buforowanie danych i aplikacyjne „tryby tunelowe” w pojazdach (ograniczone poleganie na łączności).
Architektura nie kończy się więc na warstwie radiowej – wymaga dopasowania polityk ruchu, algorytmów w pojazdach i planowania utrzymania infrastruktury drogowej.
Komunikacja V2X i C-V2X – realna rola 5G w ruchu drogowym
Jakie komunikaty naprawdę „jadą” po V2X
Komunikacja V2X jest często prezentowana jako strumień zaawansowanych danych, podczas gdy w praktyce dominują proste, cykliczne komunikaty. Typowe kategorie to:
- CAM (Cooperative Awareness Message) – informacja o pozycji, prędkości, kierunku, stanie świateł, profil pojazdu; wysyłana regularnie, częściej przy zmianach sytuacji.
- DENM (Decentralized Environmental Notification Message) – komunikaty zdarzeniowe, np. wypadek, przeszkoda na drodze, śliska nawierzchnia.
- SPaT/MAP – informacje o stanie sygnalizacji świetlnej i geometrii skrzyżowania (z infrastrukturą, nie tylko pojazd–pojazd).
5G umożliwia poszerzenie tego katalogu o:
- rozszerzoną percepcję (collective perception) – obiekty widziane przez inne pojazdy lub infrastrukturę, ale niewidoczne dla lokalnych sensorów,
- dane predykcyjne (np. planowany ruch pojazdu uprzywilejowanego, przewidywana zmiana świateł),
- informacje o politykach ruchu (zakres strefy Tempo 30, priorytety dla pojazdów komunikacji zbiorowej).
W praktyce duża część nowatorskich usług V2X kończy się na pilotażach, ponieważ:
- mało które miasto ma spójną cyfrową reprezentację stanu sygnalizacji i geometrii dróg,
- systemy zarządzania ruchem są „starsze” niż 5G i słabo integrują się z nowymi interfejsami,
- ustalenie odpowiedzialności za błędne komunikaty (np. zły czas do zmiany świateł) bywa trudne prawnie.
Priorytety dla pojazdów uprzywilejowanych a 5G
Teoretycznie V2X po 5G pozwala na:
- dynamiczne nadawanie priorytetu pojazdom uprzywilejowanym (karetki, straż, policja),
- koordynację sygnalizacji świetlnej, aby tworzyć „zielone korytarze”,
- ostrzeżenia wprost do innych pojazdów i robotów miejskich, aby ustąpiły z trasy przejazdu.
Realne wdrożenia pokazują jednak problemy:
- nie wszystkie pojazdy w pobliżu są „smart” – część nadal nie ma żadnych modułów V2X,
- koordynacja z pieszymi i rowerzystami (często poza siecią 5G) wymaga dodatkowych mechanizmów bezpieczeństwa,
- miasto musi zaakceptować, że system telekomunikacyjny współdecyduje o priorytetach ruchu – co rodzi pytania o niezawodność, cyberbezpieczeństwo i odpowiedzialność.
Sensownym kierunkiem jest start od hybryd: 5G + klasyczne pętle indukcyjne + detektory wideo. V2X dostarcza dodatkową informację, ale nie jest jedynym źródłem prawdy o obecności pojazdu uprzywilejowanego.
Wpływ V2X na autonomiczną jazdę po mieście
Dla w pełni autonomicznych pojazdów miejskich V2X ma dwie główne role:
Rola V2X w lokalnym podejmowaniu decyzji
Pierwszy obszar to lokalne wsparcie decyzji. Pojazd używa V2X, aby „zajrzeć za róg” lub skrócić czas reakcji na zmieniające się warunki, ale nadal bazuje głównie na własnych sensorach. Typowe zastosowania to:
- wykrycie zbliżającego się pojazdu uprzywilejowanego, który jest zasłonięty budynkami,
- informacja o pieszych na przejściu, wykrytych przez infrastrukturę, ale niewidocznych jeszcze dla kamer pojazdu,
- wstępne ostrzeżenie o pojazdach jadących „pod prąd” lub blokujących pas ruchu za zakrętem.
Autonomiczny system jazdy może wtedy:
- zredukować prędkość zanim zobaczy przeszkodę,
- przygotować bezpieczną trajektorię wyminięcia,
- dostosować zachowanie (np. nie rozpoczynać wyprzedzania) na podstawie sygnałów z inf