Fedt at høre fra dig Steen. Kom endelig med mere hen ad vejen!

Jeg melder mig i heppekoret, omend at her får vi da kam til håret! Denne blog skal jeg i hvert fald lige have genlæst et par gange. Men den er yderst velkommen.

Mere af det her tak. Det er super fedt at få information om hvordan jeres systemer virker direkte fra den afdeling som laver det, ligesom når vi får teknisk info fra jeres motorafdeling igennem Peter Madsen.

Hej Steen.

Hvilke test metoder har du anvendt under udviklingen?

Har du et system der kan simulere at raketten flyver?

Mvh Ulrik Nyman

Mange tak for de pæne ord. Det er bestemt også på sin plads at rette en tak til jer, der viser projektet interesse og ikke mindst CSS og andre der bidrager. Det er fantastisk med al interessen og supporten, der vises projektet udefra.

Ang. testmetoder så har jeg indtil nu nået at spoole data ind i programmet fra AAU’en. Dette er foretaget med rigtige data således at forstå, at data kommer fra GPS og AAU’ens IMU. Dertil kommer test, hvor jeg bevidst bomber FIDO programmet med en blanding af rigtige data, og data der var smadret mht. pakkelængde, indholdet af data, cheksummer der var forkerte osv. AAU’en har kørt i dagevis for at afvikle dette.

Dertil kommer almindelige udviklingstest, hvor man lige tjekker fx at afstande osv. bliver beregnet rigtigt på kortet. Det betragter jeg som en del af almindeligt udviklingsarbejde.

Hvad burde man ellers gøre? Jo, en god unittest ville bestemt på udvalgte dele være at foretrække, men meget af det er jo GUI komponenter, som ikke rigtig lader sig teste med unittest.

Yderligere har Daniel Leong fra UK har lavet et meget grundigt review af den tidligere version, og han har lige sagt, at han gerne vil lave et til, så der bliver også set på softwaren med meget kyndige øjne.

For mit vedkommende bliver det næste skridt at lave integrationstest med de andre i gruppen, samt en systemtest hvor vi sejler en tur ud i Kbh. havn og tester det hele samlet systemerne.

Virke skal det fandeme!

Styrer FIDO også affyringssekvensen? Der er en lang række test, der skal foretages lige inden og under affyring som f.eks. radiokommunikation, tilstand af alle ventiler og motorer, diverse tryk og temperaturer etc. Det er en temmelig lang og dynamisk checkliste, og parametrene kan ændre sig alt for hurtigt til, at mennesker kan nå at tage de rigtige beslutninger, så en vis form for affyringsautomation kunne være på sin plads.

Hvad har I gjort for at beskytte jer mod Single Event Upsets uden for atmosfæren dvs. ladede partikler, der ændrer tilstanden af transistorerne (prøv bare at se hvilke problemer SpaceX har på dette område, da de ikke har villet ofre strålingshærdede computere)? Det er specielt et problem for guidance systemet og ikke mindst for abortsystemet, som man må forvente skal kunne leve op til internationalt anerkendte sikkerhedsstandarder som f.eks. IEC 61508, for at I i det hele taget vil få lov til at skyde så tæt på Bornholm og Sydsverige og evt. kan tegne en ansvarsforsikring.

Styrer FIDO også affyringssekvensen? Der er en lang række test, der skal foretages lige inden og under affyring som f.eks. radiokommunikation, tilstand af alle ventiler og motorer, diverse tryk og temperaturer etc. Det er en temmelig lang og dynamisk checkliste, og parametrene kan ændre sig alt for hurtigt til, at mennesker kan nå at tage de rigtige beslutninger, så en vis form for affyringsautomation kunne være på sin plads. Hvad har I gjort for at beskytte jer mod Single Event Upsets uden for atmosfæren dvs. ladede partikler, der ændrer tilstanden af transistorerne (prøv bare at se hvilke problemer SpaceX har på dette område, da de ikke har villet ofre strålingshærdede computere)? Det er specielt et problem for guidance systemet og ikke mindst for abortsystemet, som man må forvente skal kunne leve op til internationalt anerkendte sikkerhedsstandarder som f.eks. IEC 61508, for at I i det hele taget vil få lov til at skyde så tæt på Bornholm og Sydsverige og evt. kan tegne en ansvarsforsikring.

SpaceX flyver - [b]væsenligt[/b] - højere oppe end CS.
Det inderste Van Allen bælte er normalt i området mellem L1 og L3 - der står noget med ned til 200 km ved SAA sammen med stærk solaktivitet her: http://en.wikipedia.org/wiki/Van_Allen_rad...

Vurderes ioniserende stråling fra solen til at være et problem ved en suborbital flyvning, så kan man i bedste simple Copenhagen Suborbitals stil bare løse det med noget bly indkapsling - tungt ja? Ikke et problem, vi gør bare LOX og Ethanol 75% tankene en lile smule længere.

Hej Carsten,
Nej, FIDO Monitoren styrer ikke noget. Det er alene en monitor, og som sådan er der ikke indbygget funktionalitet til at afvikle en affyringssekvens. Det betyder dog ikke, at du ikke har en pointe ang. startsignalet og den monitorering der på sigt skal foretages. P.t. er det dog ikke aktuelt, men jeg gætter på, at fremtiden vil indebære at der indføres noget automatik. Her vil man dog nok vælge at afprøve det til flere statiske test inden det bliver implementeret til en affyring pga. sikkerhed.

Single Event Upsets:
Vedr. AAU'en: Ud over, at elektronikken er placeret i en solid alu-boks, har jeg ikke gjort noget specifikt i forhold til EMC i forbindelse med denne Sapphi opsendelse. Vi kommer ikke ud af atmosfæren i dette tilfælde.

Vi har dog været heldige at få en dygtig test-ingeniør om bord, som vil lave rystetest af boksen, og som på sigt også kan foretage grundige EMC test. Dette bliver naturligvis relevant i fremtiden.

Mvh Steen

Single Event Upsets: Vedr. AAU'en: Ud over, at elektronikken er placeret i en solid alu-boks, har jeg ikke gjort noget specifikt i forhold til EMC i forbindelse med denne Sapphi opsendelse. Vi kommer ikke ud af atmosfæren i dette tilfælde. Vi har dog været heldige at få en dygtig test-ingeniør om bord, som vil lave rystetest af boksen, og som på sigt også kan foretage grundige EMC test. Dette bliver naturligvis relevant i fremtiden.

EMC og SEU er to vidt forskellige mekanismer. EMC er nemt at få styr på, for i 100 km højde er det ikke mange støjkilder bortset fra jeres egne. Det bliver ikke noget problem - specielt da ikke inden i en metalraket. SEU kan imidlertid pludselig få et program til at gå ned eller endnu værre - sætte den indbyggede thyristor i et CMOS trin i latch-up, så kredsen brænder af.

Microsemi (tidligere Actel) har en interessant oversigt over SEU, som de selvfølgelig har lavet, fordi deres kredse i modsætning til konkurrenternes ikke ændrer konfiguration som følge af SEU :-) se http://www.actel.com/documents/Neutron_SEU...

Vurderes ioniserende stråling fra solen til at være et problem ved en suborbital flyvning, så kan man i bedste simple Copenhagen Suborbitals stil bare løse det med noget bly indkapsling - tungt ja? Ikke et problem, vi gør bare LOX og Ethanol 75% tankene en lile smule længere.

Jeg tror ikke, at det er så nemt, for så havde SpaceX gjort det for længst, og NASA, ESA og alle de andre havde ikke ofret ekstremt dyre strålingshærdede komponenter. Et rimeligt bud på en CS løsning kunne være at benytte Microsemi's RTAX familie, som tilbyder SEU-hærdede flip-flops; men så kan systemerne selvfølgelig ikke skrives i JAVA.

PS. Microsemi tilbyder nu også strålingstolerante ProAsic 3 typer, som kan reprogrammeres: http://www.actel.com/products/milaero/rtpa...

Hej Carsten,

Tak for linket.

Lige for at præcisere: Det er kun FIDO programmet i MC, der er implementeret i Java. GNC og AAU'en er implementeret i C/C++.

Der kommer aldrig til at køre Java på en On Board computer af gode grunde.

Mvh
Steen

PS. Microsemi tilbyder nu også strålingstolerante ProAsic 3 typer, som kan reprogrammeres: http://www.actel.com/products/milaero/rtpa...

Jeg ved ikke om du er klar over prisen paa saadan en FPGA ? men saa vidt jeg er informeret, starter de omkring 40k €.

Det er selvfölgeligt et problem med SEU, men suborbital er stadig 'tät' paa jorden, og skal kun fungere i 10-15 minutter. Saa länge der ikke skydes lige midt i SAA, vil jeg mene der er bedre maader at löse "problemet" paa.

Astrium har lavet et meget interessant paper omkring ATMEGA128 og SEU/SEL, som er anbefalelses värdig at läse (sög paa Astrium og Atmega128)

Der er masser af gode lösninger (og billige) som kan implementeres efter behov (watchdog, redundant uC, redundant uC som laver abort hvis main ikke kan beregne en simpel udregning etc..)

Jeg ved ikke om du er klar over prisen paa saadan en FPGA ? men saa vidt jeg er informeret, starter de omkring 40k €.

Måske, og hvis de virkelig er så dyre, er den løsning selvfølgelig udelukket; men prøv lige at læse, hvad Microsemi skriver:

RT ProASIC3 FPGAs use the same silicon design and the same 0.13 µm process at UMC as their commercial equivalent ProASIC3EL parts. The ProASIC3 devices have been extensively tested for a variety of radiation effects.

Når der er tale om nøjagtig samme kreds og samme proces, mon så ikke standardkredsene også har så gode egenskaber, at de er brugbare?

Det er selvfölgeligt et problem med SEU, men suborbital er stadig 'tät' paa jorden, og skal kun fungere i 10-15 minutter. Saa länge der ikke skydes lige midt i SAA, vil jeg mene der er bedre maader at löse "problemet" paa. Astrium har lavet et meget interessant paper omkring ATMEGA128 og SEU/SEL, som er anbefalelses värdig at läse (sög paa Astrium og Atmega128) Der er masser af gode lösninger (og billige) som kan implementeres efter behov (watchdog, redundant uC, redundant uC som laver abort hvis main ikke kan beregne en simpel udregning etc..)

Jeg siger da heller ikke, at Microsemi løsningen er den eneste brugbare. Det vigtige er bare, at CS tager stilling til problemet - om løsningen så bare bliver den simple: "Det sker ikke for os" :-)

http://microelectronics.esa.int/conference...

Måske, og hvis de virkelig er så dyre, er den løsning selvfølgelig udelukket; men prøv lige at læse, hvad Microsemi skriver: [quote]RT ProASIC3 FPGAs use the same silicon design and the same 0.13 µm process at UMC as their commercial equivalent ProASIC3EL parts. The ProASIC3 devices have been extensively tested for a variety of radiation effects.

[/quote]

Det er bestemt ogsaa en mulighed. Jeg sidder selv og tamper VHDL til en ProASIC3 af nöjagtig samme grund. Min applikation er dog lidt anderledes (operationel tidslinie mere en 1 aar), og väsentligt höjere i atmosfären ( over 600km).

Når der er tale om nøjagtig samme kreds og samme proces, mon så ikke standardkredsene også har så gode egenskaber, at de er brugbare?

Det kommer helt an paa hvem der skal overbevises. RTProASIC er ikke radhard. Der er stadig SEU effekter at spore (der er et par rapporter paa Actel's hjemmeside).

Jeg siger da heller ikke, at Microsemi løsningen er den eneste brugbare. Det vigtige er bare, at CS tager stilling til problemet - om løsningen så bare bliver den simple: "Det sker ikke for os" :-)

Til SEU problemer og alle andre der kan ske ombord. Det handler om at sätte ind hvor problemerne er störst. Uden närmere kendskab til CS's HW, vil jeg tro at det er langt mere sandsynligt at andet kan fejle i elektronikken end en SEU

http://microelectronics.esa.int/conference...

Der findes ogsaa en 'rigtig' artikel, men kan kun finde den paa IEEE, hvor der ikke er fri adgang.

http://www.google.de/url?sa=t&rct=j&q=&esr...

Jeg kan desuden anbefale at se paa hvordan CERN (eller ihvertfald en gruppe dernede) omgaas problemet med SEU/SEL og generel radiation damage. De fokuserer ogsaa paa en ATMega128
http://atlas.web.cern.ch/Atlas/GROUPS/DAQT...

Til SEU problemer og alle andre der kan ske ombord. Det handler om at sätte ind hvor problemerne er störst. Uden närmere kendskab til CS's HW, vil jeg tro at det er langt mere sandsynligt at andet kan fejle i elektronikken end en SEU

Det er jeg da helt enig med dig i; men var der ikke noget med en Ariane 5, hvor et integer overflow skabte et reset, som fik raketten til at tro, at retningen var en anden end den faktiske, så den blev sendt ud af kurs og endte i selvdestruktion? Om man så ikke agter at gøre noget ved SEU problemet, skader det jo f.eks. ikke at overveje, hvad der sker, hvis guidance systemet pludselig resettes (CS har jo valgt at benytte en computer til regulering i stedet for simpel analogteknik, der er temmelig ligeglad med SEU og SEL).

Jeg sidder selv og tamper VHDL til en ProASIC3 af nöjagtig samme grund.

Jeg arbejder faktisk også med ProAsic3 til daglig; men dog ikke med VHDL, da det for det første ikke giver mig det nødvendige overblik (grafik bedre end kode) og for det andet ikke kan garantere en høj pålidelighed til asynkrone netværk, hvor man ikke clocker fra et globalt clocknetværk.

Hej Steen,

Tak for spændende blogindlæg! Tænkte på om du evt. kunner fortælle lidt om den hardware i bruger - MCUs, IMU sensorer, hvilke interfaces etc.? Muligvis findes det allerede på jeres hjemmeside under "Resource" og jeg har bare misset det!?

@Steen og Peter:
Én af de ting som er rigtig fedt ved jeres projekt, er at følge med på denne blog og se projektet fra flere personers forskellige perspektiver. Jeg har en del internationale studiekollegaer som også følger aktivt med i jeres projekt, men føler nogle gange at de går glip af denne del af CS. Har i overvejet evt. at oversætte nogle af jeres blogindlæg til engelsk (jeg ved ikke hvordan ing.dk's politik er omkring disse blogs)? - skulle være muligt at finde et par frivillige til en oversætter tjans!

Jeg var imponeret over, hvor koldblodigt Von B afgav kontrolinstrukserne ved den skydning, hvor payloaden knækkede af, men der er vel også grænser for, hvad han kan kapere.

Kunne man forestille sig, at de data, som ikke er relevante, mens raketten flyver opad blankes, så der kun vises relevante data? Så f.eks. ETA, længde/bredde, SDkort ok ikke vises, når den flyver opad.

Tillægsspørgsmål: Taster I manuelt vindhastighed og retning ind i forskellige højder inden start?

Kunne man forestille sig, at de data, som ikke er relevante, mens raketten flyver opad blankes, så der kun vises relevante data? Så f.eks. ETA, længde/bredde, SDkort ok ikke vises, når den flyver opad.

Enig. Jeg ville også stryge langt de fleste numeriske data (kun logge dem) og kun vise de aller vigtigste så som hastighed, højde og alarmer direkte på søkortet ud for den grønne prik, så blikket ikke skal vandre frem og tilbage; men når det er sagt, skal CS have ros for en meget flot grafik.

Kunne man forestille sig, at de data, som ikke er relevante, mens raketten flyver opad blankes, så der kun vises relevante data? Så f.eks. ETA, længde/bredde, SDkort ok ikke vises, når den flyver opad. Tillægsspørgsmål: Taster I manuelt vindhastighed og retning ind i forskellige højder inden start?

1) Det kunne man sagtens, og det kan godt være, at vi ender med at stryge nogle. Når man sidder vi skrivebordet, så kribler det jo for at vise så meget som muligt,men det skal man ikke lade sig narre af. Jeg vil foretage en evaluering med de andre og så må vi se om vi fjerner noget - enten helt eller som du skriver efter T0.

Når vi ser lidt længere frem, så tror jeg dog, at vi vil udbygge systemet med flere computere. Dermed kan de forskellige roller få hver deres skærmbillede, som i alt måske andrager 3, hvor der kun vises netop hvad de skal holde øje med.

Ang. vinden: P.t. er det ikke medtaget i denne version, men det er bestemt en funktionalitet vi overvejer. Og vi har den på "lager", så det er bare at smide den ind.

Hej Steen, Tak for spændende blogindlæg! Tænkte på om du evt. kunner fortælle lidt om den hardware i bruger - MCUs, IMU sensorer, hvilke interfaces etc.? Muligvis findes det allerede på jeres hjemmeside under "Resource" og jeg har bare misset det!? @Steen og Peter: Én af de ting som er rigtig fedt ved jeres projekt, er at følge med på denne blog og se projektet fra flere personers forskellige perspektiver. Jeg har en del internationale studiekollegaer som også følger aktivt med i jeres projekt, men føler nogle gange at de går glip af denne del af CS. Har i overvejet evt. at oversætte nogle af jeres blogindlæg til engelsk (jeg ved ikke hvordan ing.dk's politik er omkring disse blogs)? - skulle være muligt at finde et par frivillige til en oversætter tjans!

Hvis jeg får tid skriver jeg gerne om HW i forbindelse med AAU'en, men det kniber lige lidt for indeværende. Der er ikke specifikt noget på hjemmesiden om det, så du har ikke misset noget. Men vi bør jo have noget dokumentation, så jeg regner bestemt med at der kommer noget.

Ang. engelsk så er den umiddelbart oplagte mulighed at følge KvB på hans blog, som er på engelsk: http://www.wired.com/wiredscience/rocketshop

Men det er da ikke noget dumt forslag at oversætte til engelsk, da publikumspotentialet alt andet lige er noget større :-)

Når vi ser lidt længere frem, så tror jeg dog, at vi vil udbygge systemet med flere computere. Dermed kan de forskellige roller få hver deres skærmbillede, som i alt måske andrager 3, hvor der kun vises netop hvad de skal holde øje med.

Java er mig bekendt ikke noget realtidsoperativsystem, og jeg ville være betænkelig ved at dele f.eks. overvågning/monitering og styring af affyringssekvens ud på mange computere, som så skal synkroniseres.

I stedet ville jeg opbygge systemerne som 2 eller 3 redundante systemer, som kører det samme program på baggrund af de samme inputdata, og derfor kan vise alle skærmbilleder. Virker alt, kan I bare lade hver computer vise hver sit skærmbillede; men ved fejl kan enhver computer uden forsinkelse eller tab af data overtage og styre vha. en fælles multimasterbus koblet til telemetrisystemet.

Eller måske en opgave (oversættelse) der kunne uddelegeres til CSS?

[quote]Vurderes ioniserende stråling fra solen til at være et problem ved en suborbital flyvning, så kan man i bedste simple Copenhagen Suborbitals stil bare løse det med noget bly indkapsling - tungt ja? Ikke et problem, vi gør bare LOX og Ethanol 75% tankene en lile smule længere.

Jeg tror ikke, at det er så nemt, for så havde SpaceX gjort det for længst, og NASA, ESA og alle de andre havde ikke ofret ekstremt dyre strålingshærdede komponenter. Et rimeligt bud på en CS løsning kunne være at benytte Microsemi's RTAX familie, som tilbyder SEU-hærdede flip-flops; men så kan systemerne selvfølgelig ikke skrives i JAVA.

[/quote]

Jeg tror - modsat dig - faktisk at det er så nemt.
Hvis du tænker nærmere over det så gør SpaceX omtrent det samme som alle de andre pro-guys i branchen: De vægt optimerer - og jeg er sikker på at alle pro-guys indenfor rumfart går fuldstændig i chock og derefter baglås hvis der er nogen der nævner bly indkapsling.

Jeg er helt sikker på at der for dem er en psykologisk barriere, idet at bly for dem er et stof der bare er alt for tungt, og indkapsling betyder meget af det.

CS derimod er nødsaget til at tænker anderledes.
For mig lyder Peter Madsens: "Vi hælder bare mere billigt LOX og billigt brændstof ind i løsningen at sådan et vægt problem" lyder helt rigtigt når raketten er meget billig at producere.

[quote]Når vi ser lidt længere frem, så tror jeg dog, at vi vil udbygge systemet med flere computere. Dermed kan de forskellige roller få hver deres skærmbillede, som i alt måske andrager 3, hvor der kun vises netop hvad de skal holde øje med.

Java er mig bekendt ikke noget realtidsoperativsystem, og jeg ville være betænkelig ved at dele f.eks. overvågning/monitering og styring af affyringssekvens ud på mange computere, som så skal synkroniseres.

I stedet ville jeg opbygge systemerne som 2 eller 3 redundante systemer, som kører det samme program på baggrund af de samme inputdata, og derfor kan vise alle skærmbilleder. Virker alt, kan I bare lade hver computer vise hver sit skærmbillede; men ved fejl kan enhver computer uden forsinkelse eller tab af data overtage og styre vha. en fælles multimasterbus koblet til telemetrisystemet.
[/quote]

Om Java:
Der er vel ikke nogen der er ved sine fulde fem der ville sætte en JRE (Java Runtime Enviroment) til at styre noget som helst inde i en raket?

Det hedder MISRA C, eller SPARK / Ada som programmeringssprog i sådan et embedded system hvor der er menneskeliv på spil + god redudant hardware.

Jeg har selv brugt MISCRA C udgaven af C programmeringssproget succesfuldt i et medico-teknisk apparat.

Links:

Wikipedia om MISRA C:
http://en.wikipedia.org/wiki/MISRA_C

Introduktion til MISRA C:
http://www.embedded.com/electronics-blogs/...

MISRAs web site:
http://www.misra.org.uk/

Wikipedia om SPARK programmeringssproget:
http://en.wikipedia.org/wiki/SPARK_%28prog...

[b]Laver man GPL licenseret software kan man få lov til at hente og bruge udviklingsmiljøet (Gnat Programming System - GPS), Ada compilere, og SPARK værktøjer ganske gratis her : [/b]
http://libre.adacore.com/

Jeg er helt sikker på at der for dem er en psykologisk barriere, idet at bly for dem er et stof der bare er alt for tungt, og indkapsling betyder meget af det.

Det er jeg enig i. Det er ikke 100 kg vi taler om. Hvis min hurtige hovedregning er korrekt vil en blyterning på 20x20x20 cm med en godstykkelse på 2 mm veje ca. 5,5 kg. Og 2 mm må være alt rigeligt.

Og der skal alligevel placeres balast jvf. LES' spektakulære loop.

Og 2 mm (bly) må være alt rigeligt.

Det er jeg nu ikke så sikker på, for som I kan læse i min link fra Actel, er selv 1,5 m beton (5 fod) ikke nok til at stoppe neutronstrålingen.

[quote]Og 2 mm (bly) må være alt rigeligt.

Det er jeg nu ikke så sikker på, for som I kan læse i min link fra Actel, er selv 1,5 m beton (5 fod) ikke nok til at stoppe neutronstrålingen.
[/quote]

• og der står i din PDF: ISS og LEO.

I Van Allen bælter er der beta henfald (kilde: mit tidligere wikipedia link om Van Allen bælterne)

Vigtigst:
CS kommer ikke derop hvor det er farligt + turen tager ikke så lang tid, så det er pt et ikke-problem.

Om Java: Der er vel ikke nogen der er ved sine fulde fem der ville sætte en JRE (Java Runtime Enviroment) til at styre noget som helst inde i en raket?

Nej, det er der selvfølgelig ikke.

Derfor skrev jeg også i et tidligere indlæg

"Der kommer aldrig til at køre Java på en On Board computer af gode grunde. "

Mvh.
Steen

[quote][quote]Og 2 mm (bly) må være alt rigeligt.

Det er jeg nu ikke så sikker på, for som I kan læse i min link fra Actel, er selv 1,5 m beton (5 fod) ikke nok til at stoppe neutronstrålingen.
[/quote]

• og der står i din PDF: ISS og LEO.

I Van Allen bælter er der beta henfald (kilde: mit tidligere wikipedia link om Van Allen bælterne)[/quote]

Beta straaling skulle kunne tages selv med et par mm AL. Dog har en ikke uväsentlig del af standard komponenter (RAM osv) problemer naar de komme igennem SAA. Naar man kommer höjere op hjälkper det ikke at smide mere end 2-4mm alu omkring, da de ioniserede partikler har saa meget energi at de kommer igennem alligvel.

se evt:
http://www.mssl.ucl.ac.uk/~gbr/kirill/imag...

Faktisk kan for meget skjold det väre med til at forvärre situationen (sekundär straaling). Her snakker vi dog om ting i orbit, og ikke om en sub-orbital raket.

Vigtigst: CS kommer ikke derop hvor det er farligt + turen tager ikke så lang tid, så det er pt et ikke-problem.

Her er jeg fuldständig enig.

[quote][quote]Og 2 mm (bly) må være alt rigeligt.

Det er jeg nu ikke så sikker på, for som I kan læse i min link fra Actel, er selv 1,5 m beton (5 fod) ikke nok til at stoppe neutronstrålingen.
[/quote]

• og der står i din PDF: ISS og LEO.
  [/quote]

Hvor? FAQ artiklen beskæftiger sig desværre ikke med SEU og SEL til større højder end ca. 10 km (luftfart), hvor problemet er ca. 600 gange større end ved jorden. Det ville have været rart af få en multiplier i 100 km højde.

PS. I suborbitale højder tror jeg ikke, at ioniserende stråling er det helt store problem, til gengæld dannes neutronstråling ved overgangen til atmosfæren, og det er tilsyneladende det, Actels FAQ artikkel omhandler.

Det er rigtigt, at sandsynligheden for at blive ramt en en SEU er overordentlig ringe; men min pointe er, at hvis abortsystemerne skal leve op til gældende sikkerhedsstandarder, kræves også en ekstrem lav fejlsandsynlighed, os så kan sandsynligheden for SEU og SEL få betydning. Jeg er meget i tvivl om, hvordan man skal fortolke IEC 61508 ved kortvarige rumflyvninger; men ved kontinuert drift skal sandsynligheden for en farlig udetekteret fejl under 1 pr. 5000 år for SIL 3, og det vil inkludere risikoen for SEU.

Hvilken betydning har det for overholdelse af sikkerhedsstandarder at AAUen er redundant - nå vi flyver har vi jo ud over den også et radio uplink som kan stoppe festen. Antag det er et ret fornuftigt designet system med fornuftige antenneafstande under hele turen m.m.

Det jeg mener er at hvis en elevatorstol kommer med slyngbremser, faldskærm, retroraket og fjerder gulv - så er kravne til hver af de forskellige sikkerhedssysstemer måske mindre.

( bare et tænkt eksempel )

Peter Madsen

Det jeg mener er at hvis en elevatorstol kommer med slyngbremser, faldskærm, retroraket og fjerder gulv - så er kravne til hver af de forskellige sikkerhedssysstemer måske mindre.

Du har fuldstændig ret. Det er den totale sikkerhed, der er afgørende, så jo flere systemer du har, jo mindre sikkerhed behøver de enkelte systemer at have.

Jeg vil understrege, at jeg aldrig har beskæftiget mig med "failure on demand" delen af IEC 61508, så det efterfølgende kan meget vel være forkert; men med min nuværende viden ser regnestykket således ud:

1) Det første, man må gøre, er at fastsætte worst-case risikoen. Nu er en tonstung væskeraket, der kommer drønene med overlydshastighed jo ikke ligefrem til at spøge med, så som absolut minimum kan vi antage, at der er risiko for død af 1-3 personer og/eller skadesudgifter på 1-10 millioner dollar - f.eks. ved start af en skovbrand (en del af Bornholm og det meste af nåle- og birkeskovene i Sydsverige kan jo være den rene krudttønde om sommeren).

2) Hvis vi derefter antager, at vi får behov for at trykke på abortknappen 0,5-4 gange om året, hvilket vel er meget realistisk - ialtfald indtil CS får lidt mere styr på retningen :-) kan man af en tabel aflæse, at sikkerhedsniveauet skal være SIL 3.

3) Ud fra dette niveau (SIL 3) skal den gennemsnitlige fejlhyppighed for failure on demand være mindre end 10^-3, dvs. at hvis du trykker på abortknappen, skal den virke med en sikkerhed på 99,9%. Det niveau får du ualmindelig svært ved at leve op til, hvis du sender et aktivt udkoblingssignal. Du kan dog formodentlig reducere kravet vha. AAU'erne, der også kan aborte; men så skal du garantere, at de fungerer med den krævede sikkerhed, og det er i praksis næsten umuligt, når det indgår software. Jeg vil dog igen understrege, at jeg absolut ikke er ekspert på området og stært tilråde, at I tager kontakt til én, der er.

4) Et punkt, som jeg er overordentlig usikker på, er, om udstyret også skal leve op til de pålidelighedskrav, der stilles til det krævede sikkerhedsniveau - her SIL 3. Hvis det er tilfældet, skal sandsynligheden for en farlig, udetekteret fejl være mindre end 10^-7 pr. time med en statistisk sikkerhed på 99% (uprøvet system), hvilket svarer til max 1 fejl på 5000 år. Bemærk at fejl godt må opstå - bare de detekteres. Det er på dette punkt, at SEU muligvis kan blive et problem, for sandsynligheden for SEU kan meget vel være højere end det krævede niveau.

Der er rigtig mange måder at løse problemerne på. I denne blog er allerede nævnt nogle stykker, og jeg kan supplere med at foreslå Texas Instruments ARM Herkules serie, som har en dobbelt CPU, som er spejlet og tidsforsinket, så en SEU eller anden fejl med garanti vil blive detekteret med en til SIL 3 krævet sikkerhed.

Problemerne er absolut til at løse. Jeg påpeger bare nogle punkter, som jeg mener, man lige skal vende engang. Det kan f.eks. meget vel vise sig, at man for at leve op til sikkerhedskravet skal benytte 3 systemer, og så behøver man næppe at koncentrere sig om SEU, da det er aldeles usandsynligt, at en sådan vil ramme alle 3 systemer på én gang.

Det blev en lang smøre; men sådan er det jo, når man er usikker og ikke kan svare helt konkret :-)

PS. Punkt 1) og 2) skal ses i sammenhæng. Risikoen for at ramme Bornholm eller Sydsverige er selvfølgelig ganske lille, og bliver mindre efterhånden som I får styr på retningen. Dermed bliver sandsynligheden for at du får brug for abortknappen også mindre, og du kan muligvis reducere sikkerhedsniveauet. Jeg ville dog ikke under nogen omstændigheder gå under SIL 3.

Jeg har før haft den ære at have Steen Andersen som gæsteblogger på wired, flere gange, hvor han gik i dybden med Gopro-hacking, kontrolpaneler og FIDO... alt sammen på engelsk...
Der kommer i øvrigt snart emner om alt dette på hjemmesiden, hvor CSere (udover Peter og jeg) kan skrive om alle disse emner.. på engelsk igen naturligvis..

Jeg tror efterhaanden at emnet omkring SEE, SEU og CS er diskuteret nok. Jeg vil dog lige smide et link til en interessant hjemmeside som beskriver nogle af effekterne, og hvorfor det ikke altid er nok bare at klistre mere masse (bly, alu, etc) omkring komponenterne

http://holbert.faculty.asu.edu/eee560/see....

Jeg er sikkert ikke den eneste der har det sådan, selvom der kun er gået en lille uge.

Jeg vil dog sige at det ikke hjælper med Kristians tweets om LES Galcit design!

;-)

Jeg sidder en anelse fortumlet ved computeren - er lige kommet ind af døren efter en dag der startede tidligt...Jakob Hansen, Ewa Knap og jeg har arbejdet hele dagen på TM65IIA. Så har jeg regnet på LES med von B. Da Jakob gik hjem kl. 16 gik jeg i gang med det nye H202 anlæg som er fem gange så stort som det gamle. I dag har jeg fået lavet 2 ltr T-stoff og apparatet fungerer fremragende - kun bedre i stor skala.

Men - jeg er KVÆRNET - brugt op - og vil rigtigt gerne skrive - og jeg kommer lige om lidt med noget.

Der er bare meget i gang.

I morgen er der foredrag, og der skal forresten gøres fint herhjemme for Sirid kommer hjem kl 17 fredag. Jeg har købt flag og sætter et hjerte på døren - jeg savner hende så meget - hun har været en måned i Culombia.

Men jeg lover jeg skriver snart !

Peter Madsen

Mens i venter på flere guldkorn fra Peter, så se lige på denne lille video, som Von B fandt på youtube.

http://www.youtube.com/watch?v=hWOgWTVG5rE

Mens i venter på flere guldkorn fra Peter, så se lige på denne lille video, som Von B fandt på youtube. http://www.youtube.com/watch?v=hWOgWTVG5rE

2 ting:
Jeg er nysgerrig efter at vide, hvad kommetatoren sagde, altså hvilken vinkel de har på CS projektet derovrefra. Er der nogen, der kan lidt russisk og har lyst til at fortælle?
Den anden: Er det bare mig, der krummer tæer, hver gang man kan høre suset fra et objekt, der passerer tæt forbi "kameraet" i det lufttomme rum?

Er det bare mig, der krummer tæer, hver gang man kan høre suset fra et objekt, der passerer tæt forbi "kameraet" i det lufttomme rum?

Jeg har lært at leve med det - sikkert et eller andet standard animationssoftware der antager at der er en atmosfære.

Dem der så laver det synes nok at det lyder fedt, så det tager de med selv om det er helt forkert.
De altid travle journalister bruger det så bare som-det-er, også selv om de måske ved at der ikke er nogen atmosfære i rummet, da de ikke har tid til at klippe special-effekt lyden ud.

Skal vi tale om lyd der får en til at krumme tær, så har jeg det endnu værer med LYSkegler der har lyd på...

problemmet er nok at hjernen forventer at der er lyd påm feks et obejket der passere et kamera, med mindre man er vidende om forhold der kan mulig gøre transport af lyden (manglen på samme).