Selvreparerende computer fra DTU skal bruges i rummet
more_vert
close
close

Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og at Mediehuset Ingeniøren og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, tilbud mm via telefon, SMS og email. I nyhedsbreve og mails fra Mediehuset Ingeniøren kan findes markedsføring fra samarbejdspartnere.

Selvreparerende computer fra DTU skal bruges i rummet

Den amerikanske rumfartsorganisation Nasa er blevet interesseret i et meget eksotisk dansk computerdesign. Der er tale om en computer, der kan reparere sig selv - omtrent på samme måde, som når et menneske reparerer sig selv med sårheling og knoglebrud, der vokser sammen igen.

Derfor har den fået navnet eDNA, fordi ideen om uprogrammerede stamceller er en god metafor for mekanismen.

Sådan en computer kan blive ekstremt robust, næsten usårlig. Og det kan Nasa bruge til noget. Rummet er nemlig et farligt sted for elektronik, som ofte tager skade af solvinde og kosmisk stråling. Og da det er sjældent, man kan sende en servicetekniker af sted for at reparere elektronik i rummet, så går satellitter og andet kostbart udstyr ofte tabt, når den første alvorlige fejl indtræffer.

Nasas interesse har medført, at en ph.d.-studerende fra DTU Informatik, Michael Reibel Boesen, i øjeblikket befinder sig i Californien hos Nasas Jet Propulsion Laboratory. Her skal han prøve at bygge den danske computer ind i et spektrometer, som er magen til et, der skal i kredsløb om Mars og lede efter livstegn på planeten. Det sker ved at måle på gasser i den tynde atmosfære.

Hans ambition er imidlertid at opnå, at Nasa også vælger at implementere det robuste computerdesign i satellittens navigationssystem.

Det næste skridt efter redundans

»Det hele begyndte med, at vi overvejede, hvordan man kunne lave en virkelig pålidelig computer,« fortæller professor Jan Madsen fra DTU Informatik.

Den typiske metode er at bruge redundans, det vil sige et system, som på en eller anden måde er dubleret, sådan at reserveelementer kan tage over, hvis en komponent går i stykker. Det er derfor, fly har dobbelte tændingssystemer og somme tider flere motorer. Og det er derfor, bankerne bruger spejlede servere til kundernes data.

Men redundans er et gammelt og velkendt princip. Det måtte være muligt at udvikle nye principper, der gav et "giant leap", et kæmpespring fremad.

Resultatet er en konstruktion, som har et større antal ufærdige computer-enheder på samme chip. Altså nogle helt ens processor-celler med egne hukommelsesområder. Nogle af de små computere skal specialiseres til forskellige opgaver, der skal løses, mens resten skal ligge passivt i reserve uden specialisering.

I det øjeblik en af de fungerende computer-celler fejler - af en eller anden grund - overføres dens specialisering og arbejdsopgaver til en reservecelle, og den oprindelige celle drosles ned og slukkes. I princippet som en menneskelig stamcelle, der specialiseres og tages i brug første gang.

I praksis sker det ved, at hver af de fungerende computerceller også udfører en sekundær skyggeproces i baggrunden, som er en kopi af en anden celles primære opgave. Hvis de to parallelle processer pludselig får forskellige resultater, er der noget galt. Og en særlig algoritme bestemmer så, om en af dem skal tages ud af drift og erstattes med en af reserverne.

Målet er en ASIC

»I vores forsøgsmodeller har vi til hver celle brugt en aritmetisk enhed med lokal hukommelse til at udføre selve beregningen og en lille processor (picoBlaze) til at udføre konfigurering og reparation af cellen. Den lokale hukommelse skal blandt andet rumme opskriften på dens særlige funktionsegenskaber. I første omgang er processorenheden implementeret i 81 eksemplarer i en rekonfigurerbar FPGA, men meningen er, at der til sidst skal fremstilles en ASIC, altså en færdig chip med de samme egenskaber, men med flere celler,« siger han.

Mellem de forskellige celler, både fungerende og reserver, er et mesh-netværk lagt ned i samme chip. Det er altså et privat netværk mellem cellerne, hvori der løber informationer via en særligt udviklet dataprotokol. At det hedder et mesh-netværk skyldes, at alle celler ikke er direkte forbundet med hinanden. Det ville blive uoverskueligt. I stedet bruger de hinanden som relæstationer for den interne post.

Så alle celler undersøger alle meddelelser, der kommer forbi. Hvis beskeden ikke er til dem selv, sender de den videre i den rigtige retning, ligesom en router i et almindeligt computernetværk. På den måde hopper beskeden videre fra celle til celle, indtil den havner hos den rette modtager. Sådan fungerer internettet også, og det gør et trådløst Zigbee-netværk også, men eDNA-computeren bruger dog en meget simplere dataprotokol til det lille netværk på chippen.

»Cellerne kender ikke hinandens fysiske position. De sender beskeder til en bestemt celle-identitet. Hvis en celle bliver dårlig og skiftes ud med en anden, følger identiteten med,« siger han.

På den måde kan computeren bliver ved med at reparere sig selv, indtil der ikke er flere reserveceller tilbage. Hvor mange celler, der skal være i den endelige chip, er for tidligt at sige. Men en af de kommende opgaver bliver at optimere algoritmerne, så de bliver effektive uden at bruge for mange ressourcer på fejlmeddelelser, ændrede rutetabeller og vækningsmeddelelser til reserverne i det lille lokalnetværk på chippen.

Ph.d.-projektet er delvist finansieret af højteknologifonden Danes.

Dokumentation

Artikel i DTU Avisen

Ikke for at være negativ, men sev-REPARERENDE??
Det er er "blot" redundans i mere ekstrem form.........

  • 0
  • 0

Ikke for at være negativ, men sev-REPARERENDE??
Det er er "blot" redundans i mere ekstrem form.........

Al reparation er redundans i en eller anden form. Det kommer an på ens perspektiv.
Hvis du slår dig, så er det også bare redundante celler der udskifter de ødelagte når det heler. Eller hvis cellerne heler er det redundante molekyler der udskifter de manglende.
Men udefra ligner det reparation.

Men denne teknik bringer da redundansen et helt niveau længere ned, hvis ikke mere. Og fra de nuværende redundante systemers perspektiv ligner det skam selv-reparation.

  • 0
  • 0

Hvis jeg nu laver en dårlig lodning på et power- eller clock ben på FPGA'en (eller den kommende ASIC). Så ryger alle N celler med et brag.

Risikoen kan selvfølgelig begrænses ved at bruge mange separate power og clock forbindelser - eller helst flere separate IC'er, men den løsning konvergerer tilbage imod de gammeldags hardware redundante systemer.

De fejl arkitekturen beskytter imod, er altså fejl som rammer en celle indeni chippen, men ikke alle de andre. Hvis den skal beskytte mod software fejl, skal reserve cellen, der overtager en opgave fra en dårlig celle, gøre noget andet end at indtage den samme konfiguration + kode. Ellers er robustheden begrænset til lokale hardwarefejl i chippen. Det er selvfølgelig også et fremskridt, f.eks. overfor heavy ioner.

Venligst,
Flemming Nyboe

  • 0
  • 0

Hvis du slår dig, så er det også bare redundante celler der udskifter de ødelagte når det heler.

Det er jo sådan set nye celler der via celledeling af "friske celler" erstatter de ødelagte. Derfor er det egentlig ikke redundans, idet vi ikke har et "reservoir" af "ubenyttede" celler liggende, men derimod danner nye ved cellereplikation.

  • 0
  • 0

Onboard computere er allerede redundante, da straaling jaevnligt aendrer et "0" til "1" et eller omvendt inde i computeren. Redundansen findes derfor allerede.
Godt at DTU kommer med noget nyt og kan faa det til Mars.Men altaa blot for at slaa fast at rediundans findes over alt i satelliter og rumfartoejer hvor man paa nogen maade kan designe det ind.
Danmark er vel nok generelt teknologisk lidt bag ud kan man vel godt tillade sig at sige, i forhold til eksempelvis, Sverige, Tyskland o.s.v. Men saa er det godt at man inden for specielle omraader af og til kan vise flaget.
For nogle aar siden var den store opfindelse "brintpillen" vist ogsaa en DTU opfindelse.

  • 0
  • 0

Erik Kristiansen: Korrekt - vi har desværre ikke opfundet små pico/nano robotter (endnu) til fysisk at reparere chippen.
Vi arbejder pt på en lidt mere avanceret form for selv-reparation pt. Hvor det er muligt at dynamisk frigøre frie celler ved at skalere størrelsen på det footprint din applikation har på cellerne op og ned. Det betyder at du efter min mening er MEGET tæt på analogien til biologiske celler - som jo deler sig for at skabe en ny celle til at overtage en død celles plads. Det vil du kunne gøre indtil du kun har en celle tilbage. Problemet er selvfølgelig at det ændrer din applikations performance, hvilket er noget vi skal kigge på.

Peter Hansen: You bet!

Flemming Nyboe: Gode observationer - som du måske ved - når man laver robust hardware handler det hele om at nedsætte risikoen for at systemet fejler. State-of-the-art er som du ved at bruge 3 kopier og en "voter" (TMR) til at bestemme hvem der har ret. Det bygger på antagelserne om at 2 kopier aldrig fejler på samme tid, at permanente fejl i kopierne ikke opstår, at voteren ikke fejler mv. Vi tror på at eDNA kan nedbringe denne risiko markant. I vores fejlmodel indgår iøvrigt "funktionelle" permanente fejl, som stuck-at, etc., og transiente fejl (som fx følge af stråling).

  • 0
  • 0

TMR går vel ud på at detektere fejl og handle derefter. Men jeg kan ikke se korrelationen mellem brugen af eDNA og hvordan risikoen for fejl mindskes - som du siger. Måske du kunne uddybe lidt her?

Desuden vil brugen af von Neuman arkitekturen (picoBlaze) i cellerne, selv kunne ende i en stuck-at situation eller give forkerte svar som følge af SEUs. Hvordan forhindres dette?

  • 0
  • 0

Jeg skal gøre forsøget :)

I TMR sammenligner du hele tiden resultatet af de samme 3 kopier. Vi har en TMR lignende mekanisme som også sammenligner resultatet fra 3 kopier (den omtalte "skyggeproces" i artiklen), men i det øjeblik en fejl detekteres flytter vi den fejlende kopi et andet sted hen - dette resulterer i at vi næste gang denne celle eksekveres sammenligner 3 nye "kopier" og derved ikke lider af samme issue som TMR.

Ang. PicoBlazen: Vi har ikke tænkt os at benytte PicoBlaze i den endelige version (det er måske ikke helt klart i artiklen) - vi har blot benyttet denne for at kunne fremstille en hurtig prototype til proof-of-concept. Ang. fejl i denne så benytter vi også ovenstående metode til at teste om PicoBlazen "regner forkert", som følge af fejl. Vi publicerer en artikel på IEEE Aerospace konferencen i Marts 2011 som (såfremt vi når deadline!) som går i en del flere detaljer omkring dette. Håber det var svar nok for nu...

  • 0
  • 0

Ok, tak. Det forklarer det en del bedre. Har lige læst jeres artikler, så det hjælper også lidt på det. Men ser frem til at læse mere om "skygge processerne" i 2011 artiklen. Syns generelt det er spændende tilgangsvinkel til robust/redundans spørgsmålet og en god formalisme med cellerne.

  • 0
  • 0

Tak for positiv kritik! Så har du nok også fundet min e-mail - du skal være velkommen til at kontakte mig hvis du måtte have flere spørgsmål!
De to artikler (fra AHS'09 og ARC'10 som jeg går udfra er dem du har fundet) går ikke synderligt meget i detaljer med dine spørgsmål omkring fejl-detektering - da de primært beskriver konceptet omkring eDNA. Men det vil 2011 artiklen gøre!

  • 0
  • 0

Jeg vil blot sige tak til Michael Boesen for at bruge lidt tid på at kommentere artiklen og kommentarerne.
Det løftede niveauet af både artiklen og den efterfølgende debat =)

Jeg håber I får god vind i solsejlene!

  • 0
  • 0

Det er ikke fordi jeg ikke synes, at det er et spændende forskningsprojekt; men jeg har lidt svært ved at se den praktiske anvendelse pt.

Hvilke fejl er det, som eDNA reparerer?

Bit flips i FPGA'ens konfigurations SRAM? Det er jo allerede løst ved at vælge ASICs istedet (jeg troede egentlig at man var ved at gå helt væk fra ASICs?).

Latchups kan forhindres ved SOI eller SOS, som flere og flere IC'ere mig bekendt bliver produceret ved.

Men hvilke fejl er det, som I regner med at blive udsat for?

Hvad med energiforbruget?

  • 0
  • 0

Michael:
Lige for at gøre det klart, hvis du havde misforstået det: eDNA er ikke rettet mod en FPGA løsning - da det vil svare til at implementere en FPGA type platform oven på en anden FPGA = pænt overhead.
Men dine spørgsmål gælder naturligvis ligeså vel når vi så får produceret en ASIC version:
eDNA vil kunne reparere alle typer "funktionelle" fejl, altså fejl som resulterer i et forkert output bliver produceret, eksempelvis stuck-at fejl, cross-talk fejl mv., alle denne type "funktionelle" fejl - både permanente og transient. Derunder naturligvis også Single-Event-Upsets (SEU) som selvfølgelig primært er relevant i rummet.
Energiforbruget er et meget relevant spørgsmål, men desværre kan vi ikke sige noget om det før vi kommer en del nærmere en ASIC prototype. Vores nuværende prototype indeholder en del "forsimplinger" såsom PicoBlazen som ikke vil være med i den endelige version - derfor vil det være meningsløst at bruge tid på at måle energiforbrug når vi har massere af andre ting at videreudvikle ;)
Håber det var svar nok...

  • 0
  • 0

eDNA vil kunne reparere alle typer "funktionelle" fejl, altså fejl som resulterer i et forkert output bliver produceret, eksempelvis stuck-at fejl, cross-talk fejl mv.,

Hvordan opstår den slags fejl?

  • 0
  • 0

Jamen de kan da fx opstå som resultat af dårlig produktion, stråling mv. Går ud fra du også kender til problemet med transistor skalering? Ifølge ITRS bliver problemet ikke mindre de kommende år hvis trenden fortsætter.

Tror muligvis lidt du misforstår ideen bag - i øjeblikket har du fuldstændig ret i at der findes forskellige måder at håndtere hardware fejl på idag. Vi fokuserer primært på fejl at runtime - ligesom eksempelvis Triple Modular Redundancy (TMR) gør. TMR er den mest brugte metode til at håndtere runtime-fejl på - men den har svagheder som vi med vores eDNA arkitektur kan forbedre. I TMR sammenligner du ALTID med resultatet fra de samme 3 enheder - hvis en af enhederne fejler (fx som følge af stråling, permanent fejl osv) så har du ikke mulighed for at bestemme hvem der har ret. Det har du med eDNA fordi i det øjeblik en fejl opstår - vil du bare udskifte den enhed der er fejlet med en ny og sammenligner således med 3 nye enheder (som jeg også har skrevet tidligere).

Jeg er ikke helt sikker på hvor du vil hen med dit spørgsmål - så jeg har nok ikke svaret ordentligt på det. Beklager... Du skal være velkommen til at uddybe!

  • 0
  • 0

I praksis sker det ved, at hver af de fungerende computerceller også udfører en sekundær skyggeproces i baggrunden, som er en kopi af en anden celles primære opgave. Hvis de to parallelle processer pludselig får forskellige resultater, er der noget galt. Og en særlig algoritme bestemmer så, om en af dem skal tages ud af drift og erstattes med en af reserverne.

Ovenstående med skyggeprocessen, er ikke helt nyt. Normalt, lader man skyggeprocessen, og hovedprocessen, være tidsmæssigt forskudt i forhold til hinanden. Man kan - i nogle tilfælde - anvende samme processor, og udføre hoved, og skyggeprocessen på skift. Imidlertid, får man derved jo ikke redundant hardware, men i nogle tilfælde, kan det godt bruges til, at tjekke et resultats korrekthed - man sørger gerne for, at de to processer ikke er identiske, f.eks. kan den ene arbejde negeret. Tidsforskydningen gør, at en eventuel "burst" af støj, partikler, osv. påvirker de to processer på forskellig tidspunkt, og at fejlen derfor ikke sætter ind samtidigt - det har flere fordele, og kan gøre fejlene nemmere at opdage, og at rette.

Selvom nogle af teknikkerne således ikke er helt nye, og at man også tidligere har haft computere som man "satte ud", når de ikke fungerede, og skiftede til andre - så vil jeg dog ikke sige at projektet helt er gammel viden. Så vidt jeg har forstået, er man gået skridtet videre, til at anvende princippet fra FPGA'ernes reprogrammerbarhed, til at opnå celler der endnu ikke er programmeret, og først programmeres, når det bliver nødvendigt...

Skal vi nu kritisere systemet, så ligger en kritik blandt andet på, at vi ikke kan være sikker på, at vores reserveceller, ikke er henfaldet når der er brug for dem... Derfor, bør man faktisk have tjek til at køre uafbrudt, så man hele tiden ved, om stadset fungerer. Og, så man kan advare i god tid, når en vis procentdel af kredsen er ødelagt. En meget vigtig ting, er derfor at hele tiden tjekke cellerne igennem, også selvom de ikke bruges.

Jeg har ikke læst projektet, men jeg er sikker på, at der nok skal være noget interessant i det. Men, nogle af principperne, er altså normalt kendte. Og det vil de jo nok altid være, selvom der også er nyt i det.

Fejl er ikke altid hardwarefejl, hvor hardwaren ødelægges. Så det er overdimmensioneret, at altid koble en deffekt enhed ud. Måske regner den korrekt umiddelbart bagefter. Så i nogle tilfælde, vil man koble enheden ud - og i andre, vil man genbruge samme enhed igen, men reinitialisere, eller eventuelt reprogrammere den.

I TMR sammenligner du ALTID med resultatet fra de samme 3 enheder - hvis en af enhederne fejler (fx som følge af stråling, permanent fejl osv) så har du ikke mulighed for at bestemme hvem der har ret

Det er vigtigt, at netop ikke tjekke på samme tidspunkt, for så vil alle jo ofte fejle. Derfor køres processerne oftest forskudt. En meget simpel metode, som bruges industrielt, hvor det kun er "bløde" fejl der rettes, bruger samme hardware, og kører forskudt. Det sker ved at processoren udstyres med flere registersæt, og så kører programmet som en skjult multitasking, og skifter for hver I/O. Så snart der laves en I/O vil den laves flere gange, og resultaterne sammenlignes. På den måde, opnås en langsommere hastighed, men så stor tidsforskydning som muligt. En fejl, vil ikke ramme de samme sted i de parallele ens processer.

Ofte, vil man også gøre processerne forskellige. Det kan ske ved at f.eks. arbejde "negeret" i halvdelen af processerne. Man kan også compilere koden forskelligt, så der sikres opgaverne løses på forskellig måde.

Der findes et uhav af metoder, til at lave fejlkorrigerende elektronik. Nogle, kan implementeres i traditionelle processorer, ved at anvende en "kerne" bestående af en fortolker, så man kan skrive koden i normal fortolket sprog. Da sproget fortolkes, så kan man sikre at der er en hoved-loop, der er garanteret koden kører i. Og man kan have redundante bits overalt, både i den del af rammen der bruges, og for indstruktionspointeren, i det fortolkede program. Ulempen er at det er lidt sløvere - men hastighed betyder ikke altid alt. I mange tilflæde, er nødvendigt at have flere redundante hardwareenheder, således at total destruktion af nogle af enhederne ikke medfører fejl.

Det - som man oftest gør - er at lade alle køre samtidigt, og altså have et redundant system. Fordelen er, at man så ved de faktisk virker. Hvis vi har et system, bestående af passive uspecialiserede computere, der ikke laver et hak, så risikerer vi, at de er deffekte og måske langsomt er blevet ødelagt, af strålingen fra rummet, eller af andre forhold. Så derfor, går det ikke, at lade dem intet lave. De skal - som minimum - køre noget test software, så man ved de ikke virker, når der opstår hardware fejl på en uspecialiseret enhed.

  • 0
  • 0

Hej Jens!

Tak for en meget uddybbende kommentar! Du har ret vores skyggeprocesser er der ikke det helt store nye i - da vi helt bevidst forsøger at imitere TMR på fejl-detektionssiden. Det nye mht. fejl-detektionsvinklen består i at tilpasse TMR'en til vores dynamisk reconfigurerbare arkitektur.

Ang. henfaldne reserveceller: Helt korrekt observation! Der er en del ubesvarede spørgsmål endnu for vores arkitektur - hvad man gør med fejlende reserveceller er et af dem! I den nuværende prototype antager vi at hvis systemet flytter funktionalitet til en "død" celle, vil den blive "opdaget" næste gang den eksekveres af de andre virkende celler. MEN du har ret i at hvis vi flytter funktionalitet til en død celle kan jeg ikke sige at TMR'en opretholdes. Så det er en antagelse vi skal af med.

Ang. nyhedsværdi: Hmm.. altså indtil videre er vi sluppet videre i PCT-fasen - så mener nu stadig eDNA rummer en del nyhedsværdi - til trods for de punkter du har udpeget. Jeg vil mene at vores primære nyhedsværdi ikke ligger i fejldetektionen, som du primært kommenterer på, men snarere hele konceptet - altså hvordan man kommer fra noget funktionalitet beskrevet i et specialiseret programmeringssprog, direkte til en specialiseret mapning på en multicore arktektur til en endelig dynamisk reconfigurering og genskabning af funktionalitet i tilfælde af fejl.

Igen tak for en super relevant og uddybbende kommentar!

  • 0
  • 0

Ang. nyhedsværdi: Hmm.. altså indtil videre er vi sluppet videre i PCT-fasen - så mener nu stadig eDNA rummer en del nyhedsværdi - til trods for de punkter du har udpeget. Jeg vil mene at vores primære nyhedsværdi ikke ligger i fejldetektionen, som du primært kommenterer på, men snarere hele konceptet - altså hvordan man kommer fra noget funktionalitet beskrevet i et specialiseret programmeringssprog, direkte til en specialiseret mapning på en multicore arktektur til en endelig dynamisk reconfigurering og genskabning af funktionalitet i tilfælde af fejl.

Her er jeg helt enig.

Men, jeg tror at fremtidens compuere til rumbrug - i bedste Hollywood stil - vil rumme et display, der orienterer om, hvor mange brugbare celler der er left. Man vil så se, at det er næsten fuld ved opsendelsen, og det drastisk falder ved passagen af van allen bæltet, og besætningen er nervøse for, om den overlever, eller antallet af celler når ned på nul - hvilket naturligvis medfører at computeren udfalder, man må forsøge på farefuldt vis, at rede situationen manuelt. Uden computeren rapporterer, hvor mange procent der er tilbage, er det svært at kende computerens tilstand.

  • 0
  • 0

Hehe nice iscenesætning.

Vi arbejder pt på en løsning hvor man kan skalere størrelsen af opgaverne en celle udfører op og ned dynamisk - dette vil medføre at hvis du løber tør for celler kan du skalere størrelsen på opgaven op, således at hver celle udfører mere arbejde. Dette vil betyde at hvis dit program fyldte N celler, får du nu N/2 nye reserveceller. Dette vil du så kunne gøre indtil du har 3 tilbage, hvor du så vil være tilbage på et "standard" ikke-reparerbart TMR system.
Der er selvfølgelig nogle bivirkninger ved dette såsom at ved at lave den skalering får du en ændret eksekveringstid for dit program.

Den eneste grund til at det er muligt at gøre dynamisk at runtime er netop den måde vi formulerer vores DNA og cellerne fortolker den. Der er derfor det er primært det der er nyhedsværdien...

  • 0
  • 0