4 Eredményes fejlesztés, biztonság, tesztelés Az eredményes fejlesztés szabályai A jó szoftver alapja, különösen nagyobb rendszereknél a jó architektúra. A jó szoftverstruktúra tulajdonságai: Modularitás HW topológia elfedése A kódírás szabályai Kommentárok, dokumentáció generálása Az architektúra megadja a rendszer komponensekre bontását, a komponensek vezérlési és kommunikációs kapcsolatait. A komponensek kialakításakor célszerű a nagyfokú újrafelhasználhatóságra törekedni. Nagyon elterjedt a rétegekre bontás módszere is. Ennek során általában kialakításra kerül egy a tényleges hardver eszközöket elfedő réteg (Hardware Abstraction Layer) amin keresztül érhetjük el a memória tartományokat, portokat, perifériákat, kommunikációs csatornákat. Ha azt a réteget jól sikerül kialakítani, akkor könnyű, gyors, biztonságos lesz a hardver változásainak követése, például processzor csere. Az egyes szabványosított rendszerekben ez a réteg pontosan definiálva van, sokszor maguk a processzorgyártók szállítják. A 2011-es japán földrengés és cunami alatt nagy gyártó kapacitások is megsemmisültek. Sok nagy cég küszködött azzal, hogy a piac megtartása miatt nagyon gyorsan átállítsa termékeit egy fellelhető processzorváltozatra. Azok akik strukturált architektúrát alkalmaztak hónapok alatt ár tudtak állni, mialatt más cégeknél ez egy éves program volt. Szokásos kialakítani még egy szerviz réteget is, ahol a rendszer az alkalmazások számára biztosít szolgáltatásokat, kommunikációs protokollokat, hibatárolást és adminisztrációt, a watch dog kezelést, stb. Ennek alkalmazásával maguk az alkalmazások szabványosított módon veszik igénybe a szolgáltatásokat, így könnyen hordozhatók a projektek között. Például ha egy alkalmazásnak CAN kommunikáció helyett Ethernet kommunikációra kell átállnia, akkor ehhez csak a szerviz réteg konfigurációján kell változtatni, magán az alkalmazáson nem. Hogy egy üzenet hogyan darabolódik fel csomagokra, hogyan áll össze a válasz, ezt az alkalmazásnak nem kell figyelembe venni. Ha többen programozunk komplexebb rendszert, ahol számolunk a későbbi továbbfejlesztéssel is, érdemes szigorú programozási szabályokat lefektetni, hogy könnyen értelmezhető legyen mindenki kódja mindenki számára. A szabályok rögzítik a névkonvenciókat, a programozási stílust (tabulálás, sorokra bontás, kommentárok szabályai), az alkalmazható megoldásokat. Ezek a szabályok elemző eszközökkel és review-ekkel hatékonyan ellenőrizhetők és betartathatók. A kódot mindig sok kommentárral lássuk el, szerintem, ha egy mód van rá mindig angol nyelven. Érdemes arra is gondolni, hogy legyen lehetőségünk a dokumentáció generálására is, ezért definiált tag-ekkel írhatjuk le kommentárokban az egyes funkciók célját, paramétereit, a szerzőt, és a változtatások történetét. Így csökkenthető a dokumentálásra fordítandó idő, és mindig aktuálisak lesznek a leírt információk. A biztonság kérdései A beágyazott szoftverek kapcsán mind hangsúlyosabban vetődnek fel a biztonság kérdései. Ezek a rendszerek egyre több helyen, így egyre kritikusabb helyeken veszik át a szerepet a mechanikus rendszerektől, és sokszor úgy, hogy a rendszerben nincs már olyan mechanikus komponens, ami garantálná a biztonságot, így a szoftvernek önmagában kell megtenni ezt. 1. oldal evosoft Hungary Kft. Ügyvezető igazgató: Társaság székhelye: Budapest Banki kapcsolat: Kaposvár utca 14-18. Ekkehard Reuß Cégjegyzék: 01-09-367139 UniCredit Bank Hungary Zrt. H 1117 Budapest Dr. Várady Péter Fővárosi Törvényszék Cégbírósága 10918001-00000024-97520003 sales@evosoft.com Nagy Péter USt-IDNr. 12006883-2-43
A legfontosabb módszerek erre: A biztonságos üzemmód meghatározása - nincs abszolút biztonság Párhuzamosság Ellenőrzés modellszámításokkal Futás ellenőrzés Öntesztelés, öndiagnosztika A biztonságnak nincs abszolút jó megoldása, mindig csak a teljes rendszerműködés ismeretében lehet a biztonság és megbízhatóság kompromisszumában optimális megoldást találni. Vegyünk, mondjuk egy mozdonyt. Itt értelmezhetjük úgy elsőre a biztonság követelményét, hogy bármilyen hiba, például a motor túlmelegedése esetén, leállítjuk az üzemet. De szeretnénk-e egy olyan repülőn ülni, amit hasonló szoftver vezérel? Itt alapvető követelmény, hogy akár a technika károsodása árán is fenntartsuk a tolóerőt mindaddig, míg a repülés folyik. De térjünk vissza a mozdonyunkhoz. Vajon egy fékezési folyamatot is meg szabad szakítani egy túlmelegedés vagy más hiba miatt? 1993 a Lufthansa LH2904-es Airbus repülője Varsóban próbált leszállni esős szeles időben. A gép a nedves kifutópályán nem tudott fékezni, túlfutott, kigyulladt. forrás: AirDisaster.com A vizsgálat megállapította, hogy a rosszul értelmezett biztonság miatt a fék teljesítmény csak akkor épült fel, ha mindkét futóművön legalább 12 tonna terhelés volt, és a kerék forgott. A szeles időben viszont a gép sokáig egy kerékkel ért csak talajt, és a kerék sem forgott megfelelően a vizes felületen. Így a jármű csaknem fékezés nélkül szaladt a környező erdőbe. A vizsgálat megállapította, hogy a helytelenül értelmezett biztonsági szabályok is okozói voltak a balesetnek, és a fékezés megkezdésének határértékét például 12 tonnáról 2 tonnára módosítatta. Jól látható, hogy a biztonság az alkalmazási terület, és azon belül is az üzemmód függvénye lehet. A másik szempont a biztonság, kontra rendelkezésre állás kérdése. Lehet egy rendszer nagyon biztonságos, ami szíre-szóra leáll, de egy idő után a pokolba kívánja majd mindenki. Elvárjuk a szoftverünktől, hogy az adatokat értékelje, hihetőségüket megvizsgálja, és csak a szükséges intézkedéseket hozza meg. Kezdjük mindjárt a bejövő értéket szűrésével, formázásával. Ha van rá lehetőség, a lassabban változó jeleket többször olvassuk be, képezzünk mozgó átlagot, egy kiugró értékre ne reagáljon azonnal a szoftverünk. Végezzünk hihetőség vizsgálatot is, ha például a hűtővíz hőmérséklete másodpercen belül több tíz fokot emelkedik, miközben minden más paraméter normális és a hűtővíz szintje sem csökken vészesen, valószínűleg az érzékelő lesz csak hibás. Persze jelezzük és naplózzuk a hibát, de nem kell mindjárt leállni. Különösen, ha van más hűtőközeg is, mint mondjuk egy belsőégésű motor esetén a motorolaj, akkor ha annak normális a hőmérséklete, valószínűleg a víz sem forr még. Úgynevezett helyettesítő értéket képezhetünk a tapasztalat alapján, például mondhatjuk, hogy a víz hőmérséklete 20 fokkal kevesebb az olaj hőmérsékleténél, és ezt az értéket jelentheti a program a továbbiakban a rendszer felé.
A biztonság növelésének bevett módja a párhuzamos végrehajtás mind a szoftverben, mind a hardverben. Ha a két helyen, vagy két módon számított eredmény adott határon belülre esik, érvényesnek fogadjuk el. Egy másik ellenőrzési lehetőség, hogy a mért értékeket egy fizikai modell alapján számított értékkel hasonlítjuk össze, így ellenőrizve azok hihetőségét. A vezérlők működőképességét ellenőrizhetjük watch dog áramkörökkel, illetve a kritikus rutinokba beépített szoftveres szemaforokkal. Ha adott időn belül nem történik meg az ellenőrző pont érintése, a vezérlő újra indítja magát. Sokszor építenek be öndiagnosztikai rutinokat is, melyek ellenőrzik a memória hibákat, a stack túlfutását, a központi egység terheltségét, vagy az üzenetek visszaolvasásával a kommunikációs csatornák helyes működését. A szoftver tesztelésének módszerei Kész a szoftverünk, és persze szeretnénk minél gyorsabban kipróbálni. A következő lehetőségeink vannak erre: Szimulátorok HIL tesztek Debuggerek, logikai analizátorok, kommunikációs analizátorok Terhelés próba, klimatikus próba, tűrésértékek vizsgálata Tipikusan az szokott a helyzet lenni, hogy mire a szoftver elkészül, a hardver még sehol sincs. Ebben a korai fejlesztési fázisában a szimulátorokkal végzett tesztelések jelentik az egyetlen lehetőséget. Ekkor PC-s környezetben utasítás szimulátor alkalmazásával futtatjuk a programunkat. A fejlettebb keretrendszerekben leírhatók a portok viselkedése is, így már komoly tesztesetek is előállíthatók. Az IBM Rational Test Realtime vagy a Tessy programokkal pedig már komplett automatizált teszt forgatókönyveket építhetünk fel, futási idő méréssel, nagyon jól dokumentálva. A szimulált tesztek nagyon nagy előnye, hogy jól automatizálhatók, és minden olyan hiba ág is könnyen bejárható, amit a valós körülmények között nem lehetséges. Érdemes tehát jól kidolgozni ezeket a teszteket, és később, ha változások vannak a szoftverben újból és újból lefuttatni ellenőrzésképpen. forrás: compress.ru Ha most már hozzáférhető a hardver, elkezdhetjük a HIL (Hardware In the Loop) teszteket.
Ekkor a külső környezetet, társvezérlőket még szimuláljuk, de a program már a valóságos vezérlőn fut. Ebben a környezetben jól szimulálhatók a rendszer hibák, kábelezési, szenzor vagy más periféria hibák, társvezérlő kiesése, és jól elvégezhetők a terhelési tesztek. A teszteket debugger, logikai analizátor és kommunikációs elemző és üzenetgeneráló programokkal támogathatjuk. A szoftver és a rendszer végső ellenőrzését, validálását minden esetben a valós környezetben kell elvégezni úgy, hogy lehetőleg ekkor más semmilyen segédeszközt ne alkalmazzunk a próbák során. Veszélyes hibák maradhatnak a rendszerben, ha például a debugger maga nyugtázza folyamatosan a watch dog-ot, vagy ha a kommunikációs analizátorunk nem teszi lehetővé a bus off állapot elérését, mert figyelésével mindig bekapcsolva tartja a csatornát. forrás Lauterbach.com Végül, ha már minden hibamentesen működik, ellenőrizzük a rendszerünk működését extrém körülmények között. Ide tartoznak a különböző terhelési próbák, a klimatikus próba, és a határértékek vizsgálata. A tesztelések végén mindig szánjunk még elegendő időt a dokumentumok elkészítésére, mert ez egy későbbi vitás helyzetben bizonyító erejű lehet (termékfelelőség!), illetve a fejlesztési produktumok archiválására. Sok esetben erre törvényi kötelezettségünk is van, de a saját józan érdekünk is ezt kívánja meg.