2026-05-26

Harpia od środka: założenia i architektura systemu

Jak podzieliłem automatyczny inkubator Harpia na aplikację PC, sterownik STM32 i mechanikę oraz dlaczego każda z tych części ma własne zadanie.

koncepcja / architektura / automatyka

Najpierw system, dopiero później pudełko z grzałką

Harpia ma być automatycznym inkubatorem jaj ptasich, który prowadzi proces według przygotowanego profilu, pilnuje warunków w komorze i pokazuje użytkownikowi, co dzieje się wewnątrz urządzenia. Zależy mi na tym, aby obsługa była wygodna, ale najważniejsze funkcje nie opierały się na ciągłym klikaniu i doglądaniu programu.

Dlatego od początku traktuję Harpię jako cały system, a nie pojedynczy sterownik z wyświetlaczem. Projekt podzieliłem na trzy główne warstwy, które można rozwijać i sprawdzać osobno, a później połączyć przez jasno określone interfejsy.

Schemat blokowy architektury automatycznego inkubatora Harpia
Planowana architektura całego urządzenia: aplikacja PC, komunikacja, sterownik, czujniki, elementy wykonawcze i komora inkubacyjna.

Trzy główne części Harpii

Każda warstwa ma inne tempo pracy i inne wymagania. Rozdzielenie odpowiedzialności ułatwia rozwój, testowanie oraz późniejsze szukanie problemów — bo zdanie „coś nie działa” jest zdecydowanie mniej użyteczne niż wskazanie konkretnej warstwy.

  • aplikacja PC — konfiguracja profili, wizualizacja, wykresy, sterowanie nadrzędne i diagnostyka;
  • sterownik STM32 — autonomiczny algorytm procesu, pomiary, regulacja, zabezpieczenia i obsługa elementów wykonawczych;
  • mechanika — komora, obieg powietrza, napędy, rozmieszczenie podzespołów oraz fizyczne warunki inkubacji.

Komputer ma pomagać, a nie trzymać inkubator przy życiu

Aplikacja PC jest warstwą nadzorczą. Pozwala wygodnie przygotować harmonogram, wysłać go do urządzenia, obserwować parametry i przeprowadzić diagnostykę. Nie chcę jednak, aby komputer musiał działać przez cały cykl inkubacji. Po otrzymaniu poprawnej konfiguracji sterownik powinien prowadzić proces samodzielnie również po rozłączeniu przewodu lub zamknięciu aplikacji.

Taki podział daje prostą zasadę: PC odpowiada za wygodę i czytelną prezentację, a sterownik za ciągłość oraz bezpieczeństwo procesu. Dzięki temu awaria programu nie powinna automatycznie oznaczać awarii całego urządzenia.

Rola aplikacji PC w strukturze systemu Harpia
Aplikacja przygotowuje konfigurację i prezentuje stan, natomiast właściwy proces ma pozostać po stronie autonomicznego sterownika.

Podział odpowiedzialności

  • Aplikacja PC — profile, komunikacja, HMI, wykresy i diagnostyka; ta warstwa jest już opisana szerzej.
  • Sterownik STM32 — autonomiczne prowadzenie procesu i obsługa sprzętu; otrzyma osobny opis na późniejszym etapie.
  • Mechanika — zapewnienie rzeczywistych warunków w komorze inkubacyjnej; również zostanie opisana osobno.

Rozwój warstwami

Taki układ pozwala najpierw sprawdzić logikę i komunikację na symulatorach, zanim do programu zostanie podłączona fizyczna elektronika. Później tę samą mapę danych będzie można wykorzystać podczas uruchamiania sterownika, a na końcu zintegrować całość z mechaniką urządzenia.