Autor: Krešimir Tušek, Senior Software Engineer, GlobalLogic Croatia
Mjesto radnje: lansirna rampa Kourou u Francuskoj Gvajani, 4. lipnja 1996.
Sve je spremno za prvi let nove rakete Ariane 5 razvijene za Europsku svemirsku agenciju (ESA). Njezin teret su četiri znanstvena satelita s misijom istraživanja zemljine magnetosfere.
No, umjesto toga, sve će završiti u skupom vatrometu, nepunih 40 sekundi nakon lansiranja. I to, ispostavilo se, zbog pogreške u ugrađenoj programskoj podršci (embedded software).
Ovakve katastrofe uglavnom su posljedica cijelog lanca događaja umjesto jednog jedinog propusta. Zanimljivost ovog slučaja je u tome da se većina uzroka veže uz software, što ga čini odličnom podlogom za raspravu o upravljanju pogreškama u programskim sustavima, od razrade zahtjeva, preko implementacije, do izvođenja.
Kritični podsustav
Komisija sazvana u svrhu analize događaja, zaključila je da je uništenje rakete izazvano problemom na sustavu inercijalne navigacije (SRI – Inertial Reference System). Osvrnimo se kratko na ulogu tog podsustava u letu rakete. Raketa mora pratiti neku unaprijed zadanu putanju nakon lansiranja. To se postiže zakretanjem sapnica na motoru rakete čime se ona zakreće u željenom smjeru.
Zakretanje rakete samo je polovica cijele priče. Druga je polovica mjerenje trenutne pozicije prema kojoj se putanja korigira, što je zadaća inercijalnog sustava navigacije. Taj sustav, uz poznavanje početne pozicije (očito je poznato odakle je raketa lansirana), koristi akcelerometre i žiroskope da bi odredio trenutnu poziciju metodom integracije (senzori slične namjene postoje i u današnjim pametnim telefonima, samo s daleko manje preciznosti).
U raketi Ariane 5 sustav inercijalne navigacije generira podatke o trenutnoj poziciji i brzini rakete i šalje ih u ugrađeno računalo (OBC – On-Board Computer) koje upravlja motorima. SRI je u dizajnu prepoznat kao kritičan dio sustava i zbog toga je dupliciran. Jedan SRI je aktivan a drugi, redundantni, paralelno radi identične izračune i spreman je preuzeti ako prvi zakaže. Isti je princip redundancije primjenjen i na OBC-u.
Pokušajte uočiti gdje je nastao propust (ili više njih)
Vratimo se malo u prošlost, na početak lanca uzroka:
- SRI je originalno razvijen za raketu Ariane 4, tj. prethodnu generaciju.
- Dio SRI koda je i funkcija za poravnanje čija je zadaća da računa promjene pozicije rakete prije samog lansiranja (još uvijek na lansirnoj rampi). Ta se funkcionalnost koristi u slučaju da se lansiranje mora prekinuti između 9 i 5 sekundi prije lansiranja. Tada funkcija postaje korisna jer se njezin izlaz može koristiti za brzo ponavljanje lansiranja bez potrebe za ponovnim poravnanjem rakete na lansirnoj rampi (što može trajati preko 45 minuta). Predviđeno trajanje izvođenja te funkcije je 50 sekundi od početka odbrojavanja, nakon čega se funkcija prestaje izvršavati (što znači da će se nepotrebno izvršavati i u prvoj fazi leta). Ta je funkcionalnost bila iskorištena pri samo jednom prijašnjem lansiranju.
- U svim drugim scenarijima, rezultat te funkcije se ne koristi.
- Zapravo uopće nema smisla da se funkcija nastavi izvoditi tijekom leta jer njezin izlaz tada nema smisla i ne koristi se.
- Ariane 5 ima drugačiju sekvencu lansiranja pa se na njoj navedena funkcionalnost uopće ne može koristiti.
- Navedena funkcionalnost ostala je dio SRI-a i na Ariane 5 zato da se izbjegnu nepotrebne izmjene na već od prije funkcionalnom sustavu.
- SRI interno pretvara neke od svojih rezultata iz 64-bitnog float broja u 16-bitni integer.
- Od ukupno 7 takvih kritičnih varijabli, za 3 nije dodana zaštita od overflowa u kodu, zbog uštede procesorskih resursa. Analizom je utvrđeno da su te vrijednosti fizički ograničene i da, uz veliku sigurnosnu marginu, ne može doći do overflowa na njima. Među tim varijablama je i vrijednost horizontalnog pomaka.
- Horizontalna brzina rakete u letu utječe na mjereni horizontalni pomak.
- Raketa Arianne 5 ima drugačiju putanju pri lansiranju koja rezultira otprilike 5 puta bržim porastom horizontalne komponente brzine u odnosu na Ariane 4.
- U slučaju iznimke (exception), SRI je dizajniran da na sabirnicu pošalje dijagnostičke podatke i isključi se.
Što se u stvari dogodilo?
Pažljivijem čitatelju slijed događaja već je vjerojatno jasan. Tijekom prve faze leta, raketa Arianne 5 ubrzava horizontalno znatno više od svoje prethodnice. Funkcija horizontalnog pomaka zbog te veće brzine računa vrijednost koja ne stane u 16-bitni broj. SRI signalizira grešku operanda i gasi se. 50-ak milisekundi kasnije to čini i redundantni SRI. OBC pogrešno interpretira dijagnostičke podatke podatke na sabirnici kao informacije o poziciji i pokušava korigirati putanju zakretanjem motora u krajnju poziciju. Raketa se počinje raspadati nekoliko sekundi kasnije.
Srećom, sustav za samouništenje radi ispravno, prepoznaje početak rapadanja rakete i ispravno se aktivira tako da se daljnji nekontrolirani let zaustavlja, prolazi bez ljudskih žrtava i nama ostavlja poučnu priču za buduće generacije inženjera.
Neispravan kod suština problema
Glavna pouka ove katastrofe je da redundancija sustava ne štiti od svih pogrešaka u dizajnu. Kod dizajna Ariane 5 veliki je naglasak bio stavljen na upravljanje pogreškama proizašlima iz slučajnih događaja ili kvarova na sklopovlju.
Redundancija sklopovlja je fantastičan pristup za smanjivanje tih rizika ali od male koristi ako se na dva ili više redundantnih sustava izvodi – neispravan kod.
Nastavak slijedi…
Ova priča ima nastavak na .debugu. Krešimir Tušek i Mario Rotim, Senior Software Engineers iz GlobalLogic Croatia, održat će 3. lipnja u 12:10 sati u tracku #hardcore prezentaciju “Ugradbeni sustav bez glavobolje – model upravljanja pogreškama”. Tijekom prezentacije prisutni će moći doznati kako se nepredviđena stanja mogu svesti na minimum te kako klasificirati pogreške i uspostaviti razne načine upravljanja istima.
Ulaznice za online praćenje .debuga i dalje su dostupne.
