MQTT vs Sparkplug B: Porównanie Protokółów Komunikacyjnych cz I

Wprowadzenie

W świecie przemysłowego Internetu Rzeczy (IIoT), wybór odpowiedniego protokołu komunikacyjnego jest kluczowy.

Dwa popularne protokoły to MQTT i Sparkplug B. Oba mają swoje unikalne cechy i zastosowania. W tym artykule omówimy te protokoły, ich powstanie, działanie, jakość usług, retencyjność wiadomości oraz różnice między nimi, jak również na końcu przedstawię zastosowanie SparkPlug B w systemie Omnimes firmy Multiprojekt.

Powstanie MQTT

Protokół MQTT został wynaleziony w 1999 roku przez Andy'ego Stanforda-Clarka z IBM i Arlena Nippera z Arcom (obecnie Cirrus Link). Jego główne założenia to:

Prosta implementacja
Dostarczanie danych dotyczących jakości usług (QOS)
Lekkość i efektywność pod względem przepustowości
Niezależność danych
Ciągłość sesji (retencyjność)

Działanie MQTT

MQTT działa w trybie nasłuchiwania, gdzie klient subskrybuje określone topiki i odbiera wiadomości. Przykładowy topik może wyglądać tak: switch/light/, a ładunek to dokument JSON:

{status: "ON", color:"red", date:"2023-01-08", time:"10:23"}

Schemat ilustrujący centralny czerwony blok oznaczony jako „Broker” ze strzałkami łączącymi się z pięcioma szarymi blokami zatytułowanymi „Urzadzenie 1”, „Urzadzenie 2”, „Urzadzenie 3”, „Urzadzenie 4” i „Urzadzenie 5”. Strzałki wskazujące „Subskrypcję” i „Publikację” ilustrują komunikację MQTT

Jakość usług (QoS) w MQTT

MQTT oferuje trzy poziomy QoS:

QoS 0: "zwykły list" - wiadomość dostarczana raz, bez potwierdzenia.
QoS 1: "list polecony" - wiadomość dostarczana przynajmniej raz, z potwierdzeniem odbioru.
QoS 2: "list polecony z informacją zwrotną" - wiadomość dostarczana dokładnie raz, z potwierdzeniem odbioru i informacją zwrotną dla nadawcy.

Retencyjność wiadomości w MQTT

Retencyjność wiadomości pozwala na zapisanie ostatniego stanu wiadomości, co jest przydatne np. w przypadku powiadomień o stanie urządzeń. Dzięki temu, nowy użytkownik może dowiedzieć się o ostatnim stanie maszyny.

Powstanie Sparkplug B

Sparkplug B to protokół oparty na MQTT, rozwijany przez Arlena Nippera (założyciela Cirrus Link). Został stworzony jako odpowiedź na potrzeby przemysłu, oferując bardziej ustandaryzowany i mniej złożony protokół niż OPC UA.

Różnice między MQTT a Sparkplug B

Schemat kanału i ładunku:

Sparkplug B: Ustandaryzowany schemat topików i ładunków. Przykładowy topik: spBv1.0/switch/light/#. Przykładowy ładunek:

{
  "timestamp": 1673262477011,
  "metrics": [
    {
      "name": "status",
      "timestamp": 1673262477011,
      "dataType": "Int16",
      "value": "ON"
    },
    {
      "name": "color",
      "timestamp": 1673262477011,
      "dataType": "Int16",
      "value": "red"
    }
  ],
  "seq": 9
}

MQTT: Dowolność w tworzeniu topików i ładunków. Przykładowy topik: switch/light/. Przykładowy ładunek:
```
{
  "status": "ON",
  "color": "red",
  "date": "2023-01-08",
  "time": "10:23"
}
```

Retencyjność wiadomości:
- Sparkplug B: Brak natywnej retencyjności wiadomości. Konieczne jest stworzenie magazynu danych, który będzie przechowywał ostatnie stany/informacje z danego urządzenia.
- MQTT: Wbudowana funkcjonalność retencyjności.

Zastosowanie Sparkplug B w systemie Omnimes firmy Multiprojekt

Implementacja Sparkplug B w systemie Omnimes przyniosła kilka korzyści:

Stworzenie kreatora konfiguracji
Ułatwienie konfigurowania połączeń
Brak narzucania struktury danych użytkownikowi
Przerzucenie odpowiedzialności za konfigurację na użytkownika

Na ekranie komputera wyświetlany jest dashboard z polskim tekstem, tabelami i wykresami. Dwie zielone strzałki wskazują fragment kodu JSON u góry do elementów w dolnej części, ilustrując połączenie między danymi wejściowymi a elementami sterującymi pulpitu nawigacyjnego w systemie Omnimes.

Podsumowanie

Wybór między MQTT a Sparkplug B zależy od specyficznych potrzeb i wymagań aplikacji.

MQTT jest bardziej elastyczny i posiada natywną retencyjność wiadomości, podczas gdy Sparkplug B oferuje ustandaryzowane struktury i jest bardziej zoptymalizowany dla zastosowań przemysłowych.

Oba protokoły mają swoje miejsce w ekosystemie IIoT i warto dokładnie przeanalizować, który z nich najlepiej spełni wymagania Twojego projektu.

← Powrót do bloga