Az időjárás-előrejelzési szolgáltatásokkal kapcsolatos elvárások az utóbbi évtizedben drasztikusan megváltoztak. A lokáció-alapú időjárási információ napjainkra az okostelefon egyik alapvető funkciójává vált. De milyen adatokból táplálkoznak a mérések eredményeit felhasználó meteorológiai szolgáltatók?
Közismert, hogy az adatokat felszíni mérésekkel és meteorológiai ballonok segítségével légköri mérésekkel nyerik ki. Azt azonban talán kevesebben tudják, hogy az utóbbi évtizedekben valamennyi repülőgép számára előírás, hogy a bejárt út során a műszerekből nyert, meteorológiailag releváns mérési értékeket automatikusan továbbítsa az erre a célra szabványosított adatformátumban a földi központok felé, ezzel is növelve a mérési modellek számára rendelkezésre álló megfigyelési információk számát.
A légkör bonyolult fizikai kölcsönhatásai nem írhatók le determinisztikus módon, ezért az időjárás-előrejelzéshez használt modell megközelítő módszereket alkalmaz a különféle mérésekből származó előrejelzések elkészítése közben.
A modellek analízise során mindig is számolni kellett a hibakorrekcióval, azonban az ECMWF (Középtávú Időjárás Előrejelzések Európai Központja) kutatói az utóbbi években ezen felül azonosítottak egy kellemetlen és a számítási modelleket erőteljesen befolyásoló visszatérő adathibát, melyről azt feltételezték, hogy a repülőgépek egy adott típusára vezethető vissza, azonban az intenzív nemzetközi légiforgalom miatt 2020-ig nem volt lehetőségük identifikálni a téves adatokat küldő repülőgép típust.
A COVID-19 világjárvány okozta megritkult járatsűrűségnek köszönhetően a tavalyi évben az ECMWF azonosította, hogy a hibát a Boeing Dreamlinerek, vagyis a B787-es repülőgépek fedélzeti szoftvere okozza, amely a légköri mérések egyikét, a szélirány értéket téves előjellel küldi tovább a meteorológiai célú automatikus adatcsomagokban.
Mivel ezek az adatok anonimizáltan érkeznek meteorológiai feldolgozásra, ezért a hiba valódi karakterisztikájának és eredetének feltérképezése, az érkező adatok elhatárolása rendkívül nehéz volt. A gyártó szoftveres javítása az ECMWF legfrissebb szemináriuma szerint nem oldotta meg a problémát, a téves kalkulációk elkerülését így utólagos korrekcióval és a bizonytalan forrású adatok ignorálásával biztosítják.
A fenti történet jól példázza, hogy gyorsuló világunkban az egyre több, bonyolultabb és egymástól függő informatikai rendszer működése során tapasztalt hibát kiváltó ok és a hiba felbukkanásának helye között akár rendszernyi távolságok is lehetnek. Minél nagyobb az összefüggő IT rendszerek közötti távolság, a hiba feltérképezése, elemzése, végül korrigálása hatványozott erőforrásigény mellett lesz csak kivitelezhető.
Az egyre nagyobb mértékű és komplexitású integráció új kihívások elé állítja a tesztelési szakembereket. Egyre több szoftver támaszkodik különféle interfészen keresztül más rendszerek szolgáltatásaira, gondoljunk csak a már említett meteorológiai app-ra, amely a legtöbb ember okostelefonján megtalálható.
Az interoperabilitás megvalósulása, vagyis a különböző informatikai rendszerek együttműködő képessége kiemelt fontosságú szempont lett a szoftverfejlesztésben. Ez azt jelenti, hogy egy adott szoftver funkcionalitását több integráltsági szinten is ellenőrizni kell, vagyis az integrációs teszteket valamennyi együttműködő rendszer szintjének megfelelően be kell vonni a tesztelési folyamatba. Az együttműködő rendszerek esetében a tapasztalat azt mutatja, hogy a rendszerek határain elhelyezkedő funkciók általában kevésbé esnek a figyelem középpontjába, ezért a hibák átlagos gyakorisága itt jellemzően magasabb.
Fontos tanulsága a fenti esetnek, hogy az integráció tesztelése során a tesztfeltételeket modul szinttől haladva a teljes integráltsági állapotig valamennyi elkülöníthető fázisban ellenőrizni kell, beleértve valamennyi függő adatelemet, mely az adott tesztelési egység elvárt működését befolyásolhatja, de az adott egységen kívülről származik.
Könnyen elképzelhető ugyanakkor az is, hogy a meteorológiai célú adatcsomagok esetében a Boeing tesztelési procedúrája valamennyi szintre kiterjedő és alapos volt és “mindössze” a tesztek kivitelezéséhez szükséges tesztelési környezet vagy a szimulációs elemek (stub) egyike nem volt megfelelően kialakítva és ez okozta a fals verifikációt.
Mindenesetre meglepő, hogy egy előjel(!) hiba miatt a világ valamennyi meteorológiai szolgáltatója redukált információmennyiséghez jut, valamint hogy látenciában maradhatott közel egy évtizeden át egy ilyen, triviálisnak tűnő szoftverhiba (az első Dreamlinert 2011-ben állították szolgálatba).
