Awaria słynnej sondy kosmicznej

[KopalniaWiedzy.pl 317]

Słynny pojazd Deep Impact, który w 2005 roku wystrzelił specjalny pocisk w jądro komety Tempel 1, uległ poważnej awarii. Centrum kontroli utraciło z nim łączność pomiędzy 11 a 14 sierpnia. Ostatnio próbowano wprowadzić sondę w tryb hibernacji. Bezskutecznie. Jak przyznał główny naukowiec projektu EPOXI - tak nazwano misję Deep Impact po wykonaniu przezeń głównego zadania - pojazd obraca się w niekontrolowany sposób i nie może wykonywac obserwacji.

Inżynierowie znaleźli przyczynę awarii. Jest nim błąd w oprogramowaniu komunikacyjnym, który doprowadził do resetu komputera sondy. Specjaliści pracują obecnie nad przywróceniem łączności z pojazdem. Najpierw jednak muszą dowiedzieć się, w jakiej pozycji znajduje się sonda i do której z anten należy wysłać komendy. Czasu jest niewiele, gdyż Deep Impact jest zasilany z paneli słonecznych. Jeśli nie będą one ustawione w odpowiedniej pozycji, pojazd nie będzie ładował akumulatorów. Wszystko zależy od tego, czy do paneli chociaż częściowo dociera światło naszej gwiazdy. Jeśli tak, sonda będzie pracowała jeszcze przez kilka miesięcy. Jeśli nie - pozostało kilka dni na odzyskanie kontroli nad nią.

Deep Impact rozpoczęła swoją misję w styczniu 2005 roku. Jej głównym celem było zbadanie budowy jądra komety Tempel 1 poprzez wystrzelenie w jej kierunku pocisku i sfotografowanie efektów uderzenia. Misja przebiegła pomyślnie. Po jej zakończeniu Deep Impact rozpoczął misję EPOXI. W jej ramach badał planety pozasłoneczne i kometę Hartley 2. Obserwował też inne komety, a ostatnim obiektem jaki badał, była kometa ISON. Niestety, przed awarią pojazd nie przesłał zdjęć ISON.

[tommy2804 1]

Najpierw orbitalny teleskop Kepler, a teraz Deep Impact. Ostatnio jakaś czarna seria trapi urządzenia do badania przestrzeni kosmicznej...

[sator666 1]

Błąd w sofcie i cały hardware jest do niczego. Albo kiepscy programiści przy tym pracowali albo przykładają małe znaczenie do oprogamowania. A to właśnie soft jest tu naważniejszy.

[pogo 102]

Nie ma oprogramowania bez bugów. Jest tylko takie, w którym nie da się ich znaleźć w zadanym czasie.

Jakbyś im dał 100 lat na testy i poprawki to znaleźliby pewnie i tego buga, ale na pewno zostałby inny. Nie można rozwijać oprogramowania w nieskończoność, w końcu trzeba zaakceptować jego aktualny stan i przestać szukać dziury w czymś co od jakiegoś czasu wydaje się absolutnie całe.

Koszty znalezienia "wszystkich" bugów w prostym kalkulatorze mogą przekroczyć koszt wysłania człowieka na księżyc. Więc pomyśl jakie musiałyby być koszty tak dokładnego sprawdzenia softu w sondzie.

[Mariusz Błoński 184]

Bardzo pocieszające jest to, że oba urządzenia pracowały wielkokrotnie dłużej, niż miały pracować.

[radar 103]

Zastanawia mnie tylko, że "błąd w sofcie" doprowadził do "resetu komputera" i co... system czeka na wpisanie hasła do windowsa?

Wydaje mi się logicznym rozwiązanie, że system po restarcie dokonuje jakiejś autoanalizy, sprawdzenia systemów i automatycznego ustawienia się antenami w stronę Ziemi. Wiem, że jest to zadanie nietrywialne, ale wydaje się jednak "naturalne".

Chyba, że... nie mówią nam wszystkiego i "błąd w sofcie" nie spowodował restartu tylko właśnie to niekontrolowane obracanie albo to nie błąd w sofcie

[wilk 103]

Niekoniecznie musiał być tradycyjny błąd w sofcie, czyli ktoś zapomniał, że parametry funkcji trzeba podać w mph zamiast km/h, czy też jakiś segfault wyskoczył. Mimo ekranowania mogło także dość do uszkodzenia kodu. W końcu nawet u nas na Ziemi dochodzi do przekłamań z powodu promieniowania kosmicznego.

[radar 103]

Niekoniecznie musiał być tradycyjny błąd w sofcie, czyli ktoś zapomniał, że parametry funkcji trzeba podać w mph zamiast km/h, czy też jakiś segfault wyskoczył. Mimo ekranowania mogło także dość do uszkodzenia kodu. W końcu nawet u nas na Ziemi dochodzi do przekłamań z powodu promieniowania kosmicznego.

Jakby nie było nie wydaje mi się możliwym wysyłanie czegoś w miejsce, gdzie nie będzie możliwości jego naprawy bez systemów backup'ujących. Pamięć jest tak tania, i to na różnych nośnikach w stosunku do ceny całego przedsięwzięcia, że takie sytuacje powinny być brane pod uwagę. Włącznie z twardym resetem przy pojawieniu się określonych warunków.

Zaznaczam, że i tak nie wiemy co się naprawdę stało, więc trudno dywagować.

[wilk 103]

Gorzej jak resetuje się ciągle do tego samego uszkodzonego obwodu i w ten sposób zapętla. Mogę się mylić, ale przy różnych awariach czasem podawano, że to z kontroli lotów wysyłano polecenie przełączenia się na zapasowy podsystem. Przydałby się może jakiś nowy wywiad z kimś siedzącym w tym temacie, by móc zadać takie pytanie. ;-)