Rövid összefoglaló

A feladat egy modern, letisztult és könnyen kezelhető mobilalkalmazás (Android és/vagy iOS prototípus) tervezése és lefejlesztése, amely a meglévő nyiregyhazahazavar.hu portál tartalmára építve közvetlenebb kapcsolatot teremt a várossal. A projekt kulcsfontosságú eleme egy olyan Instagram-szerű, képekkel ellátott push-értesítési rendszer megvalósítása deep linkinggel, amely valós időben, személyre szabottan juttatja el a legfrissebb helyi karrierlehetőségeket, lakhatási támogatásokat és híreket a felhasználókhoz. A csapatoknak egy működő, offline módot is támogató kliens-szerver architektúrát kell prezentálniuk a forráskóddal, egy rövid UI/UX koncepcióval és bemutató videóval kiegészítve.

1. A projekt háttere

A nyiregyhazahazavar.hu portál fontos szerepet játszik Nyíregyháza Megyei Jogú Város életében. Az oldal célja, hogy segítse a helyi fiatalokat, a hazatérni vágyókat, a munkavállalókat és a családokat a beilleszkedésben, az otthonteremtésben, valamint tájékoztatást nyújtson a városi támogatásokról, karrierlehetőségekről és helyi hírekről.

Bár a weboldal reszponzív és sok információt tartalmaz, a felhasználók többsége az azonnali, mobilra optimalizált elérést részesíti előnyben. Egy dedikált mobilalkalmazás közelebb hozná a várost a felhasználókhoz, és közvetlenebb kommunikációs csatornát biztosítana Nyíregyháza és a városhoz kötődő emberek között.

2. A projekt célja

A csapatok feladata egy olyan könnyen kezelhető mobilalkalmazás (Android és/vagy iOS prototípus) megtervezése és lefejlesztése a Nyíregyháza Hazavár programhoz kapcsolódóan, amely:

• Modern, letisztult és intuitív felhasználói felületet (UI) biztosít.

• Lehetővé teszi a legfontosabb információk (hírek, támogatások, álláslehetőségek) gyors elérését.

• Rendelkezik felugró értesítésekkel (push notifications), amelyek a közösségi média platformokhoz (pl. Instagram értesítések) hasonlóan azonnali elérést biztosítanak a legfrissebb eseményekről vagy fontos városi bejelentésekről.

• Képes személyre szabott tartalmakat nyújtani a felhasználónak az érdeklődési köre alapján.

3. Alkalmazási példa (Felhasználói életút)

Péter egy Nyíregyházáról elszármazott friss diplomás szoftverfejlesztő, aki azon gondolkodik, hogy hazaköltözik. Letölti a Nyíregyháza Hazavár appot.

1. Regisztráció/Személyre szabás: Kiválasztja a „Karrier” és az „Otthonteremtési támogatások” kategóriákat, mint fő érdeklődési körök.

2. Hírcsatorna: Az app azonnal megjeleníti a számára releváns nyíregyházi állásokat és az önkormányzati lakáspályázatokat, stb.

3. Push értesítés (Instagram-szerű élmény): Néhány nappal később Péter telefonján felugrik egy push értesítés: „Új támogatási lehetőség nyílt meg fiatal házasoknak Nyíregyházán! Kattints a részletekért.”

4. Interakció: Az értesítésre kattintva az appon belül azonnal megnyílik a támogatás részletes leírása és az igénylés menete.

4. Kötelező funkcionális követelmények

4.1. Felhasználóbarát felület és navigáció

• Egyszerű, tiszta, modern design (javasoltan a weboldal elemeivel vagy ahhoz passzoló színekkel)

• Alapszín / Háttérszín (Világoskék): #D9E8FE (a portál jellegzetes, tiszta háttérszíne)

• Elsődleges kékes szín (Pantone 653): #1F5A95 (gombok, fejlécek, hangsúlyos elemek)

• Kiegészítő zöld (Pantone 382): #C4D600 (pozitív visszajelzések, aktív állapotok, kiemelések)

• Figyelemfelkeltő narancs (Pantone 1495): #FF8F1C (akciógombok, kiemelt felhívások, vagy az átmenetekhez a #DE6A10 -> #F2B800 gradiens)

• Semleges sötét/szürke (Process Black 60%): #6D7176 (szövegek, másodlagos ikonok, leírások)

4.2. Hírek és információs modul

• A nyiregyhazahazavar.hu aktuális híreinek, cikkeinek dinamikus megjelenítése.

• Kategóriák szerinti szűrés (pl. Karrier, Lakhatás, Kultúra/Szabadidő, Ösztöndíjak).

• Cikkek mentése kedvencek közé (offline olvasáshoz).

4.3. Értesítések (Push Notifications) modul – Kiemelt funkció!

• Instagram-szerű felugró értesítések megvalósítása.

• Képes legyen képeket vagy rövid figyelemfelkeltő szövegeket is megjeleníteni az értesítésben.

• Az értesítésre kattintva az alkalmazás az adott hírre vagy menüpontra navigáljon (Deep Linking).

• Beállítások menüpont, ahol a felhasználó ki-be kapcsolhatja a különböző témájú értesítéseket (pl. csak a Karrier hírekről kér értesítést).

4.4. Kapcsolatfelvétel és Ügyintézés támogatása

• Közvetlen gombok a Hazavár iroda eléréséhez (e-mail küldés appon belül).

4.5. Adminisztrációs felület (Mock vagy egyszerű CMS)

• Egy egyszerű felület (akár webes, akár külön admin szerepkör az appban), ahol a versenyen demonstrálható módon új hírt lehet feltölteni, és ki lehet küldeni egy teszt push értesítést a telefonokra.

5. Kommunikációs és adatkezelési követelmények

• Az appnak REST API-n (JSON formátumban) keresztül kell kommunikálnia egy backend szerverrel (ez lehet egy egyszerű szimulált backend vagy Firebase).

• Hálózati kapcsolat kiesése esetén az app ne omoljon össze, mutasson barátságos „Offline mód” képernyőt, és jelenítse meg a legutóbb letöltött (gyorsítótárazott) adatokat.

6. Nem funkcionális követelmények

• Gyorsaság: Az alkalmazásnak gyorsan kell betöltenie, az animációk legyenek folyamatosak (60 FPS).

• Biztonság: Felhasználói regisztráció esetén a jelszavak biztonságos tárolása, HTTPS protokoll használata.

• Bővíthetőség: Tiszta kódstruktúra, hogy a későbbiekben újabb funkciókkal (pl. ügyintézési modul) is bővíthető legyen.

7. Technológiai szabadság

A csapatok szabadon választhatják meg az alkalmazott technológiát, például:

• Native fejlesztés: Kotlin (Android) / Swift (iOS).

• Cross-platform keretrendszerek (ajánlott): Flutter vagy React Native.

• Backend: Node.js, Python, Firebase, Supabase vagy bármilyen egyéb preferált környezet.

8. Minimálisan bemutatandó működési folyamat (Demo forgatókönyv)

A zsűri előtti bemutatón a csapatnak az alábbi folyamatot kell működés közben prezentálnia:

1. Az alkalmazás elindítása egy valós vagy emulált mobilon.

2. Navigálás a hírek között, szűrés egy adott kategóriára.

3. Az admin felületről egy új, egyedi hír beküldése.

4. A telefonra valós időben megérkező felugró (push) értesítés bemutatása.

5. Az értesítésre rákattintva az app azonnal megnyitja a frissen beküldött hírt.

6. Az internetkapcsolat lekapcsolása mellett az app offline működésének bemutatása.

9. Beadandó eredmények

• A működő prototípus (telepíthető APK fájl Androidra, vagy iOS tesztkörnyezet, pl. TestFlight / Expo).

• A teljes forráskód elérhetősége (pl. GitHub repozitórium).

• Rövid rendszerterv és UI/UX koncepció (Figmatev vagy képernyőképek, a könnyű kezelhetőség tervezési elveinek bemutatása).

• Rövid bemutató videó (max. 3 perc), amely bemutatja a működést, különös tekintettel a push értesítésekre.

10. Értékelési szempontrendszer

11. Választható többletfeladatok (Plusz pontokért)

Többletpont szerezhető az alábbi extra funkciók kidolgozásával:

• Sötét mód: Automatikus váltás a rendszerbeállítások alapján.

• Megosztás funkció: Hírek közvetlen megosztása közösségi médiában (Instagram, Facebook) egy gombnyomásra.

Rövid összefoglaló

Egy tervezett helyi kedvezményrendszer hátterének és biztonsági hálójának a megtervezésére és lefejlesztésére. A feladat egy olyan központi adatbázis és háttérlogika kidolgozása, amely valós időben képes ellenőrizni a beolvasott QR-kódok érvényességét. A rendszernek alkalmasnak kell lennie a visszaélések kiszűrésére (pl. egy kód többszöri, jogosulatlan felhasználásának letiltása, időbeli korlátok kezelése), valamint egy egyszerű adminisztrációs felület biztosítására, ahol a program koordinátorai és a partnercégek követhetik

1. A projekt háttere

A nyiregyhazahazavar.hu portál fontos szerepet játszik Nyíregyháza Megyei Jogú Város életében. Az oldal célja, hogy segítse a helyi fiatalokat, a hazatérni vágyókat, a munkavállalókat és a családokat a beilleszkedésben, az otthonteremtésben, valamint tájékoztatást nyújtson a városi támogatásokról, karrierlehetőségekről és helyi hírekről. A projekthez kidolgozás alatt van egy egyedi kedvezményrendszer, amely helyi szolgáltatóknál biztosít meghatározott kedvezményeket előnyöket.

A program keretében tervezett digitális kedvezményrendszer sikere nagymértékben múlik azon, hogy a helyi partnercégek (boltok, éttermek, szolgáltatók) gyorsan, zökkenőmentesen és biztonságosan tudják-e ellenőrizni a felhasználók által felmutatott egyedi azonosítót (pl:QR-kód). Ha a rendszer kijátszható (például a megengedettnél többször érvényesítenek kedvezményeket egy jogosultsággal), a partnerek anyagi veszteséget szenvednek el. Egy biztonságos, valós idejű háttérrendszer és adminisztrációs felület biztosítja a program hosszú távú hitelességét és fenntarthatóságát.

2. A projekt célja

A csapatok feladata egy olyan könnyen kezelhető háttérrendszer (Backend API) és webes adminisztrációs felület prototípusának megtervezése és lefejlesztése a Nyíregyháza Hazavár programhoz kapcsolódóan, amely:

• Modern, letisztult és intuitív felületeket (UI) biztosít a partnereknek, valamint egy átfogó "főadmin" nézetet a koordinátoroknak.

• Lehetővé teszi a beolvasott QR-kódok valós idejű ellenőrzését és a tranzakciók gyors rögzítését.

• Rendelkezik intelligens biztonsági szabályokkal, amelyek azonnali védelmet (riasztást) nyújtanak a visszaélési kísérletekkel szemben.

• Képes strukturált jelentéseket és statisztikákat nyújtani a kártyahasználati adatok alapján.

3. Alkalmazási példa (Csalás kiszűrése)

Kovács úr átküldi az ismerőseinek a saját, egyedi, állandó QR-kódját fotó formájában, hogy ők is vásároljanak be vele. A partnercégnél a beállított kedvezmény heti egyszer használható fel.

• Első beolvasás: A felesége kedden 14:00-kor felmutatja a kódot az egyik üzletben. A partnercég dolgozója beolvassa azt, majd a felületen rányom, hogy szeretné érvényesíteni a kedvezményt. A háttérrendszer sikeresen ellenőrzi a jogosultságot, egyértelmű zöld jelzést ad, és rögzíti a tranzakciót.

• Második próbálkozás: Kovács úr fia 14:02-kor ugyanezen partnernél megpróbálja felmutatni ugyanezt a kódot. A dolgozó beolvassa és megpróbálja jóváhagyni.

• Visszaélés kiszűrése: A backend azonnali hibaüzenetet és piros jelzést küld vissza a partner kasszájához/készülékére: „A kódhoz tartozó kedvezménykeret már felhasználásra került!”

• Riasztás és adminisztráció: A tranzakciót a rendszer automatikusan elutasítja, naplózza az eseményt, a főadminisztrátori felületen pedig azonnal megjelenik egy gyanús tevékenységről szóló riasztás.

4. Kötelező funkcionális követelmények

4.1. Felhasználóbarát felület és navigáció

Egyszerű, tiszta, modern design (javasoltan a weboldal elemeivel vagy ahhoz passzoló színekkel):

• Alapszín / Háttérszín (Világoskék): #D9E8FE (a portál jellegzetes, tiszta háttérszíne)

• Elsődleges kékes szín (Pantone 653): #1F5A95 (gombok, fejlécek, hangsúlyos elemek)

• Kiegészítő zöld (Pantone 382): #C4D600 (pozitív visszajelzések, aktív állapotok, kiemelések)

• Figyelemfelkeltő narancs (Pantone 1495): #FF8F1C (akciógombok, kiemelt felhívások, vagy az átmenetekhez a #DE6A10 $\rightarrow$ #F2B800 gradiens)

• Semleges sötét/szürke (Process Black 60%): #6D7176 (szövegek, másodlagos ikonok, leírások)

4.2. Biztonságos QR-kód validációs API

• Egy dokumentált végpont (API) biztosítása a beolvasott QR-kódok valós idejű dekódolására és ellenőrzésére.

• A beküldött adatok alapján a rendszer ellenőrizze a kód érvényességét, és a felhasználó státuszát.

• A validációs válasznak azonnal vissza kell jeleznie az ellenőrzés eredményét (Sikeres / Elutasítva + hibaok).

4.3. Visszaélés-gátló szabálymotor (Anti-fraud) – Kiemelt funkció!

Intelligens szabályok megvalósítása a csalások kiszűrésére:

• Állandó, egyedi azonosító: Minden felhasználónak generálódik egy egyedi QR kód, amit ő fel tud mutatni.

• Manuális jóváhagyás és vizuális visszajelzés: A QR-kódot be tudják olvasni, majd a partneralkalmazásban rányomnak, hogy igen, szeretnék használni a kedvezményt. Ezután a rendszer egyértelmű zöld (lehet használni) vagy piros (már felhasznált/elutasított) vizuális jelzést ad.

• Frekvencia-limit: Egy felhasználói fiókkal egy adott szolgáltatónál (a szolgáltató beállítása alapján) csak meghatározott számú kedvezményt lehessen igénybe venni (pl. naponta 1, hetente 1), ezzel megakadályozva a kód többszörözött felhasználását.

4.4. Partneri felület, Jogosultságkezelés és Riportok

• Jogosultságkezelés: Lehessen hozzáadni dolgozókat a felülethez. A jogosultságoknál meg kell különböztetni a dolgozókat (akik csak érvényesíteni tudják a kuponrendszert) és a vezető beosztásúakat (akik jogosultak a statisztikák és riportok lekérdezésére).

• Monitorozás és statisztika: Közvetlen felület a partnerek vezetői részére a statisztikák (pl. hányan használták a kupont), a saját tranzakciós történetük, hogy pontos statisztikát lehessen lekérni a forgalomról.

4.5. Főadminisztrátori felület (Globális Webes Dashboard)

• Teljes körű ("Főadmin") jogosultság: Egy olyan központi felület biztosítása a program koordinátorai (főadminok) számára, ahonnan mindent látnak és kezelnek. Hozzáférnek a teljes felhasználói adatbázishoz, valamint rálátnak az összes csatlakozott partnercég (vállalati) felületére, adataira és statisztikáira.

• Globális monitorozás: Ezen az egyszerű webes dashboardon a versenyen demonstrálható módon nyomon követhetők a globális statisztikák (összes tranzakciók száma, legnépszerűbb helyek), valamint valós időben megjelennek a letiltott visszaélési kísérletek és riasztások.

5. Kommunikációs és adatkezelési követelmények

• Az adminisztrációs felületeknek REST API-n (JSON formátumban) keresztül kell kommunikálniuk a backend szerverrel.

• Hálózati kapcsolat vagy adatbázis-hiba esetén a backend ne omoljon össze, alkalmazzon megfelelő kivételkezelést és biztonságos hibatájékoztatást.

6. Nem funkcionális követelmények

• Gyorsaság: A validációs kérések kiszolgálásának rendkívül gyorsnak kell lennie (alacsony válaszidő).

• Biztonság: Az adminisztrátori belépések védelme, a jelszavak hashelt tárolása az adatbázisban, valamint HTTPS protokoll használata.

• Bővíthetőség: Tiszta kódstruktúra és adatmodell, hogy a későbbiekben újabb partnerkezelő és számlázási modulok is beépíthetők legyenek.

7. Technológiai szabadság

A csapatok szabadon választhatják meg az alkalmazott technológiát, például:

• Backend keretrendszer: Node.js (Express), Python (FastAPI/Django), Java Spring Boot, vagy felhőalapú logikák (Firebase/Supabase).

• Adatbázis: PostgreSQL, MySQL, MongoDB, vagy egyéb strukturált adattároló.

• Admin Frontend: React, Angular, Vue.js, vagy bármilyen egyéb preferált környezet.

8. Minimálisan bemutatandó működési folyamat (Demo forgatókönyv)

A zsűri előtti bemutatón a csapatnak az alábbi folyamatot kell működés közben prezentálnia:

• Egy valid felhasználói QR-kód beolvasása, majd egy dolgozói fiókkal a jóváhagyás (érvényesítés) gomb megnyomása az API felé.

• A backend zöld jelzéssel sikeresen érvényesíti a kódot, és a tranzakció azonnal megjelenik a statisztikákban.

• Ugyanezen QR-kód ismételt beolvasása és jóváhagyási kísérlete (a partneri frekvencia-limit túllépésével).

• A backend piros jelzéssel elutasítja a tranzakciót a dolgozói felületen, és a csalásmegelőző rendszer riasztást generál.

• A gyanús tevékenységről szóló riasztás valós időben felugrik a főadminisztrátori webes felületen.

• A partner vezetői fiókjának bemutatása, megmutatva a kedvezmény mértékének/gyakoriságának beállítási lehetőségét, valamint az ebből húzott statisztikákat (monitorozás).

• A teljes folyamat és az összes adat visszakereshetőségének bemutatása a főadmin felületen, a rendszer adatbázisában vagy biztonsági naplójában.

9. Beadandó eredmények

• A működő backend, partneri és főadmin felület prototípusa (link a futó webes alkalmazáshoz vagy lokálisan futtatható Docker környezet).

• A teljes forráskód elérhetősége (pl. GitHub repozitórium).

• Rövid rendszerterv és adatbázis-séma leírása (API dokumentáció vagy adatmodell bemutása).

• Rövid bemutató videó (max. 3 perc), amely bemutatja a működést, különös tekintettel a valós idejű validációra és a visszaélés-szűrésre.

10. Értékelési szempontrendszer

11. Választható többletfeladatok (Plusz pontokért)

Többletpont szerezhető az alábbi extra funkciók kidolgozásával:

• Dockerizált környezet: A teljes backend és adatbázis elindítása egyetlen docker-compose up paranccsal.

• Automatikus PDF elszámolás: A partnerek számára egy gombnyomásra letölthető tranzakciós jelentés generálása a kedvezményekről.

• Árukedvezmény funkció: Lehetőség legyen nem %-os kedvezményt rendelni a partnercéghez (pl.: „ingyen üdítő a páros menühöz” jelelgű nem pénzbeli kedvezmények)

A rendszer célja, hogy bemutassa, hogyan lehet egy mikrokontrolleres eszközt természetesebb, emberközeli interfésszel vezérelni. A megoldásnak nem szükséges teljes beszédfelismerést megvalósítania, elegendő néhány előre definiált parancsszó felismerése és megbízható végrehajtása.

Egyes farmokon komoly szenzorokkal rengeteg adatot mérnek, de a gazdák nagy része nehezen használ technológiát - pedig az adatokból sok hasznos információval tudnánk nekik szolgálni. Cél Készítsetek egy egyszerűen kezelhető webes dashboardot, amelyen a gazdák könnyedén áttudják tekinteni a szenzorok és érzékelők adatai,

A gazdák nem akarnak számítógép és telefon előtt ülve adatokat bogarászni, hogy eldöntsék, mit tegyenek a terméssel a legjobb hozam érdekében. Egy könnyen elérhető,fact-first asszisztenssel viszont szívesen beszélgetnek: felteszik a kérdést, és kapnak egy érthető, indokolt választ. Cél Egy agrár chatbotot, amely lehetőség szerint lokális, kis LLM-et futtat, és amelybe betölthető
egy saját tudásbázis. A cél egy moduláris, könnyen telepíthető alkalmazás, amit bárki saját adataival fel tud okosítani - guardrailekkel és a beszélgetések auditálható naplózásával

1. A projekt háttere

Az ipari, mezőgazdasági, energetikai és épületüzemeltetési környezetekben egyre több szenzor, vezérlő, relé és egyéb IoT-eszköz működik. Ezek az eszközök gyakran eltérő kommunikációs protokollokat használnak, különböző gyártóktól származnak, és közvetlenül nem képesek együttműködni az üzleti informatikai rendszerekkel.

A feladat egy kisméretű számítógépen – például Raspberry Pi eszközön – működő szoftverrendszer megtervezése és prototípusának elkészítése. A rendszer feladata, hogy kapcsolatot teremtsen a fizikai IoT-eszközök, a helyi hálózat, a távoli szerverek és az üzleti alkalmazások között.

A megoldás egy helyi, intelligens átjáróként – edge gatewayként – működjön. Legyen képes adatokat fogadni, tárolni, feldolgozni és továbbítani, valamint előre meghatározott szabályok vagy külső informatikai döntések alapján fizikai eszközöket vezérelni.

2. A projekt célja

A csapatok feladata egy modulárisan bővíthető, biztonságosan működő IoT middleware rendszer elkészítése, amely:

• szenzoradatokat olvas és gyűjt;
• helyi szabályok alapján eseményeket ismer fel;
• riasztásokat és értesítéseket generál;
• reléket, szabályozókat vagy szimulált beavatkozó eszközöket vezérel;
• adatokat továbbít külső alkalmazásoknak;
• képes más Raspberry Pi alapú egységekkel együttműködni;
• külső szerver vagy üzleti alkalmazás döntését fogadni és végrehajtani;
• hálózati kapcsolat kiesése esetén is korlátozottan működőképes marad;
• megfelelő hitelesítési, titkosítási és naplózási megoldásokat alkalmaz.

A rendszer ne kizárólag egyetlen előre meghatározott feladatot oldjon meg. Olyan általános platform készüljön, amely különböző szenzorokkal, vezérlőkkel és alkalmazási területeken is használható.

3. Alkalmazási példa

Egy épületben két különálló Raspberry Pi működik.

Az első Raspberry Pi egy helyiség hőmérsékletét, páratartalmát és levegőminőségét méri. Az adatokat továbbítja egy központi szervernek. A szerver az aktuális értékek, az épület használati rendje és egy külső üzleti alkalmazásból érkező információ alapján meghozza a döntést.

Amennyiben beavatkozás szükséges, a szerver utasítást küld a második Raspberry Pi számára, amely bekapcsol egy ventilátort, szellőztetőberendezést vagy más szimulált fogyasztót.

Ha a központi szerver nem érhető el, a helyi Raspberry Pi egy előre meghatározott biztonsági szabály alapján önállóan is végrehajthatja a szükséges beavatkozást.

A csapatok más alkalmazási területet is választhatnak, például:

• szerverterem hőmérséklet-felügyelete;
• üvegház vagy növénytermesztő rendszer szabályozása;
• vízszint- és szivárgásfigyelés;
• energiafogyasztás felügyelete;
• raktári környezet ellenőrzése;
• intelligens épületüzemeltetés;
• gépállapot-felügyelet;
• beléptetési vagy területbiztonsági rendszer;
• kritikus infrastruktúra szimulált felügyelete.

4. Kötelező funkcionális követelmények

4.1. Szenzoradatok fogadása

A rendszer legalább két különböző típusú adatforrást kezeljen.

Lehetséges adatforrások:

• Raspberry Pi GPIO-csatlakozón elérhető szenzor;
• I²C-, SPI- vagy UART-kommunikációt használó eszköz;
• hálózaton keresztül elérhető szenzor;
• MQTT-üzenet;
• HTTP-kérés;
• Modbus TCP-eszköz;
• szimulált vagy fájlból beolvasott adatforrás.

A rendszer rögzítse legalább:

• a mért értéket;
• a mérés típusát és mértékegységét;
• az adatforrás azonosítóját;
• a mérés időpontját;
• az adat érvényességi vagy minőségi állapotát.

4.2. Adattárolás

A mért adatok helyi adatbázisban vagy más strukturált adattárolóban kerüljenek rögzítésre.

Biztosítani kell:

• az időalapú visszakeresést;
• az eszköz vagy szenzor szerinti lekérdezést;
• a hibás vagy hiányos adatok megjelölését;
• a régi adatok archiválásának vagy törlésének lehetőségét;
• hálózati kapcsolat hiányában az adatok ideiglenes helyi tárolását.

4.3. Szabály- és triggerkezelés

A rendszer tegye lehetővé feltételek és válaszreakciók megadását.

Példák:

• ha a hőmérséklet 30 °C fölé emelkedik, kapcsoljon be egy relét;
• ha egy érték öt percen keresztül egy megadott tartományon kívül van, keletkezzen riasztás;
• ha egy szenzor meghatározott ideig nem küld adatot, a rendszer jelezze az eszközhibát;
• ha külső szerverről vezérlési parancs érkezik, a rendszer hajtsa végre azt;
• ha a hálózati kapcsolat megszakad, a rendszer térjen át helyi működésre.

Legalább három különböző típusú szabály megvalósítása szükséges.

4.4. Beavatkozó eszköz vezérlése

A rendszer legalább egy fizikai vagy szimulált beavatkozó eszközt vezéreljen.

Ez lehet:

• relé;
• LED;
• ventilátor;
• motor;
• szivattyú;
• szabályozó;
• virtuális vagy szoftveresen szimulált eszköz.

A rendszer minden vezérlési műveletet naplózzon. A napló tartalmazza a parancs forrását, időpontját, eredményét és a végrehajtás állapotát.

4.5. Külső API

A rendszer biztosítson dokumentált API-végpontokat legalább az alábbi műveletekhez:

• aktuális szenzoradatok lekérdezése;
• korábbi mérések lekérdezése;
• eszközök állapotának lekérdezése;
• vezérlési parancs küldése;
• riasztások lekérdezése;
• a rendszer működési állapotának ellenőrzése.

Az API JSON formátumot használjon, és rendelkezzen hitelesítéssel.

4.6. Webhook támogatás

A rendszer legyen képes előre beállított esemény bekövetkezésekor külső HTTP- vagy HTTPS-végpontot meghívni.

A webhook tartalmazza legalább:

• az esemény azonosítóját;
• az esemény típusát;
• az érintett eszközt;
• az aktuális értéket;
• az esemény időpontját;
• a riasztási szintet.

Sikertelen továbbítás esetén a rendszer próbálja meg később ismételten elküldeni az eseményt.

4.7. Több átjáró együttműködése

Legalább két logikailag elkülönülő edge egység együttműködését kell bemutatni. Ezek lehetnek fizikai Raspberry Pi eszközök, virtuális gépek, konténerek vagy szimulált példányok.

A bemutatandó folyamat:

1. az egyik egység adatot olvas;
2. az adat eljut egy központi vagy köztes rendszerhez;
3. a rendszer döntést hoz;
4. a másik egység vezérlési parancsot kap;
5. a második egység végrehajtja a beavatkozást;
6. a végrehajtás eredményét visszajelzi.

4.8. Felügyeleti felület

A rendszerhez készüljön egyszerű webes vagy asztali kezelőfelület, amelyen:

• megtekinthetők a csatlakoztatott eszközök;
• láthatók az aktuális mért értékek;
• megtekinthető legalább egy historikus grafikon;
• ellenőrizhetők a riasztások;
• megtekinthetők a vezérlési események;
• kézi vezérlési parancs adható ki;
• ellenőrizhető a kapcsolat és a szolgáltatások állapota.

5. Kommunikációs követelmények

A rendszer legalább két különböző kommunikációs megoldást támogasson.

Lehetséges megoldások:

• Ethernet/LAN;
• Wi-Fi;
• mobilhálózat vagy GSM/LTE modem;
• MQTT;
• HTTP/HTTPS;
• WebSocket;
• Modbus TCP;
• OPC UA;
• más, dokumentált ipari vagy IoT-protokoll.

A rendszernek kezelnie kell a kapcsolat megszakadását és helyreállását. A hálózati hibák nem eredményezhetik a teljes alkalmazás összeomlását.

6. Kiberbiztonsági követelmények

A megoldást úgy kell kialakítani, mintha ipari vagy kritikus infrastruktúrához kapcsolódna. A verseny során elegendő a biztonsági megoldások prototípusszintű megvalósítása, de az alkalmazott módszereket dokumentálni kell.

Kötelező követelmények:

• titkosított kommunikáció használata;
• felhasználók vagy rendszerek hitelesítése;
• jogosultság-ellenőrzés a vezérlési műveleteknél;
• jelszavak és hozzáférési kulcsok biztonságos tárolása;
• bemeneti adatok ellenőrzése;
• hibás vagy jogosulatlan kérések elutasítása;
• biztonsági szempontból fontos események naplózása;
• a vezérlési parancsok forrásának azonosíthatósága;
• hálózati kapcsolat kiesésére meghatározott biztonságos működési állapot;
• az IoT- és az üzleti informatikai hálózat közötti logikai elválasztás bemutatása.

A forráskódban nem szerepelhetnek nyílt szövegként valódi jelszavak, tokenek vagy privát kulcsok.

7. Nem funkcionális követelmények

A rendszer:

• moduláris felépítésű legyen;
• új szenzortípusokkal bővíthető legyen;
• Raspberry Pi vagy hasonló erőforrású eszközön futtatható legyen;
• hiba esetén adjon értelmezhető naplóbejegyzést;
• újraindítás után automatikusan helyre tudja állítani az alapvető működését;
• hálózati kapcsolat nélkül is végezzen helyi adatgyűjtést;
• a kapcsolat helyreállása után továbbítsa a korábban eltárolt adatokat;
• rendelkezzen telepítési és konfigurációs dokumentációval;
• ne igényeljen indokolatlanul nagy számítási vagy memória-erőforrást.

Előnyt jelent a konténerizált, automatikusan telepíthető vagy reprodukálható környezet.

8. Technológiai szabadság

A csapatok szabadon választhatják meg:

• a programozási nyelvet;
• az adatbázist;
• a kommunikációs protokollokat;
• a felhasználói felület technológiáját;
• a szerveroldali vagy felhőalapú komponenseket;
• a rendszer architektúráját;
• a használt nyílt forráskódú komponenseket.

A választásokat a dokumentációban szakmailag indokolni kell.

9. Minimálisan bemutatandó működési folyamat

A végső demonstráció során a csapatnak az alábbi folyamatot kell működés közben bemutatnia:

1. Egy szenzor vagy szimulátor adatot küld az edge rendszernek.
2. Az adat megjelenik a felügyeleti felületen.
3. Az adat helyi tárolásra kerül.
4. Egy beállított feltétel teljesül.
5. A rendszer riasztást hoz létre.
6. A rendszer webhookot vagy API-hívást küld egy külső komponensnek.
7. Helyi vagy külső döntés alapján vezérlési parancs keletkezik.
8. Egy másik edge egység vagy vezérlő végrehajtja a parancsot.
9. A végrehajtás eredménye visszakerül a rendszerbe.
10. A teljes eseménysor visszakereshető a naplóban.

A csapatnak röviden azt is be kell mutatnia, mi történik hálózati kapcsolat megszakadásakor.

10. Beadandó eredmények

A pályamunkának tartalmaznia kell:

• a működő prototípust;
• a teljes forráskódot;
• telepítési útmutatót;
• felhasználói útmutatót;
• rendszerarchitektúra-ábrát;
• az alkalmazott kommunikációs folyamatok bemutatását;
• API-dokumentációt;
• adatmodell vagy adatbázisséma leírását;
• kiberbiztonsági koncepciót;
• tesztelési dokumentációt;
• rövid bemutatóvideót vagy élő demonstrációt;
• a fejlesztési döntések és alkalmazott technológiák indoklását.

A dokumentációban egyértelműen fel kell tüntetni a felhasznált külső könyvtárakat, komponenseket és nyílt forráskódú megoldásokat.

11. Értékelési szempontok

Az értékelés során nem a felhasznált szenzorok vagy hardverelemek ára és mennyisége a meghatározó. A hangsúly a működő, jól megtervezett, biztonságos és továbbfejleszthető szoftverrendszeren van.

12. Választható többletfeladatok

Többletpont szerezhető az alábbi megoldásokkal:

• grafikus szabályszerkesztő;
• dinamikusan betölthető szenzor- vagy eszközmodulok;
• automatikus eszközfelderítés;
• OPC UA- vagy SCADA-integráció;
• mobilalkalmazás;
• távoli konfigurációkezelés;
• biztonságos távoli szoftverfrissítés;
• többfelhasználós jogosultsági rendszer;
• digitális tanúsítványon alapuló eszközhitelesítés;
• redundáns központi szolgáltatás;
• prediktív vagy gépi tanulási alapú riasztás;
• energiafogyasztás-optimalizálás;
• részletes monitoring és rendszerállapot-mérés;
• automatikus tesztelési környezet;
• támadási vagy hálózati hibaforgatókönyv szimulációja;
• mobilhálózati tartalék kommunikáció;
• konfiguráció biztonsági mentése és visszaállítása.

13. Biztonsági korlátozás

A verseny során hálózati feszültséggel működő berendezés közvetlen vezérlése csak megfelelő szakmai felügyelettel és érintésvédelmi kialakítással végezhető.

A demonstrációhoz javasolt alacsony feszültségű fogyasztó, LED, ventilátor, fejlesztőpanel, relémodul vagy teljesen szimulált beavatkozó eszköz használata.

14. A sikeres megoldás ismérvei

A sikeres pályamunka nem csupán adatokat jelenít meg, hanem teljes, kétirányú folyamatot valósít meg:

fizikai eszköz → adatgyűjtés → helyi feldolgozás → külső rendszer → döntés → vezérlési parancs → fizikai vagy szimulált beavatkozás → visszaigazolás.

A megoldás akkor tekinthető kiemelkedőnek, ha egy új szenzor vagy vezérlő hozzáadása nem igényli a teljes rendszer átalakítását, a kommunikáció biztonságos, a hálózati hibák kezelhetők, és a prototípus valós ipari vagy üzleti környezetben továbbfejleszthető.