Gör vi rymdfarkoster för autonoma?

Dragon V2 inomhus

Det inre av rymdfarkosten Crew Dragon. Dimitri Gerondidakis / NASA





När SpaceXs Crew Dragon tog NASA-astronauter till ISS nära slutet av maj , lanseringen förde tillbaka en välbekant syn. För första gången sedan rymdfärjan lades ner, sköt amerikanska raketer upp från amerikansk mark för att ta amerikaner ut i rymden.

Inuti fordonet kunde saker och ting inte ha sett mer annorlunda ut. Borta var den vidsträckta instrumentbrädan med lampor och strömbrytare och rattar som en gång dominerade rymdfärjans interiör. Allt ersattes med en futuristisk konsol med flera stora pekskärmar som går igenom en mängd olika skärmar. Bakom dessa skärmar drivs fordonet av programvara som är utformad för att ta sig ut i rymden och navigera till rymdstationen helt autonomt.

Att växa upp som pilot, hela min karriär, med ett visst sätt att styra ett fordon – det här är verkligen annorlunda, sa Doug Hurley till NASAs tv-tittare kort innan SpaceX-uppdraget. Istället för att ropa på en hand på kontrollspaken är navigering nu en serie förutbestämda ingångar. SpaceX-astronauterna kan fortfarande vara inblandade i beslutsfattande vid kritiska tidpunkter, men mycket av den funktionen har gått ur deras händer.



Spelar detta någon roll? Mjukvara har aldrig spelat en mer kritisk roll i rymdfärder. Det har gjort det säkrare och mer effektivt, vilket gör att en rymdfarkost automatiskt kan anpassa sig till förändrade förhållanden. Enligt Darrel Raines, en NASA-ingenjör som leder mjukvaruutveckling för Orion djuprymdkapseln, är autonomi särskilt nyckeln för områden med kritisk responstid – som uppstigningen av en raket efter uppstigningen, när ett problem kan kräva att en avbrytningssekvens initieras på bara en fråga om sekunder. Eller i fall där besättningen kan vara arbetsoförmögen av någon anledning.

Och ökad autonomi är praktiskt taget avgörande för att få vissa former av rymdfärd att fungera. Ad Astra är ett Houston-baserat företag som vill göra plasmaraketframdrivningsteknik lönsam. Den experimentella motorn använder plasma gjord av argongas, som värms upp med elektromagnetiska vågor. En inställningsprocess som övervakas av systemets programvara räknar automatiskt ut de optimala frekvenserna för denna uppvärmning. Motorn kommer till full effekt på bara några millisekunder. Det finns inget sätt för en människa att reagera på något sådant i tid, säger vd Franklin Chang Díaz, en före detta astronaut som flög på flera rymdfärjor från 1986 till 2002. Algoritmer i kontrollsystemet används för att känna igen förändrade förhållanden i raketen när den rör sig genom startsekvensen – och agera därefter. Vi skulle inte kunna göra något av det här bra utan mjukvara, säger han.

Men att förlita sig på mjukvara och autonoma system i rymdfärder skapar nya möjligheter för problem att uppstå. Det är särskilt ett bekymmer för många av rymdindustrins nya utmanare, som inte nödvändigtvis är vana vid den typ av aggressiva och omfattande tester som behövs för att sålla bort problem i mjukvara och fortfarande försöker hitta en bra balans mellan automatisering och manuell kontroll.



  • rymdfärjan Atlantis

    Rymdfärjan Atlantis hade en mer traditionell instrumentbräda för sina piloter att använda.

  • inflight video av Dragon 2 uppdrag

    Crew Dragon-kapseln ersätter rattarna och omkopplarna med stora pekskärmar.

Nuförtiden kan några få fel i över en miljon rader kod betyda skillnaden mellan uppdragsframgång och uppdragsmisslyckande. Vi såg det i slutet av förra året, när Boeings Starliner-kapsel (det andra fordonet som NASA räknar med att skicka amerikanska astronauter ut i rymden) misslyckades med att ta sig till ISS på grund av ett fel i dess interna timer . En mänsklig pilot kunde ha åsidosatt felet som slutade med att Starliners dragkraft brändes i förtid. NASA-administratören Jim Bridenstine anmärkte strax efter att Starliners problem uppstod: Hade vi haft en astronaut ombord, kan vi mycket väl vara vid den internationella rymdstationen just nu.



Men det avslöjades senare många andra fel i programvaran hade inte fångats före lanseringen, inklusive ett som kunde ha lett till att rymdfarkosten förstördes. Och det var något som mänskliga besättningsmedlemmar lätt kunde ha åsidosatt.

Boeing är verkligen inte främmande för att bygga och testa rymdfärdsteknik, så det var en överraskning att se företaget misslyckas med att fånga dessa problem innan Starliner testflygning. Programvarudefekter, särskilt i komplex kod för rymdskepp, är inte oväntade, sa NASA när det andra felet offentliggjordes. Det fanns dock många tillfällen där Boeings mjukvarukvalitetsprocesser antingen borde ha eller kunde ha avslöjat defekterna. Boeing avböjde en begäran om kommentarer.

Enligt Luke Schreier, vice VD och general manager för flyg vid NI (tidigare National Instruments), är problem med mjukvara oundvikliga, vare sig det gäller autonoma fordon eller rymdfarkoster. Sånt är bara livet, säger han. Den enda verkliga lösningen är att aggressivt testa i förväg för att hitta dessa problem och åtgärda dem: Du måste ha ett riktigt rigoröst program för testning av programvara för att hitta de misstag som oundvikligen kommer att finnas där.



Ange AI

Rymden är dock en unik miljö att testa för. Förhållandena som ett rymdskepp kommer att möta är inte lätta att efterlikna på marken. Medan ett autonomt fordon kan tas ut ur simulatorn och lättas in i lättare verkliga förhållanden för att förfina programvaran lite i taget, kan du inte riktigt göra samma sak för en bärraket. Uppskjutning, rymdfärd och en återgång till jorden är handlingar som antingen händer eller inte gör det – det finns ingen lättversion.

Detta, säger Schreier, är anledningen till att AI är en så stor sak i rymdfärder nuförtiden – du kan utveckla ett autonomt system som är kapabelt att förutse dessa förhållanden, snarare än att kräva att villkoren lärs in under en specifik simulering. Du skulle omöjligt kunna simulera på egen hand alla hörnfall i den nya hårdvaran du designar, säger han.

Så för vissa grupper är testning av programvara inte bara en fråga om att hitta och åtgärda fel i koden; det är också ett sätt att träna AI-driven programvara. Ta till exempel Virgin Orbit, som nyligen försökte skicka sitt LauncherOne-fordon ut i rymden för första gången. Företaget arbetade tillsammans med NI för att utveckla en testbänk som kopplade ihop alla fordonets sensorer och flygelektronik med programvaran som är avsedd att köra ett uppdrag i omloppsbana (ned till den exakta längden på kablarna som används i fordonet). När LauncherOne var redo att flyga trodde den att den redan hade varit i rymden tusentals gånger tack vare testningen, och den hade redan ställts inför många olika typer av scenarier.

Naturligtvis LauncherOnes första testflygning slutade i fel , av skäl som fortfarande inte har avslöjats. Om det berodde på mjukvarubegränsningar är försöket ytterligare ett tecken på att det finns en gräns för hur mycket en AI kan tränas för att möta verkliga förhållanden.

Raines tillägger att i motsats till det långsammare tillvägagångssätt som NASA använder för testning, kan privata företag röra sig mycket snabbare. För vissa, som SpaceX, fungerar detta bra. För andra, som Boeing, kan det leda till några överraskande hicka.

I slutändan är det värsta du kan göra att göra något helt manuellt eller helt autonomt, säger Nathan Uitenbroek, en annan NASA-ingenjör som arbetar med Orions mjukvaruutveckling. Människor måste kunna ingripa om programvaran går sönder eller om datorns minne förstörs av en oväntad händelse (som en explosion av kosmiska strålar). Men de förlitar sig också på att programvaran informerar dem när andra problem uppstår.

NASA är van vid att ta reda på denna balans, och den har redundans inbyggd i sina bemannade fordon. Rymdfärjan körde på flera datorer med samma programvara, och om en hade problem kunde de andra ta över. En separat dator körde på helt annan programvara, så den kunde ta över hela rymdfarkosten om ett systemfel påverkade de andra. Raines och Uitenbroek säger att samma redundans används på Orion, som också inkluderar ett lager av automatisk funktion som kringgår programvaran helt för kritiska funktioner som fallskärmssläpp.

På Crew Dragon finns det tillfällen där astronauter kan initiera avbrytningssekvenser manuellt och där de kan åsidosätta mjukvara på grundval av nya indata. Men utformningen av dessa fordon innebär att det är svårare nu för människan att ta fullständig kontroll. Pekskärmskonsolen är fortfarande bunden till rymdfarkostens programvara, och du kan inte bara kringgå den helt när du vill ta över rymdfarkosten, även i en nödsituation.

Det finns ingen konsensus om hur mycket mer den mänskliga rollen i rymdfärd kommer – eller bör – krympa. Uitenbroek tycker att det helt enkelt är opraktiskt att försöka utveckla mjukvara som kan ta hänsyn till alla möjliga oförutsedda händelser, speciellt när du har deadlines att göra.

Chang Díaz håller inte med och säger att världen förändras till en punkt där människan till slut kommer att tas ur ekvationen.

Vilket tillvägagångssätt som vinner kan bero på graden av framgång som uppnås av de olika parterna som skickar människor ut i rymden. NASA har inte för avsikt att ta människor ur ekvationen, men om kommersiella företag upptäcker att de har lättare att minimera den mänskliga pilotens roll och låta AI:n ta ansvaret, än är pekskärmar och pilotlöst flyg till ISS bara ett smakprov på vad som ska komma.

Dölj