\chapter{A rendszer ismertetése}

A     rendszer tervezését olyan alapvető felelősségekkel kezdtük, mint adatok fogadása, ezek tárolása, valamint továbbítása. A fejlesztési folyamat során ezektől haladtunk az egyre specifikusabbak fele, mint a mesterséges intelligencia által használt modellek tárolása és dinamikus frissítése. Ennek a folyamatnak eredményeképp készítettük el a <ÁBRAHIVATKOZÁS> látható architektúrát. A rendszer minden komponense egy-egy mikroszolgáltatás. Ezt a tervezési folyamat egy korai lépésében döntöttük el. E döntés mögött két indokunk volt. Az első a fejlesztés során a kooperáció könnyebbsége, hiszen a mikroszolgáltatások interfészeinek egyeztetése után azok egymástól függetlenül fejleszthetők, ezzel a kooperációt is elősegítve. Emellett ettől a döntéstől azt vártuk, hogy amennyiben a rendszer tervezése során követjük a korábban leírt ajánlásokat, a komponensek skálázhatósága jobb lesz, így a nagyobb terhelés esetén nem lesz érzékelhető növekedés a válaszidőben. Ebben a fejezetben szeretnénk bemutatni az általunk tervezett architektúrát a beérkező adatok útját bejárva.
\section{Felhő rendszer ismertetése}
<Jól ismert kép az architektúráról>
A    rendszerbe két típusú adat érkezhet . A kihelyezett eszközök által felvett hangadatok a felhő rendszerbe az Input Service-hez kerülnek be, ahol a beérkezett hangfájl és az azt kísérő üzenet formátumának validálása után az alapvető metaadatok – többek között a küldő eszköz azonosítója, beérkezés dátuma, valamint az egész felhős rendszerben használt egyedi azonosító – eltárolódnak. Ezt követően az állomány továbbításra kerül a Storage Service-nek, ahol egy objektumtárban kerül eltárolásra. Ez azért előnyös, mert ha egy mintát szeretnénk többször is feldolgozni , a feldolgozott mintákat meghallgatni validálás céljából vagy az AI Service-ben használt modellt a rendszer felhasználója pontosítani szeretné a rendelkezésre álló valós mintákkal, akkor lehetőség van azt lekérni egyéb metaadatai mellett az egyedi azonosító segítségével. Erre viszont csak limitált ideig van lehetőség, ugyanis az eltárolt hangfájlok beállítható idő múlva – alapértelmezés szerint egy hét – törlésre kerülnek, hogy a beérkezett minták által elfoglalt lemezterületet kordában tartsuk. A fájl sikeres tárolását követően az Input Service egy üzenetsorra beküldi a minta azonosítóját, ezzel jelezve a feldolgozó komponensnek az új minta beérkezését és azt, hogy milyen azonosítót használhat a Storage Service-től lekérdezéskor.
Az üzenetsoron az AI Service  példányai fogadják az üzenetet, ezen komponens felelőssége a minták klasszifikálása többek között seregély, traktor és egyéb zaj kategóriákba. Még  mielőtt megkezdhetné a feldolgozást, a Model Service-nél ellenőrzi, hogy elérhető-e újabb modell, amivel dolgozni tud. A Model Service egy képes több típusú – beleértve a felhő rendszerben és az IoT eszközön található mesterséges intelligenciák által használtakat – modelleket képes tárolni, a modellek verzióját követni, valamint visszaadni REST API-n keresztül. Az éppen használt modell friss állapotának eldöntésére lekéri az alapértelmezett modell metaadatait, amiket összevet a lokálisan meglévő modell metaadataival. Amennyiben valóban elérhető újabb modell, letölti azt és onnan betölti további használatra. E mechanizmus által lehetőség van a rendszer által használt modellek dinamikus frissítésére és cseréjére , valamint a Model Service-ben az alapértelmezett modell korábbira visszaállításával akár korábbira visszatérés is könnyedén lehetséges. A modell ellenőrzése után az AI Service-ben található mesterséges intelligencia elvégzi a hangfájl klasszifikációját. Ennek eredményét a minta azonosítójával  egyetemben egy másik üzenetsoron publikálja. 
Az üzenetsorra érkező adatokat három mikroszolgáltatás fogadja, de az üzenetsornak hála újabb ilyen komponens illesztése a meglévő a rendszerhez könnyedén lehetséges. A Results Service feladata eltárolni minden egyes minta adatait úgy, hogy azok egyesével lekérdezhetők legyenek. Ennek a mikroszolgáltatásnak a segítségével lehetséges harmadik fél által gyártott szoftverekhez csatolni az általunk fejlesztett rendszert. A Metrics Service felelőssége idősoros adatbázisba illeszteni az eredményeket. Az idősor adatbázisból statisztikai lekérdezések segítségével betekintést nyerhetünk a szőlőben a seregélyek mozgásába, tendenciáiba akár egy harmadik fél által fejlesztett dashboarddal. Az utolsó mikroszolgáltatás, ami megkapja a klasszifikációk eredményeit a Guard Service. Ez a mikroszolgáltatás üzenetsoron küld egy riasztási parancsot annak az eszköznek, ahonnan seregélyként detektált minta érkezett.
Az egyes komponensek közötti kommunikáció alapvetően HTTP feletti REST API-k segítségével történik, kivéve az előzőekben említett helyeken. Előbbit olyan esetekben alkalmaztuk, amikor az adott interfész külső alkalmazások felé elérhető, nagy mennyiségű adat átvitele történik, vagy fontos a szinkron kommunikáció. Jó példa a Storage Service interfésze, ugyanis itt fontos tudni, hogy mikor áll készen a mikroszolgáltatás a minta kiszolgálására, valamint egy tipikus JSON formátumú üzenethez képest nagy mennyiségű, bináris adat átvitelét jelenti. Természetesen üzenetsorra is megvalósítható lenne ez a viselkedés, viszont jelentősen bonyolultabb üzleti logikát igényelt volna a megvalósítás, jelentősebb előnyt viszont nem hozna.
Az egyes mikroszolgáltatások közötti üzenetsorok AMQP (Advanced Message Queuing Protocol) felett zajlanak. Emellett akkor döntöttünk, amikor több komponensnek is szüksége van egy művelet eredményére – mint például az AI Service kimenetére reagáló három mikroszolgáltatás –, vagy nem szükséges az adott üzenetre válasznak érkeznie. Ilyen az Input Service által az AI Service-nek küldött értesítés is.
Az interfészek és üzenetek tervezése során kiemelten figyeltünk arra, hogy minden üzenetsoron és REST API-n átvitt adat lehetőleg minél kisebb legyen, csak a szükséges adatok kerüljenek továbbításra. Ezzel is növelve a kommunikáció hatékonyságát és kihasználva a HTTP és üzenetsor előnyeit minimális többletköltség mellett.
A minták fogadásában nem vesz részt a Command and Control Service, felelőssége az egyes eszközök és azok szenzorainak állapotának vezérlése, nyomon követése. A kihelyezett IoT eszközök az állapotukat üzenetsoron jelzik. Egy ilyen üzenet például lehet jelzés, hogy az eszköz valamilyen hibás állapotba került és javítást vagy cserét igényel, esetleg egy szenzorrol nem képes adatot olvasni, kikapcsolni készül vagy épp most kapcsolt be. Egy másik üzenetsoron hallgatják a parancsokat és végrehajtják azokat. Ilyen parancs lehet a mesterséges intelligencia által használt modell frissítése és a szenzor vagy eszköz kikapcsolása. Az irányító üzenetek küldését REST API segítségével lehet kiváltani. A Command and Control Service indulásakor nem ismeri a rendszerben futó eszközöket, azokat az első üzenetük fogadásakor jegyzi fel egy saját relációs adatbázisba, ahol követi az állapotukat. Azokat az eszközöket, amik öt perce nem küldtek státusz üzenetet, a mikroszolgáltatás hibás állapotba lépteti a belső állapotreprezentációjában. Az egy hétnél tovább el nem érhető eszközöket automatikusan kikerülnek az adatbázisból kivéve, ha a felhasználó API hívás segítségével permanensnek nem jelölte azt.
Az eszközök és a felhőben lévő komponensek közti üzenetsoros kommunikáció MQTT (Message Queue Telemetry Transport) protokollon történik, ami mellett annak flexibilis téma (topic) architektúrája mellett döntöttünk. Lehetőség van az egyes üzenetsorok vagy másnéven témák struktúrálására és ezáltal egyszere több témára üzenet küldésére, valamint feliratkozásra. Ezt a Command and Control Service esetében ki is használtuk, ugyanis az egyszere iratkozik fel minden eszköz státuszüzeneteire, valamint a struktúrált témáknak köszönhetően minden vezérlőüzenetet csak a céleszköz kap meg, ami csökkenti a szükséges hálózati forgalmat és az eszközök által feldolgozandó üzenetek számát.
\section{Internet of Things eszköz ismertetése}
Az IoT eszköz architektúrájának tervezése során a legfontosabb szempont az új szenzorok bevezetése volt. Emiatt úgy döntöttünk, hogy az egyes szenzorokat teljesen külön kezeljük. Három alapvető lépést határoztunk meg egy mért adat útja során. Az első a szenzor általi mérés elvégzése, amit az opcionális előfeldolgozás követ. Végezetül, a szoftvernek döntést kell hoznia, hogy az eredményt tovább küldje-e felhőbe, majd a döntést végre is kell hajtsa.
Azért, hogy ez a folyamat minél flexibilisebb legyen, az egyes lépéseket összefogja és indítja egy külön osztály, valamint a mintavételezéseket egy központi, belső óra vezérli.
Itt konkrét, hardveres implementációval nem foglalkoztunk, azt a szoftver tervezése és fejlesztése során elabsztracháltnak tekintettük.
<osztálydiagram>
A felvázolt koncepciót a fenti osztálydiagramon valósítottuk meg. Új szenzor felvétele esetén az ISensor, IPreProcessor, ISender interfészek implementálásával és SignalProcessor osztályból leszármazással, valamint ezek az Application osztályba regisztrálásával lehetséges. Új riasztásra képes forgatókönyv esetében az IActuator interfész implementálásával van lehetőségünk a riasztás elvégzésére. 
Az Application  osztály tartalmazza az eszközök eseményhurkát, ami lehetővé teszi a szenzorok ismételt mintavételét, előfeldolgozását és a minta felhőbe küldését. Az általunk megvalósított viselkedés során egy ütemben a SoundSignalProcessor vezényli a hangminták kezelését. Az ütem elején egy másodperc hosszú hangmintát vesz az előre bekonfigurált mikrofonról, amit egy mesterséges intelligencia bekategorizál többek között traktor, emberhang, méhek és madárcsicsergés kategóriákba. A madárcsiripelés kategóriába sorolt mintákat továbbítja a felhőbe a SoundSender, ahol az előbbiekben leírt folyamat kerül végrehajtásra. Ez a forgatókönyv <ÁBRAHIVATKOZÁS> látható. Minden harmadik ütem végén küld az eszköz státusz frissítést a felhőnek.
<szekvenciadiagram>
Az eszköz indulásakor az Application osztály a beállított üzenetsoron elküldi, hogy éppen bekapcsolt, hamarosan elkezd adatokat küldeni és képes parancsok végrehajtására. Utóbbi külön szálon történik, emiatt szükség volt a szenzorok offline és online állapotainak szálbiztos kezelésére a SignalProcessor leszármazottjaiban és az ezeket nyilvántartó listának is hasonlóan szálbiztosnak kell lennie. Az offline szenzorok forgatókönyve kikerül az ütemezett forgatókönyvek közül, viszont futó forgatókönyvet az alkalmazás nem szakít meg.