Ditt skepp utför en oväntad kollision - hur pålitlig är programvaran att klara av det?
Artikeln var förberedd på materialet i Icarus Interstellar-specialist Donna A. Dulo, en ledande matematiker, programvaruforskare, systemingenjör vid US Department of Defense. Läs mer om Icarus Interstellar i Discovery News artikeln.
När ditt rymdskepp galoppar galaxen med ljusets hastighet, hittar du en knappt synlig ökning i sensorerna ombord. Ju mer du närmar sig källan, desto starkare dess flöden, var och en av dem i en tät formation skickas i din riktning. I ångest tar du och ditt team sina platser på skeppet och inser det värsta: du måste konfrontera en stor armada av Borg-kuber och deras sfärer.
Lyckligtvis kunde du leda skeppet från en allvarlig kollision genom att manövrera genom ett litet, knappt märkbart smutthål som upptäcktes under den förberedande beredningen av navigeringsplanen, och fartyget lämnar oskadd. Du var tvungen att avvika lite från kursen, men skeppet är säkert och ditt besättning är nu säkert.
Så snart du börjar beräkna din rutt igen upptäcker du en annan signal. Fartygets livsupportsystemmodul misslyckades på grund av ett programfel som uppstod under en kollisionsundviklingsmanöver. Programvaran skadade lagets livsstödssystem, och du förstår att fartyget inte längre kan dra luft för andning under de närmaste 24 timmarna. Backup-systemet var hjälplöst, och själva komponentens säkerhetskopiering använder samma programvara. Räddningsanordningar möjliggör 48 timmar för att få luft för andning och mobila enheter ombord är försedda med luftkit konstruerade för 8 timmars andning.
Du skickar dina bästa datavetenskapare och mjukvaruingenjörer till maskinrummet för att diagnostisera ett problem. De meddelar att åtminstone det tar fyra dagar att lösa problemet för att isolera och eliminera fel i flera hundra miljoner koder som styr fartygets livsstödssystem.
Din situation är särskilt svår nu. Du begär en rapport från icke-kritiska system och skickar snabbt ett team av programmerare. Nu väntar du och vet att livet för alla besättningsmedlemmar är nu i händerna på mjukvaruutvecklingsteamet.
Scenariot som beskrivs ovan visar mjukvarans vitala natur på en lång skeppsresa. En naturlig fråga uppstår: Vad är en stor fiende: en flotilla av rymdskurkar eller en svaghet i skeppssystemets mjukvarusystem?
För de som känner till mjukvarusystemets mycket komplexa natur är svaret uppenbart; Detta är den programvara som utgör störst fara.
Att resa i interstellära utrymmen kräver ett självförsörjande fartyg och besättning, vilket innebär snabba beslut av de allvarligaste tekniska problemen. Den exponentiella komplexiteten och sårbarheten i den slutliga mjukvaran gör den till en av de svagaste länkarna i behovet av långsiktig överlevnad ombord på ett interstellärt skepp. Föreställ dig ett fullt fungerande rymdfarkoster, med hundratals miljoner kodrader och tiotals eller till och med hundratusentals av deras variabler och stater. Att diagnostisera ett enda fel i en kodlinje är nästan omöjligt vid en nödsituation, även med de mest avancerade automatiserade testprocedurerna. Spänningen i situationen i kombination med de inneboende svårigheterna med matematisk logik och en stor mängd kod kommer att skapa spänning i arbetet till även de bästa team av ingenjörer som för närvarande utför arbete.
Precis som i situationen med Borg, där du tänkte igenom allt på förhand, gjort beredskapsplaner och planerade utrymningsvägar, så är säkerhetsplanering för rymdskeppens långsiktiga program möjlig. Denna planering måste emellertid ske under skeppets utveckling såväl som under dess interstellära operationer. Nyckeln till det nya tekniska paradigmet kallas "hållbarhet", och det kan mycket väl vara lätt att tillämpa på utveckling och utveckling av program.
I det långsiktiga rymduppdraget kommer de möjliga gränserna för mjukvaran att utmanas, men risken för misslyckande kommer inte att passa någon.
Programvaran, såväl som besättningsmedlemmar som använder den, måste vara stabila för att klara alla kritiska situationer för att upprätthålla säkerheten. Begreppet hållbarhet som en ämnesdisciplin uppstod i mitten av 2000-talet som ett sätt att minska misslyckandet i komplexa system, mot bakgrund av ljudtekniska insatser. Teknikens hållbarhet, som ett konceptkoncept, fångas i hur människor hanterar komplexiteten hos ett mjukvarusystem för att lyckas på kort tid även i de svåraste situationerna. Teknisk robusthet fokuserar på systemets förmåga att anpassa sig till en ständigt föränderlig situation och förhållanden så att ett positivt tillstånd av kontroll över systemet upprätthålls för att undvika misslyckande. I kombination med systemets förmåga att anpassa sig är nödvändigheten av den mänskliga faktorn i systemet nödvändig för större anpassningsförmåga till förändrade förhållanden. Kombinationen av man-maskin-system ger ett nytt tillvägagångssätt för säkerhet, förse människor med elementen för att få kunskap och förutse processer i systemet, så att de kan bli en aktiv del av systemets säkerhetsoperation.
Det finns två aspekter av mjukvaruutvecklingsteknik: mjukvarubeständighet genom ljudprocessen av orienterad säkerhetsutveckling och den aktuella realtidsoperationen av programvara med ett positivt mänskligt svar inom cykelfunktioner. Det övergripande programmet fungerar i enlighet med konceptet att säkerhet är ett kärnvärde tillsammans med den konstanta förväntan om ett eventuellt programfel.
Sålunda hjälper en person genom att orientera säkerhetsuppmärksamhet att förändra riskekvationen i åtgärdsstödsystemet, för att bryta kedjan av kaskadprogramvarufel på grund av orsakssamband, samtidigt som systemets bräcklighet minskas. Resultatet är säkrare, mer genomförbar och förutsägbar mjukvaruprestanda, i samarbete med användare, som deltar i hela omfattningen av mjukvaruprocesser och evolution.
Stabiliteten hos ingenjörsmetoderna fortsätter att manifestera sig och fokuserar på redundans av logikprogram, adaptiva interventionsmetoder, intellektuell analys, bland många andra tekniker för ljudteknik. Bland ingenjörsstrukturer finns det ett ljud som är motiverat av en mänsklig resurs och operativa hanteringsprotokoll är utformade för att fokusera på besättningens förmåga att anpassa sig till förändrade förhållanden och mildra även de mest komplexa programvarosjukdomen. Genom kopplingar av fjädrande mjukvaruutvecklingsmetoder och lönsamhet för tekniskt organisatoriskt ledarskap och ett team som fokuserar på hantering av nödprogram, har det komplexa systemet förmågan att överleva ett katastrofalt fel, vilket hjälper till att förhindra ett totalt besättningssvikt.
I vårt exempel misslyckades säkerhetskopieringslivsstödssystemet, eftersom det var samma programmering som huvudsystemet och därmed i samma situation, misslyckades också säkerhetskopieringen. Ett mer robust system kommer att använda ett annat program från mjukvarupaketet och en uppsättning backupsystemalgoritmer för att göra samma arbete, vilket gör systemet stabilt.
Ett feltolerant system, som mjukvara, är mer modulärt och matematiskt provbart, vilket ger mer och mer livskraftiga sätt att anpassa, refactoring och reparera. Minskad komplexitet och mer standardiserad programvara och algoritmiska strukturer kommer att ge ytterligare garantier för att förbättra stabiliteten.
Då kommer mannen som ett led i ett hållbart system in i spelet. Efter ett system med livsuppehållssystem är besättningen på tjänst, omedelbart växlar systemet till reservkomponenter, där en annan uppsättning programvaruprocedurer, inklusive en helt annan uppsättning matematisk logik, strömmar.
Alla besättningsmedlemmar är utbildade i nyanserna på fartygets hårdvara och programvara samt ansvaret för att förstå alla typer av beräkningsfel och hur man klarar dem. Under en betydande tid senare fortsätter mjukvarusystemet för ingenjörsarbetet att arbeta för att reparera funktionsfel i den logiska kedjan av den primära uppsättningen programvaruförfaranden, eftersom backupsystemet fungerar felfritt.
Reparationsuppgiften är enklare, eftersom programvaran är mer modulär, lätt sönderdelas hierarkiskt och noggrant dokumenterad i design, arkitektur och även i dess matematiskt beprövade strukturer. Teamet kompletteras med en uppsättning andra mjukvaruingenjörer som har den nödvändiga utvecklingen och utför de sekundära funktionerna för besättningen och högkvalificerade primära mjukvarulag.
Skriptet var välövrerat i förväg, under träning, och spelaren i varje lag känner till sin funktion: kodare, verifierare, matematiker, testare och implementatör. I en systematiskt organiserad teknikhanteringsaktivitet utvecklas en ny uppsättning logik och kodas för huvudsystemet. Inom två dagar kontrolleras han och går så småningom på jobbet. Efter genomförandet av experimentet med besättningens fulla deltagande återvände skeppet till den ursprungliga stridsordern.
Genom att tillämpa uthållighet i mjukvaruutveckling och rymdfarkostens realtidsarbete kan besättningen öka överlevnadsförmågan hos fartyget, även vid en tidpunkt då allvarliga programproblem uppstår. Tack vare utvecklingen och tillämpningen av spännande teorier och metoder för att utveckla programvara för hållbarhet kommer skeppet att ha verktyg och utbildat besättning för att på ett säkert sätt kunna genomföra djupgående mjukvaruoperationer.
Metoder för hållbarhet kan också tillämpas på andra former av teknik, såväl som drift på fartyg, vilket skapar en holistisk säkerhetskultur som förbättrar skeppets övergripande överlevnad.
Således kommer hållbarheten att göra skeppet en långlivad, avsedd att passera genom en galax med oändliga möjligheter för nuvarande och kommande generationer. Även när det inte finns någon chans före Borg. Uppdraget i Icarus Interstellar är att främja utvecklingen av rymdfarkostforskning, både för bemannade och obemannade fordon. Programvaran kommer att ta en stor del av dessa framtida system, och studiens stabilitet kommer att bidra till att uppnå de ultimata målen, först och främst för att komma till stjärnorna och sedan flytta mellan dem, som i en interstellär civilisation.
