211service.com
Gjør vi romfartøyer for autonome?
Interiøret i romfartøyet Crew Dragon. Dimitri Gerondidakis / NASA
Da SpaceXs Crew Dragon tok NASA-astronauter til ISS nær slutten av mai , brakte lanseringen tilbake et kjent syn. For første gang siden romfergen ble pensjonert, ble amerikanske raketter skutt opp fra amerikansk jord for å ta amerikanere ut i verdensrommet.
Inne i kjøretøyet kunne ting imidlertid ikke sett mer annerledes ut. Borte var det vidstrakte dashbordet med lys og brytere og knotter som en gang dominerte romfergens interiør. Alt ble erstattet med en futuristisk konsoll med flere store berøringsskjermer som går gjennom en rekke skjermer. Bak disse skjermene drives kjøretøyet av programvare som er designet for å komme seg ut i verdensrommet og navigere til romstasjonen helt autonomt.
Etter å ha vokst opp som pilot, hele min karriere, med en viss måte å kontrollere et kjøretøy på – dette er absolutt annerledes, fortalte Doug Hurley til NASA TV-seere kort før SpaceX-oppdraget. I stedet for å be om en hånd på kontrollpinnen, er navigering nå en rekke forhåndsbestemte innganger. SpaceX-astronautene kan fortsatt være involvert i beslutningstaking på kritiske tidspunkter, men mye av den funksjonen har flyttet ut av hendene deres.
Betyr dette noe? Programvare har aldri spilt en mer kritisk rolle i romfart. Det har gjort det sikrere og mer effektivt, slik at et romfartøy automatisk tilpasser seg skiftende forhold. I følge Darrel Raines, en NASA-ingeniør som leder programvareutvikling for Orion dypromskapselen, er autonomi spesielt nøkkelen for områder med kritisk responstid - som oppstigningen av en rakett etter oppstigningen, når et problem kan kreve å starte en avbruddssekvens på bare en spørsmål om sekunder. Eller i tilfeller der mannskapet kan være ufør av en eller annen grunn.
Og økt autonomi er praktisk talt avgjørende for å få noen former for romfart til å fungere. Ad Astra er et Houston-basert selskap som ønsker å gjøre plasmarakettfremdriftsteknologi levedyktig. Den eksperimentelle motoren bruker plasma laget av argongass, som varmes opp ved hjelp av elektromagnetiske bølger. En innstillingsprosess overvåket av systemets programvare finner automatisk ut de optimale frekvensene for denne oppvarmingen. Motoren kommer til full kraft på bare noen få millisekunder. Det er ingen måte for et menneske å reagere på noe sånt i tide, sier administrerende direktør Franklin Chang Díaz, en tidligere astronaut som fløy på flere romfergeoppdrag fra 1986 til 2002. Algoritmer i kontrollsystemet brukes til å gjenkjenne skiftende forhold i raketten. mens den beveger seg gjennom oppstartssekvensen – og handle deretter. Vi ville ikke vært i stand til å gjøre noe av dette bra uten programvare, sier han.
Men overdreven avhengighet av programvare og autonome systemer i romfart skaper nye muligheter for problemer. Det er spesielt en bekymring for mange av romindustriens nye utfordrere, som ikke nødvendigvis er vant til den typen aggressive og omfattende testing som er nødvendig for å luke ut problemer i programvare og fortsatt prøver å finne en god balanse mellom automatisering og manuell kontroll.
-
Romfergen Atlantis hadde et mer tradisjonelt dashbord for sine piloter å bruke.
-
Crew Dragon-kapselen erstatter knottene og bryterne med store berøringsskjermer.
I dag kan noen få feil i over én million linjer med kode stave forskjellen mellom oppdragssuksess og oppdragsmislykket. Vi så det sent i fjor, da Boeings Starliner-kapsel (det andre kjøretøyet NASA regner med å sende amerikanske astronauter ut i verdensrommet) klarte ikke å komme seg til ISS på grunn av en feil i den interne tidtakeren . En menneskelig pilot kunne ha overstyrt feilen som endte med å brenne Starliners thrustere for tidlig. NASA-administrator Jim Bridenstine sa like etter at Starliners problemer oppsto: Hadde vi hatt en astronaut om bord, kan vi godt være på den internasjonale romstasjonen akkurat nå.
Men det ble senere avslørt at mange andre feil i programvaren hadde ikke blitt fanget opp før oppskyting, inkludert en som kunne ha ført til ødeleggelsen av romfartøyet. Og det var noe menneskelige besetningsmedlemmer lett kunne ha overstyrt.
Boeing er absolutt ikke fremmed for å bygge og teste romfartsteknologier, så det var en overraskelse å se at selskapet ikke klarte å fange opp disse problemene før Starliner-testflyvningen. Programvarefeil, spesielt i kompleks romfartøyskode, er ikke uventet, sa NASA da den andre feilen ble offentliggjort. Det var imidlertid mange tilfeller hvor kvalitetsprosessene for Boeing-programvaren enten burde ha eller kunne ha avdekket manglene. Boeing avslo en forespørsel om kommentar.
Ifølge Luke Schreier, visepresident og daglig leder for romfart ved NI (tidligere National Instruments), er problemer i programvare uunngåelige, enten det er i autonome kjøretøy eller i romfartøy. Sånn er bare livet, sier han. Den eneste virkelige løsningen er å teste aggressivt på forhånd for å finne disse problemene og fikse dem: Du må ha et veldig strengt program for testing av programvare for å finne de feilene som uunngåelig vil være der.
Skriv inn AI
Space er imidlertid et unikt miljø å teste for. Forholdene et romfartøy vil møte er ikke lett å etterligne på bakken. Selv om et autonomt kjøretøy kan tas ut av simulatoren og settes inn i lettere virkelige forhold for å avgrense programvaren litt etter litt, kan du egentlig ikke gjøre det samme for en bærerakett. Oppskyting, romfart og retur til jorden er handlinger som enten skjer eller ikke gjør det – det er ingen lettversjon.
Dette, sier Schreier, er grunnen til at AI er en så stor sak i romfart i dag – du kan utvikle et autonomt system som er i stand til å forutse disse forholdene, i stedet for å kreve at betingelsene læres under en spesifikk simulering. Du kunne umulig simulere på egen hånd alle hjørnekoffertene til den nye maskinvaren du designer, sier han.
Så for noen grupper er testing av programvare ikke bare et spørsmål om å finne og fikse feil i koden; det er også en måte å trene opp AI-drevet programvare. Ta for eksempel Virgin Orbit, som nylig prøvde å sende LauncherOne-kjøretøyet ut i verdensrommet for første gang. Selskapet samarbeidet med NI for å utvikle en testbenk som koblet sammen alle kjøretøyets sensorer og flyelektronikk med programvaren ment å kjøre et oppdrag i bane (ned til den nøyaktige lengden på ledningene som brukes i kjøretøyet). Da LauncherOne var klar til å fly, trodde den at den allerede hadde vært i verdensrommet tusenvis av ganger takket være testingen, og den hadde allerede møtt mange forskjellige typer scenarier.
Selvfølgelig, LauncherOnes første testflyvning endte i feil , av årsaker som fortsatt ikke er avslørt. Hvis det var på grunn av programvarebegrensninger, er forsøket enda et tegn på at det er en grense for hvor mye en AI kan trenes til å møte virkelige forhold.
Raines legger til at i motsetning til den langsommere tilnærmingen NASA tar for testing, er private selskaper i stand til å bevege seg mye raskere. For noen, som SpaceX, fungerer dette bra. For andre, som Boeing, kan det føre til noen overraskende hikke.
Til syvende og sist er det verste du kan gjøre å lage noe helt manuelt eller helt autonomt, sier Nathan Uitenbroek, en annen NASA-ingeniør som jobber med Orions programvareutvikling. Mennesker må være i stand til å gripe inn hvis programvaren feiler eller hvis datamaskinens minne blir ødelagt av en uventet hendelse (som en eksplosjon av kosmiske stråler). Men de er også avhengige av programvaren for å informere dem når andre problemer oppstår.
NASA er vant til å finne ut av denne balansen, og den har redundans innebygd i sine mannskapsbiler. Romfergen opererte på flere datamaskiner med samme programvare, og hvis en hadde et problem, kunne de andre overta. En separat datamaskin kjørte på en helt annen programvare, så den kunne ta over hele romfartøyet hvis en systemfeil påvirket de andre. Raines og Uitenbroek sier at den samme redundansen brukes på Orion, som også inkluderer et lag med automatisk funksjon som omgår programvaren helt for kritiske funksjoner som fallskjermutløsning.
På Crew Dragon er det tilfeller der astronauter manuelt kan starte avbruddssekvenser, og hvor de kan overstyre programvare på grunnlag av nye input. Men utformingen av disse kjøretøyene betyr at det er vanskeligere nå for mennesket å ta fullstendig kontroll. Berøringsskjermkonsollen er fortsatt knyttet til romfartøyets programvare, og du kan ikke bare omgå den helt når du vil ta over romfartøyet, selv i en nødssituasjon.
Det er ingen konsensus om hvor mye mer den menneskelige rollen i romfart vil – eller bør – krympe. Uitenbroek mener det er upraktisk å prøve å utvikle programvare som kan ta hensyn til alle mulige beredskaper, spesielt når du har tidsfrister.
Chang Díaz er uenig, og sier at verden skifter til et punkt hvor mennesket til slutt kommer til å bli tatt ut av ligningen.
Hvilken tilnærming som vinner kan avhenge av suksessnivået oppnådd av de forskjellige partene som sender folk ut i verdensrommet. NASA har ingen intensjoner om å ta mennesker ut av ligningen, men hvis kommersielle selskaper finner ut at de har lettere for å minimere rollen til den menneskelige piloten og la AI-en ta kontroll, er berøringsskjermer og pilotløs flyging til ISS bare en smakebit på hva som skal komme.