Prywatny satelita testujący żagiel słoneczny prawie został spisany na straty po tym, jak po przepełnieniu pamięci zawiesił się jego system operacyjny. Na szczęście na ratunek przyszła zabłąkana cząsteczka która spowodowała reset.
LightSail to znajdujący się od kilku tygodni na orbicie okołoziemskiej prywatny satelita, którego zadaniem jest testowanie procedur rozkładania żagla słonecznego. Jego twórcy chcą sprawdzić wszystkie procedury przed wysłaniem właściwego satelity w podróż z napędem generowanym przez fotony uderzające w żagiel. Satelita co rusz napotyka na poważne przeszkody, w tym spowodowane prostym błędem programistów.
Jestem sobie małym satelitą
Towarzystwo Planetarne od wielu lat pracuje nad koncepcją satelity napędzanego energią fotonów. LightSail-1, wysłany na orbitę 20 maja tego roku, jest ważnym krokiem na drodze do udowodnienia zasadności takiego napędu. Niestety krążący właśnie wokół ziemi miniaturowy satelita jest źródłem wielu zmartwień zespołu nadzorującego eksperyment. LightSail-1 zbudowany jest w modelu CubeSat o rozmiarze 3 modułów, czyli 10x10x30cm.
Satelita jest naprawdę miniaturowy
Dzięki niewielkiej wadze i rozmiarom koszt wyniesienia go na orbitę był akceptowalny dla stowarzyszenia, które utrzymuje się ze składek członkowskich i darowizn od sponsorów. Wraz z nim na rakiecie zmierzającej na orbitę znalazło się 9 innych satelitów podobnego rozmiaru (oraz wojskowy wahadłowiec szpiegowski X-37B). Niestety LightSail po niecałych 3 dniach przestał wysyłać jakiekolwiek dane. Przez pierwsze 40 godzin w trakcie każdego przelotu nad jednym z dwóch centrów kontroli można było usłyszeć komunikaty satelity, sygnalizującego, że nadal funkcjonuje prawidłowo. Zaraz potem system pokładowy się zawiesił.
Testy, testy i jeszcze raz testy
Na pokładzie satelity podróżuje system operacyjny oparty o jądro Linux. Satelita co 15 sekund wysyła komunikat sygnalizujący prawidłowe działanie. Po każdym wysłaniu komunikatu informacja o tym fakcie zapisywana jest do pliku /data/beacon.csv. Niestety nikt nie przewidział, że miejsce w systemie plików może w ten sposób skończyć się szybciej niż sama misja satelity. Już po 40 godzinach plik osiągnął rozmiar 32 megabajtów i zawiesił system. W trakcie naziemnych testów komputer nigdy nie działał naraz ponad 40 godzin – testy długoterminowe są jak widać stałą bolączką systemów lotniczych (pamiętacie Boeinga 787, którego też trzeba było resetować od czasu do czasu?) Okazało się, że satelita nie tylko przestał komunikować się z otoczeniem, ale także wyglądało na to, że ignoruje regularnie wysyłane instrukcje restartu komputera. Co ciekawe, błąd był już znany producentowi systemu, jednak w kosmos wysłana została starsza, zapewne lepiej przetestowana wersja. Zespół jednak nie tracił nadziei, licząc na mały, choć powtarzalny cud.
Promieniowanie kosmiczne na ratunek
W przestrzeni kosmicznej nie było żadnego śmiałka gotowego nacisnąć guzik odcinający zasilanie. Trzeba było zatem liczyć na oddziaływanie innych sił. Wcześniejsze doświadczenia z satelitami CubeSat wykazywały, że w większości przypadków po 3 tygodniach od umieszczenia na orbicie ich komputery resetowały się samoistnie. Najdłużej na reset czekano 6 tygodni. Reset powodowany był najprawdopodobniej przez cząsteczki o dużym ładunku, poruszające się w przestrzeni kosmicznej i trafiające w elementy satelity. Takie trafienie może spowodować zmianę stanu komórki pamięci czy też rejestru procesora, powodując anomalię wystarczającą do restartu (nawet na Ziemi, chronionej atmosferą, zdarza się, że pakiet wysyłany do serwera WWW może zostać przypadkowo zmodyfikowany przez przestawienie jednego bitu w ten właśnie sposób).
Czas życia satelity na tej orbicie planowany był na około 6 miesięcy, zatem zespół kontroli lotu uzbroił się w cierpliwość i czekał. Szczęście im dopisało, ponieważ już po 8 dniach satelita nagle się zrestartował i nawiązał ponowny kontakt z ziemią. Podjęto próbę naprawy satelity przez… SSH. Polecenie, które należało wydać, by załatać system, to
ssh root@[IP] 'ln -sf /dev/null /data/beacon.csv'
Niestety okazało się, że połączenie SSH jest tak niestabilne, że nie ma możliwości skutecznego przesłania nawet tego jednego polecenia. Kierownictwo lotu uznało zatem, że bezpieczniej będzie po prostu raz na dobę restartować satelitę ręcznie. Metoda ta wydaje się działać.
LightSail właśnie rozkłada żagiel
Najważniejszym etapem misji miało być rozłożenie żagla słonecznego. Misja najwyraźniej jednak była z definicji pechowa, ponieważ dwa dni temu satelita znowu przestał nadawać sygnały kontrolne. Tym razem milczenie trwało niecałe 2 doby i nastąpiło po rozłożeniu baterii słonecznych. Prawdopodobnie było spowodowane zbyt dużymi skokami napięcia pomiędzy momentami, kiedy baterie widziały słońce, a momentami, kiedy były w cieniu. Naukowcy postanowili wykorzystać dostępność satelity i nie kusić więcej losu oraz jak najszybciej przeprowadzić najważniejszą część eksperymentu. Dosłownie kilka minut temu szef misji poinformował, że z odczytów parametrów satelity wynika, że żagiel zaczął się już rozkładać. Trzymamy kciuki za los satelity, oby jego dalsza podróż wolna już była od błędów programistów.
Komentarze
Nie chcę być złośliwy (jako die-hard Linuksowiec), ale do takiego zadania jak już nie któryś RTOS (o cenie będącej ułamkiem procenta ceny całego projektu, choć darmowe też są) to chyba lepiej było jakieś BSD dać…
Możesz swoją wiedzę wielkiego programisty przelać w projekcie PW-Sat2 – polski satelita studencki ;)
Zobacz http://www.pw-sat.pl
Na komputerze pokładowym będzie FreeRTOS
młody programista + c++ = nieszczęście.
Pracuję od dawna w automotive i obserwuję młodych ambitnych programistów którzy dołączają do zespołu to często mają bardzo duże mniemanie o sobie i swoich zdolnościach. Ile to razy słyszałem „a po co sprawdzać czy przydział pamięci zakończył się sukcesem?” i wiele innych kwiatków. Na szczęście w mojej branży stosuje się standard MISRA, który dość ładnie mówi co programista może a czego nie. Innym problemem jest używanie języka C++ w aplikacjach systemowych lub wręcz niskopoziomowych. C++ jest bardzo skomplikowanym językiem i czyha w nim wiele pułapek chociażby związanych z metodami oznaczonymi jako inline przy dziedziczeniu o których początkujący nie zdaje sobie problemu i traktuje ten język jak c z dodanymi funkcjami obiektowymi. Kiedyś było jasne że C był językiem systemowym i do niskopoziomowego oprogramowania a C++ do aplikacji.
Przeceniasz MISR’ę. Robi co może ale nie jest rozwiązaniem problemów które powinny być rozwiązane testami. Z C++ także da się żyć przy programowaniu niskopoziomowym. Co do złożoności zgadzam się. C++ jest złożony. Trzeba wiedzieć jak ten język funkcjonuje aby stosować go i wydajnie i bezpiecznie. Jednak się da (łaziki marsjańskie oprogramowane w C++).
Pojawia się pytanie, czy twórcy zapomnieli rzeczywiście o rotacji logu (przecież powszechnej w systemach *nix) i watchdogu (co jest obowiązkiem w takich systemach wbudowanych)?
Właśnie – watchdog, etc… To podstawa jest. A tu taka fuszerka. WTF?
Zapomniał wół, jak cielęciem był ;)
Przemysław: nie zapomniałem, taki sam byłem dlatego uczulam młodszych kolegów na różne błędy. Problem polega jednak na tym, że czasami w mniejszych firmach lub gdzie nie ma doświadczonych programistów łatwo można wpaść w pułapkę bo taki młody zdolny programista może zechcieć użyć niewłaściwego narzędzia (np. języka) do wykonania zadania.
W tym projekcie zabrakło wiedzy i doświadczenia, po pierwsze nie pomyśleli o stabilności połączenia co było do przewidzenia, po drugie z tego co widzę to nie zapewnili właściwej ochrony oprogramowania chociażby w postaci odpowiednich watchdogów czy 'heartbeatów’. To nie są jakieś wymyślne mechanizmy a w zasadzie standard praktycznie w każdym urządzeniu. Tak to jest jak się idzie na łatwiznę, weźmie się linuxa, poinstaluje programy i nawet nie zrobi testów długoterminowych. Mają wielkie szczęście że udało im się odzyskać kontrolne nad tym.
Jezeli jest młody i słucha to jeszcze nie jest źle. Najgorzej jak ktos przecenia swoje możliwości, powtarza wciąż te same błędy i zabiera sie za rzeźbienie w uC. Potem wychodzi ze cos nie działa, ale przeciez kod jest dobry wiec to inne elementy musza być winne.
W sumie niewielu jest ludzi którzy zastanawiają sie jak działa kompilator.
Przy tak niestabilnym polaczeniu, lepiej bylo uzyc mosh’a :)
Musieliby najpierw go na satelicie zainstalować… :x
„bezpieczniej będzie po prostu raz na dobę restartować satelitę ręcznie”
4 8 15 16 23 42
@Wacri: wyksztalceni i doswiadczeni ludzie tez popelniaja bledy!
@kaczy – i cały film nabrał sensu :)
Czemu punktu montowania /data nie dali na innej niż systemowa partycja??? Skończyłoby się tym że aplikacja raportująca nie mogła by zapisywać danych i nie zawiesiłoby to całego systemu.