Rubin SPIRIT TEST. Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0. Készítette: Hajnali Krisztián Jóváhagyta: Varga József

Átírás

1 Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0 Készítette: Hajnali Krisztián Jóváhagyta: Varga József Rubin Informatikai Zrt Budapest, Egressy út telefon: ; fax: web:

2 1 A firmware és hardver tesztelés bemutatása 1.1 Hardverek fejlesztése Részlegünk 10 éve fejleszt hardvereket különböző szintű összetételben. A hardverpiac erősödő igénye a hardver termékek moduláris felépítésére vonatkozóan azt eredményezte, hogy egy-egy készülék 5-10 kártyát is tartalmazhat, azonban ezek tesztelése jelentős időt vesz igénybe. A mikrokontrollert, processzort tartalmazó kártyák működtető programot (firmware) is tartalmaznak, amiben számos funkció működéséért felelős. A fejlesztés során ellenőriznünk kell a kártyák működőképességét, a firmware megbízhatóságát, majd a gyártás beindítása után az egyes kártyák megfelelő működését (bemérés). A korábbi módszer szerint a firmware funkciókat egy előre összeállított és folyamatosan bővülő táblázat alapján kézzel próbáltuk ki, a bemérést vagy kézzel, vagy ha a hardver lehetővé tette, akkor a hardverben önmagában futó bemérő firmware segítségével végeztük a rendelkezésre álló be és kimenetek segítségével. Mikrovezérlőt nem tartalmazó áramkör esetén csak a kézi bemérés volt megvalósítható. A fenti black-box tesztelések hatékonyságát jelentősen sikerült javítanunk. 1.2 Tesztek automatizálása Az áramkörök számának növekedésével szükségessé vált a firmware tesztelés és a bemérés automatizálása, amit egy hardver- és szoftverelemekből álló rendszerrel oldottunk meg. A hardverelemek a tesztelendő áramkörre csatlakoznak, a számítógépen a futó szoftverelemek pedig a hardverelemeken keresztül végeznek vezérlést vagy ellenőrzést. 1. Hardver elemek Kifejlesztettünk egy univerzális kártyát (RTESTER MODULE), ami tartalmaz egy mikrokontrollert az abban futó firmware-rel. A firmware fel van készítve arra, hogy rendszer szoftverelemeivel kommunikáljon, a kontroller általános célú portjait pedig kivezettük a csatlakozó pontokra. Ezzel létrejött egy olyan hardvermag, ami könnyen csatlakoztatható egy az adott hardverhez tervezett alaplap kártyához. A modul mérete 95x35mm. Oldal 2 / 5

3 Az új fejlesztésű hardverek esetén szükséges egy alaplapkártya tervezése a tesztelt firmware funkcióknak és a bemérésnek megfelelő követelményekkel. Az RTESTER MODULE ebbe az alaplapba csatlakozik. A hardverek felépítése teljesen egyedi lehet, ezért szükséges minden új hardvernél alaplap fejlesztése és gyártása. Kivételt jelenthet egy kártyacsalád, illetve adott kártya újabb verziója, ilyenkor nem mindig szükséges új alaplapterv. A tesztelő készletet (RTESTER MODULE és a kártyának megfelelő alaplap) célszerűen egy mechanikai szerkezetbe építjük, ennek kivitele az adott kártya méreteiből adódik. Az alkalmazásnak megfelelően szükség lehet érintésvédelemre, ez így szintén megoldható, ilyenkor a fedél kinyitásával tápelvétel történik. Néhány elkészült bemérő szett az alábbi képen látható: 2. Szoftver elemek A hardver elemek eléréséhez létrehoztunk egy szoftver keretrendszert, ami python programozási nyelvet használ, ez egyaránt futtatható Windows és Linux operációs rendszereken. A keretrendszer alkalmas az RTESTER MODULE-lal történő kommunikációra. Mikrokontrollert tartalmazó kártyák esetén előfordulhat, hogy a tesztelendő kártya közvetlenül megszólítható, a keretrendszer erre is nyújt megoldást az eszközvezérlő objektumok használatával. Amennyiben az adott feladatra nem létezik eszközvezérlő, akkor a keretrendszer bővítése, fejlesztés szükséges. A jelenleg használható eszközvezérlők: RTESTER MODULE kezelő (digitális be, kimenetek kezelése, analóg mérés, i2c kezelés), UserInterface (kérdések, figyelmeztetések kezelése), SNMPManager (SNMP lekérdezések, beállítások kezelése) Oldal 3 / 5

4 1.3 Teszttervezési fázis A tesztelés tervezését a hardverfejlesztés kezdetekor végezzük, hiszen a firmware funkciók és a bemérési funkciók megkövetelik a kártyát kezelő teszthardver elkészítését. Mivel saját tervezésű berendezéseink teszteléséről van szó, ezért a white-box teszt tervezési metódussal élünk. Egyszerűbb kártyák esetén akár az élesztés is elvégezhető a tesztelő-hardver segítségével. A teszteléshez a következő tervek születnek: alaplapkártya fizikai terv (NYÁK) firmware teszt terv (ha a kártya tartalmaz firmware-t), amiben a teljes tesztfolyamat szerepel bemérési terv (hardveres összeköttetések leírása és folyamat) 1.4 Tesztek fejlesztése A létrejött tervek alapján a tesztek fejlesztése megkezdődik, ez tesztesetek programozását jelenti python rendszerben. Minden a tervben szereplő esetet külön el kell készíteni, ez történhet a hardverfejlesztésével egy időben vagy azt követően. Miután a hardver elkészült (tesztelő hardver és a tesztelendő hardver) a teszteket ellenőrizzük, esetleg módosítjuk. 2 Tapasztalatok Az automata tesztek bevezetése a megbízhatóságot jelentősen növelte, és a folyamat lényegesen rövidebb időt vesz igénybe. A fejlesztési költségek magasabbak, de sorozatban gyártott kártyák esetén mostanra elengedhetetlen a tesztrendszer elkészítése. A gyakorlatban az eddig elkészített összes firmware teszt talált hibát a programban az előzetesen elvégzett kézi tesztek ellenére is. A bemérések gyorsabbak és nem szükséges hozzáértők alkalmazása a feladat elvégzésére. Ezek az előnyök a korábbi magas költségek megtérülését eredményezték. A tesztek bevezetését az RDOOR nevű beléptető egységgel kezdtük, ahol több firmware verzió folyamatos fejlesztése mellett volt szükség a tesztelésre. A korábbi módszer szerint egy táblázatban definiált tesztsorozatot hajtottunk végre manuálisan. A tesztsorozat 170 pontot tartalmazott, a folyamat időigénye 1 nap volt. Bármilyen hiba észlelése esetén az összes tesztet újra el kellett végezni a működés ellenőrzéséhez, így a tesztelésre fordított idő akár egy hetet is igénybe vehetett. Az RTESTER rendszer bevezetésével a korábbi módszerhez képest a teljes teszt lefutása emberi erőforrás igénybevétele nélkül 60 percet vett igénybe, ami a korábbi érték 12,5%-a. Az RDOOR tapasztalatok alapján ma már minden sorozatban gyártott termékhez készítünk célhardvert és automata teszteket, a legutóbb fejlesztett RUBICON USB-IO-MULTI kártya firmware fejlesztése során is ezt a módszert használtuk. A bemérő elkészülte előtt a prototípus firmware tesztelése 1 napot vett igénybe, az RTESTER rendszer használatával az idő 7 percre csökkent. Bemérés esetén a vizsgálat korlátozódik a hardver elemekre, ilyenkor bevált gyakorlat, hogy a firmware tesztek szűkítésével készülnek a bemérést végző tesztek. Egy manuális bemérés ennél a kártyánál 1 órát vesz igénybe, az új módszer pedig kártyacserével együtt 3 percet. Oldal 4 / 5

5 3 Tesztek további felhasználása A fejlesztés során elkészített tesztek sok időt takarítanak meg a firmware változtatása vagy a hardvermódosítások során. A változtatás időigénye csekély, míg az eddigi megbízható működés megmarad. Az elkészült naplófájlok tesztelési, illetve bemérési jegyzőkönyvként szolgálnak. Oldal 5 / 5