Urządzenie grzewczo-chłodnicze przestało być samym sprzętem. O jego wartości coraz częściej decyduje to, co dzieje się wokół urządzenia: aplikacja mobilna, konto użytkownika, zdalne sterowanie, telemetria i chmura, która to wszystko spina. Dla producenta HVAC oznacza to, że oprogramowanie dla systemów HVAC staje się częścią produktu, a nie dodatkiem.
Z naszego doświadczenia najtrudniejsze nie jest wymyślenie funkcji, tylko dostarczenie ich na czas, z zespołem, który rozumie i urządzenie, i chmurę. Dla globalnego producenta systemów grzewczo-chłodniczych zbudowaliśmy taki zespół i rozwijaliśmy jego aplikacje oraz warstwę chmurową, łącząc backend w Javie, natywną aplikację iOS i DevOps w chmurze.
Dlaczego systemy HVAC potrzebują dziś własnych aplikacji i chmury?
Bo zmieniło się to, czego oczekuje użytkownik i czego potrzebuje sam producent:
- użytkownik chce sterować ogrzewaniem i chłodzeniem z telefonu, nie z panelu na ścianie,
- serwis chce wiedzieć zdalnie, co dzieje się z urządzeniem, zanim klient zadzwoni,
- producent chce danych o pracy urządzeń w całej flocie, nie pojedynczych zgłoszeń,
- cykl życia produktu się wydłuża, bo aktualizacje aplikacji i chmury dokładają wartość po sprzedaży.
To wszystko wymaga oprogramowania utrzymywanego latami, a nie jednorazowego wdrożenia.
Jakie aplikacje najczęściej budujemy dla HVAC?
W projektach dla producentów skupiamy się na warstwie, która realnie dotyka użytkownika i serwisu:
- aplikacje mobilne do sterowania i monitoringu (natywny iOS, Android),
- portale i panele dla użytkowników, instalatorów i serwisu,
- funkcje zdalnej diagnostyki i zgłoszeń serwisowych,
- integracje z urządzeniem i istniejącymi systemami producenta.
W przypadku naszego klienta HVAC zespół rozwijał i optymalizował funkcje oraz UX jego własnych aplikacji, dopasowując je do celów biznesowych i oczekiwań użytkowników.
Jak wygląda warstwa chmurowa dla urządzeń HVAC?
Aplikacja to tylko wierzchołek. Pod spodem potrzebna jest chmura dla urządzeń HVAC, która uniesie telemetrię i ruch z całej floty:
- backend i API (Java, Spring, mikroserwisy) jako serce rozwiązania,
- konteneryzacja i orkiestracja (Docker, Kubernetes) dla skalowania,
- CI/CD i infrastruktura jako kod (Jenkins, Terraform, Ansible, Helm),
- chmura publiczna (np. GCP) jako środowisko uruchomieniowe.
Taki fundament pozwala dokładać funkcje bez przepisywania całości i obsłużyć rosnącą liczbę podłączonych urządzeń.
Jak połączyć aplikację z urządzeniem: embedded, chmura, aplikacja?
Produkt HVAC żyje na styku trzech warstw i każda z nich ma inne wymagania:
- urządzenie (embedded) zbiera dane i wykonuje komendy,
- chmura przyjmuje telemetrię, przechowuje dane i udostępnia API,
- aplikacja zamienia to w sterowanie i obraz dla użytkownika.
Wartość powstaje dopiero wtedy, gdy te warstwy grają razem, dlatego patrzymy na projekt end-to-end, a nie na pojedynczy ekran. Jak budujemy samą warstwę aplikacji dla urządzeń połączonych z siecią, opisaliśmy w artykule o aplikacjach dla connected products i IoT.
Jak zadbać o UX, żeby aplikacja HVAC była naprawdę używana?
Aplikacja do sterowania ogrzewaniem jest warta tyle, ile jej codzienne użycie. Dlatego pracujemy nad tym, żeby:
- codzienne czynności (zmiana temperatury, harmonogram) były proste i szybkie,
- stan urządzenia był czytelny także dla osoby nietechnicznej,
- serwis i diagnostyka nie wymagały telefonu do infolinii,
- aplikacja była spójna z resztą ekosystemu producenta.
W projekcie HVAC to właśnie optymalizacja funkcjonalności i UX była głównym celem naszego zespołu.
Jakich kompetencji dostarczamy do projektu HVAC?
Dobraliśmy skład pod konkretną specyfikację pracy, a nie „na zapas”:
- architekt / Java developer wyznaczający kierunek techniczny i backend,
- iOS developer odpowiadający za natywną aplikację,
- DevOps budujący wdrożenia, chmurę i pipeline CI/CD.
Ten układ, architekt plus specjaliści iOS i DevOps, pozwolił czteroosobowemu zespołowi realnie przejąć odpowiedzialność za aplikacje klienta.
Jak szybko zespół może wejść w projekt HVAC?
Liczy się tempo. W projekcie dla producenta HVAC większość specjalistów weszła w projekt w ciągu miesiąca od rekomendacji. Nasz proces rekrutacji zwykle zamyka się w około trzy tygodnie, a do dwóch miesięcy wydłuża się tylko przy nietypowych wymaganiach. Jako partner nearshore z Polski pracujemy w zbliżonej strefie czasowej, więc zespół wchodzi w rytm pracy, przeglądy kodu i spotkania bez długiego rozruchu.
Dedykowane oprogramowanie czy wzmocnienie zespołu: co się opłaca dla HVAC?
To zależy od tego, czy budujesz coś od zera, czy rozwijasz istniejący produkt. Przy nowym rozwiązaniu sprawdza się projekt dedykowanego oprogramowania z jasnym zakresem, przy ciągłym rozwoju aplikacji i chmury, wzmocnienie zespołu lub zespół dedykowany. W projekcie HVAC zadziałał ten drugi model: nasi specjaliści rozwijali aplikacje pod zarządem klienta, dokładając kompetencje tam, gdzie ich brakowało.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, z realnym doświadczeniem w projektach HVAC i przemysłowych:
- dla globalnego producenta systemów grzewczo-chłodniczych dostarczyliśmy zespół, który rozwijał jego aplikacje i warstwę chmurową (Java/Spring, natywny iOS, DevOps na GCP/Kubernetes),
- większość specjalistów weszła w projekt w ciągu miesiąca od rekomendacji,
- łączymy aplikację, backend i chmurę w jedną, utrzymywalną całość,
- kompetencje weryfikujemy przed startem, a skład dobieramy pod specyfikację projektu.
Najczęściej robimy to jako dedykowane oprogramowanie budowane przez nasz zespół, a tam gdzie potrzebne jest szybkie uzupełnienie kompetencji, w modelu wzmocnienia zespołu.
Od czego zacząć budowę aplikacji i chmury dla HVAC?
Zacznij od jednej, najważniejszej ścieżki użytkownika (np. zdalne sterowanie albo diagnostyka serwisowa) i od pytania, jakie dane musi unieść chmura. To wyznacza zakres aplikacji, architekturę backendu i role, których potrzebujesz. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Budujesz aplikacje lub chmurę dla systemów HVAC? Porozmawiajmy, dobierzemy zespół i architekturę pod Twój produkt.