Do Projektu iAutomatyka dołączyli:

https://iautomatyka.pl/wp-content/uploads/2020/05/artykuł-mqtt-wyrozniona.jpg

Czym jest protokół MQTT?

autor: MATHAEUS.

W przemyśle bardzo często spotykamy się z potrzebą łączenia ze sobą wielu rozproszonych maszyn. Na rynku od wielu lat standardowymi protokołami do wymiany danych między maszynami są np.:

  • Modbus RTU/TCP,
  • Profibus,
  • Profinet,
  • CANopen,
  • ETHERCAT.

W związku z coraz bardziej powszechną cyfryzacją rośnie zapotrzebowanie na zdalne zbieranie informacji z zakładów przemysłowych, jak i zdobywających coraz większą popularność inteligentnych domów. Przesył dużej ilości danych wiążę się z dużymi kosztami oraz ograniczeniami, które wynikają z ograniczonych fizycznie łączy. Naprzeciw potrzeb klientów wychodzi protokół MQTT ( z ang. Message Queue Telemetry Transport), który co ciekawe został zapoczątkowany już w 1999r. Za założycieli, uważa się Andye’go Stanforda-Clarka z firmy IBM oraz Arlena Nippera z firmy Eutotech. W tym artykulę przedstawię zasadę jego działania.

Czym jest protokół MQTT?

Protokół MQTT jest lekkim protokołem transmisji danych, opartym o wzorzec publikacja/subskrypcja, pracujący na szczycie warstwy TCP ( z ang.Transmision Control Protocol) / IP ( z ang. Internet Protocol). Dzięki temu idealnie nadaje się do obsługi wyzwań, które stawiają przed nim funkcje w aplikacjach IoT ( z ang. Internet of Things), czy M2M ( z ang. Machine to Machine).

MQTT to bardzo przydatne narzędzie szczególnie gdy łączymy świat automatyki z wirtualnym światem IT. Obok OPC UA stanowi chyba trzon rewolucji IIoT, a na pewno jest jeden z kluczowych protokołów w telemetrii. Z jednej strony w żaden sposób nie wiąże nas z konkretnym producentem, platformą programistyczną czy systemem operacyjnym, a z drugiej jest skalowalne i tanie w implementacji. W świecie przemysłowego Big Data, gdzie wymagana jest informacja o najdrobniejszym elemencie procesu produkcji taki protokół jest czymś w rodzaju zbawienia. Poprzez zastosowanie bramki IIoT (panel HMI, serii HMe czy serwer FP-I4C) możemy przygotować kolekcje danych pochodzących z różnych elementów maszyny, integrując jednocześnie różne protokoły komunikacyjne warstwy sterowania i wypchnąć je do brokera. To co z nimi dalej się stanie: czy zostaną przetworzone lub zapisane, jaki raport technolog z nich wygeneruje, nas automatyków może tak naprawdę nie interesować.

Odchodząc od typowo postrzeganej automatyki, w naszej przestrzeni już teraz znajdziemy mnóstwo inteligentnych urządzeń, które podłączone są do globalnej sieci Internet i komunikują się z dedykowanym serwisami. Mamy na myśli tak prozaiczne elementy jak dystrybutory napojów, paczkomaty, myjnie, toalety publiczne. One wszystkie raportują swój stan na bieżąco, a część z nich korzysta z MQTT.

Jak potężnym narzędziem jest MQTT pokazuje również fakt, że zostało ono zastosowane w popularnym komunikatorze internetowym jakim jest Messenger. Także część serwisów od Google, czy Amazon pozwala na komunikację z użyciem MQTT.

Moim zdaniem jest to jeden z kilku przypadków w historii, kiedy protokół dostępny dla automatyki jest tak szeroko używany do przetwarzania milionów informacji w IT.

Daniel Leszczewicz, Panasonic

Głównymi zaletami protokołu są:

  • niskie zapotrzebowanie względem zasobów sprzętowych (niski pobór energii),
  • możliwość asynchronicznej wymiany danych w obu kierunkach z niskim poziomem opóźnienia,
  • możliwość odbioru informacji w oparciu o wystąpienie wydarzenia,
  • wymiana informacji, odbywająca się w niemal czasie rzeczywistym,
  • duży stopień skalowania, umożliwiający dystrybucję danych do wielu klientów,
  • łatwość wykorzystania,
  • niskie obciążenie łącza komunikacyjnego,
  • szybkość konfiguracji,
  • niezawodność przy wymianie danych,
  • komunikacja M2M,
  • szyfrowanie i zabezpieczenie komunikacji.

Do wad należy zaliczyć:

  • na dzień dzisiejszy istnieje stosunkowo niewiele urządzeń obsługujących MQTT
  • konieczność uruchomienia brokera.

Do najważniejszych parametrów wyróżniających protokół MQTT należy zaliczyć:

  1. Szybkość transmisji do 1000 mbps,
  2. Ilość urządzeń podłączonych do jednej sieci zależy przede wszystkich od brokera i może ich być ponad 1000,
  3. Jako medium transmisyjne wykorzystywany jest Ethernet,
  4. Transmisja danych jest zabezpieczona przy wykorzystaniu SSL na poziomie samego brokera, a dodatkowo autoryzacja na poziomie dostępu do brokera.

Protokół MQTT zdobywa coraz większą popularność i w 2018 roku był najczęściej stosowanym protokołem w aplikacjach IoT.

Zasada działania

Centralnym elementem komunikacji jest broker MQTT (pełni rolę serwera), który odpowiada za wysyłanie wszystkich wiadomości między nadawcami, a oczekującymi odbiorcami. Każdy klient który, chce wysłać wiadomość przez serwer w nomenklaturze protokołu MQTT to Publisher (wydawca/nadawca). Broker filtruje przychodzące wiadomości i przesyła do klientów zainteresowanych odbiorem wiadomości. Klienci którzy rejestrują się do brokera i są zainteresowani konkretnymi rodzajami wiadomości, są znani jako Subscriber (subskrybenci/odbiorcy). W związku z tym, zarówno wydawcy, jak i subskrybenci nawiązują połączenie z brokerem.

Serwer MQTT jest odpowiedzialny na uwierzytelnianie oraz autoryzację klientów MQTT. Po pomyślnej autoryzacji i uwierzytelnieniu, klienci będą mogli zostać wydawcami jak i odbiorcami.

Diagram przedstawiający przykład komunikacji MQTT pomiędzy sterownikami i oprogramowaniem SCADA. 

Zobaczmy jak to wygląda w praktyce. Do sterownika Astrada One DC2007 podłączony jest miernik energii Lumel, którego zadaniem jest pomiar prądu na silniku od transportera. Powiedzmy, że do prawidłowej pracy całej linii technologicznej informacja o prądzie na silniku musi być przekazana do oddalonego sterownia S7-1200. Dodatkowo pomiar energii monitorowany jest w systemie SCADA np. Wonderware. W naszym przypadku dane z pomiaru udostępnia sterownik Astrady pełniąc funkcję wydawcy (Pubisher), sterownik S7-1200 oraz system monitoringu są z kolej odbiorcami tej wiadomości, co oznacza, że są subskrybentami. Jak już wcześniej wspomniałem serwer (Broker) pełni centralną funkcję w MQTT i to właśnie przez niego przechodzą wszystkie dane. Dane są zapisywane w serwerze w postaci tematów, tak jak w naszym przypadku tematem jest gaugage1/current. Chcąc odczytać dane opublikowane dane musimy zasubskrybować odpowiedni temat). Jak widzimy na diagramie, publisher komunikuje się jedynie z Brokerem i sam nic nie wie o potencjalnych odbiorcach wiadomości. Cała wymiana danych odbywa się za pomocą subskrypcji odpowiednich tematów.


Jak już wcześniej wspomniałem, subskrybenci otrzymują tylko te wiadomości do których są zapisani przez tematy. Dzięki zastosowaniu filtracji tematów, nie otrzymujemy informacji innych niż jesteśmy zainteresowani. Jeśli publisher chce opublikować wiadomość, to musi ona określać zarówno temat, jak i wiadomość. Serwer nie musi sprawdzać zawartości wiadomości, aby móc ją dostarczyć do odpowiednich adresatów, wystarczy sprawdzić jedynie temat każdej otrzymanej wiadomości, która przed opublikowaniem jest odpowiednio filtrowana.  Filtrowanie tematów pozwala na obserwację więcej niż tylko jednego tematu. Na poniżej przedstawionym diagramie system do pomiaru energii publikuje 2 tematy dotyczące prądu oraz napięcia, z jakiegoś względu w systemie SCADA chcemy wiedzieć jaki płynie prąd w silniku i nie potrzebujemy napięcia, dlatego zapisujemy się tylko do tematu gaugage1/current. Nie oznacza to, że inne urządzenie nie może otrzymywać obu informacji. Jak widzimy Astrada zbiera informacje zarówno o prądzie jak i napięciu na silniku. Dzięki mechanizmowi filtracji każdy dostaje tylko te dane, które chce.

Ważne: 

Każde urządzenie, które posiada pakiet TCP/IP i jest w stanie korzystać z biblioteki MQTT, może pełnić zarówno rolę nadawcy jak i odbiorcy. Biblioteka MQTT umożliwia urządzeniom komunikację w pakiecie TCP/IP oraz interakcję z określonymi typami serwerów MQTT. Planując nasz system powinniśmy wcześniej sprawdzić jakie możliwości oferują dostępne na rynku serwery i wybrać ten który najlepiej spełnia nasze oczekiwania. Może się okazać, że wybrany broker ma zaimplementowaną tylko część możliwości i posiada ograniczenia, które mogą nie spełniać wymagań naszej aplikacji. Tak samo jak w przypadku innych produktów, możemy spotkać wersje typu open source, darmowe oraz płatne. Oprócz wymagań sprzętowych, które musi spełnić serwer MQTT musimy również zwrócić uwagę na jego cenę.

Operacja publikacji wiadomości może odbywać się zarówno synchronicznie jak i asynchronicznie. Asynchroniczna komunikacja pozwala uniknąć blokady do czasu dostarczenia wiadomości do klientów. Synchroniczna komunikacja pozwala kontynuować dopiero po zakończeniu operacji. W większości przypadków wykorzystuje się komunikację asynchroniczną.

Każdy subskrybent może również pełnić rolę wydawcy wiadomości.

FP-i4C

Kompaktowy serwer i bramka IIoT. Urządzanie poza typową wizualizacją danych na stronie www, ich zapisem i udostępnianiem poprzez wbudowany serwer FTP, umożliwia bezpośrednią komunikację z bazami danych SQL. Dodatkowo może pełnić rolę serwera lub klienta OPC UA czy łączyć się z serwisami internetowymi przy pomocy protokołu MQTT. Uzupełnieniem funkcjonalności jest opcja zdalnego dostępu z wykorzystaniem usługi Corvina Cloud i wbudowanego routera oraz wsparcie dla technologii OpenVPN.

https://www.panasonic-electric-works.com/pl/fp-i4c-the-iiot-gateway.htm

Struktura wiadomości

W protokole MQTT istnieje 15 typów komunikatów.

Pierwsze cztery najbardziej znaczące bity stałego nagłówka są używane jako specyficzne flagi:

  • DUP – dupplikat jest ustawiany, gdy klient lub broker MQTT zatwierdza ponowne wysłanie pakietu (używane w PUBLISH, SUBSCRIBE, UNSUBSCRIBE, PUBREL). Jeśli flaga jest ustawiona, nagłówek zmiennej musi zawierać identyfikator wiadomości.
  • QoS – jakość usług (0,1,2).
  • RETAIN – podczas publikowania danych z ustawioną flagą. Broker zapisze ją.

Zmienny nagłówek jest obecny w niektórych typach nagłówków i zawiera następujące dane:

  • Identyfikator pakietu – obecny w większości typów komunikatów.
  • Nazwa protokołu – występuje tylko w typie komunikatu CONNECT.
  • Wersja protokołu – występuje tylko w typie komunikatu CONNECT.
  • Połącz flagi – flagi, które określają zachowanie klienta podczas połączenia.

  • User name –  jeśli flaga jest ustawiona, wtedy nazwa użytkownika musi znajdować się w ładunku.
  • Password – jeśli flaga jest ustawiona, wtedy hasło musi się znajdować w ładunku.
  • Will Retain – jeśli flaga jest ustawiona, wtedy Broker przechowuje komunikat woli.
  • Will QoS –  określa jakość usługi dla wiadomości.
  • Will Flag – jeśli flaga jest wysterowana i klient rozłączy się z serwerem bez wysłania komendy DISCONECT, Broker poinformuje wszystkich połączonych klientów o tym zdarzeniu za pośrednictwem Will Message.
  • Clean Session – jeśli flaga nie jest ustawiona, broker przechowuje sesję oraz wszystkie subskrypcje klienta, a przy kolejnym połączeniu z klientem wysyła wszystkie wiadomości z QoS1 i QoS, które zostały odebrane przez brokera, gdy klient był odłączony. Jeśli flaga jest ustawiona, to przy próbie nawiązania kolejnego połączenia klient musi zasubskrybować wszystkie tematy.
  • Dane, ładunek

Treść oraz format danych przesyłanych za pośrednictwem komunikatów MQTT są określone w urządzeniu. Rozmiar danych można obliczyć, odejmując długość nagłówka zmiennej od pozostałej długości.

Tematy

Kluczowym elementem komunikacji MQTT są tematy. Najłatwiejszym sposobem do zrozumienia nazw tematów jest myślenie o nich jak o ścieżkach w systemie plików. Wyobraźmy sobie, że wszystkie nasze pliki przechowujemy na pulpicie bez żadnych katalogów oraz folderów. Jak możemy się słusznie domyślać, mielibyśmy duży bałagan w plikach i znalezienie konkretnych plików zajmowałoby dużo więcej cennego czasu. Jeśli jednak nasze pliki odpowiednio poukładamy do odpowiednich katalogów i plików tematycznie, to nasza praca stanie znacznie łatwiejsza. Słowo temat  jest kluczem. Załóżmy, że w zakładzie produkcyjnym mamy 1000 czujników i każdy z nich jest odpowiedzialny za coś innego.

Przykład 1:

sensor1 – w tym przykładzie temat nie za wiele zdradza nam o przeznaczeniu takiego czujnika.

Przykład 2:

machine1/sensor/voltage/motor1 – w tym przykładzie temat mówi użytkownikowi znacznie więcej, na podstawie tematu jesteśmy w stanie określić, że jest to maszyna nr 1 i jest to czujnik napięcia silnika nr 1.

Do nadawania nazw tematów, można stosować dowolne znaki UTF-8, z wyjątkiem dwóch znaków + i #. Dobrą praktyką jest stosowanie słownictwa powszechnie stosowanego w języku angielskim. Dodatkowo nasze tematy powinny zaczynać się od „$”, a konkretnie od „$SYS” i jest to ściśle związane z funkcjonowaniem serwerów.

Analizując operację subskrypcji, dowiemy się, że klient może subskrybować zarówno jeden jak i więcej filtrów tematu. Jeśli jako filtr podamy nazwę tematu, będziemy mogli subskrybować tylko jeden temat. Korzystając ze znaków + oraz # może utworzyć filtry wątków tematów, które subskrybują wszystkie tematy pasujące do podanego filtra.

  • „+” – jednopoziomowy symbol wieloznaczny, który pasuje do dowolnej nazwy dla danego poziomu tematycznego. Wykorzystywany zamiast określenia nazwy dla dowolnego poziomu tematu w filtrze.
  • „#” – wielopoziomowy symbol wieloznaczny, stosowany jedynie na końcu filtra, jako ostatni poziom. Pasuje do każdego tematu, którego pierwsze poziomy są takie same jak poziomy tematu określone po lewej stronie symbolu #.

Przykład „+”:

gaugage/+/voltage pasuje do:

gaugage/motor1/voltage,gaugage/motor2/voltage, itd.

Przykład „#”:

gaugage/motor1/# pasuje do:

gaugage/motor1/voltage,gaugage/motor/current, itd.

Poziomy jakości usług QoS

Wiedząc jak działa subskrypcja oraz publikacja, w połączeniu z nazwami tematów, filtrami tematów oraz im towarzyszącymi symbolami wieloznacznymi, przejdziemy trochę dalej i dowiemy się czym są poziomy QoS (z ang. „Quality of Service”). W zależności od ustawienia poziomu QoS, decydujemy czy wysłana wiadomość musi zostać odebrana przez subskrybenta.

Specyfikacja protokołu MQTT definiuje 3 poziomy poziomy jakości usług.

  • Poziom 0 – wysłana wiadomość nie potrzebuje żadnego potwierdzenia dostarczenia, po jej wysłaniu zapominamy o tym,

  • Poziom 1 – wysłana wiadomość musi zostać dostarczona przynajmniej jeden raz, w tym przypadku musimy uzyskać potwierdzenie, ten poziom pozwala na dostarczenie wiadomości do wielu odbiorców.

  • Poziom 2 – wysłana wiadomość musi zostać dostarczona dokładnie do jednego odbiorcy, tutaj również jest wymagane potwierdzenie.

Co jeśli wiadomość nie zostanie odebrana?

Jeśli wiadomość nie zostanie odebrana, to zostanie podjęta próba ponownego nadania wiadomości. Cykl ponownego przesłania wiadomości zależy od konfiguracji naszego serwera pośredniczącego.

MQTT przez WebSockets

MQTT przez WebSockets umożliwia przeglądarce wykorzystanie wszystkich funkcji, które oferuje MQTT.

Takie rozwiązanie pozwala na:

  • wyświetlanie informacji na żywo z urządzeń czy czujników,
  • otrzymywanie powiadomień (alerty o stanach krytycznych),
  • sprawdzenie aktualnego stanu rządzeń i zachowanie wiadomości,
  • wydajną komunikację dzięki mobilnym aplikacjom internetowym.

WebSocket to protokół sieciowy, który zapewnia dwukierunkową komunikację między przeglądarką, a serwerem WWW. Protokół został ustandaryzowany w 2011 roku, a wszystkie nowoczesne przeglądarki zapewniają jego wbudowaną obsługę. Protokół WebSocket, podobnie do MQTT jest oparty o TCP. Wykorzystanie WebSocket’u jest dobrą metodą przesyłu dla MQTT, ponieważ zapewnia dwukierunkową, uporządkowaną i bezstratną komunikację. Nie zaleca się używania serwera WWW do łączenia WebSocket’u z brokerem.


Na dzień dzisiejszy nie jesteśmy w stanie jeszcze mówić o czystym protokole MQTT w przeglądarce, ponieważ nie jest możliwe otwarcie surowego połączenia TCP. Rozwiązaniem problemu może być implementacja Socket’u API w przeglądarkę.

Bezpieczeństwo

Do omówienia tego tematu podzielmy bezpieczeństwo na trzy poziomy.

Poziom sieci

Jednym ze sposobów zapewnienia bezpiecznego połączenie jest zastosowanie fizycznie bezpiecznej sieci lub połączenia VPN do wszelkiej komunikacji między klientami a brokerami.

Poziom transportu

Jeśli naszym głównym celem jest poufność, do szyfrowania transportu stosuje się protokół TLS/SSL. Metoda ta skutecznie chroni dane przed odczytem w czasie transmisji i zapewnia uwierzytelnienie certyfikatu klienta w celu weryfikacji tożsamości obu stron.

Poziom aplikacji

Protokół MQTT zapewnia identyfikator klienta i poświadczenia w postaci login’u czy hasła do uwierzytelnienia na poziomie aplikacji. Autoryzacja lub kontrola, co może zrobić każde urządzenie, jest zdefiniowane przez konkretną implementację brokera.

MQTT opiera się na protokole transportowym TCP. Domyślnie, połączenie TCP nie używa szyfrowanej transmisji, stąd, aby zagwarantować bezpieczeństwo w wielu brokerach MQTT używa się TLS zamiast zwykłego TCP. Ma to szczególne znaczenie, jeśli w mechanizmie uwierzytelniania i autoryzacji stosuje się klasyczne logowanie za pomocą loginu i hasła.

Transport Layer Security (TLS) jest protokołem kryptograficzny, który umożliwia bezpieczną i zaszyfrowaną komunikację w warstwie transportowej pomiędzy aplikacją kliencką, a serwerem. Równocześnie protokół TLS zapewnia poufność danych. Komunikujące się urządzenia wykorzystują certyfikaty do wzajemnej weryfikacji autentyczności. Pozwala to uniknąć ataków typu „man-in-the-middle”. Nadawca może mieć pewność, że odbiorca otrzyma dokładnie takie same dane jak nadawca wysłany (i na odwrót).

Możliwe są trzy scenariusze uwierzytelniania TLS:

  • TLS po stronie serwera, gdzie broker MQTT przedstawia certyfikat klientom,
  • TLS po stronie klienta, gdzie klient przedstawia certyfikat brokerowi,
  • Mutual TLS, gdzie zarówno klient jak i broker przedstawiają certyfikaty.

Zalecane jest stosowanie tego trzeciego scenariusza.

Certyfikaty TLS są zazwyczaj wydawane przez tzw. Urząd Certyfikacyjny (CA), który działa jako zaufana strona trzecia. Nieodłączną cechą wydanego w ten sposób certyfikatu jest jego wiarygodność, która zapewnia autentyczność każdemu, kto przedstawi certyfikat. Bardzo często by obniżyć koszty stosuje się tzw. samo podpisane certyfikaty wydane przez własne CA.

Jednak niezależnie od wydawcy certyfikatu zawsze należy stosować TLS z MQTT, jeśli tylko pozwala nam na to przepustowość, a klienci mają wystarczającą moc obliczeniową i pamięć dla TLS.

Oprócz TLS dobrą praktyką jest stosowanie innych, równoległych zabezpieczeń jak mechanizm uwierzytelnienia, szyfrowanie wątków czy autoryzacja dostępu do wątków. Ogólnie rzecz biorąc, więcej bezpieczeństwa nigdy nie boli.

Daniel Leszczewicz, Panasonic

Nowości w MQTT 5

W 2013 roku po raz pierwszy opublikowano oficjalnie protokół MQTT w wersji 3.1.1. Pod koniec 2015 roku rozpoczęto pracę nad dużą aktualizacją tego standardu, głównym jej celem miało być rozwiązanie złożoności współczesnego środowiska komputerowego. Nowe funkcje były szczególnie istotne dla aplikacji wdrażanych w chmurach, wymagających dużej niezawodności i niezawodnej obsługi błędów, w celu wdrożenia komunikatów o znaczeniu krytycznym. Nowy standard miał być łatwiejszy w integracji komunikatów MQTT z ich istniejącą infrastrukturą obliczeniową. Wprowadzenie nowego standardu pozwoliło na określenie limitu czasu wygasania sesji i wiadomości. Zapewnia to, że wiadomość jest dostarczania tylko w czasie, w którym uruchomione urządzenie jest bezpieczne i nigdy nie zostanie dostarczone z opóźnieniem wynikającym z awarii sieci. Jest to szczególnie istotna funkcja w przypadku maszyn o krytycznym znaczeniu dla bezpieczeństwa w hali produkcyjnej. Dodatkowo wersja 5 wprowadza koncepcję negatywnych podziękowań. Nasz broker w oparciu o wcześniej zdefiniowane ograniczenia może wysyłać potwierdzenie odrzucenia określonych wiadomości. Ograniczenia mogą opierać się o maksymalny rozmiar wiadomości, maksymalną jakość usług, czy nieobsługiwane funkcje. Oprócz tego nowa wersja wprowadza koncepcję współdzielonych subskrypcji, która jest szczególnie przydatna przy wdrożeniach do baz danych. Z punktu widzenia użytkownika, interesujące może być wprowadzenie aliasów tematów, które pozwalają na zwiększenie wydajności poprzez zastąpienie ciągów tematów liczbą całkowitą.

Podsumowanie

W artykule starałem się przedstawić najważniejsze elementy protokołu MQTT oraz przekonać Ciebie czytelniku do podjęcia próby zaimplementowania go w swoim zakładzie. Z roku na rok pojawia się na rynku coraz większa ilość urządzeń wspierających ten protokół. Możliwość kontroli maszyn i urządzeń z dowolnej lokalizacji, a przy tym stały monitoring zapewnia ich maksymalną sprawność i redukuje skutecznie czas przestoju. Dzięki szyfrowaniu danych poprzez SSL/TLC bezpośrednio w systemie sterowania oraz możliwość wykorzystania bezpiecznego tunelowania VPN zwiększają znacząco poziom bezpieczeństwa naszych danych. Protokół MQTT jest protokołem zdobywającym popularność w obszarach przemysłowych, np. w przemyśle motoryzacyjnym czy wydobywczym. Jak już wspomniałem, protokołu MQTT możemy używać z wykorzystaniem przeglądarki internetowej. Instalując rozszerzenie MQTT Lens do przeglądarki Google Chrome możemy w zaciszu swojego domu przetestować takie połączenie. Zachęcam do zapoznania się z filmikiem przedstawiającym przykładową wymianę danych:


Ocena artykułu zgłoszonego do Konkursu iAutomatyka 4.0 pisz artykuły, zdobywaj punkty, wymieniaj je na nagrody.

Kryterium 1 2 3 4 5 6 7 8 9 10
Punkty (0-2) 2 2 2 2 2 0 1 2 1 2
Suma zdobytych punktów: 16


Utworzono: / Kategoria: , , ,

Reklama

Newsletter

Zapisz się i jako pierwszy otrzymuj nowości!



PRZECZYTAJ RÓWNIEŻ



NAJNOWSZE PUBLIKACJE OD UŻYTKOWNIKÓW I FIRM

Reklama



POLECANE FIRMY I PRODUKTY
  • Bezpieczny, prosty w obsłudze i energooszczędny Seria serwowzmacniaczy Mitsubishi Electric MELSERVO MR-J4 wraz z kompatybilnymi modułami pozycjonującymi oraz zaawansowanymi kontrolerami motion, umożliwia konstruktorom maszyn i urządzeń oraz...
  • 1,200 PLN
    Szkolenie jest wprowadzeniem do systemu sterowania PSS4000 i środowiska programowania PAS4000. W jego trakcie omówiona zostanie zarówno struktura sprzętowa, jak i programowanie, a także diagnostyka kompletnego systemu sterowania. Poruszane ...
    Czas trwania: 8h
    Link: Terminy
  • #PILZ wraca na rynek komponentów dla aplikacji zdecentralizowanych z nową wyspą z grupy #PDP67 powiększając tym samym istniejące portfolio o nowe rozwiązanie.Moduł PDP67 jak każda wyspa I/O to urządzenie ułatwiające koncentrację sygnałów w ...
  • Seria FX-100 Czujniki z serii FX-100 to najlepsze rozwiązanie pod względem stosunku jakości do ceny. Wyposażone są w funkcje szybkiego uczenia, co pozwala użytkownikom w szybki i prosty sposób przystosować czujnik do pracy z nieskomplikowan...
  • Rozwiązania wizyjne nadają się idealnie do zautomatyzowanych zadań kontrolnych i pomiarowych. Kamery wizyjne 2D i 3D firmy SICK sprawdzają się w ogromnej ilości aplikacji, polegających na pomiarze, lokalizacji, kontroli i identyfikacji. Nas...
  • Inteligentny chwytak równoległy SCHUNK EGI z certyfikowanym interfejsem PROFINET-IRT został zaprojektowany z myślą o rozmaitych wymagających zastosowaniach z zakresu przenoszenia w branży elektronicznej, farmaceutycznej i laboratoryjnej. Te...