Airbus A350 miał limit 149 godzin ciągłego zasilania, po którym wewnętrzny timer mógł zakłócić komunikację awioniki
EASA w 2017 r. nakazała operatorom części A350 wykonywać okresowe power cycle. Analiza zdarzeń eksploatacyjnych wykazała, że po 149 godzinach ciągłego zasilania wewnętrzny timer w systemie Integrated Modular Avionics mógł doprowadzić do utraty komunikacji między częścią modułów i siecią awioniki. Skutki zależały od konfiguracji: od utraty redundancji do całkowitej utraty określonej funkcji. To przykład błędu, który nie zależy od konkretnego wejścia pasażera czy pilota, lecz od samego upływu uptime.
Nowoczesna awionika przypomina centrum danych w samolocie
A350 korzysta z Integrated Modular Avionics, gdzie wiele funkcji działa na wspólnej platformie obliczeniowej i sieciowej. Zamiast osobnego pudełka dla każdej funkcji mamy moduły, które współdzielą zasoby. Zwiększa to elastyczność, ale oznacza, że problem wspólnej infrastruktury może wpływać na kilka systemów.
149 godzin było granicą stanu wewnętrznego
EASA opisała problem jako związany z internal timer. Po odpowiednio długim ciągłym zasilaniu mogła zostać zaburzona komunikacja pomiędzy systemami a siecią awioniki. To typowa klasa „aging bugs”: stan narasta lub licznik dochodzi do granicy, choć pojedyncze operacje działają poprawnie.
Skutki zależały od tego, co działało na danym module
W systemie modułowym ten sam typ procesora może hostować różne funkcje. EASA zaznaczała, że konsekwencją mogła być utrata redundancji albo całej konkretnej funkcji, w zależności od zaangażowanych modułów. To utrudnia analizę bezpieczeństwa: bug infrastruktury nie ma jednego widocznego symptomu.
Power cycle zerował warunek
Tymczasowym środkiem było okresowe wyłączenie i ponowne włączenie zasilania na ziemi przed osiągnięciem limitu. Restart przywracał stan timerów do bezpiecznej wartości. Z punktu widzenia eksploatacji jest to proste, ale wymaga proceduralnej dyscypliny i śledzenia czasu.
Późniejsza modyfikacja mogła usunąć potrzebę procedury
Dyrektywa została później zrewidowana wraz z dostępnością zmian software’u. To normalny cykl dla systemów certyfikowanych: najpierw ogranicza się ryzyko operacyjnie, potem wprowadza poprawkę techniczną po przejściu wymaganej walidacji.
Uptime powinien być traktowany jak dane wejściowe
Programiści myślą o wejściu jako o wiadomościach, kliknięciach czy sygnałach. Tymczasem sam czas działania jest również wejściem. System trzeba testować nie tylko dla różnych wartości danych, ale także dla 1 godziny, 100 godzin i momentów rollover. To dlatego systemy o bardzo długim cyklu życia potrzebują testów soak i accelerated aging. Nie chodzi wyłącznie o sprzęt nagrzewający się przez wiele dni; software też ma stany narastające w czasie. Tester powinien aktywnie szukać liczników, cache’y i kolejek, których rozmiar zależy od uptime.
Software aging nie zawsze oznacza wyciek pamięci
Określenie software aging kojarzy się często z programem, który z każdym dniem zużywa coraz więcej RAM-u. W rzeczywistości starzenie może wynikać z wielu stanów: rosnącego licznika, fragmentacji, kolejki, cache, liczby otwartych uchwytów albo narastającego dryfu. System działa poprawnie dla małego stanu, a po długim uptime przechodzi do regionu, którego projektant nie testował. Jedną z praktyk jest software rejuvenation — kontrolowany restart lub odtworzenie stanu zanim kumulujące się efekty osiągną niebezpieczny poziom. W serwerach taki zabieg może być normalną techniką dostępności, ale w awionice musi być ściśle kontrolowany i certyfikowany. A350 pokazuje, że granica kilkudziesięciu czy stu godzin nie jest absurdem: z perspektywy logiki komputera to po prostu kolejna wartość stanu, która może ujawnić nieprzetestowany warunek. Z punktu widzenia maintenance ważna jest też obserwowalność samego uptime. Operator powinien wiedzieć nie tylko, że system działa, ale jak długo pozostaje w stanie, dla którego znane są ograniczenia. Taka informacja może automatycznie wywołać kontrolowany restart przed granicą.