Czy zajmowałeś się hartowaniem przestrzeni?

Bardzo chętnie studiuję najlepsze praktyki w zakresie hartowania przestrzeni. Na przykład przeczytałem (choć nie mogę już znaleźć tego artykułu), że niektóre podstawowe części łazików Marsa nie korzystały z dynamicznej alokacji pamięci, w rzeczywistości było to zabronione. Przeczytałem również, że staroświecka pamięć podstawowa może być lepsza w kosmosie.

Patrzyłem na niektóre projekty związane z Google Lunar Challenge i zastanawiałem się, jak by to było dostać kod na Księżycu, a nawet po prostu w kosmos. Wiem, że zahartowane w przestrzeni kosmicznej płyty oferują trochę zdrowia psychicznego w tak trudnym środowisku, jednak zastanawiam się (jako programista C), jak musiałbym dostosować moje myślenie i kod, gdybym pisał coś, co działałoby w przestrzeni kosmicznej?

Myślę, że najbliższe lata mogą przynieść większy wzrost w prywatnych firmach kosmicznych, naprawdę chciałbym przynajmniej mieć trochę wiedzy na temat najlepszych praktyk.

Co stanie się z programem, jeśli promieniowanie, zimno lub ciepło bombarduje płytę, która doznała uszkodzenia izolacji? Myślę, że celem jest trzymanie ludzi wewnątrz statku kosmicznego (w zakresie naprawiania lub wymiany rzeczy) i unikanie misji naprawiania rzeczy.

Ponadto, jeśli tablica utrzymuje jakiś krytyczny system, wczesne ostrzeżenia wydają się najważniejsze.

W jaki sposób zdobywa się doświadczenie dzięki testom oraz próbom i błędom (z wyjątkiem odpalenia własnego satelity?)

Oprogramowanie kosmiczne nie jest magią tajemną. Nadal używasz 0 i 1, a nie 1 i 3. Prawdopodobnie więc nie ma żadnego wpływu na opisywanie tego, co dzieje się w tworzeniu oprogramowania.

W tej chwili przychodzą mi na myśl niewielkie różnice:

• Niezwykle zorientowany na proces.
• Oprogramowanie kosmiczne zawsze będzie miało zarówno programowe, jak i sprzętowe zegary nadzorujące.
• Każdy system kosmiczny, nad którym pracowałem, był ciężkim systemem czasu rzeczywistego.
• Symulujesz (z dużą dokładnością) każdego zewnętrznego aktora systemu. Zwykle wiąże się to z budowaniem (czasem naprawdę drogim) niestandardowego sprzętu, który służy wyłącznie do testowania.
• Ogromny wysiłek i koszty spędzasz na testach formalnych.
• Klient (zwykle JPL) jest bardzo zaangażowany w proces testowy.
• Zazwyczaj używasz starych i znanych kompilatorów i środowisk programistycznych, a nie nowych.
• Recenzje kodu, recenzje kodu i recenzje kodu.
• Lepiej bardzo wygodnie przełączaj się między światem sprzętu i oprogramowania. Nie musisz wiedzieć, jak zaprojektować sprzęt, ale musisz wiedzieć, jak to działa.
• Szerokie zastosowanie sprzętu testowego, takiego jak oscyloskopy, analizatory logiczne, syntezatory i analizatory widma.
• Co najmniej 3 lokalizacje do przechowywania aplikacji. Domyślnie jest wypalany w ROM. To się nigdy nie zmieni. Pozostałe 2 dotyczą bieżącej wersji i następnej / ostatniej wersji.
• Analiza awarii (MTBF) jest naprawdę ważna.
• Nadmiarowe systemy i plany przełączania awaryjnego dla krytycznych komponentów.

Właśnie natknąłem się na twoje interesujące pytanie.

Byłem w Instrumentation Lab podczas Apollo i ponownie później, gdy nazywał się Draper Lab podczas „zimnej wojny”.

W przypadku komputera prowadzącego Apollo zastosowano rdzeń dla pamięci RAM, a dla pamięci ROM zastosowano specjalny pleciony rdzeń. Sama maszyna została wykonana w całości z bramek NOR i była taktowana dość wolno, aby zapewnić niezawodność.

Nie pracowałem bezpośrednio nad pociskami Minuteman, ale zdawałem sobie sprawę z niektórych problemów. Jeśli głowica nuklearna rozbije się w pobliżu jakiejś elektroniki, w zasadzie powoduje zwarcie. Komputer prowadzący miał czujnik promieniowania, który natychmiast wyłączał Vc, aby nic się nie wypaliło. Następnie komputer uruchomi się ponownie, po skasowaniu rejestrów.

Aby sobie z tym poradzić, komputer okresowo zapisuje swoje rejestry w rdzeniu, a po ponownym uruchomieniu uruchamia się od tego punktu kontrolnego. Aby to zadziałało, oprogramowanie (wszystkie w ASM) musiało zostać przeanalizowane, aby zobaczyć, że może przyjąć dowolną liczbę takich trafień, na dowolnej częstotliwości, bez uzyskania błędnych odpowiedzi. Nazywano to „ochroną przed ponownym uruchomieniem”. Bardzo interesujący problem, biorąc pod uwagę, że (dzięki Bogu) nigdy nie musiał być używany.

Aby uzyskać twardą niezawodność środowiska, szczególnie w C, oto kilka naprawdę konkretnych rzeczy, które widziałem.

MISRA-C: Podzbiór Automotive C. Trochę jak Ravenscar ADA / Java.

strażnicy: upewnij się, że program się nie blokuje

pamięć ecc (czasami)

sumy kontrolne: szukanie rzutowych bitów. Widziałem wszystkie trzy z nich w jednym systemie:

1) suma kontrolna programu w sposób ciągły (był w EPROMie, ale wciąż miał odwrócone bity).

2) okresowo sumuj sumę kontrolną niektórych struktur danych.

3) Okresowo sprawdzaj poprawność procesora.

4) sprawdź, czy rejestry IO mają to, co powinny w nich mieć.

4b) odczytać wyjścia na niezależne wejścia i zweryfikować.

O wiele ważniejsze niż język programowania są wymagania dotyczące systemu podstawowego (systemu operacyjnego i sprzętu). Zasadniczo musisz zapewnić (i udowodnić) deterministyczne i przewidywalne zachowanie całego systemu. Przeprowadzono wiele powiązanych badań w społeczności czasu rzeczywistego. Zdecydowanie polecam przeczytanie dwóch książek, jeśli naprawdę chcesz przestudiować ten temat: Real-Time Systems autorstwa Jane Liu i książki o tym samym tytule autorstwa Hermanna Kopetza . Pierwsza z nich obejmuje planowanie w bardzo teoretyczny sposób, podczas gdy druga z powrotem opiera się na ziemi i praktycznie obejmuje wszystkie powiązane aspekty projektowania systemu (w czasie rzeczywistym), np. Odporność na awarie.

Ponadto następujące dwa incydenty dobrze obrazują jakość problemów, z którymi muszą się zmierzyć inżynierowie oprogramowania, wysyłając coś w kosmos:

• Ariane 5 (Ponowne użycie sprawdzonego oprogramowania pod różnymi ograniczeniami)
• Mars Rover Pathfinder Reboot (Inwersja priorytetowa)

Znalazłem ten dokument (około 2009 r.) Dla standardu kodowania instytucjonalnego JPL dla języka programowania C w laboratorium niezawodnego oprogramowania (LaRS) w witrynie Jet Propulsion Laboratory .

Oto podsumowanie udokumentowanych zasad:

1. Zgodność językowa

   • Nie odchodź poza definicją języka.
   • Kompiluj z włączonymi wszystkimi ostrzeżeniami; użyj statycznych analizatorów kodu źródłowego.

2. Przewidywalna realizacja

   • Użyj weryfikowalnych granic pętli dla wszystkich pętli, które mają się kończyć.
   • Nie używaj rekurencji bezpośredniej lub pośredniej.
   • Nie używaj dynamicznej alokacji pamięci po inicjalizacji zadania.
   • * Użyj komunikatów IPC do komunikacji zadań.
   • Nie używaj opóźnień zadań do synchronizacji zadań.
   • * Jawnie przenieś uprawnienia do zapisu (własność) dla współdzielonych obiektów danych.
   • Nałóż ograniczenia na użycie semaforów i zamków.
   • Używaj ochrony pamięci, marginesów bezpieczeństwa, wzorów barier.
   • Nie używaj goto, setjmp lub longjmp.
   • Nie należy używać selektywnych przypisań wartości do elementów listy wyliczeniowej.

3. Kodowanie obronne

   • Deklaruj obiekty danych na możliwie najmniejszym poziomie.
   • Sprawdź wartość zwracaną funkcji nie void lub jawnie rzutuj na (void).
   • Sprawdź poprawność wartości przekazywanych do funkcji.
   • Użyj statycznych i dynamicznych stwierdzeń jako sprawdzeń poczytalności.
   • * Użyj U32, I16 itp. Zamiast predefiniowanych typów danych C, takich jak int, short itp.
   • Podaj wyraźną kolejność oceny w wyrażeniach złożonych.
   • Nie używaj wyrażeń z efektami ubocznymi.

4. Klarowność kodu

   • Korzystaj tylko w bardzo ograniczonym stopniu z preprocesora C.
   • Nie definiuj makr w obrębie funkcji lub bloku.
   • Nie definiuj ani nie redefiniuj makr.
   • Umieść #else, #elif i #endif w tym samym pliku, co pasujące #if lub #ifdef.
   • * Umieść nie więcej niż jedno oświadczenie lub deklarację w wierszu tekstu.
   • * Używaj krótkich funkcji o ograniczonej liczbie parametrów.
   • * Używaj nie więcej niż dwa poziomy pośredniczości na deklarację.
   • * Używaj nie więcej niż dwóch poziomów dereferencji na odwołanie do obiektu.
   • * Nie ukrywaj operacji wyłuskiwania w makrach lub typedefach.
   • * Nie używaj niestałych wskaźników funkcji.
   • Nie rzutuj wskaźników funkcji na inne typy.
   • Nie umieszczaj kodu ani deklaracji przed dyrektywą #include.

*) Wszystkie przepisy są członkowskie zasady, z wyjątkiem tych oznaczonych gwiazdką.

W komputerowych systemach komputerowych chodzi o niezawodność. Głębokie wprowadzenie w tę dziedzinę można znaleźć w Podstawowych koncepcjach niezawodności autorstwa Algirdasa Avižienisa, Jean-Claude'a Laprie i Briana Randella.

Czas rzeczywisty jest również kluczową koncepcją obliczeń kosmicznych. Jako Pankrat poleciłbym systemy czasu rzeczywistego autorstwa Hermanna Kopetza.

Aby uzyskać pragmatyczne wyczucie wyzwań związanych z obliczeniami kosmicznymi, pomyśl o:

• ekstremalne warunki w kosmosie: bardzo gorąco, gdy jest skierowane na słońce, bardzo zimno z drugiej strony, wiele promieni kosmicznych, które mogą odwrócić bity w pamięci, ogromne przyspieszenia i wibracje podczas śmiechu, ... Sprzęt do kosmosu musi być znacznie bardziej wytrzymały niż sprzęt dla wojska.

• Kiedy nastąpi awaria, z wyjątkiem Międzynarodowej Stacji Kosmicznej lub teleskopu kosmicznego Hubble'a, nikt nie przychodzi i nie zastępuje uszkodzonego systemu. Wszystko musi być naprawione od ziemi, przez maksymalną obserwowalność i dowodzenie oraz przez zapasowe systemy, na które można się przełączyć. Jest to łatwe dla satelitów Ziemi. Jest to trudniejsze w przypadku sond kosmicznych, dla których opóźnienia w komunikacji mogą trwać godzinę. Rzeczywiście, przede wszystkim wszystko musi być tak niezawodne, jak to tylko możliwe.

Czego nauczyłem się z jednego projektu, w którym uczestniczyłem jako stażysta:

Specyfikacje sprzętu ulegną zmianie, zwykle na gorsze!

Na przykład, zahartowany w przestrzeni procesor, który został użyty w projekcie, obiecano, obiecano , proszę pamiętać, że będzie działał przy 20 MHz.

Ostateczny wynik przebiegał przy 12 MHz. Starszy programista w projekcie spędził dużo czasu na przeprojektowywaniu algorytmów, aby sprostać wymaganiom systemów sterowania w czasie rzeczywistym, a większość oprogramowania telemetrycznego została przeniesiona do drugiego systemu zamiast na podstawowym procesorze.

Staraj się więc pozostawić dodatkowe zasoby dostępne w oryginalnym projekcie i nie używaj całego dostępnego procesora i pamięci.

Z perspektywy oprogramowania napisz uprzywilejowane zadanie, które od czasu do czasu losowo zamienia bity w kodzie i zobacz, jak sobie z tym radzi. To twój symulator.

Pod względem sprzętowym części będą stare, ponieważ zajmuje dużo czasu, aby uzyskać coś, co ma przestrzeń kosmiczną. Ponadto nowe części stale się zmniejszają, a im mniejsza jest cecha (pomyśl o komórce pamięci na układzie scalonym), tym bardziej podatna jest na uszkodzenie w wyniku zdarzenia radiacyjnego.

Pracowałem nad urządzeniem o znaczeniu krytycznym dla bezpieczeństwa i musieliśmy przejść przez podobne obręcze.

Mieliśmy zmienne krytyczne dla bezpieczeństwa. Była kopia odwrotności zmiennej. Po każdej pętli zmienna była sprawdzana względem jej odwrotności.

Mieliśmy test chodzących zer i zer WSZYSTKICH rejestrów. Obejmuje to licznik programów!

Przeprowadziliśmy test wszystkich kodów zestawu instrukcji mikro. Musieliśmy mieć pewność, że jeśli dodasz 2 rejestry, zostaną one dodane.

Część tego prawdopodobnie nie jest związana z programami w kosmosie, ale daje poczucie możliwości sprawdzania, czy jest to możliwe.

Wierzę, że im gorsze jest środowisko, tym więcej kodów korygujących błędy jest używanych, i istnieją pamięci ECC, które można w pewnym stopniu wykorzystać.

Jeśli można oszacować poziom błędów, można skonstruować kod korygujący błędy, który będzie w stanie obsłużyć wprowadzone błędy.

• Tak, podstawowa pamięć znajduje się na tablicach badawczych.
• Pamięć dynamiczna nie jest dobra dla systemów osadzonych. Problemy z niezawodnością.

Sądzę, że oprogramowanie ECC danych i wykorzystanie teorii informacji oraz niestandardowy moduł do rozprowadzania danych w systemie w celu zarządzania awariami pamięci będzie początkiem. Ale nie studiuję oprogramowania odpornego na działanie rad, więc nie znam go, to tylko przypuszczenie.