Gør vi rumfartøjer for autonome?

Det indre af Crew Dragon-rumfartøjet. Dimitri Gerondidakis / NASA

Da SpaceX's Crew Dragon tog NASA-astronauter til ISS nær slutningen af ​​maj , lanceringen bragte et velkendt syn tilbage. For første gang siden rumfærgen blev pensioneret, blev amerikanske raketter opsendt fra amerikansk jord for at tage amerikanere ud i rummet.

Inde i køretøjet kunne tingene dog ikke have set mere anderledes ud. Væk var det vidtstrakte instrumentbræt af lys og kontakter og knapper, der engang dominerede rumfærgens interiør. Det hele blev erstattet med en futuristisk konsol med flere store berøringsskærme, der cykler gennem en række forskellige skærme. Bag disse skærme drives køretøjet af software, der er designet til at komme ud i rummet og navigere til rumstationen helt autonomt.

At vokse op som pilot, hele min karriere, med en bestemt måde at styre et køretøj på - det er bestemt anderledes, fortalte Doug Hurley til NASA tv-seere kort før SpaceX-missionen. I stedet for at bede om en hånd på styrepinden, er navigation nu en række forudbestemte input. SpaceX-astronauterne kan stadig være involveret i beslutningstagning på kritiske tidspunkter, men meget af den funktion er flyttet ud af deres hænder.

Betyder dette noget? Software har aldrig spillet en mere kritisk rolle i rumfart. Det har gjort det sikrere og mere effektivt, hvilket gør det muligt for et rumfartøj automatisk at tilpasse sig skiftende forhold. Ifølge Darrel Raines, en NASA-ingeniør, der leder softwareudvikling til Orion dybe rumkapslen, er autonomi især nøglen til områder med kritisk responstid - som opstigningen af ​​en raket efter opstigningen, hvor et problem kan kræve at starte en afbrydelsessekvens på blot en spørgsmål om sekunder. Eller i tilfælde, hvor besætningen kan være uarbejdsdygtig af en eller anden grund.

Og øget autonomi er praktisk talt afgørende for at få nogle former for rumflyvning til at fungere. Ad Astra er en Houston-baseret virksomhed, der søger at gøre plasmaraketfremdriftsteknologi levedygtig. Den eksperimentelle motor bruger plasma lavet af argongas, som opvarmes ved hjælp af elektromagnetiske bølger. En tuning-proces, der overvåges af systemets software, finder automatisk ud af de optimale frekvenser for denne opvarmning. Motoren kommer til fuld kraft på få millisekunder. Der er ingen måde for et menneske at reagere på sådan noget i tide, siger administrerende direktør Franklin Chang Díaz, en tidligere astronaut, der fløj på adskillige rumfærgemissioner fra 1986 til 2002. Algoritmer i kontrolsystemet bruges til at genkende skiftende forhold i raketten. mens den bevæger sig gennem startsekvensen – og handle derefter. Vi ville ikke være i stand til at gøre noget af dette godt uden software, siger han.

Men overdreven afhængighed af software og autonome systemer i rumfart skaber nye muligheder for, at problemer kan opstå. Det er især en bekymring for mange af rumindustriens nye kandidater, som ikke nødvendigvis er vant til den slags aggressive og omfattende tests, der er nødvendige for at frasortere problemer i software, og som stadig forsøger at finde en god balance mellem automatisering og manuel kontrol.

• 

  Rumfærgen Atlantis havde et mere traditionelt instrumentbræt, som sine piloter kunne bruge.

• 

  Crew Dragon-kapslen erstatter knapperne og kontakterne med store berøringsskærme.

I dag kan nogle få fejl i over en million linjer kode betyde forskellen mellem missionssucces og missionsfejl. Det så vi i slutningen af ​​sidste år, da Boeings Starliner-kapsel (det andet køretøj, NASA regner med at sende amerikanske astronauter ud i rummet) undlod at komme til ISS på grund af en fejl i dens interne timer . En menneskelig pilot kunne have tilsidesat den fejl, der endte med at brænde Starliners thrustere for tidligt. NASA-administrator Jim Bridenstine bemærkede kort efter Starliners problemer opstod: Havde vi haft en astronaut om bord, kunne vi meget vel være på den internationale rumstation lige nu.

Men det blev senere afsløret mange andre fejl i softwaren var ikke blevet fanget før opsendelsen, inklusive en der kunne have ført til ødelæggelsen af ​​rumfartøjet. Og det var noget, menneskelige besætningsmedlemmer nemt kunne have tilsidesat.

Boeing er bestemt ikke fremmed for at bygge og teste rumfartsteknologier, så det var en overraskelse at se, at selskabet undlod at fange disse problemer før Starliner-testflyvningen. Softwarefejl, især i kompleks rumfartøjskode, er ikke uventede, sagde NASA da den anden fejl blev offentliggjort. Der var dog adskillige tilfælde, hvor Boeings softwarekvalitetsprocesser enten skulle have eller kunne have afsløret defekterne. Boeing afviste en anmodning om kommentarer.

Ifølge Luke Schreier, vicepræsident og general manager for aerospace hos NI (tidligere National Instruments), er problemer i software uundgåelige, hvad enten det er i autonome køretøjer eller i rumfartøjer. Sådan er bare livet, siger han. Den eneste rigtige løsning er at teste aggressivt i forvejen for at finde disse problemer og rette dem: Du skal have et virkelig strengt softwaretestprogram for at finde de fejl, der uundgåeligt vil være der.

Indtast AI

Rummet er dog et unikt miljø at teste for. De forhold, et rumfartøj vil støde på, er ikke lette at efterligne på jorden. Mens et autonomt køretøj kan tages ud af simulatoren og lempes ind i lettere virkelige forhold for at forfine softwaren lidt efter lidt, kan du ikke rigtig gøre det samme for en løfteraket. Opsendelse, rumflyvning og tilbagevenden til Jorden er handlinger, der enten sker, eller også gør de ikke - der er ingen light-version.

Dette, siger Schreier, er grunden til, at AI er så stor en ting i rumflyvning i dag - du kan udvikle et autonomt system, der er i stand til at forudse disse forhold, snarere end at kræve, at betingelserne skal læres under en specifik simulering. Du kunne umuligt simulere på egen hånd alle hjørnebeholderne i den nye hardware, du designer, siger han.

Så for nogle grupper er test af software ikke kun et spørgsmål om at finde og rette fejl i koden; det er også en måde at træne AI-drevet software på. Tag for eksempel Virgin Orbit, som for nylig forsøgte at sende sit LauncherOne-køretøj ud i rummet for første gang. Virksomheden arbejdede sammen med NI for at udvikle en testbænk, der sløjfede alle køretøjets sensorer og flyelektronik med softwaren, der skulle køre en mission i kredsløb (ned til den nøjagtige længde af ledninger, der bruges i køretøjet). Da LauncherOne var klar til at flyve, troede den, at den allerede havde været i rummet tusindvis af gange takket være testen, og den havde allerede stået over for mange forskellige slags scenarier.

Selvfølgelig, LauncherOnes første testflyvning endte i fiasko , af årsager, der stadig ikke er blevet oplyst. Hvis det var på grund af softwarebegrænsninger, er forsøget endnu et tegn på, at der er en grænse for, hvor meget en AI kan trænes til at møde virkelige forhold.

Raines tilføjer, at i modsætning til den langsommere tilgang, NASA tager til test, er private virksomheder i stand til at bevæge sig meget hurtigere. For nogle, som SpaceX, fungerer dette godt. For andre, som Boeing, kan det føre til nogle overraskende hikke.

I sidste ende er det værste, du kan gøre, at lave noget helt manuelt eller helt autonomt, siger Nathan Uitenbroek, en anden NASA-ingeniør, der arbejder på Orions softwareudvikling. Mennesker skal være i stand til at gribe ind, hvis softwaren fejler, eller hvis computerens hukommelse ødelægges af en uventet begivenhed (som et eksplosion af kosmiske stråler). Men de er også afhængige af softwaren til at informere dem, når der opstår andre problemer.

NASA er vant til at finde ud af denne balance, og den har redundans indbygget i sine bemandede køretøjer. Rumfærgen kørte på flere computere med den samme software, og hvis den ene havde et problem, kunne de andre tage over. En separat computer kørte på helt anden software, så den kunne overtage hele rumfartøjet, hvis en systemisk fejl påvirkede de andre. Raines og Uitenbroek siger, at den samme redundans bruges på Orion, som også inkluderer et lag af automatisk funktion, der helt omgår softwaren til kritiske funktioner som f.eks. faldskærmsudløsning.

På Crew Dragon er der tilfælde, hvor astronauter manuelt kan starte afbrydelsessekvenser, og hvor de kan tilsidesætte software på basis af nye input. Men designet af disse køretøjer betyder, at det nu er sværere for mennesket at tage fuldstændig kontrol. Berøringsskærmskonsollen er stadig bundet til rumfartøjets software, og du kan ikke bare omgå den helt, når du vil overtage rumfartøjet, selv i en nødsituation.

Der er ingen konsensus om, hvor meget længere den menneskelige rolle i rumflyvning vil - eller bør - skrumpes. Uitenbroek mener, at det simpelthen er upraktisk at forsøge at udvikle software, der kan tage højde for alle mulige hændelser, især når du skal lave deadlines.

Chang Díaz er uenig og siger, at verden skifter til et punkt, hvor mennesket til sidst vil blive taget ud af ligningen.

Hvilken tilgang der vinder kan afhænge af graden af ​​succes opnået af de forskellige parter, der sender folk ud i rummet. NASA har ingen intentioner om at tage mennesker ud af ligningen, men hvis kommercielle virksomheder finder ud af, at de har nemmere ved at minimere den menneskelige pilots rolle og lade AI'en tage ansvaret, er touchskærme og pilotløs flyvning til ISS kun en forsmag på, hvad der skal komme.

skjule