W maszynach jednostkowych – stanowiskach montażowych, liniach produkcyjnych i urządzeniach pomiarowych – korekty programu zdarzają się najczęściej w pierwszych tygodniach i miesiącach pracy, gdy produkcja weryfikuje założenia przyjęte na etapie projektu. Poniżej opisujemy, jak zbudowaliśmy zdalny dostęp do maszyn oparty na minikomputerze Raspberry Pi, tunelu VPN WireGuard i protokole MQTT, co da się w ten sposób zrobić, a czego zdalnie robić nie należy.
Dlaczego drobna zmiana w programie maszyny potrafiła trwać tygodnie?
Maszyny, które budujemy, sterowane są sterownikami PLC (Programmable Logic Controller – programowalny sterownik logiczny) albo mikrokontrolerami z własnym oprogramowaniem, pisanym pod konkretny proces. Po uruchomieniu u klienta prawie zawsze pojawia się lista poprawek: wydłużenie czasu docisku o 200 ms, zmiana progu czujnika, inna kolejność kroków sekwencji, nowy wariant produktu w recepturach albo czytelniejszy komunikat alarmu dla operatora. Sama zmiana w kodzie zajmuje zwykle od kilkunastu minut do godziny.
Problemem była logistyka wokół tej zmiany. Trzeba było zaplanować wyjazd inżyniera, uzgodnić z klientem okno, w którym maszyna może stanąć, i zarezerwować 1–3 dni na dojazd, wprowadzenie poprawki i testy. W praktyce klienci zbierali prośby w paczki, żeby „opłacić” wizytę, a maszyna przez kilka tygodni pracowała na obejściach: operator ręcznie dociskał detal, pomijał krok albo kasował powtarzający się alarm.
Podobnie wyglądała diagnostyka awarii. Operator opisywał objawy przez telefon, a inżynier próbował odgadnąć przyczynę bez wglądu w stany wejść i wyjść. Często dopiero na miejscu okazywało się, że czujnik indukcyjny przesunął się o 2 mm albo przewód enkodera ma przerwę – czyli coś, co przy podglądzie sygnałów na żywo byłoby widać w kilka minut. Więcej o tym, dlaczego program maszyny rzadko jest „skończony” w dniu odbioru, piszemy w artykule o programowaniu sterowników maszyn.
Przykład z jednej z naszych linii montażowych: klient poprosił o nowy tryb pracy – możliwość przejścia na inny typ montowanego elementu bez opróżniania maszyny. Linia miała kontynuować pracę, a nowy cykl ruszać płynnie za ostatnim detalem poprzedniej serii, bez zatrzymania i ręcznego rozładunku stanowisk. Przygotowanie zmiany w programie sterownika zajęło ok. 2 godzin pracy inżyniera przy biurku, a przesłanie jej na maszynę i sprawdzenie razem z operatorem – kolejne 5 minut. Zakład klienta znajduje się ok. 3 godziny drogi od nas, więc wizyta na miejscu oznaczałaby cały dzień zablokowany dla inżyniera i termin uzgadniany z produkcją z wyprzedzeniem. Zdalnie zmiana trafiła na maszynę od razu, gdy była gotowa.
Skutki dla klienta były zawsze te same: koszty delegacji i przestoju, niska reaktywność na zmiany w produkcji oraz ryzyko, że pojedyncza usterka zatrzyma linię na kilka dni. To był główny powód, dla którego zaczęliśmy przewidywać zdalny dostęp już na etapie projektowania maszyn w ramach automatyzacji produkcji.
Jak zbudowany jest zdalny dostęp do maszyny z Raspberry Pi i WireGuard?
Po przetestowaniu kilku rozwiązań wybraliśmy prostą architekturę z trzech elementów: minikomputera Raspberry Pi w szafie sterowniczej maszyny, serwera VPN (Virtual Private Network – wirtualna sieć prywatna) z publicznym adresem IP oraz stacji inżyniera.
Raspberry Pi montowany jest na szynie DIN i zasilany z obwodu 24 V przez przetwornicę DC/DC. Ze sterownikiem łączy się na dwa sposoby, zależnie od typu maszyny:
- przez Ethernet – w przypadku sterowników PLC, paneli operatorskich HMI (Human-Machine Interface) i napędów z interfejsem sieciowym,
- przez USB, UART lub ISP – w przypadku mikrokontrolerów (np. AVR), gdzie Raspberry Pi pełni jednocześnie rolę programatora i konsoli szeregowej.
Do internetu Raspberry Pi wychodzi przez sieć LAN klienta albo, jeśli dział IT nie chce wpuszczać urządzeń zewnętrznych do sieci zakładowej, przez osobny modem LTE. Kluczowe jest to, że to Raspberry Pi inicjuje połączenie: zestawia wychodzący tunel WireGuard (protokół UDP) do naszego serwera i podtrzymuje go pakietem keepalive co ok. 25 sekund, dzięki czemu tunel przechodzi przez NAT i firewall klienta. Po stronie zakładu nie trzeba więc otwierać portów, przekierowywać ruchu ani mieć publicznego adresu IP.
Inżynier łączy się z tym samym serwerem VPN jako kolejny, osobno autoryzowany uczestnik sieci. Reguły routingu (w WireGuard – lista AllowedIPs) ograniczają, które adresy są dla niego widoczne: zwykle wyłącznie Raspberry Pi i podsieć sterownika konkretnej maszyny. Dalsza praca odbywa się przez SSH (Secure Shell – szyfrowany dostęp do konsoli) albo bezpośrednio z oprogramowania inżynierskiego producenta sterownika, które widzi PLC tak, jakby był podłączony do lokalnej sieci biura.
Dlaczego WireGuard, a nie OpenVPN czy IPsec? Rdzeń WireGuard to kilka tysięcy linii kodu, który jest częścią jądra Linuksa, łatwo go audytować, a konfiguracja sprowadza się do jednej pary kluczy na urządzenie. Tunel odnawia się w ułamku sekundy po zaniku łącza, co przy słabym zasięgu LTE w halach produkcyjnych ma realne znaczenie.
Raspberry Pi ma też ograniczenia, o których warto pamiętać przy projektowaniu szafy. Karta microSD zużywa się przy częstym zapisie, dlatego lepiej stosować karty przemysłowe, system plików w trybie tylko do odczytu albo moduł Compute Module z pamięcią eMMC. Trzeba też sprawdzić temperaturę w szafie – przy falownikach i zasilaczach potrafi przekroczyć 50°C, co wymusza radiator lub wentylację.
Co można zrobić zdalnie, a co nadal wymaga obecności na miejscu?
Najczęstszym zadaniem jest aktualizacja programu. Nowa wersja trafia przez tunel na Raspberry Pi, a stamtąd do sterownika – za pomocą narzędzia producenta PLC albo programatora mikrokontrolera. Zmiana parametru, poprawka logiki sterowania czy dodanie receptury dla nowego wariantu produktu zajmuje kilkanaście minut zamiast wyjazdu serwisowego. Każda wersja programu trafia do repozytorium (Git), więc w razie problemu można w kilka minut wrócić do poprzedniej.
Drugim obszarem jest monitoring. Maszyna publikuje dane przez MQTT (Message Queuing Telemetry Transport) – lekki protokół typu publikuj/subskrybuj, zaprojektowany z myślą o słabych łączach. Typowy zestaw danych to liczniki cykli, stany wejść i wyjść, temperatury, ciśnienia, kody alarmów i czasy postojów. Broker MQTT przekazuje je na dashboard albo do bazy danych, a przy zaniku łącza Raspberry Pi buforuje komunikaty lokalnie i wysyła je po odzyskaniu połączenia. Te same dane mogą zasilać systemy SCADA (Supervisory Control and Data Acquisition – nadzór i wizualizacja procesu) lub MES (Manufacturing Execution System – system realizacji produkcji) i służyć do liczenia wskaźnika OEE (Overall Equipment Effectiveness – całkowita efektywność wyposażenia) bez inwestowania w osobny system telemetrii.
Trzecim obszarem jest diagnostyka. Zdalnie można przeanalizować logi sterownika, obejrzeć stany czujników w czasie rzeczywistym, porównać czasy kroków sekwencji z wartościami z odbioru i wychwycić trend – np. wydłużający się czas wysuwu siłownika, który zapowiada problem z zaworem albo przygotowaniem powietrza. To bezpośrednio wspiera planowanie przeglądów, o którym piszemy w artykule o utrzymaniu ruchu maszyn.
Są jednak rzeczy, których zdalnie nie robimy albo robimy tylko z udziałem osoby przy maszynie:
- wgrywanie programu do pracującej maszyny – najpierw maszyna musi zostać zatrzymana i doprowadzona do stanu bezpiecznego, a operator na miejscu potwierdza gotowość,
- wymuszanie wyjść (np. ruch siłownika czy osi) – tylko przy obecności człowieka, który widzi strefę roboczą,
- zmiany w funkcjach bezpieczeństwa (wyłączniki awaryjne, kurtyny, blokady osłon) – wymagają walidacji na miejscu zgodnie z oceną ryzyka,
- usterki mechaniczne, regulacja czujników i wymiana podzespołów – zdalnie można je zlokalizować, ale naprawić trzeba na miejscu.
Poniższa tabela zestawia typowy przebieg obsługi zmiany przed i po wdrożeniu zdalnego dostępu:
| Obszar | Przed wdrożeniem | Po wdrożeniu |
| Wprowadzenie zmiany w programie | wyjazd serwisowy: 1–3 dni | zdalnie: kilkanaście minut |
| Koszt | delegacja + przestój w oczekiwaniu na wizytę | brak kosztów dojazdu |
| Diagnostyka | tylko na miejscu lub „na telefon” | podgląd sygnałów na żywo, także poza godzinami pracy |
| Dane z maszyny | brak | ciągły monitoring i archiwum |
| Reakcja na zużycie podzespołów | po awarii | na podstawie trendów, przed awarią |
Jak zabezpieczyć zdalny dostęp do maszyny przed nieuprawnionym użyciem?
Zdalny dostęp do sterownika to potencjalna furtka do procesu produkcyjnego, dlatego bezpieczeństwo jest częścią projektu, a nie dodatkiem. WireGuard korzysta z nowoczesnego zestawu kryptograficznego: wymiany kluczy Curve25519, szyfrowania ChaCha20-Poly1305 i funkcji skrótu BLAKE2s. Serwer nie odpowiada na pakiety od nieznanych nadawców, więc przy skanowaniu sieci jego port jest praktycznie niewidoczny.
Każde urządzenie i każdy inżynier ma własną parę kluczy. Odebranie dostępu sprowadza się do usunięcia jednego wpisu na serwerze – nie trzeba zmieniać haseł na wszystkich maszynach. Na samym Raspberry Pi logowanie przez SSH odbywa się wyłącznie kluczem, logowanie hasłem jest wyłączone, a lokalna zapora przepuszcza ruch tylko do adresu sterownika i tylko na portach, których używa oprogramowanie inżynierskie.
Ważna jest też segmentacja sieci. Raspberry Pi stoi pomiędzy siecią zakładową a siecią maszyny i nie łączy ich w jedną – z tunelu nie widać komputerów biurowych klienta, a z sieci biurowej nie widać sterownika. Tam, gdzie klient chce mieć kontrolę nad momentem połączenia, dostęp może być włączany przełącznikiem na szafie albo przyciskiem na panelu HMI. Każda sesja i każda wgrana wersja programu są rejestrowane, więc wiadomo, kto, kiedy i co zmienił.
Te zagadnienia nabierają znaczenia prawnego. Rozporządzenie maszynowe (UE) 2023/1230, stosowane od 20 stycznia 2027 roku, wprowadza wymagania dotyczące ochrony układów sterowania przed nieuprawnioną ingerencją i rejestrowania zmian w oprogramowaniu wpływającym na bezpieczeństwo – szerzej opisujemy to w artykule o rozporządzeniu maszynowym 2023/1230. Punktem odniesienia dla architektury sieci przemysłowych jest też seria norm IEC 62443 dotycząca cyberbezpieczeństwa systemów automatyki.
Zdalny dostęp nie zastępuje wizyty serwisowej tam, gdzie trzeba wziąć klucz do ręki, ale przejmuje większość pracy, która dotyczy programu i danych. Najprościej przewidzieć go już przy projektowaniu nowej maszyny: miejsce na szynie DIN, zasilanie i wolny port komunikacyjny sterownika kosztują niewiele, a dobudowywanie ich później w gotowej szafie jest zawsze trudniejsze.
Najczęściej zadawane pytania
Czy zdalny dostęp do maszyny wymaga publicznego adresu IP lub otwarcia portów w sieci firmy?
Nie. Połączenie inicjuje urządzenie w maszynie, zestawiając wychodzący tunel do serwera VPN. Dział IT zwykle musi jedynie zezwolić na ruch wychodzący UDP do jednego adresu i portu. Jeśli nie jest to możliwe, można użyć osobnego modemu LTE niezależnego od sieci zakładowej.
Co się stanie z maszyną, gdy połączenie internetowe zostanie przerwane?
Nic. Raspberry Pi nie uczestniczy w sterowaniu – maszyna pracuje na własnym sterowniku niezależnie od łącza. Dane z monitoringu są w tym czasie buforowane lokalnie i wysyłane po przywróceniu połączenia.
Czy zdalny dostęp można dodać do starszej maszyny?
W większości przypadków tak, o ile sterownik ma interfejs komunikacyjny (Ethernet, RS-232, RS-485 lub USB) i dostępne jest oprogramowanie do jego programowania. W starszych sterownikach często potrzebny jest konwerter interfejsu. Dobrym momentem na taką rozbudowę jest modernizacja szafy sterowniczej.
Czy przez zdalny dostęp można zmieniać funkcje bezpieczeństwa maszyny?
Zmiany dotyczące funkcji bezpieczeństwa, takich jak wyłączniki awaryjne, kurtyny świetlne czy blokady osłon, wymagają walidacji na miejscu zgodnie z oceną ryzyka. Zdalnie można je przygotować i przeanalizować, ale uruchomienie i sprawdzenie odbywa się przy maszynie.
Kto ma dostęp do maszyny i czy klient może go kontrolować?
Dostęp mają wyłącznie urządzenia i osoby z indywidualnie wygenerowanymi kluczami. Klient może zażądać wyłączenia dostępu w dowolnym momencie, a w wersji z przełącznikiem na szafie lub przyciskiem na panelu HMI sam decyduje, kiedy połączenie serwisowe jest aktywne.
