Helsinki út 105
1238
Magyarország
info@knorr-bremse.com
Biztonságkritikus szoftver újrafelhasználásának előnyei és kihívásai.
A biztonságkritikus rendszereknek és szoftvereknek nem csak a jóváhagyási folyamataik hosszúak, hanem az életciklusuk is. Nem ritka, hogy 20 évvel korábban fejlesztett elektronikák támogatására vagy karbantartására van szükség, hogy új környezetben is hasznosítani lehessen azokat. Joggal merül fel a kérdés, hogy milyen feladatokat tartogat az ilyen szoftverek felhasználása, karbantartása. Elektronikai fejlesztőmérnökeink Budapesten alaposan körbejárták a kérdést.
Kapcsolat
Knorr-Bremse Vasúti Jármű Rendszerek Hungária Kft.
Bevezető
A biztonságkritikus rendszerek, így a Knorr Bremse vasúti fékvezérlő elektronikái (ideértve az ezeken futó szoftvereket is) alapos, és ennek következtében hosszadalmas kvalifikációs és külső, szabványok által előírt, hatóság által végzett jóváhagyási folyamaton esnek át, mielőtt a szállítmányozást vagy az utazóközönséget szolgálnák a mindennapokban.
Nemcsak a termékfejlesztés hosszú, hanem ezen eszközök életciklusa is. Ebből adódóan szükségszerű az akár 20 évvel ezelőtt kifejlesztett elektronikák támogatása és karbantartása is. Mindezek mellett pedig az új vevői igényeket is ki kell elégítenünk, azaz új interfészeket kell biztosítanunk ahhoz, hogy a meglévő terméket, vagy annak egy részét egy új környezetben (például új fékvezérlő platform részeként) is tudjuk hasznosítani.
Fékezz velünk!
A Knorr-Bremse Budapestnél minden nap egy biztonságosabb és zöldebb jövőn dolgozunk. Fékezz velünk cikksorozatunkban nem csak azt mutatjuk meg, hogyan működnek a vasúti fékezvezérlők és az azokhoz kapcsolódó szolgáltatások, rendszerek, de betekintést nyújtunk a kulisszák mögé is. Mérnökeink maguk mesélik el, miként zajlik a fejlesztés, tesztelés, hogyan állnak össze a különböző komponensek a folyamat végére egy kerek egésszé, amiből az utas csak annyit érzékel, hogy a jármű pont ott és úgy áll meg, ahogy kell.
A vasúti szerelvényeken futó vezérlőkkel több százezer üzemórányi tapasztalat gyűlik össze, amely visszaigazolja az adott termék jóságát és alátámasztja a tesztelési és minősítési folyamat helyességét.
Mindezek mellett, a befektetett munkát és költségeket is figyelembe véve nyilvánvaló, hogy az elkészített és jól működő eszközeinket, valamint az azokat irányító szoftvereket később újra fel szeretnénk majd használni. A leírtak alapján felmerülhet a kérdés, hogy milyen kihívásokat tartogat ezen szoftverek karbantartása, felhasználása számunkra.
Kihívások
Változó szabványok
Általánosságban elmondható, hogy a szabványok újabb és újabb verziói egyre szigorúbb előírásokat tartalmaznak, de legalábbis egyre precízebben fogalmaznak. Igaz, hogy a korábbi szabvány szerint fejlesztett kódokat nem kell az új szabvány szerint minősíteni, de ehhez bizonyos feltételeknek teljesülniük kell.
Amennyiben a szoftverben csak hibajavítást eszközölünk, akkor azt az eredeti projekt szabványi környezetében tehetjük meg, és ekkor elegendő csak a változást dokumentálni. Ha azonban bővíteni szeretnénk egy komponens funkcionalitását, megoldás lehet egy kiegészítő modul fejlesztése. Ebben az esetben az eredeti forrásfájlokat érintetlenül hagyhatjuk, az új interfészeket pedig új fájlokban valósítjuk meg. Ekkor természetesen a kiegészítő komponens már az új szabványoknak kell, hogy megfeleljen.
Valós példa erre egy CAN (Controller Area Network) perifériát vezérlő komponens, ahol például a funkcionalitást az ”extended frame” támogatással kell kibővíteni. Ekkor azonban figyelni kell arra, hogy a régi és az új kiegészítő modul is ugyanahhoz a perifériához fér hozzá, ugyanazokat a regisztereket használja. Ebből adódó megoldandó probléma, hogy ne férjenek hozzá egyszerre a közös erőforrásokhoz. A régi komponens ekkor érintetlen maradhat, míg az új komponens tisztán, a mai fejlesztési követelményeknek megfelelően készülhet el.
Változó technológiák és „best practice”
Korunk fejlettebb és gyorsabb mikrovezérlői és okosabb fordítói lehetőséget biztosítanak a kód akár nagyon kicsi, de jól tesztelhető modulokba történő szervezésére, amelyek jól definiált interfészeken keresztül kapcsolódnak egymáshoz. Ezenkívül már azt is elvárhatjuk egy fordítótól, hogy magasan optimalizált gépi kódot generáljon, amiből következik, hogy akár terjengősebb, de jobban olvasható, karbantartható és tesztelhető forráskódokat is írhatunk.
Ehhez képest 20 éve még sokkal korlátozottabb erőforrásokkal kellett beérniük a fejlesztőknek, így a terjedelmesebb függvények és számos globális változó használata is szóba kerülhetett a minél gyorsabb futás érdekében. A korábbi kezdetleges operációs rendszerek vagy ütemezők miatt a különböző feladatok aszinkronitásából eredő problémákat is másképp kezelték (például lokális hozzáférést szabályozó változók használata szemaforok, mutexek helyett). Mindezek a megoldások azonban csökkentették a kód átláthatóságát, karbantarthatóságát és tesztelhetőségét.
Ilyenkor bármennyire is vonzó lenne a teljes kód újratervezése, el kell fogadni az eredeti „szabályrendszert”, amiben a kód készült, és annak megfelelő megoldásokat kell alkalmazni az adott modul további fejlesztésére, még ha mai szemmel ez elavultnak is tűnhet. Az ilyen kódok használata során egyfelől minél kisebb változtatásokra törekszünk, másrészt viszont architekturálisan is megbomolhat a szoftver egységessége, ami hibákhoz vezethet.
Informalitás
Minden formalizmus (dokumentáció, kódban elhelyezett megjegyzések, értelmes változónevek) ellenére is vannak olyan elemei a fejlesztésnek, amelyek az adott közegben magától értetődőnek, evidensnek tűnnek, ezért nem képezik részét a dokumentációnak. Ilyen lehet például a használt mikrokontroller kitapasztalt viselkedése, esetleg a régi és ezért nem túl kifinomult fordító optimális assembly kódgenerálásához igazított C kód.
Amikor hibajavítás, vagy további fejlesztés céljából vizsgálunk egy szoftvert, érdemes például tudni, hogy a kódot eredetileg is erre a mikrovezérlőre fejlesztették-e, vagy már portolás útján került a rendszerbe. Általában az ilyen, sokat futott és robusztusnak mondható szoftverek hibás működése a körülmények és az integrált környezet megváltozására vezethetőek vissza. Ilyenkor kézenfekvő lehet ezek módosítása a hiba megszüntetéséhez.
Konklúzió
Ha megörökölt rendszerhez nyúlunk, fontos, hogy a módosításainkat csak a minimálisan szükségesre korlátozzuk. Amit lehet, érdemes új modulként fejleszteni akkor is, ha logikailag a meglévővel szerves egységet alkot. Ha a kódban “furcsa” vagy elsőre észszerűtlennek tűnő, nem praktikus megoldást látunk, mindig alaposan járjuk körbe, mert lehet, hogy az tapasztalati úton alakult ki. Amennyiben már létező kódot szeretnénk újra felhasználni, érdemes lehet tiszteletben tartani a korábbi fejlesztés logikáját, “szabályrendszerét”, mert ezzel rendszerszintű hibákat előzhetünk meg.
Új szoftverek fejlesztése közben pedig törekednünk kell arra, hogy az általunk implementált kódrészek meglehetősen (de még észszerű mértékben) általánosak legyenek a későbbi, egyszerűbb bővíthetőség érdekében. A fejlesztés során felmerülő korlátozó tényezőket, kényszermegoldásokat pedig minden esetben dokumentálni szükséges. Mindezzel hozzájárulunk ahhoz, hogy az elkészült szoftverkomponenseket akár újabb 20 év múlva is probléma nélkül lehessen újra felhasználni.