Boeing 787 mógł po 248 dniach ciągłego zasilania utracić całe zasilanie AC przez przepełnienie licznika w sterownikach generatorów
FAA w 2015 r. wydała dyrektywę zaskakującą nawet jak na branżę lotniczą: wszystkie Boeingi 787 należało okresowo całkowicie odłączać od zasilania, ponieważ wewnętrzny licznik software’u w generator control units przepełniał się po 248 dniach ciągłej pracy. Wszystkie jednostki mogły wtedy jednocześnie wejść w tryb failsafe, powodując utratę zasilania prądem przemiennym. Początkowym środkiem zaradczym był power cycle, a późniejsza dyrektywa wymagała instalacji poprawionego oprogramowania. Skutek był więc wspólny dla wielu kanałów.
Licznik czasu ma skończony zakres
Program może przechowywać uptime jako liczbę ticków w polu o określonej liczbie bitów. Gdy licznik osiąga maksimum, następne zwiększenie może zawinąć wartość do zera lub liczby ujemnej. Jeśli logika nie obsługuje rollover, dalsze obliczenia czasu stają się niepoprawne.
248 dni brzmi absurdalnie długo, ale samolot nie musi być stale w powietrzu
Warunek dotyczył ciągłego zasilania systemu, a nie lotu bez lądowania. Samoloty mogą pozostawać zasilane z APU lub źródeł naziemnych między lotami. W procedurach bezpieczeństwa nie można zakładać, że operator na pewno przypadkiem zresetuje urządzenie wcześniej.
Najgroźniejsza była synchronizacja awarii
787 ma wiele źródeł i sterowników generatorów. Gdyby każdy miał niezależny moment awarii, redundancja mogłaby ochronić system. Problem polegał na tym, że identyczne liczniki uruchomione razem mogły osiągnąć limit jednocześnie. To kolejny przykład common-mode software failure.
FAA uznała potencjalny skutek za utratę kontroli
Dyrektywa nie opisywała kosmetycznego błędu wyświetlacza. Pełna utrata zasilania AC mogła wpływać na wiele krytycznych systemów i według FAA prowadzić do utraty kontroli nad samolotem. Dlatego regulator nakazał konkretne działania mimo że zdarzenie wymagało bardzo długiego uptime.
Restart był poprawką proceduralną, nie rozwiązaniem architektury
Pierwsza dyrektywa nakazywała okresowe odłączenie zasilania, co resetowało licznik. To częsty wzorzec w technice: jeśli trwała poprawka wymaga czasu na opracowanie i certyfikację, można chwilowo ograniczyć warunki, w których bug się ujawnia. W 2018 r. FAA zastąpiła ten środek obowiązkiem instalacji nowego software’u GCU.
Rzadki warunek nadal należy do przestrzeni testów
248 dni jest poza typowym czasem testu systemowego. Właśnie dlatego testy długotrwałe często symulują starzenie liczników, manipulując stanem zegara albo szybciej zwiększając ticki. Jeśli zachowanie systemu zależy od uptime, graniczne wartości muszą być częścią specyfikacji. Z perspektywy testów przypadek jest prosty do przyspieszenia: zamiast czekać 248 dni, można ustawić wewnętrzny licznik kilka ticków przed maksymalną wartością i obserwować rollover. Jeżeli architektura uniemożliwia taki test bez realnego czekania, sama testowalność systemu staje się problemem projektowym.
Identyczne zegary mogą pokonać redundancję
System lotniczy często ma kilka niezależnych kanałów właśnie po to, by awaria jednego nie pozbawiła samolotu funkcji. Taka redundancja chroni świetnie przed przypadkowym uszkodzeniem elektroniki, ale gorzej przed deterministycznym błędem software’u. Jeśli wszystkie kontrolery uruchomiono w podobnym momencie, korzystają z tego samego typu licznika i wykonują tę samą wersję programu, osiągają granicę niemal równocześnie. To zjawisko nazywa się common-cause lub common-mode failure. Projektanci mogą mu przeciwdziałać przez różnorodność implementacji, niezależne źródła czasu, staggered resets, mechanizmy cross-monitoringu albo udowodnienie, że rollover jest bezpiecznie obsługiwany. W przypadku 787 najprostszy środek tymczasowy — okresowy power cycle — celowo rozrywał właśnie tę synchronizację. Nie naprawiał algorytmu, ale gwarantował, że licznik nie osiągnie krytycznej granicy w eksploatacji. To również dobry argument za projektowaniem liczników z zapasem rzędu wielu lat, jeśli koszt dodatkowych bitów jest pomijalny. W nowoczesnym systemie oszczędność kilku bajtów rzadko uzasadnia ryzyko, że po miesiącach uptime pojawi się specjalna procedura operacyjna.