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 bemutatása, védés:  december 7.

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.)