Főoldal · Referenciák · Kémiai keverő vezérlőrendszer
Esettanulmány · Laborszoftver · Magyarország

Valós idejű vezérlőrendszer kémiai keverőkhöz

Egyedi, recept-alapú vezérlőrendszer egy kémiai keverőhöz: érintőképernyős felület a többlépéses reakciók megtervezésére, és egy valós idejű szoftverréteg, ami biztonságosan fordítja le ezeket élő hardverparancsokra.

Ügyfél
Bizalmas ipari partner
Iparág
Vegyipar és laboreszközök
Amit építettünk
Recept-alapú, valós idejű vezérlőrendszer egy kémiai keverőhöz
Szolgáltatás
Hardverintegráció · Full-stack fejlesztés · Rendszerarchitektúra

A kihívás

A labor munkatársainak érintőképernyőn kellett tudniuk összeállítani a többlépéses kémiai keverési recepteket — hőmérséklet-görbét, keverési sebességet, pontos anyagadagolást —, és biztonságosan futtatni azokat, anélkül hogy kézzel kellene írniuk a gépnek.

A legnagyobb technikai kihívás az élő, byte-szintű, kétirányú kommunikáció volt a valódi laborhardverrel — hőmérséklet-szabályozóval, keverőmotorral, adagoló fecskendőkkel, szelepekkel — egy soros porton keresztül, ahol a magas szintű, deklaratív recepteket valós időben kellett alacsony szintű, imperatív hardverparancsokra fordítani, úgy, hogy a gép soha ne kerülhessen veszélyes állapotba.

A vezérlő egy Raspberry Pi-n fut a laborban, gyakran megbízható internetkapcsolat nélkül, ezért a teljes rendszernek offline is működnie kellett, korlátozott hardveren is gyorsan kellett reagálnia, és egy összeomlás vagy áramkimaradás után magától kellett helyreállnia — miközben a felület folyamatosan szinkronban tartja magát egy futó recept valós állapotával, nem egy állandó kapcsolatra támaszkodva.

A megoldás: háromrétegű, biztonságközpontú vezérlőrendszer

A rendszert három, egymással HTTP-n kommunikáló, önálló rétegként építettük fel: egy érintőképernyőre optimalizált Vue felület, ami a Pi saját böngészőjében fut, egy Node.js/Express backend, ami az üzleti logikát és a recept-adatokat kezeli, és egy alacsony szintű Rust szolgáltatás, ami a keverő pontos soros protokollját beszéli.

Ez a szétválasztás lehetővé tette, hogy a biztonságkritikus, byte-szintű hardverlogikát teljesen függetlenül fejlesszük és teszteljük a felhasználói felülettől — akár egy szimulált „fake hardware” soros porton keresztül is, valódi keverőgép nélkül.

01

Recept-szerkesztő és élő monitorozás

Érintőképernyőre optimalizált SPA a többlépéses receptek — fűtés, hőmérsékleten tartás, hűtés — összeállítására, lépésenkénti hőmérséklettel, keverési sebességgel és pontos fecskendős adagolással, előzetes hőmérséklet-görbével, majd futás közben élő grafikonnal és valódi mérési pontokkal, plusz azonnali leállítással.

02

Recept-hardver fordítómotor

Node/Express backend, ami minden módosítást validál, hogy a gép soha ne kerülhessen veszélyes állapotba, SQLite-ban tárolja a recepteket és a futástörténetet, és egy háttérfolyamattal folyamatosan összeveti a futó recept deklarált lépéseit a keverő valós állapotával, majd a megfelelő parancsokat küldi tovább.

03

Közvetlen hardver- és soros port vezérlés

Rust szolgáltatás, ami a soros kapcsolatot kezeli a keverővel, és minden hardverutasítást saját végpontként ér el, a JSON parancsokat byte-pontosan fordítva a keverő bináris protokolljára — beépített timeouttal, hibakezeléssel és vészleállítással.

Kihívások és megoldások

  • Valós idejű hardverszinkron: a protokollt Rust enumokkal modelleztük, így minden parancs megbízhatóan kódolható és dekódolható, és a szoftver megvárja a hardver tényleges visszaigazolását, mielőtt egy lépést befejezettnek tekintene — nem vakon küldi tovább a parancsokat.
  • Beépített biztonság: a backend minden recept-módosítást a keverő aktuális állapotához képest validál, így az soha nem vezérelhető veszélyes konfigurációba, és egy teljes leállítás mindig egy koppintásnyira van.
  • Offline-first, önjavító üzemeltetés: a teljes rendszer a Raspberry Pi-n fut, internetfüggés nélkül, felügyelve, hogy bármelyik komponens — frontend, backend vagy hardverréteg — összeomlás esetén automatikusan újrainduljon, miközben a felület adott időközönként lekérdezi a backendet, hogy szinkronban maradjon a tényleges futással, állandó kapcsolat helyett.

Nálatok is van hasonló hardveres-szoftveres kihívás?

Kezdjük egy beszélgetéssel arról, milyen projekten dolgoztok, és hogyan válhat belőle szoftverrel biztonságos, valós idejűen vezérelt rendszer.

Időpontot foglalok →