Problemen Mars Rover Spirit uitgelegd

Bij de EE Times is een artikel verschenen waarin wordt uitgelegd waarom eind vorige maand het contact verloren werd met de Mars Rover en wat de NASA gedaan heeft om het probleem op te lossen. Kort samengevat was de oorzaak van de crash een gebrek aan geheugen. De rover is in totaal uitgerust met 128MB RAM-geheugen en 256MB flashgeheugen. Van de 256MB flashgeheugen wordt circa 230MB gebruikt om databestanden, zoals foto's, op te slaan om verstuurd te worden naar aarde. Foto's en dergelijke blijven bewaard in het geheugen totdat er van aarde signaal komt dat het bestand succesvol ontvangen is. Deze beveiliging tegen gegevensverlies en een brakke afhandeling van geheugenallocatiefouten werden de Mars Rover bijna fataal.

Nasa logo Al vlak na de lancering van de Spirit werd het besturingssysteem geüpgrade naar een nieuwe versie. Het resultaat was dat er verschillende bestanden in het flashgeheugen achterbleven die niet meer nodig waren. Op de vijftiende dag op Mars werden er een tweetal programmaatjes naar de Spirit verstuurd om deze troep op te ruimen. Eén van deze twee programmaatjes werd echter niet succesvol ontvangen waardoor er bestanden bleven staan. Hier werd geen rekening mee gehouden door de berekeningen van NASA's data management team, waardoor een paar dagen later door de Spirit geprobeerd werd om meer geheugen te gebruiken dan er aanwezig was.

Het gevolg was een Mars Rover die geen signalen meer uitzond en slechts in een loop bezig was met rebooten. Gelukkig luisterde de Spirit nog wel naar commando's waardoor het team van de NASA in staat was om op de gok een serie low level commando's te versturen om een flink aantal bestanden te verwijderen. Vervolgens kon het bestandsysteem weer gemount worden en zonder problemen gebruikt worden na het draaien van een checkdisk programma. Om dergelijke problemen in de toekomst te voorkomen wordt door de NASA gewerkt aan een betere afhandeling van geheugenfouten.

IT-banen

Reacties (102)

zeroxcool 22 februari 2004 13:52

Er is een miljard dollar in dat ding gestopt. En dan zit er 'maar' 384MB aan geheugen in

Verwijderd @zeroxcool • 22 februari 2004 13:57

Een giga zou waarschijnlijk teveel stroom trekken, vergeet niet dat het ding moet draaien van wat zonneënergie.
Verder zou het ook kunnen dat men aan het project begonnen is toen 384MB aan geheugen nog ontzettend veel was

. Vergeet niet dat de NASA nog altijd 286s gebruikt in zijn spaceshuttles, omdat de laatste ontwerpwijziging kennelijk in de tijd van deze proc gebeurd was...
Het was eig idd wel wat onvoorzienig om zo'n kleine marge te laten in zijn geheugen, in het vervolg zullen ze toch moeten rekening houden met het feit dat wanneer er zo'n zaken optreden (overbodige files) dat ze dus niet al het geheugen functionneel kunnen inzetten.

VROEM! @Verwijderd • 22 februari 2004 14:09

Je moet op mars rekenen dat een zonnecel ongeveer 0.7 watt levert, als je ziet hoeveel cellen ze hebben is er wel een wattje of 100 zeker aanwezig.
Ik denk niet dat een GB aan flash dusdanig meer stroom trekt dat er problemen optreden.
Wat wel een feit is is dat die dingen zo minimalistisch als mogelijk ontworpen worden om elke gram massa te sparen.
Als je denkt uit te kunnen met 384MB is er geen reden om er 1GB in te stoppen. Dat maakt het alleen maar lastiger om je schijf op te ruimen.

BaatZ @VROEM! • 22 februari 2004 15:18

komt nog bij dat flash geheugen geen stroom trekt als er geen read/write operaties op worden losgelaten

kwiebus @Verwijderd • 22 februari 2004 15:12

Vergeet niet dat de NASA nog altijd 286s gebruikt in zijn spaceshuttles

Waren dat geen 8086 processors?

http://www.tweakers.net/nieuws/21786/?highlight=8086

Skinkie @kwiebus • 22 februari 2004 15:49

yup en ze draaien op ELKS

http://flightlinux.gsfc.nasa.gov/

Auteur

Hielko @zeroxcool • 22 februari 2004 13:55

Allereerst werd de Rover natuurlijk al jaren en jaren geleden gebouwd en toen was 384MB alles behalve weinig. Daarnaast moet er wel rekening mee gehouden worden dat geheugen gebakken op kleinere productieprocede's (en dus meer capaciteit) gevoeliger zijn voor straling enzo wat een reeel probleem is in space.

RobzQ @Hielko • 22 februari 2004 14:00

Ik weet niet of dit echt een argument is. Men kan schijnbaar wel vlak voor de lancering de gehele software upgraden (zonder het fatsoenlijk te testen!) maar niet een flashkaartje bijprikken?

brainball @RobzQ • 22 februari 2004 15:21

Ik kan me niet voorstellen dat ze het niet door en door getest hebben.
Over het algemeen woordt de door nasa geschreven code voor dit soort dingen gezien als een van de zuiverste en beste.

Het probleem zat m ook niet in het feit dat er niet getest was, maar dat er een paar files overbodig waren geworden die niet verwijderd waren.
Ze kunnen nou eenmaal geen volledige installer omhoog sturen

EnsconcE @RobzQ • 22 februari 2004 15:39

ff bijprikken is geen optie op een custom build robot, deze robot is gebouwd op 384 mb. de kosten om alles te vervangen en zodoende meer geheugen te krijgen zijn gewoon te hoog. reken maar uit: nieuw (custom build)moederbord, aangepaste software, aangepaste (custom build?)bios en extra(custom build?) geheugen en dan heb ik waarschijnlijk ook nog enkele dingen over het hoofd gezien

Ashe @RobzQ • 22 februari 2004 20:58

Reactie op brainball:

Moesten ze bij de NASA echt zeer goed en nauwkeurig getest hebben, dan snap ik niet waarom ze een half mislukte upload zomaar over het hoofd zien.

In principe stel je bij dergelijke voorbereidingen en testen verschillende scenario's voor wat er mogelijk allemaal kan mis gaan. Een half mislukte upload zou daar zeer zeker in thuis horen vind ik persoonlijk.

Janoz Moderator PRG/SEA @RobzQ • 23 februari 2004 10:00

Op het moment van lanceren was de software nog niet eens af. Dit hebben ze gewoon als firmware update verstuurt vlak voordat hij moest landen.

Op dat moment de geheugen modules vervangen gaat een beetje lastig

.

Daarnaast gaat het hier om een embedded systeem. Er draait geen fullblown windows achtig operating system op. Het gebruikte geheugen is daarnaast ook niet hetgeen je om de hoek bij de pcboer koopt. Het moet bestand zijn tegen de hoge radioactiviteit en enorme temperatuur verschillen die er in de ruimte heersen.

GBits @RobzQ • 23 februari 2004 10:13

Het is natuurlijk geen consumenten flashkaartje wat je er even bij prikt.

Dit flash moet aan space kwalificaties voldoen, dat is dus iets anders dan 0-55 graden celcius waarop consumenten elektronica is gespecificeerd.

ajvdvegt @RobzQ • 23 februari 2004 11:20

'Geen fullblown operating system'?!? Juist wel! Het is alleen niet bloated: het zou wel ERG onzinnig zijn om er een GUI om heen te hangen.
Die dingen draaien een commercieel OS hoor, VxWorks. Hier kan je meer vinden: http://www.windriver.com/. Dat OS wordt ook voor medische applicaties e.d. gebruikt. 'niet fullblown....' ......voordat ze in Redmond zover zijn als bij Windriver zijn we nog heel wat jaren verder hoor!

SCRAP @zeroxcool • 22 februari 2004 18:53

Er is een miljard dollar in dat ding gestopt. En dan zit er 'maar' 384MB aan geheugen in

Het hoe wat en waarom, zie hieronder.

Plok schreef:

Probleem is dus dat de componenten in de ruimte stralingshard moeten zijn. Moderne componenten zijn dat in de regel niet, zodat de kans groot is dat componenten gaan sneuvelen. Vrijwel alle microprocessoren die in zogenaamde space qualified hardware zit is daarom ook een electronica die je bij je electronicaboer op de hoek kan kopen, maar is militair spul. Er zijn maar een beperkt aantal fabrikanten die productielijnen hebben hiervoor. Op dit moment loopt er dus een project om een 486 achtige processor door de qualificatie heen te slepen.
Ook geheugen is dus een probleem in de ruimte. Of je hebt zware (dus dure) afscherming nodig, of je neemt speciaal geheugen (wat dus meestal vrij klein is). Processoren in satellieten bijvoorbeeld draaien meesal op 16 tot 40 MHz en hebben meestal niet meer dan 64 of 128 kB aan geheugen. Meer komt soms wel voor, maar het gevolg is meestal dat een paar keer per maand zogenaamde bit-flips gedetecteerd worden. Hier kan weer voor worden gecorrigeerd, maar met ennige regelmaat komen zelfs dubbele flips voor, waardoor instrumenten voor de zekerheid maar gereboot worden.

rapture @SCRAP • 22 februari 2004 20:31

Military/Aerospace-elektronica is goedgekeurde elektronica. (lees: chips die een burnin-test krijgen van 24 uur) Door de burn-in-test weet men zeker dat een stuk elektronica probleemloos werkt.

De commerciële elektronica (die wij gebruiken) is bijna alleen op productie gericht en als er een kapotte stuk elektronica tussen zit, dan verwachten ze die in de RMA-afdeling. Military/Aerospace kan niet op de RMA wachten...

Bovendien kan je niet een stuk Military/Aerospace-elektronica kopen bij je elektronicaboer, want de klant bepaalt meestal zelf de omstandigheden waaronder een stuk elektronica probleemloos moet werken.

Military/Aerospace-uitvoering van een stuk commercieel elektronica kost minstens paar keren meer, testen/keuren kost tijd en geld.

Als je straling op geheugenchips zet, dan kunnen er paar bits verkeerd staan wegens straling en hoe kleiner de productieproces (nanometers), hoe meer problemen. En als er paar bits verkeerd staan, dan kan er veel misgaan.

Aan de ene kant probeer men de straling zoveel mogelijk buitenhouden (bv lood houdt per millimeter de meeste straling tegen, maar veel te zwaar voor in de ruimte, loden platen worden wel gebruikt in kerncentrales).

Aan de andere kant test men elektronica op stralingsgevoeligheid.

Meestal wordt Military/Aerospace-elektronica 2- of 3-dubbel gemaakt, zodat als er iets kapot gaat, dat er nog genoeg hotspares zijn die ervoor zorgen dat het nog probleemloos werkt.

packman @rapture • 23 februari 2004 12:08

Er komt wel "net iets meer" bij te pas dan enkel een 24u burnin test hoor. Bij moderne ontwerpen moet dit vanaf design-niveau worden voorzien omdat de componenten te klein worden, waardoor bij een impact van een ioon (dat meer dan 100m beton kan penetreren met de snelheid die die halen in space) meerdere bits zouden kunnen corrupten, of zelfs in het logische circuit iets kunnen wijzigen waardoor een berekening een fout resultaat geeft (wat rampzalige en dure gevolgen kan hebben in de ruimte

) Bij de oudere ontwerpen kon men - door de grootte - door een specifieke (en dure) productietechniek te gebruiken dit bekomen met slechts kleine wijzigingen aan het ontwerp. Bij nieuwe productietechnieken echter - om hogere (en benodigde) snelheden te halen is dit echter niet meer mogelijk. Dit weekend hier nog een interessante presentatie over gezien op fosdem...

De redenen dat er trouwens maar zo weinig geheugen opzit zijn:
- Full-tolerance military compliance
- stroomverbruik - elke milliwatt meer is er eentje teveel
- gewicht - meer chips = meer gewicht, meer stroomverbruik = meer gewicht voor stroombron
- fout tolerantie: meer componenten, meer kans dat er iets kapotgaat waardoor er enkele miljarden de ruimte zijn ingeschoten die ze dan beter gewoon aan mij hadden gegeven

Verwijderd @rapture • 22 februari 2004 23:24

Onderdelen gemaakt voor militaire doeleinden, of beter gezegd, geproduceerd volgens militaire specificaties, zijn voor een belangrijk deel zo duur vanwege het produktieproces. Alles, maar dan ook echt alles moet volgens speciaal gedefinieerde regels uitgevoerd worden ("mil-specs"). Tevens moet elke sample ook precies aan allerlei strenge regels en specificaties voldoen, voor, tijdens en na elke stap in het productieproces.

Aaargh! @zeroxcool • 22 februari 2004 13:56

Dat is wel speciaal geheugen dat beschermd is tegen straling.

Verwijderd @Aaargh! • 22 februari 2004 14:05

En dit betekent, 10mm Aluminium errond of zoiets, om de geladen deeltjes uit de zonnewind tegen te houden (= protonen, electronen en nog wat ionen aan 500-800km/s, dit kan wel tellen dus). Het geheugen moet er echt niet voor aangepast worden, en zo heb je tegelijk een mooie koelblok eraan om te ocen

http://www.oma.be/BIRA-IASB/Public/Research/Belts/Particles1.nl.html

langgelee2002 @Verwijderd • 22 februari 2004 18:45

Leuk en aardig, maar dat had dan prima een module van 512 of zelfs 1024 MB kunnen zijn. Met zon budget kan je alles op maat laten maken, zelfs 'jaren later' ..

Trouwens,

Eén van deze twee programmaatjes werd echter niet succesvol ontvangen waardoor er bestanden bleven staan

Ik dacht dat er 'geen bit verloren' was gegaan binnen het eerste interplanetaire netwerk, zoals ons onlangs hier werd bericht..

Verwijderd @Verwijderd • 22 februari 2004 19:06

En waaraan moet die warmte worden afgestaan ?
Het is sowieso behoorlijk koud daar, koeling is vanzelf al aanwezig.

fallusballus @Verwijderd • 22 februari 2004 21:24

Reactie op Strijder:

Koud, maar ook wel warm en bij hoge straling. De temperatuur op Mars (afhankelijk van welk gebied) kan dacht ik iets van 150 graden tussen dag en nacht varieren (ik dacht dat het was +40gr C en -110 gr C). Kan dus beide kanten opgaan...

Tadango @Verwijderd • 23 februari 2004 00:55

Koeling gaat door lucht, en die is er in de ruimte niet dus....

Iblies @Verwijderd • 23 februari 2004 14:32

@ Crash, misschien mierenneukerij, maar je bedoelt dat vaccuum niet geleid. Koeling is niets meer of minder dan warmte afvoeren, en dat kan op verschillende manieren. Lucht wordt vaak gebruikt, maar ook water, stikstof. Tweakers zouden dat toch moeten weten.

Tomatoman @Aaargh! • 22 februari 2004 22:16

De temperatuur op Mars is niet eens zo belangrijk, het is de temperatuur onderweg. Daar is het 4 Kelvin (vlakbij het absolute nulpunt dus). Bovendien kunnen er onderweg enorme bombardementen met röntgenstraling plaatsvinden, iets waar elektronische circuits (en ook mensen) slecht tegen kunnen.

Dat betekent dat de ontwerpspecificaties bijzonder streng zijn. Ook al kost een flashkaartje nauwelijks geld, om te testen of zo'n ding aan de specificaties voldoet ben je miljoenen euro en maanden testwerk kwijt. 'Effe' upgraden is er dus niet bij.

Dual Infinity @Tomatoman • 24 februari 2004 10:21

hmm, volgens mij klopt dat niet. Er bestaat altijd nog zoiets als stralingswarmte. Als ik me niet vergis is er in de ruimte sprake van enorme variaties, welke bepaald worden door de hoeveelheid zonlicht (straling) waar je 'in' zit.

4 Kelvin zal best voorkomen, maar zal niet de constante temperatuur zijn.

Rembert 22 februari 2004 14:38

't Is wel een bijzonder apart OS: de directory structuur zelf zou al beperkend zijn voor opslag van bestanden. Kennelijk een filesystem met iets als fat- slots of zo. Files worden uiteindelijk geupload zodra er een communicatie slot is. Ok, klinkt logisch, maar wat ik niet wist is dat dit ook via een relay kon: er cirkelen hiervoor 2 satellieten om Mars, deze vangen ook bestanden op en sturen die dan door naar Aarde (als de bestanden niet al rechtstreeks zijn verzonden).

Inderdaad, 1 proggie was niet correct ontvangen en die zou opnieuw worden verzonden. Het was niet het team dat in de tussentijd meer (teveel) geheugen probeerde te alloceren maar de de marsrover zelf. En de exception (blue screen

nah.. ) resulteerde in de reboot loop. Bij het booten werd kennelijk eerst het communicatie OS gestart en daarna pas het flash file system. Op het moment dat dit laatste werd gestart, trad wederom een exception op, reboot enz. Het team was uiteindelijk in staat om het opstarten van het flash OS te stoppen. De Mars Rover was op dat moment dus gewoon operationeel en in staat te communiceren met Aarde.

op de gok een serie low level commando's te versturen

Het lijkt me niet dat er iets op de gok is gebeurd. Er werd wel een script geupped om het flash geheugen op te ruimen, zo'n 1000 bestanden moesten worden verwijderd. En daarna kon het flash OS ook weer rebooten.

Verwijderd 22 februari 2004 14:30

Had ik niet verwacht dat ze zo bekrompen met geheugen om geheugen om zouden springen.
IPV groot geheugen, grote blunder eigenlijk.

zo weinig intern geheugen maar

Und so weiter, und so weiter...

Onvoorstelbaar dat er elke keer weer van die figuren zijn die het veeel beter weten dan de ontwikkelaars (in dit geval NASA/JPL).
Er zal echt wel een goede reden zijn dat er een bepaalde hoeveelheid geheugen gebruikt wordt.

Het zijn de zelfde type figuren die bv. een moederboard Kwalitatief Uitermate Triest vinden omdat de floppy-connector volgens hen op een waardeloze plek zit. Of de geheugenbanken, of whatever.

twiFight @Verwijderd • 22 februari 2004 15:55

Ik moet het helaas met je eens zijn. Onvoorstelbaar hoe tientallen huis tuin en keuken programmeurs wel even weten hoe zo'n marsferrari moet werken, hoeveel ram erin had gemoeten "want zij hebben immers ook 1 GB in hun bak" en de NASA dat zijn maar amateurs hoor.

! Ik ben blij dat er nog wat mensen zijn die doorhebben dat het in die tijd best veel was, je niet zomaar ff een reepje erbij prikt en ook ik vind het "grappig" te horen hoe mensen in alle hoeken van de IT problemen blijven houden. Ik vind het trouwens nog knap hoe ze van afstand nog zoveel commandos kunnen uitvoeren. Dat was vroeger wel anders.

Trouwens ook tof dat de NASA naar buiten heeft gebracht wat de problemen precies waren en hoe ze het opgelost hebben. Veel mensen hier interesseren zich er veel voor en het brengt ruimtevaart ook iets meer in de maatschappij.

Verwijderd @twiFight • 22 februari 2004 16:28

Eigelijk zijn het ook gewoon amateurs zoals abit en resettim & A.P versteeg.
Alleen met een groot buget en met zijn 10 tallen i.p.v alleen.
Zo`n zonde werkt gewoon op de normale pc hardware, enigzins aangepast, op vorm & maat maar er zit echt geen super seciale onbekende hardware in.
De 1e mars karretje, exploder had zelfs molinex pluggen!!!!

Geef me 100.000 euro en ik bouw een zender en stuur er zelf even een programmatje heen.
Een kleine linux distro en een koetje.
of een paar leuke foto`s voor het nasa team.

P.S het is echt niet zo moeilijk hoor.

Kheldar 22 februari 2004 14:42

Zo een probleem hadden ze de vorige keer ook al

. Op die apparaatjes draait een realtime OS en de vorige keer hadden ze een probleem met de prioriteiten.

Er was een proces met een lage prioriteit dat bezig was met IO, vervolgens draaide er een proces met normale prioriteit dat constant de cpu gebruikte. Op een gegeven moment werd er een proces met hoge prioriteit uitgevoerd dat dezelfde IO wilde doen als het proces met de lage prioriteit, dus pauzeerde het hoge prioriteitproces. Hierdoor kreeg het normale proces de cpu weer terug, maar deze gebruikte de cpu zoveel dat het lage prioriteitproces zijn IO niet af kon handelen, waardoor dus ook het hoge prioriteitproces niks kon en het normale proces maar door bleef draaien. Toen kon het apparaat dus eigenlijk niets meer...

Dit soort fouten sluipen erin doordat die mensen bij de NASA onder verschrikkelijke tijdsdruk staan. Ik heb laatst op National Geographic een docu gezien over de makers van het landingssysteem van de Spirit en zijn broer. Dat was ook allemaal maar op het laatste moment klaar, omdat ze vlak voor de deadline er achterkwamen dat de parachute niet goed was...

Frank-L @Kheldar • 22 februari 2004 15:49

Het probleem wat jij omschrijft staat bekend als "Priority Inversion". Goede real-time kernels hebben hier een oplossing voor, genaamd "Priority Inheritance", wat erop neer komt dat zodra de hoge-prioriteitstaak moet wachten op een resource, de taak die op dat moment de resource heeft, tijdelijk de prioriteit krijgt van de wachtende taak. Ik weet niet of VxWorks (wat in andere reakties genoemd wordt als OS wat hier gebruikt is) dit kent. Wel weet ik dat de andere real-time kernel van WindRiver (pSOS) vanaf versie 2.5 deze voorziening kent.

SeatRider @Frank-L • 22 februari 2004 15:59

Kewle technologie. Ik neem aan dat dat alleen gebeurt als het wachtende proces een hogere prio heeft als het proces dat de resource op dat moment gebruikt

Bigs 22 februari 2004 15:34

Iedereen roept hier nu wel over het feit dat het ding maar 384mb geheugen heeft, maar het geheugen voor de foto's e.d. dient alleen als buffer voor de momenten dat er geen communicatie met de aarde is. Zogauw die er wel is worden de bestanden verstuurd en wanneer er een signaal van de aarde terugkomt dat ze goed ontvangen zijn worden ze gewist. Dus waarom zou je dan meer nodig hebben?

Yoshi @Bigs • 22 februari 2004 16:30

daarbij komt dat er wel degelijk bespaard moet worden op stroom, die heeft nl niet de hele tijd zonnelicht, en heeft enorm veel stroom nodig voor de meetapperatuur dus elke watje dat ze kunnen besparen doen ze

kvind dat die manne da goe gedaan hebben, alleen spijtig dat de beagle II niets van zich laat horen

Verwijderd @Bigs • 22 februari 2004 16:34

iedereen vergeet de hardeschijf van 3 gig

Blokker_1999

Wetenschap

22 februari 2004 13:59

De 2 mars landers van de NASA werken met JAVA, het onderliggende OS werd hierboven al vermeld

bgever @Blokker_1999 • 22 februari 2004 15:00

Waarom niet een taal die direct naar machinecode kan worden omgezet? Ik neem aan dat zoiets toch wel in performance zal schelen?

Ik dacht dat ze er altijd op uit waren om zo weinig mogelijk te verbruiken? Dan moet je vooral met JAVA gaan werken waarbij eerst de bytecode moet worden ontcijferd...

Left @bgever • 22 februari 2004 16:57

Ik denk dat er voor Java gekozen is omdat je met Java, ironisch genoeg, minder kans maakt fouten te maken. De Jvm handelt je geheugenmanagement voor je af en daar kun je dus geen fouten meer mee maken. Beetje jammer dat het OS vervolgens weer alles in het water laat vallen.

sid3windr @bgever • 22 februari 2004 16:58

Dat hoeft helemaal niet...

Drogo 22 februari 2004 13:55

Hier werd geen rekening mee gehouden door de berekeningen van NASA's data management team...

Dat lijkt me nou net het enige waar een afdeling met de naam 'data management team' rekening mee moeten houden...

Verwijderd @Drogo • 22 februari 2004 16:34

Human error he...

Verwijderd @Verwijderd • 24 februari 2004 09:36

user error, replace user????

Tyf 22 februari 2004 14:10

Ja echt raar zo'n duur project en dan zo'n probleem.

Dat er niet veel geheugen in zit is echt wel niet raar
zoals al gezegd werd dit geheugen moet bestand zijn tegen zeeeeeeeeer extreme temperaturen, dus stoppen ze daar niet ff gewone ram in. It's not the size that matters it's what u do with it!
En ik denk dat het ruim voldoende is voor wat ze ermee willen doen.