W przemysłowych systemach sterowania opóźnienie liczone w setkach milisekund bywa różnicą między poprawną pracą linii a kosztownym przestojem. Tam, gdzie klasyczne rozwiązania publish-subscribe przestają wystarczać, do gry wchodzi protokół DDS (Data Distribution Service) — standard Object Management Group opisujący wymianę danych w rozproszonych systemach czasu rzeczywistego. Znajdziemy go w robotyce, energetyce, systemach pokładowych i coraz częściej w zaawansowanych wdrożeniach IIoT.
W skrócie: protokół DDS to bezbrokerowy, data-centric standard komunikacji czasu rzeczywistego, w którym węzły odnajdują się automatycznie, a jakość transmisji opisuje ponad 20 negocjowanych polityk QoS. Sprawdza się tam, gdzie liczą się deterministyczne opóźnienia poniżej milisekundy i duże strumienie telemetrii.
Czym jest protokół DDS?
Protokół DDS to specyfikacja middleware komunikacyjnego, zdefiniowana przez OMG w 2004 roku i rozwijana do dziś (aktualna linia DDS 1.4 wraz z rodziną standardów DDS-RTPS, DDS-Security i DDS-XRCE). W odróżnieniu od rozwiązań opartych na kolejkach, DDS nie przesyła „wiadomości do tematu”, lecz utrzymuje wspólną, rozproszoną przestrzeń danych — tzw. global data space.
Aplikacja deklaruje, że publikuje lub subskrybuje określony Topic o zdefiniowanym typie danych (opisanym w IDL). Middleware sam znajduje pasujących partnerów, sprawdza zgodność typów i polityk, po czym zestawia bezpośrednie połączenie. Nie ma centralnego brokera, który mógłby stać się pojedynczym punktem awarii.
Jak działa DDS: RTPS, DomainParticipant i model data-centric
Warstwą transportową standardu jest RTPS (Real-Time Publish-Subscribe Protocol), pracujący domyślnie nad UDP — najczęściej z multicastem w fazie odkrywania węzłów. To właśnie RTPS zapewnia interoperacyjność implementacji różnych dostawców, takich jak Fast DDS, Cyclone DDS czy RTI Connext.
Podstawowe pojęcia, które trzeba znać przy projektowaniu:
- Domain — logiczna izolacja ruchu, identyfikowana liczbą 0–232; węzły w różnych domenach nigdy się nie widzą.
- DomainParticipant — instancja middleware w procesie aplikacji.
- Topic — nazwana struktura danych o ściśle określonym typie.
- DataWriter / DataReader — punkty zapisu i odczytu, negocjujące ze sobą polityki QoS.
- Instance i klucz — DDS rozróżnia rekordy po polach kluczowych, dzięki czemu jeden Topic obsługuje tysiące osobnych czujników.
Odkrywanie węzłów odbywa się dwustopniowo: najpierw uczestnicy ogłaszają swoje istnienie (SPDP), następnie wymieniają szczegóły punktów końcowych (SEDP). W dużych instalacjach ruch odkrywania rośnie kwadratowo, dlatego przy setkach węzłów stosuje się Discovery Server zamiast czystego multicastu.
Polityki QoS — serce protokołu DDS
Polityka QoS w DDS to kontrakt między nadawcą a odbiorcą: jeśli wymagania odbiorcy są ostrzejsze niż oferta nadawcy, połączenie po prostu nie powstanie. Ten mechanizm request-offered eliminuje klasę błędów, które w innych protokołach ujawniają się dopiero na produkcji.
- Reliability — BEST_EFFORT dla strumieni o wysokiej częstotliwości, RELIABLE z retransmisją dla poleceń krytycznych.
- Durability — VOLATILE, TRANSIENT_LOCAL lub PERSISTENT; ta ostatnia pozwala odbiorcy dołączyć później i otrzymać ostatnią znaną wartość.
- Deadline — deklarowany maksymalny odstęp między próbkami; jego przekroczenie generuje zdarzenie diagnostyczne.
- Liveliness — wykrywanie utraty węzła w czasie liczonym w milisekundach, odpowiednik Last Will znanego z MQTT.
- History i Resource Limits — ile próbek middleware buforuje i ile pamięci może na to przeznaczyć.
- Ownership i Transport Priority — obsługa redundantnych źródeł danych oraz priorytetyzacja ruchu.
W połączeniu z siecią deterministyczną, opisaną w naszym artykule o Time-Sensitive Networking w przemysłowym IoT, DDS pozwala budować systemy o gwarantowanym czasie reakcji, a nie tylko o „zwykle niskim” opóźnieniu.
DDS-XRCE i Micro-ROS: DDS na mikrokontrolerach
DDS-XRCE to profil standardu przeznaczony dla urządzeń o ekstremalnie ograniczonych zasobach. Klient zajmuje rząd 50–80 kB Flash i pojedyncze kilobajty RAM, komunikuje się binarnym protokołem z agentem XRCE i to agent reprezentuje go w pełnej sieci DDS.
Dzięki temu czujnik na STM32L4 czy sterownik na ESP32 może uczestniczyć w tej samej przestrzeni danych co komputer przemysłowy. To model wykorzystywany przez Micro-ROS w ROS 2 — i praktyczna ścieżka wdrożenia dla zespołów, które budują rozwiązania przemysłowego IoT na własnym hardware.
Kiedy stosować DDS, a kiedy MQTT lub OPC UA?
Wybór protokołu wynika z topologii i wymagań czasowych, nie z mody. Przy transmisji telemetrii przez sieć rozległą do chmury trudno pokonać prostotę i odporność protokołu MQTT, który świetnie znosi wysokie RTT i przerwy w łączności.
DDS wygrywa w obrębie zakładu, pojazdu lub maszyny: gdy dziesiątki węzłów wymieniają dane z częstotliwością setek herców, a opóźnienie musi być przewidywalne. Z kolei OPC UA daje najbogatszy model informacyjny maszyny i najlepszą interoperacyjność z istniejącym parkiem sterowników. W praktyce architektury hybrydowe są normą: DDS w warstwie sterowania, MQTT jako most do chmury, OPC UA na styku z automatyką.
Bezpieczeństwo i wdrożenie produkcyjne
DDS-Security definiuje pięć wtyczek: uwierzytelnianie, kontrolę dostępu, kryptografię, logowanie i znakowanie danych. Uwierzytelnianie opiera się na certyfikatach — warto zestawić je z naszym opracowaniem o certyfikatach X.509 w IoT, bo bez działającego PKI i rotacji kluczy żadna z tych wtyczek nie da realnej ochrony.
Na etapie wdrożenia największe ryzyka to nadmiarowy ruch odkrywania, brak limitów zasobów w politykach History oraz multicast blokowany przez infrastrukturę sieciową. Warto od początku instrumentować system metrykami i łączyć je z warstwą analityczną — na przykład w scenariuszach predykcyjnego utrzymania ruchu, gdzie strumienie z czujników drgań trafiają jednocześnie do sterowania i do modeli uczenia maszynowego.
Najczęściej zadawane pytania (FAQ)
Czym różni się protokół DDS od MQTT?
MQTT jest zorientowany na wiadomości i wymaga centralnego brokera, przez który przechodzi cały ruch. Protokół DDS jest data-centric i działa peer-to-peer: węzły odnajdują się automatycznie i wymieniają dane bezpośrednio. DDS oferuje ponad 20 polityk QoS oraz deterministyczne opóźnienia rzędu mikrosekund, MQTT — prostotę i doskonałą pracę przez sieci WAN o wysokim RTT.
Czy DDS działa na mikrokontrolerach?
Tak, poprzez profil DDS-XRCE (eXtremely Resource Constrained Environments). Klient XRCE zajmuje ok. 50–80 kB pamięci Flash i kilka kB RAM, więc mieści się na STM32 czy ESP32. Urządzenie łączy się z agentem XRCE, który tłumaczy jego komunikaty na pełny ruch DDS w sieci. To fundament Micro-ROS w robotyce.
Kiedy wybrać DDS zamiast OPC UA?
DDS wybieramy, gdy kluczowe są niskie i przewidywalne opóźnienia oraz duża częstotliwość próbkowania — sterowanie ruchem, robotyka, autonomiczne pojazdy, systemy pokładowe. OPC UA lepiej sprawdza się tam, gdzie liczy się bogaty model informacyjny maszyny i interoperacyjność z parkiem sterowników PLC. Oba standardy można łączyć przez bramkę.
Podsumowanie — najważniejsze wnioski
Protokół DDS to standard dla systemów, w których dane muszą docierać szybko, przewidywalnie i bez centralnego pośrednika. Jego siła leży w modelu data-centric, automatycznym odkrywaniu węzłów oraz kontrakcie QoS wymuszanym przez middleware. Profil DDS-XRCE otwiera ten świat także dla mikrokontrolerów, a DDS-Security domyka temat uwierzytelniania i szyfrowania.
Projektujesz system, w którym liczy się czas reakcji? Zespół FSS Technology projektuje hardware, pisze firmware i buduje warstwę chmurową dla wdrożeń IIoT — od schematu PCB po integrację z systemami nadrzędnymi. Sprawdź, jak wspieramy klientów w obszarze urządzeń połączonych, i porozmawiajmy o architekturze komunikacji dla Twojego produktu.