SpaceX – Josh
Całe oprogramowanie autonomiczne na poziomie aplikacji jest napisane w  C++. Generalnie używamy technik programowania obiektowego z C++, chociaż staramy się, aby wszystko było w miarę możliwości proste. Używamy bibliotek open source, przede wszystkim standardowej biblioteki C++, a także kilku innych. Niemniej ograniczamy się do korzystania jedynie z bibliotek open source o bardzo wysokiej jakości i często decydujemy się na tworzenie własnych bibliotek, gdy jest to wykonalne, dzięki czemu możemy sami kontrolować jakość kodu. Jeśli chodzi o obsługę błędów, istnieje wiele różnych aspektów tego zagadnienia. Z błędami w komputerach wywołanych promieniowaniem radzimy sobie poprzez posiadanie wielu redundantnych komputerów i głosowanie na temat wyniku. Błędy w czujnikach są obsługiwane przez posiadanie wielu różnych czujników. Błędy w transmisji danych są obsługiwane za pomocą kodów wykrywających i korygujących błędy, które dołączamy do danych. Oprogramowanie zdecydowanie składa się z wielu małych modułów, a ich architektura była jedną z głównych rzeczy, nad którymi pracowałem. W projekcie istnieje hierarchia od elementów niskiego poziomu, przez podsystemy, aż po cały pojazd. Różne podsystemy są na ogół od siebie odizolowane, czasami w tym samym komputerze, czasami na różnych komputerach, z niewielkimi interfejsami pomiędzy nimi. Nie jestem pewien, ile czasu zajęłoby nam przepisanie całego kodu od nowa. Nie planujemy go usuwać w najbliższym czasie.

SpaceX – Sofian
1. Tak, używamy Chromium i używamy reaktywnej biblioteki, którą opracowaliśmy sami.

SpaceX – Jeff
2. Symulator dokowania jest całkowicie odrębnym kodem od tego, co faktycznie znajduje się na wyświetlaczach załogi, chociaż został on opracowany przez nasz zespół od wyświetlaczy. Zaczął się jako zabawny projekt Shane'a Mielke i Mike'a Westenhavera, zanim zdecydowaliśmy się go ukończyć i umieścić w sieci przed misją Demo-2.
3. Możemy uruchamiać i uruchamiamy na Ziemi dokładnie ten sam kod, który jest wyświetlany na ekranach załogi. Jedynym ograniczeniem jest to, że z powodu limitów w naszym budżecie częstotliwości, na Ziemi niekoniecznie dostajemy wszystkie dane telemetryczne, do których jest dostęp w kokpicie. Moglibyśmy, ale generalnie priorytetem jest pozyskiwanie innej krytycznej telemetrii.
4. Zdecydowanie chcielibyśmy udostępnić zrzuty ekranu wyświetlaczy załogi w wysokiej rozdzielczości. Zobaczymy, czy uda nam się dostać pozwolenie, żebyśmy mogli pokazać wam to, co Bob i Doug mogli zobaczyć z bliska.

SpaceX – Matt
5. Technologia używana w wyświetlaczach załogi (zwłaszcza mapy i alarmy) stworzyła podstawę naszego interfejsu użytkownika dla pierwszej pary satelitów Starlink (Tintin). Od tamtego bardzo się on rozrósł, ale świetnie było widzieć Boba i Douga używających czegoś, co dla nas też było w jakiś sposób znajome.

SpaceX – Sofian
Wykorzystanie Chromium i JavaScriptu w środowiskach krytycznych dla misji to popularne pytanie. Abym mógł odpowiedzieć na nie jasno, musimy zrozumieć, że Chromium w tym kontekście jest używane wyłącznie jako silnik renderujący interfejs użytkownika. Warstwa oprogramowania odpowiedzialna za lot, która zajmuje się interakcją z wyświetlaczami, wraz z odpornością na błędy, jest dobrze zdefiniowana i znajduje się całkowicie poza obszarem odpowiedzialnym za wyświetlacze. Tak czy inaczej, wykorzystujemy ten sam proces rozwoju kodu dla pojazdu, niezależnie od stosu technologicznego. Szkolimy naszych programistów także w zakresie pisania kodu pojazdu w języku C++ i kierowania się później tą samą mentalnością w celu pisania niezawodnego oprogramowania. Bardzo poważnie podchodzimy do niezawodności i wydajności i tak jak w przypadku oprogramowania dla każdego pojazdu, testujemy je intensywnie w różnych warunkach, aby poznać wszystkie scenariusze awarii. Dysponujemy alarmami i procedurami postępowania w przypadku, kiedy takie awarie wystąpią. Do tego wszystkiego należy dodać setki godzin symulacji, uruchamiane na sprzęcie używanym podczas lotów, aby przeszkolić załogę.
Pomimo że po drodze stanęliśmy przed wieloma wyzwaniami, jesteśmy bardzo zadowoleni z naszych wyświetlaczy i co najważniejsze, nasi (jak dotąd) dwaj klienci również. Oprogramowanie naziemne Starshipa już wykorzystuje stos technologiczny z wyświetlaczy dla załogi i niedługo zaczniemy projektować interfejsy dla ludzi w Starshipie. Upewnij się, że do nas zaaplikujesz!

SpaceX – Wendy
Na niektórych zdjęciach można również zauważyć, że w kapsule tuż pod wyświetlaczami nadal znajdują się fizyczne przyciski, co zapewnia, że w przypadku gdy wyświetlacze nie mogą być wykorzystane z jakiegokolwiek powodu, astronauci mogą nadal używać przycisków sprzętowych do inicjowania krytycznych akcji, takich jak reagowanie na pożar w kabinie.

SpaceX – Wendy
Jesteśmy świadomi istniejącego długu technicznego, a ponieważ jesteśmy małym zespołem, każdy brak efektywności jest bardzo widoczny z lotu na lot. W przypadku wielu naszych pojazdów, które odbywają częste loty, staramy się inwestować w zespół operacyjny, aby upewnić się, że możemy pozbyć się tego długu technicznego i uczynić każdy kolejny lot jak najbardziej bezbolesnym. Zawsze jednak wiele się dzieje, więc przy każdej decyzji o sposobie wykorzystania naszego czasu musimy zastanowić się nad właściwą równowagą między pójściem do przodu, jeśli chodzi o nową funkcjonalność, a spaleniem istniejącego długu. 
Tak, używamy systemu ciągłej integracji (ang. continuous integration), dzięki czemu nasz kod jest zawsze testowany, ale także analizujemy te dane w czasie rzeczywistym, aby upewnić się, że metryki związane z wydajnością mieszczą się w oczekiwanym przedziale. Przypadki testowe są skonstruowane w taki sposób, że jeśli naruszymy jakiekolwiek kluczowe wskaźniki wydajności, przypadek „zawodzi" i wtedy inżynier się mu przygląda.

SpaceX – Matt
Ogólnie, jeśli chodzi o bezpieczeństwo, istnieje wiele jego warstw. Na początek zaprojektowaliśmy system tak, aby dane użytkowników były zaszyfrowane od początku do końca, aby włamanie do satelity lub bramy dostępowej przez napastnika, który chce przechwycić komunikację, było mniej użyteczne. Każdy sprzęt w naszym systemie (satelity, bramy dostępowe, terminale użytkownika) jest tak zaprojektowany, aby uruchamiać tylko podpisane przez nas oprogramowanie, dzięki czemu nawet jeśli napastnik się włamie, nie będzie w stanie uzyskać stałego punktu zaczepienia. Oprócz tego „utwardzamy" wnętrze systemu (w tym usługi w naszych centrach danych), aby utrudnić wykorzystanie w jednym obszarze luki znalezionej w innym miejscu. Nadal ciężko pracujemy, aby upewnić się, że nasz cały system jest odpowiednio utwardzony i wciąż mamy przed sobą wiele pracy (szukamy pracowników!), ale jest to coś, co traktujemy bardzo poważnie.

SpaceX – Sofian
1. Używamy C i C++ do oprogramowania związanego z lotem, HTML, JavaScript i CSS do wyświetlania i Pythona do testowania.
2. Wykorzystujemy HTML, JavaScript i CSS. W dużej mierze korzystamy z Web Components.

SpaceX – Dietrick
3. Nie używamy żadnej gotowej dystrybucji – mamy swoją własną. 
4. W każdy sposób, jaki możemy sobie wyobrazić! Testy jednostkowe, testy integracyjne w kontenerach (można je przeprowadzić na własnej maszynie z pełną symulacją fizyki) oraz pełne testy „HITL" (hardware-in-the-loop) na prawdziwym sprzęcie wykorzystywanym podczas lotu, także z pełną symulacją. Połączenie oprogramowania do lotu z symulatorem to najpotężniejsze narzędzie, jakie mamy, zwłaszcza, gdy jest ono uruchamiane na prawdziwym sprzęcie. Możemy symulować całą misję, a także wiele szczegółowych scenariuszy awarii, przy czym sprzęt znajduje się po prostu na stole w laboratorium. 
5. W pojeździe (dla wyświetlaczy Boba i Douga) jest to całkiem proste. W celu dostarczenia sygnału na Ziemię mamy kilka świetnych łącz komunikacyjnych i sieć naziemną, które pozwalają nam na bardzo szybkie pozyskiwanie dużej ilości danych z pojazdu. 
6. Dragon i Falcon nie wykorzystują żadnej technologii uczenia maszynowego, ale to nie znaczy, że takie rzeczy nie są częścią przyszłości SpaceX!
7. Tak, lądowanie rakiety jest całkowicie zautomatyzowane.

SpaceX – Wendy
8. Jeśli chodzi o Dragona, okresowo przygotowujemy wydanie, gdy pojazd jest integrowany oraz testowany i przepuszczamy wydanie przez serię testów i analiz danych. W podobny sposób przygotowujemy wydanie, gdy szykujemy się do lotu. Uruchamiamy pełen zestaw przypadków testowych dla konkretnych rewizji naszego kodu. 
9a. W przypadku Dragona mamy dużą redundancję po stronie sprzętowej (wiele komputerów, czujników, siłowników, itp.), ale także używamy oprogramowania do obsługi reakcji na awarie. Wymagania NASA są takie, że nasz pojazd musi być odporny na dwie usterki (tzn. może bezpiecznie wycofać się ze stacji kosmicznej i/lub wrócić bezpiecznie na Ziemię w przypadku pojazdów załogowych), więc robimy zarówno analizę, jak i testy, aby upewnić się, że spełniamy te zasady odporności na błędy.

SpaceX – Matt
9b. Jeśli chodzi o Starlink, zaprojektowaliśmy system tak, aby w przypadku awarii satelity szybko pasywnie deorbitowały z powodu oporów atmosferycznych (choć bardzo staramy się aktywnie je deorbitować, jeśli to możliwe). Nadal mamy pewną redundancję wewnątrz satelity, tam gdzie jest ona łatwa i ma sens, ale przede wszystkim liczymy na odporność na błędy na poziomie systemowym: wiele satelitów w polu widzenia, które mogą służyć użytkownikowi. Wystrzelenie większej liczby satelitów to jedna z głównych rzeczy, którymi się zajmujemy, więc generalnie używamy tego rodzaju odporności na usterki wszędzie tam, gdzie możemy, co pozwala nam na świadczenie jeszcze lepszych usług przez większość czasu, kiedy nie ma problemów. 

SpaceX – Matt
Podczas wprowadzania zmian oczekujemy od naszych inżynierów krytycznego myślenia (i wzajemnego kwestionowania decyzji) w temacie testów funkcjonalnych (skąd mam wiedzieć, że moja zmiana działa?) i testów regresyjnych (skąd będę wiedział, czy zepsułem coś innego, albo jeśli to zepsuje się w przyszłości?). Konstruowanie przypadków testowych, które możemy uruchomić na Ziemi, to świetny sposób, aby odpowiedzieć na te pytania i często tak robimy, ale to nie jedyny sposób.
Jeśli chodzi o Starlink, musimy myśleć o naszych satelitach bardziej jak o serwerach w centrum danych, niż o specjalnych, jedynych w swoim rodzaju pojazdach. Są pewne rzeczy, co do których musimy być absolutnie pewni (wysyłanie poleceń, aktualizacja oprogramowania, zasilanie i bezpieczeństwo sprzętowe), a zatem zasługują one na szczegółowe przypadki testowe. Ale jest też wiele rzeczy, co do których możemy być bardziej elastyczni – w ich przypadku możemy przyjąć podejście, które jest bardziej zbliżone do sposobu, w jaki rozwijane są usługi webowe. Możemy wdrożyć konkretną wersję kodu w małym podzbiorze satelitów, a następnie porównać ich działanie z resztą floty. Jeśli nie działa on tak jak powinien, można go zmodyfikować i spróbować jeszcze raz przed pełnym wdrożeniem tych zmian. Jeśli wystąpi problem podczas wypuszczania zmian, możemy zatrzymać ten proces, wycofać go i spróbować ponownie. Jest to ogromna zmiana w sposobie myślenia o pojazdach kosmicznych i jest absolutnie krytyczna, jeśli chodzi o możliwość wprowadzania szybkich iteracyjnych zmian.
Zdecydowanie znaleźliśmy miejsca, w których nasze przypadki testowe miały dziury. Posiadanie cały czas setek satelitów w przestrzeni kosmicznej doprowadziłoby do znalezienia przypadków brzegowych w każdym systemie i oznacza, że zobaczysz szalone krawędzie rozkładu Gaussa. Ważne jest, aby mieć pewność co do rdzenia systemu, który zapewnia bezpieczeństwo sprzętu, informuje o problemie, a następnie daje czas na jego naprawienie. Mieliśmy wiele przypadków, w których satelita na orbicie miał awarię, o której nigdy wcześniej nawet nie pomyśleliśmy, ale był w stanie pozostać w bezpiecznym stanie na tyle długo, żebyśmy mogli go debugować, znaleźć poprawkę lub obejście i zaktualizować oprogramowanie.
I tak, dużo pracujemy nad niestandardowymi układami ASIC w ramach projektu Starlink.

SpaceX – Dietrick
1. Na bardzo wysokim poziomie, mamy wiele komputerów w pojeździe, z których każdy jest zbudowany i skonfigurowany tak, aby być jak najlepiej przystosowanym do zadań, które są mu przypisane. Wszystkie one pracują w synchronizacji czasowej ze sobą nawzajem, a komputer pokładowy nadzoruje wszystkie operacje. Prawie wszystko można wyrazić w postaci pętli sterowania w czasie rzeczywistym: odczytujesz dane z niektórych czujników, podejmujesz decyzję (kombinacja danych z czujników i poprzedniego stanu), a następnie wysyłasz wyniki tej decyzji z powrotem do sprzętu. Dzieje się to wiele razy na sekundę. 

SpaceX – Jeff
2. Podczas każdej misji uruchamiamy w Falconie ten sam kod, chociaż wciąż dość regularnie aktualizujemy to oprogramowanie i zazwyczaj mamy nowy kod podczas każdej misji. Mamy również dane konfiguracyjne, które są dostarczane przez inne grupy inżynierskie i zazwyczaj zmieniają się przy każdej misji. Wprowadzają one zmiany w takich rzeczach, jak maszyny stanu, progi tolerancji na błędy, wiatr w dniu startu, itp., które oprogramowanie wykorzystuje do sterowania pojazdem. 
3. Oprogramowanie autonomicznego systemu bezpieczeństwa lotu (AFSS – ang. Autonomous Flight Safety System – tu chodzi o bezpieczeństwo) uruchamiane jest na zestawie mikrokontrolerów niezależnych od komputera pokładowego. Otrzymuje ono dane bezpośrednio z czujników (np. pomiary z IMU), jak również niektóre obliczone dane z komputera pokładowego. Paczka danych związana z misją służy do konfiguracji AFSS, aby wiedział on, jakie warunki mogą wymagać zakończenia lotu, np. zboczenie rakiety z kursu, całkowita utrata przyspieszenia, itp.

SpaceX – Dietrick
4. Das U-Boot, Buildroot, MUSL. Poza systemem operacyjnym i oprogramowaniem wyświetlaczy dla załogi nie używamy tak dużo oprogramowania zewnętrznego, jak mogłoby się wydawać. Staramy się, aby nasze programy były proste, zgrabne i oparte na kodzie, który bardzo dobrze rozumiemy. 
5. Zdecydowanie, chociaż nominalnie w zakresie wsparcia i możliwości dodatkowej kontroli. Spędzamy dużo czasu na przeglądaniu danych z samego pojazdu przed rozpoczęciem misji i mamy osoby z zespołu oprogramowania w centrum kontroli misji podczas wszystkich istotnych faz lotu, na wypadek, gdyby coś się pojawiło. Mamy świetny zespół od treningów przed misjami, który atakuje naszych operatorów w centrum kontroli różnymi scenariuszami podczas symulacji i mamy nadzieję, że prawdziwy dzień startu będzie o wiele bardziej nudny niż te symulacje! Cieszę się, że mogę powiedzieć, że dla misji Demo 2 do tej pory tak jest! 

SpaceX – Wendy
1. Dla każdego pojazdu mamy symulator typu „hardware in the loop” (cały ważny dla misji sprzęt plus symulacja fizyki i wskazań czujników), w którym uruchamiamy ogromny zestaw testów, zanim jeszcze wgramy oprogramowanie do samego pojazdu, także przed lotem. Po każdych zmianach w oprogramowaniu (które zdarzają się nader często podczas rozwoju pojazdu) upewniamy się, czy przeszło ono testy jednostkowe kodu, testy funkcjonalne, by upewnić się, że wszystko działa tak jak należy, jak i testy całego systemu dla różnych faz misji, zarówno dla przypadków nominalnych jak i innych.
2. Obecnie nie, ale od czasu do czasu pojawia się on w naszych rozmowach na wewnętrznych kanałach chatu. 
3. Świetne pytanie – jest bardzo ważna, a tworzenie odpornych na awarię systemów opiera się na poprawnej synchronizacji pomiędzy wszystkimi komputerami pokładowymi. Dla wolniej reagujących podsystemów, jak np. podtrzymywanie życia lub kontrola temperatury, odpowiedź może przyjść trochę później (rzędu kilku sekund, w zależności od przyjętego marginesu).
4a. W przypadku Dragona są to setki gigabajtow podczas typowej misji i po każdym locie sporo czasu poświęcamy na analizę tych danych, by mieć pewność, że system zachowuje się tak, jak byśmy sobie tego życzyli. 

SpaceX – Matt
4b. Jeśli chodzi o Starlinka, obecnie generujemy ponad 5 terabajtów danych dziennie! Aktualnie aktywnie zmniejszamy ilość danych wysyłanych przez każde urządzenie, ale też jednocześnie szybko zwiększamy ilość urządzeń (i użytkowników) w samym systemie. Co do analizy, wykrywanie problemów na pokładzie urzędzenia to jeden z najlepszych sposobów, by zmniejszyć ilość telemetrii, którą musimy wysłać i zapisać (wysyłamy tylko to, co nas interesuje). System ostrzegania, którego używamy, jest taki sam dla Starlinka, jak i dla Dragona.

SpaceX – Sofian
1. Nie, nasz sprzęt nie jest taki sam jak w Teslach.
2. Zgadza się, używamy Chromium jako silnika renderowania dla interfejsu ekranów. Ten projekt zaczął się jako prototyp symulatora do pokazania naszej wizji designu ludziom z NASA. Spróbowaliśmy później uruchomić go na komputerze Dragona i po pewnych modyfikacjach działał całkiem dobrze. Nabraliśmy więcej przekonania do tego stosu technologicznego wraz z rozwojem prototypu i później zaprojektowaliśmy całe oprogramowanie lotu z myślą o tym rozwiązaniu. Spodobały nam się wszystkie nowoczesne funkcje, które są domyślnie dostępne w przeglądarkach, odpowiadało nam także to, że mieliśmy dostęp do ludzi znających ten stos technologiczny. Chyba chodzi o to, że nie boimy się tu w SpaceX robić rzeczy odrobinę inaczej. Wolimy sami rozwiązywać problemy od podstaw, zamiast po prostu bazować na branżowych standardach. 
3. Używamy dedykowanego czterordzeniowego procesora o mocy obliczeniowej podobnej do pięcioletniego telefonu. 
4. Oczywiście, że gramy w KSP :) 
5. Jeszcze tego nie zrobiliśmy, ale nie widzę przeszkód, by stało się to w przyszłości. Głosujcie na swoją ulubioną grę! 

SpaceX – Josh
Tak, używamy Linuxa, z poprawką PREEMPT_RT, aby uzyskać lepszą wydajność obsługi czasu rzeczywistego. Nie używamy żadnych zewnętrznych dystrybucji, tylko korzystamy z własnej kopii jądra i powiązanych narzędzi. W przeciągu lat zrobiliśmy kilka małych poprawek do jądra, ale w większości jest ono niezmienione. Wyjątkiem jest tu kilka własnych sterowników do komunikacji z sprzętem. Używamy wielu różnych architektur. Nie mogę zdradzić wielu szczegółów poza tym, że jest to rozproszony system zbudowany z mnóstwa małych komputerów. 

SpaceX – Matt
Dla ukazania rzędu wielkości w Starlinku, każda wyniesiona paczka 60 satelitów zawiera ponad 4000 komputerów opartych na Linuxie. Znajdująca się w tej chwili w kosmosie konstelacja ma ponad 30000 Linuxowych instancji (i ponad 6000 mikrokontrolerów). A w związku z tym, że nasza infrastruktura Linuksowa jest też współdzielona z Falconem i Dragonem, to oba czerpią korzyść z tego, że łącznie mamy ponad 180 lat czasu testów na orbicie.

SpaceX – Jeff
Zdobądź wykształcenie informatyczne (lub jakieś podobne). Poświęć czas, by mieć pewność, że naprawdę wiesz jak działają różne rzeczy – najlepsi inżynierowie w SpaceX to ci, którzy są dociekliwi w skrupulatnie chcą zrozumieć, jak działa ich kod, jak działa sieć, jak działa Linux, jak działa sprzęt, itp. Zdobądź praktyczne doświadczenie budując rzeczy i rozwiązując trudne problemy, albo poprzez projekty w ramach hobby albo na stażu (w SpaceX!). 
Nasi inżynierowie oprogramowania są głównie w Seattle i Hawthorne, ale niektórzy pracują też z naszych ośrodków w Teksasie. Jeśli poważnie myślisz o dołączeniu do SpaceX, to my zawsze szukamy świetnych inżynierów, skontaktuj się więc – nie zaszkodzi porozmawiać i sprawdzić, czy da się coś z tym zrobić. 
Przygotowanie na sytuacje awaryjne przyjmuje w oprogramowaniu różne formy. Jak już mówiliśmy, potrajamy praktycznie wszystko więc jesteśmy odporni na utratę dowolnego jednego komputera pokładowego, sensora, serwomechanizmu, itp. w Falconie i dowolnych dwóch w Dragonie. Na poziomie systemowym Falcon i Dragon są tak zaprojektowane, że utrata np. silników napędowych lub manewrowych może być dopuszczalna, a nasze algorytmy to zrekompensują. Możemy też uwzględnić niektóre sytuacje awaryjne w naszych maszynach stanów. Na przykład maszyna stanów Dragona jest tak zaprojektowana, by autonomicznie przełączyć się z podejścia na ucieczkę, jeśli wystąpią pewne konkretne awarie.

SpaceX – Josh
Tak, cały zespół programistów zbierał od Boba i Douga sugestie na temat wszystkich aspektów oprogramowania. Chociaż głównie skupiali się na ekranach, panelu z przyciskami i systemie audio, Bob i Doug byli bardzo zainteresowani jak oprogramowanie działa jako całość, a zwłaszcza dodatkowymi możliwościami, które mogą okazać się niezbędne w sytuacjach awaryjnych. Ich sugestie były nieocenione przy ulepszaniu systemu.

SpaceX – Wendy
Tak naprawdę nie mam pojęcia! Mamy osobny zespół w dziale niezawodności, którego głównym zadaniem jest przygotowanie tych liczb i upewnienie się, że są one aktualizowane przy każdej zmianie w sprzęcie lub koncepcjach działania.

SpaceX – Dietrick
Dragon nie wykorzystuje sztucznej inteligencji.

SpaceX – Josh
Dragon korzysta jednak z widzenia komputerowego (rozpoznawania obrazów) do nawigacji. 

SpaceX – Sofian
LCD

SpaceX – Sofian
Ekrany dla załogi na pokładzie Dragona wykorzystują Chromium wraz z HTML, JavaScriptem i CSS. Nie korzystamy z LESS. 
Wykorzystujemy zwinne metodyki, mamy wysoki wskaźnik pokrycia testami, a także mamy testy integracyjne, które możemy uruchomić ze sprzętem wykorzystywanym podczas lotu lub bez niego. Jesteśmy też dumni z procesów ręcznej weryfikacji i dokumentowania nowej funkcjonalności, które dają nam pewność, że funkcje działają tak jak chcemy i nie ma żadnych regresji. 
Mocno wykorzystujemy Web Components. 
Używamy biblioteki do reaktywnego programowania, którą sami napisaliśmy.
Każdy członek zespołu korzysta z innego edytora, ja używam VSCode, ale mogę być trochę stronniczy. :)
Musiałbym to sprawdzić, ale ogólnie mówiąc dbamy o nasz kod i staramy się, by był czysty i czytelny. Nie spodziewałbym się w nim znaleźć żadnego potworka. Warto zauważyć, że do wszystkiego używamy linterów. 

SpaceX – Dietrick
Nie mogę wchodzić zbytnio w szczegóły konkretnych problemów, ale błędy jądra są zawsze „najzabawniejsze” i najbardziej zapadają w pamięć. Większość naszego oprogramowania sterującego jest jednowątkowa, by uniknąć problemu niedeterminizmu, jaki mogą wprowadzić wszelkie kłopoty z synchronizacją. Wiadomo jednak, że w systemie operacyjnym cały czas dzieją się różne rzeczy. Włożyliśmy dużo wysiłku, by zrobić z Linuksa niezawodną platformę do sterowania w czasie rzeczywistym, która ma znacząco wyższy stopień determinizmu, niż typowe domowe systemy operacyjne. Jak było wspomniane wcześniej, używamy łatki CONFIG_PREEMPT_RT, która nam w tym bardzo pomogła. Wciąż jednak, na wczesnym etapie rozwoju, przyłapywaliśmy system na tym, że nie działał w czasie rzeczywistym w odpowiednim stopniu, a wgryzanie się w tego typu problemy to zawsze przygoda. 

SpaceX – Jeff
Mamy wiele tradycyjnych zabezpieczeń cyberprzestrzeni, których można się spodziewać, chroniących nasze sieci korporacyjne, monitorujących zagrożenia wewnątrz i na zewnątrz naszych sieci, kampanie phishingowe, itp. Musimy również analizować potencjalne ataki na nasze pojazdy, zwłaszcza wokół ścieżek poleceń i źródła pochodzenia kodu, który trafia do pojazdów. Dysponujemy dedykowanym zespołem, który określa, w jaki sposób nasze pojazdy i satelity mogą zostać zhakowane, tak abyśmy mogli wyeliminować lub uniemożliwić tego rodzaju zagrożenia podczas budowy naszych pojazdów. W pełni wykorzystujemy również statyczną i dynamiczną analizę naszego kodu. ITAR w większości przypadków ogranicza to, czym możemy się dzielić – przepraszam z góry, jeśli nie możemy odpowiedzieć na wszystkie wasze pytania. Pracujemy nad tym, aby wkrótce uruchomić system nagród za zgłoszone błędy.

SpaceX – Josh
Niestety nie mogę zagłębić się w szczegóły dotyczące algorytmów lądowania F9. Linux jest używany tylko do uruchomienia naszych aplikacji i interakcji ze sprzętem. Całość zarządzania błędami i redundancja obliczeniowa jest obsługiwana na poziomie aplikacji przez opracowane przez nas specjalne oprogramowanie. Synchronizacja czasowa korzysta z kombinacji rozwiązań sprzętowych i programowych, trochę standardowych, trochę naszych własnych. 

SpaceX – Jeff
Pamiętam, że podczas prac nad F9-14 byłem w boksie Elona informując go, że nie ma szans, żebyśmy ogarnęli cały nowy kod lądowania pierwszego stopnia na czas przed planowanym za dwa tygodnie startem. Po namyśle spojrzał na Larsa Blackmore’a, który był tam z nami i zapytał, jakie będzie prawdopodobieństwo lądowania jeśli wdrożymy ten kod, Lars stwierdził, że ok 90%. Parafrazując, Elon spojrzał na nas i w zasadzie zapytał „czy możecie mi dać 50%”? Powiedziałem, że w ciągu dwóch tygodni na pewno możemy napisać wystarczająco dużo logiki, żeby osiągnąć 50% prawdopodobieństwo lądowania! Nie wylądowaliśmy F9-14 (widać to na filmiku z nieudanymi próbami), ale WIELE się nauczyliśmy i odegrało to kluczową rolę w udanym lądowaniu F9-21. Kluczowym elementem naszego sukcesu jest chęć poniesienia porażki w sposób nienarażający misji, pod warunkiem ciągłej nauki na naszych własnych błędach.

SpaceX – Sofian
Przestrzegaliśmy zasad projektowania skoncentrowanego na człowieku (ang. Human Centered Design), zaczynając od zdefiniowania głównych zasad przewodnich, które ściśle odpowiadają wizji Dragona, jako w pełni autonomicznego statku kosmicznego XXI wieku. Jednym z przykładów jest określenie minimalnej interakcji załogi jako kryterium sukcesu (tj. paradygmat „nie naciskaj przycisku”). Uważamy, że dobre zaprezentowanie informacji oznacza minimalizowanie wymaganej interakcji potrzebnej do monitorowania i kontrolowania statku. Ogólnie rzecz biorąc, oparliśmy projekt na szczegółowym zrozumieniu zadań załogi, jej możliwości, potrzeb w zakresie świadomości sytuacyjnej i warunków środowiskowych w trakcie całego lotu, co pozwoliło nam skupić się na przejrzystości, prostocie i usunięciu bałaganu informacyjnego. Nasz programista/pilot, Mike Westenhaver, opracował narzędzie, które pozwoliło nam na mapowanie zadań załogi do cech i funkcjonalności wyświetlaczy, co pozwoliło nam na pełne śledzenie wymagań i sposobu ich realizacji w naszym oprogramowaniu.
W ramach naszej kampanii testowej i kwalifikacji przeprowadzamy testy pod kątem wibracji i widoczności w różnych konfiguracjach foteli. Załoga wykonała wiele symulacji w kombinezonach, wchodząc w interakcje z wyświetlaczami, mając założone rękawice.

SpaceX – Jeff
W SpaceX zdecydowanie możesz zachować równowagę pomiędzy życiem zawodowym a prywatnym. SpaceX niewątpliwie nie jest miejscem, gdzie pracuje się od 9 do 17 i czasem trzeba wesprzeć misję wieczorem lub w weekend. Tak było w przypadku misji Demo-2 i w naszej agresywnej kampanii Starshipa w południowym Teksasie (pośród wielu innych starań, które mamy w toku). Nasi ludzie zdecydowanie potrafią zrównoważyć pracę i życie rodzinne – Joshowi i Wendy niedawno narodziły się dzieci! Nie wspólne. :)  Zdecydowanie jest to coś, na czym moja drużyna i ja musimy się skupiać, ponieważ jesteśmy małym (ale rosnącym) zespołem i mamy przed sobą wielkie cele, które musimy osiągnąć.

SpaceX – Jeff
C++ używamy do wszystkich systemów kontroli pojazdów, Pythona do narzędzi, testowania i automatyzacji, a JavaScript/HTML/CSS do wyświetlaczy. Obecne naziemne wyświetlacze, które możesz zobaczyć w centrum kontroli lotów dla Falcona i Dragona, są oparte na LabVIEW, ale nasze wyświetlacze dla załogi i przyszłe naziemne wyświetlacze dla Starshipa są oparte na stosie technologii webowych. Nasze systemy lotu wykorzystują niestandardowe jądro Linuxa z łatką PREEMPT_RT. 

SpaceX – Dietrick
Ciężko odpowiedzieć bez nadmiernego wdawania się w szczegóły, ale wszystko, co miało coś wspólnego z restartem jednego z naszych komputerów podczas lotu, jest zdecydowanie ciekawym przypadkiem. Ponowne uruchomienia są w pełni oczekiwane i wspierane (ze względu na obawy związane z promieniowaniem), ale są też jednym z bardziej interesujących scenariuszy, które musimy uwzględnić przy projektowaniu.

SpaceX – Wendy
Niektóre z bardziej interesujących systemowych przypadków są również wadami lub niepowodzeniami, które wymagają reakcji w wielu podsystemach, w tym obliczeniowych, komunikacji RF, podtrzymywania życia i napędu. Świetnym tego przykładem jest obsłużenie ewakuacji w czasie lotu lub pożaru kabiny – pojazd bardzo szybko przechodzi istotną rekonfigurację, co wymaga koordynacji wielu składowych naszego kodu. 

SpaceX – Wendy
Bycie częścią zespołu projektowego na uczelni to świetne miejsce do nauki! Podczas studiów pracowałam w zespole opracowującym satelitę (CUSat na Uniwersytecie Cornell) i nauczyłam się wiele o projektowaniu sprzętu, integrowaniu oprogramowania i tworzeniu strategii działania dla danej misji. Najlepsze narzędzia to chęć do nauki i chęć do brudzenia sobie rąk nauką. Projekty poboczne to także świetny sposób i coś, co na pewno bierzemy pod uwagę przy przeglądaniu CV podczas procesu zatrudniania! 

SpaceX – Jeff
Jak pewnie da się zauważyć na zdjęciach Boba i Douga przy kokpicie, mamy dużo fizycznych przycisków do wszystkich poleceń awaryjnych, takich jak przerwanie podejścia do stacji, czy awaryjna deorbitacja. Ponadto mamy fizyczne przyciski „Wykonaj” oraz „Anuluj” dla większości komend, które można zainicjować z poziomu wyświetlacza. Ostatecznie byliśmy w stanie spełnić wszystkie wymagania NASA dotyczące dotykowego sprzężenia zwrotnego, niezawodności, itp. i wszyscy jesteśmy naprawdę zadowoleni, że mogliśmy wprowadzić ten rodzaj nowoczesnego interfejsu do naszego bardzo nowoczesnego statku kosmicznego.

SpaceX – Sofian
Bob i Doug ściśle współpracowali z zespołem SpaceX od początku programu. Spędzili dużo czasu w Hawthorne z zespołami projektującymi pojazd. Wnieśli bogactwo doświadczeń, obejmujących wiele lotów wahadłowców i byli hojni w dzieleniu się nimi. To powiedziawszy, na uznanie zasługuje fakt, że przyszli z otwartym umysłem i z chęcią zaakceptowania, że wiele rzeczy jest robionych w tym pojeździe inaczej. Wszyscy widzimy ich teraz w ich wymyślnych skafandrach kosmicznych lub robiących salta w kosmosie, ale ci faceci poświęcili mnóstwo godzin latając do Hawthorne, spędzając czas z dala od rodziny, szkoląc się, a jednocześnie dzieląc się spostrzeżeniami i robiąc to wszystko z uśmiechem i bez narzekania. Ich etyka pracy jest prawdziwie inspirująca i to jest to, co sprawia, że robią to, co robią.
Nie możemy się doczekać sprawozdania w Hawthorne po ich powrocie – jestem pewien, że będą mieli dla nas mnóstwo uwag. Zwłaszcza Bob. On zawsze je ma. :)

SpaceX – Josh
Tak, używamy filtrów Kalmana w niektórych przypadkach. Korzystamy też ze znacznie prostszych rozwiązań przy wielu sensorach, jak np. zwykłe sprawdzanie sensowności albo filtr dolnoprzepustowy. Ogólnie rzecz biorąc nasze podejście do obsługi błędów odczytu czujników polega na posiadaniu wielu takich samych sensorów i łączeniu tego co zwracają w odporny na pomyłki sposób, tak by zepsute czujniki nie mogły doprowadzić do niebezpiecznego zachowania się statku. 

SpaceX – Josh
Używamy łatki PREEMPT_RT do Linuksa, ale tak poza tym to nie modyfikowaliśmy go, z wyjątkiem dodania kilku własnych sterowników. Tolerancję na promieniowanie i błędy obsługujemy poprzez korzystanie z kilku komputerów działających równolegle i wybieraniu tego wyniku, który zwróciła większość z nich. Jeśli jeden z nadmiarowych komputerów ulegnie uszkodzeniu z powodu promieniowania, to nie wpłynie to generalnie na całość systemu. Uszkodzony komputer może zostać uruchomiony ponownie i wcielony do systemu, jak tylko wróci do pracy, co pozwala odzyskać poprzedni poziom odporności na błędy.

SpaceX – Dietrick
Dragon może robić tak wiele fajnych rzeczy, że trudno wybrać jedną z nich. Ale myślę, że nasze dwa ostatnie loty naprawdę pokazały, jak wszechstronny jest ten pojazd: potrafi poradzić sobie ze skomplikowanymi, delikatnymi, manewrami w mikrograwitacji w pobliżu ISS, a także może odlecieć na bezpieczną odległość w czasie ewakuacji, z dużymi przeciążeniami podczas lotu naddźwiękowego w najgrubszych warstwach atmosfery.

SpaceX – Josh
Chociaż mamy nadzieję, że nigdy nie będzie on używany z załogą na pokładzie, myślę, że system ucieczki jest jedną z najfajniejszych części Dragona. Pamiętam, że kiedy oglądałem na żywo test systemu ewakuacji z platformy startowej na Cape Canaveral, byłem zszokowany tym, jak szybko pojazd uciekł z platformy. (https://youtu.be/1_FXVjf46T8) Równie niesamowite było to, co zobaczyłem w teście systemu ewakuacji w czasie lotu. Dragon płynnie oddzielił się od Falcona 9, oddalając się na dużą odległość, podczas gdy Falcon 9 eksplodował pod nim. Wyglądało to jak film sci-fi, z wyjątkiem tego, że działo się to naprawdę! (https://youtu.be/mhrkdHshb3E?t=1167) 

SpaceX – Matt
Narzędzia i koncepcje są takie same, a wielu inżynierów w zespole pracowało przy obu projektach (w tym ja), ale bycie naszym własnym klientem przy Starlink pozwala nam działać nieco inaczej. Sprzęt Starlink jest dość elastyczny – aby działał, potrzeba olbrzymiej ilości oprogramowania, a drobne ulepszenia w oprogramowaniu mogą mieć ogromny wpływ na jakość świadczonych przez nas usług i liczbę osób, które możemy obsłużyć.
W tego typu projektach tempo innowacji jest najważniejsze. Spędziliśmy mnóstwo czasu na tym, aby aktualizacja oprogramowania naszej konstelacji była łatwiejsza, bezpieczniejsza i szybsza. Aktualizujemy oprogramowanie działające na wszystkich naszych satelitach mniej więcej raz w tygodniu, a także przeprowadzamy kilka mniejszych wdrożeń. Zanim wystrzelimy partię satelitów, zawiera ona zazwyczaj starsze oprogramowanie niż reszta konstelacji! Usługi naziemne są równie ważne – to one w dużym stopniu sprawiają, że system działa, a my wprowadzamy nowe wersje kilka razy w tygodniu, lub nawet częściej.
A co do deorbitacji – satelity są zaprogramowane w taki sposób, aby przechodziły w stan dużego oporu aerodynamicznego, jeśli nie otrzymają kontaktu z systemu naziemnego przez dłuższy czas. Dzięki temu atmosfera może je ściągnąć na dół w bardzo przewidywalny sposób.

SpaceX – Wendy
Dla misji Dragona zawsze mamy unikalną konfigurację na dzień startu, zawierającą parametry naprowadzania i nawigacji. Jest ona jednak obsługiwana jako konfiguracja programu, więc nie wymaga zbyt wielu zmian w oprogramowaniu, a różni inżynierowie odpowiedzialni za swoje części systemu sami wprowadzają zmiany. Poza tym, zależy to głównie od tego, czy dana misja ma nowe wymagania (np. nowe możliwości, które wprowadzamy ze względu na żądanie wewnątrzfirmowe lub pochodzące od NASA) lub czy podejmujemy się aktualizacji sprzętu.

SpaceX – Josh
Wszystkie nasze komputery pokładowe używają Linuksa (z łatką PREEMPT_RT) albo mikrokontrolerów, na których uruchomiony jest bezpośrednio kod niskiego poziomu (ang. bare-metal code), W przypadku aplikacji działających na Linuksie zwracamy uwagę, aby poprawnie skonfigurować priorytety wątków kernela i procesu, aby uniknąć inwersji priorytetów. Generalnie piszemy nasz kod w sposób, który maksymalizuje determinizm, np. unikając alokacji pamięci podczas wykonywania programu, czy pętli o nieokreślonej długości. Ponadto dysponujemy telemetrią, która wskazuje wydajność wszystkich naszych procesów, aby zapewnić dotrzymywanie przez nie terminów we wszystkich fazach lotu, nawet w obecności nieoczekiwanych lub przekraczających limity danych wejściowych.

SpaceX – Dietrick
Nasz zespół wywodzi się ze wszystkich środowisk (poważnie!), ale zauważyliśmy szczególne podobieństwa pomiędzy tym co robimy, a tworzeniem gier komputerowych. Istnieje wiele podobnych problemów skoncentrowanych na wydajności i obliczeniach w tych dwóch dziedzinach. Ale to absolutnie nie jest wymóg – ja na przykład nigdy profesjonalnie nie tworzyłem gier komputerowych.
Aby otrzymać swoją pierwszą (lub jakąkolwiek) pracę jako inżynier oprogramowania, dwie ważne rzeczy, na których należy się skupić, to: a) twoje algorytmy i struktury danych oraz b) rozumienie, jak działa komputer, nawet na najniższych poziomach. Nawet jeśli na co dzień nie grzebiesz w sterownikach, stosie sieci, czy asemblerze, zrozumienie jak to wszystko do siebie pasuje, pozwoli Ci na rozwiązanie każdego problemu, który napotkasz.

SpaceX – Dietrick
Pierwszą rzeczą, która przychodzi na myśl jest to jak wyjątkowo bezlitosne może być nasze środowisko produkcyjne. Pracowałem w kilku miejscach z wieloletnimi cyklami modelu kaskadowego (ang. waterfall), w innych z cotygodniowymi wdrożeniami i hotfixami („ups, zepsułem to!”) na żądanie. SpaceX nie jest żadnym z nich. Tutaj koniecznym jest skupienie się na tworzeniu oprogramowania, które będzie działać poprawnie za pierwszym razem, gdy trafi do przestrzeni kosmicznej. Oznacza to dążenie do prostych i niezawodnych rozwiązań wszędzie tam, gdzie to możliwe oraz wiele, wiele testów i symulacji. 

SpaceX – Wendy
Robimy jedno i drugie! W przypadku Dragona przechodzimy przez każdy rodzaj awarii, która ma wpływ na oprogramowanie krytyczne dla bezpieczeństwa w pojeździe. Używamy kombinacji testów jednostkowych, testów na poziomie komponentów, aby zapewnić, że pojedyncze i podwójne błędy powodują reakcję pojazdu w sposób, w jaki zostało to zaprojektowane. Prowadzimy również symulowane przypadki misji dla nominalnych przypadków, łącznie z przejściem przez pełny nominalny profil misji, a także z uwzględnieniem usterek w tych przypadkach w celu zapewnienia, że wszelkie współzależności międzysystemowe są dobrze zrozumiane. Testy te przeprowadzamy również w sposób ciągły za pośrednictwem naszego systemu ciągłej integracji (CI) i przeprowadzamy automatyczne kontrole danych, aby upewnić się, że nie ma żadnych nieoczekiwanych zachowań. 

SpaceX – Josh
Sam osobiście czuję ogromne poczucie odpowiedzialności względem moich współpracowników, firmy, misji i załogi za prawidłowe działanie naszego oprogramowania. Oprogramowanie steruje niemal każdym aspektem kapsuły, od odpalania silników manewrowych po wtryskiwanie tlenu, więc wiele złego może się stać, jeśli zrobimy to źle. Tekst, którym lubimy się posługiwać w SpaceX to „tylko paranoik przetrwa”. Cały czas myślimy o tym, co może się nie udać i upewniamy się, że obsługujemy każdy prawdopodobny scenariusz awarii. Nie powiedziałbym jednak, że czuję niepokój z powodu tej odpowiedzialności, ponieważ kluczowym aspektem naszego procesu jest to, że zawsze mamy co najmniej jednego partnera, często więcej, we wszystkim co robimy. Stale analizujemy, kwestionujemy i wzajemnie sprawdzamy swoją pracę. Nie zwalnia nas to z osobistej odpowiedzialności, ale oznacza, że nigdy nie jesteśmy sami i zawsze możemy liczyć na pomoc innych. 

SpaceX – Matt
Jest mnóstwo dobrych symulacji i filmików o Starlink (a zespół uwielbia oglądać to, co ludzie potrafią wymyślić). Ta, którą podesłałeś, jest świetna! Jedną z moich ulubionych jest ta (prosta, ale hipnotyzująca): https://www.youtube.com/watch?v=857UM4ErX9A 

SpaceX – Matt
Kiedy po raz pierwszy wynieśliśmy 60 satelitów na Falconie. Zaprojektowaliśmy mechanizm do wypuszczenia wszystkich satelitów na raz, ale ciężko było go zamodelować i do końca nie byliśmy pewni czy zadziała. Pamiętam, że kiedy Falcon unosił się z platformy startowej pomyślałem sobie: OK. W ciągu godziny okaże się, czy jesteśmy idiotami, bo spróbowaliśmy zrobić coś, co nigdy nie miało szans na powodzenie, czy jesteśmy geniuszami, bo zrobiliśmy coś, co jest w oczywisty sposób słuszną metodą na wypuszczenie dużej ilości satelitów. Na szczęście wszystko poszło dobrze.

SpaceX – Josh
Założenie uprzęży i wspięcie się na górę Grasshoppera, by wykonać diagnostykę awioniki. Najbardziej bezpośrednie szukanie błędów, jakiego w życiu dokonałem. 

SpaceX – Dietrick
Start, który się nie odbył (27 maja) był świetną okazją do kolejnego pełnego testu wszystkich systemów, prawie aż do T-0. Podobne rzeczy robiliśmy w poprzedni weekend, ale zawsze świetnie jest mieć więcej danych. Spędziliśmy kilka kolejnych dni na sprawdzaniu i ponownym sprawdzaniu tego, czego dowiedzieliśmy się 27 maja, ale ostatecznie nie wprowadziliśmy żadnych zmian. Na początku roku zaczęliśmy agresywnie stabilizować kod i w zasadzie od kilku miesięcy jest on bardziej lub mniej „zamrożony”.

SpaceX – Dietrick
Toaleta znajduje się pomiędzy przednim, a bocznym włazem – na „suficie”. Prawdopodobnie chcesz z niej korzystać tylko w zerowej grawitacji!

SpaceX – Sofian
Aby przetestować ręczne sterowanie, mieliśmy załogę Demo-2 (Bob i Doug) i załogę Crew-1 (Mike i Victor) w Hawthorne na tygodniowy hackaton (uznanie dla Jeffa Dextera za ten pomysł). Załoga latała symulatorami w ciągu dnia, zbieraliśmy od nich komentarze przed wyjściem i następnego dnia rano mieliśmy dla nich gotowe buildy (nowe wersje oprogramowania z wprowadzonymi zmianami – przyp. tłum). Mimo, że nie opracowywaliśmy pełnej funkcjonalności w ciągu jednej nocy, ta ciasna pętla pozwoliła nam na szybkie iteracje i osiągnięcie płynnie latającego pojazdu do końca tamtego tygodnia. Michael Hopkins wygrał nagrodę za znalezienie najlepszego błędu podczas tego hackatonu. To był niesamowity tydzień, widzieć obie załogi dokujące i latające Dragonem na naszych symulatorach. 

SpaceX – Jeff
Jeśli chodzi o „Power of 10”, to tak i stosujemy wiele z tych zasad w naszym kodzie, jak na przykład unikanie alokowania sterty w trakcie wykonywania programu. Inne, jak np. „ograniczenie długości funkcji do jednej drukowanej strony” są dość przestarzałe i generalnie unikamy drukowania naszego kodu. :)