På slutten av 1950-tallet, før NASA hadde noen intensjoner om å dra til Månen - eller trenge en datamaskin for å komme dit - hadde MIT Instrumentation Laboratory designet og bygd en liten prototype som de håpet en dag skulle fly til Mars (les bakgrunnen delvis 1 av denne historien her). Denne lille sonden brukte en liten, rudimentær generell datamaskin for navigasjon, basert på treghetssystemene for ballistiske missiler, ubåter og fly Lab hadde designet og bygget for militæret siden andre verdenskrig.
Folkene på Instrumentation Lab trodde at Mars Probe-konseptet deres - og spesielt navigasjonssystemet - ville være av interesse for de som var involvert i det nye planetariske letearbeidet, som det amerikanske flyvåpenet og Jet Propulsion Laboratory. Men da MIT Lab nærmet seg dem, var ingen av enhetene interessert. Luftforsvaret var på vei ut av romfartsvirksomheten, og JPL hadde planer om å drifte sitt eget planetariske romfartøy ved å navigere fra den store kommunikasjonsfatet Goldstone i Mojave-ørkenen. Den 26 meter lange radarskålen var blitt konstruert for å spore de tidlige robot Pioneer-probene.
Både Luftforsvaret og JPL foreslo at Lab snakket med folk om den nyopprettede NASA-organisasjonen.
Lab-medlemmer besøkte Hugh Dryden, viseadministrator for NASA i Washington D.C., og Robert Chilton, som ledet NASAs Flight Dynamics Branch ved Langley Research Center. Begge mennene mente at laboratoriet hadde gjort noen veldig fine arbeider med designen, spesielt på veiledningsdatamaskinen. NASA bestemte seg for å gi laboratoriet $ 50 000 for å fortsette studiene på konseptet.
Senere ble det opprettet et møte mellom Labs leder, Dr. Charles Stark Draper og andre NASA-ledere for å diskutere de forskjellige langdistanseplanene som NASA hadde i tankene, og hvordan Labs design kan passe inn i et romfartøy pilotert av mennesker. Etter flere møter ble det bestemt at systemet skulle bestå av en generell digital datamaskin med kontroller og skjermer for astronautene, en rom-sekstant, en treghedsstyringsenhet med gyros og akselerometre, og all bærende elektronikk. I alle disse diskusjonene var alle enige om at astronauten skulle spille en rolle i driften av romfartøyet og ikke bare være med på turen. Og alle NASA-folket likte spesielt den selvforsynte navigasjonsevnen, siden det var frykt for at Sovjetunionen kunne forstyrre kommunikasjonen mellom et amerikansk romfartøy og bakken, noe som utsatte oppdraget og astronautenes liv.
Men så ble Project Apollo født. President John F. Kennedy utfordret NASA i april 1961 til å lande på Månen og returnere trygt til Jorden - alt før slutten av tiåret. Bare elleve uker senere, i august 1961, ble den første hovedkontrakten for Apollo signert med MIT Instrumentation Laboratory for å bygge veilednings- og navigasjonssystemet.
"Vi hadde en kontrakt," sa Dick Battin, ingeniør ved Lab som hadde vært en del av Mars Probe designteam, "men ... vi hadde ingen anelse om hvordan vi skulle gjøre denne jobben, annet enn å prøve å modellere den etter Mars sonde."
En del av leken til Apollo Guidance Computer (AGC) er at noen av spesifikasjonene som er oppført i Labs 11-siders forslag i utgangspunktet ble trukket ut av tynn luft av Doc Draper. På grunn av mangel på bedre antall - og å vite at det måtte trenge å passe inn i et romfartøy - sa han at det ville veie 100 pund, være 1 kubikkfot i størrelse og bruke mindre enn 100 watt strøm.
Men på den tiden var svært få spesifikasjoner kjent om noen av de andre Apollo-komponentene eller romfartøyene, da ingen andre kontrakter hadde blitt utleid, og NASA hadde ennå ikke bestemt seg for metoden sin (direkte oppstigning, Earth Orbit Rendezvous eller Lunar Orbit Rendezvous) og hvilke typer romskip som kommer til månen.
"Vi sa: 'Vi vet ikke hva jobben er, men dette er datamaskinen vi har, og vi skal jobbe med den, vi skal prøve å utvide den, vi skal gjøre alt vi kan,' sa Battin . "Men det var den eneste datamaskinen som noen har i landet som muligens kunne utføre denne jobben ... uansett hva denne jobben måtte være."
Battin husket hvordan alternativet for å fly til månen til å begynne med ville være jordomkjøring, der de forskjellige delene av romfartøyet ville bli lansert fra jorden og kombinert i jordens bane og fly til månen og lande der som en helhet. Men etter hvert vant møteplanen for månens bane ut - der lander skulle skille seg fra kommandomodulen og lande på månen.
"Så da det skjedde, så var spørsmålet ... trenger vi et helt nytt og annet ledelsessystem for Lunar Module enn vi har for Command Module?" Battin sa. “Hva skal vi gjøre med det? Vi overbeviste NASA om å bruke det samme [datamaskin] -systemet i begge romfartøyene. De har forskjellige oppdrag, men vi kan legge et duplikatsystem i månemodulen. Så det var det vi gjorde. ”
Det tidlige konseptuelle arbeidet med Apollo Guidance Computer (AGC) foregikk raskt, med Battin og hans årskull Milt Trageser, Hal Laning, David Hoag og Eldon Hall som arbeidet ut den overordnede konfigurasjonen for veiledning, navigasjon og kontroll.
Veiledning innebar å dirigere bevegelsen av et fartøy, mens navigering refererte til å bestemme nåværende posisjon så nøyaktig som mulig, i forhold til et fremtidig reisemål. Kontroll refererte til å dirigere kjøretøyets bevegelser, og i rommet retningene knyttet til dets holdning (gir, stigning og rulle) eller hastighet (hastighet og retning). MITs ekspertise sentrerte seg om veiledning og navigasjon, mens NASA-ingeniører - spesielt de som hadde erfaring med å jobbe med Project Mercury - la vekt på veiledning og kontroll. Så de to enhetene jobbet sammen for å lage manøvrene som ville være nødvendige basert på data fra gyros og akselerometre og hvordan manøvreringene skulle bli en del av datamaskinen og programvaren.
For MIT Instrumentation Lab var påliteligheten en stor bekymring for Apollo Guidance Computer. Datamaskinen ville være hjernene til romfartøyet, men hva om det mislyktes? Siden overflødighet var en kjent løsning på det grunnleggende pålitelighetsproblemet, foreslo folk på The Lab å inkludere to datamaskiner om bord, med en som sikkerhetskopi. Men North American Aviation - selskapet som bygger Apollo kommando- og servicemoduler - hadde sine egne problemer som oppfylte vektkrav. Nordamerikanske balket raskt over størrelsen og plasskravene til to datamaskiner, og NASA var enig.
En annen ide for økt driftssikkerhet inkluderte å ha sparebrett og andre moduler ombord i romfartøyet slik at astronautene kunne gjøre "vedlikehold under flyging", og bytte ut defekte deler mens de er i rommet. modul, og å sette inn et ekstra kretskort mens han var på godkjenning, virket månen uhøflig - selv om dette alternativet ble sterkt vurdert over ganske lang tid.
"Vi sa:" Vi skal bare gjøre denne datamaskinen pålitelig, "husket Battin. "I dag vil du bli kastet ut av programmet hvis du sa at du skal bygge det slik at det ikke mislykkes. Men det er det vi gjorde. "
Høsten 1964 begynte The Lab å designe sin oppgraderte versjon av AGC, hovedsakelig for å dra nytte av forbedret teknologi. Et av de mest utfordrende aspektene ved Apollo-oppdraget var mengden sanntids databehandling som kreves for å navigere i romfartøyet til Månen og tilbake. Da ingeniørene på laboratoriet først begynte arbeidet med prosjektet, stolte datamaskiner fortsatt på analog teknologi. Analoge datamaskiner var ikke raske eller pålitelige nok for et oppdrag til Månen.
Integrerte kretsløp, som nettopp ble oppfunnet i 1959, var nå mer dyktige, pålitelige og mindre; de kunne erstatte de tidligere designene ved hjelp av kjernetransistorkretser, og tok omtrent 40 prosent mindre plass. Så raskt som teknologien hadde avansert siden MIT vant AGC-kontrakten i 1961, følte de seg sikre på ledelsestiden til Apollos første flytur ville gi større fremskritt i pålitelighet og forhåpentligvis reduksjoner i kostnadene. Med den avgjørelsen ble AGC en av de første datamaskinene som brukte integrerte kretsløp, og snart ble over to tredjedeler av den totale amerikanske produksjonen av mikrokretser brukt til å bygge Apollo-datamaskinens prototyper.
Bly bildetekst: En tidlig integrert krets, kjent som Fairchild 4500a integrert krets. Bildetillatelse: Draper.
Selv om mange designelementer for datamaskinvaren begynte å komme på plass, ble en irriterende sak midt på 1960-tallet åpenbar: minne. Det originale designet, basert på Mars Probe, hadde bare 4 kilobyte ord med fast minne og 256 ord som kan slettes. Etter hvert som NASA tilførte flere aspekter til Apollo-programmet, fortsatte minnekravene å øke, til 10 K, deretter 12, 16, 24 og til slutt til 36 kilobyter fast minne og 2 K oferasable.
Systemet Lab utarbeidet ble kalt kjernetau-minne, med programvare som ble nøye opprettet med nikkellegeringstråd vevd gjennom de bittesmå magnetiske ‘donuts’ for å skape det ikke-slettbare minnet. På språket til datamaskiner og nuller, hvis det var en, løp den gjennom smultringen; hvis det var en null, løp ledningen rundt den. For en minnekomponent tok det bunter på en halv kilometer tråd vevd gjennom 512 magnetiske kjerner. Én modul kan lagre over 65 000 informasjonsstykker.
Battin kalte prosessen for konstruksjon av kjernevirksomheten LOL-metoden.
“Lille gamle damer,” sa han. "Kvinner i Raytheon-fabrikken ville bokstavelig talt vev programvaren i dette kjernetau-minnet."
Mens kvinner først og fremst utførte vevingen, var de ikke nødvendigvis gamle. Raytheon ansatte mange tidligere tekstilarbeidere, flinke til å veve, som måtte følge detaljerte instruksjoner for å veve ledningene.
Da kjernetau-minnene først ble bygget, var prosessen ganske arbeidsintensiv: to kvinner satt overfor hverandre de ville vevet for hånd en strøm av ledninger gjennom bittesmå magnetiske kjerner og presset en sonde med ledningen festet fra den ene siden til den andre. I 1965 ble det implementert en mer mekanisk metode for veving av ledningene, basert på tekstilmaskiner brukt i New Englands vevingsindustri. Men likevel var prosessen ekstremt treg, og det kunne ta flere uker eller måneder å veve et program, med mer tid til å teste den. Eventuelle feil i vevingen betydde at den måtte gjøres om. Command Module-datamaskinen inneholdt seks sett med kjernetau-moduler, mens Lunar Module-datamaskinen inneholdt syv.
Totalt var det omtrent 30 000 deler i datamaskinen. Hver komponent ble satt gjennom en elektrisk test og en strengestest. Enhver feil oppfordret til avvisning av komponenten.
"Selv om minnet var pålitelig," sa Battin, "det NASA ikke likte med det, var det faktum at du ganske tidlig trengte å bestemme hva dataprogrammet skulle bli. De spurte oss, 'Hva om vi hadde en endring i siste øyeblikk?', Og vi sa at vi ikke kan ha endringer i siste øyeblikk, og når som helst du vil endre minnet, betyr det en seks ukers utglidning, minimum. Da NASA sa det var utålelig, sa vi dem: "Det er slik denne datamaskinen er, og det er ingen andre datamaskiner som du kan bruke."
Mens design og bygging av all maskinvaren stilte utfordringer, mens arbeidet gikk videre med AGC gjennom 1965 og inn i 1966, skilte størrelsen og kompleksiteten til et annet aspekt ut: programmering av programvaren. Det ble det viktigste definerende problemet med datamaskinen, når det gjaldt både tidslinjer og spesifikasjoner.
All programmering var i utgangspunktet gjort på dem og nullnivå, montering språk programmering. I utformingen av programvaren for å utføre kompliserte oppgaver, trengte programvareingeniørene å komme med geniale måter å passe koden innenfor minnebegrensningene. Og selvfølgelig har ikke noe av dette vært gjort før, i alle fall ikke til dette nivået av skala og kompleksitet. Samtidig kan AGC måtte koordinere flere oppgaver på en gang: å ta utlesninger fra radaren, beregne bane, utføre feilretting på gyros, bestemme hvilke thrustere som skal skytes, samt overføre data til NASAs bakkestasjoner og ta nye innspill fra teatronautene .
Hal Laning tenkte på det han kalte et utøvende program, som tildelte oppgaver forskjellige prioriteringer og tillot oppgaver med høy prioritet å gå i stykker før de hadde lav prioritet. Datamaskinen kunne fordele minne mellom forskjellige oppgaver, og følge med på hvor en oppgave ble avbrutt.
Labs programvareteam begynte med vilje å designe programvaren med en prioritert planleggingsfunksjon som kunne identifisere de viktigste kommandoene og la dem løpe uten avbrudd fra mindre viktige kommandoer.
Høsten 1965 ble det imidlertid tydelig for NASA at Apollo-datamaskinen var i alvorlige problemer, ettersom utviklingen av programmene var betydelig etter planen. At en relativt ukjent mengde kalt ‘programvare’ kunne forsinke hele Apollo-programmet ble ikke godt mottatt av NASA.
Neste: Del 3, og finn ut det hele.
