Biztonságkritikus szoftver újrafelhasználásának előnyei és kihívásai

A biztonságkritikus rendszereknek és szoftvereknek nemcsak a jóváhagyási folyamataik hosszúak, hanem az életciklusuk is. Nem ritka, hogy húsz é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. A Knorr-Bremse Vasúti Jármű Rendszerek Kft. elektronikai fejlesztőmérnökei Budapesten alaposan körbejárták a kérdést.

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 húsz é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íteni, azaz új interfészeket kell biztosítani ahhoz, hogy a meglévő terméket vagy azok egy részét egy új környezetben (például új fékvezérlő platform részeként) is tudjuk hasznosítani.

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özöket, valamint az azokat irányító szoftvereket később újra fel szeretnék 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.

Á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ölnek, akkor azt az eredeti projekt szabványi környezetében tehetik meg, és ekkor elegendő csak a változást dokumentálni. Ha azonban bővíteni szeretnék 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 hagyhatják, az új interfészeket pedig új fájlokban valósítják 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.

Korunk fejlettebb és gyorsabb mikrovezérlői és okosabb fordítói lehetőséget nyújtanak 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 az is elvárható 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 lehet írni.

Ehhez képest húsz é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.

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.

Ha megörökölt rendszerhez nyúlnak, fontos, hogy a módosításokat csak a minimálisan szükségesre korlátozzák. Amit lehet, érdemes új modulként fejleszteni akkor is, ha logikailag a meglévővel szerves egységet alkot. Amennyiben már létező kódot akarnak újra felhasználni, érdemes lehet tiszteletben tartani a korábbi fejlesztés logikáját, „szabályrendszerét”, mert ezzel rendszerszintű hibákat előzhetnek meg.