# Architektura IoT: warstwy, diagram i budowa systemów przemysłowych Source: https://ordergroup.co/pl/blog/architektura-iot/ Last updated: 2026-10-21 > Architektura IoT w praktyce: 3 czy 5 warstw, diagram referencyjny, edge czy chmura, MQTT, Modbus i OPC UA oraz checklista tego, co psuje się na produkcji. ![Płytka drukowana z układami elektronicznymi](https://ordergroup.co/media/images/photo-1562408590-e32931084e23fmj.width-2850.format-webp.webp) # Architektura IoT: warstwy, diagram i budowa systemów przemysłowych [Maciej Sułek](https://ordergroup.co/pl/eksperci/maciej-sulek/), Współzałożyciel i CTO | 21 października 2026 | 9 min czytania Spis treści W skrócie Warstwy architektury IoT: model 3-warstwowy i 5-warstwowy Diagram architektury IoT: referencyjny system przemysłowy Edge czy chmura: gdzie powinna działać logika? Jakie protokoły łączą warstwy architektury IoT: MQTT, Modbus, OPC UA, HTTP? Co psuje się na produkcji: checklista architektury IoT dla CTO Jak wybrać architekturę IoT przed rozpoczęciem budowy Architektura IoT: najczęstsze pytania Następne kroki W skrócie Architektura IoT przenosi dane z urządzeń przez łączność, bramkę edge i platformę chmurową do aplikacji, a tą samą drogą odsyła komendy. Porównujemy model 3-warstwowy i 5-warstwowy i wyliczamy, co sprawdzić, żeby zerwane połączenie nie przeszło na produkcji niezauważone. Architektura IoT prowadzi dane przez łańcuch warstw: urządzenia i czujniki, łączność, bramkę edge, platformę chmurową, która dane przyjmuje, przetwarza i przechowuje, oraz aplikację, w której pracują ludzie. Tą samą drogą wracają do urządzeń komendy. Podręczniki upraszczają to do trzech warstw (percepcji, sieci, aplikacji) albo pięciu (percepcji, transportu, przetwarzania, aplikacji i biznesu). Większość poradników rysuje te same prostokąty. Różnica między diagramem a systemem produkcyjnym wychodzi, gdy zrywa się połączenie: klient MQTT z czystą sesją traci subskrypcje bez żadnego komunikatu o błędzie, a urządzenie edge, które przeszło w tryb offline, w portalu wciąż może wyglądać na sprawne. Przykłady pochodzą z systemów przemysłowych i energetycznych, które zbudowaliśmy dla Skyfri, Zeronest i KYOTO w ramach naszych [usług przemysłowego IoT](https://ordergroup.co/pl/tworzenie-oprogramowania-iot/). ## Warstwy architektury IoT: model 3-warstwowy i 5-warstwowy 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”](https://arxiv.org/abs/2004.12936) (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](https://ordergroup.co/pl/slownik/iot/) i nasz tekst o tym, [czym jest przemysłowy IoT](https://ordergroup.co/pl/blog/czym-jest-przemyslowy-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. Warstwy architektury IoT: co robi każda z nich, typowe ryzyko na produkcji (ze wskazaniem źródła, gdy pochodzi z zewnętrznej dokumentacji) i przykład z naszych projektów. | Warstwa | Co robi | Typowe ryzyko na produkcji | Przykład z naszych projektów | |---|---|---|---| | Urządzenia i czujniki | Odczytują wartości z instalacji i przyjmują komendy | Ścieżka danych zależy od chmury producenta albo domowego Wi-Fi | Zeronest: urządzenie podłączone do falownika przez RS485/Modbus, wysyła dane przez LTE | | Łączność | Przenosi wiadomości między urządzeniem, bramką i platformą | Klient MQTT z czystą sesją traci subskrypcje po rozłączeniu (HiveMQ, ThingsBoard) | Zeronest: MQTT z TLS 1.2 do AWS IoT Core | | Bramka edge | Wykonuje lokalną logikę i buforuje wiadomości podczas awarii | Zbuforowane wiadomości wygasają po upływie TTL (domyślnie 7200 s na Azure IoT Edge) albo gdy zapełni się dysk (Microsoft Learn) | Skyfri: decyzje sterujące EMS podejmowane lokalnie na Azure IoT Edge, więc EMS mógł działać w pełni offline | | Platforma chmurowa (przyjmowanie, przetwarzanie, przechowywanie) | Odbiera, przetwarza i przechowuje dane całej floty | Na AWS IoT Core sesja trwała domyślnie wygasa po godzinie, a QoS 2 nie jest obsługiwany (dokumentacja AWS) | Zeronest: AWS IoT Core; Skyfri: Azure IoT Hub jako strona chmurowa | | Aplikacja | Dashboardy, alerty, raporty i integracje | Na Azure IoT Edge urządzenie, które przeszło w tryb offline, wciąż może wyglądać na sprawne (200 OK), bo agent przestaje raportować (Microsoft Learn) | Skyfri: monitoring działa jako osobna warstwa w Skyfri Intelligence | W warstwie aplikacji pojawiają się [analityka przemysłowego IoT](https://ordergroup.co/pl/blog/analityka-danych-iiot/) i [projektowanie dashboardów](https://ordergroup.co/pl/blog/projektowanie-dashboardow-iiot/). ### 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. ## Diagram architektury IoT: referencyjny system przemysłowy ![Diagram architektury IoT w pięciu krokach: urządzenie z Modbus, RS485 lub OPC UA, brama edge działająca offline, broker MQTT z TLS (np. AWS IoT Core albo Azure IoT Hub), przetwarzanie i magazyn danych oraz aplikacja z API, z torem komend z powrotem do urządzenia](https://ordergroup.co/media/images/iot-architecture-diagram.width-800.format-webp.webp) 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](https://ordergroup.co/pl/slownik/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](https://ordergroup.co/pl/case-studies/zeronest-monitorowanie-paneli-slonecznych/). ## Edge czy chmura: gdzie powinna działać logika? ![Hala centrum danych z rzędami szaf serwerowych i korytkami kablowymi pod sufitem](https://ordergroup.co/media/images/photo-1564457461758-8ff96e439e83w.width-800.format-webp.webp) 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](https://ordergroup.co/pl/slownik/ems/), 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”](https://learn.microsoft.com/en-us/azure/iot-edge/offline-capabilities) 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. ## Jakie protokoły łączą warstwy architektury IoT: MQTT, Modbus, OPC UA, HTTP? 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. Protokoły łączące warstwy architektury IoT i miejsce każdego z nich. | Protokół | Model | Gdzie pasuje | Uwagi | |---|---|---|---| | Modbus | Protokół magistrali polowej, często przez RS485 | Od urządzenia do bramki | Mapa rejestrów (która wartość leży pod którym adresem) różni się u poszczególnych producentów, więc ktoś musi być właścicielem tych map | | OPC UA | Dane z modelem informacyjnym | Hala produkcyjna, zwłaszcza zakłady brownfield | W badaniu VDMA 2025 wśród niemieckich producentów maszyn i instalacji 57% firm używało go na produkcji, a około połowa nowych produktów już go obsługiwała | | MQTT | Lekki model publish/subscribe | Od bramki do chmury; urządzenia o ograniczonych zasobach i zawodne sieci | Trzy poziomy QoS: 0 (najwyżej raz), 1 (co najmniej raz), 2 (dokładnie raz) | | HTTP | Żądanie/odpowiedź | Odpytywanie i integracje REST | Gorzej pasuje do ciągłego strumienia telemetrii | 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”](https://opcconnect.opcfoundation.org/2021/12/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](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html) 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. ## Co psuje się na produkcji: checklista architektury IoT dla CTO 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”](https://www.hivemq.com/mqtt-essentials-part-7-persistent-session-queuing-messages/), przez ThingsBoard w [„Non-persistent and persistent sessions”](https://thingsboard.io/docs/mqtt-broker/pe/user-guide/clean-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](https://ordergroup.co/pl/blog/bezpieczenstwo-iot/). ## Jak wybrać architekturę IoT przed rozpoczęciem budowy ![Dashboard analityczny na tablecie](https://ordergroup.co/media/images/dashboard_tablet_2x.width-800.format-webp.webp) 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](https://ordergroup.co/pl/case-studies/kyoto-oprogramowanie-cyfrowego-blizniaka/) 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](https://ordergroup.co/pl/slownik/bms/)) oparty na [SCADA](https://ordergroup.co/pl/slownik/scada/), który w czasie rzeczywistym monitoruje przepływ energii i nim steruje. Więcej projektów znajdziesz w [przykładach przemysłowego IoT](https://ordergroup.co/pl/slownik/cyfrowy-blizniak/). 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](https://ordergroup.co/pl/kontakt/), które obejmują sprzęt, protokoły, zachowanie offline, aktualizacje i granice bezpieczeństwa. ## Architektura IoT: najczęstsze pytania ### 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. ## Następne kroki 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ń](https://ordergroup.co/pl/tworzenie-oprogramowania-iot/) - [Przeczytaj case study Skyfri](https://ordergroup.co/pl/case-studies/skyfri-platforma-zarzadzania-aktywami-fotowoltaicznymi/) - [Umów bezpłatne warsztaty discovery](https://ordergroup.co/pl/kontakt/) Planujesz system połączonych urządzeń? Ustal warstwy, protokoły i zachowanie offline, zanim zacznie się programowanie. [Umów bezpłatne warsztaty discovery](https://ordergroup.co/pl/kontakt/?utm_source=blog&utm_medium=referral&utm_campaign=content_marketing) ## Więcej w tym temacie - Specjalizacja [Rozwiązania IoT dla przemysłu i oprogramowanie urządzeń](https://ordergroup.co/pl/tworzenie-oprogramowania-iot/) - Usługa [Tworzenie oprogramowania na zamówienie](https://ordergroup.co/pl/uslugi/tworzenie-oprogramowania/tworzenie-oprogramowania-na-zamowienie/) - Usługa [Warsztaty strategii produktu](https://ordergroup.co/pl/uslugi/doradztwo-it-discovery/warsztaty-strategii-produktu/) - Case study [Skyfri - platforma do zarządzania aktywami fotowoltaicznymi i magazynami energii](https://ordergroup.co/pl/case-studies/skyfri-platforma-zarzadzania-aktywami-fotowoltaicznymi/) ## Więcej artykułów: Przemysłowy IoT [Przemysłowy IoT | 24 stycznia 2022 | 6 min czytania Czym jest "przemysłowy IoT" i jaką rolę odgrywa w Przemyśle 4.0?](https://ordergroup.co/pl/blog/czym-jest-przemyslowy-iot/) [Przemysłowy IoT | 10 kwietnia 2024 | 6 min czytania Analiza i wizualizacja danych z przemysłowego IoT](https://ordergroup.co/pl/blog/analityka-danych-iiot/) [Przemysłowy IoT | 1 lutego 2022 | 5 min czytania Jaka jest rola cyberbezpieczeństwa w systemach IoT?](https://ordergroup.co/pl/blog/bezpieczenstwo-iot/) [Wszystkie artykuły: Przemysłowy IoT](https://ordergroup.co/pl/blog/iot/)