Architektura IoT: warstwy, diagram i budowa systemów przemysłowych

Najczęściej spotkasz dwa modele: trzywarstwowy i pięciowarstwowy. Model trzywarstwowy ma warstwę percepcji (fizyczne urządzenia i czujniki), warstwę sieci (łączność) i warstwę aplikacji (usługę dla użytkownika). Model pięciowarstwowy dzieli warstwę sieci na transport i przetwarzanie, a na górze dokłada warstwę biznesu, która zarządza całym systemem, jego modelem biznesowym i tym, jak system zarabia.

Przegląd „Internet of Things Architectures: A Comparative Study” (dos Santos i in., 2020, arXiv 2004.12936) opisuje oba modele i zauważa, że źródła różnie nazywają warstwy środkowe. Stąd tak różne liczby w wynikach wyszukiwania: od czterech do sześciu warstw. Ten sam przegląd wskazuje, że model pięciowarstwowy pomija bezpieczeństwo i prywatność. Podstawowe pojęcia wyjaśnia hasło IoT w słowniku i nasz tekst o tym, czym jest przemysłowy IoT.

Kiedy budujesz system, bardziej przydaje się wiedza, co robi każda warstwa i jak zawodzi. Tabela poniżej opisuje warstwy, które faktycznie się wdraża.

W warstwie aplikacji pojawiają się analityka przemysłowego IoT i projektowanie dashboardów.

Co zmieniają dodatkowe warstwy modelu 5-warstwowego

W modelu trzywarstwowym „sieć” obejmuje zarówno przesyłanie danych, jak i ich interpretację. Model pięciowarstwowy oddziela transport (dostarczenie wiadomości z urządzenia do platformy) od przetwarzania (przechowywania, filtrowania i analizy). W prawdziwym systemie to często osobne usługi z różnymi właścicielami. Warstwa biznesu dokłada pytania o zarządzanie systemem i zysk, których model trzywarstwowy nie stawia.

Referencyjny diagram architektury IoT dla systemu przemysłowego ma dwie ścieżki. Telemetria idzie z urządzenia w górę, a komendy wracają w dół.

Ścieżka telemetrii, od urządzenia do aplikacji:

1. Urządzenie lub czujnik. Odczytuje wartości z instalacji, takiej jak falownik, bateria czy licznik, często przez magistralę polową, jak RS485 z Modbusem.
2. Bramka edge. Zbiera odczyty lokalnie, wykonuje logikę, która nie może czekać na chmurę, i buforuje wiadomości, gdy nie ma łącza.
3. Broker i przyjmowanie danych. Broker MQTT albo usługa zarządzana, taka jak AWS IoT Core czy Azure IoT Hub, odbiera wiadomości przez bezpieczne połączenie.
4. Przetwarzanie i przechowywanie. Reguły, przetwarzanie strumieniowe i baza szeregów czasowych zamieniają surowe odczyty w stan i historię.
5. Aplikacja. Dashboardy, alerty, raporty i integracje, z których korzystają operatorzy i biznes.

Ścieżka komend, od aplikacji do urządzenia: nastawa albo harmonogram wychodzi z aplikacji, przechodzi przez platformę i broker, dociera do bramki edge i zostaje zapisana w urządzeniu. Większość ogólnych diagramów tę ścieżkę pomija, a to ona ma najostrzejsze wymagania, bo komenda, która dotrze za późno albo dwa razy, może zmienić pracę urządzeń.

Prawdziwy łańcuch: Zeronest

W systemie Zeronest urządzenie podłączone do falownika przez RS485/Modbus wysyłało odczyty przez LTE, protokołem MQTT z TLS 1.2, do AWS IoT Core. Urządzenie, Bzyk D200, to własny sprzęt Zeronest, a łącze LTE uniezależniało ścieżkę danych od chmury producenta falownika i od domowego Wi-Fi. Dane klientów zostawały w UE. Co minutę system decydował, czy ładować, rozładowywać, czy sprzedawać energię. Obsługiwał 16 marek falowników i obejmował ponad 3000 prosumenckich instalacji magazynowych (stan na kwiecień 2026). Platformę zbudowaną na tym łańcuchu opisuje case study Zeronest.

Logikę, która musi działać bez internetu, uruchamiaj na edge, a do chmury wysyłaj wszystko, co zyskuje na danych z całej floty. Decyzje sterujące fizycznymi urządzeniami zwykle należą do edge. Analityka, raportowanie i porównania wielu lokalizacji należą do chmury.

System zarządzania energią (EMS), który zbudowaliśmy dla platformy solarno-bateryjnej Skyfri, wszedł na produkcję w czerwcu 2024 roku, obejmował 7 obiektów i sterował magazynami energii o pojemności ponad 5 MWh. EMS podejmował decyzje sterujące lokalnie na Azure IoT Edge, więc mógł działać w pełni offline, a stroną chmurową był Azure IoT Hub. Współpracował z bateriami i falownikami kilku producentów. Monitoring działa jako osobna warstwa we własnym produkcie Skyfri, Skyfri Intelligence.

Co naprawdę oznacza offline na Azure IoT Edge

Szczegóły opisuje dokumentacja Microsoftu, „Operate Azure IoT Edge devices offline” w serwisie Microsoft Learn:

• Po pierwszej synchronizacji z IoT Hub urządzenie edge może działać bez połączenia dowolnie długo.
• Edge hub buforuje wychodzące wiadomości, a po powrocie połączenia wysyła je w pierwotnej kolejności.
• To, jak długo wiadomości przetrwają, zależy od ustawienia czasu życia (TTL) i wolnego miejsca na dysku. Domyślny TTL to 7200 sekund, czyli dwie godziny.
• W trybie offline agent nie raportuje stanu, więc portal może dalej pokazywać urządzenie jako sprawne (200 OK).

Jeśli awaria może trwać dłużej niż TTL bufora, podnieś go i dobierz rozmiar dysku albo pogódź się z utratą starszych odczytów. I nie traktuj zielonego statusu jako dowodu, że urządzenie jest online.

Modbus łączy urządzenia z bramką, OPC UA przenosi na hali produkcyjnej dane razem z modelem informacyjnym, MQTT przesyła wiadomości z bramki do chmury, a HTTP obsługuje odpytywanie i integracje REST. Każdy pasuje do innej granicy między warstwami.

Dane o OPC UA pochodzą z badania interoperacyjności VDMA 2025 wśród niemieckich producentów maszyn i instalacji. Opisał je fertigungstechnik.de 28 listopada 2025. Poziomy jakości usługi MQTT definiuje specyfikacja OASIS.

MQTT czy OPC UA?

Często używa się obu. W artykule OPC Foundation „OPC UA, MQTT and Information Interoperability” Erich Barnstedt, Chief Architect Standards & Consortia for Azure IoT w Microsofcie, opisuje OPC UA jako ładunek, a MQTT jako transport. OPC UA nadaje danym znaczenie, a MQTT sprawnie przenosi je do chmury.

Sprawdź też limity platformy. Według AWS IoT Core Developer Guide usługa obsługuje QoS 0 i 1, ale nie QoS 2. Sesja trwała przechowuje subskrypcje i niepotwierdzone wiadomości QoS 1. Domyślnie wygasa po godzinie. W MQTT 3 to ustawienie obowiązuje dla całego konta, a w MQTT 5 limit można podnieść do siedmiu dni. Jeśli projekt zależy od dostarczenia dokładnie raz, musi to zapewnić logika aplikacji, choćby przez idempotentne komendy.

Wiele awarii produkcyjnych zdarza się na styku warstw, często wtedy, gdy zrywa się połączenie. Jeden wzorzec z branży, opisywany przez HiveMQ w „MQTT Essentials part 7”, przez ThingsBoard w „Non-persistent and persistent sessions” i w dokumentacji AWS IoT, pokazuje, jak taka awaria przechodzi niezauważona:

• Klient MQTT, który łączy się z czystą sesją, po zerwaniu połączenia traci subskrypcje i po ponownym połączeniu musi subskrybować od nowa.
• Przy sesji trwałej (clean session ustawione na false) broker zachowuje subskrypcje i kolejkuje wiadomości dla tego samego identyfikatora klienta.
• W MQTT 5 flagę clean session zastępują Clean Start i Session Expiry Interval. Domyślny interwał wygaśnięcia to 0, więc sesja kończy się, gdy klient się rozłączy.
• Klient powinien trzymać własną listę subskrypcji i przywracać ją po ponownym połączeniu, niezależnie od tego, co robi broker.

Klient, który połączy się ponownie bez odnowienia subskrypcji, wygląda na połączonego i nic nie dostaje. Dodaj do tego status edge, który w trybie offline zostaje zielony, a urządzenie może zamilknąć tak, że nikt tego nie zauważy.

Checklista: zanim zatwierdzisz architekturę IoT

1. Co działa bez internetu? Wypisz funkcje, które muszą działać offline, i potwierdź, że działają na edge.
2. Ile zmieści bufor? Porównaj TTL wiadomości i wolne miejsce na dysku z najdłuższą spodziewaną awarią.
3. Czy klient MQTT wznawia połączenie i subskrypcje? Użyj sesji trwałej albo trzymaj własną listę subskrypcji i ją przywracaj.
4. Czy status urządzenia mówi prawdę w trybie offline? Upewnij się, że urządzenie, które przestało raportować, nie wygląda dalej na sprawne.
5. Kto odpowiada za mapy rejestrów Modbus i za urządzenia? Ustal, kto utrzymuje mapy dla każdego producenta i modelu.
6. Jak aktualizujesz urządzenia? Planuj aktualizacje etapami zamiast całej floty naraz.
7. Gdzie leżą dane? Potwierdź regiony, w tym to, że dane klientów zostają w UE.
8. Co zależy od chmury producenta? Wskaż każdą funkcję, która przestanie działać, gdy padnie chmura dostawcy albo domowe Wi-Fi.

O bezpieczeństwie przy tych decyzjach piszemy w poradniku o bezpieczeństwie IoT.

Architekturę IoT wybierasz, ustalając najpierw ograniczenia: urządzenia i protokoły na miejscu, zachowanie offline, czasy reakcji, aktualizacje i granice bezpieczeństwa. Odpowiedz na te pytania, zanim ktokolwiek narysuje diagram:

• Jakie urządzenia i protokoły już są na miejscu, a jakie dojdą?
• Co musi działać podczas awarii i jak długo?
• Które decyzje wymagają reakcji w sekundach, a które mogą poczekać na chmurę?
• Jak będziesz aktualizować i wymieniać urządzenia przez cały okres życia systemu?
• Gdzie przebiegają granice bezpieczeństwa między siecią urządzeń, platformą i użytkownikami?

KYOTO pokazuje, jak architektura rośnie. MVP zaczęło się od prac UX/UI i przez trzy i pół roku pracy nad przemysłowym IoT i cyfrowym bliźniakiem magazynu energii cieplnej wyrosło na system zarządzania budynkiem (BMS) oparty na SCADA, który w czasie rzeczywistym monitoruje przepływ energii i nim steruje. Więcej projektów znajdziesz w przykładach przemysłowego IoT.

Zajmujemy się architekturą oprogramowania takich systemów. Nie piszemy firmware'u mikrokontrolerów (C/C++), embedded Linuksa ani Bluetooth Low Energy (BLE), a projekt PCB przekazujemy partnerowi sprzętowemu.

Żeby rozpisać to wszystko, zanim cokolwiek powstanie, prowadzimy bezpłatne warsztaty discovery, które obejmują sprzęt, protokoły, zachowanie offline, aktualizacje i granice bezpieczeństwa.

Jakie są warstwy architektury IoT?

Model trzywarstwowy ma percepcję (urządzenia i czujniki), sieć (łączność) i aplikację (usługę dla użytkownika). Model pięciowarstwowy dzieli sieć na transport i przetwarzanie oraz dodaje warstwę biznesu. We wdrożonym systemie warstwy to urządzenia, łączność, bramka edge, platforma chmurowa i aplikacja.

Czym różni się architektura IoT 3-warstwowa od 5-warstwowej?

Model pięciowarstwowy dzieli warstwę sieci z modelu trzywarstwowego na transport, który przenosi wiadomości, i przetwarzanie, które je przechowuje i analizuje. Dodaje też warstwę biznesu, która zarządza systemem, jego modelem biznesowym i tym, jak system zarabia. Źródła różnie nazywają warstwy środkowe, dlatego często spotyka się od czterech do sześciu warstw.

Czy dane IoT przetwarzać na edge, czy w chmurze?

Na edge przetwarzaj wszystko, co musi działać bez internetu, w tym sterowanie fizycznymi urządzeniami. Do chmury wysyłaj to, co zyskuje na danych z całej floty, na przykład analitykę i raportowanie. EMS, który zbudowaliśmy dla Skyfri, podejmował decyzje sterujące lokalnie na Azure IoT Edge, więc mógł działać w pełni offline.

MQTT czy OPC UA w przemysłowym IoT?

Często oba. OPC UA jest popularny na hali produkcyjnej, bo razem z danymi przenosi model informacyjny, a MQTT to lekki transport publish/subscribe do chmury. Erich Barnstedt z Microsoftu w artykule OPC Foundation opisuje OPC UA jako ładunek, a MQTT jako transport.

Co się dzieje z systemem IoT, gdy zerwie się połączenie z internetem?

Azure IoT Edge dalej działa offline, buforuje wychodzące wiadomości domyślnie do 7200 sekund, a po powrocie połączenia wysyła je w pierwotnej kolejności. Klient MQTT z czystą sesją traci subskrypcje i musi subskrybować od nowa. W trybie offline status urządzenia w portalu wciąż może wyglądać na sprawny.

Jeśli planujesz system połączonych urządzeń i chcesz ustalić warstwy, protokoły i zachowanie offline, zanim zacznie się programowanie:

• Usługi przemysłowego IoT i oprogramowanie urządzeń
• Przeczytaj case study Skyfri
• Umów bezpłatne warsztaty discovery