Budujemy oprogramowanie dla przemysłowego IoT i urządzeń

Nasze oprogramowanie przemysłowego IoT dla obiektów energetycznych działa na sterowniku na miejscu. Odczytuje baterie i falowniki przez Modbus, decyduje, co ma zrobić magazyn, i raportuje do chmury przez MQTT albo Azure IoT Hub. Energetyczną stronę tej pracy, od systemu zarządzania energią (EMS) po handel i elastyczność, opisujemy w naszym Energy Hubie.

Rozwiązania IIoT, które zbudowaliśmy dla energetyki

• Skyfri: EMS dla portfela elektrowni słonecznych z magazynami. Decyduje, kiedy baterie się ładują i rozładowują, prowadzi peak shaving i handel energią oraz współpracuje z bateriami i falownikami kilku producentów. Liczniki energii po stronie sieci, baterii i PV zasilają jego potoki danych. Od czerwca 2024 obejmował 7 obiektów i sterował ponad 5 MWh pojemności magazynów oraz ponad 4 MW mocy baterii.
• Zeronest: platforma EMS dla domowych instalacji PV z magazynem, którą budujemy od stycznia 2024. Obsługuje 16 marek falowników przez własne urządzenia Zeronest, Bzyk D200 i Świetlik D300, podłączone do każdego falownika przez RS485 i Modbus. Urządzenie raportuje przez LTE, niezależnie od chmury producenta i domowego Wi-Fi, a z AWS IoT Core rozmawia przez MQTT i TLS 1.2. Dane klientów zostają w UE. Co minutę platforma decyduje, czy domowy magazyn ładuje się, rozładowuje albo sprzedaje energię do sieci, a instalatorzy pracują we własnej aplikacji. Według stanu na kwiecień 2026 obsługiwała ponad 3000 prosumenckich instalacji magazynowych.
• Global Green: operator instalacji PV i magazynów energii w Niemczech i Kanadzie. Od grudnia 2025 roku budujemy oprogramowanie na sterowniku przy jego bateriach i w chmurze, dla 15 MWh magazynów. Obejmuje ono mapy rejestrów Modbus dla baterii dwóch producentów, MQTT, sterownik handlowy, polecenia od operatora systemu dystrybucyjnego oraz bilansowanie aFRR (rezerwa odtwarzania częstotliwości). Symulator urządzeń w AWS testuje logikę sterowania, zanim dotknie ona magazynu na obiekcie.
• KYOTO: trzy i pół roku pracy nad przemysłowym IoT i cyfrowym bliźniakiem dla magazynu energii cieplnej Kyoto Group. MVP w warstwie UX/UI rozwinęliśmy w system oparty na SCADA, który w czasie rzeczywistym monitoruje przepływ energii i nim steruje, z warstwą cyfrowego bliźniaka dla danych pogodowych, analizy cen energii i symulacji pracy instalacji. W 2024 roku nasz zakres objął bezpieczną infrastrukturę chmurową łączącą urządzenia, czujniki i systemy elektrowni słonecznej oraz magazynu ciepła. System zarządzania magazynem ciepła w stopionej soli steruje zaworami, pompami i przepływem gorących cieczy. Nadzór z kamerami na podczerwień i rozpoznawaniem obrazu alarmuje personel o zagrożeniach.

Wcześniejsze projekty z AP-TECH

Wśród naszych wcześniejszych prac z partnerem AP-TECH są systemy lotniskowe Monster (zarządzanie oświetleniem) i ATOS (śledzenie samolotów i pojazdów lotniskowych).

Więcej szczegółów projektów znajdziesz w naszych przykładach przemysłowego IoT, a pojęcia wyjaśniamy w słowniku IoT.

W Global Green sterownik przy bateriach czyta przez Modbus z lokalnego urządzenia partnera handlowego trzy kanały: żądaną moc, flagę mówiącą, czy żądanie jest ważne, oraz licznik życia, czyli heartbeat, który zmienia się, dopóki łącze działa. Kiedy żądanie jest ważne, a łącze żyje, sterownik w każdym cyklu wysyła do baterii wartość zadaną mocy czynnej, zarówno do ładowania, jak i do rozładowania. Żądanie 0 kW też jest ważnym żądaniem.

Utrzymanie ostatniego ważnego żądania

Łącze uznaje się za utracone, gdy licznik życia przestaje się zmieniać dłużej niż skonfigurowany próg. Od tej chwili sterownik utrzymuje ostatnie ważne żądanie do końca bieżącego 15-minutowego okna (UTC), a potem wraca do stanu bezczynności. W przykładzie z wymagań łącze zrywa się o 13:06:07, sterownik utrzymuje 500 kW do 13:14:59, a od 13:15:00 nie wydaje żadnego polecenia. Gdy łącze wraca, świeże dane od razu zastępują utrzymane żądanie.

Wartość zadana jest ograniczana przez limity aktywne na sterowniku.

Utrzymanie systemu przemysłowego IoT zaczyna się od wiedzy, że urządzenie przestało się odzywać, i od wychwycenia awarii, zanim zadzwoni klient.

Ostrzeżenia i błędy, aktywne i archiwalne

Moduł alertów platformy Zeronest dzieli zdarzenia na ostrzeżenia i błędy, aktywne i archiwalne, z jedną globalną listą dla wszystkich instalacji. Alerty pozwalają zespołowi ograniczyć liczbę wyjazdów serwisowych. Opisana niżej platforma obchodów planuje patrole i cykle konserwacji i zgłasza alert, gdy harmonogram zostanie naruszony.

Jakość danych na urządzeniu i w potoku

Zeronest uznaje urządzenie, które przez ustalony czas (domyślnie 120 sekund) nie wysłało żadnej ramki danych, za niedostępne. Gdy produkcja skacze powyżej progu (domyślnie 400 W), wartości z ostatniej ramki licznika nie są przekazywane dalej. Dwa kolejne alerty pilnują potoku: jeden zgłasza się, gdy zadanie przetwarzające dane modemu nie wykona się 4 razy w ciągu godziny, drugi, gdy najnowsze dane w bazie są starsze niż 20 minut.

Raz dziennie platforma odczytuje rejestry konfiguracyjne falownika, zapisuje je i odczytuje ponownie, a gdy odczytana wartość różni się od zapisanej, zgłasza alert. Instalacja zmienia status na uruchomioną dopiero po pierwszym poprawnym odczycie z falownika, a inicjalizacja urządzeń przebiega etapami pokazywanymi osobno. Dane można wyeksportować do CSV jako energię zagregowaną co 15 minut lub co godzinę albo jako odczyty surowe.

Prognozy na podstawie danych

Aplikacja Zeronest pokazuje prognozowane zachowanie magazynu do końca dnia, przewidywane zużycie i produkcję oraz wynikającą z nich oszczędność w złotówkach. Backend liczy prognozę na dzień następny ze statystyk cen taryf rynku dnia następnego i aktualizuje ją po przeliczeniu agregatu godzinowego.

Dostęp i bezpieczeństwo systemu

Panel webowy Zeronest jest wielodostępny: dane są rozdzielone między organizacjami, a uprawnienia mają dwa poziomy, więc manager widzi wszystkie instalacje firmy, a instalator tylko przypisane mu. Użytkownicy logują się jednorazowym sześciocyfrowym kodem, a logowanie hasłem wyłączono w styczniu 2025 roku.

W terenie warunki wyznaczają projekt: obiekt bez zasięgu albo skaner, który nie może zgubić sesji skanowania. Tworzenie oprogramowania IoT na zamówienie dla sprzętu w terenie łączy urządzenia, które ludzie noszą albo instalują na obiekcie, z aplikacjami i systemami zaplecza, które od nich zależą.

Punkty kontrolne odczytywane z kodów QR, tagów NFC i iBeaconów

Od 2021 roku budujemy dla klienta platformę SaaS do obchodów. Zarządza inspekcjami, zgłoszeniami serwisowymi i dokumentacją z audytów w placówkach przez aplikację webową i mobilną, która działa także offline i synchronizuje się po odzyskaniu połączenia. Ochroniarze potwierdzają punkty kontrolne, skanując kody QR, tagi NFC lub iBeacony, a ścieżki planują patrole oraz złożone wzorce konserwacji i przeglądów. Integracja z urządzeniami śledzącymi przez TCP/IP wyrosła z prototypu na używane rozwiązanie. Klienci platformy działają w Polsce, Republice Południowej Afryki i Australii.

Skanery i logistyka

Dla hurtowni wyrobów objętych unijnym systemem śledzenia budujemy aplikację na Androida dla przemysłowych skanerów ręcznych. Pracownicy skanują opakowania, kartony i palety przy odbiorze towaru, przy wydaniu z faktury, przy przesunięciu i w innych zdarzeniach. Backend przetwarza każdy typ sesji i w odpowiednim momencie rejestruje ją w centralnym routerze instytucji UE. Pełni też rolę API aplikacji i panelu administracyjnego do weryfikacji danych i zgłoszeń.

W tle zadania pobierają dokumenty klienta (faktury, korekty i płatności) przez SFTP. Po zgłoszeniu każdej sesji wynik wraca na skaner: przyjęta, przyjęta warunkowo albo odrzucona z listą kodów. Aplikacja integruje SDK skanerów Datalogic i Zebra, w tym obsługę Zebra MC3300X dodaną w styczniu 2024 i obsługę SDK Datalogic w 2026 roku, i buforuje sesje skanowania, gdy sieć przestaje działać. Aplikacja jest napisana w Kotlinie, a backend działa na Django i Celery.

Każdy projekt zaczyna się od bezpłatnego warsztatu discovery. To podstawowe discovery: jedno spotkanie, po którym masz zakres, wycenę i podstawowy mockup lub PoC, który pozwala oszacować koszt realizacji. Mapujemy na nim sprzęt i jego producentów, protokoły, to, co musi działać offline, drogę aktualizacji do urządzenia i granice bezpieczeństwa. Rozbudowane discovery, z pełnym zestawem artefaktów, to osobny, szerszy zakres.

Od warsztatu do specyfikacji

Skyfri pokazuje, co może nastąpić po warsztacie. Zanim zbudowaliśmy EMS, od 20 listopada 2023 do 7 stycznia 2024 trwało Technical Feasibility Study: siedem tygodni, w których powstały studium wykonalności i specyfikacja techniczna. Architektura i wdrożenie EMS ruszyły w styczniu 2024 roku.

Wymagania przed kodem

W Global Green każda funkcja dostaje dokument wymagań z kryteriami akceptacji i otwartymi pytaniami, powiązany z jej zadaniem. Przykładem jest sterownik handlowy. Mapy rejestrów urządzeń powstają, zanim napiszemy kod.

Długoterminowe wsparcie

Sprzęt zostaje w terenie na lata, więc oprogramowanie wokół niego musi nadążać za nowymi modelami urządzeń i nowymi wersjami Androida. Przy RAW Cyber osobnym nurtem prac było dotrzymywanie kroku zmianom Copperhead i nowemu sprzętowi dla RAW OS. Gdy Copperhead przeszedł na Androida 11, scaliliśmy nasze zmiany z kodem frameworka Androida, a we wrześniu 2021 roku zakończyliśmy to przejście. Co oznacza budowanie na Android Open Source Project dla aktualizacji i poprawek bezpieczeństwa, wyjaśnia nasze hasło AOSP.