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?)
Odpowiedzi:
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:
źródło
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.
źródło
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ć.
źródło
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:
źródło
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:
Zgodność językowa
Przewidywalna realizacja
Kodowanie obronne
Klarowność kodu
*) Wszystkie przepisy są członkowskie zasady, z wyjątkiem tych oznaczonych gwiazdką.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło