Zapytaj sprzedawcę PLC o MQTT, a dostaniesz mapę drogową: "w przyszłym roku, może, na modelu premium." Potem patrzysz na mały druk i znajdujesz bramkę, konwerter lub subskrypcję w chmurze ukrywającą się za funkcją. Wsparcie MQTT na procesorach Ethernet xLogic nie ma tego wszystkiego — jest w oprogramowaniu od wersji 1.04 i publikuje bezpośrednio z kontrolera.
To zmienia to, co może zrobić budżetowa maszyna, a większość integratorów tego nie zauważyła.
Dlaczego MQTT dlaMicro PLC
MQTT jest zaprojektowane dokładnie na tę sytuację: urządzenie w zawodnej sieci, publikujące małe wiadomości do brokera, z subskrybentami, którzy przychodzą i odchodzą. Maszyna w fabryce, stacja pomp w polu, szklarnia dwie godziny od biura — każda publikuje swój status; pulpit w chmurze, aplikacja na telefon i laptop inżyniera subskrybują ten sam temat. Bez zapytań, bez otwartych portów w zakładzie, bez serwera SCADA opiekującego się połączeniem.
Broker radzi sobie z chaosem. PLC po prostu publikuje.
Co właściwie konfigurujesz
Bloki połączeń żyją w programie: ustaw adres brokera, temat, interwał publikacji i mapuj, które wartości idą w ładunku. CPU zarządza cyklem życia połączenia — ponowne połączenie po przerwaniu, ponowna publikacja po przerwie — co jest częścią, która zabija ręcznie wykonane implementacje.
Połącz to z serwerem WWW i alarmem SMS, a masz trzy niezależne zdalne kanały na jednym kontrolerze. Pulpit w chmurze dla biura, strona przeglądarki dla operatora, SMS dla inżyniera dyżurnego. Wybierz swój kanał w zależności od odbiorcy.
Prawdziwy przypadek: zdalne monitorowanie szklarni
Szkółka z czterema stanowiskami chciała widoczności w chmurze bez przebudowy sieci lokalnej. Każdy kontroler stanowiska publikował temperaturę, wilgotność i status zaworu do brokera na wynajmowanym VPS; prosty pulpit subskrybował i pokazywał wszystkie cztery stanowiska na jednym ekranie. Gdy internet padł na popołudnie, kontrolery nadal publikowały do lokalnej kolejki, a wartości nadrobiły po ponownym połączeniu.
Podsumowanie hodowcy, przetłumaczone z entuzjastycznego: "Obserwowałem wykres temperatury z telefonu podczas wakacji. To było lepsze niż bycie tam."
Gdzie MQTT jest złym rozwiązaniem
Bądź szczery co do ograniczeń. MQTT jest zorientowane na zdarzenia i telemetrię — nie jest to deterministyczna pętla kontrolna. Jeśli potrzebujesz gwarantowanej dostawy i reakcji w milisekundach, użyj Modbus TCP lokalnie. MQTT jest do nadzoru i raportowania, nie do blokowania bezpieczeństwa. Zaprojektuj to w ten sposób, a będzie ci służyć przez lata.
I trzymaj dane logowania brokera w porządku. PLC, które publikuje na publicznym temacie, to PLC, które nadaje swoje sprawy. Prywatne tematy, lokalny broker lub przynajmniej TLS na brokerze — koszt konfiguracji to minuty, a wstyd, którego można uniknąć, jest realny.
Wzór wart kradzieży
Projektowanie tematów, które się skalują
MQTT jest tak czyste, jak twoja struktura tematów, a struktura tematów to miejsce, gdzie małe projekty cicho stają się niezarządzalne. Naiwne podejście — jeden temat na urządzenie, jeden ładunek ze wszystkim w środku — działa dla jednej maszyny i załamuje się przy dziesięciu. Każdy subskrybent ponownie analizuje każdy ładunek, każda zmiana w ładunku łamie każdy pulpit, a debugowanie staje się polowaniem na temat po temacie.
Zaprojektuj hierarchię przed pierwszą publikacją. Wzór, który dobrze mi służył:strona/urządzenie/kategoria/wartość. Więcplant1/pump1/status/run, plant1/pump1/sensor/level, plant1/pump2/alarm/high-level. Subskrybenci z dzikimi kartami — pulpit dla plant1, strona dla pump1, słuchacz alarmów dla wszystkiego — każdy subskrybuje dokładnie to, czego potrzebuje. Nowe urządzenia wpasowują się bez dotykania starych tematów, a ładunki pozostają małe i typowane.
Utrzymuj ładunki proste: wartość i znacznik czasu. Żadne zagnieżdżone bloby JSON trzymające jedenaście pól, chyba że naprawdę ich potrzebujesz. Proste ładunki są łatwe do debugowania — możesz przeczytać jeden w konsoli brokera i od razu wiedzieć, czy jest poprawny. I ustaw flagę retain na tematach statusu, aby nowy subskrybent natychmiast widział ostatni znany stan zamiast czekać na następną publikację. Zachowany stan to różnica między pulpitem, który otwiera się gotowy, a takim, który przez minuty patrzy pustym wzrokiem.
Ostatnia zasada to ta, której ludzie się opierają: wersjonuj temat, gdy zmienia się format ładunku.plant1/pump1/status/v2. To jest brzydkie. Ratuje cię przed złamaniem pięciu subskrybentów w produkcji jednym zmianą. Brzydkie tematy, które działają, pokonują czyste tematy, które eksplodują.
Dane warte publikacji
Publikowanie wszystkiego jest tak samo złe jak publikowanie niczego — zalewa brokera, powiększa logi i zakopuje wartości, które mają znaczenie. Zacznij od pytania, które zada subskrybent, a nie od listy rejestrów. Operator chce statusu, alarmów i sum bieżących. Inżynier chce trendów: temperatury, ciśnienia, godzin pracy. Menedżer chce czasu pracy i liczb. Publikuj te, i tylko te.
Stawki też mają znaczenie. Przejścia alarmów: publikuj natychmiast, zawsze. Status: przy zmianie plus puls. Wartości analogowe: w interwale, który rzeczywiście pokazuje proces — dziesięć sekund dla wolnej temperatury w szklarni, jedna sekunda dla narzędzia maszynowego. Każdy szybki temat, którego nie potrzebujesz, to zmarnowany ładunek brokera i zmarnowane dane SIM w modelach bezprzewodowych.
I loguj ważne lokalnie. Datalogging CPU plus wiadomości zachowane przez brokera daje ci dwie kopie krytycznej historii. Gdy broker ma zły dzień — wszyscy mają — log po stronie maszyny jest źródłem prawdy, a rozmowa o odzyskiwaniu jest krótka.
Lokalna kontrola na CPU, widoczność w chmurze przez MQTT, a te dwa nigdy się nie zakłócają. Ta separacja to architektura nowoczesnej małej automatyki, a ona pasuje na szynę DIN. Mapa drogowa sprzedawcy nie nadeszła. Oprogramowanie już zostało wysłane.
