Jedno moduł DIN-rail mówiące MQTT do chmury, BACnet do budynku i Modbus TCP do maszyn. To zdanie opisuje panel pełen bramek. Teraz opisuje pojedyncze kompaktowe CPU z obsługą Ethernetu, a historia wieloprotokołowa na platformie xLogic nie jest slajdem marketingowym — jest w oprogramowaniu, udokumentowana w kolejnych wersjach instrukcji: MQTT od V1.04, BACnet od V1.57, Modbus od pierwszego dnia.
Oto jak to wykorzystać, nie tworząc koszmaru konserwacji.
Mapa protokołów
Każdy protokół ma swoją naturalną publiczność, a sztuczka polega na ich oddzieleniu:
- Modbus TCP— podłoga maszyn: falowniki, HMI, SCADA, inne PLC. Deterministyczne, oparte na rejestrach, uniwersalne połączenie przemysłowe
- MQTT— chmura: publikowanie telemetrycznych danych do brokera, pulpity nawigacyjne subskrybują. Oparte na zdarzeniach, przyjazne dla NAT, stworzone dla niezawodnych sieci
- BACnet— budynek: pomieszczenia techniczne, AHU, systemy zarządzania budynkiem (BMS). Rodzimy język branży nieruchomości
Jedno CPU obsługujące wszystkie trzy grupy oznacza, że budowniczy maszyn, zarządca obiektów i pulpit chmurowy widzą to samo urządzenie — każdy w swoim własnym języku, żaden z nich nie potrzebuje konwertera.
Prawdziwy budynek: Małe pomieszczenie techniczne
Pomieszczenie z AHU, dwiema grupami wentylatorów i pompą ciepła: Modbus TCP do lokalnego HMI i VFD, BACnet do BMS budynku w celu harmonogramowania i alarmów, MQTT do usługi chmurowej do zdalnego trendowania. Trzy protokoły, jeden kontroler, jeden program. Inżynier BMS zapytał, kto zrobił bramkę. Odpowiedź — "nie ma bramki" — wywołała ciszę, która trwała pełne pięć sekund.
Ta cisza to produkt działający.
Co należy oddzielić
Protokół może dzielić CPU, ale nie powinien dzielić planu danych. Mapuj punkty raz, celowo: które rejestry są widoczne w Modbusie, które obiekty są BACnet, które tematy są MQTT. Jedna mapa punktów, utrzymywana w jednym arkuszu kalkulacyjnym, zapobiega klasycznemu błędowi — zmiana numeru rejestru i trzy systemy cicho stają się nieaktualne.
I pamiętaj o ograniczeniach modeli: BACnet/IP i MQTT potrzebują CPU z obsługą Ethernetu. Modele tylko szeregowe obsługują Modbus RTU i BACnet/MSTP. Sprawdź model w odniesieniu do wymagań przed obietnicą, a nie po złożeniu zamówienia.
Kąt wsparcia, którego nikt nie wycenia
Wieloprotokołowość to nie tylko funkcja; to drzwi do sprzedaży. Przetargi teraz wymagają integracji BMS jako standardu, łączności z chmurą jako pozycji na liście kontrolnej. Kontroler, który odpowiada na obie potrzeby bez dodatków, przechodzi przez filtr wstępnej kwalifikacji. Różnica cenowa między wersjami jednoprotokołowymi a wieloprotokołowymi jest mała; różnica w projektach, na które możesz składać oferty, nie jest.
Dyscyplina mapy punktów
Wieloprotokołowość to błogosławieństwo i pułapka. Błogosławieństwo: jedno CPU obsługujące trzy systemy. Pułapka: trzy systemy odczytujące nieco różne wersje prawdy. Naprawa jest nudna i niepodlegająca negocjacjom — jedna mapa punktów, która wymienia każdą wartość raz, z jej rejestrem, obiektem BACnet i tematem MQTT w tym samym wierszu.
Rozpocznij arkusz kalkulacyjny od pierwszego dnia, zanim pierwszy blok zostanie podłączony. Kolumny: nazwa wartości, rejestr Modbus, typ i instancja obiektu BACnet, temat MQTT, typ danych, skalowanie, częstotliwość aktualizacji i który system jest autorytatywny dla zapisów. Ostatnia kolumna ma większe znaczenie, niż ludzie myślą — gdy zarówno BMS, jak i pulpit chmurowy chcą zmienić punkt ustawienia, ktoś musi wygrać, a mapa mówi, kto. Bez niej dwa systemy walczą o jedną wartość, a maszyna zachowuje się nieprzewidywalnie o 3 nad ranem.
Wersjonuj mapę z programem. Każda zmiana oprogramowania, każdy dodany punkt, każde ponumerowanie — mapa aktualizuje się w tym samym commicie. Dziedziczyłem projekty, w których mapa była dwa lata przestarzała, a trzy osoby miały różne kopie. Odbudowa zajęła tydzień wpatrywania się w tabele rejestrów. Tydzień. Nie bądź tym projektem.
I testuj ścieżki międzyprotokolowe celowo: zapisz punkt ustawienia z BMS, zweryfikuj, że maszyna odpowiada, zweryfikuj, że pulpit chmurowy pokazuje zmianę. Jeden test end-to-end na punkt, przy uruchomieniu, wychwytuje błędy mapowania, gdy są tanie do naprawy.
Rzeczywistość oprogramowania i wersji
Funkcje protokołu przychodziły falami, a historia rewizji instrukcji opowiada tę historię: MQTT w 4.2, serwer WWW w 4.5, instrukcje WiFi w 6.0, BACnet w 6.2, wsparcie dla SR-22 w 6.2.1. Jeśli planujesz projekt wieloprotokołowy, wersja oprogramowania nie jest szczegółem — to wymóg. CPU, które wysłano dwa lata temu, może potrzebować aktualizacji, zanim zacznie mówić BACnet, a ścieżka aktualizacji zależy od modelu.
Uczyń sprawdzanie oprogramowania częścią listy kontrolnej przed sprzedażą. Zapisz wersję w zamówieniu, potwierdź ją przy dostawie i udokumentuj na arkuszu uruchomieniowym. Najdroższa rozmowa w tym biznesie to "powinno to wspierać" a następnie "to nie wspiera".
I trzymaj protokoły uczciwe co do ich mocnych stron. BACnet dla budynku, Modbus dla maszyn, MQTT dla chmury — każdy na typie przewodu, do którego został zaprojektowany. CPU Ethernet obsługuje wszystkie trzy jednocześnie; nie czyni ich magicznie jednym protokołem i nie powinno. Oddzielenie to to, co utrzymuje zakład w ruchu, gdy łącze chmurowe przestaje działać — lokalny ruch Modbus i BACnet nie czeka na internet.
Nawyk dokumentacji protokołów
Kontroler obsługujący trzy protokoły bez mapy protokołów to eksponat muzealny. Dyscyplina kosztuje godzinę przy uruchomieniu i oszczędza tydzień za każdym razem, gdy budynek się zmienia: jeden arkusz wymieniający każdy punkt, jego rejestr Modbus, jego obiekt BACnet i jego temat MQTT — z oznaczoną autoryzacją zapisu. Arkusz żyje z rysunkami paneli, wersjonowany z programem. Gdy inżynier BMS pyta "jaka wartość to temperatura zasilania?" odpowiedzią jest jeden wiersz, a nie popołudnie archeologii rejestrów.
Kup wersję z protokołami. Projekty będą następować.
