Łatanie oprogramowania na miliard Mil

Byłem twórcą oprogramowania systemu przełączania telefonów publicznych, które ma dość poważne ograniczenia dotyczące niezawodności, dostępności, przetrwania i wydajności, które zbliżają się do tego, czego potrzebują systemy kosmiczne. Nie pracowałem na statkach kosmicznych (chociaż pracowałem z wieloma byłymi programistami wahadłowców, gdy w IBM), i nie jestem zaznajomiony z VXworks, systemem operacyjnym używanym na wielu statkach kosmicznych (w tym łazikach marsjańskich, które mają fenomenalny rekord operacyjny).

Jeden z podstawowych wymagania dotyczące łatkowalności polega na tym, że system powinien być zaprojektowany od podstaw do łatania. Obejmuje to strukturę modułów, dzięki czemu można dodawać nowe zmienne i zastępować metody bez zakłócania bieżących operacji. Często oznacza to, że zarówno stary, jak i nowy kod dla zmienionej metody będzie rezydentem, a operacja łatania po prostu aktualizuje wektor dyspozytorski dla klasy lub modułu.

Jest to po prostu obowiązkowe, aby oprogramowanie do łatania (i un-patchowania) było zintegrowane do systemu operacyjnego.

Kiedy pracowałem nad systemami telefonicznymi, Zwykle używaliśmy funkcji łatania i wymiany modułów w systemie do ładowania i testowania naszych nowych funkcji, a także poprawek błędów, na długo przed zgłoszeniem tych zmian do buildów. Każdy programista w ramach swojej pracy musi czuć się komfortowo z łataniem i wymianą modułów. Buduje poziom zaufania do tych komponentów i upewnia się, że kod łatania i wymiany jest wykonywany rutynowo.

Testowanie tych systemów jest o wiele bardziej rygorystyczne niż cokolwiek, co kiedykolwiek spotkałeś w jakimkolwiek innym projekcie. Kompletne i częściowe makiety systemu wdrożeniowego będą łatwo dostępne. Prawdopodobnie pojawią się również środowiska maszyn wirtualnych, w których można uruchomić i przetestować pełne obciążenie. Plany testowe na wszystkich poziomach powyżej testu jednostkowego będą pisane i formalnie weryfikowane, podobnie jak formalne kontrole kodu (a te będą również rutynowe).

Tolerancja błędów projektowanie systemu, w tym projektowanie oprogramowania, ma zasadnicze znaczenie. Nie wiem dokładnie o systemach kosmicznych, ale coś w rodzaju klastrów wysokiej dostępności jest prawdopodobnie standardem, z dodaną możliwością uruchamiania zarówno zsynchronizowanych, jak i niezsynchronizowanych, oraz z możliwością przesyłania informacji między stronami podczas przełączania awaryjnego. Dodatkową zaletą tej struktury systemu jest to, że można podzielić system (jeśli to konieczne), przeładować nieaktywną stronę z nowym obciążeniem oprogramowania i przetestować go w produkcji system bez podłączenia do sieci systemowej lub magistrali. Gdy będziesz mieć pewność, że nowe oprogramowanie działa poprawnie, możesz po prostu przełączać w tryb awaryjny.

Podobnie jak w przypadku patchingu, każdy programista powinien wiedzieć, jak wykonywać przełączanie awaryjne, i powinien je wykonywać zarówno podczas opracowywania, jak i testowania. Ponadto programiści powinni znać każdy problem z aktualizacją oprogramowania, który może wymusić przełączanie awaryjne, i powinni wiedzieć, jak pisać poprawki i wymianę modułów, które unikają wymaganych przełączników awaryjnych możliwe.

Ogólnie rzecz biorąc, systemy te są projektowane od podstaw (sprzęt, system operacyjny, kompilatory i ewentualnie język programowania) dla tych środowisk. Nie uznałbym systemu Windows, Mac OSX, Linuksa ani żadnego innego wariantu Uniksa za wystarczająco solidny. Częścią tego są wymagania w czasie rzeczywistym, ale cały problem niezawodności i przetrwania jest równie krytyczny.

Aktualizacja: jako kolejny punkt zainteresowania, oto blog jednego ze sterowników łazika marsjańskiego. To da ci perspektywę na codzienne życie utrzymania operacyjnego statku kosmicznego. Fajne rzeczy!