W piątek 5 czerwca na subreddicie /r/spacex na portalu Reddit odbyło się AMA (Ask Me Anything – zapytaj mnie o cokolwiek) z udziałem członków zespołu programistów SpaceX, którzy odpowiadali na pytania internautów dotyczące oprogramowania załogowego statku Dragon.

Tłumaczenie AMA z zespołem programistów SpaceX

wtorek, 9 czerwca 2020 19:18 (edytuj)
Tłumaczenie AMA z zespołem programistów SpaceX

W piątek 5 czerwca na subreddicie /r/spacex na portalu Reddit odbyło się AMA (Ask Me Anything – zapytaj mnie o cokolwiek) z udziałem członków zespołu oprogramowania SpaceX, którzy odpowiadali na pytania internautów. Brali oni udział w tworzeniu oprogramowania, które wykorzystuje Dragon podczas lotu oraz które steruje dotykowymi wyświetlaczami wewnątrz kabiny. Wyświetlacze można było zobaczyć w akcji podczas niedawnej załogowej misji demonstracyjnej Crew Demo-2. Jako że obecnie dwaj astronauci, Robert Behnken i Douglas Hurley, dotarli już do Międzynarodowej Stacji Kosmicznej (ISS), a Dragon jest bezpiecznie zadokowany, zespół wziął udział w AMA, aby odpowiedzieć na pytania na temat Dragona, oprogramowania oraz pracy w SpaceX.

W AMA udział wzięli:

  • Jeff Dexter – starszy dyrektor ds. oprogramowania lotu i cyberbezpieczeństwa w SpaceX
  • Josh Sulkin – główny inżynier oprogramowania lotu w SpaceX, lider projektu oprogramowania załogowego Dragona
  • Wendy Shimata – menadżer oprogramowania statków kosmicznych w SpaceX, zarządza zespołem oprogramowania Dragona i pracowała nad odpornością na błędy i bezpieczeństwem Dragona
  • John Dietrick – inżynier oprogramowania lotu w SpaceX, kierujący rozwojem oprogramowania dla misji Crew Demo-2
  • Sofian Hnaide – starszy inżynier oprogramowania w SpaceX, pracował nad wyświetlaczami dla załogi przed misją Crew Demo-2
  • Matt Monson – dyrektor oprogramowania Starlink w SpaceX, wcześniej pracował przy Dragonie, obecnie kieruje rozwojem oprogramowania dla konstelacji Starlink

Poniżej znajdują się przetłumaczone pytania użytkowników Reddita i odpowiedzi zespołu programistów SpaceX.

/u/TURCIK
Gratuluję olbrzymiego osiągnięcia, dzięki za zrobienie tego AMA!
1. Jaki jest najczęściej używany język programowania podczas tworzenia oprogramowania Falcona 9 i Dragona? Czy jest to C czy C++?
2. Jakiego paradygmatu programowania używacie przy tworzeniu oprogramowania dla Falcona 9 i Dragona? Proceduralnego, obiektowego, funkcjonalnego, ich kombinacji?
3. Czy używacie jakiegoś oprogramowania open source (mam na myśli głównie biblioteki)? Jeśli odpowiedź brzmi „tak", to jakiego używacie w największym stopniu (lub jest najważniejsze czy najbardziej istotne)? Jeśli odpowiedź brzmi „nie", czy korzystacie przynajmniej ze standardowej biblioteki dostarczanej przez dany język (np. C++ STL), czy też wszystko implementujecie sami?
4. W jaki sposób wykrywacie i korygujecie błędy podczas lotu?
5. Czy oprogramowanie składa się z małych (czasem niezależnych) modułów, czy też wszystko jest zintegrowane w jednym dużym module? Na przykład, jak ścisła jest integracja modułu GNC (system służący do nawigacji i sterowania, ang. GNC – Guidance, Navigation and Control) załogowego Dragona z modułem odpowiedzialnym za środowisko w załogowym Dragonie (ciśnienie, poziom tlenu, temperatura, itp.)?
6. Jeśli mielibyście usunąć cały kod, jak byście oszacowali czas ponownej implementacji wszystkiego od zera (mając obecny zespół i zgromadzone know-how)? 1 rok? 5 lat? 10 lat? Czy uważacie, że efekt byłby lepszy od obecnej implementacji? Co zrobilibyście inaczej niż teraz?
7. Może trochę związane z #6: jak często całkowicie implementujecie moduł od początku, aby uczynić go lepszym (szybszym/czystszym/bezpieczniejszym, itp.), zamiast refaktoryzować istniejący kod?


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.
/u/zlsa
Cześć! Gratuluję perfekcyjnego startu z Bobem i Dougiem!

1. Wiadomo, że wyświetlacze załogowego Dragona wykorzystują Chromium i JavaScript. Czy korzystacie z biblioteki reaktywnej, a jeśli tak, to czy jest ona opracowana wewnętrznie, czy też jest to istniejąca biblioteka/framework?

2. Czy symulator dokowania został opracowany przez zespół pracujący nad wyświetlaczami dla załogi, czy był to osobny projekt?

3. W niektórych ujęciach z centrum kontroli misji zauważyłem interfejs użytkownika bardzo podobny do wyświetlaczy w załogowym Dragonie. Czy dokładnie to samo oprogramowanie do wyświetlaczy może być obsługiwane z serwera na Ziemi, zasilanego na żywo telemetrią z Dragona podczas lotu? Jeśli tak, to czy to oprogramowanie jest lub będzie używane do monitorowania także towarowego Dragona podczas przyszłych lotów?

4. Czy jest jakaś szansa na otrzymanie zrzutów ekranu wyświetlaczy załogi w wysokiej rozdzielczości? Jest to bez dwóch zdań najładniejszy interfejs użytkownika, jaki kiedykolwiek widziałem w przemyśle kosmicznym.

5. Jedno pytanie dotyczące Starlinka: jak stworzenie oprogramowania wyświetlaczy dla załogi wpłynęło na rozwój interfejsu Starlink dla działań SpaceX (widoki map, wizualizacje danych, itp.)? Dzięki za AMA!

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.
/u/Keavon
Czy moglibyście powiedzieć więcej o tym, w jaki sposób ekrany załogowego Dragona wykorzystują Chromium i jakie wyzwania to stworzyło? Jakie środki zastosowano w celu uzyskania odporności na błędy (przy tak ogromnej ilości kodu pod spodem) i jakie wysiłki włożono w ochronę przed skutkami promieniowania? Czy był to dobry wybór z perspektywy czasu i czy to samo webowe podejście będzie wykorzystane w przyszłości w Starshipie? Jak wyglądał proces projektowania i testowania, jeśli chodzi o user experience (UX)?
Jestem webowym front-end developerem/projektantem UX/programistą grafiki/artystą 3D/projektantem grafiki, lawirującym pomiędzy dziedzinami związanymi ze sztuką i inżynierią, a moim marzeniem jest pracować dla SpaceX, kiedy w sierpniu skończę studia. Interfejs użytkownika załogowego Dragona to dokładnie to, co mnie interesuje, chociaż obecnie SpaceX ma oferty pracy głównie dotyczące systemów wbudowanych. Jak mogę znaleźć odpowiedni projekt oprogramowania graficznego, do którego mógłbym zaaplikować? Mam pewne kontakty w SpaceX, czy są jakieś pasujące zespoły lub projekty, do których mógłbym poprosić o wysłanie mojego CV? Symulacje graficzne dla Starshipa? Coś po stronie klienta w projekcie Starlink?
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.
/u/captaincool
Jakie macie podejście do długu technicznego w waszej organizacji? Czy ciągła presja na dostarczanie produktów, z której słyną firmy Elona, uniemożliwia wam ponowne zaglądanie do dawnych projektów?
Czy monitorujecie wydajność swojego kodu? Wyobrażam sobie, że jest to krytyczny parametr projektowy dla systemu wbudowanego z krytycznymi ograniczeniami czasowymi, takiego jak wasz, więc zastanawiam się, jak wasze podejście można porównać do czegoś takiego jak przemysł gier wideo, gdzie taka praktyka jest powszechna, ale prawdopodobnie w przypadku lotów kosmicznych wymagania są bardziej rygorystyczne.
Jaki poziom rygoru jest wprowadzany, jeśli chodzi o bezpieczeństwo konstelacji Starlink? Jak bardzo my, jako zwykli obywatele, możemy być pewni, że prywatna firma mająca tysiące satelitów internetowych zapewni odpowiednie bezpieczeństwo, aby nie zostały one zdalnie przejęte przez kogoś o złych intencjach? Jeżeli zostanie to zrobione źle, może to mieć potencjalny wpływ na wiele pokoleń, więc byłoby świetnie, gdybyście mogli publicznie przedstawić swoją strategię.
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.
/u/pinpinbo
1. Z jakich stosów technologicznych korzystacie? Czy są to głównie frameworki open source, czy też rozwijane wewnętrznie?
2. Jaki jest wasz front-endowy stos technologiczny dla wyświetlacza?
3. Z jakiej dystrybucji Linuksa korzystacie?
4. Jak testujecie swoje oprogramowanie?
5. Jak sprawiacie, aby strumienie wideo były wyświetlane praktycznie w czasie rzeczywistym, bez opóźnień?
6. Czy używacie jakichkolwiek technik uczenia maszynowego (ang. Machine Learning)?
7. Czy lądowanie rakiet jest zautomatyzowane (bez kontroli człowieka)?
8. Jak wygląda cykl publikacji oprogramowania?
9. Jestem pewny, że zaimplementowaliście wiele strategii, jeśli chodzi o redundancję. Podzielicie się częścią z nich?
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. 
/u/btimar
SpaceX jest znane z testów hardware-in-the-loop.
Jaką część (w przybliżeniu) osobogodzin inżynierów oprogramowania przeznacza się na rozwój tych systemów?
Jak wygląda cykl rozwoju symulatorów lotu (np. dla systemów Falcona)? Jak często są one aktualizowane w oparciu o telemetrię? Która część lotu jest najtrudniejsza w modelowaniu?
Czy przy kilkuset satelitach Starlink na orbicie są jakieś elementy operowania pojedynczymi satelitami lub konstelacją, co do których uświadomiliście sobie, że nie są dobrze pokryte testami?
Jak głęboko sięgają testy Starlinka, jeśli chodzi o fizykę? Np. jeśli staracie się oszacować opóźnienia w komunikacji międzysatelitarnej lub pomiędzy satelitą i Ziemią, czy możecie traktować kanały radiowe jak czarną skrzynkę, czy też staracie się modelować również działanie szyku fazowanego (ang. phased array)?
Ciekawi mnie również sprzęt obliczeniowy. SpaceX słynie z tego, że buduje komponenty na własną rękę. Czy w przypadku konstelacji Starlink, celującej w dziesiątki tysięcy satelitów na orbicie, istnieją obszary, w których niestandardowe układy ASIC byłyby tańsze niż komercyjne rozwiązania dostępne na rynku? Czy są przypadki komponentów, które są „zbyt dobre" dla czasu działania satelity Starlink poniżej 10 lat (być może tolerancja na promieniowanie?), które mogłyby zostać zbudowane od nowa przy znaczącej redukcji kosztów?
Wreszcie, wszelkie wasze spostrzeżenia dotyczące projektowania systemu (sprzęt + oprogramowanie od poziomu fizyki w górę) służącego do dostarczania pakietów z minimalnymi opóźnieniami byłyby fascynujące.
Z góry bardzo dziękuję!
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.
/u/hero-sl
Gratuluję udanego startu niesamowitego statku kosmicznego! Oto moje pytania.
1. Podajcie proszę, na bardzo ogólnym poziomie, przegląd tego, jak działa program sterujący Falconem 9 i Dragonem. Jakiego rodzaju połączenia komunikacyjne są używane pomiędzy Dragonem i Falconem 9?
2. Czy oprogramowanie sterujące działające w Falconie 9 jest niestandardowo skonstruowane do każdego rodzaju misji (wystrzelenie satelity na niską orbitę, dostawy do ISS, itp.)? Czy może jest to to samo bazowe oprogramowanie z różnymi zestawami parametrów/celów/skryptów?
3. Jak działa oprogramowanie AFTS (autonomiczny system przerwania lotu, ang. Autonomous Flight Termination System)?
4. Wymieńcie proszę kilka przykładów oprogramowania open source używanego w Falconie lub Dragonie, innych niż jądro Linuxa i Chromium.
5. Czy zespoły inżynierów oprogramowania Falcona/Dragona odgrywają jakąś rolę podczas dnia startu?
Wielkie dzięki. Kontynuujcie tę niesamowitą pracę. Wszystkiego najlepszego!
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! 
/u/lucid8
1. W jaki sposób testujecie oprogramowanie przed wgraniem go do urządzeń statku?
2. Czy używacie języka programowania Rust albo chociaż czy myśleliście o tym?
3. Jak ważna jest kwestia opóźnień w różnych komponentach oprogramowania Dragona? Czy każda akcja musi być natychmiastowa czy jest może miejsce na trochę swobody?
4. Jak dużo telemetrii (w gigabajtach) zazwyczaj otrzymujecie z  Falcona/Dragona/Starlinka? Czy przepuszczacie ją przez narzędzia do uczenia maszynowego lub analizy danych?

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.
/u/Nufflee
Cześć, dzięki wam bardzo za zorganizowanie takiego fajnego AMA i gratulacje w związku z DM-2!
Mam kilka pytań:
1. Czy używacie w załogowym Dragonie sprzętu lub ekranów dotykowych z Tesli?
2. Były plotki, że interfejs załogowego Dragona działa na Chromium (opakowane w Qt), czy to prawda? Jeśli tak, to dlaczego wybraliście technologię webową zamiast interfejsu natywnego lub QT?
3. Czym różni się procesor w załogowym Dragonie od typowego procesora używanego w komputerach PC? Wiem, że jest tam wiele procesorów dla redundancji, ale jak byście porównali któryś z nich z powiedzmy desktopowym i9 9900k?
4. I najważniejsze, czy gracie w KSP?
5. Czy myśleliście, żeby dać jakieś gry w Dragonie?
Dzięki jeszcze raz i nie mogę się doczekać pierwszej misji operacyjnej załogowego Dragona w niedalekiej przyszłości.
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ę! 
/u/Shanduur
1. Z tego co wiem, wasze rakiety działają na Linuxie – ale która „mainstreamowa” dystrybucja jest najbardziej podobna do jądra, którego używacie?
2. Czy wprowadziliście jakieś ciekawe modyfikacje o których możecie nam więcej opowiedzieć?
3. Jakiej architektury procesorów używacie? ARM, MIPS, czy jakaś inna?
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.
/u/wesleychang42
Cześć SpaceXowcy, dzięki za poświęcenie na to czasu.
1. Jestem w liceum, co mogę zrobić, jeśli kiedyś w przyszłości chcę pracować jako programista w SpaceX?
2. Mieszkam daleko od Hawthorne. Czy SpaceX oferuje jakieś stanowiska na wschodnim wybrzeżu, a jeśli nie, to czy jest na to szansa w przyszłości?
3. (do Jeffa Dextera) Czy mógłbyś podać jakieś szczegóły dotyczące planów w sytuacjach awaryjnych (np. awaria silnika w trakcie wnoszenia, jakiś problem podczas lądowania, itp.)?
4. (do Josha Sulkina) Czy programiści dostawali jakieś sugestie od Boba i Douga w trakcie treningu?
5. (do Wendy Shimaty) Jak obliczacie współczynniki LOM (utraty misji) i LOCV (utrata załogi/pojazdu) dla Dragona?
6. (do Johna Dietricka) Czy SpaceX używa sztucznej inteligencji w jakiejś części oprogramowania?
7. (do Sofiana Hnaide) W jakiej technologii są wykonane ekrany w Dragonie (np. LCD, IPS, OLED, itp.)?
8. (do Matta Monsona) Kiedy twoim zdaniem Starlink zacznie korzystać z połączeń laserowych?
9. Proszę, zróbcie oficjalny SpaceXowy mod do Kerbal Space Program (to nie pytanie, ale byłoby naprawdę super, gdybyście to zrobili).
Jeszcze raz dzięki za poświęcony czas!
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. 
/u/Tchalla_
Po pierwsze gratuluję udanej misji. Mimo bardzo trudnych czasów mieliśmy okazję być świadkami tak wielkiego osiągnięcia.
Muszę przyznać, że Falcon 9 ma bardzo ładny interfejs i jako inżynier interfejsu użytkownika (UI) mam o niego wiele pytań, postaram się je w miarę możliwości streścić.
W poprzednim AMA wspomnieliście o JavaScripcie i LESS, jako narzędziach, z których korzysta wasz zespół i jestem bardzo ciekawy jak wykorzystywane są technologie webowe w SpaceX.
Gdzie wykorzystujecie JavaScript i LESS?
Jak wygląda proces tworzenia UI i jak go testujecie?
Z jakich bibliotek open source korzysta zespół SpaceX, jeśli w ogóle?
Na jakim poziomie i z jakich technologii webowych korzystacie oprócz tych wymienionych wcześniej?
Jakich edytorów kodu używacie?
Jaka jest najdłuższa nazwa metody, jaką macie w swoim kodzie?
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. 
/u/Nehkara
Jakie były najdziwniejsze błędy, na które natknęliście się podczas tworzenia i testowania oprogramowania do załogowego Dragona?
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. 
/u/eth0izzle
Do Jeffa: Jak wygląda u was cyberbezpieczeństwo? Wyobrażam sobie, że jesteście stale atakowani przez państwa czy zaawansowane trwałe zagrożenia (APT), itp., w celu kradzieży poufnej własności intelektualnej. Czy musicie przestrzegać jakichś przepisów dotyczących ITAR w tym zakresie, czy też jest to na wyższym poziomie, to co uważacie za odpowiednie?
W teorii, jak trudno byłoby zhakować rakietę? Chciałbym, abyście stworzyli system nagród podobny do Tesli i (zwirtualizowanych) systemów rakietowych.
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.
/u/_pechora_
Po pierwsze, gratulacje!
Gdzie mogę znaleźć kod/pseudokod dla algorytmu G-FOLD (algorytm lądowania Falcona 9)? Próbowałem przebrnąć przez oryginalną pracę Larsa Blackmore’a, ale dla studenta informatyki niektóre terminologie były ponad moje możliwości.
Wiem, że SpaceX używa głównie standardowych procesorów ze zmodyfikowaną dystrybucją Linuksa do swoich systemów sterowania lotem. Czy redundancja w  przetwarzaniu danych jest zarządzana przez samo jądro Linuksa, czy przez aplikację napisaną w C++, działającą w środowisku Linuksa? Jeśli to możliwe, czy możecie wyjaśnić praktyki stosowane w implementacji metodyki Lockstep na poziomie sprzętowym?
Jeszcze raz gratuluję i dziękuję za ponowne uczynienie eksploracji kosmosu czymś fajnym!
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. 
/u/MajorRocketScience
Jaka jest najbardziej szalona/niemożliwa rzecz, o którą poprosiło was kierownictwo (czytaj Elon)?
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.
/u/dfshk
Fantastyczna robota! Naprawdę uwielbiam to, co osiągnęliście. Kilka pytań:
1. Jak został zaprojektowany interfejs użytkownika? Czy przestrzegaliście jakichś konkretnych zasad projektowania? W jaki sposób uwzględniliście specyficzne warunki lotu w kosmos (wibracje, hełm ograniczający widoczność, …).
2. Czy możecie podać więcej szczegółów na temat konkretnych komponentów wizualizacji i interfejsu? Jakieś fajne pomysły, które zostały porzucone?
3. Jak testowaliście interfejs użytkownika i konkretnie obsługę dotyku przez rękawice?
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.
/u/DUKE546
Jestem inżynierem oprogramowania i moja żona nie pozwala mi aplikować do pracy w SpaceX, ponieważ uważa, że wtedy nigdy więcej mnie nie zobaczy. Czy ma rację, przyjmując takie założenie? A może da się zachować równowagę pomiędzy życiem zawodowym, a prywatnym?
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ąć.
/u/lkk270
Cześć. Dzięki, że to robicie. Jakie języki są najczęściej używane przy tworzeniu różnego oprogramowania do lotu dla Dragona i Falcona 9? Czy jest to głównie C++?
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. 
/u/xXAndrew28Xx
Jakie są najciekawsze przypadki brzegowe (ang. edge cases), które musieliście wziąć pod uwagę przy pisaniu oprogramowania do załogowego Dragona?
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. 
/u/sudoHack
Hej, chłopaki! Jestem ogromnym fanem wszystkiego, co robi SpaceX. Gratulacje za DM-2!
Jestem częścią zespołu budującego rakiety na mojej uczelni i pracuję nad awioniką. W związku z tym zastanawiałem się, jakich umiejętności/narzędzi mógłbym się nauczyć, gdybym chciał w przyszłości pracować z awioniką? W szczególności, czy moglibyście nam opowiedzieć co dzieje się za kulisami, jeśli chodzi o komputery pokładowe, z punktu widzenia programowania/oprogramowania?
Dzięki za zrobienie tego AMA!
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! 
/u/cmonachan
Czy otrzymaliście jakieś zastrzeżenia od NASA w kwestii używania nowoczesnego interfejsu oprogramowania zamiast wielu fizycznych przycisków, itp.?
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.
/u/MohanBhargava
Jak pracuje się z Dougiem i Bobem? Czy kiedykolwiek zasugerowali coś konkretnego, co z czasem przerodziło się w poważną zmianę w załogowym Dragonie? 
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. :)
/u/syedubaid086
Z jakiego algorytmu sterowania korzystacie, by korygować/walidować dane z czujników? Słyszałem, że filtr Kalmana był używany w projekcie Apollo w latach sześćdziesiątych. Macie coś nowego, czy Kalman wciąż rządzi?
Dzięki za tę możliwość.
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. 
/u/przsd160
Gratulacje za DM-2!
1. Czy (i jak) zmodyfikowaliście jądro Linuksa, by bardziej pasowało do waszych wymagań?
2. Jak zaimplementowaliście odporność na promieniowanie/błędy w zwykłym niezabezpieczonym procesorze?
3. Którego procesora x86 używacie w Dragonie (i Falconie)?
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.
/u/Sea_Outside
Jaka jest waszym zdaniem najfajniejsza rzecz, jaką Dragon może zrobić dzięki swojemu oprogramowaniu?
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
/u/Captain_Hadock
Do Matta Monsona.
1. Jak różne są odczucia programistów i tempo zmian w oprogramowaniu produkcyjnym pomiędzy rzadko latającym i lustrowanym przez NASA Dragonem (w przypadku Dragona V2, chyba mniej tyczy się to V1), a czysto wewnętrznymi startami Starlinka co dwa tygodnie?
2. Jak często zdalnie aktualizujecie oprogramowanie już latających satelitów?
3. Czy satelity Starlink są zaprogramowanie w taki sposób, by deorbitować w przypadku, gdy nie są w stanie nawiązać komunikacji w określonym czasie (uszkodzenie anteny w prawidłowo funkcjonującym satelicie)?
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.
/u/wizang
Jak dużo indywidualnego kodu jest tworzone dla każdej z misji w porównaniu do mniej lub bardziej wspólnego kodu dla wszystkich lotów? Mam na myśli to, że zastanawiam się na przykład, czy dynamika orbitalna to dane wejściowe/konfiguracyjne, czy niestandardowe oprogramowanie, które musi być napisane za każdym razem.
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.
/u/km3k
Widziałem artykuły wspominające o tym, że SpaceX używa Linuksa. Jakie systemy z niego korzystają? Jakie kroki podejmujecie, aby zapewnić wykonywanie operacji w czasie rzeczywistym oraz jak deterministyczne są systemy? Modyfikacje jądra, takie jak CONFIG_PREEMPT_RT?
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.
/u/lukewalpole
Gratuluję udanego startu!
Czy moglibyście opowiedzieć nam o poprzednich zadaniach/projektach/umiejętnościach, nad którymi pracowaliście, a które pomogły wam zdobyć pracę w SpaceX, oraz o wszystkim, nad czym według was powinno się pracować, gdy chce się dostać pierwszą pracę w firmie technologicznej?
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.
/u/rootcage
Dzięki za to co robicie, chłopaki! Nie wydaje mi się, żeby większość inżynierów oprogramowania mogła pracować nad lotami kosmicznymi. Jakie są wyjątkowe wyzwania związane z inżynierią oprogramowania w pracy w tej dziedzinie?
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. 
/u/driveawayfromall
Jak testujecie swój kod pod kątem wszystkich błędów, które mogą wystąpić podczas lotu? Czy przeprowadzacie symulowane misje, aby przetestować kod w sposób całościowy, czy też opieracie się na indywidualnym testowaniu solidności modułów lub na jakiejś kombinacji jednego i drugiego?
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ń. 
/u/SpaceEnthusiast
Jako programista pracujący w firmie nad niekrytycznymi systemami, odczuwam pewien niepokój związany z kodem i błędami. Wiem, że musicie mieć dużo testów i nadmiarowości, ale jak duży niepokój odczuwacie wszyscy, jeśli chodzi o wszystkie systemy?
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. 
/u/Tengo10
Hej, gratulacje za wszystko, co osiągnęliście do tej pory.
Ile danych jest generowanych podczas typowego startu? O ile więcej było ich dla misji DM-2?
Czy któreś z tych danych będą kiedyś dostępne (może na żywo)?
Czy widzieliście niektóre symulacje Starlink (na YouTube: https://www.youtube.com/watch?v=m05abdGSOxY) i jak się one mają do rzeczywistości?
Czy rozpoczął się już rozwój oprogramowania dla Starshipa/Super Heavy?
Dzięki za odpowiadanie na nasze pytania!
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 
/u/Skywalker1002
Jaki moment był waszym ulubionym w SpaceX?
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. 
/u/tarruma87
W jaki sposób oprogramowanie rewidowane było pomiędzy dniem, w którym pogoda przeszkodziła w starcie (27.) oraz dniem startu (30.)?
Czy w międzyczasie zrobiliście albo rozważaliście nowe wdrożenia? Na ile dni przed startem zazwyczaj wasz kod produkcyjny jest uznawany za „zamrożony”?
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”.
/u/-JG-77-
Gdzie znajduje się toaleta w załogowym Dragonie?
SpaceX – Dietrick
Toaleta znajduje się pomiędzy przednim, a bocznym włazem – na „suficie”. Prawdopodobnie chcesz z niej korzystać tylko w zerowej grawitacji!
/u/Nerdyasian
Jakieś zabawne historie z testowania prototypów interfejsu użytkownika (UI)?
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. 
/u/night0x63
Z jakiego systemu operacyjnego korzysta załogowy Dragon do obsługi wyświetlaczy dotykowych? Z jakich języków programowania?
Co z resztą rakiety? Jakie języki?
Zakładam, że w obu przypadkach jest to prawdopodobnie C.
Czytaliście „The Power of 10 Rules”, wydane przez NASA?
Jeśli tak, to czy stosujecie wszystkie te reguły? Jeśli nie, to dlaczego?
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. :)

Oryginalne AMA w języku angielskim znajduje można znaleźć pod tym linkiem

Informacje o polityce prywatności

SpaceX.com.pl szanuje dane osobowe Użytkowników i spełnia wymogi ich ochrony wynikające z powszechnie obowiązujących przepisów prawa, a w szczególności z Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE.

Informacje o użytkowniku zbierane podczas odwiedzin oraz dane osobowe podawane podczas kontaktu z autorami serwisu SpaceX.com.pl wykorzystywane są jedynie w celu umożliwienia poprawy jakości działania portalu, zrozumienia zachowań odwiedzających oraz komunikacji z użytkownikami, którzy na to wyrazili chęć. Dane zbierane o użytkownikach podczas ich odwiedzin zawierają takie informacje jak listę stron które otworzyli, szczegółowy czas spędzony na poszczególnych stronach i zachowanie w trakcie przeglądania. Aplikacja internetowa lub zewnętrzne usługi mogą tworzyć także na komputerze użytkownika pliki tekstowe, które służą rozpoznawaniu odwiedzajacego i dostarczaniu mu usług takich jak powiadomienia.

Administratorem zebranych danych są twórcy strony SpaceX.com.pl i wszystkie informacje są dostępne tylko i wyłącznie dla nich i ich zaufanych usługodawców. Dane te nie są w żaden sposób monetyzowane przez twórców serwisu. Wspomniani zaufani usługodawcy to: Google Analytics, Hotjar, Matomo, OVH.

Dalsze przeglądanie tej strony, scrollowanie jej, a w szczególności zamknięcie tego okna informacyjnego oznacza wyrażenie zgody na zbieranie, przetwarzanie i nieograniczone przechowywanie danych o użytkowniku przez twórców serwisu SpaceX.com.pl