diff --git a/src/contents/5-elozmenyek.tex b/src/contents/5-elozmenyek.tex index bbcd5eeb27369fd1145680792069938bb513335a..cefe09cccf90cc605a5df2ed2693a46bdecd4b10 100644 --- a/src/contents/5-elozmenyek.tex +++ b/src/contents/5-elozmenyek.tex @@ -30,27 +30,27 @@ sorolni: rendszerek. \end{enumerate} Az előbbi kategória esetében szükséges egy szakember ismerete, aki a felmért -igények alapján ad ajánlatot, illetve hoz döntést, hogy a rendszer mely -elemeket fogja tartalmazni. A telepítés szintúgy egy szakember feladata. Az -ilyen termékeknél nem szempont az ``onboarding" élmény a végfelhasználó számára, +igények alapján ad ajánlatot, illetve hoz döntést, hogy a rendszer mely elemeket +fogja tartalmazni. A telepítés szintúgy egy szakember feladata. Az ilyen +termékeknél nem szempont az ``onboarding'' élmény a végfelhasználó számára, ellenben az utóbbi kategóriával. A DIY rendszereknél a beszerelés kezdetétől fogva a végfelhasználóra van bízva a rendszer. A két kategória alapján választottam 2-2 terméket vizsgálatra, melyeket \aref{tab:analyzed-systems}. -táblázatban jegyeztem le. Bár a Homey termékcsalád nem elsősorban biztonsági +táblázatban jegyeztem le. Bár a Homey termékcsalád elsősorban nem biztonsági rendszer - hanem komplett okosotthon megoldás -, mégis lehetőség van -objektumvédelemre programozni. Itt már bizonyára homályos a határ, hogy mit +objektumvédelemre programozni. Emiatt az egyedi megközelítés miatt vettem hozzá +a vizsgálandó rendszerek közé. Itt már bizonyára homályos a határ, hogy mit nevezhetünk riasztórendszernek és okosotthon rendszernek, ezért ezeket mind a DIY kategória alá sorolom. -A két kategória közötti megkülönböztetést azért tartom fontosnak, mert -- megfigyelésem szerint - a hagyományos rendszerek sok esetben nem adnak -lehetőséget bármiféle integrációs lehetőségre, illetve elavult megoldásokat -kínálnak arra. Egy ilyen rendszerrel potenciálisan nehezebb interfészelni egy -modern okosotthon megoldás keretében, mint az újabb DIY rendszerek esetében, -melyek előtérbe helyezik annak fontosságát, vagy már eleve okosotthon -rendszerként üzemelnek. Ennek ellenére a DIY rendszereknek is megvannak a -hátrányai. Ezeken szeretnék a következőkben végigjárni, mérlegelni a két -megközelítés között. +A két kategória közötti megkülönböztetést azért tartom lényegesnek, mert +megfigyeléseim alapján a hagyományos rendszerek sokszor nem teszik lehetővé +az integrációt, vagy elavult módszerekkel valósítják meg azokat. Egy ilyen +rendszerrel potenciálisan nehezebb interfészelni egy modern okosotthon megoldás +keretében, mint az újabb DIY rendszerek esetében, melyek előtérbe helyezik annak +fontosságát, vagy már eleve okosotthon rendszerként üzemelnek. Ennek ellenére +a DIY rendszereknek is megvannak a hátrányai. Ezeken szeretnék a következőkben +végigjárni, mérlegelni a két megközelítés között. \paragraph{} \begin{table}[htbp!] @@ -233,7 +233,7 @@ lehetővé teszi, hogy a felhasználók igényeik szerint fokozatosan bővítsé rendszert. Ezt a skálázódást általában szoftveresen vezérelt regisztrációs folyamat, és gyakran licencalapú árképzés kíséri, amely az új elemek beemelésével arányos plusz költségeket jelenthet. A gyártók rendszerint -„freemium” modellekkel operálnak, ahol az alapszolgáltatások ingyenesek, de a +``freemium'' modellekkel operálnak, ahol az alapszolgáltatások ingyenesek, de a professzionális funkciókért fizetni kell. A \emph{hagyományos rendszerek} ezzel szemben hardveres szinten lineárisan @@ -394,15 +394,15 @@ módszere és az azt körbefoglaló folyamat sok ponton hibára tud futni. \paragraph{} Az elemzett kereskedelmi megoldások alapján jól kirajzolódik a ``hagyományos'' és a ``DIY'' rendszerek közötti technológiai, gazdasági és filozófiai különbség. Míg az ipari, szakember által telepített rendszerek -megbízhatóságukkal, zártságukkal és hosszú távú stabilitásukkal tűnnek ki, addig -a DIY rendszerek rugalmasságot, gyors telepíthetőséget és széleskörű integrációs -lehetőségeket kínálnak -- gyakran a felhasználói élmény rovására. Manapság -a hagyományos rendszerek jobban rendezkedtek be ipari alkalmazásra, mint egy -háztartáson belül. A DIY rendszerek átvették az otthoni riasztórendszerek -körében a népszerűséget nagyrészt a könnyű telepítési folyamatuk és az -alacsony belépési költségük miatt. A kutatás során megismert legfontosabb -tulajdonságokat, jellemzőket, \aref{tab-kereskedelmi-osszesites}. táblázatban -összesítettem. +megbízhatóságukkal, zártságukkal és hosszú távú stabilitásukkal tűnnek ki, +addig a DIY rendszerek rugalmasságot, gyors telepíthetőséget és széleskörű +integrációs lehetőségeket kínálnak -- gyakran a felhasználói élmény rovására. +Manapság a hagyományos rendszerek túlnyomórészt ipari alkalmazásra rendezkedtek +be, mint egy háztartáson belüli üzemre. A DIY rendszerek átvették az otthoni +riasztórendszerek körében a népszerűséget nagyrészt a könnyű telepítési +folyamatuk és az alacsony belépési költségük miatt. A kutatás során megismert +legfontosabb tulajdonságokat, jellemzőket, \aref{tab-kereskedelmi-osszesites}. +táblázatban összesítettem. \begin{table}[htbp!] \begin{tblr}{ @@ -479,8 +479,8 @@ besorolni. A dolgozat során ezen a speciális biztonságtechnikai funkción bel \paragraph{} A behatolásjelző rendszerek alapvető feladata, hogy \textsl{``[...] függetlenül képesek legyenek nem csak a [behatolást észelni egy] adott -ponton vagy bejárati úton, hanem bármely mozgást [észleljenek] a megfigyelt -területen.''} \cite{bizt-rendszerek} A detektálás során a rendszer a +ponton vagy bejárati úton, hanem bármely mozgást [detektáljanak] a megfigyelt +területen.''} \cite{bizt-rendszerek} Az üzem alatt a rendszer a behatolásról vagy mozgásról különböző módon gyűjt információt. Ezt a megvalósításban szenzorokkal teszi, nevezetesen: PIR mozgásérzékelők, ajtó-, ablak nyitásérzékelők, ablak-törésérzékelők. A szenzor által kiváltott behatolás @@ -488,7 +488,8 @@ ablak nyitásérzékelők, ablak-törésérzékelők. A szenzor által kiváltot csatornán. Hagyományosan a rendszer tartalmaz egy szirénát, ami a behatoló elrettentésének funkcióját tölti be. Ez gyakran elegendő ahhoz, hogy elriassza a cselekvőt, amivel a későbbi behatolásra tett kísérleteket megelőzheti, -illetve csökkentheti a behatolás során okozott vagyoni és személyi károkat. +illetve csökkentheti a behatolás során okozott további vagyoni és személyi károk +bekövetkezésének valószínűségét. \cite{bizt-rendszerek} A következőekben definiáljuk a behatolásjelző rendszer komponenseit és végigjárok azok @@ -508,9 +509,8 @@ hatástalanítás-kísérletei ellen, ami akár azonnali riasztást is kiváltha felület a rendszer bizonyos funkcióinak működtetésére. Tipikusan a rendszer élesítése és hatástalanítása ezen a felületen történik. Ebből az egységből egy vagy több is lehet a rendszerben. A kezelő azonosítására alkalmas kell, hogy legyen, hiszen egy -esetleges behatoló (vagy bármilyen nemkívánatos fél) nem befolyásolhatja a rendszer -működését. Az azonosítás vagy egyben a rendszer -hatástalanítása általában egy előre beprogramozott PIN kód megadásával történik. \cite{bizt-rendszerek} +esetleges behatoló (vagy bármilyen nemkívánatos fél) nem válthatja ki a rendszer +hatástalanodását. Az azonosítás általában egy előre beprogramozott PIN kód megadásával történik. \cite{bizt-rendszerek} \\ \textbf{Szirénák}: Hang- vagy fényjelző eszközök, melyek a behatolás pillanatában aktiválódnak. Szerepük kettős; a környék számára ad jelzést, hogy @@ -565,14 +565,16 @@ szenzort helyezünk ugyanarra a célterületre. \end{table} \\ \textbf{Kábelezés vagy rádiókapcsolat}: A központi egységet és az egyes -szenzorokat, kezelőegységeket és a szirénát összeköttető vezetékek vagy vezeték -nélküli kommunikációs csatorna. Szükséges úgy kialakítani a kábelek vezetését, +szenzorokat, kezelőegységeket és a szirénát összeköttető vezetékes vagy +vezeték nélküli kommunikációs csatorna és/vagy tápellátás. Értelemszerűen +vezeték nélküli tápellátás fizikailag nem kivitelezhető -- illetve ennek +kérdésével nem foglalkozunk. Szükséges úgy kialakítani a kábelek vezetését, hogy azt ne lehessen vandalizálni. Hasonlóan, a központi egység helyét úgy kell megválasztani, hogy az ahhoz hozzáférést megelőzze olyan terület, melyet -a rendszer szenzorai figyelnek. A szenzorok legtöbb esetben el vannak látva -vandalizmus elleni védelemmel, mely a szenzor dobozának felnyitására riasztást -vált ki. A védelem egy normál esetben zárt állapotú nyomógombbal valósítható -meg. +a rendszer szenzorai megfigyelés alatt tartanak. A szenzorok legtöbb esetben +el vannak látva vandalizmus elleni védelemmel, miszerint a szenzor dobozának +felnyitása riasztást vált ki. A védelem egy normál esetben zárt állapotú +nyomógombbal valósítható meg. \subsection{Informatikai biztonság} \label{inf-bizt} diff --git a/src/contents/6-tervezes.tex b/src/contents/6-tervezes.tex index 52c2d9b0504947a66a33497f652b48e70817a62e..2c0f06cc69f15a4f6476246e809b891546c2ba2f 100644 --- a/src/contents/6-tervezes.tex +++ b/src/contents/6-tervezes.tex @@ -6,10 +6,10 @@ vetett megkötéseinket figyelembe véve. Miután konkretizáltam a projekt kereteit, a megvalósítandó rendszer tervezésével foglalkozom. A mikrokontroller az ESP32 hardver platfomon, Rust szoftveres környezetben valósul meg. Az okosotthon - integrációhoz a rendszer vezetékes hálózaton MQTT protokollon fog kommunikálni. - A választott technológiákkal ismerkedem és megindoklom - a választásaimat helyesség, biztonság, a fejlesztés kényelmessége és a későbbi - bővíthetőség szempontjai alapján. + integrációhoz a rendszer vezetékes hálózaton MQTT protokollon fog kommunikálni + a Home Assistant okosotthon szoftverrel. A választott technológiákkal ismerkedem + és megindoklom a választásaimat helyesség, biztonság, a fejlesztés kényelmessége + és a későbbi bővíthetőség szempontjai alapján. } \section{Döntések} \label{dontesek} @@ -290,15 +290,16 @@ iratkozhat fel, illetve küldhet üzenetet. A protokoll megköveteli azt az architektúrai elemet, hogy a kliensek között legyen egyetlen szerver, elnevezés szerint a ``broker''. A broker fogadja a kliensek csatlakozási, feliratkozási, üzenetküldési, leválasztási és egyéb kérelmeit. Nyilván tartja a klienseket, -azok jogosultságait és a topic-ok továbbítását végzi. Számos implementációja van -mind kliens oldali és broker oldali szerepeknek. \cite{mqtt-vs-coap} +azok jogosultságait és a topic-on közzétett üzenetek továbbítását végzi. +Számos implementációja van mind kliens oldali és broker oldali szerepeknek. +\cite{mqtt-vs-coap} Az architektúra előnye, hogy a komplex feldolgozás feladata az a broker-re van hagyva és egy kliens működtetése minimális erőforrásokat igényel. További előnye más megoldásokkal szemben, hogy beépített Quality of Service (QoS) megoldást kínál az átvitt üzenetek fogadásának és célba érkezésének garanciájához. A TCP önmaga ilyen garanciát nem tud adni -- csak integritás és rendezettséget -- -illetve csomagok újraküldéssel tud próbálkozni de ez még nem garancia az adott +illetve csomagok újraküldésével tud próbálkozni de ez még nem garancia az adott üzenet célba érkezésére, hiszen alacsonyabb absztrakciós szinten tartózkodik. Ezért ez a feladat magasabb egy szintű protokollra marad. \cite{tcp} Az MQTT három szinten definiál QoS-t: @@ -306,7 +307,7 @@ három szinten definiál QoS-t: \begin{itemize} \item \textbf{QoS 0} (``At most once delivery''): Az üzenetek átviteléről kvázi nincs garancia, tehát itt nincs semmilyen újraküldésre tett kísérlet. - \item \textbf{QoS 1} (``At least one delivery''): Az üzenetküldést jóvá kell hagyni, + \item \textbf{QoS 1} (``At least one delivery''): Az üzenetküldés sikerességét jóvá kell hagyni, ellenben az üzenet újra küldésre kerül. Ez a szint garantálja hogy az üzenet célba fog érni, de lehetséges, hogy többször is. \item \textbf{QoS 2} (``Exactly once delivery''): Az üzenetküldés maga egy @@ -383,25 +384,27 @@ ha nincs mozgás legalább 10 percen át, akkor kapcsolódjon le a lámpa. Az MQTT egy első osztályú integráció a Home Assistantban. Az MQTT minden QoS szintjét támogatja, illetve a többi integrációhoz képest sokkal általánosabb interfészt ad. Ez kimagaslóan jobb élményt ad a végfelhasználó számára, -mert egységes és konzisztens marad a frontend. A fejlesztő számára is jobb +mert egységes és konzisztens marad a frontend. A fejlesztő számára is jobb élmény, mert az intgrációt így nem szükséges a Home Assistant forráskódján át implementálni Pythonban. MQTT-n keresztül lehetőség van entitások és eszközök telepítésére manuális konfigurációval vagy az úgynevezett ``MQTT-discovery'' -segítségével. Mindkét esetben az eszközöknek és entitásoknak van egy deklaratív -leíró sémája, ami tartalmaz meta-adatokat és leírást azok működtetésére. -Manuális konfiguráció esetén ezt a Home Assistantban YAML formátumban kell -megadni, autodiscovery során pedig egy előre meghatározott MQTT topic-on kell -küldeni JSON formátumban a rendszer felé. Látható, hogy az utóbbi esetben -az azt támogató eszköz végfelhasználói onbarding élménye sokkal kényelmeseb. -Például, az eszköz első indítása után az autodiscovery üzenet küldésével a Home -Assistant frontend felületén azonnal látni fog a felhasználó egy jóváhagyandó -üzenetet, hogy az készen áll a használatra. Jóváhagyás után a meghirdetett -entitások importálásra kerülnek a Home Assistantba. \cite{hass-mqtt} Célom úgy -megvalósítani a saját rendszert, hogy az alapból támogassa az autodiscovery-t. -Így \aref{kereskedelmi}. fejezetben megismert DIY rendszereknél is potenciálisan -jobb élményt tudna nyújtani, hiszen a kommunikáció vezetékes médiumon történne, -ahol az Ethernet csatlakoztatásával azonnal a hálózatra kerül az eszköz. Ez -elméletben kényelmesebb, mint például a WiFi konfigurációja. Ennek realitását -szintén a gyakorlatban fogjuk tudni megállapítani. +vagy ``autodiscovery'' segítségével. Mindkét esetben az eszközöknek és +entitásoknak van egy deklaratív leíró sémája, ami tartalmaz meta-adatokat +és leírást azok működtetésére. Manuális konfiguráció esetén ezt a Home +Assistantban YAML formátumban kell megadni, autodiscovery során pedig egy +előre meghatározott MQTT topic-on kell küldeni JSON formátumban a rendszer +felé. Látható, hogy az utóbbi esetben az azt támogató eszköz végfelhasználói +onbarding élménye sokkal kényelmeseb. Például, az eszköz első indítása után +az autodiscovery üzenet küldésével a Home Assistant frontend felületén azonnal +látni fog a felhasználó egy jóváhagyandó üzenetet, hogy az készen áll a +használatra. Jóváhagyás után a meghirdetett entitások importálásra kerülnek a +Home Assistantba. \cite{hass-mqtt} Célom úgy megvalósítani a saját rendszert, +hogy az alapból támogassa az autodiscovery-t. Így \aref{kereskedelmi}. +fejezetben megismert DIY rendszereknél is potenciálisan jobb élményt tudna +nyújtani, hiszen a kommunikáció vezetékes médiumon történne, ahol az Ethernet +csatlakoztatásával azonnal a hálózatra kerül az eszköz, egyúton megjelenne a +felhasználó Home Assistant felületén. Ez elméletben kényelmesebb, mint például +a WiFi konfigurációja. Ennek realitását szintén a gyakorlatban fogjuk tudni +megállapítani. \clearpage % Ez azért kell, hogy nehogy képek átcsússzanak a következő fejezethez diff --git a/src/contents/7-eredmenyek.tex b/src/contents/7-eredmenyek.tex index 79f61944d3a4986b5406f35c7696bdde3ae9b68c..87da737a98c2ce81979a978dc64c74d554dd4c0e 100644 --- a/src/contents/7-eredmenyek.tex +++ b/src/contents/7-eredmenyek.tex @@ -107,9 +107,9 @@ szükséges és kényelmi beállítások. Ezek közül megemlítendő: \end{itemize} Ezek után nekiláttam a perifériák vezérlésének implementálásához. A \verb|main| -függvény valahány utasítása az a perifériák inicializálását végzi, utána az +függvény valahány utasítása a perifériák inicializálását végzi, utána az egyes feladatkörök elindítása több szálon (thread). A legnagyobb kihívás -itt az ethernet vezérlő működésre bírása volt. Ahogy \aref{hardware}. fejezetben +itt az Ethernet vezérlő működésre bírása volt. Ahogy \aref{hardware}. fejezetben is említettem, végül a Wiznet W5500 típusú SPI interfész alapú chip vezérlését kellett implelentáljam. A fizikai réteg inicializálása egyszerűen történik, mely így néz ki a forráskódban: @@ -216,12 +216,13 @@ fn mqtt_task( Az \mintinline{rust}/msg/ változó az MQTT kliens fogadott eseményeit fogja tartalmazni, ami lehet a csatlakozás esemény, lecsatlakozás esemény, -feliratkozott topic-ra érkezett üzenet. A \mintinline{rust}/handle_mqt_message/ +feliratkozott topic-ra érkezett üzenet. A \mintinline{rust}/handle_mqtt_message/ függvény kezeli a beérkezett üzeneteket feliratkozott topic-ra. Az eszköz -lényegében egyetlen dologra kíváncsi: a firmware frissítésre -- Over the -Air Update (OTA). Ezt egy erre dedikált MQTT topic-on tudja megkapni, az új -firmware tartalmát ide lehet publikálni bináris formátumban. Ennek a kezelése a -legbonyolultabb az egész firmware kódjában -- nem is az alapfeladat része, így +lényegében két dologra kíváncsi: a rendszer élesítése/hatástalanítás +műveleteire, illetve a firmware frissítésre -- Over the Air Update (OTA). Az +üzeneteket az ezekre dedikált MQTT topic-on tudja megkapni szövegesen, és az új +firmware tartalmát ide lehet publikálni bináris formátumban. Az utóbbi kezelése +a legbonyolultabb az egész firmware kódjában -- nem is az alapfeladat része, így csak egy kivonatát mutatom itt be: %TC: ignore @@ -474,13 +475,14 @@ Lényegében három dolog történik: (alarm panel és mozgásérzékelők) a segéd struktúrákkal, majd JSON formátumba konvertáljuk, és azonnal el is küldjük a Home Assistant számára az autodiscovery protokoll szerint. \item Az entitások elérhetőségét (availability) egyetlen közös topic-ra állítottuk az előző lépésben (hiszen mindegyik - a központi egység elérhetőségétől függ), így egyetlen üzenetet kiküldve ``online'' állapotba hozzuk. + a központi egység elérhetőségétől függ), így egyetlen üzenetet kiküldve ``online'' állapotba hozzuk. Ha + az entitás rendelkezik az annak vezérlésére alkalmas topic-kal (alarm panel), arra feliratkozunk. \item Feliratkozunk a firmware frissítés (OTA) topic-jára -- melynek működését láttuk az előző fejezetben. \end{enumerate} -Ezzel még nem vagyunk kész, hiszen a szenzorok állapotát még nem küldjük és a -riasztópanel parancsait még nem fogadjuk. Ezek implementációját így oldottam -meg: +Ezzel még nem vagyunk kész, hiszen a szenzorok állapotát még nem küldjük és +a riasztópanel parancsait még nem dolgozzuk fel. Ezek implementációját így +oldottam meg: \noindent\extlink{https://github.com/akosnad/rusty-esp-alarm/blob/1d3073a0cbd3b98af0f6a14bdf625732938f78e2/src/scheduler.rs\#L168}{scheduler.rs} \begin{minted}[linenos,firstnumber=168]{rust} @@ -566,12 +568,12 @@ hosszútávú tesztelésre. A dolgozat írásakor a rendszer nagyjából 8 hóna \begin{itemize} \item Az első 2 hónap alatt ha elég sokáig futott a firmware (nagyjából 4-5 nap hossza), hirtelen nem reagált semmire. A hiba egy deadlock - szituációból adódott, melyet kijavítottam. A hiba bekövetkezése és az eltelt idő látszólagos + szituációból adódott. A hiba bekövetkezése és az eltelt idő látszólagos korrelációja valójában hamis volt, mert a deadlock bekövetkezéséhez két eseménynek kellett egyszerre történnie: a riasztó élesedése és egy mozgásérzékelő jelet észlelése. Javítás után a hiba nem jelentkezett többször. \item Az MQTT broker leállása és újraindulása után a firmware nem csatlakozott - újra, így használhatatlan maradt a manuális újraindításig. Ez azért volt, + újra, így használhatatlan maradt a manuális újraindításig. Ez azért jelentkezett, mert csak az Ethernet link megszakadását kezeltem le. Ha a link sértetlen maradt, és csak a socket szakadt meg, azt figyelmen kívül hagyta az implementáció. Javítás után teszteltem a hibatűrést. @@ -580,11 +582,12 @@ hosszútávú tesztelésre. A dolgozat írásakor a rendszer nagyjából 8 hóna is képes volt visszacsatlakozni az eszköz. A hibát kijavítottnak tekintettem. \end{itemize} -Összesítve a hibák sűrűsége alacsony volt, de azok kritikusak. Itt látszik jól -a Rust erőssége és az aranymondás róla igazolódik: \textsl{``Ha a kód lefordul, - akkor biztos lehetsz benne, hogy az úgy működni fog.''} \cite{rust-compiles-1} -\cite{rust-compiles-2} \cite{rust-compiles-3} Bizonyos keretekig ez az állítás -igaz; a fordító garantálja azt a működést amit enged, hogy leforduljon. Azt, -hogy a programozó logikai hibát vétett, azt már nem tudja kijavítani helyette. +Összesítve a hibák sűrűsége alacsony volt, de azok kritikus logikai hibák. Itt +látszik jól a Rust erőssége és az aranymondás róla igazolódik: \textsl{``Ha + a kód lefordul, akkor biztos lehetsz benne, hogy az úgy működni fog.''} +\cite{rust-compiles-1} \cite{rust-compiles-2} \cite{rust-compiles-3} Bizonyos +keretekig ez az állítás igaz; a fordító garantálja azt a működést amit enged, +hogy leforduljon. Azt, hogy a programozó logikai hibát vétett, azt már nem tudja +kijavítani helyette. \clearpage % Ez azért kell, hogy nehogy képek átcsússzanak a következő fejezethez diff --git a/src/contents/8-osszefoglalas.tex b/src/contents/8-osszefoglalas.tex index 1bbcdc13aac993ba2a612b70ab034bc905c21de5..8731c3abf2317a3f04baabcfe6fb5e9eafb11836 100644 --- a/src/contents/8-osszefoglalas.tex +++ b/src/contents/8-osszefoglalas.tex @@ -4,7 +4,8 @@ \chapterintro{ Az utolsó fejezetben refletálok a dolgozat kitűzött céljára az eredmények - fényében. A projekt továbbhaladásához kifejtem a következő lépéseket. + fényében. A projekt továbbhaladásához kifejtem a következő lépéseket és + visszatekintek a szerzett tapasztalatokra. } \section{Feladat} @@ -14,7 +15,7 @@ \item Megismerkedtem a biztonságtechnika alapjaival, melyről \aref{bizt-kerd}. fejezetben írtam le a szükséges megszerzett tudást. \item Kiválasztottam kereskedelmi riasztórendszereket (\ref{tab:analyzed-systems}. táblázat), - melyek architektúrai felismerését megismertem (\ref{kereskedelmi-arch}. fejezet). Összevetettem + melyek architektúrai felépítését megismertem (\ref{kereskedelmi-arch}. fejezet). Összevetettem azok integrációs lehetőség (\ref{kereskedelmi-integralhatosag}. fejezet), gazdasági elköteleződés (\ref{koltseg}. fejezet), megbízhatóság és felhasználói élmény (\ref{kereskedelmi-megbizhatosag}. fejezet) szempontjai alapján. Az eredményeket \aref{tab-kereskedelmi-osszesites}. táblázatban gyűjöttem össze. @@ -45,6 +46,22 @@ következtetést kell levonnom, hogy a jövőben több kutatást kell végeznem az adott hardverről, és több alternatívát is érdemes összehasonlítani a megválasztás előtt, hogy biztos lehessek annak megbízhatóságában. +\section{Jövőbeli tervek} +\label{jovo} + +\paragraph{} A megvalósított rendszer egy stabil alapot biztosít további +fejlesztésekhez. A jövőben szeretném a funkcionalitást bővíteni például +többféle érzékelő támogatásával, mint ajtó- és ablaknyitás-érzékelők és egyéb +szenzorok integrálásával minél általánosabb módon. Hosszútávú terveim között +szerepel a rendszer eseménykezelésének finomítása, például riasztási prioritások +és naplózási funkciók bevezetése, valamint egy önálló webes felület ezek +megtekintésére és a szenzorok konfigurálására. + +A dolgozaton túl az első célom, hogy a rendszer támogassa az érzékelők zónákba +sorolását, valamint az egyes zónák önálló élesítését és hatástalanítását. Ezzel +lehetőség nyílna például csak bizonyos területek védelmére, miközben a ház más +részei szabadon használhatók maradnának. + \section{Személyes tapasztalatok} \paragraph{} A dolgozat elkészítése során számos új ismerettel gazdagodtam @@ -67,18 +84,12 @@ fejlesztési projekteket. Összességében a dolgozat elkészítése rendkívül és motiváló tapasztalatot jelentett számomra, amely tovább erősítette az érdeklődésemet a beágyazott rendszerek és a biztonságtechnika iránt. -\section{Jövőbeli tervek} -\label{jovo} +\section{Köszönetnyilvánítás} -\paragraph{} A megvalósított rendszer egy stabil alapot biztosít további -fejlesztésekhez. A jövőben szeretném a funkcionalitást bővíteni például -többféle érzékelő támogatásával, mint ajtó- és ablaknyitás-érzékelők és egyéb -szenzorok integrálásával minél általánosabb módon. Hosszútávú terveim között -szerepel a rendszer eseménykezelésének finomítása, például riasztási prioritások -és naplózási funkciók bevezetése, valamint egy önálló webes felület ezek -megtekintésére és a szenzorok konfigurálására. - -A dolgozaton túl az első célom, hogy a rendszer támogassa az érzékelők zónákba -sorolását, valamint az egyes zónák önálló élesítését és hatástalanítását. Ezzel -lehetőség nyílna például csak bizonyos területek védelmére, miközben a ház más -részei szabadon használhatók maradnának. +\paragraph{} Köszönöm mindazoknak akik lehetővé tették vagy segítették a +munkámat, első sorban szüleimnek a támogatást és a lehetőséget arra, hogy +otthonomban tudtam a projektet hosszú távon üzemeltetni. Köszönöm Tihanyi +Attila Tanár Úrnak, egyben témavezetőmnek a szerteágazó tudását és szakértelmét. +Nemcsak inspirációt adott a hardver világához, hanem a mérnöki gondolkodásomat +alakította ki. Köszönöm a barátaimnak a kitartó jelenlétüket mellettem, akik +végig kísértek a tanulmányaim során.