Házi feladat (Kiberfizikai rendszerek)

Házi feladat

A házi feladat egy elképzelt „okos” egyetem felügyeleti rendszere egy komponensének kidolgozása: specifikáció, tervezés, prototípus készítése. A feladat során az egyetem termeiben (vagy terem modelljében) elhelyezett szenzorok, illetve külső adatforrások segítségével kell egyszerűbb beavatkozásokat végezni a munkavégzésre alkalmas klíma és az energiatakarékosság biztosítása érdekében.

A rendszernek tartalmaznia kell legalább egy helyi, valamint legalább egy felhőben futtatott komponenst (és ezek kommunikációját) is, a funkciók komponensekhez rendelése része a feladatnak. A minimálisan a felhőben megvalósítandó funkciókkal kapcsolatban az egyéni feladatkitűzésben megkötésekkel élünk. A konkrét feladatok személyre szólóak, itt csak a közös információkat szedtük össze. Az egyes feladatok jellegétől függően az elkészítendő prototípusnak vagy egy valódi tanteremet kell fizikai környezetként használnia, vagy pedig egy makettet (tulajdonképpen egy kis üvegházat vezérelhető ablakokkal, fűtéssel, szellőztetéssel). A makettnek a vezérelhetőség mellett fontos jellemzője a kisebb fizikai tehetetlensége is, amely bizonyos jellegű feladatoknál szükséges a prototípus bemutatásához.

A házi feladatnak része (többek között):

  • A feladatkitűzésben meghatározott funkcióval kapcsolatos követelmények összegyűjtése és rendszerezése, majd finomítása. Ehhez -- ugyanúgy mint a valós projekteknél -- szükség lehet a megrendelő (ez esetben az oktatók) kikérdezésére, a követelményfinomítás során felmerülő részletek tisztázására. Ezt megtehetik személyesen az előadások és gyakorlatok környékén, vagy emailben.
  • A kitűzött feladatban szereplő szenzor és esetleges beavatkozó(k) kezelése. A szenzorokat és beavatkozókat a tanszék biztosítja, beüzemelésük a hallgató feladata. (Kérdezni szabad.)
  • A kiberfizikai rendszerekben általában szükség van a fizikai rész fizikai, szabályozástechnikai modellezésére. Ennek a modellnek az elkészítése, paraméterezése és határértékeinek meghatározása is része a feladatnak.
  • A kitűzött feladatban szereplő külső, felhőben megvalósítandó adatforrások használata. Általános célű adatforrások esetén (pl. időjárás) a feladat része egy meglévő nyilvános (ingyenes) szolgáltatás keresése és használata. Speciálisabb adatforrások esetén (pl. órarend) a bemutatandó prototípushoz elegendő egy szabványos webes technológiákkal elérhető saját adatforrást létrehozni, majd azt mintaadatokkal feltölteni.

A házi feladattal kapcsolatban ezen az oldalon folyamatosan publikálni fogunk további információkat.

Beadási határidők

Specifikáció, követelmények:  szeptember 28.

Architektúra, rendszerterv:  november 2.

Prototípus beadása:  december 10.

Pótbeadás: Díjköteles pótbeadási lehetőségre jelentkezni e-mailben lehet Huszerl Gábornál. Pótbeadásra csak a pótlási héten van lehetőség.

Válaszok hallgatói kérdésekre

  • Az első határidőre csak a ReqIF Studio projektjét kérjük leadni egy ZIP-fájlba csomagolva. Ne írjanak más Excel fájlokba vagy szövegfájlokba, minden menjen a .reqif fájlokba.
  • A ReqIF Studio hibája miatt a .reqif fájlok közötti linkek elvesz(het)nek mentéskor/visszatöltéskor. Ezért legyenek szívesek az ilyen linkeket kézzel dokumentálni a TestCase mezőbe. (A Link mezőbe nem tudnak írni.) A linkek szöveges jelölése legyen egyértelmű, hivatkozásnál használják a követelmények ID-ját. A TestCase mezőben így hol linkek lesznek, hol teszt esetek (hol mindkettő). Ez nem jó, de a ReqIF Studio hibáját így tudjuk legegyszerűbben megkerülni.
  • A tovább nem finomított követelményekhez írjanak teszt eset(ek)et Gherkin nyelven a TestCase mezőbe.
  • A "Realization" fejezetekbe most nem kell írni semmit. Az általános követelmények (pl. funkcionális vagy teljesítmény/időzítés jellegűek) menjenek a Conceptualization fejezetbe, a megbízhatósági jellegűek az Assurance fejezetbe. (A megbízhatósági jellegű követelmények sokszor kicsit "kilógnak" a többi közül, így külön fejezetben egyszerűbb kezelni őket.)

 Kiadott adatok (terem és egy épületen kívüli mérőpont):

  • Time - időbélyeg
  • DHT_temp - DHT szenzor által mért hőmérséklet a teremben
  • DHT_Humidity - DHT szenzor által mért levegő nedvesség a teremben
  • Light - fényerősség a teremben
  • Ozone - Levegő ózon koncentrációja a teremben
  • Methane - Levegő metán koncentrációja a teremben
  • Smoke - Füst érzékelő a teremben
  • Dust - Levegőben szálló por mennyisége a teremben
  • Move - Mozgásszenzor (átlagolt 10 percre, a teremben)
  • Noise - Zaj (átlagolt 10 percre, a teremben)
  • BMP_Temp - BMP hőmérséklet szenzor a teremben
  • BMP_Pressure - BMP nyomás szenzor a teremben
  • Temp - Külső hőmérséklet (meteorológiai szolgálat által szolgáltatva, külső adatforrás)
  • Dew_Point - Harmatpont (meteorológiai szolgálat által szolgáltatva, külső adatforrás)
  • Humidity - Levegő nedvességtartalma (meteorológiai szolgálat által szolgáltatva, külső adatforrás)
  • Pressure - Légnyomás (meteorológiai szolgálat által szolgáltatva, külső adatforrás)
  • Wind_Speed - Szélsebesség (meteorológiai szolgálat által szolgáltatva, külső adatforrás)
  • O3 (NO, NO2, NOX) - Levegő ózon (és egyéb, nitrogén-monoxid, nitrogén-dioxid és nitrogén oxidok) koncentrációja (meteorológiai szolgálat által szolgáltatva, külső adatforrás)

A hőmérséklet adatok mértékegysége Celsius fok, a légnedvesség %-ban értendő, a légnyomás hPa, harmatpont Celsius fok, külső adatforrás esetén az ózon, NO, NO2, NOX mértékegysége ug/m3.

CO2 adat nincsen a kiadott készletben, helyette használják a "Smoke" adatokat. Ezek mértékegységgel nem jellemzett értékek 0 és 1024 között.

Beüzemelt adatforrások a prototípusokhoz

Terem adatok

A DDS kommunikációban használt adatstruktúra leírása letölthető innen. (A fájlt kérjük UvegHaz.idl néven elmenteni, a kiterjesztése technikai okokból hamis.) Ugyanezen fájlnak volt egy korábbi, hibás verziója, ne azt használják, abban "//key" szerepel "//@key" helyett a megfelelő helyen. Ha a régi IDL fájlból dolgoztak, akkor generálják újra a megfelelő fájlokat az újjal, de a saját kódjukhoz nem kell nyúlniuk emiatt.

A használt domain ID: 1

A használt topicok: A fenti felsorolás minden eleme külön topicon kerül publikálásra ("DHT_temp", "DHT_Humidity", "Light", "Ozone", "Methane", "Smoke", "Dust", ... nevű topicok). Az ID minden esetben "0", a Value a mért érték, a TimeStamp a mérés időpontja.

Üvegház adatok

A DDS kommunikációban használt adatstruktúra leírása letölthető innen. (A fájlt kérjük UvegHaz.idl néven elmenteni, a kiterjesztése technikai okokból hamis.) Ugyanezen fájlnak volt egy korábbi, hibás verziója, ne azt használják, abban "//key" szerepel "//@key" helyett a megfelelő helyen. Ha a régi IDL fájlból dolgoztak, akkor generálják újra a megfelelő fájlokat az újjal, de a saját kódjukhoz nem kell nyúlniuk emiatt.

A használt domain ID: 0

A használt topicok:

  • "temp": Az üvegház csak írja, a hőmérséklet szenzorok értékét publikálja. Az ID "temp0", "temp1", "temp4", "temp5", "temp6", temp7", "temp8", "temp9", "temp10", "temp11", "temp12" és "temp13" is lehet, mind a 12 szenzor értéke rendszeresen frissül.
  • "brightness": Az üvegház csak írja, a fényszenzorok értékét publikálja. Az ID "light0" és "light1" is lehet, mindkét szenzor értéke rendszeresen frissül.
  • "humidity":  Az üvegház csak írja, a páratartalom szenzorok értékét publikálja. Az ID "humidity0" és "humidity1" is lehet, mindkét szenzor értéke rendszeresen frissül.

 

  • "heater": Az üvegház olvassa és írja is, a fűtőelemekhez kapcsolódik.
    • Az üvegház olvasáskor "getheater" és "setheater" ID-kre számít. "getheater" esetén a Value nem számít, viszont az üvegház publikál egy "heater" ID-jű példányt ugyanezen a topicon "0" Value értékkel (ha a fűtés nem megy) vagy "1" Value értékkel (ha megy). "setheater" esetén a Value értékétől függően bekapcsolja a fűtést (ha a Value "1") vagy kikapcsolja (ha a Value "0").
    • Az üvegház csak a fent leírt esetben írja ezt a topicot egy "heater" ID-jű példánnyal.
  • "lamp": Az üvegház olvassa és írja is, a fűtőlámpákhoz kapcsolódik.
    • Az üvegház olvasáskor "getlamps" és "setlamp1", "setlamp2", "setlamp3" ID-kre számít. "getlamps" esetén a Value nem számít, viszont az üvegház publikál négy példányt ugyanezen a topicon "lamp0"-"lamp3" ID-kkel 0-63 közötti Value értékkel (0 a kikapcsolt állapot, 63 a teljes fényerő. A "lamp0" mindig 0, mert nem létezik, csak a vezérlése van meg, de nincsen mit felkapcsolni). "setlamp1", "setlamp2" és "setlamp3" esetén a Value értékétől függően kapcsolja az adott lámpát, 0-ra kikapcsolja, 63-ra teljesen felkapcsolja, a köztes értékekre arányos csökkentett fényerőre kapcsolja. (A "setlamp0" ID-re nem reagál az üvegház.)
    • Az üvegház csak a fent leírt esetben írja ezt a topicot "lamp0", "lamp1", "lamp2" és "lamp3" ID-jű példányokkal. 
  • "window": Az üvegház olvassa és írja is, az ablakokhoz és a ventillátorhoz kapcsolódik.
    • A fenti logika szerint kérdezni "getwindow1" és "getwindow2" ID-jű példányok publikálásával lehet, erre "window1" vagy "window2" ID-jű példányok írásával válaszol, "0" Value a zárt ablakot jelenti, "1" Value a nyitottat. "setwindow1" és "setwindow2" nyitja (ha a Value "1"), zárja (ha a Value "0") a megfelelő ablakot. "setvent" ID-jű példány írásával lehet a ventillátort indítani (Value "1"), leállítani (Value "0"). A ventillátor állapota nem kérdezhető le.

 

  • "blinder": Az üvegház csak olvassa, az árnyékoló zárható/nyitható vele. Ha az ID "so", akkor nyitja, ha az ID "sc", akkor zárja az árnyékolót. A Value értékét nem figyeli.

A TimeStamp minden esetben a mérés időpontja.