Obsługa danych i architektura

IronFlock zapewnia pełną, kompleksową infrastrukturę przyjmowania i przechowywania danych — od brzegu do chmury — zaprojektowaną z myślą o skalowalności, bezpieczeństwie i jasnej własności danych. Niezależnie od tego, czy kierujesz telemetrią z tysięcy czujników, czy budujesz interfejsy SCADA w czasie rzeczywistym, architektura danych IronFlock gwarantuje, że Twoje informacje są bezpieczne, izolowane i dostępne.

Routing wiadomości i bezpieczne realmy

Sercem komunikacji IronFlock w czasie rzeczywistym jest solidny klaster routingu wiadomości. Ta infrastruktura komunikacyjna łączy różnorodne urządzenia brzegowe w ramach projektu ze sobą oraz z infrastrukturą chmurową IronFlock.

Aby zapewnić ścisłe bezpieczeństwo i izolację danych, klaster routingu jest semantycznie podzielony na bezpieczne realmy. Realmy to izolowane podsieci — wiadomości pozostają ściśle w ich granicach, co oznacza, że dane i polecenia nie opuszczają ani nie przekraczają realmów.

Aplikacje działające na urządzeniach brzegowych mogą komunikować się w tych realmach komunikacyjnych za pomocą ironflock-sdk na jeden z następujących sposobów:

• Publish/Subscribe (Pub/Sub): idealne do ciągłego rozgłaszania telemetrii czujników lub zmian stanu.
• Remote Procedure Calls (RPC): doskonałe do bezpośredniego wyzwalania akcji lub bezpiecznego odpytywania stanu urządzenia.

Dynamicznie udostępniane bazy danych projektu

Do trwałego przechowywania i analiz historycznych IronFlock udostępnia dedykowaną fizyczną bazę danych TimescaleDB dla każdego projektu.

Ta baza danych projektu stanowi centralny punkt zbierania danych dla każdej aplikacji zainstalowanej w projekcie:

• Zaplecza danych aplikacji: zaplecza danych wszystkich aplikacji zainstalowanych w Twoim projekcie są bezpiecznie przechowywane w tej bazie. Zainstaluj drugą aplikację, a doda ona własne tabele obok pierwszej — projekt uruchamiający kilka aplikacji gromadzi wszystkie ich dane w jednym miejscu, gdzie można je odpytywać wspólnie.
• Bezpośrednie przyjmowanie: gdy aplikacje urządzeń publikują dane za pomocą ironflock-sdk, strumienie te są bezpośrednio przyjmowane i porządkowane w bazie danych projektu.
• Dostęp do odczytu, za zgodą: aplikacja domyślnie odczytuje tylko własne dane, ale po Twoim zatwierdzeniu jedna aplikacja może również odczytywać dane innej aplikacji w tym samym projekcie — dzięki czemu aplikacje mogą korzystać ze wzajemnych odczytów. Ty kontrolujesz to udostępnianie i możesz je w każdej chwili odwołać (patrz poniżej).

Ponieważ baza danych projektu działa jako jedno źródło prawdy dla Twoich operacji, odblokowuje zaawansowane możliwości:

• Zapytania SQL: pisz potężne zapytania bezpośrednio na surowych tabelach historycznych.
• Integracja Physical AI: pozwól agentom IronFlock AI wyodrębniać, analizować i odpytywać dane w języku naturalnym.
• Źródło wizualizacji: baza danych projektu jest ostatecznym źródłem danych dla paneli na żywo, paneli IoT i paneli SCADA.

Niestandardowe transformacje

Tabele, które zapisuje aplikacja, rzadko mają dokładnie taki kształt, jakiego wymaga pytanie, które chcesz zadać. Całkowita efektywność wyposażenia (OEE) łączy dostępność, wydajność i jakość; raport zmianowy potrzebuje godzinowych przedziałów; porównanie dwóch maszyn oznacza złączenie tabel dwóch różnych aplikacji. Niestandardowa transformacja odpowiada na takie pytanie raz na zawsze: to zapytanie SQL zapisane pod nazwą, które od tej pory zachowuje się jak każda inna tabela w projekcie.

Tworzenie takiej transformacji nie jest zadaniem dla dewelopera aplikacji. Każdy członek projektu z uprawnieniem Dostęp do danych — tym samym, które otwiera konsolę zapytań SQL — może zapisać transformację, a asystent AI IronFlock może utworzyć ją na żądanie, gdy panel potrzebuje wartości, której nie zawiera żadna surowa tabela. Transformacje żyją poza wszystkimi aplikacjami, we własnej przestrzeni projektu o nazwie IronFlock, dzięki czemu jedna transformacja może czytać z tabel wszystkich aplikacji zainstalowanych w projekcie.

• Napisz zapytanie raz. Opracuj je w konsoli zapytań w widoku danych projektu i wybierz Zapisz jako transformację albo przejdź od razu do tamtejszej zakładki Transformacje. Do tabel źródłowych odwołujesz się jako databackend_<key>.<table> — są to nazwy, które drzewo danych pokazuje obok każdej aplikacji.
• Wybierz sposób obliczania. Transformacja zmaterializowana przechowuje swój wynik i przelicza go zgodnie z ustawionym przez Ciebie harmonogramem, co najwyżej raz na minutę. Zwykły widok jest obliczany przy każdym odczycie: zawsze aktualny, ale tak szybki, jak jego zapytanie.
• Opisz, co zwraca. Transformacja niesie ze sobą opis, a każda kolumna wyniku ma własną nazwę wyświetlaną i własny opis. Są one przechowywane razem z transformacją w bazie danych — to właśnie pokazuje edytor widżetów i to czyta asystent AI; dobrze opisana transformacja to taka, której asystent potrafi poprawnie użyć także wiele miesięcy później.
• Powiąż ją jak tabelę. Transformacja pojawia się w selektorze danych edytora widżetów pod pozycją IronFlock, obok tabel każdej aplikacji, i zasila ten sam kanał na żywo: gdy się odświeży, odświeżają się powiązane z nią panele.

Pisanie transformacji, która dobrze się zachowuje

Transformacja zwraca dokładnie te wiersze, które wybiera jej własny SQL. Okna czasowe widżetów, filtry kalendarza i tryb latest dotyczą tabel i są tutaj ignorowane, co sprawia, że warto przyjąć trzy nawyki:

• Ogranicz zakres czasu wewnątrz zapytania, na przykład WHERE tsp > now() - interval '7 days'. Pojedynczy odczyt jest też ograniczony do 3000 wierszy, więc agreguj w zapytaniu, zamiast wybierać surową historię.
• Sortuj szereg czasowy od najnowszych (ORDER BY <kolumna czasu> DESC). Widżety otrzymują wtedy wiersze od najstarszych do najnowszych, a tam, gdzie obowiązuje limit wierszy, zachowywane są te najnowsze.
• Wybierz każdą kolumnę, którą chcesz wykreślić lub według której chcesz filtrować. Transformacja nie ma ukrytych kolumn ze znacznikiem czasu ani z urządzeniem: widżet może użyć tylko tego, co zapytanie faktycznie zwraca.

Jeśli transformacja przestanie działać — odczytywana przez nią aplikacja została odinstalowana, użyta kolumna zniknęła — zakładka Transformacje pokazuje przyczynę, a pozostałe transformacje działają dalej. Odczyt transformacji na panelu podlega tym samym regułom dostępu co dane dowolnej aplikacji; uprawnienie Dostęp do danych decyduje tylko o tym, kto może ją zapisać.

Deweloperzy aplikacji mogą zamiast tego dostarczać transformacje wraz z aplikacją, deklarując je w jej schemacie danych — zobacz Tabele transformacyjne. Oba rodzaje odczytuje się tak samo.

Magazyn plików projektu

Nie wszystko, co wytwarza aplikacja, mieści się w tabeli. Obok bazy danych projektu każdy projekt otrzymuje prywatny magazyn plików na obiekty — klatki z kamer, raporty PDF, obrazy firmware, klipy audio, eksporty — podlegający dokładnie tym samym zasadom co baza danych.

• Każda aplikacja otrzymuje magazyn automatycznie. Po zainstalowaniu aplikacji IronFlock udostępnia jej prywatny obszar magazynowy w magazynie plików projektu, tak samo jak udostępnia tabele bazy danych aplikacji. Kilka aplikacji łączy swoje pliki w jednym magazynie projektu, przy czym obiekty każdej aplikacji są wyraźnie oddzielone od obiektów pozostałych.
• Obowiązują te same gwarancje własności. Pliki należą do właściciela projektu, a nie do dewelopera aplikacji. Możesz je przeglądać, pobierać, ograniczać ich ilość i usuwać, a deweloper aplikacji nie widzi plików, które ona gromadzi podczas działania w Twoim projekcie.
• Pliki łączą się bezpośrednio z Twoimi danymi. Przechowywany obiekt ma trwały, kontrolowany pod względem dostępu adres URL, który aplikacja może zapisać w kolumnie bazy danych — dzięki czemu widżet panelu renderuje obraz lub dokument bez dodatkowej pracy, a odebranie użytkownikowi dostępu do projektu odbiera mu również możliwość pobierania plików.
• Ty zarządzasz budżetem. Ustawienia magazynu każdej aplikacji pokazują, ile go zużywa, i pozwalają ustawić limit magazynu, opróżnić tabelę lub usunąć wszystkie pliki aplikacji. A dla narzędzi spoza platformy — analityka z DuckDB, nocnej kopii zapasowej — możesz wydać poświadczenia S3 tylko do odczytu, ograniczone do plików pojedynczej aplikacji.

Magazyn plików można przeglądać tuż obok tabel: widok danych projektu pokazuje pozycję Pliki dla każdej aplikacji, wymieniając każdy przechowywany obiekt wraz z jego rozmiarem, typem i datą. Szczegóły po stronie dewelopera — deklarowanie magazynu, przestrzenie nazw, retencja i wywołania SDK — znajdziesz w sekcji Przechowywanie plików.

Udostępnianie danych między aplikacjami

Aplikacje w tym samym projekcie są domyślnie izolowane: każda odczytuje i zapisuje tylko własne tabele oraz własne pliki. To bezpieczny punkt wyjścia — aplikacja, którą zainstalowałeś do pomiaru energii, nie ma powodu odczytywać zdjęć inspekcyjnych innej aplikacji, chyba że tak zdecydujesz.

Jednak aplikacje często powinny współpracować — aplikacja analityczna odczytująca historię aplikacji monitorującej, aplikacja raportująca pobierająca zdjęcia z aplikacji kontroli jakości. IronFlock umożliwia to dzięki jednej decyzji o zgodzie, którą kontrolujesz, w ustawieniach aplikacji korzystającej z danych:

• Zatwierdzasz dokładnie, które aplikacje-dostawców może odczytywać dana aplikacja, i widzisz powód, dla którego aplikacja chce uzyskać dostęp. Nic nie jest udostępniane bez Twojego wyraźnego zatwierdzenia.
• Jedno przyznanie obejmuje obie połowy huba — udostępnione tabele aplikacji-dostawcy oraz jej udostępnione pliki. Nie zarządzasz uprawnieniami do bazy danych i do plików osobno.
• Dostęp jest tylko do odczytu. Aplikacja korzystająca może przeglądać dane innej aplikacji, ale nigdy ich nie zmienia ani nie usuwa.
• Możesz odwołać dostęp w dowolnym momencie, a dostęp ustaje natychmiast.

To, co w ogóle jest oferowane do udostępnienia, zależy od decyzji dewelopera aplikacji, podejmowanej dla każdej tabeli i każdej przestrzeni nazw plików — część danych aplikacja zachowuje ściśle wewnętrznie i nigdy nie pojawiają się one jako coś, co mógłbyś przyznać. Spośród tego, co można udostępnić, to Ty decydujesz, czy faktycznie to udostępnić. Mechanika po stronie dewelopera została opisana w sekcji Korzystanie z danych innych aplikacji.

Własność danych a Akt o Danych UE

IronFlock jest zbudowany na jednej jasnej zasadzie: właściciel projektu jest właścicielem danych — nie deweloper aplikacji.

Wszystkie dane generowane przez aplikacje — strumienie telemetrii z urządzeń brzegowych, dzienniki zdarzeń, pochodne analizy — są przechowywane w bazie danych projektu, która należy do właściciela projektu. Deweloperzy aplikacji piszą aplikacje, ale dane, które te aplikacje generują, gdy są uruchamiane w projekcie, są wyłączną własnością projektu, który je hostuje.

Ten model jest bezpośrednio zgodny z wymaganiami Aktu o Danych UE (EU Data Act), który daje użytkownikom produktów podłączonych do sieci oraz powiązanych usług pełną kontrolę nad danymi generowanymi przez ich urządzenia. W IronFlock:

• Wyłączna kontrola. Właściciele projektów mają pełną władzę administracyjną nad bazą danych projektu — mogą odczytywać, eksportować, usuwać i tworzyć kopie zapasowe wszystkich zawartych w niej danych.
• Brak ukrytego gromadzenia danych. Deweloperzy aplikacji nie mają dostępu do danych projektu, chyba że zostaną do niego wyraźnie zaproszeni. Nie istnieje żaden ukryty potok danych od projektu z powrotem do dewelopera aplikacji.
• Przenośność. Wszystkie dane znajdują się w standardowej instancji TimescaleDB, dzięki czemu można je odpytywać za pomocą SQL, eksportować w otwartych formatach i migrować do woli — właściciele projektów nigdy nie są uwięzieni w vendor lock-in.
• Szczegółowe udostępnianie. Właściciele projektów mogą zapraszać deweloperów aplikacji, partnerów integracyjnych lub innych interesariuszy do projektu i przyznawać im szczegółowe uprawnienia dostępu do konkretnych obszarów danych. Umożliwia to korzystanie z zewnętrznego wsparcia technicznego, zdalnej konserwacji lub specjalistycznych usług analitycznych na warunkach zdefiniowanych — i w każdej chwili odwołalnych — przez właściciela.

W skrócie: aplikacje generują dane, ale właściciel projektu jest ich właścicielem, kontroluje je i udostępnia. Ten model własności jest pierwszorzędnym celem projektowym platformy IronFlock, a nie refleksją ex post.

Rezygnacja: ominięcie potoku danych IronFlock

Warstwa komunikacyjna IronFlock i baza danych projektu to zalecana ścieżka — zapewniają routing w czasie rzeczywistym, trwałe przechowywanie, dane gotowe do paneli i wbudowane gwarancje własności od razu po zainstalowaniu. Jednak IronFlock nie zmusza aplikacji do korzystania z tego potoku.

Aplikacje działające na urządzeniach zarządzanych przez IronFlock są zwykłymi obciążeniami kontenerowymi i zachowują pełną swobodę sieciową i systemową. Jeśli właściciel projektu lub deweloper aplikacji woli inny stos obsługi danych, aplikacja może:

• Wysyłać dane do systemów zewnętrznych. Wysyłać dane bezpośrednio do brokerów stron trzecich (MQTT, Kafka, AMQP), chmurowych punktów przyjmowania danych (AWS IoT, Azure IoT Hub, Google Cloud IoT) lub niestandardowych API REST / gRPC.
• Używać alternatywnego magazynu. Zapisywać do zewnętrznych baz danych (InfluxDB, MongoDB, S3, własna TimescaleDB klienta itp.) zamiast lub obok bazy danych projektu IronFlock.
• Łączyć się z systemami on-premise. Integrować się bezpośrednio z istniejącymi systemami MES, ERP, historianami lub SCADA w sieci lokalnej bez przechodzenia przez chmurę IronFlock.
• Łączyć oba podejścia. Publikować podzbiór danych do IronFlock dla paneli i analiz AI, strumieniując jednocześnie dane o pełnej wierności gdzie indziej.

Ta elastyczność sprawia, że IronFlock nadaje się zarówno do wdrożeń greenfield, w których użytkownicy w pełni adoptują platformę, jak i do integracji z istniejącymi architekturami danych przedsiębiorstwa, w których miejsca docelowe danych nie podlegają negocjacjom.

Wykorzystanie danych w panelach IoT i SCADA

Wizualne wykorzystanie danych jest proste. Podczas konfigurowania widżetów na panelu IoT lub SCADA prawie każdą właściwość widżetu (np. jego tytuł, wartości lub kolor) można dynamicznie powiązać z danymi na żywo z bazy danych projektu.

Podczas edycji widżetu w Board Studio pod polem konfiguracji znajduje się przełącznik wiązania danych. Po wybraniu konkretnej kolumny z tabeli ustanawiasz kanał w czasie rzeczywistym dla tej właściwości. Gdy tylko nowa telemetria dotrze do bazy danych projektu, powiązana właściwość zostanie automatycznie zaktualizowana w czasie rzeczywistym, bez konieczności ręcznego odświeżania UI.

Uwaga: szczegółowe wyjaśnienie, jak połączyć właściwości widżetu z bazą danych, znajdziesz w sekcji wiązania danych w dokumentacji paneli IoT.