Urządzenia brzegowe i agent

Urządzenia brzegowe to główne węzły wykonawcze IronFlock. Każde urządzenie to maszyna z systemem Linux — komputer przemysłowy, Raspberry Pi, NVIDIA Jetson, brama lub dowolny sprzęt z jądrem Linux — uruchamiający agent IronFlock i jedną lub więcej konteneryzowanych aplikacji Docker.

Agent IronFlock

Agent to lekki plik binarny w Go działający na urządzeniu i obsługujący:

Zarządzanie kontenerami — Uruchamia, zatrzymuje i monitoruje kontenery Docker dla wszystkich zainstalowanych aplikacji
Łączność WAMP — Utrzymuje trwałe, szyfrowane połączenie WebSocket z centralnym brokerem wiadomości
Aktualizacje OTA — Odbiera i stosuje aktualizacje agenta, systemu operacyjnego hosta i zainstalowanych aplikacji
Tunelowanie — Zapewnia bezpieczny dostęp zdalny do usług urządzenia (HTTP, SSH, VNC, TCP, UDP) przez tunele odwrotnego proxy — bez otwartych portów
Zarządzanie siecią — Konfiguruje połączenia Wi-Fi, LAN i LTE na urządzeniu

Agent jest jedynym komponentem IronFlock działającym bezpośrednio na systemie operacyjnym hosta. Wszystko inne działa wewnątrz kontenerów Docker.

Autonomiczne działanie

Urządzenia brzegowe są zaprojektowane do działania niezależnie od usług centralnych. Jeśli połączenie sieciowe zostanie przerwane:

Aplikacje kontynuują działanie — Wszystkie konteneryzowane aplikacje nadal działają normalnie
Aplikacje mogą buforować dane — Telemetria jest kolejkowana lokalnie i przekazywana do FleetDB po przywróceniu łączności

Ta autonomia to fundamentalny wybór projektowy. W środowiskach przemysłowych nie można zagwarantować niezawodności sieci, a aplikacje brzegowe nie mogą zależeć od połączenia z chmurą.

Co działa na urządzeniu


┌─────────────────────────────────────────┐
│       System operacyjny Linux (host)    │
│                                         │
│  ┌─────────────────────────────────┐    │
│  │         Agent IronFlock         │    │
│  │  (łączność, OTA, tunelowanie)   │    │
│  └────────────┬────────────────────┘    │
│               │                         │
│  ┌────────────┴────────────────────┐    │
│  │         Docker Runtime          │    │
│  │                                 │    │
│  │  ┌─────────┐  ┌─────────┐       │    │
│  │  │  Aplik. │  │  Aplik. │ ...   │    │
│  │  │  (czyt. │  │ (własna │       │    │
│  │  │ OPC UA) │  │  logika)│       │    │
│  │  └─────────┘  └─────────┘       │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘
         │ (tylko połączenia wychodzące WSS)
         ▼
    Broker wiadomości WAMP

Każda aplikacja działa we własnym kontenerze z własnymi zależnościami. Aplikacje mogą być pisane w dowolnym języku programowania — Python, Go, Rust, Node.js, C++ lub cokolwiek, co działa w kontenerze Docker.

Obsługiwany sprzęt

IronFlock obsługuje dowolne urządzenie z systemem Linux i obsługą Docker:

Platforma	Architektura	Przykłady
Komputery przemysłowe	x86_64	Beckhoff, Advantech, Kontron, Dell Edge
Komputery jednomodułowe	ARM64, ARMv7	Raspberry Pi 4/5, BeagleBone
Akceleratory AI	ARM64	NVIDIA Jetson Nano, Orin, Xavier
Bramy	ARM64, x86_64	Teltonika, Moxa, Advantech
Sprzęt niestandardowy	ARM (v5, v6, v7), ARM64, x86_64	Dowolne urządzenie Linux z Docker

Provisioning urządzeń

Urządzenia można dodawać do IronFlock na kilka sposobów:

Flash z FlockFlasher — Użyj desktopowej aplikacji FlockFlasher do zapisania IronFlock OS na nośniku urządzenia. Urządzenie uruchamia się z wstępnie skonfigurowanym agentem i łączy automatycznie.
Instalacja agenta — Na istniejącym systemie Linux zainstaluj plik binarny agenta i dostarcz plik konfiguracyjny (plik .flock) z danymi uwierzytelniającymi urządzenia.
Wstępna rejestracja OEM — Zarejestruj numery seryjne urządzeń z wyprzedzeniem. Gdy urządzenie jest zasilone i łączy się, jest automatycznie przypisywane do właściwego projektu.

Model komunikacji

Domyślnie urządzenia brzegowe nawiązują tylko połączenia wychodzące. Agent łączy się z brokerem wiadomości WAMP przez szyfrowany WebSocket (WSS) i nie musi nasłuchiwać na żadnym porcie. Oznacza to:

Domyślnie nie są wymagane żadne reguły zapory dla ruchu przychodzącego na urządzeniu
Urządzenie nie jest wykrywalne ani adresowalne z internetu
Dostęp zdalny jest zapewniany przez tunele odwrotne — inicjowane przez urządzenie, nie przez operatora

Jednak porty urządzenia mogą być selektywnie otwierane gdy potrzeba — na przykład, aby udostępnić lokalny HMI, REST API lub inną usługę działającą na urządzeniu.