DUTCH

NASA ‘ s onbezongen helden: De Apollo codeurs die mannen op de maan

133

Nul

Dit artikel verscheen oorspronkelijk op TechRepublic.

Homer Ahr was in slaap gevallen om de 15 minuten, toen hij een telefoontje kreeg van zijn baas op het Johnson Space Center.

“Alles wat hij zei was, ‘Homerus, in mission control zo snel als je kunt.’ Ik had geen idee van waarom ik was gaan zitten,” zei hij.

“Binnen 30 minuten op de meeste wist ik dat ze echt in een situatie van leven of dood,” zei de Ahr.

Eerder die avond, Apollo 13 astronaut Jack Swigert had gebracht NASA mission control tot stilstand met de inmiddels beroemde uitspraak, “Houston, we hebben een probleem gehad.”

De Apollo 13 ambacht was meer dan 300.000 kilometer in zijn reis naar de maan als een explosie scheurde door de kleine capsule.

Op die dag in April 1970, met het schip de ontluchting van de kostbare aanvoer van zuurstof, NASA wist dat hij weinig opties voor de drie Apollo-astronauten op de getroffen ruimteschip veilig thuis.

“Vanuit die gedachte op, alles wat we deden was alles doen wat we kunnen om ze terug te krijgen,” Ahr zei.

“Het is een beetje zoals in de ER, weet je wel? Als u vast een naald in iemands borst te activeren hun hart, je doet het gewoon. Je hoeft niet na te denken over wat je aan het doen bent. Je doet het gewoon.”

Een van de vele indrukken van problemen was hoe te monteren een redding zonder het afvuren van de motoren op het beschadigde deel van het vaartuig. Op het Johnson Space Center in Houston, TX, mission control verkleinde de opties om een manoeuvre probeerde nooit tevoren. Het voortbestaan van de astronauten nu scharnierende over het gebruik van de afdaling motoren op de lunar lander om het vaartuig op een homeward traject.

Mission control had weinig tijd om uit te werken hoe te trekken uit de manoeuvre. Gelukkig, slechts enkele maanden voordat de bemanning weggeblazen vanaf Cape Canaveral, twee programmeurs geschreven had, de software voor mission control te berekenen net zoals een verhuizing.

“Binnen 30 minuten op de meeste wist ik dat ze echt in een situatie van leven of dood.” Homer Ahr, NASA computer programmeur

Een van die programmeurs werd de 22-jarige Ahr, net een jaar naar de universiteit en werkzaam bij IBM als een manoeuvre-planning expert ondersteunen van NASA vlucht officieren in mission control.

“Als wat er was gebeurd op de Apollo 13 had plaatsgevonden op Apollo 12, hadden we een echte beer van een probleem,” zei de Ahr, omdat de algoritmen voor het berekenen van de manoeuvre had alleen net zijn toegevoegd.

“Fysiek je zou kunnen doen, maar voor de computer en in het mission control center, het zou uiterst moeilijk zijn om erachter te komen wanneer het te doen voor het manoeuvreren, en hoe het te doen,” zei hij.

Mission control nodig garantie dat het afvuren van de afdaling motoren zou werken, en de Ahr en een collega bracht de nacht actief is wat genoemd werd een dispersie analyse, controle van elke mogelijke parameter om te zien of de beweging zou zetten het vaartuig op de juiste koers.

“Ik kon niet eens vertellen u het aantal keren we liepen berekeningen,” zei de Ahr, “maar we hadden de dispersie-analyse en de conclusie was, ‘Ga je gang en doe het manoeuvreren.'”

De computers als de helden

De uiteindelijke terugkeer van de astronauten was het gevolg van een veel meer dan die reeks van berekeningen, maar Ahr de herinnering illustreert hoe belangrijk de eerste computers waren naar de maan-missies.

Met het doel van het zetten van een man op de maan, NASA ‘ s Apollo-programma is misschien wel het meest ambitieuze technische inspanning ooit ondernomen. Gedurende de 15 Apollo missies die zes maan landingen, de precisie die nodig is–in termen van positionering en de snelheid–om het vaartuig op het juiste traject op de reis naar en van de aarde was veeleisend.

Elke manoeuvre die zou worden uitgevoerd door het ruimteschip werd berekend in een vooraf door IBM-computers in Real-Time Computer Complex (RTCC) bij Johnson Space Center en gecontroleerd aan de hand van het ambacht van de werkelijke manoeuvres binnen de missie.

Net zo belangrijk is voor de terugkeer van Apollo 13, en het succes van het bredere programma, werden de computersystemen van de onderbouwing van de talrijke simulator op het Johnson Space Center en Cape Canaveral. De simulatoren werk exemplaren van het ruimteschip van de commando-en maan-modules, en liet NASA astronauten en de flight controllers op de grond te oefenen ieder deel van de reis: vanaf de lancering naar de maan-landing, naar de aarde re-entry, het werken in tandem als ze zou tijdens de missie.

Simulatoren gerepliceerd niet alleen de werking van de onboard computers, maar ook gevoed gegevens naar grond-systemen, het opnieuw maken van de ervaring van een echte missie zo goed mogelijk, en het voorbereiden van medewerkers om te gaan met een host van potentiële problemen.

Jack Winters, die beheerd simulatoren testen en begonnen met het schrijven van software voor simulatoren tijdens de eerdere Gemini missies, zei de training voor de flight controllers van onschatbare waarde was voor het Apollo-Project.

ZIE: NASA toont de wereld haar 20-jarige virtual reality experiment om te trainen astronauten: Het verhaal (TechRepublic)

“Op Apollo 13, zij waren bijvoorbeeld veel beter in staat om ter plaatse het probleem en ontwikkelen van oplossingen, omdat van de training,” zei hij.

Tijdens de Apollo 13, deze simulatoren zou laten ingenieurs en astronauten op de begane–werken samen met astronaut Ken Mattingly, die waren vervangen van de Apollo-13 bemanning op het laatste moment–erachter te komen hoe je de commando-module aan boord systemen weer online met de beperkte beschikbare vermogen, een belangrijke stap voor het opnieuw invoeren van de atmosfeer van de aarde.

Merritt Jones was aan het werken bij Johnson Space Center als een computer programmeur en een astrodynamicist, het berekenen van de mechanica van hoe een ruimteschip beweegt in een baan.

Het uitwerken van de juiste volgorde te herstellen van de lander de systemen van ongelooflijk belang voor de veilige terugkeer van de Apollo 13 bemanning, zei hij.

“Ze moest verminderen de kracht die nodig is voor de opstartvolgorde. De opstartvolgorde van cruciaal belang was. Als je niet start in de juiste volgorde, de systemen zou niet goed werken of niet zou werken.”

Grenzen verleggen

De computers die worden gebruikt tijdens de Apollo-missies werden onmogelijk ruw door de moderne normen. Elk van de RTCC vijf IBM System/360 Model J75 mainframes had ongeveer 1MB geheugen, zelfs niet genoeg om het laden van een typische web-pagina in 2017.

“De software die bepaalt wat er gebeurt als u met uw muis op uw PC–stuurprogramma voor de muis voor Windows–neemt meer geheugen in beslag dan alle de NASA supercomputers samen was voor Apollo”, zegt Jones.

Ondanks het vullen van een hele zaal met elektronica, de mainframes iedere kwamen uit op ongeveer één miljoen instructies per seconde (MIPs), een aantal van 30.000 keer langzamer dan de snelste processoren gebruikt in de hedendaagse personal computers.

“Het muis stuur programma voor Windows neemt meer geheugen in beslag dan alle de NASA supercomputers samen was voor Apollo.” Merritt Jones, NASA computer programmeur en astrodynamicist

NASA was botsen tegen de grenzen van de techniek op het moment zou kunnen doen, dat betekende vaak een beroep op de cutting-edge, en soms onbewezen, hardware en software. En waar de tech simpelweg nog niet bestond, NASA ‘ s van de commerciële partners moesten uitvinden.

Een voorbeeld hiervan was de Apollo Guidance Computer (AGC). Terwijl op de begane systemen klinkt misschien underpowered, de onboard computers waren ordes van grootte meer eenvoudig. De begeleiding computer voor het Apollo-ruimtevaartuig nodig is klein genoeg om te passen in een krappe capsule, en licht genoeg voor de Saturnus raket te krijgen in de ruimte. De kast-en kleinbedrijf IBM mainframes die de NASA gebruikt op de grond waren van de vraag.

Massachusetts Institute of Technology Instrumentation Laboratory (MIT-IL), die had het contract voor de ontwikkeling van de AGC, draaide om een nieuwe technologie, geïntegreerde schakelingen, die het potentieel had om computers sneller en kleiner door het etsen van meerdere transistoren op kleine chips. Op dat moment in 1961, geïntegreerde schakelingen alleen had uitgevonden twee jaar daarvoor waren iets van een onbekende hoeveelheid, maar door 1963 MIT-IL had ongeveer 60 procent van de wereldbevolking beschikbaar ICs.

“Veel had te maken met macht en gewicht”, aldus Bob Zagrodnick, een ingenieur die werkte op de AGC bij Raytheon, die gebouwd 43 van de computers in de loop van het Apollo-programma.

“Dit zijn kleine eenheden en ze niet nemen veel van de macht. Zouden We streven voortdurend naar het minimaliseren van het gewicht en het stroomverbruik.”

Meer ongebruikelijke was de manier waarop de software draait op de AGC was letterlijk aan elkaar geweven. Bij Raytheon van de productielijn in Waltham, MA, wevers lusvormige draad door ronde magneten, en in het creëren van een metalen tapijt waarvan het patroon overeen met digitale nullen en enen, die op zijn beurt de gecodeerde programma ‘ s worden uitgevoerd op de computer.

“Ze eigenlijk schroefdraad van de vlucht programma-informatie in de kern touw herinneringen,” zei Zagrodnick. “Het was een zeer intense activiteit, dus meestal op vrouwen die goed waren in naald en draad werden degenen die geweven of samen de kern van herinneringen.”

Terug in het Johnson Space Center, IBM zag zich geconfronteerd met een heel andere uitdaging. Zoals de naam al doet vermoeden, de computers in de RTCC nodig om te kunnen omgaan met nieuwe taken en gegevens in real time, om te voldoen aan hun rol monitoring ruimtevaartuig trajecten en het besturen van complexe simulaties van de missies. Het probleem was dat het op dat punt in het begin van de jaren 1960 real-time operating systemen niet bestaan.

Volgens de Ahr: “We moesten een multi-tasking, multi-jobbing besturingssysteem in de jaren 1960 — voordat IBM ooit had gebouwd een multi-jobbing, multi-tasking besturingssysteem.”

Dus IBM uitgevonden één, het aanpassen van de bestaande OS op de System/360 mainframe, in aanvulling op het maken van een real-time database genaamd DataTables, “goed voor je had iets, een zogenaamde relationele database,” zei de Ahr, met strikte regels rond waarop gegevens kunnen worden bijgewerkt wanneer, om ervoor te zorgen belangrijke informatie met betrekking tot het ruimteschip zou zijn correct en beschikbaar is wanneer dat nodig is.

Werken met een nieuw BESTURINGSSYSTEEM toegevoegd voor een frisse rimpel aan een taak al vol uitdagingen, met berekeningen gooien tot onverwachte resultaten als gevolg niet alleen voor de toepassing van fouten, maar ook fouten in het relatief niet-besturingssysteem.

Download dit artikel als PDF (gratis registratie vereist).

Het fotograferen van de maan

De druk op de jonge IBM programmeurs was intens, met individuen werkt zo veel als 80 uur in een week, in een poging om het hardst getroffen van deadlines.

Winters zei: “NASA had een schema. Ze waren gaan vliegen op bepaalde data. Ze kondigde aan het publiek en IBM zeker niet wil dat de oorzaak van de vlucht vertraagd is.”

Die drive om te werken rond-de-klok werd deels veroorzaakt door de straffen tijdschema, maar ook door de spanning op het werken aan een man op de maan, en de wil om te winnen van de Russen in de ruimte race.

“We waren zo opgewonden,” zegt Winters. “We waren jong. Ik denk dat ik was 21 toen ik begon. We wisten niet wat we konden doen. We dacht dat we iets konden doen. Hier was ik bezig met software die de ruimte in gaat en uiteindelijk naar de maan. De adrenaline factor was enorm.”

Jong genoeg om niet volledig te waarderen wat zij niet kon doen of niet doen soms werd beloond, volgens Harry Hulen, die voornamelijk gewerkt aan de software die gebruikt wordt bij de simulatoren in Houston voor je gaat toezicht houden op anderen’ code.

Hulen herinnert moeite met het simuleren van de brandstof tanks op de Agena onbemande raket tijdens de Gemini-missies, de AMERIKAANSE bemande ruimtevaart project, dat voorafgegaan Apollo, toen hij een uitstapje naar zijn lokale Sakowitz warenhuis.

“Op de plank, samen met de gebruikelijke soorten boeken die je in een winkel zien, was een boek Raket Brandstof en kunstmatige druk Systemen,” zei hij.

ZIE: het implementeren van AI en machine learning (ZDNet/TechRepublic bijzonder verslag)

“Ik kocht het en het bleek dat dat boek was precies vertellen wat ik moet doen met de eisen die ik had. Ik heb gewoon totaal niet aan de eisen, die de NASA had geschreven en geprogrammeerd out van dit boek dat ik kocht in Sakowitz,” zei Hulen. “Het werkte goed. Niemand ving me op, en de resultaten van het werkte gewoon prima. Ze waren in staat om te simuleren dat bepaalde dingen tot een hogere graad van nauwkeurigheid dan nodig was.

“Het belangrijkste is dat ik het was, misschien, 22 jaar oud, en ik wist niet dat ik het doen van de verkeerde dingen. Ik zei: ‘Dit lijkt mij als wat ik zou moeten doen.’ Ik vermoed dat er was nogal een beetje van dat,” zei hij.

Dat wil niet zeggen dat het altijd makkelijk om het juiste evenwicht tussen persoonlijke en professionele verplichtingen. Veel van de jonge programmeurs werden vanaf gezinnen in de tijd, maar vaak vinden zichzelf hoeft te werken laat voor het testen van software, door machines constant in gebruik tijdens de dag.

“Veel van onze ontwikkeling in de tijd was in het midden van de nacht,” zegt Winters.

“Ik heb veel op een laat uur in de kamer met de computer testen van software en het toezicht op het testen van software. In feite, mijn eerste scheiding werd waarschijnlijk veroorzaakt door de vele uren die ik werkte in die periode,” zei hij.

ZIE: Foto ‘s: De computer programmeurs achter NASA’ s Apollo-missies

Op de achterkant van elke ingenieur in de geest was niet alleen het succes van de missie, maar ook de levens van de astronauten die afhankelijk zijn van software doet zijn werk.

Vanaf het moment dat Tom Steele toegetreden IBM in 1963, werkt uit Huntsville, AL op software voor de leiding systemen op de Saturnus raketten gebruikt tijdens de Apollo, hij zei dat zijn team werden gemaakt scherp bewust van wat op het spel stond.

“Elke aannemer had een programma van bemande vlucht van het bewustzijn. Deze programma ‘ s zijn ontworpen om zowel je dingen doen beter, maar ook om u te kunnen omgaan met het idee dat je zou kunnen doden een man als u messed up,” zei hij.

Ahr voelde dat de verantwoordelijkheid vooral scherp tijdens de Apollo 11, de 1969 missie die landde de eerste mens op de maan.

Zijn baan bij dat het tijd was om software die berekend manoeuvres van de raket en het ruimtevaartuig in elke fase van de missie, en controleer de real-time positie van het ruimteschip tegen de verwachte resultaten, werken ter ondersteuning van de vlucht officieren in mission control.

De rol was niet eenvoudig, waarvoor Ahr te zitten op een console te luisteren naar over acht verschillende telefoonlijnen in een keer, evenals de audio-invoer van de astronauten. Hij herinnert zich de angst die hij voelde toen de lijnen begonnen echo op het geluid van een alarm als de Apollo 11 lunar module afgedaald naar het oppervlak van de maan.

“Wanneer die alarm gaat af tijdens de eerste afdaling, het was eng om te zeggen het minst,” zei de Ahr. “Het was chaotisch om te luisteren naar alles dat in één keer en probeer kalm te blijven, houd je hoofd omhoog en niet in paniek.

“Het was alsof je zit op een voetbalwedstrijd, er is ton van de mensen gillen en schreeuwen, en geroep, plus er is een vuur. Weet je, brandweerwagens te zien zijn, ambulances zien, politie opdagen, en ze hebben allemaal hun zwaailichten aan,” zei hij. “Dat is wat je aan het luisteren bent als je probeert om daar te zitten en rustig te kijken naar de real-time data te komen.”

Gelukkig is de afdaling naar het maanoppervlak was in de buurt-op het perfect: “Zo goed een afdaling als we ooit gevlogen,” zei de Ahr, dankzij de vele fail-safes gebouwd in de Apollo-systemen. In dit geval, de rendez-vous radar in de module was ingeschakeld, overbelasting van de Apollo Guidance Computer met banen. Echter, het systeem was in staat om de prioriteit van de taken die nodig zijn voor de afdaling, en negeer die in verband met de radar.

Ahr credits zijn vermogen om kalm te blijven en zijn werk doen op de uitgebreide training van de missie, waar allerlei problemen werden gesimuleerd, en een besef van de belangrijke rol die hij en andere grondpersoneel had.

“Elke actie die je deed op de console beïnvloed het succes van de missie en invloed kunnen hebben op de levens van de astronauten,” zei hij. “Je had een soort van een kenmerk waar de druk het was en hoe meer stress er is, hoe beter u heeft gewerkt.”

Er was wederzijds respect tussen de IBM ingenieurs en hun collega ‘ s van de NASA, geboren uit hun nauwe samenwerking en de high stakes betrokken bij het maken van de bemande ruimtevaart een realiteit.

“We waren echt een band van broers,” zei de Ahr. “We waren altijd toegewijd aan hetzelfde doel: een succesvolle missies.”

Download dit artikel als PDF (gratis registratie vereist).

“Ik ben een beetje verbaasd dat we het klaargespeeld”

Toe te voegen aan de druk waren met de ingrijpende beperkingen van de primitieve technologie in de tijd, of het was het gemak waarmee de console operators van de Ahr kunnen fouten te maken bij het invoeren van gegevens in een telex machine tijdens een missie of die programma ‘ s schrijven voor de IBM-mainframes op ponskaarten.

“Achteraf ben ik soort van verbaasd dat we in staat waren om het af te trekken,” zegt Winters.

Elke fase van de programmering was ongelooflijk omslachtig. Programma ‘ s voor de IBM-mainframes in Houston werden geschreven op codering pads, die dan zou worden gegeven aan keypunch exploitanten die zou punch hen op kaartspellen.

Met de belangrijkste IBM Federal Systems Division-bureau dat zich bijna een mijl van de computers, het was vaak noodzakelijk voor een koerier voor het leveren van de kaart laden van het rekencentrum en de resultaten terug, het beperken van het aantal keren dat de software kon draaien tot gemiddeld 1,2 keer per programmeur per dag.

“Mijn salaris was het hetzelfde als een uur op het mainframe.” Merritt Jones, NASA computer programmeur en astrodynamicist

Hulen zei: “Als je geluk had, kreeg je een ren terug de volgende dag. Wat heb je weer werd het papier, en heel vaak, het was een core dump,” een teken dat het programma had gecrasht. Het debuggen van deze code, meestal een Assemblage van de taal Fortran, voor het identificeren van de oorzaak van het probleem was niets, zoals vandaag.

De core dump, zou een stapel papier, “misschien acht of negen centimeter” hoog, zonder een woord van de menselijke taal.

“Het zou allemaal in hexadecimaal, en je moest leren lezen en vinden de belangrijkste punten die in de dump. Wat je nodig zou waarschijnlijk op één pagina passen, maar er was niet echt een middel om te weten wat je echt nodig, dus heb je deze enorme core dumps terug,” zei Hulen.

“Je moest heel vloeiend in hexadecimale en in staat zijn tot het herkennen van uw assembler taal instructies letterlijk in machine taal,” zei hij. “Je moest het weten, zijn er veel mensen om hulp te krijgen. Op een slechte dag, het duurt misschien twee of drie dagen om het uit te werken.”

Documentatie is ook minimaal, vooral in de eerste missies. Hulen herinnert aan het werken op telemetrie software in verband met de Agena-raket gebruikt in het Project Gemini. Programmeurs gehouden een bit-by-bit uitsplitsing van elk van die software basic componenten, bekend als woorden, dat werd geschreven op een stuk karton noemden ze de bits van bestuur.

“De enige documentatie was dit bit raad die we hadden samen. Het werkte heel goed totdat op een nacht de schoonmaakploeg gooide,” zei Hulen. “We hadden geen back-up. We hadden een echte crisis, waar we om erachter te komen wat elk van die stukjes was en probeer het opnieuw bit boord, dat is nooit helemaal gelukt.”

Na verloop van tijd, echter, de ongekende omvang van de programma ‘ s wordt gewerkt nodig IBM aan de ontwikkeling van geavanceerde project management plannen, technieken die gebruikt zouden worden voor de komende decennia.

“Deze waren extreem grote software programma’ s. Er werden meer dan een miljoen regels code van de applicatie software”, zegt Winters. “Waren er maar een paar succesvolle voorbeelden van de ontwikkeling van die bedrag van de software met succes.”

Er waren ongeveer 500 IBM programmeurs gebaseerd op Johnson Space Center in Clear Lake Houston, verdeeld over 10 verschillende gebouwen. Om effectief coördineren van de beroepsbevolking, IBM kwam met een benadering van het afbreken van de software in modules worden beheerd door verschillende teams en het instellen van data voor bij het ontwerp, codering, integratie en het testen van de code zou worden voltooid.

ZIE: Digitale Transformatie: EEN CXO ‘ s Guide (ZDNet/TechRepublic bijzonder verslag)

Winters, zei één van de vroege managers, Dick Hanrahan, “de pionier van dat soort management techniek,” toevoegend dat de aanpak zou worden gebruikt voor grote projecten over IBM ‘ s Federal Systems Division.

De kracht van de processor en de hoeveelheid geheugen die beschikbaar was zo beperkt dat de programmeurs zouden besteden een enorme hoeveelheid tijd probeert te vereenvoudigen code, in het bijzonder indien een opdracht is uitgevoerd, werd herhaaldelijk.

“Ik zou maandenlang bezig om de vergelijking in een vorm die minder geheugen en sneller uitgevoerd en nog steeds een aanvaardbaar juiste antwoord. En ik bedoel maanden,” zei Jones van zijn werk berekening van ruimtevaartuigen trajecten op IBM mainframes.

“Als ik een loop waar ik zou moeten doen wat berekeningen aan de binnenkant van de loop waar ik het zou doen duizenden keren, ik zou u een maand proberen om het verwijderen van een instructie van de loop,” Jones zei. “Als ik één instructie uit, ik kon redden, zeggen de 10.000 instructie executies. Ik had alleen de 1.000.000 beschikbaar voor mij en de besturingssysteem nam een aantal van hen.”

Een ander exemplaar zag Jones schrijven van code voor het direct manipuleren van de nullen en enen van de machine code, met behulp van “maskeren instructies” voor het afleiden van een veel efficiëntere manier om te controleren of een getal groter is dan de andere.

“Als je kijkt naar de code, het zou er verschrikkelijk, maar het zou snel zijn,” zei hij.

Volgens Jones, zonder deze extreme optimalisaties, software die uitgevoerd real-time berekeningen, zoals het ruimtevaartuig huidige positie, het zou gewoon niet moeten kunnen uitvoeren op computers beschikbaar.

Gezien de IBM mainframes gebruikt in mission control had duizend keer minder geheugen dan een machine vandaag, software geladen moesten worden in secties, die elk gerelateerd zijn aan een andere fase van de reis naar de maan. Elk deel zou nemen seconden om te laden, verder bemoeilijkt het proces van het bijhouden van een ruimtevaartuig dat kon bewegen zo snel als zeven mijl per seconde.

Systemen aan boord van het ruimteschip werden massaal beperkter dan die op de grond, met het Instrument Eenheid computer aan boord van de Saturnus V-raket staat alleen de 15.000 operaties per seconde en niet het ondersteunen van de drijvende-kommaberekeningen. “Je kan zelfs niet beginnen te vergelijken met dat van vandaag,” zei Jones.

De schaarste van de rekenkracht men de relatieve waarde van de programmeur tijd tot tijd van de computer was het omgekeerde van wat het is in 2017, zei Jones.

“Vandaag de dag, kunt u kopen zoveel berekenen van macht als je nodig hebt als je het geld hebt om het te kopen, en de programmeur tijd is meer waard dan de computer. In die dagen, het ene uur op een IBM mainframe de moeite waard was om een maand van iemand met een Master ‘ s degree in wiskunde doen dit werk. Mijn salaris was het hetzelfde als een uur op het mainframe.”

Verrassend, Steele zei dat de meeste van de programmering technieken die vandaag beschikbaar waren in de jaren 1960: “Je had gewoon alle computers die kunnen profiteren van hen,” zei hij.

De beperkingen van de technologie waren zo talrijk en de berekeningen zo complex is dat het beste dat de ingenieurs op kon hopen was dat je zo dicht mogelijk bij zekerheid mogelijk.

“Er waren geen absolute ja / nos. [Maar] u had om de beslissing te maken als er waren,” zegt Steele.

Het verkrijgen van zo dicht mogelijk naar zekerheid bedoeld testen voor elke denkbare uitkomst. Echter, bepaalde dingen niet kon worden getest op de grond, zoals hoe de gewichtloze omgeving van de ruimte zou verstoren luchtbellen in de soldeerverbindingen op elektronische circuits. Zo, even belangrijk, is het leren van elke eerdere missie.

“Een ding is waar: we nooit, ooit vloog een missie die niet over een mislukking. Ooit,” zegt Steele.

Ondanks de schijnbaar onoverkomelijke problemen, het Apollo-programma niet alleen bereikt President John F. Kennedy ‘ s massaal ambitieuze doel van het zetten van een Amerikaan op de maan door het einde van de jaren 1960, maar volgde het met een of meerdere reizen naar de aarde rocky satelliet.

Tientallen jaren later, de Apollo programmeurs beschrijven een gevoel van trots, maar nog meer van zijn ongelooflijk geluk.

“Ik voel me erg gezegend te hebben gehad in de gelegenheid te zijn geweest een deel van dat. Ik voel me het is waarschijnlijk een van de mooiste dingen die me ooit zijn overkomen in mijn leven,” zegt Winters.

Steele vat het nog kernachtiger: “Er was nooit een dag, nooit een enkele dag was er niet een probleem op te lossen, en het was geweldig. Het was een geweldige rit.”

Download dit artikel als PDF (gratis registratie vereist).

Zie ook:

HPE en NASA-experiment met ‘Spaceborne Computer,’ een supercomputer, die ons zou kunnen helpen naar Mars (TechRepublic)NASA Mission Control: Foto ‘s van het verleden en het heden op het Johnson Space Center (TechRepublic)Hoe NASA maakt gebruik van virtual reality om te trainen astronauten (TechRepublic)NASA picks onderzoek teams aan te pakken ontwikkelingen in de drone, self-driving car tech (ZDNet)NASA vooruit duwt met asteroïde doorbuiging tests (ZDNet)Uber werken met de NASA te maken vliegende taxi’ s een realiteit (ZDNet)

Verwante Onderwerpen:

Ontwikkelaar

CXO

Digitale Transformatie

Tech Industrie

Smart Cities

Cloud