Przetwarzanie na żywo czy zapisane dane: czego naprawdę wymaga VPN?

Robot, który przestaje być użyteczny już o jeden pokój dalej, ma problem z łączem albo z obciążeniem pracą znacznie wcześniej niż problem z VPN. Szyfrowanie chroni ścieżkę, ale nie rozszerza zasięgu radiowego i nie sprawia, że zdalne obliczenie kończy się szybciej. Decyzja przed tobą dotyczy tego, która praca naprawdę musi przekroczyć sieć, a ta odpowiedź zwykle usuwa więcej ruchu, niż ludzie się spodziewają. Rozstrzygają to trzy warunki, a przepustowość nie jest jednym z nich.

Trzy układy, jedno pytanie o zależność

Tabela rozdziela układy według tego, co zależy od łącza, a nie według tego, jakie oprogramowanie widać na schemacie.

Żaden wiersz tej tabeli nie jest argumentem bezpieczeństwa. Funkcje sterowania i bezpieczeństwa nadal wymagają rzetelnej odpowiedzi na opóźnienie, utratę pakietów i zerwane połączenie, a żaden wskaźnik tunelu jej nie dostarcza. Tabela pokazuje, gdzie mieszka zależność, i właśnie tę część projekt sieci może realnie zmienić.

Warunek pierwszy: czy odpowiedź musi być na czas?

Jeśli zdalny wynik zasila sterownik, sieć znajduje się wewnątrz pętli sterowania, a jej opóźnienie, jitter i przerwy stają się właściwościami sterowania. Jeśli ten sam wynik zasila tylko ekran, pulpit albo patrzącego człowieka, identyczne opóźnienie jest wyłącznie kosmetyczne.

Praca w pętli zamkniętej przez łącze bezprzewodowe jest możliwa i właśnie stąd pochodzi większość zgłoszeń „VPN jest wolny”, bo tunel jest widocznym elementem, a przyczyną są radio i trasowanie. Mierz czas rundy rzeczywistej wiadomości, a nie ping samego tunelu, potem zapytaj, czy ta liczba mieści się w budżecie pętli. Jeśli się nie mieści, przenieś krok na pokład zamiast negocjować ostrzejszy poziom usługi dla łącza, którego nikt w pomieszczeniu nie kontroluje. Zapisz zmierzoną liczbę wraz z warunkami, w których ją uzyskano, bo następny raport dotrze bez nich.

Warunek drugi: jakie tempo, kierunek i przerwę możesz zadeklarować?

Zapisz dane, tempo, kierunek i najdłuższą przerwę, jaką toleruje aplikacja. Strumień kamery w górę i kanał poleceń w dół zawodzą inaczej, a przerwa, którą toleruje badanie stacjonarne, zakończy zadanie w ruchu.

Porównując opcje, trzymaj fizyczne podłączenie i tunel osobno, bo mocniejsze radio i mniejsze obciążenie pracą to różne naprawy. Duży transfer, który w końcu się kończy, niczego nie dowodzi o wyniku wrażliwym na czas, który przychodzi regularnie, a zdrowy tunel niczego nie dowodzi o radiu za nim.

Potem zmniejsz popyt zamiast go bronić. Zmniejsz próbkowanie strumienia obserwacyjnego, wysyłaj podsumowania lub delty, a surowe dane czujników zostaw na pokładzie tam, gdzie pamięć jest tania, a transmisja nie. Mniejszy ładunek osłabia argument za szybszym łączem i często usuwa potrzebę jego istnienia.

Warunek trzeci: kto musi to widzieć i co zostaje lokalnie

Obserwacja to zwykle znacznie mniejsze wymaganie niż przetwarzanie. Jeśli człowiek musi patrzeć na kamerę i potem musi istnieć log, to telemetria plus pamięć; jeśli model musi działać, najpierw zapytaj, czy może działać na pokładzie i przekazywać tylko swój wynik. Przeniesienie ciężkiego kroku na pokład usuwa zależność synchroniczną i zostawia transfer, który można ponowić.

Dwa procesy ROS na tym samym robocie nie uzasadniają tunelu same z siebie. Osiągalność węzłów, autoryzacja aplikacji i lokalny plan odzyskiwania to osobne problemy, a VPN odpowiada tylko na pierwszy i tylko dla ruchu, o którego trasowanie zostanie poproszony.

Zapis zbioru danych to własny projekt, z własnymi poleceniami

Dla przykładu powiązanego z wersją, samouczek nagrywania ROS 2 Jazzy omawia nagrywanie wybranych tematów, sprawdzanie powstałego baga i odtwarzanie go. Nagraj zatwierdzone tematy obserwacyjne, nadaj przebiegowi nazwę i trzymaj definicje wiadomości oraz konfigurację obok niego.

ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42

Nie nagrywaj każdego tematu dlatego, że narzędzie to ułatwia. Pamięć się zapełnia, dane kamery i lokalizacji są wrażliwe, a bag z nieoznaczonymi tematami jest problemem analitycznym dla tego, kto otworzy go następny. Wdrożona dystrybucja decyduje też o poleceniach: narzędzia pisane dla bagów ROS 1 nie przenoszą się na bagi ROS 2, więc dopasuj dokumentację do wersji zainstalowanej na robocie.

Odtwarzaj w odizolowanym środowisku analizy lub symulacji. Odtwarzanie nagranych tematów poleceń do siłowników działającego robota to wypadek, a zapobieganie to osobna domena ROS albo brak sprzętu w pętli.

Zdecyduj, gdzie należy zależność, i zapisz to: VPN chroni wymianę, która musi się odbyć, przetwarzanie na pokładzie usuwa wymianę, która nigdy nie musiała być synchroniczna, a zapisany zbiór danych zastępuje odbiorcę na żywo późniejszym. Potem celowo przetestuj przypadek rozłączenia, gdy lokalne zadanie wciąż działa, zanim ktoś uzna projekt za skończony.