Ingeniørstuderende

Tidligere på året 2011 fik CS en ingeniørstuderende fra DTU. Har Peter Madsen hørt mere ham.

Tryksætning af LOX

Nu har jeg jo visse problemer med min hukommelse (stress) så hvis vi har været omkring min tanke i en tidligere tråd så siger jeg : undskyld
Kan trykkes styres ved at montere et varmetæppe omkring LOX tanken og så bare lave en regulering, så jo mindre lox i tanken jo højere temperatur fra varmetæppet hvilket giver mere kogende LOX og derfor et højere tryk?

Ventilløs HEAT 1X

Peter skriver:
"Hvis man følger CS kan jeg godt frygte at man kan miste den røde tråd i det hele"

Hjælp mig lige her.
Var det ikke netop ventilen der muliggjorde abort ved flyvningen i Juni ?
Forstår selvfølgelig filosofien med den mest enkle løsning.
Men giver muligheden for at slukke raketten kontrolleret ikke så mange indlysende fordele ?
Ikke mindst overfor diverse skeptikere og bekymrede instanser. Som I selv har været inde blev det på smukkeste vis bevist i Juni. Og endnu en årsag til at launchen blev en succes.

Re: Ventilløs HEAT 1X

Niels Sigvard Hansen:

Men giver muligheden for at slukke raketten kontrolleret ikke så mange indlysende fordele ?

Vi giver ikke afkald på at kunne abortere.

Hvis vi vælger et ventilløst design, vil vi sørge for at kunne tage trykket fra LOX-tilførslen på anden måde: ved at punktere LOX-tanken. Den er i forvejen (også på HEAT-1X) forsynet med en sprængplade som back-up til overtryksventilen. Ved abort af en ventilløs raket kan denne sprængplade simpelthen blive sprængt i stykker (dobbeltbetydning af "spræng"plade).

Inden I kommer for godt i gang (igen) så er proceduren for dette (i forhold til separation, højde, flyveretning mv.) ikke fastlagt.

Abort på ventiløs.

Som Niels antyder så blev Rom ikke bygget på en dag...

Men - HEAT 1X havde en dobbelt sikkerhedsfunktion på tanktrykket. Den havde en konventionel fjederbelastet sikkerhedsventil og en sprængplade.

Det er en såre enkel indretning. Vi havde en 0.2 mm tyk aluplade indspændt mellem to flanger med et ø 21 mm hul. Den ene flange sad på et tykt rør til tanken. Ved et tryk på 28 - 30 bar ville denne plade revne og trykket gå af HEAT. Tanken var at skulle sikkerhedsventilen svingte ville næste beskyttelse være sprængpladen. Systemet er faktisk lovpligtigt på cryotanke i industrien.

Sprængpladen er dog ret følsom. Tænk samme system med en ø 50 plade. På selve pladen anbringer vi en lille sprængkapsel ( prof type )
Aktiveres denne går pladen i tu og trykket går af tanken.

Sker dette i luften vil oxygenforsygningen til motoren i løbet af brøkdele af sekunder falde hvorved også kammertrykket falder. Ved et vist niveau kan HEAT ikke længere overvinde luftmodstanden og hele LOX ladningen vil ruge frem i tanken, og faktisk strømme ud af den nye åbning.

Dette kræver kun at sprængkapselen går - strøm på et sted og fuld stop. Det kan blive så pålideligt som noget.

Når jeg skriver her - forholder jeg mig til en ø 650 mm raket som HEAT, med navnet 2X - og med aktiv styring. Den er ubemandet - og har ikke noget LES system eller noget andet. Formålet med sådan et system er - som i 2011 at kunne stoppe HEAT hvis kursen afviger mere end et fastsat niveau fra det ønskede.

Få, enkle dele, kan give en meget høj pålidelighed.

Vores LES raket har ikke dette - for vi forventer ikke at nogen vil ønske at aborte en abort. Slet ikke inden for de 3.5 sek den kører.

Det er svært at få alt med i blogs der helst ikke skulle blive mere urimeligt lange og tekniske end de allerede er...

Peter Madsen

Re: Abort på ventiløs.

Vores LES raket har ikke dette - for vi forventer ikke at nogen vil ønske at aborte en abort. Slet ikke inden for de 3.5 sek den kører.

Hvis raketten vender næsen nedad i lav højde kunne det vel nok være interessant med en dobbelt abort?
Eller måske har jeg ikke forstået princippet :o(

Re: Abort på ventiløs.

LES er i første omgang designet til en Ramp Abort som jeg blev belært om i en anden tråd.Der er ikke regnet på hvorledes en Flight abort vil opføre sig som jeg forstod det.

Re: Abort på ventiløs.

Næsen nedad? Ramp abort?

Jeg tror ikke det er muligt at skrive det tydeligere end Peter har gjort i teksten, så prøv lige at læse det igen.

Men for at gentageendnu en gang: Der er TO seperate projekter, der ikke har noget med hinanden at gøre. Hvis den store raket løber løbsk skal man have en måde at standse den på. Hvis den lille fiser afsted så er det bare ærgeligt, for den kan IKKE standses.

Hmm. Er det ikke gentaget nok nu?

Re: Abort på ventiløs.

Det er en glimrende idé med det ventilløse design; men aktiv udkobling (støm) og mangel på redundans duer altså ikke.

Når raketten bliver så stor, at den kan nå Bornholm, hvis den kommer ud af kurs (det er den vel egentlig allerede?), er I nødt til at kunne bevise, at sikkerhedssystemerne er opbygget i henhold til gældende sikkerhedsnormer som f.eks. IEC 61508. Den hamrende dyre godkendelse "glemmer" vi lige :-) Det betyder redundante systemer, som af sig selv kobler ud f.eks. i tilfælde af strømsvigt, og det gør en pyroteknisk løsning, som måske oven i købet skal have et aktivt radiosignal fra kontrolcentret (ikke fravær af radiokommunikation), absolut ikke. Måske kan problemet løses ved at holde pladerne (mindst 2) på plads med elektromagneter, hvis man kan sikre, at systemet ikke fryser.

Ved sidste affyring på Bornholm skulle Windows lige genstartes inden kommunikationen virkede - i 2. forsøg! Med den pålidelighed var I hamrende heldige med, at aborten virkede. Var raketten landet uden for øvelsesområdet, havde det måske været slut for CS! Gør det ny rigtigt efter bogen, inden én eller anden sur "show-stopper" begynder at kræve dyre sikkerhedsgodkendelser.

Et passivt sikkerhedssystem kan selvfølgelig koble ud i utide, så missionen fejler, og risikoen for det stiger med redundansen; men det er prisen, så I må hellere lave det ordentligt. Det kan godt være, at CS er villige til at tage en relativ stor risiko; men det skal I ikke regne med, at alle andre også er.

slemt

det er vel ikke være end at man også kan få en faldskærmsudspringer i hovedet

sikkerhed?

Jeg tør dårligt skrive det, men har i tænkt over at jeres udvikling af raketter kunne gavne nogle uheldige elementer?

Re: sikkerhed?

Jeg tør dårligt skrive det, men har i tænkt over at jeres udvikling af raketter kunne gavne nogle uheldige elementer?

Arh, come on! De laver jo ikke noget, et hvilket som helst land eller narko/oliebaron ikke selv kan betale sig fra at få lavet.
At det så nok er både lettere og billigere at købe det fra Rusland er en anden sag. Deres raketter dur bar ikke så godt til rum-misioner (tror jeg).

Re: sikkerhed?

nu er opskriften jo det vigtigste ved cola, hvis alle kender den kan alle lave den, og jo simplere man kan lave den jo flere kan, det må da have strejfet nogens tanke

Re: sikkerhed?

Mon ikke Forsvarskommandoen kan finde alt hvad der er skrevet om og af CS oversat til arabisk? ;-)

Re: Abort på ventiløs.

Har læst, har læst igen, LES er til ramp abort når det bliver indført på den bemandede kapsel engang.Kan kun give dig ret.
@Carsten Kanstrup. vil et system som når det mister spænding, initiere abort sequens som drives via geleakkumulator eller kondensatorer kunne godkendes?

Re: Abort på ventiløs.

LES er til flight abort.

Re: sikkerhed?

Nu er der lige en enkelt ting der mangler i CS programmet før at det kan bruges af terrorrister eller andre nationer. Targeting delen!!
Hvad hjælper det at kunne sende 250 kg op til100 km væk hvis du ikke ved hvor det lander.Med så lille en nytte last skal der laves en cep på omkring 25 meter før at det kan bruges til noget praktisk terror angreb.
http://www.missilethreat.com/m....asp
det er nok lettere af få fingr i et af disse med konventionelt sprænghoved, de har været tilsalg på E-bay på et tidspunkt 8))

Re: Abort på ventiløs.

Definer flight abort.
Systemet blev oprindeligt udviklet til brug før, under og umiddelbart efter liftoff.
Ud fra hvad jeg har kunne finde blev systemet både på apollo, soyz og Shenzhou systemerne armeret når austronauterne blev stroppet ind og deaktiveret omkring 100 sekunder efter liftoff
At det så også havde en funktion under opstigningen som beskyttelses og varme skjold er noget andet.

Re: Abort på ventiløs.

@Carsten Kanstrup. vil et system som når det mister spænding, initiere abort sequens som drives via geleakkumulator eller kondensatorer kunne godkendes?

Det er MEGET vanskeligt, men dog ikke helt umuligt at lave et aktivt sikkerhedssystem. Hvis man f.eks. taler om personsikkerhed, hvor kravet måske er IEC 61508 SIL 3, skal man for systemer som dette uden lang tids driftserfaring dokumentere, at sandsynligheden for en farlig, udetekteret fejl er mindre end én fejl pr. 1140 år (10^7 timer) med en statistisk sikkerhed på 99% dvs. en statistisk fejlhyppighed på mindre end én fejl pr. ca. 5000 år! Det betyder, at man formodentlig skal bruge mindst 3 systemer, som konstant overvåger hinanden i mindste detalje. Hvis f.eks. forsyningsspændingen falder i det ene system, eller der sker en vilkårlig anden fejl, så det ikke længere kan forventes at virke, skal der stadig være 2 systemer (redundans) til at detektere det og koble ud. Det er måske til at håndtere ved meget simple systemer; men begynder man at involvere f.eks. en aktiv radiotransmission fra kontrolcentret eller forskellige computersystemer, bliver det i realiteten næsten umuligt.

Det er langt nemmere med passive systemer, som blot skal være redundante og dimensioneres, så de altid går i en sikker tilstand ved en vilkårlig fejl på en komponent.

Hvordan spiser man en elefant?

Begynd med en god opskrift Peter Madsen: Elephant Stew

Ingredients:

1 Elephant
10 Warthog
100 kilogram tomatoes
half ton potatoes
2 bags onions
100 kilogram salt
1 wheelbarrow onions (heaped)
10 liter vinegar
20 liter chutney
4 Guineafowl

Method:

Hunt the elephant, warthog and guineafowl. Hang guineafowl to ripen.
Cut elephant into edible chunks, (will take about a month).
Boil the warthog with other ingredients (except guineafowl) till nice and juicy. Now boil elephant chunks over high flames till tender. (will take about 4 weeks) and add everything together.
Boil for another 5 to 7 days.

Produces about 3,500 helpings.

Note: If the above isn't enough, add the guineafowl as well.

Re: Abort på ventiløs.

Carsten Kanstrup:

Ved sidste affyring på Bornholm skulle Windows lige genstartes inden kommunikationen virkede

Det har du påstået før. Hvor har du dén idé fra?

@Carsten Kanstrup

Som du ved er adgangen til abort hjerteblod for os. Se blog med den titel.

Carsten, alle løfteraketter i verden har abort systemer som er helt afhængige af telemetri, og af elektriske systemer ombord. Hvis din argumentation skal være helt vandtæt - så har du lige grounded rumfarten
- og dermed en hel del andet - med et pennestrøg.

Som du kan læse i min blog om range safety, det er den med fri abort, så er der to muligheder når man sender raketter op:

1. Den skal være så lille at den ikke kan nå mennesker

2. Man skal have pålidelige abort systemer.

Området er ikke reguleret af offentlige myndigheder når vi opererer uden for 12 sm grænsen.

Peter Madsen

hvad?

hvad sker der hvis den trods alt rammer Bornholm trods 12 sm grænsen
sådan set fra myndighedernes side?

Re: sikkerhed?

Jeg tør dårligt skrive det, men har i tænkt over at jeres udvikling af raketter kunne gavne nogle uheldige elementer?

Udviklingen af vaccine mod almindelige børnesygdomme har nok fremmet de uheldige elementer meget mere. Noget andet er at man aldrig må lade sig begrænse af hvad nogle idioter eventuelt kan finde på - der er for mange af dem og deres kreativitet er ubegrænset så deres dumhed overvælder hele samfundet hvis samfundet indretter sig efter dem!

@Kurt

"hvad sker der hvis den trods alt rammer Bornholm trods 12 sm grænsen sådan set fra myndighedernes side?"

Det samme som når fly styrter, tog afsporer, tag kollapser og alle andre ting som ikke MÅ ske.

Det handler i alle tilfælde om sandsynligheder.

Hvis man kikker på det så er vi så heldigt stillet at vi altid kan rykke længere ud på vandet. Det vil måske kræve en anden affyringsplatform, og det vil måske kræve at vi opererer længere fra Danmark - men det kan lade sig gøre hvis det er nødvendigt.

Jeg vil godt give et par eksempler her.

Motorcykler er markant farligere end mange andre trafikanter. De er kun sjældent strengt nødvendige - men er i høj grad populære på grund af køreglæden forbundet med dem.

Vi tillader ( naturligvis ) at de kører rundt til glæde for de få der har dem, og til fare for de mange der ikke har dem.

Forholdet mellem det antal mennekser det glæder at vi kan opsende raketter, og sandsyneligheden for at netop du bliver ramt af en - er sikkert meget bedre end forholdet mellem danske motorcyklisters glæde ved at køre motorcykel og faren for at du bliver ramt af en i trafikken.

Bemærk det er ikke den abolutte sandsynlighed jeg kikker på, men
forholdet mellem "bennefit" og "cost" Her er "bennefit" - Jaaa ! - vi har et dansk microrumprogram man kan følge og inspireres af. "cost" sandsynligheden for at den ene årlige opsendelse netop indfrier følgende kæde af uheld.

1. Darlig kurs

2. "optimal" bane for uheld mod Bornholm,

3. abort svigter

4. Af alle marker og skove og tomme bygninger vælger den netop nedsalg der hvor DU står og kikker på det.

( i virkeligheden er kæden meget længere - det er ekstremt vanskeligt at få ram på nogen uden at ville det. )

Det er simpelthen så utropisk urealistisk at blive ramt af en CS raket - fordi der er så uendeligt få af dem - og de er så langt ude på havet - at du skal forbyde motorcykler, ( og alt fra hakkebøf til chokoladestænger til piger i for korte kjoler ) før du forbyder nogen at i opsende en raket langt ude på åbnet hav væk fra alting.

Hvis der oveni købet er tænkt gode, kloge og åbne tanker om abortsystemer der kan forhindre det utopisk urealistiske i at ske, ja så giver det virkelig mening at man lader den slags foregå.

Hvad for et land ønsker du ? Skal vi regulere alt, hakkebøffer, piger i korte kjoler, høje hæle, retten til at spise mercipanbrød, og nyde en lakridspastil ?

Eller, skal vi kunne leve med at livet rummer nogle farer - som er relevante at beskytte sig imod ( fedt, cigaretter, tilsætningsstoffer, våben, forurening ) og lade de irrelevante farer eksistere fordi de er så små ? - og giver os glæde og inspiration ?

Tro mig - dette emne ligger mig rigtigt meget på sinde - selvom jeg ved at det er så usandsyneligt at det ganske givet er spild af tid.

Hvad med dampkedler på Dansk Jernbane klubs lokomotiver ?

Hvad med dykkerflasker ?

Hvad med styrken af træspær ?

Hvad med børns gynger i haven ?

Hvad med gå turen hjem fra en våd aften i byen ?

Hvad med faren for elektrisk stød ?

Det er yderst relevant at forbyde alt ovenstående. Ingen regulering eller certificering kan 100 % fjerne faren ved ovenstående. Når vi tilader noget som helst er det fordi sandsyneligheden for uheld står i et rimeligt forhold til den gavn vi har af at acceptere anvendelsen af børngynger, elektricitet, korte kjoler af lak, og høje hæle over 7,2 cm.

Jeg vil til enhver en tid sige at sandsyneligheden for et uheld der rammer trediemand ved CS aktiviteter, divideret med glæden for de der følger det, er bedre end den tilsvarende brøk ved f.eks. dartspil, hakkebøfstegning til middelfarve, spidsning af blyanter og karbade med vanddybder over 6,5 cm.

Hvadfor et samfund vil vi have ?

Peter Madsen

Re: Abort på ventiløs.

@ Niels Foldager

Ved sidste affyring på Bornholm skulle Windows lige genstartes inden kommunikationen virkede

Det har du påstået før. Hvor har du dén idé fra?

Fra TV transmissionen/nettransmissionen, hvor det tydeligt blev sagt.

@ Peter Madsen

Carsten, alle løfteraketter i verden har abort systemer som er helt afhængige af telemetri, og af elektriske systemer ombord. Hvis din argumentation skal være helt vandtæt - så har du lige grounded rumfarten
- og dermed en hel del andet - med et pennestrøg.

Man kan sagtens lave fejlsikre telemetrisystemer. Det kræver blot, at man repetitivt sender et "on" signal. Forsvinder bare ét eneste telegram (telegramløbenummer), går systemet automatisk "off". Sådan fungerer f.eks. vores nye feltbus Max-i, som netop er designet til at kunne opfylde IEC 61508 SIL 3. Bemærk desuden, at jeg skriver, at et aktivt udkoblingssystem er MEGET vanskeligt at lave, men IKKE umuligt.

Det er fuldstændig lige gyldigt, om du mener, at sandsynligheden for at blive ramt af jeres raket er nær 0. I fyrer kun, så længe millitæret giver jer lov til at benytte deres øvelsesområde. Hvordan vil I ellers kunne holde fly og andre fartøjer ude? Den tilladelse ryger nok, hvis I rammer Bornholm, eller hvis en "show-stopper" ikke er tilfreds med sikkerheden, så I kan lige så godt gøre det professionelt fra starten.

Af alle marker og skove og tomme bygninger vælger den netop nedsalg der hvor DU står og kikker på det.

Tja. Jeg mindes en historie i Det Bedste, hvor en mand ville skyde fisk med en riffel, men projektilet blev i stedet rikocheret af vandet og dræbte en ung pige i en åben sportsvogn over 1 km væk. Projektilet efterlod kun et lille blodløst sår under øret, som ikke blev opdaget af politibetjenten i den efterfølgende bil eller på hospitalet. Hvor stor er lige sandsynligheden for det Peter?

Re: @Kurt

Det er måske nogle af de parametre som du nævner der, omkring hvilket land vi ønsker,som vi skal tænke på i valgboxen. Jeg føler efterhånden at vi lever i et samfund hvor alt ansvar for eget liv er fjernet, og vi skal pakkes ind og sikres mod vores egen dumhed.I CS tager i ansvarligheden alvorligt og tænker ikke kun på hvad der sker med jer hvis uheldet er ude, men også på alle omkring jer.Respekt for jer.
Jeg har desværre endnu ikke fundet et parti der vil fjerne alle nuværende love ,regler og bekendtgørelser, og starte helt forfra med lovgivningen, og lave den :KISS

Re: @Kurt

ja ja ro på nu, man må vel spørge hvad de har tænkt på

@Carsten kanstrup

Dette er definitivt forkert:

"I fyrer kun, så længe millitæret giver jer lov til at benytte deres øvelsesområde. Hvordan vil I ellers kunne holde fly og andre fartøjer ude?"

Forsvaret giver ikke lov til noget. De tager ganske enkelt ikke den slags beslutninger - og de kan slet ikke tage den slags beslutninger uden for dansk territorium.

Vi har meddelt SOK at vi ønskede at aflyse området til skydning i visse perioder, og det har man så gjort. Det omfatter en note til lufttrafikken og informationer gennem Efterretninger for Søfarende.

At proceduren er sådan er produktet af en dialog med Søfartsstyrelsen.

Ved du godt at Søværnet ikke kan forbyde en russisk fregat i at øve sig med skarp ammunition i samme område ? Typisk vil russeren aflyse området, og danske orlogskibe vil sejle ind og kikke på hans aktiviteter. Han vil igen og igen henstille om at de smutter, hvorefter han vil gennemføre sin øvelse tydeligt irriteret over at der bliver kikket og filmet.

Folkeretten giver ikke landene ret store muligheder uden for deres territorialfarvand - kun undtaget er råstoffer og fisk.

Mht. din kilde til windows historien må jeg spørge dig - tror du på hvad TV2 news siger, eller tror du på hvad vi siger - husk inden du svarer at TV2´s kilde i dette tilfælde vil være os. Siger de noget med Windows og HEAT er det altså i modstrid med hvad vi siger til dem. Vi har pressefrihed - og de kan naturligvis insistere på at sige hvad det passer dem.

Du kan ikke, og må ikke regne med at oplysninger i pressen har nogen forbindelse til virkeligheden - det har jeg understreget før opsendelsen og jeg gentager det gerne.

Ideen med at sende et GO signal har været vent, prøv at læse bloggen om abort.

Takker i øvrigt for dine indspark - kritikere er altid et gode - og typisk ender vi med at inkorporere deres ideer og forslag i vores egne.
Som f.eks. ønsket flere statiske motortests for næste flyvning

Peter Madsen

@Kurt

Min lange svar kun fordi du stiller et vigtigt spørgsmål.

Peter Madsen

Re: @Kurt

jeg går ud fra myndighederne er glade for at man melder ens intentioner inden man letter med en raket, også selv om det er internationalt farvand ;O)

Re: Abort på ventiløs.

Carsten Kanstrup:

Fra TV transmissionen/nettransmissionen, hvor det tydeligt blev sagt.

Jeg ved ikke, hvad de har sagt; men uanset hvor tydeligt det var, er det noget vrøvl. Vores sender og booster er naturligvis ikke Windows-, endsige pc-baseret.

Re: Abort på ventiløs.

Carsten Kanstrup:

Fra TV transmissionen/nettransmissionen, hvor det tydeligt blev sagt.

Jeg ved ikke, hvad de har sagt; men uanset hvor tydeligt det var, er det noget vrøvl. Vores sender og booster er naturligvis ikke Windows-, endsige pc-baseret.

Det undrede mig også, at I kunne være så letsindige at benytte Windows til telemetristyring og styring af startsekvens.

Windows

Ved sidste affyring på Bornholm skulle Windows lige genstartes inden kommunikationen virkede

Det har du påstået før. Hvor har du dén idé fra?

Fra TV transmissionen/nettransmissionen, hvor det tydeligt blev sagt.

Det vil jeg gerne dementere. Jeg sad selv i TV2 News-studiet sammen med Michael Linden-Vørnle fra Tycho Brahe Planetariet og kommenterede opsendelsen, og på intet tidspunkt blev der nævnt noget om Windows. Du kan selv se og høre hele sekvensen på http://www.youtube.com/watch?v...pECI

Re: Abort på ventiløs.

Carsten Kanstrup:

Jeg mindes en historie i Det Bedste, hvor en mand ville skyde fisk med en riffel, men projektilet blev i stedet rikocheret af vandet og dræbte en ung pige i en åben sportsvogn over 1 km væk. Projektilet efterlod kun et lille blodløst sår under øret, som ikke blev opdaget af politibetjenten i den efterfølgende bil eller på hospitalet. Hvor stor er lige sandsynligheden for det Peter?

Sandsynligheden er "uendelig" lille. Og næppe én, man vil tage forholdregler mod i hverdagen.

Det er en god historie, men et dårligt argument. I en Verden med et meget stort antal hændelser per tidsenhed vil også meget sjældne hændelser kunne observeres fra tid til anden. Så kommer de i avisen, så du kan læse om dem. Men det ændrer ikke a priori sandsynligheden for den enkelte hændelse.

Hold dig hellere inden døre, så du ikke bliver ramt af et rikocheterende projektil fra en fjern skovsø.

3 Gange sikkerhed.

Hvis styringen af rakettens retning deles op på to uafhængige styresystemer, og abortmulighed også har sit eget uafhængige styresystem. Så skal alle tre systemer svigte samtidigt, for at raketten skulle kunne ramme Bornholm. Abortsystemet burde måske indeholde luftbremse og senere automatisk udløsning af faldskærm.

Visuel kontakt ?

Var det også med basis i visuel kontakt med HEAT-1X, at I foretog abort sidst i futtede den af ?

Re: Abort på ventiløs.

@ Tommy Johansson.

Prøv at læse dette blogindlæg:
http://ing.dk/artikel/120738-l...-tak

Ved ikke hvad du mener med at LES kan bruges som varmeskjold?

Sandsynlighed

@ Niels Foldager og Peter Madsen

Vi er fuldstændig enige om, at sandsynligheden for at blive ramt af raketten er forsvindende lille; men min pointe er, at hvis I laver systemerne ordentlig og professionelt iht. gældende normer, så I sagligt og professionelt kan berolige evt. tvivlere, får I nok lov til at fortsætte fra området ved Bornholm - også selv om raketten vokser. Hvis I derimod ikke gør og samtidig blogger om, at I accepterer et relativt beskedent sikkerhedsniveau, risikerer I, at en kedelig "papirnusser" sætter en stopper for hele projektet ved f.eks. at forlange ekstremt dyre sikkerhedsgodkendelser. Det var sådan set bare en venlig påmindelse.

OK, det var SOK og ikke millitæret, der gav jer tilladelsen; men selvfølgelig kan I ikke bare sejle uden for 12sm grænsen og skyde løs uden myndighedernes tilladelse og deres aflysning af luftrummet og området. I princippet måske, men ikke i praksis. Russerne kan måske. Det er storpolitik og "kold krig", men ikke en lille håndfuld raketamatører.

Re: Abort på ventiløs.

Carsten Kanstrup:

Jeg mindes en historie i Det Bedste, hvor en mand ville skyde fisk med en riffel, men projektilet blev i stedet rikocheret af vandet og dræbte en ung pige i en åben sportsvogn over 1 km væk. Projektilet efterlod kun et lille blodløst sår under øret, som ikke blev opdaget af politibetjenten i den efterfølgende bil eller på hospitalet. Hvor stor er lige sandsynligheden for det Peter?

Sandsynligheden er "uendelig" lille. Og næppe én, man vil tage forholdregler mod i hverdagen.



Det er en god historie, men et dårligt argument. I en Verden med et meget stort antal hændelser per tidsenhed vil også meget sjældne hændelser kunne observeres fra tid til anden. Så kommer de i avisen, så du kan læse om dem. Men det ændrer ikke a priori sandsynligheden for den enkelte hændelse.



Hold dig hellere inden døre, så du ikke bliver ramt af et rikocheterende projektil fra en fjern skovsø.

Ja jeg skal ud og sejle i morgen aften i Århus bugten, hvor jeg a og til iagttager marine hjemmeværnet på øvelse, mon ikke jeg skulle overveje min videre færten i bugten, da jeg kan risikere at blive ramt af et rikochetterende projektil! altså hvis nu at...

windows

Ja alle computere kan gå ned,
jo mere komplexe de er og jo flere programmer de køre som er udviklet
af mange og ikke testet sammen med hinanden og sammen med alle mulig hardware kombinationer, vi ser det jo hver dag, windows maskiner
gå jo oftere ned end æble maskiner og linux maskiner.

Ja vi bruger Windows maskiner, til DISPLAY af måle data,
men de er ikke direkte forbundet til at styre noget som helst den anden vej,
dette kræver en finger på knappen,
dvs vi kan overleve en flyve tur med en PC der er gået ned.
man kan vurdere om vi bør have flere parallele PC'er stående
om der er plads til det, vi har ikke harft grund til at foreslå dette,
da alle vores tests samt lang udviklings tid, ikke har vist at noget af dette var upålideligt, og det var heller ikke tilfældet da motoren ikke gad starte i første hug..
Ja der blev genstartet sender systemet, som er microcontroller baseret,
samt uplink forstærkeren der giver masser af margin på rækevidden,
alle raketens systemer blev ikke genstartede.
der gik hele 6 microcontroller kredsløb til at håndtere remote signalerne og styre alle udgange og måle og log ind og omkonfigurere på rampe,
ud over dette var der flere loggere ombord, hele 3 systemer, hvoraf vi fik de 2 igen, samt 2 video optagere, hvor vi kun fik 1 igen.
Alt i dag er microcontroller baseret, lige fra lommelygter til kaffemaskiner,
og mange af os lever netop af at udvikle sådan nogle sager hver eneste dag.
Sandheden er at vi faktisk ikke VED med sikkerhed hvorfor den ikke startede i første hug, der er brugt uendeligt meget tid på at rekonstuere og lave videnskab på netop dette fænomen i CS, vi er ikke tilfredse med tilfældigheder, og går virkeligt meget op i sikkerheden og virkemåden af alle vores kreationer, om det er mekanik eller elektronik osv.

Jeg er meget stolt af alt vi har lavet og leveret,
det var vores første flyvning, comeon, hvordan går det andre der prøver noget som helst første gang.

Re: Abort på ventiløs.

I beskrivelsen af funktion for LES til Gemini og Apollo program står der at LES beskytter CM mod opvarmning/friktions varme i den lavere del af atmosfæren.
Derudover giver det også en væsentlig beskyttelse ved "birdstrike" igen i den lavere del af atmosfæren.

Re: windows

@ Niels Foldager, Steen Eiler Jørgensen og andre

Ja der blev genstartet sender systemet, som er microcontroller baseret,
samt uplink forstærkeren der giver masser af margin på rækevidden,
alle raketens systemer blev ikke genstartede.

Så var der alligevel noget om snakken. Det blev bare udlagt fejlagtigt i pressen, som at Windows lige skulle genstartes, før kommunikationen virkede.

Re: Abort på ventiløs.

@ Tommy Johansson.

LES fjerner nok noget af luftfriktionen, men det er bare ikke hvad men normalt ville kalde et varmeskjold.

Re: Abort på ventiløs.

Fra overall beskrivelsen:
A boost protective cover is attached to the tower and completely covers the command module. This cover protects the command module from the rocket exhaust and also from the heating generated by launch vehicle boost through the atmosphere. It remains attached to the tower and is carried away when the launch escape assembly is jettisoned.
Fra system beskrivelsen:
Boost Protective Cover -- It is made of layers of impregnated fiberglass, honeycomb cored-laminated fiberglass, and cork. It has 12 "blow-out" ports for reaction control motors, vents, and an 8-inch diameter window in front of the commander's forward viewing window. It completely covers the command module to prevent charring of external surfaces during boost out of the earth's atmosphere. It is jettisoned with the launch escape tower assembly.

Ja jeg spørger bare: er det ikke et varmeskjold der beskrives her?

Re: Abort på ventiløs.

Jeg ville nu stadig mene at der er forskel på varmebeskyttelse og varmeskjold, når det kommer til rumfart.

Re: windows

Siden i jo også er open-surse tænker jeg lidt over om muligheden ikke kunne være med Linux eller deres Ubuntu 10.2

Er dette en mulighed for softwaren i LES eller HEAT

Re: windows

Siden i jo også er open-surse tænker jeg lidt over om muligheden ikke kunne være med Linux eller deres Ubuntu 10.2

Er dette en mulighed for softwaren i LES eller HEAT

Nu kører alt jo tilsyneladende på on-board (i ordets egentlige betydning!) mikrokontrollere og data gemt on-board simultant med at blive transmitteret tilbage.

Selvom jeg selv er Linux-mand, er valget af OS nærmest ligegyldigt i denne sammenhæng. Det drejer sig om hvad der er til rådighed at udviklingsværktøjer og især programmørernes kendskab til disse. Skulle man endelig begynde at tænke i disse baner er Linux lige så lidt vejen frem - snarere en form for simplificeret *BSD, med mindre man helt vil skifte til lukkede militære systemer.

Re: Abort på ventiløs.

Tja. Jeg mindes en historie i Det Bedste, hvor en mand ville skyde fisk med en riffel, men projektilet blev i stedet rikocheret af vandet og dræbte en ung pige i en åben sportsvogn over 1 km væk. Projektilet efterlod kun et lille blodløst sår under øret, som ikke blev opdaget af politibetjenten i den efterfølgende bil eller på hospitalet. Hvor stor er lige sandsynligheden for det Peter?

Den ammestuehistorie er helt hen i vejret. Det er fysisk umuligt og det er eftervist af det populær-videnskabelige TV-program "Myth Busters". De prøvede at skyde "ofre" i vandet og konklusionen var at jo større kaliber og mundingshastighed desto dårlige penetrationsdybde simpelthen fordi projektilet splintredes og energien gik tabt. En simpel, "langsom" riffel stak væsentligt dybere i vand end en high-speed riffel og ingen af dem ville være dødelige under en meter vand.

At påstå at et projektil kan rikochettere i vand fra en vinkel hvor manden rent faktisk kan se fisken og stadig være dødelig efter 1000m er direkte morsomt. Det er *meget* nemmere at få en meteor i hovedet.

Re: windows

Carsten Kanstrup:

Så var der alligevel noget om snakken. Det blev bare udlagt fejlagtigt i pressen, som at Windows lige skulle genstartes, før kommunikationen virkede.

Nej, der var ikke. Der blev ikke genstartet noget operativsystem.
Din reference til pressen var jo også forkert.

Når man konstaterer et tilfælde af manglende respons og kun har minutter til at fejlfinde, er det fornuftigt at man laver en tænd/sluk procedure overalt. Det siger intet om, at der var fejl i det pågældende system. Man ville gøre det samme med en kaffemaskine.

Det er svært ikke at opfatte din sætning "... skulle Windows lige genstartes inden kommunikationen virkede" som nedladende.

Jeg tror, vi har modtaget dine velmente budskaber.

O.S.

Alle "mine" boxe køre med mindre microcontrollere
AVR mega88 og mega168 da de er rigeligt til opgaverne,
der bruges ikke noget OS, og programmerne er lavet helt uden interrupts,
af den årsag at det sagtens kan lade sig gøre at køre de hele i sekvens,
derved bliver afprøvning meget lettere og der kommer mindre chance
for at noget man ikke har tænkt over kommer til at vise sig senere.

Flemming kan sikkert undeholde en del mere med "sin" box
som indeholder en langt hurtigere 32bitter fra ST da der skal regnes
og lagers store data mængder på flash kort.
Alt vores flight hard og software er hjemelavet, specielt designet til deres opgaver

Re: windows

@ Peter Madsen og Niels Foldager:

Jeres tålmodighed er beundringsværdig !!!

- specielt efter den "sandfærdige" historie om riffelkuglen ;o))

mvh Flemming

Re: Visuel kontakt ?

Rud Wichmann:

Var det også med basis i visuel kontakt med HEAT-1X, at I foretog abort sidst i futtede den af ?

Ja. Pejlingen foregik manuelt med sigteantenner støttet af signalstyrkeindikator fra et videolink og live videobilleder på skærm.

Vi har 8Watt sende styrke, og 10dB forstærkning på en beam antenne. Med en spredning på 16 grader, så det er relativt let at ramme, selv i blinde. Abortsignalet sendes 5 gange per tryk.

Automatisk search med scandering blev diskuteret, men nedprioriteret på denne mission.

Softwaren viser prediktorer, der hele tiden giver positionen for landingen både, hvis vi stopper motoren nu, og hvis vi ikke gør. Falder data fra raketten ud, benytter systemet de sidste valide data.

Når vi engang har udviklet aktiv guidance, får guidance sikkert også noget at skulle have sagt mht. abort.

Men alle disse ting er under fortsat udvikling.

Re: windows

Jeres tålmodighed er beundringsværdig !!!

Enig. Efter en enkelt høflig forklaring er der åbent for sarkastiske svar.

Re: windows

Siden i jo også er open-surse tænker jeg lidt over om muligheden ikke kunne være med Linux eller deres Ubuntu 10.2

Hvis man bare skal lave et hurtigt GUI og man tilfældigvis ikke har lyst til at bruge en masse energi, tid og penge på det så er der - desværre - ikke meget FOSS som slår Microsoft's Visual Studio og .net!

Måske da lige dette: http://sourceforge.net/project...hmi/ - som bruger VisualStudio.

Eller "Ren" Linux+FOSS (Python): http://sourceforge.net/project...gic/


PS0: Siden virtualisering er blevet standard og tilgængelig for enhver, f.ex. via 'qemu-kvm' eller 'virtualbox' er det blevet psykologisk nemmere at vælge Windows til de ting som dette OS tilfældigvis er bedst til - man "spilder" jo ikke længere en hel maskine på "skidtet" ;-).

PS1: Man har brug for virtualisering, selv på sin desktop: F.ex. så virker FreeBSD 8.1's gcc-tools for TI msp430 helt perfekt, men man behøver Windows for at få print-pakken og ICE-programmeringsboksen til msp430 til at virke. ... eller man kan mange bruge uger på at debugge hvorfor ting ikke/aldrig(!) helt virker i Linux under Wine.

Windows og tålmodighed

@ Niels Foldager

Når man konstaterer et tilfælde af manglende respons og kun har minutter til at fejlfinde, er det fornuftigt at man laver en tænd/sluk procedure overalt. Det siger intet om, at der var fejl i det pågældende system. Man ville gøre det samme med en kaffemaskine.

Det er svært ikke at opfatte din sætning "... skulle Windows lige genstartes inden kommunikationen virkede" som nedladende.

Det er skam også nedladende, så det er ganske rigtigt forstået :-) Er det virkelig kun rygklappende kommentarer, der er velkomne? Jeg tror faktisk, at et kvalificeret modspil fra professionelle er ganske sundt!

Man kan ikke få kontakt og genstarter så. Herefter virker det i 2. forsøg, dvs. at der skulle mindst 3 forsøg til. Det er for så vidt OK og godt nok til en affyringssekvens; men absolut ikke til et abortsystem - uanset om I sender abortsignalet 5 gange pr. tryk. Det skal være fejlsikkert, eller raketten skal selv kunne spore sin position og aborte automatisk vha. redundante systemer, hvis den kommer uden for skydeområdet.

Mht. enhver form for software vil jeg tillade mig at påpege, at kravene normalt er 10 gange større end for hardware, da software er meget mere uforudsigelig, og så snakker vi lige én fejl pr. 50.000 år (10^8 timer med en sikkerhed på 99%), hvis man skal leve op til IEC 61508 SIL 3 (jeg ved ikke hvilke normer, der gælder for rumfart). F.eks. benytter Pilz sikkerheds PLC'er 3 CPU'er af 3 forskellige typer/fabrikater programmeret af 3 forskellige programmører for at skabe den krævede diversitet. Moralen er - lav alt sikkerhed i simpel hardware så vidt det er muligt, og glem alt om Linux og Windows til sikkerhedskritiske anvendelser.

Ja, CS og andre har udvist en engleagtig tålmodighed ved at høre på mine kommentarer; men CS må hellere blive sur på mig end på én eller anden embedsmand, der sætter en kæp i hjulet for det videre forløb, fordi CS ikke har gjort sit arbejde tilstrækkelig professionelt.

Jeg gælder mig hvergang i skriver om nyt

og ser frem til at læse om udfaldet "Og jorden skal ryste..., og de følgende resultater af analyse på data'erne fra testene.

Sandheden, skal man aldrig tage for givet -hvis den kommer ud igennem en anden end kilden, Ej heller om det er officiele medier der transportere den til en....

For hulen, da -hvad der ikke er blevet sagt og skrevet af vrøvl og opdigtet gøjl om jeres projekt. -når det lykkedes og Du/I skriver bogen om det, så bliver alle de fejl agtige postulatater og presse meddelelser perfekte at have på bagsiden, Men en lille fodnote fra jer "selv med alle alle de rette informationer, formåde pressen ikke at komme rigtigt ud med det, Vi nåede 100km som planlagt fra starten"

-T

sømbrædt

et sømbræt ville vel være det sikreste, så er der kun den menneskelige faktor tilbage ;O)

Re: sømbrædt

-jeg slår gerne de første 100 slag for sikkerheden ved CS

Re: Windows og tålmodighed

Jeg tror faktisk, at et kvalificeret modspil fra professionelle er ganske sundt!

Garanteret, men der er forskel på systemer. De certificeringer du slynger om dig relaterer sig til 24/7 systemer der står på redundante elforsyninger godt forankret i mulden. Det er fint man prøver at være kritisk med sikkerheden i industri-systemer og sådan, men det er svært ikke at grine lidt af de her certificeringer. 1 fejl per 50.000 år, det er jo umuligt at eftervise (og desuden fuldstændigt absurd uholdbart).

Det skal være fejlsikkert, eller raketten skal selv kunne spore sin position og aborte automatisk vha. redundante systemer, hvis den kommer uden for skydeområdet.

Nej, det skal virke. Du glemmer de fysiske begrænsninger. Automatisk abort kan godt lade sig gøre, men da det ikke er muligt at bruge GPS ved disse hastigheder, så vil en ren maskin-løsning basere sig på inertiel data. Det er betydelig ringere kvalitet end et par menneskeøjne.

Mht. enhver form for software vil jeg tillade mig at påpege, at kravene normalt er 10 gange større end for hardware, da software er meget mere uforudsigelig, og så snakker vi lige én fejl pr. 50.000 år (10^8 timer med en sikkerhed på 99%), hvis man skal leve op til IEC 61508 SIL 3 (jeg ved ikke hvilke normer, der gælder for rumfart). F.eks. benytter Pilz sikkerheds PLC'er 3 CPU'er af 3 forskellige typer/fabrikater programmeret af 3 forskellige programmører for at skabe den krævede diversitet. Moralen er - lav alt sikkerhed i simpel hardware så vidt det er muligt, og glem alt om Linux og Windows til sikkerhedskritiske anvendelser.

Så er det jo heldigt at det netop er det der er gjort :) uC'ere der kører rent sekventielt.

Ja, CS og andre har udvist en engleagtig tålmodighed ved at høre på mine kommentarer; men CS må hellere blive sur på mig end på én eller anden embedsmand, der sætter en kæp i hjulet for det videre forløb, fordi CS ikke har gjort sit arbejde tilstrækkelig professionelt.

I denne sammehæng havde det været passende at udskifte "professionelt" med "langtrukken og dyrt". Jeg har set meget langtrukken dyrt bras, og mange systemer der er af langt bedre kvalitet som er lavet af "amatører". Konceptet er jo netop at vise at projektet kan lykkedes ved bare at gøre det (billigt og hurtigt) istedet for at sidde i et hjørne og bide negle for evigt.

Hvis der kommer kedelige embedsmænd på banen, så er det ikke CS' opgave at slås med dem på deres hjemmebane, men istedet løse problemet på CS' måde (super-MLP!)

Re: Windows og tålmodighed

@Carsten Kanstrup:

Jeg tror faktisk, at et kvalificeret modspil fra professionelle er ganske sundt!

Det tror jeg, alle er enige i - vi venter så stadig på et fra dig ;o))

- første professionelle tiltag KUNNE jo være at få styr på de "fakta" du slynger om dig med. Først genstart af windows, så genstart af "ikke windows" hvorefter det virkede i 2. forsøg. BEGGE dele er usandt.

Mit råd til dig må være: Ophold dig aldrig inden for det potentielle nedslagssted for en CS raket - så skulle du være sikker - for mit eget vedkommende vil jeg gerne så tæt på som muligt - for at opleve "drønet".

Dette var IKKE ment nedladende, men blot et forsøg på at understrege, at forskellige mennesker har forskellig tilgang til emner. Som Anders skriver ovenfor: Hvis CS skulle efterleve dine ønsker (krav) til hw/sw, ville det blive 100% sikkert - der ville nemlig aldrig blive en raket. Man er som med alle andre systemer nødt til at analysere price / performance for givne tiltag, og så vurdere, hvor billigt (usikkert) et system, man kan leve med.

Yderligere: Jeg er ret sikker på, at rigtigt mange af de forslag der kommer her på ing.dk bliver analyseret til bunds af CS, og dem der giver mening, bliver naturligvis implementeret.

Sæt dig nu hjem og bed til vor herre om, at den næste CS raket udraderer en mindre Bornholmsk by, så du kan skrive "Hvad sagde jeg" her på ing.dk om et par år ;o)

mvh Flemming

Re: Windows og tålmodighed

@ Anders Palm

Sikke da noget vrøvl. IEC 61508 bruges til sikkerhedssystemer - ikke til kraftværksstyringer, og al computerteknik involverer software, der ifølge sagens natur altid er sekventiel. CS anvender bare ikke interrupts eller operativsystemer; hvilket imidlertid ikke gør sagen bedre, da et non-maskable interrupt er alt afgørende for sikkerhedssystemer - prøv f.eks. at se på sikkerhedsprocessoren TMS570 fra TI.

Én kritisk fejl pr. f.eks. 5.000 år er absolut ikke umuligt at bevise. Der må nemlig godt opstå fejl - bare de detekteres! Det farlige er udetekterede fejl. F.eks. har vores feltbussystem Max-i 22 checkbit. Det betyder, at hvis systemet kan køre uden fejludkoblinger i blot 11 timer, betyder det, at sandsynligheden for en udetekteret fejl er mindre end 1 fejl pr. 1140 år med en statistisk sikkerhed på 99%, og kravet til SIL 3 er dermed opfyldt. Det er straks noget værre med software, for hvor et 22-bit CRC polynomie er eksakt matematisk beskrevet, gælder det ikke for software, så her er kravet hævet en faktor 10. IEC 61508 er en internationalt vedtaget standard. At komme og sige at kravene i den ikke kan eftervises eller opfyldes er noget amatøragtigt vås.

@Flemming Rasmussen

Det er vel et faktum, at man genstartede microprocessoren for at få kommunikationen igang. Det gør man kun, hvis man opdager, at den ikke virker. Det er vel også et faktum, at raketten først gik af i 2. forsøg derefter. Så kan vi ikke blive enige om, at der alt i alt skulle mindst 3 forsøg til - det eller de første, som førte til genstarten, ét, der fejlede, og så endelige det, der førte til affyring? Eneste fejl i min udlægning er vel, at jeg skrev Windows i stedet for microcontroller; men det var det, pressen oplyste.

Sæt dig nu hjem og bed til vor herre om, at den næste CS raket udraderer en mindre Bornholmsk by, så du kan skrive "Hvad sagde jeg" her på ing.dk om et par år ;o)

Det er jo lige netop det, jeg ikke gør ved at prøve at tage problemet i opløbet; men du og mange andre er bare så naive at tro, at I ikke vil blive mødt med sikkerhedstekniske krav, den dag raketten er stor nok til at nå både Danmark, Sverige og Tyskland - ikke mindst hvis I går over til væskeraketter, der nemt kan koge en hel børnehave eller en skole. Hvor vil I skyde, hvis det ikke skal være ved Bornholm? I nærheden af en olieboreplatform?

Min sidste replik her...

@ Anders Palm

Du er beviset på der stadig findes engle som kan sprede lidt sund fornuft her...

@Carsten Kanstrup,

Tag dig ikke af at du møder lidt modstand - dine kommentarer har jo den værdi at de får en til at indse at netop denne "no bullshit, lets get it done" holding der præger CS også er rigtig.

Engang beskrev jeg noget planlagt bugsering med Sputnik. Ubåden skulle slæbe MLP Sputnik over Østersøen til Bornholm.

En kommentator var meget kritisk og det kunne ikke lade sig gøre, og man kan ikke, og hvordan vil gøre det neddykket og jeg skal gi dig.

Så forklarede jeg hvordan det var planlagt til at blive gjort - med to slæbefartøjer ect.

Så svarede han minsanten:

Nåe, det lyder mere fornuftigt - det skal nok fungere...

-Mere fornuftigt end hvad ? Jo, mere fornuftigt end hans egen forestilling om hvordan en gruppe amatører han ingen havde respekt for, ville gribe det an.

Bugseringen lykkedes i øvrigt fint. Sputnik ankom den gang til tiden i Nexø Havn, skubbet af Nautilus´s elektromotor. Steen Lorck - med baggrund i Søværnet - lagde det hele til i smuk stil i Nexø havn efter 36 timer på vandet.

Den er der hele tiden - det kan man skuda ikke - nåe jo - det kan man jo egentligt godt. Heldet følger de tossede hvis de griber tingene fornuftigt an.

Godmorgen og hav en god dag.

Tak for en sjov, vigtig og god debat.

Peter Madsen

Re: Min sidste replik her...

@ Peter Madsen

Bugseringen lykkedes i øvrigt fint. Sputnik ankom den gang til tiden i Nexø Havn, skubbet af Nautilus´s elektromotor.

Ja, stævnen af Nautilus bevægede sig voldsomt op og ned i forhold til Sputnik, de korte trosser sprang efter noder, fordi der ikke var nogen fjedring og Kristian (så vidt jeg husker) blev voldsomt søsyg, fordi en ubåd absolut ikke er egnet til overfladesejlads. Er det dit succeskriterie? Havde I trukket den med en meget lang line (50-100 m) efter en kutter, havde det selvfølgelig været noget mindre alternativt, men meget mere overbevisende og jævnt.

Re: Windows og tålmodighed

Carsten Kanstrup:

Er det virkelig kun rygklappende kommentarer, der er velkomne?

Bestemt ikke. Det mener jeg heller ikke, historikken her på ing. dk viser. Vi gør os faktisk umage for at besvare spørgsmål, herunder kritiske, på en ordentlig måde.
Men når du konstant stiller spørgsmål ved og er helt ukorrigerbar mht. faktuelle forhold, som vi qua vores tilstedeværelse og involvering, er de nærmeste til at kende, så er det uproduktivt og spild af vores tid.

Vi har som sagt modtaget dine budskaber, - for længe siden og helt uforpligtende.

(Der var kun 2 launch-forsøg i alt. Men det tror du sikkert ikke på.)

Re: Windows og tålmodighed

Jeg ser at Flemming har opbrugt sin kvote af venlige mails...

Jeg har lige én tilbage, så den kommer her: Carsten, det er forstået, at du forsøger at yde dit bidrag. Der lader til at være en del uenighed om hvordan begrebet "sikkerhed" skal forstås, så skal vi ikke bare lade det være ved det? Og rent faktisk så har CS jo fundet et hul i vores ellers så fintmaskede lovgivning der gør at de kan fortsætte som de gør nu, ligegyldigt hvad du eller jeg mener. Så hvor er pointen andet end at spilde alles tid? CS vil flyve, hvis de anser sikkerheden for tilstrækkelig. Hvis de tager fejl, vil CS sandsynligvis ophøre med at eksistere.

OK?

Re: Windows og tålmodighed

@ Niels Foldager

Der var kun 2 launch-forsøg i alt. Men det tror du sikkert ikke på.

Jo selvfølgelig gør jeg det; men jeg taler ikke om launch-forsøg; men om kommunikationsforsøg, og her skal det eller de fejlslagne forsøg, der førte til genstarten, tælles med. Det er jo kommunikationssikkerheden, der har betydning for abortsikkerheden, når systemet har aktiv udkobling, som i jeres tilfælde.

Re: Windows og tålmodighed

Sikke da noget vrøvl. IEC 61508 bruges til sikkerhedssystemer - ikke til kraftværksstyringer

Jeg nævnte intet om kraftværker, men IEC 61508 bruges til industrielle systemer, de står pænt og beskyttet.

, og al computerteknik involverer software, der ifølge sagens natur altid er sekventiel. CS anvender bare ikke interrupts eller operativsystemer; hvilket imidlertid ikke gør sagen bedre, da et non-maskable interrupt er alt afgørende for sikkerhedssystemer - prøv f.eks. at se på sikkerhedsprocessoren TMS570 fra TI.

Kun sekventiel per processeringsenhed. Her tænker jeg også på lidt højere niveau, hvor et styresystem kan lade flere tråde kludre rundt i delte ressourcer, det sker ikke uden et OS. Interrupts er fint, men en fejlbehæftet sensor der aktiverer interrupts kan så til gengæld ende med at forstyrre.

Én kritisk fejl pr. f.eks. 5.000 år er absolut ikke umuligt at bevise.

Umuligt med sikkerhed at afgøre uden at køre i 5.000 år. Du kan naturligvis bevise at du med en rimelig statistisk signifikans ikke laver fejl ofte, men det forudsætter jo alligevel at f.eks. at din elektronik ikke er fejlbehæftet, at du ikke overskrider temperaturværdier osv. Prøv at sammenlægge den statistiske usikkerhed fra produktionen af komponenter, samling, montering, vedligehold osv. der alt sammen er defineret ud fra stikprøver.
At sige noget skal køre i 5.000 eller 50.000 år uden at lave fejl er en håbløs angivelse af sikkerhed. Intet elektronik kommer til at køre i 5000 år alligevel.

F.eks. har vores feltbussystem Max-i 22 checkbit. Det betyder, at hvis systemet kan køre uden fejludkoblinger i blot 11 timer, betyder det, at sandsynligheden for en udetekteret fejl er mindre end 1 fejl pr. 1140 år med en statistisk sikkerhed på 99%, og kravet til SIL 3 er dermed opfyldt.

Det er desværre noget vrøvl du siger. Det er fint at smide nogle ekstra bit i en checksum, det formindsker naturligvis antallet af reele fejlfortolkninger af din data, men altså, du sender jo din checksum igennem samme kanal som din data :)

Tillykke med nomineringen til produktprisen forøvrigt. Jeg ved ikke helt om jeg skal heppe på at produktet slår for meget igennem i min branche, jeg synes vi har busser nok ( http://xkcd.com/927/ )


@Peter Madsen

Ingen årsag :) Jeg lytter mere end jeg skriver i den her blog, men når jeg nu er faret til tastaturet så lad mig lige kime ind med en stor stor tak for den kæmpe inspiration dig og projektet er.
Jeg er desværre an af de her upraktiske folk der kan lave elektronik og software men ikke kan svejse om så mit liv afhang af det, ellers havde jeg nok kigget forbi ;)

Jeg nød til gengæld at se ubåden drøne ind i sydhavnen til halfmachine dengang jeg havde kontor i sydhavnen med havneudsigt

Re: Windows og tålmodighed

@ Anders Palm

Tillykke med nomineringen til produktprisen forøvrigt.

Tak for det.

Det er desværre noget vrøvl du siger. Det er fint at smide nogle ekstra bit i en checksum, det formindsker naturligvis antallet af reele fejlfortolkninger af din data, men altså, du sender jo din checksum igennem samme kanal som din data :)

Det er lidt mere kompliceret end som så. Fejl, der udelukkende rammer checksummen/signaturen, detekteres med 100 % sikkerhed. Fejl, der rammer identifieren, resulterer i en reject af telegrammet, og volder derfor ingen skade. En 7-bit Hamming kode beskytter mod at andre detekterer det fejlramte telegram (maskering). Fejl, på mindre end én databyte som f.eks. 2-bit Boolske sikkerhedstelegrammer, detekteres med en Hamming afstand på 8, dvs. at 7 og færre fejl detekteres med 100% sikkerhed. Resten med en sikkerhed på 1-2^-22. Hvis man derfor antager en konstant fejlhyppighed og systemet har kørt 11 timer uden fejl, vil sandsynligheden for en udetekteret fejl være bedre end 2^22 gange 11 timer.

Bemærk, at nøglen til dette er, at der godt må opstå fejl - bare de detekteres. Derfor virker en længere checksum. IEC 61508 er ren statestik.

Normer ISO-certificeringer og IEC xxxtal

Jeg er overbevist om CS, aldrig ville flyve med noget endsige teste noget som de ikke selv troede på.

-om det så følger div gældene normer og regler, gældene for alt muligt andet end SubOrbitalflyving med hjemme bygget raket, ja se det er en helt anden sag.

Men tror du seriøst at CS bygger noget med henblik på at det ikke skal være så sikkert som over hovedet muligt ?

ved startforsøg skulle der aktivt sendes et signal (det er ret fixst), og da langt mere fornuftigt end det modsatte hvor rakten starter når den INTET signal får.. det samme som jeg husker det i den blok om netop det gjorde sig gældene for den aktive Abort... -hvor et kortsignal tab kunne resultere i hvad som helst, hvor som helst, med uanede følger.

og det kan da godt være man så skal have Dobbelt op på signal modtage grej og på sende grejet.. -men det er da langt mere sikkert synes jeg.

Jeg ville personlig aldrig sætte mig i noget der ved en signal fejl udløste et eller andet, som så generede en anden fejl, der fik noget tredige til at ske. Jeg har det meget dårligt med jeg har opleve min ret moderne bil smide kontakten til styresystemet kortvarigt, ved en fejl i dens nervesystem (men det hedder CAN-BUS, men hul i hvad det hedder) den modtog ikke det signal den forventede, og konstaterede derfor at det var mest fornuftigt at lukke ned for Servo pumpen, og bremse forsærkeren, for dernæst at afbryde motoren (jeg er ret sikker på det system ikke tager højde for hastigheden)... til mit held foregik det ved lav hastighed på ral, og under bakning -og ikke på motorvejen...

Men sådan er jeg bare, andre har det fint med deres nye biler med CAN-BUS systemet i, og tænker ikke over det, før de oplever det samme.

I guder jeg savner min gamle Ford, der var hel-mekanisk og med ALB bremser, uden latterlig elektronik gøjl der kunne fejle.... og min gamle bil kan vel med god vilje sammen lignes med HEAT X1, og min 3år gamle Skoda med NASA'a fancy pancy rumfærger/Aux tank/booster rockets...

-bare en tanke, fra en der elsker at tænke -og i den grad ser frem til næste opsendelses forsøg, både fra NASA, ESA og fra CS (mest CS da de er mest funky ;-)

@Carsten kanstrup

På hvilken forlægning havde vi problemer ? ( Fakta: Den i hårdt vejr den 5. sep, ikke den debatten handlede om )

Havde vi ikke netop en 100 meter trosse mellem slæbebåden og
Sputnik ? ( Fakta: joh, vi gjorde nøjagtigt, som du skiver vi burde have gjort )

Du ved for lidt, vid noget mere, tak.

Du har skreget om windows indtil det blev dokumenteret at det var fri fantasi ?

Er det ikke lidt pinligt for dig ? Hvorfor snakker du ikke mere om windows nu ?

Synes du ikke du skulle tage og vide noget mere før du klager over manglende ditten eller datten ?

Hvordan synes du det er når det dokumenteres at vi for måneder siden gjorde ting sådan som du nu, måneder efter siger vi burde ?

Synes du ikke det virker som om du ved for lidt og udtaler dig på et mangelfuldt grundlag ?

Tag og vid noget mere tak, og husk, at hvis du ved så meget bedre hvordan alt bør gribes an - hvorfor er du så ikke allerede i kredsløb Carsten ?

Jeg er i hvertfald ved at gå orbit over en debat, hvor jeg er ganske sikker på at din drivkraft ikke er at se andet end hullerne i osten - vi er ikke perfekte - men vi gør med de midler vi har, det bedste vi kan.

Du er måske perfekt, og meget klogere - men så tag og lav dig en raket og gør det hurtigt, bedre, for færre penge. Sørg endelig for at opfylde alle normer, relevante som irrelevante og få den CE mærket. Så skal det nok gå hurtigt. Da vil dine argumenter gennem det gode eksempel, få megen større vægt.

Som det er nu virker det ikke konstruktivt.

Hvis du melder dig ind i raketvenner.dk kan du bidrage til at vi får mulighed for at gøre det bedre næste gang. Det er konstruktivt, og man kommer til at vide mere !

:O)

Men man må gerne være kritisk - men ordkløveri er bare spild af tid.
Og det er fint fint Carsten - kik ud til næste åbnet hus - så vil du komme til at vide mere !

;o)

Peter Madsen

Don't feed the troll

Don't feed the troll, tak :o)

Re: Windows og tålmodighed

Der var kun 2 launch-forsøg i alt. Men det tror du sikkert ikke på.

Jo selvfølgelig gør jeg det; men jeg taler ikke om launch-forsøg; men om kommunikationsforsøg, og her skal det eller de fejlslagne forsøg, der førte til genstarten, tælles med.

Vi i CS er ikke vidende om gentagne "kommunikationsforsøg". Vi havde ét tilfælde, hvor sequenceren ikke startede. Måske af så banal en grund, at knappen ikke var tilstrækkeligt nedtrykket. Efter ny nedtælling startede sequenceren, som den skulle.

@ Peter Madsen

Du har skreget om windows indtil det blev dokumenteret at det var fri fantasi ?

Er det ikke lidt pinligt for dig ? Hvorfor snakker du ikke mere om windows nu ?

Nej, det er ikke pinligt for mig. Det er faktisk mere pinligt for jer! Jeg skrev Windows, fordi det var det, pressen oplyste. Thomas Scherrer rettede det så til, at det i stedet var en microcontroller, der skulle genstartes - se hans kommentar:

Ja der blev genstartet sender systemet, som er microcontroller baseret

OK, jeg blev vildledt af pressen, og har så selvfølgelig ikke omtalt Windows sidenhen; men at det er jeres egen microcontroller, som det var nødvendigt at genstarte, er faktisk mere pinligt for jer, end hvis det var Windows! Windows eller microcontroller. Ja, du har ret. Ordkløveri er spild af tid!

Når jeg ikke allerede er i kredsløb, skyldes det, at jeg ikke lige har et par milliarder til at give Virgin Galactic baghjul, og som ingeniør synes jeg ikke, at det er så interessant ikke at være blandt de bedste. Desuden kunne jeg nok finde noget bedre at bruge et par milliarder på.

At jeg så ikke er medlem af CSS skyldes, at I og jeg vil gå i to forskellige retninger. I starten var jeg meget positiv og ville måske også have været en del af teamet, hvis jeg stadig boede i Københavnsområdet, og I kunne bruge mig (jeg er elektromekanikingeniør og iøvrigt radioamatør); men med et lodretstående, cylinderformet kapseldesign, som jeg aldrig har troet på, og nu en kopi af Apolloprogrammet og en sikkerhed for andre - og dermed for projektets fremtid (!), som jeg anser for helt ude i hampen, må jeg nok konstatere, at vores veje definitivt må skilles. Men derfor kan vi jo godt sige pænt goddag til hinanden på H.I. messen.

Hi

Carsten, det vil jeg se frem tid. Hvor på messen kan jeg finde dig ?

Peter Madsen

Re: Hi

Så vidt jeg ved, har I en stand i svejseafdelingen, hvor I bl.a. har kapslen med og holder foredrag, så jeg kommer forbi der (er der noget standnummer?). Er der nogen tidspunkter, hvor du ikke er på standen, eller nogle tidspunkter, der passer bedre end andre?

Microcontrolere skal genstartes...

Det er meget almindeligt, at microcontrolere skal genstartes... Naturligvis, så skyldes det som oftest støj, og manglende indskærmning. Men, det kan være næsten umuligt, at få skærmet en konstruktion godt nok - lednigner skal ind og ud, og der vil opsamles støj. Hvis der går kraftige strømme, så kan det medføre at microcontrolleren "hænger". Dette hænger naturligvis sammen med, at microcontrollerne ikke er udviklet til "seriøs" brug, og amerikanerne har indbygget et lille trik, for at forhindre det:

1. Når en microcontroller, har kørt et stykke tid, så vil de hænge. Når de hænger, vedbliver de at hænge, og må genstartes.
2. Ofte, kommer man ovenstående til livs, ved at sætte et ur på, som genstarter med jævne mellemrum - så man er sikker på, at det faktisk fungerer - når det skal. Eller, microcontrolleren genstartes så snart der sker noget - f.eks. en kritisk hændelse. Så er man sikker på den dur... Dette problem, har amerikanerne klaret, ved at lave microcontrollerne, så de i få tilfælde, ikke genstartes, når de resettes.
3. Dette problem, kan så klares ved, at microcontrolleren sender en "kode" ud til noget hardware, der vedbliver at genstarte dem, indtil de faktisk starter op. Og ikke hænger. Problemet har amerikanerne forudset, og derfor indlagt et system, som gør at mange genstarts, forholdsvis hurtigt efter hinanden, ikke vil fungere. I værste tilfælde, kan det gå ud over chippen, så genstart herefter bliver sværre, og sandsynligheden for at den kommer op efter genstart mindskes.

Der findes komponenter, der er beregnet til bilindustrien, som har lidt højere "pålidelighed" - formentligt, er de ikke perfekte, men sandsynligheden for at påvirkes af den såkaldte "støj" er lavere.

Alt, er selvfølgeligt, et resultat af, at amerikanerne er så hundeangst for at sælge elektronik der dur, da der er risiko for, at en "fjende" vil kunne bruge elektronikken til raketter!

Russerne fandt ud af, at problemet ikke opstod, når de brugte egenproducerede radiorør. Måske kan I finde nogle russiske radiorør på ebay. Så er problemet løst.


Anvender man en microcontroller, så er en god idé, at genstarte den, før en kritisk hændelse. Eventuelt have en timer (watch-dog timer), der resettes med nogle koder fra softwaren med jævne mellemrum, og hvis ikke, at den får disse koder, så genstarte automatisk. Som minimum, skal bruges et skift af et signal til watch'dog'en som kode, da det ikke må være noget der kan opstå af sig selv, f.eks. konstant høj eller lav. Dette kaldes en watch-dog. Normalt, øger det pålideligheden en del - men, som sagt, så er der taget højde for det. Så det er ikke helt perfekt.

Jeg ved ikke, hvilke tiltag som amerikanerne har gjort i forbindelse med FPGA'er. Måske, er en løsning, at anvende en CPU i en FPGA. Men, man skal her også være opmærksom på, at der sandsynligvis kan opstå fejl, og have et fejlkorrektionskredsløb. På en FPGA, er meget nemt, at lave hardwaren, så processoren automatisk genstartes, når der sker et skift, som der skal reageres på. Og man kan lave softwaren, således at værdier der huskes over en "reset" automatisk fejlrettes. Ingen tilstand, som lever videre, og skal huskes med sikkerhed, efter en reset, må være uden fejlkorrektion.

Dertil, skal man naturligvis forsøge at undgå støj. Er der støj, så vil der opstå problemet, næsten uanset hvor meget man gør ud af fejlkorrektioner. Fejlkorrektionerne, er kun til den støj, som kommer meget sjældent, og ikke håndteres. Hvis man logger en eventuel fejlkorrektion, så skal den helst aldrig ske. Den er beregnet, til at hånddtere problemet, som ikke må opstå - og forhåbentligt ikke opstår - med mindre man "tester" kredsløbet, for at se om det fungerer.

Der findes flere microcontrollere på markedet, som er beregnet til transport industrien. De er mere robuste overfor støj, og er måske mere egnet. Under alle omstændigheder, vil jeg dog anbefale en form for watch-dog, der automatisk genstarter, når der sker en fejl. Kredsen skal helst tjekke uafbrudt, at alt er som det skal være, og give besked til watch-dog'en, om at alt er ok. Hvis denne signalering mangler, skal watchdog''en lave en genstart. Og softwaren, skal være så robust, at den ikke fejler, selvom der sker fejl i registre, eller ramlager, i forbindelse med denne genstart. Det kan f.eks. ske med en sikker fejlkorrigering. Desto større del af ram'en, der accepteres er "ødelagt", desto bedre er fejlsikkerheden.

hovsa

stik den en lunte i stedet, nej stik den tre, det er rart med back up

Re: Microcontrolere skal genstartes...

@ Jens Madsen

Du har vist aldrig laver computerbaserede automatiksystemer, hvor hver genstart måske koster over 100.000 kr. og giver en meget sur værkfører! Man genstarter altså ikke lige styringen på f.eks. et kraftværk!

I en bil sidder der talrige microcomputere. Hvad tror du, der ville ske, hvis man genstartede dem med jævne mellemrum?

Hvis det er nødvendigt at genstarte en microcomputer, er systemet ganske simpelt laver forkert, eller man har ikke haft råd til f.eks. strålingshærdede processorer til high-altitude anvendelse. Det sidste kan blive et problem for CS, når de når 100 km højde, hvor strålingsniveauet er meget højere, og man derfor må regne med risiko for single-event upsets.

FPGA'er er helt klart at foretrække, hvis det er muligt, og de er baseret på antifuse eller Flash (ikke RAM) som dem fra Microsemi - tidligere Actel.

@jens madsen

Årsagen til to gange signal til HEAT er formentlig meget mere jordnær.

Der var indbygget en hel del sikkerhed i HEAT - sådan at den ikke kunne starte mens der var mennesker på Sputnik.

Det systemet gør er at HEAT skal have et signal gennem et stik på rampen som sige GO til dens egen elektronik. HEAT svarer gennem samme stik og vi få en både visuel og akustik besked om at HEAT vil starte om 60 sek.

Når systemet er startet responderer det på radiosignaler der vil stoppe motoren.

Fejlen vi så var banal. Stikket havde fået regn og salt, og gav os konstant problemer med dårlig forbindelse. Det betyder at det kan være ret svært at få HEAT igang - men når først den er igang er den let at stoppe.

Det er alt hvad der relevant for abort debatten.

Der var et par andre ting med rumskibets elektronik - som handler om dataopsamling - men som er irrelevant for adgangen til fri abort.

Vores overvejelser om nyt ventilløst design fjerner dette system - og gør det langt simplere. Sikkerheden for Sputnik crewet opnås i dette system ved at vi har en bøje i sikker afstand fra Sputnik - forbundet med et flydekabel - og heri samles tændkablet som er det eneste der kan starte HEAT. Abort systemet er uafhængigt - og kan dobles og tribles og alt muligt så det er urimeligt sikkert. Det er aldrig farligt for tat have en unødvendig abort - det koster bare missionen. Derfor kan abort systemet laves ret "triggerhappy" hvis det giver en større sikkerhed.

Men et er teknik.

Jeg ser hellere at vi få skaffet penge til at bygge den meget diskuterede FMLP, så vi kan rykke så langt væk fra alt at hele denne abortdebat bliver irrelevant.

At trænge ind til kernen af et problem, og fjerne kilde årsagen, er nogen gange meget sundere end at lægge lag på lag af sikkerhedssystemer udenpå¨hinanden.

Lidt ala kernekraft er sikkert nok - hvis bare det kun findes på månen.

jeg går og tænker over en smart metode til fremstilling af store kontant beløb hurtigt - så vi kan bygge og operere en FMLP der kan opsende fra havområder der ligger længere væk.

Tænk på at F.L. Smidt kan bygge en cement fabrik i langbordistan, så skulle vi vel nok også kunne operere 200 sm fra land.

Mvh.

Peter Madsen

Fornuften har sejret!

E-mail/blogs er langt fra altid gode til ophedede debatter, - der er ikke noget bedre loesning en face-to-face, - specielt vist det involverer to kolde fra kassen... ;-)

ingen beviser

>men at det er jeres egen microcontroller, som det var nødvendigt at >genstarte, er faktisk mere pinligt for jer, end hvis det var Windows! >Windows eller microcontroller. Ja, du har ret. Ordkløveri er spild af tid!

Der er faktisk ingen beviser på at denne genstartning var løsningen,
det kunne lige så godt have virket bare ved at tykke på start igen,
vi ved heller ikke om knappen rent faktisk blev trykket korrekt ned,
kun at KVB udtalte at den gav klick følelsen og at der for en sikkerhedsskyld blev trykket 2 gange på den lige efter hinanden,
sådan nogle forsøg har vi prøvet uendelige mange gange hjemme i HAB,
vi genbruger nemlig flight grej også til statiske tests og andre forsøg,
for på den måde at forsøge at opdage hvis noget evt skulle have "løse forbindelser" selv kabler er markeret og pakket ind i kasser med navne på,
så alt er testet og i orden.

Folk har deres ret til ikke at forstå projektet,
eller til at syndtes hvad de vil om det.
Men er meget velkommen til at lave en "jeg syndtes i er dumme blog"
man er også meget velkommen til at komme forbi og se det hele og stille
spørgsmål hvis man oprigtigt ønsker viden og indsigt.

Men som svar til vores blogs foretrækker jeg at folk kommer med konstruktiv kommentare, viden eller erfaring vi kan bruge til noget, frem for at forsøge på at latterlig gøre noget man ikke har sat sig ind i, desværre sker sådan noget på alle typer af forums/blogs, og det ender altid med at folk spilder hinandens tid.

Jeg skal hilse og sige at langt de fleste på ing kommer med gode inputs,
der er rigtigt meget vi har kunne bruge, så jeg håber i fortsætter.

Fodring af trolde er forbudt....

...men det vidste I vist godt i forvejen.

Re: windows

Nej, det er ikke pinligt for mig. Det er faktisk mere pinligt for jer! Jeg skrev Windows, fordi det var det, pressen oplyste. Thomas Scherrer rettede det så til, at det i stedet var en microcontroller, der skulle genstartes - se hans kommentar:

OK, jeg blev vildledt af pressen, og har så selvfølgelig ikke omtalt Windows sidenhen; men at det er jeres egen microcontroller, som det var nødvendigt at genstarte, er faktisk mere pinligt for jer, end hvis det var Windows!

Et enkelt indspark: Carsten, jeg tror ikke pressen har nævnt Windows på noget som helst tidspunkt. Jeg tror, det er noget som enten er opstået i hovedet på dig, eller alternativt, at du har taget en åbenlys joke lidt for seriøst fra en eller anden i din nærhed, der har sagt: "De skulle nok lige have genstartet windows, hehehe".

Det folk nok har lidt problemer med, det er at du holdt fast i det en tand for længe. Det burde ikke være nødvendigt for ham, der rent faktisk stod med dimsen, at sige mere end 1 gang, at Windows ikke var involveret.

Der er sikkert masser at hente i din viden og dine erfaringer, men det bliver spild af tid, hvis ikke du forsøger at formulere dig mindre nedladende. Så bliver svarene i samme stil, og vi ender med en mængde spild af tid for alle involverede. Og det er uanset om du har ret eller ej, eller hvor tåbeligt CS efter din mening opfører sig.

Jeg synes det er super fint, at kritikere er med på bloggen, og det er absolut heller ikke nødvendigt at have fløjelshandsker på, når man kommer med kritik. Bestemt ikke. Men det er nødvendigt at have respekt for projektet og den måde, som det er nød til at køre på, og det er nødvendigt at man forsøger at lave få faktuelle fejl (og undlade at gentage dem), og det er nødvendigt at undlade at være nedladende og bedrevidende, hvis man skal opnå noget som helst positivt resultat af debatten. Ellers så er det nok bedst, hvis man bare undlader at blande sig i debatten, og nøjes med at ryste overbærende på hovedet af det man har læst.

/Kristian

Re: windows

@ Kristian Hougaard

Det folk nok har lidt problemer med, det er at du holdt fast i det en tand for længe. Det burde ikke være nødvendigt for ham, der rent faktisk stod med dimsen, at sige mere end 1 gang, at Windows ikke var involveret.

Det var det da heller ikke. Så snart Thomas, som den første, havde fortalt, at det ikke var Windows, men en microcontroller, der blev genstartet, har jeg da ikke omtalt genstart af Windows siden - hvilket Peter så undrede sig over og kaldte pinligt.

Du har skreget om windows indtil det blev dokumenteret at det var fri fantasi ?

Er det ikke lidt pinligt for dig ? Hvorfor snakker du ikke mere om windows nu ?

For det første har jeg ikke *skreget* om noget som helst - kun omtalt det, og det var jo heller ikke fri fantasi, at et computersystem blev genstartet. Min eneste fejl var vel at kalde det Windows, for det var det, jeg hørte på affyringsdagen.

Hvor ville jeg dog ønske, at jeg havde de gamle lydfiler - både fra TV2 og fra den transmission, man kunne følge på et web-sted (måske ing.dk?). Jeg kan ikke huske på hvilket medie, det blev sagt; men hvorfor skulle jeg dog opfinde, at Windows skulle genstartes? Det kom faktisk som en overraskelse for mig, at systemet tilsyneladende var Windows baseret, hvilket det så heller ikke var.

PS.

@ Kristian Hougaard

Hvordan skulle jeg iøvrigt kunne vide, at et computersystem blev genstartet, hvis det ikke var sagt i pressen? Jeg er jo ikke synsk, og det er først nu i denne blog, at Thomas bekræfter, at det skete.

Genstart af Windows

En Google-søgning efter "raket genstarte windows" giver bl.a. en artikel på ingeniøren og en tv2-artikel, der henviser til ingeniør-artiklen.

Er det måske her, misforståelsen er startet?

Re: Genstart af Windows

En Google-søgning efter "raket genstarte windows" giver bl.a. en artikel på ingeniøren og en tv2-artikel, der henviser til ingeniør-artiklen.

Er det måske her, misforståelsen er startet?

Ja, det kan meget vel være det eller relateret til andre artikler på ing.dk:

Der var ingen forbindelse mellem Mission Control og rumskibet. Det blev imidlertid løst ved noget så simpelt som en genstart af Windows, skriver ing.dk.

Mange tak for din Google søgning :-)

tja...

en tredve fyrre indlæg oppe skriver jeg at man ikke kan bruge oplysninger fra pressen til noget.

Det skrev jeg også i dagene før opsendelsen.

Carsten har brug for nøjagtig en nøjagtig beskrivelse af systemet for at kunne vurdere det, og den elektriske / software mæssige side af sagen er kun sekundær - det er lige så vigtigt at vurdere de mekaniske komponenter og deres pålidelighed.

Endelig er det lidt illusorisk - systemet virkede og vil ikke blive brug igen. HEAT havde ikke fløjet ud af området unden abort, og havde den havde den stadig kun ramt tomt hav.

Kan man vurdere fremtidige raketter systemer ved at kikke på tidligere raketters systemer ?

Vi skal ikke være gode til at flyve 1X næste gang, vi skal være gode til at flyve 2X, og det er en helt anden maskine med helt andre systemer.

Er det ikke dem man bør forholde sig til ?

1X har fløjet, og, som de fleste andre løfteraketter er den endt på havets bund.

Carsten skal ikke være fornærmet - det er jo bare en debat, og den ville være meget bedre face to face.

Derfor glæder jeg mig til at hilse på Carsten på Hi Messen.

Peter Madsen

Peter's email

Peter, if you happen to spot this, or if anyone has a way to contact him other than email, the uc3nautilus email address was apparently compromised a few hours ago and has been sending out phishing attacks to everyone in the address book.

Peter´s email

Peter has by mail been informed about this problem, and given access to the countermeasures.

Uffe Ravn

Re: Microcontrolere skal genstartes...

Du har vist aldrig laver computerbaserede automatiksystemer, hvor hver genstart måske koster over 100.000 kr. og giver en meget sur værkfører! Man genstarter altså ikke lige styringen på f.eks. et kraftværk!

Jo, det er det man gør. Ofte genstarter computerne hele tiden. Man laver så programmet, så der udføres et lille stykke, mellem hver genstart. Sådan har man lavet mange industrielle computere i tidens løb. F.eks. PLC'er.

Det er ganske almindeligt, at computere til industrielt brug, indeholder en watchdog. Den står for, at lave en automatisk genstart.

Og, det er ikke ualmindeligt, at genstarte mellem 50 og 10.000 gange i sekundet. Så er man sikker på, at computeren er konstant genstartet. Programmet laves så, som en løkke, der gentages f.eks. 50 gange i sekundet - eller oftere. For hver genstart, sikres også, at de variable, der huskes mellem løkkerne fejlkorrigeres, således at eventuelle fejl, ikke får betydning for udførslen, selvom endog store dele af hukommelsen er korrupt.

Der findes mange løsninger - men jeg har aldrig hørt om et system, der anvendes industrielt, som ikke har en watch-dog. Hvordan den bruges, er så forskelligt. Også udstyr, der bruges til rumfart, laves ofte med en watch-dog.

Det kan være et problem, at lave koden, så den kører i en løkke konstant. En måde at løse det på, er at lave en fortolker. Genstartes, f.eks. 10.000 gange per sekund, og sikres at der kan udføres éen linie i et fortolket sprog, så kan man skrive programmer, uden at tænke på genstartene. I praksis behøver programmørerne derfor ikke at vide noget om det - da dem der laver fortolkeren gør arbejdet, med at lave en fejltollerant fortolker, der kører på en processor, som genstarter uafbrudt.

Som regel, laver man fortolkeren, så den automatisk genstarter, når den er færdig med en ordre, eller linie. Dertil genstartes den naturligvis af hardwaren, hvis en sådan genstart mangler. Og, programmet kan eventuelt også lave en "trap" i den fortolkede kode, så den ved, at der er opstået fejl.

Fordi at man hele tiden retter eventuelle fejl, for hver gang en kodelinie eller bare en enkelt ordre udføres, så kan man endog anvende almindelige processorer i rummet - også dynamisk ram. Der sker hele tiden fejlkorrigering, og hvis der opstår fejl, så opdages det, og den pågældende kode kører igen, hvis noget ikke er blevet færdigt. Det kan sikres, at det ikke er synligt udefra, ved at udføre koden i bidder, så den passer til inputs og outputs. Ofte, vil man have flere tasks, som kører, således at man tjekker koden, ved at udføre den dobbelt.

Kunsten til at undgå genstart, er at genstarte uafbrudt. Så længe, at du genstarter, så ved du, at alt er ok. Når genstart mangler - så er der et problem.

Mange industricomptuere, såsom PLC'er, har en løkke der køres igennem, og som kalder forskellige funktioner - også når det er eventdrevet kode. I næsten alle eventdrevne systemer, er der en kode, der stepper igennem forskellige liste, som angiver hvilke koder der skal udføres. Det betyder, at man i denne løkke, på praktisk vis, kan sikre at den udføres, og ellers genstartes så den kører. I lidt ældre PLC'er, fra før man lavede dem eventdrevne, kørte programmet i en stor løkke, der blev gentaget og gentaget. Det var med til, at gøre at de opnåede høj pålidelighed. Hvis noget gik galt, så blev systemet resat, og ingen opdagede det. Selvom en løkke ikke bliver helt færdig, og afbrydes midt i det hele af fejl, vil det som regel ikke få betydningen. Fejlen rettes ganske enkelt, ved næste gennemløb.

Idag, er det desværre ikke mere så populært at lave på den måde. Årsagen er, at programmørerne hedder C og C++. Og her er alt et helvede, blandt andet, fordi det ikke bygger på en fortolker. Java har her nogle fordele. Og i "gamle" dage, brugte man Basic. Det medfører også, at moderne elektronik, ikke mere er fejlrobust, fejltollerant, eller har ekstra bits, der sikrer mod fejl. Sikkerheden er for længst fjernet.

Måske virker det som om, at det var kedeligt og besværligt, at kode i "sikker" basic, eller en anden fortolket sprog. Men, man kan også have det, hvis noget er hastighedskritisk, så man har en fejlsikker kerne, der beror på fortolkning, og så "klisterer" maskinsprog på, eller oversat kode, og så kun overvåger programmet, og programmerer det kritiske i et fortolket sprog. Så skal man naturligvis kode det, så man tager hensyn til, at maskinkoden kan fejle - men, man opnår, at kunne skrive noget kode så det går hurtigt, og samtidigt har man en fejlsikker fortolker, der er baseret på, at det genstarter uafbrudt. Bruges denne måde, så er dog grænse for, hvor mange millisekunder, at et maskinsprogsprogram må tage - tager det mere end f.eks. 1ms, så vil det blive afbrudt af reset, og programmet vil lave en trap til en bestemt kode i fortolkeren, således at den ved, at programmet ikke er normalt afsluttet indenfor den millisekund, som maskinkoden må bruge. Er ikke muligt, at klare det, på den pågældende tid som er sat for genstart, så kan koden deles op i blokke. Der udføres så en lille del af gangen, ved at programmet bygges sammen af rutiner, som fortolkeren kalder. Opstår fejl, så køres fortolkerens fejlhåndteringskode, og det er altid muligt, at skrive "langsom" kode i fortolkeren, hvis hastigheden ikke er kritisk.

Fornuftige fortolkere, kan i øvrigt godt laves, så de har stor hastighed, og genstarter de automatisk, så snart en ordre er udført, så går det forholdsvis hurtigt. Normalt, vil man også genstarte før maskinkoder udføres, for at tillade den fulde tid mellem genstarts, til den pågældende kode.

Udover, at bruge watchdog's, og automatiske genstarts, så kan man også lave processorer der er fejltollerante, men det koster kassen, og er ikke hyldevarer endnu. Samtidigt, er de ofte dårligere, fordi at fejl kommer i klynger mv. og det kan software bedre tåle.

Re: Microcontrolere skal genstartes...

@ Jens Madsen

Jeg ved ikke, hvilken verden du stammer fra; men den eventdrevne, soft-PLC, som jeg i sin tid skrev til Søren T. Lyngsø's Stella automationssystem til brug i industri og skibe, var ialtfald ikke baseret på konstant genstart, og selv efter ca. 34 år i branchen kender jeg ikke ét eneste system, der er. Forveksler du ikke genstart med interrupt?

Hvis en watch-dog laver genstart, er det fordi den detekterer, at ét eller andet er gået galt! Den bruges absolut ikke til at lave konstant genstart.

Dette problem, har amerikanerne klaret, ved at lave microcontrollerne, så de i få tilfælde, ikke genstartes, når de resettes.
3. Dette problem, kan så klares ved, at microcontrolleren sender en "kode" ud til noget hardware, der vedbliver at genstarte dem, indtil de faktisk starter op. Og ikke hænger. Problemet har amerikanerne forudset, og derfor indlagt et system, som gør at mange genstarts, forholdsvis hurtigt efter hinanden, ikke vil fungere. I værste tilfælde, kan det gå ud over chippen, så genstart herefter bliver sværre, og sandsynligheden for at den kommer op efter genstart mindskes.

Alt, er selvfølgeligt, et resultat af, at amerikanerne er så hundeangst for at sælge elektronik der dur, da der er risiko for, at en "fjende" vil kunne bruge elektronikken til raketter!

Russerne fandt ud af, at problemet ikke opstod, når de brugte egenproducerede radiorør. Måske kan I finde nogle russiske radiorør på ebay. Så er problemet løst.

Der er så meget vrøvl i dette og dit seneste indlæg, at jeg ikke ved, om jeg skal grine eller græde. Jeg har netop været på seminar om sikkerhedscomputeren TMS570 fra det amerikanske firma Texas Instruments, og her har man gjort alt, hvad det er teknisk muligt for at gøre det så sikkert som overhovedet muligt. Processoren indeholder to CPU'er, som er spejlet og drejet i forhold til hinanden og forskudt i tid, så en single-event upset ikke rammer den samme instruktion i begge processorer samtidig. Speciel hardware overvåger konstant, at de to kerner er enige og genererer en non-maskable interrupt, hvis der detekteres en fejl. Processoren suppleres med ialtfald 2 ekstra kredse (en strømforsyning og en motordriver) i samme sikkerhedsklasse.

Ja, lav du en mikrocomputer med gamle russiske radiorør :-)

Re: Microcontrolere skal genstartes...

Jeg har netop været på seminar om sikkerhedscomputeren TMS570 fra det amerikanske firma Texas Instruments, og her har man gjort alt, hvad det er teknisk muligt for at gøre det så sikkert som overhovedet muligt. Processoren indeholder to CPU'er, som er spejlet og drejet i forhold til hinanden og forskudt i tid, så en single-event upset ikke rammer den samme instruktion i begge processorer samtidig. Speciel hardware overvåger konstant, at de to kerner er enige og genererer en non-maskable interrupt, hvis der detekteres en fejl. Processoren suppleres med ialtfald 2 ekstra kredse (en strømforsyning og en motordriver) i samme sikkerhedsklasse.

Det vigtige er, at du sender en kode til watch-dog'en, så den ikke genstarter, så længe den kører i hovedløkken. I så fald, virker det som den blev genstartet for hver gennemløb. Sker det ikke, så træder hardwaren til, og genstarter. Funktionen, er dermed omtrent den samme, som jeg skriver. Det som er pointen, er at du fanger en fejl, hvis støj medfører, at indstruktionspointeren løber et forkert sted hen. Du ved, at løkken gennemføres, for ellers får du reset.

Hvis man bruger interrupt - så er det NMI. Et interrupt, der kan disables, er ikke så egnet. Endnu, har jeg aldrig set en watch-dog, der er koblet på NMI.

Nogle har ikke en hovedløkke i programmet, og sender i stedet koder til watch-dog'en, forskellige steder i programmet - det er ikke så godt, da at kode så udmærket kan springes over, uden det opdages. En watch-dog, fungerer bedst, hvis der er en hovedløkke som gennemløbes, og den garanterer så gennemløbet af denne hovedløkke. En watch-dog, kan sagtens have en timeout, på under 1ms, så den er i stand til at sikre, at løkken gennemløbes mindst 1000 gange per sekund - eller mere, hvis timeout er kortere. Er det f.eks. en fortolkerløkke, så vil der ofte kunne garanteres 100.000 gennemløb per sekund eller højere.

At anvende to processorer, der kører tidsforskudt, har nogle fordele. F.eks. hvis hardwaren går i stykker, så er det en meget sikker løsning. Men, du kan også vælge, at have to tasks, der kører tidsforskudt i samme processor. Igen, kan dette "skjules" af en eventuel fortolkerkerne - eller en compiler. I forhold til et system med to processorer, så opnås ikke helt samme fejltollerance. Du opnår rettelse af fejl som opstår, også fejlretningen sker forskudt. Men, du får ikke en hardware redundans. I nogle tilfælde, kan et billigere redundant system, med to CPU'er, hvor der ikke er automatisk forskudt fejlretning, være bedre - fordi at hvis den ene CPU går i stykker, og du laver fejlretningen i software - så får du stadigt fejlretning, når der køres med kun én CPU. Problemet med hardware redundans, og problemet med fejlretning, deles så op i to, hvor fejlretningen klares i software, og hardwareredundansen i hardware. Det kan være bedre - og endog billigere i hardware.

Specielt ved små opgaver, der kræver meget lavt strømforbrug, og hvor hastigheden ikke er kritisk, bruges ofte en konstant frekvens til at vække CPU'en. Årsagen er, at du efter endt løkke, sender den i sleep-mode, og venter på signal fra watch-dog'en, der vækker, samtidigt med CPU'en resettes, og starter forfra.

Ved systemer, der kræver større processorkraft, og hvor strømforbrug betyder mindre, vil man normalt sende en kode til watch-dog'en, således den ikke resetter, og så manuelt lave et hop der svarer til genstart, således at det sikres løkken kører, og kun genstarte processoren, hvis signalet mangler til watch-dog'en. I princippet, er dog ingen større forskel. Det vigtige er, at programmet kan fortsætte, som intet var sket, og at fejlene rettes, selvom watch-dog'en må genstarte. En eventuelt genstart af watch-dog'en, er derfor normalt iberegnet timing analysen, så genstarten påvirker ikke systemets pålidelighed.

Re: Microcontrolere skal genstartes...

Specielt ved små opgaver, der kræver meget lavt strømforbrug, og hvor hastigheden ikke er kritisk, bruges ofte en konstant frekvens til at vække CPU'en. Årsagen er, at du efter endt løkke, sender den i sleep-mode, og venter på signal fra watch-dog'en, der vækker, samtidigt med CPU'en resettes, og starter forfra.

Det er også normalt, at genstarte andre former for hardware, et antal gange per sekund. Det kan være f.eks. sensorer, og behandling af data. Fidusen er, at hardwaren kører i sløjfre, og der opnås stor pålidelighed. Går nogle data tabt, vil de med stor sandsynlighed være korrekte, i de efterfølgende målinger. Sendes dataene med en repeterende protokol, opnås også stor pålidelighed, da funktionen fortsætter, når eventuelle kabelbrud, eller fejl på kablet er rettet. Og repeterende protokoller, tillader også fejlretninger.

Efterhånden som alle kører i C og C++, er det måske ikke moderne mere. Men, dengang man brugte fortolkere, da var det almindeligt, at der var en hovedløkke, hvor man resatte watchdog timeren, og således sikrede sig, at denne løkke konstant blev udført, samt der blev udført fejlretninger mv. i denne løkke, hvorved fortolkeren opnåede fejltollerans, på både kode, registre, og ram. Hvis watch-dog'en blev aktiveret, så fortsatte bare hovedløkken - evt. blev sat et flag, så programmet kunne udføre en trap, eller teste på et flag, der indikerede at der var lavet genstart, men ellers blev programmet ikke påvirket.

Re: Microcontrolere skal genstartes...

@ Jens Madsen

Endnu, har jeg aldrig set en watch-dog, der er koblet på NMI.

Så se lige TMS570, der har en meget avanceret watch-dog. Det er helt essentielt, at hvis der detekteres en uoverensstemmelse mellem de to processorkerner, må det interrupt, som skal behandle dette, ikke kunne disables.

Iøvrigt giver de to processorkerner ikke højere fejltolerance eller pålidelighed - tværtimod, for enhver fejl vil føre til en øjeblikkelig nedlukning. Det er imidlertid helt efter ICE 61508, som processoren er designet til. Fejl må godt opstå - bare de detekteres. Fejlkorrektion kan ikke bruges i sikkerhedssystemer, da man ikke kan garantere tilstrækkelig fejlretning. Hvis du f.eks. har tilstrækkelig checkbit til en Hamming afstand på 4, vil du normalt kunne detektere 3 fejl (og alle ulige fejl), men kun kunne rette én enkelt bit. Er det flere fejlbit end 3, har du derfor hverken sikkerhed for fejldetektering eller korrekt fejlretning.

Jeg forstår ikke, at du hele tiden skelner mellem fortolkere og C og C++. Hvad tror du fortolkeren selv er skrevet i? En fortolker er bare en overbygning, der f.eks. gør det muligt at interpretere PLC kode. Min eventdrevne soft-PLC var en fortolker.

Re: Microcontrolere skal genstartes...

Jeg forstår ikke, at du hele tiden skelner mellem fortolkere og C og C++. Hvad tror du fortolkeren selv er skrevet i? En fortolker er bare en overbygning, der f.eks. gør det muligt at interpretere PLC kode. Min eventdrevne soft-PLC var en fortolker.

Som regel, er selve kernen i en fortolker skrevet i højtoptimeret maskinkode. Idag er C og C++ compilere, dog blevet så gode, at de kan bruges. Men jeg mener ikke, at det er en god løsning, da du mister overblikket, over hvad der reelt foregår. I C og C++, kan det være svært at sikre, at du til enhver tid, kan ødelægge registre eller dele af programmet, og garantere at softwaren kan fortsætte, eller tage den korrekte beslutning, som følge af fejlen. Jeg mener, at det er bedst at programmere i maskinkode, og kerne koden til en fortolker, behøver ikke at være mega eller giga kode.

Det, som er fordelen i en fortolker, er at du har en fortolkerløkke, som gennemløbes uafbrudt. Og, at der er kun éen løkke. Det betyder, at du i denne løkke, kan have netop éen reset af watch-dog'en. Og at du kan garantere at denne kode udføres, og ellers genstarter watchdog'en processen. Du kan nemt lave fortolkeren, så den sikrer, at såvel registre, som brug af ram, er fejlsikker, og du kan lave den, så en genstart ikke har betydning for udførslen. Eller, du kan vælge, at kalde en handler funktion, hvis der opstår genstart på grund af fejl.

I nogle tilfælde, kan du godt foretage en meget sikker fejlretning, hvis du bruger bits nok. Du vil altid have brug for at lave en fejltjek på de værdier som bruges i dit program, så du kan sikre, at de ikke er muteret. Om du så vælger at rette fejl, eller aktivere en handler, som følge af en fejl, er op til programmøren. I mange tilfælde, er det mest sikre, at fortsætte, hvis det kan ske uden der er risiko for fejl. Typisk, vil man gentage indstruktionen, og sikre at den beregnes korrekt næste gang. Derfor, vil man hellerikke fortolke indstruktioner som y:=y+2, for så vil det gå galt, hvis de udføres to gange. I stedet, vil det blive delt op på indstruktioner som x:=y+2, efterfulgt af y:=x - på den måde, kan begge indstruktioner tåle, at udføres flere gange.

Det er korrekt, at du ikke kan lave en 100% sikker fejlretning. Men, du kan hellerikke med sikkerhed lave en detektion af, om noget er galt. Problemet er omtrent ens. Hvis du bruger bits nok, kan du lave en meget sikker fejlretning - og tilmed sige, med meget stor sikkerhed, om noget er gået galt. Bruger du ikke bits nok, f.eks. kun en paritetsbits, så vil mange fejl ikke detekteres. Laver du fejlretning, kræves flere bits, for at opnå samme sikkerhed, som hvis du kun detekterer fejl. Det, som er ulempen ved fejlretning, skyldes ikke problemet med at rette fejlene. Det kan med meget stor sikkerhed gøres, så det er korrekt. Og ellers, vil fejlen detekteres, og det håndteres som fejl. Det, som er problemet ved fejlretning, er at nogle lader det bero på fejlretning - således at støjproblemer ikke løses, men i stedet satses på, at fejlretningen klarer problemet. Og så er man ude på dybe vande. Derfor, så ingen fejlretning - tak. Men, det er faktisk bedst, når bare det ikke bliver udnyttet.

I mange tilfælde, kan du rette fejl sikkert. F.eks. hvis det er tale om en hardwarefejl, som en komponent der fejler. Så kan du roligt køre videre, med de resterende komponenter, såfremt at sikkerheden stadigt er tilstrækkeligt. Det betyder, at i stedet for, at stoppe motoren på en rumraket, et uheldigt sted under opsendelsen, så kan du vente med at rette fejlen, til du har landet på jorden.

Jeg går selv indfor både fejlretning, og detektering af, om fejlen kunne rettes sikkert. På den anden side, så mener jeg, at fejlretning kun er effektiv, hvis man tager den alvorlig. Som eksmpel, skal den medføre, at man kan køre sikkert videre, selvom en del af hardwaren ødelægges. Man skal kunne køre sikkert videre, ved en genstart - og genstarten må helst ikke påvirke systemet. Og ikke mindst - systemet må ikke bero på fejlretning, således at det gøres til en del af en løsning, for et dårligt design, f.eks. støj. I nogle tilfælde, hvis man ved hvad støjen skyldes, og kan beskrive eksakt hvornår den opstår, og at det kan løses med fejlretning - så kan det måske accepteres som en del af løsningen, hvis man har regnet på det, og kan stå inde for, at man har øget fejlretningen, således at den stadigt er sikker, på trods af det. Men, igen skal man passe på, at det ikke bliver en sovepude.

Re: Microcontrolere skal genstartes...

Typisk, vil man gentage indstruktionen, og sikre at den beregnes korrekt næste gang. Derfor, vil man hellerikke fortolke indstruktioner som y:=y+2, for så vil det gå galt, hvis de udføres to gange. I stedet, vil det blive delt op på indstruktioner som x:=y+2, efterfulgt af y:=x - på den måde, kan begge indstruktioner tåle, at udføres flere gange.

Mon ikke du skulle blive opdateret på hvordan moderne pipelinebaserede mikrocomputere virker og hvor meget, man f.eks. kan lave i én instruktion i f.eks. ARM arkitekturen?

Det er mig ubegribeligt, hvad der skulle kunne detektere, at noget går galt og så vende tilbage til den samme instruktion igen - ikke mindst i en pipelinebaseret computer, hvor man for længst er igang med den eller de næste instruktioner, når fejlen detekteres.

Re: Microcontrolere skal genstartes...

Typisk, vil man gentage indstruktionen, og sikre at den beregnes korrekt næste gang. Derfor, vil man hellerikke fortolke indstruktioner som y:=y+2, for så vil det gå galt, hvis de udføres to gange. I stedet, vil det blive delt op på indstruktioner som x:=y+2, efterfulgt af y:=x - på den måde, kan begge indstruktioner tåle, at udføres flere gange.

Mon ikke du skulle blive opdateret på hvordan moderne pipelinebaserede mikrocomputere virker og hvor meget, man f.eks. kan lave i én instruktion i f.eks. ARM arkitekturen?



Det er mig ubegribeligt, hvad der skulle kunne detektere, at noget går galt og så vende tilbage til den samme instruktion igen - ikke mindst i en pipelinebaseret computer, hvor man for længst er igang med den eller de næste instruktioner, når fejlen detekteres.

De nye pipelinede processorer, og processorer med cache, kræver et relativt stort antal indstruktioner ved genstart, og det betyder, at det aldrigt er så effektivt at genstarte. Imidlertid, er det ikke nødvendigt - vi skal bare have en løkke - vores fortolkerløkke - hvor vi resetter vores watch-dog timer, og så fungerer dette ligeså godt som en genstart.

Der findes mange måder, at tjekke på, om alt udføres korrekt. En er, at have to tasks der kører, og som skiftes ved f.eks. i/o indstruktioner. På den måde, udføres samme kode to gange, mellem hver i/o indstruktion. Laves en output, skal det derfor medføre to outputs, som er identiske. Ved inputs, er vigtigt, at begge tasks får samme værdi, så de skal synkroniseres. Denne metode, svarer meget godt til en processor, hvor du har tidsforsinket kontrol. Du kan også lave din fortolker (hvis det er fortolkerbaseret), så dine to tasks udføres på forskellig måde - f.eks. så data der gemmes i ram'en, og i registre er omvendte. Det er også muligt, at lave compilere, som producerer sådan kode. At processorerne er pipelined, behøver du ikke at tænke på - fra et softwaresynspunkt, gør de det samme. Og laves koden, så de ikke laver det samme - men det omvendte - så er stor sandsynlighed for, at opdage enhver fejl. Sansynligvis den samme, som i en processor, hvor det er integreret i hardware.

En processor, hvor det er integreret i hardware, har dog andre vigtige fordele. De ligger mest i, at de er lavet til stor pålidelighed.

Normale processorer, har som jeg tidligere har nævnt, indbygget adskillige faciliteter, der gør dem uegnet, til fornuftig brug. En af dem, er at man også har taget højde for anvendelsen af watch-dog. Altså, så findes en tilstand, hvor watch-dog'en hænger. Den aktiveres automatisk ved rumbrug, hvor der er stor kosmisk stråling. Det er ofte et krav, hvis kunderne til processorerne ikke skal igennem en vurdering, af hensyn til de amerikanske eksport krav.

Der, kan man så forsøge, at komme om ved problemet, f.eks. ved at måle strømforbruget, da der er tendens til, at denne stiger ved en sådan tilstand. Måles strømforbruget, og er det for stort, skal vi afbryde strømmen, og sætte den på igen. Så aktiverer vi dog, formentligt den forringede levetid. Også kredse, som er specielt sikre - sandsynligvis også din texas kreds - vil have en sådan "funktion", så den i bedste tilfælde ikke fungerer i rummet, og i værste tilfælde, brænder af. I nogle tilfælde, kan ekstremt støj, f.eks. fra switch-mode elektronik, og andet kraftigt støjende elektronik, aktivere samme funktion i kredsen, og så er ikke sikkert, at nogen NMI funktioner udføres. Skulle det ske, og sker det meget sjældent, og kun i ekstreme tilfælde, så kan man sætte noget eksternt logik på, der slukker for strømmen, og tænder igen. Typisk, vil man give ok signaler uafbrudt til en watch-dog, og mangler de, så slukkes strømmen, og lidt efter tændes igen. Det er også en fordel, at strømbegrænse konstruktionen, da der kan gå ekstrem-strømme, der levetidsbegrænser kredsløbet. I denne tilstand, er reset og NMI ikke nok.

Re: Fodring af trolde er forbudt....

Don't constipate the troll ;-)

Re: Fodring af trolde er forbudt....

@ Peter J. Hansen

Don't constipate the troll ;-)

Ja, ja, ja. Jeg ved ikke, om du er medlem af CSS; men hvis du er, kan du jo overveje, hvad der er billigst og giver mulighed for flest affyringsforsøg - at lave et fejlsikkert abortsystem og dermed kunne fortsætte med at skyde fra Bornholm - også selv om raketten vokser, eller at bygge en gigantisk FMLP og skyde fra den anden side af jordkloden!

"No bullshit, lets get it done" - CSS betaler.

Sikkerhed

Til jer alle:
Vi sætter sikkerheden meget højt. CS kommer aldrig til at omtale abort-systemer som værende "sikre". Men som det hele tiden har været vores intention, gør vi os konstant umage for at forbedre sikkerheden, hvor vi kan. Bl.a. ved udvikling af guidance- og abortsystemerne. Herunder vha. såvel transmission som on-board løsninger. Der er absolut intet nyt i vores holdning dér.

Re: Microcontrolere skal genstartes...

@ Jens Madsen

Normale processorer, har som jeg tidligere har nævnt, indbygget adskillige faciliteter, der gør dem uegnet, til fornuftig brug. En af dem, er at man også har taget højde for anvendelsen af watch-dog. Altså, så findes en tilstand, hvor watch-dog'en hænger. Den aktiveres automatisk ved rumbrug, hvor der er stor kosmisk stråling. Det er ofte et krav, hvis kunderne til processorerne ikke skal igennem en vurdering, af hensyn til de amerikanske eksport krav.

Du har skrever meget sludder, men den her tager vist prisen. At normale computere ikke er egnet til high-altitude anvendelse (luftfart og specielt rumfart) skyldes, at strålingsniveauet øges efterhånden som atmosfæren tyndes ud, hvilket fører til højere risiko for de såkaldte single-event upsets, hvor ladede partikler, der rammer ind under gaten, får transistoren til at skifte stilling. Derfor anbefaler jeg også CS at anvende FPGA'er fra Microsemi (antifuse eller flash) i stedet , da CS næppe har råd til strålingshærdede komponenter. At kredse oven i købet skulle kunne brænde af pga. single-event upsets er også ny for mig. Der skal meget højere strålingsdoser til.

Hvad er nok sikkerhed?

CS kommer aldrig til at omtale abort-systemer som værende "sikre".

Hvorfor egentlig ikke? Det behøver ikke at være en umulig eller specielt dyr opgave at nå til et niveau, hvor man med rette kan bruge den betegnelse. Hele sendesystemet og lag 1 (det fysisk lag) af OSI modellen på modtagesiden dvs antenne og modtager t.o.m. enkelte bit uden nogen speciel betydning, behøver ikke at ændres, bortset fra at senderen skal udsende dummy telegrammer, når den ikke laver andet, så det er muligt med en watch-dog på modtagesiden. Først herefter skal systemet dupleres eller triples; men har I én gang programmeret en FPGA til de øvrige lag i OSI modellen, er det jo bare at brænde 1-2 mere.

Hvor meget sikkerhed skal der egentlig til, for at det er nok, hvis andres liv kan være i fare, og hvornår kan man betegne noget som "sikkert"? Jeg er temmelig overbevist om, at Peters svar på det spørgsmål er temmelig forskellig fra svaret fra en pædagog, der har måttet fortælle et forældrepar, at deres barn desværre er død pga. et legeredskab, der ikke levede op til gældende lovgivning. Den eneste måde at undgå denne fuldstændig umulige diskussion er at leve op til en internationalt anerkendt standard, hvor niveauet er defineret. Derfor er standarder som f.eks. IEC 61508 faktisk en gave til raketbyggere og lignende!

Hvem har egentlig det juridiske ansvar og erstatningspligt, hvis raketten, når den bliver stor nok til det, rammer Bornholm, Sverige eller Tyskland og forvolder skade og evt død? Er det Thomas med sit abortsystem og fremtidige aktive styring, eller er det Peter og/eller Kristian? De fleste firmaer har en produktansvarsforsikring. Hvad med jer? CS har formodentlig ikke råd til en egentlig sikkerhedsgodkendelse; men kan man bevise, at man f.eks. lever op til IEC 61508 SIL 3, er det helt givet en meget formildende omstændighed, idet ingen så kan påstå, at man ikke har gjort alt, hvad der er rimeligt. Det gør det måske oven i købet muligt at tegne en ansvarsforsikring?

Jeg tror kun CS lever, så længe det er muligt at skyde fra områder ved Bornholm. Ellers skal I bygge en meget stor FMLP, skaffe mange mand, der vil bruge 14 dage på at sejle den frem og tilbage, sørge for hotelskib med besætning, forudsige vejret 1-2 uger frem i tiden og skabe live TV fra en helt umulig position (ellers kan I ikke bevare interessen). Pas nu på, at I ikke sætter det hele overstyr.

Re: Hvad er nok sikkerhed?

nu har du nej-hatten på igen

@Carsten Kanstrup

Jeg tror at du har overvurderet hvor meget support der behøves til et launch fra Rockall 350 km fra skotlands vestkyst.Denne position er blot en tilfældig valgt fordi at den kan findes via google.
En FMLP der bliver bugseret af den ombyggede Sputnik med opholds og launch faciliteter kan vel gøre det ud for et hotelskib og der skal vel bruges max 12 mand med 4 mand per skift til forlægning og affyring.Hvad angår TV transmission kan der bade skydes til en satellit fra FMPL(den er klippe stabil)
Hvort stort behovet er for RIB samt deres bemanding er ikke med i dette regnestykke.

Re: @Carsten Kanstrup

Afstanden fra København til Rockall er vel skønsmæssigt (google maps) omkring 1600 km dvs 864 sømil. Sputnik kan med den nuværende motorisering klare lige under 6 knob; men med en FMLP på slæb sikkert ikke mere end max 3 knob - husk at vi normalt har vestenvind. Det vi sige, at det vil tage omkring 1 måned at sejle den frem og tilbage plus lanch vindue, hvis vejret er for dårligt. 12 mand i 1 måned et ét mandeår. God fornøjelse :-)

Re: @Carsten Kanstrup

Du har jo ret Carsten - det kan ikke lade sig gøre! Og hvis du inden den første opsendelse havde påpeget alle de umuligheder der ville være ved forlægning til Bornholm, og launch fra en hjemmebrygget katamaran ville du også have haft ret. Men ikke desto mindre så lykkedes det jo jo over al forventning. En gang imellem er man nødt til at bare at se bort fra at det ikke kan gøres, og så gøre det alligevel. Det er denne egenskab ved Peter & Co at skide på hullerne i osten og så bare gøre det jeg beundrer allermest. Og jeg er 100% tryg ved deres praktiske og pragmatiske tilgang til sikkerhed.

Steen

Re: @Carsten Kanstrup

@ Steen Enevoldsen

Selvfølgelig kan det lade sig gøre at skyde langt fra beboede områder. Spørgsmålet er bare, om CS og CSS har ressourcerne til det?

Jeg har aldrig udtalt, at det ikke er muligt at skyde fra området ved Bornholm - heller ikke før første forsøg! Hvad med om du nøjes med at udtale dig om, hvad du selv mener, og ikke hvad du mener, jeg mener?

Re: @Carsten Kanstrup

Kan du give nogle svar på hvor disse midler så skal komme fra rent økonomisk end CS og CSS ?

Hvor ville CS så kunne affyre HEAT eller andre projekter henne end udenfor Spaceport Nexoe. ?

Venligst
Sune
CSS-medlem

Re: @Carsten Kanstrup

@Carsten Kanstrup

Hvis du så til gengæld lader være med at udtale dig om hvad du mener jeg mener, så er vi alle glade (hint: læg mærke til det lille ord 'hvis' i indlægget du besvarede).

Det er væsentlig nemmere at skyde raketprojektet ned, end det er at skyde raketten op.

Jeg synes helt ærligt du skulle glæde dig over at der stadig findes nogle mennesker i landet som tør bryde med sædvanen.

Man kan sagtens finde nogle iso'er eller andre normer som umuliggør det hele - Men husk nu på at dette projekt ikke er kommercielt - det er for hyggens skyld. Det er ikke meningen at vi skal gå og være triste over overholdelse af diverse mere eller mindre omfattende standarder samt ikke mindst dokumentionen af samme. Jeg har indtryk af at der er en overordentlig stor mængde sund fornuft og erfaring i CS - hvilket skulle være tilstrækkeligt

Iøvrigt prøv lige at overveje den reelle sandsynlighed for at raketten skulle kunne skade mennesker. Der er jo ikke tale om at de skyder fra Refshaleøen ind over København. Selv hvis den letter med forkert retning og alle abort systemer fejler så er der stadig meget lille sandsynlighed for at andet end CS's stolthed tager skade.

Hvis vi skulle til at forbyde alt det der kan gøre skade på mennesker så bliver her sgu ret kedeligt.

-Steen

Re: @Carsten Kanstrup

@ Steen Enevoldsen

Man kan sagtens finde nogle iso'er eller andre normer som umuliggør det hele

Det var jo så bare ikke lige det jeg skrev:

Det behøver ikke at være en umulig eller specielt dyr opgave at nå til et niveau, hvor man med rette kan bruge den betegnelse (sikkert)

@ Sune Jensen

Kan du give nogle svar på hvor disse midler så skal komme fra rent økonomisk end CS og CSS ?

Hvor ville CS så kunne affyre HEAT eller andre projekter henne end udenfor Spaceport Nexoe. ?

Ikke helt forstået. Er det mig eller Steen Enevoldsen, du henvender dig til? Som jeg skrev, ser JEG ikke anden realistisk mulighed end Spaceport Nexoe.

Ørsted Satellitten ...

Ørsted er proppet med "plastic"-indpakkede COTS komponenter der aldrig har været "space-qualified". Det fungerede jo meget godt, endda meget længere end nogen på Terma troede. Som regel er det simplere at have en praktisk tilgang til tingene og prøve noget efter i stedet for at teoretisere over alle mulige bizarre grænsetilfælde.

http://ing.dk/artikel/11473-oe...eren

Re: @Carsten Kanstrup

Det var jo så bare ikke lige det jeg skrev:

Det behøver ikke at være en umulig eller specielt dyr opgave at nå til et niveau, hvor man med rette kan bruge den betegnelse (sikkert)

Og hvad er problemet så? CS tager sikkerheden meget alvorligt, og har behandlet sikkerhedsmæssige emner mange gange i de forløbne blogs. google site:ing.dk cs sikkerhed giver over 500 hits så det er da et emne der har været ivrigt diskuteret.

Var det ikke dig der begyndte at vifte med IEC 61508 ?

Re: @ Sune Jensen

Kan du give nogle svar på hvor disse midler så skal komme fra rent økonomisk end CS og CSS ?

Hvor ville CS så kunne affyre HEAT eller andre projekter henne end udenfor Spaceport Nexoe. ?

Ikke helt forstået. Er det mig eller Steen Enevoldsen, du henvender dig til? Som jeg skrev, ser JEG ikke anden realistisk mulighed end Spaceport Nexoe.

Hvilket jeg er helt enig i. Det var dig der begyndte at mene at det skulle foregå på den anden side af jorden.

-Steen

Rockall

Som jeg skrev er det fordi at det kan findes via google og wiki.
et punkt som 56° 32.248'N 4° 48.704'Ø er 200 km syd for norge og 200 km vest for vestkysten.
der er nogle få offshore platforme inden for ca 30 km, men de kan undgås ved planlægning.
Ved et suborbital skud vil 200 km fra beboet område i min lommer bog være helt sikkert.
Det er ca samme afstand fra Esbjerg som HAB til Nexø.
Om der kan skydes orbitalt med en østlig kurs er jeg også sikker på kan lade sig gøre, over 300.000 fod er det rumfarts reglerne der gælder.
Vær lidt realist og erkend at det er farligt at leve,IEC 61508 SIL 3 er garanteret ikke implementeret i automobil soft/hardware, og alligevel køre der 1.000.000 mennesker rundt hver dag og satser deres liv og helbred på ting der ikke er garanteret en MTBF på 10.000.000 timer.Jeg vil hellere tage en tur i et CS bygget rumfartøj end flyve med SAS, eller køre med IC3

Re: @ Sune Jensen

@ Steen Enevoldsen

Kan du give nogle svar på hvor disse midler så skal komme fra rent økonomisk end CS og CSS ?

Hvor ville CS så kunne affyre HEAT eller andre projekter henne end udenfor Spaceport Nexoe. ?

Ikke helt forstået. Er det mig eller Steen Enevoldsen, du henvender dig til? Som jeg skrev, ser JEG ikke anden realistisk mulighed end Spaceport Nexoe.

Hvilket jeg er helt enig i. Det var dig der begyndte at mene at det skulle foregå på den anden side af jorden.

-Steen

Hvor i alverden har jeg skrevet det? Jeg har aldrig anset andet end Spaceport Nexoe for realistisk.

@ Tommy Johansson

Vær lidt realist og erkend at det er farligt at leve,IEC 61508 SIL 3 er garanteret ikke implementeret i automobil soft/hardware, og alligevel køre der 1.000.000 mennesker rundt hver dag og satser deres liv og helbred på ting der ikke er garanteret en MTBF på 10.000.000 timer.Jeg vil hellere tage en tur i et CS bygget rumfartøj end flyve med SAS, eller køre med IC3

TMS570 fra TI, som netop er dedikeret stort set udelukkende til bilbrug (elektrisk servo styring), er designet ud fra IEC 61508 SIL 3, så måske skulle du være lidt mere varsom med garantierne. Hvem snakker iøvrigt om en MTBF på 10.000.000 timer? Det er MTTF for udetekterede fejl, der er afgørende, så MTBF kan være mange gange mindre.

Re: @Carsten Kanstrup

@ Steen Enevoldsen

Det var jo så bare ikke lige det jeg skrev:

Det behøver ikke at være en umulig eller specielt dyr opgave at nå til et niveau, hvor man med rette kan bruge den betegnelse (sikkert)

Og hvad er problemet så? CS tager sikkerheden meget alvorligt, og har behandlet sikkerhedsmæssige emner mange gange i de forløbne blogs. google site:ing.dk cs sikkerhed giver over 500 hits så det er da et emne der har været ivrigt diskuteret.

Var det ikke dig der begyndte at vifte med IEC 61508 ?

Ja, CS og specielt Peter har blogget meget om det at tage en stor risiko for til gengæld at "leve". Lev stærkt, dø ung. Det skal nok indgyde tillid :-)

Jo, det var mig, der begyndte at vifte med IEC 61508, fordi det er den eneste professionelle og ingeniørmæssige måde at angribe problemet på, så man undgår diskusionen om, hvornår noget er sikkert nok!

Re: Ørsted Satellitten ...

Ørsted er proppet med "plastic"-indpakkede COTS komponenter der aldrig har været "space-qualified". Det fungerede jo meget godt, endda meget længere end nogen på Terma troede. Som regel er det simplere at have en praktisk tilgang til tingene og prøve noget efter i stedet for at teoretisere over alle mulige bizarre grænsetilfælde.

http://ing.dk/artikel/11473-oe...eren

Denne artikel viser meget godt, hvordan professionelle folk arbejder. Enten bruger man komponenter, som man på forhånd ved egner sig til opgaven dvs. "space-qualified" eller FPGA'er, som på grund af deres konstruktion er strålingstolerante (Microsemi), eller også tester man sig ud af problemet med protonacceleratorer og lignende.

Jeg håber, at CS agter at gøre ligeså mht. abortsystemet, når man kommer op i højder, hvor det for alvor kan blive et problem.

Re: @Carsten Kanstrup

"Ja, CS og specielt Peter har blogget meget om det at tage en stor risiko for til gengæld at "leve". Lev stærkt, dø ung. Det skal nok indgyde tillid"

Det mener jeg nu ikke Peter har skrevet. Han har skrevet om, at han er klar over der er en risiko.

Re: @Carsten Kanstrup

@ Thomas Hansen

"Ja, CS og specielt Peter har blogget meget om det at tage en stor risiko for til gengæld at "leve". Lev stærkt, dø ung. Det skal nok indgyde tillid"

Det mener jeg nu ikke Peter har skrevet. Han har skrevet om, at han er klar over der er en risiko.

Så se lige disse blogs:
http://ing.dk/artikel/121402-p...ddag
http://ing.dk/artikel/120997-s...3542

@Carsten Kanstrup

Tjaa hvor mange biler ud af ca ½ miliard er certificeret til IEC 61508,og hvor mange fly ,skibe,metrobaner osv er på nuværende tidspunkt?
Min påstand er at vi stadig lever et farligt liv til hverdag, og endnu ikke et :"Design it,calculate it, simulate it, before living it" liv.
Mange af de fejl der sker i nutidens konstruktioner er en følge af at virkeligheden altid har en overraskelse i baghånd som kræver en rimelig sikkerheds margen.Den der var i sidste århundrede var skabt af sund fornuft og ikke beregnet ud fra nogle optimale styrkedata.Jeg vil hellere stole på at en sikkerheds margen er dobbelt så stor ud fra sund fornuft , som at beregne den værst tænkelige og sætte den som standart. Logisk tænkning og sund fornuft er bedre end design to cost.

tid

jeg håber ikke peter bruger for megen tid her

Opfyldelse af standarder

@ Tommy Johansson

Tjaa hvor mange biler ud af ca ½ miliard er certificeret til IEC 61508,og hvor mange fly ,skibe,metrobaner osv er på nuværende tidspunkt?

TMS570 er som komponent certificeret efter IEC 61508; men biler, fly og jernbaner har som product deres egne sikkerhedsstandarder, som de til gengæld alle opfylder 100% (ialtfald når de forlader fabrikken). IEC 61508 bruges typisk på de områder, hvor der ikke findes en dedikeret standard.

@Kurt

Hej Kurt,


Det gør jeg faktisk ikke. Debatten her er kørt helt af sporet og er tidspilde for alle involverede. Hvis Carstens drivkraft er et ønske om sikre raketter spilder han sin tid ved at skrive her - hvis hans drivkraft er et ønske om at være en modkraft til den optimisme og glæde der eller præger debatten her - er det måske meget effektivt.

Carsten kunne for længe siden have skrevet til os - via mail - og derved sparet resten af landet for at høre om IEC 61508 SIL 3.

Jeg tror hans motivation for længe siden er skiftet fra ønsket om at hjælpe CS til ønsket om at få respons. Han er ikke en fornuftens stemme, hvis lyttet til kan man ikke lave noget nyt her i verden.

I stedet har han opnået at lave et debatspor som kan få uindviede til at tro vi er helt på vildspor uden hans visdom. Det er ikke tilfældet. Vi operer i meget høj grad efter de samme principper som f.eks. bruges
på Andoya Rocket Range og ESA´s Esrange i nordsverige.

Ved Carsten at

A. Der ligger et fiskerleje få kilometer fra ARR´s rampe ?

B. At de fleste raketter fra ARR intet abort system har og ikke kan stoppes når først de er startet ?

C. Det er normen for sonderaketter - ikke IEC 61508 SIL 3.

D. Andoyas raketter når op til 2000 km højde og styrter ned i Norske Havet. Ud over tæt ved basen er havet ikke ryddet skibstrafik.

ARR har gennem årene opsendt tusinder af raketter ud over havet uden at ramme nogen.

Vi har - en gang imellem - nogen i røret eller på besøg som i bedste mening prøver at hjælpe os - men som ikke har noget som vi rigtigt kan bruge. Det gælder f.eks. IEC 61508 SIL 3.

Jeg kunne godt frygte at såden en debattråd kunne være forlig for vores eksistens - vi lever jo trods alt af at embedsmænd er udrustet med sund fornuft og ikke kikker i IEC 61508 SIL 3 når et konkredt problem skal løses i den virkelige verden. F.eks. kan man skele til
ARR´s praksis når man konkredt skal vurdere den slags.

Jeg tror det bedste er hvis man ikke giver nogen respons her - så dør det måske ud.

Jeg kan love en ting - uanset hvordan vi opererer i fremtiden - så vil vi som i juni 2011 sikre os at der er rigtigt godt styr på sikkerheden omkring vores aktiviteter.

Vi kan, og vi skal altid kunne, tage en debat også om ubehagelige emner - men der må være en grænse.

Dette uanset indholdet af IEC 61508 SIL 3 som jeg er ufatteligt træt af at høre om.

Jeg pakker til turen til Herning og HI messen og håber at slippe for mere IEC 61508 SIL 3.

Peter Madsen

N.B. Gad vide hvad så IEC 61508 SIL 4 dækker over ?

hej peter

egentlig var det ikke en kommentar til dig peter ;O)
men en separat tråd om standarters relevans ville være skønt

@ Peter Madsen

Dette uanset indholdet af IEC 61508 SIL 3 som jeg er ufatteligt træt af at høre om.

Jeg pakker til turen til Herning og HI messen og håber at slippe for mere IEC 61508 SIL 3.

Peter Madsen

N.B. Gad vide hvad så IEC 61508 SIL 4 dækker over ?

Så kan vi jo lige så godt aflyse vores møde på H.I. messen.

SIL 4 dækker iøvrigt over mulig massedød som f.eks. kan forekomme ved nedsmeltning af atomkraftværker.

@Carsten Kanstrup

At kredse oven i købet skulle kunne brænde af pga. single-event upsets er også ny for mig. Der skal meget højere strålingsdoser til.

Der kan ske så meget, når kredsene udsættes for stråling. I nogle tilfælde, vil kredsene tage gradvis skade. I andre, kan opstå effekter, der får kredsen til at brænde af - f.eks. latch-up. Selvom kredsene er sikrede mod latch-up, kan det ske, når de udsættes for stråling. For at undgå sådanne problemer, skal kredsene være specielt lavet til det, og f.eks. have modstande og strømbegrænsere, og kondensatorer på chippen, således at strømmene ikke kan blive for voldsomme, og at strømmen ikke kan opholde tilstanden. Der findes designstandarder, som skal opfyldes til rumbrug - men det er ikke altid man gør det. F.eks. havde ørsted sattelitten en 486'er om bord og dynamisk ram. Her, var softwaren så skrevet til at være ekstra robust, og rettede f.eks. automatisk fejl der opstod i programlageret, i cpuens registre og programtæller, og den dynamiske ram. Man kan også bruge FPGA'er, som reprogrammerer sig selv, eller bruger andre dele, hvis dele af den bliver deffekt.

Standarder, og sikkerhed er en god ting. Men, ved en raket, er det meget andet som betyder noget, end den "elektroniske" sikkerhed. Elektronikken, skal kun fungere i ganske kort tid, og sandsynligheden for en fejl er lav. De fejl som opstår, skyldes fysiske problemer, såsom mekanisk påvirkning, kontakter, fugt osv. Og i tilfældet her, er vi langt fra van allen bæltet - og dosen som elektronikken udsættes for, er lav.

Den måde, som Thomas Scherrer har lavet elektronikken - med flere processorer, der kører i sløjfe, lyder også til at være en god løsning. Naturligvis, vil jeg altid foretrække, hvis der i sløjen er en clear watcdog, og at en watch-dog genopstarter løkken, hvis indstruktionspointeren skulle løbe løbsk. Man kan også fylde hele programlageret op med jumps til løkkens kode, så der tages højde for, hvis programtælleren skulle hoppe ud af den. Måske springes nogle indstruktioner over, men i nogle tilfælde, vil det intet betyde for funktionen.

Det vigtige er, at softwaren er uden fejl, og muligt at teste. Risikoen for en softwarefejl, er større end en hardwarefejl, hvis ellers hardwaren er designet i orden. Og for hardware, er større risiko for dårlige stik der vrister sig fra hinanden, ledninger der påvirkes mekanisk, fugt, osv. end for en hardwarefejl, hvor en bedre processor, havde gjort underværker.

Selv i sattelitter bruges kommercielt DRAM og 486. Og det holder.

Ved kompliceret software, er det vigtige at kunne garantere at softwaren fungerer. Dette har vist sig for komplicerede ting, at være mere svært, end at få hardwaren til at fungere. Naturligvis, så tror jeg, at det skyldes at hardwarefolkene er dygtigere end softwarefolk. Indenfor hardware, har man styr på tingene. Netop det, er det som glipper i softwareindustrien.

Re: @Carsten Kanstrup

Indenfor hardware, har man styr på tingene. Netop det, er det som glipper i softwareindustrien.

Software har langt mere varians end hardware: Man kan jo skrue een byte sammen på 256 måder og få, ingen eller alle "måder" er korrekt, afhængigt af kontekst.
Rigtigt meget software er lavet til en fast pris og en bestemt deadline. Når een af betingelserne Pris eller Deadline opnås er softwaren færdig :)

Re: @Carsten Kanstrup

Rigtigt meget software er lavet til en fast pris og en bestemt deadline. Når een af betingelserne Pris eller Deadline opnås er softwaren færdig :)

Ja, det er korrekt. Indenfor hardware, går man ofte dem ovendte vej - og har en god idé, som man så bygger et produkt ud af. Det betyder, at tingene er sat sammen så det fungerer. Næsten alt, indenfor hardware, er "komponenter", hvor bred den brede anvendelse, er den man satser på - fremfor specifik anvendelse, til en enkelt opgave. For mange år siden, lavede man ASIC's, men igen - så har kredse til general anvendelse, f.eks. FPGA'er, erstattet ASIC's. Så man laver først ASIC's når det skal være småt, og så er det afprøvet grundigt først i FPGA's. Fidusen i hardware, er at man interesserer sig for at udvikle komponenter, der er robuste, gode og som fungerer. Det er virksomhedens eksistensopgave. Software er det modsatte - programmering på kontrakt. Og det fungerer normalt ikke, for det er upålideligt. Og som regel, tager det meget længere tid. For man har ikke nogle komponenter der fungerer indenfor softwarebranchen. Og selvom det findes, så er beslutning 1, at det skal bygge på Microsoft ... osv. Og så har man besluttet sig for en anden vej.

Hardwarefolket, har altid bygget op på komponenter der fungerer. Indtil man når "toppen", hvor så lidt som muligt så tilrettes produktet. Inden for software, starter man forfra hver gang man får en opgave - og der findes intet marked for komponenter der fungerer.

Hvis softwarefolket skulle opbygge deres software på komponenter der eksisterede - og som fungerede - så kunne de ikke nå langt. For de har ingen komponenter.

Det svarer til, hvis hardwarebranchen gik over til, at kun lave komponenter på bestilling, og til den enkelte kunder. Måske, med en teoretisk mulighed for - hvis de må - at kunne genbruge nogle skruer, som de har lavet til en anden komponent.

Var det skruebranchen, var vi alle fortabte. Skruer fremstilles efter mål, og så gevindet er drejet, til den pågældende opgave. Ellers kan det ikke fungere. Det grundlæggende mangler. Og samtidigt laves alt på tid.

Der findes nogle få genialiteter indenfor softwareområdet, f.eks. regneark. Et regneark, kan løse mange opgaver, og er en general ting, der ikke er lavet til et helt bestemt formål. Men, der er ikke et marked, for pålidelige softwarekomponenter, hvor der følger bevis med for at det fungerer, og som virker med garanti. Typisk, vil softwarebranchen hævde, at det ikke er muligt, for vores område, er ih så advanceret, at det kan man naturligvis ikke. Men sandheden er, at man gør det advanceret, for at det ikke skal være muligt. Og at man undlader beviser, fordi det ikke kan bevises (altså, det vil fejle et bevis).

@Jens

Gisp en omgang vås. Jeg håber ikke du har fingre i hverken HW eller SW i den raket.

Omvendt hvis du har, så letter den nok aldrig og Carsten og os andre behøver ikke spekulere på sikkerhed.

Re: @Jens

Gisp en omgang vås. Jeg håber ikke du har fingre i hverken HW eller SW i den raket.

Omvendt hvis du har, så letter den nok aldrig og Carsten og os andre behøver ikke spekulere på sikkerhed.

Enig, han har åbenbart aldrig hørt om C++ stdlib eller CPAN (indsæt selv flere for andre sprog end C++ og Perl) hvis han mener at man aldrig genbruger ting man ved virker.....

Re: @Jens

Gisp en omgang vås. Jeg håber ikke du har fingre i hverken HW eller SW i den raket.



Omvendt hvis du har, så letter den nok aldrig og Carsten og os andre behøver ikke spekulere på sikkerhed.

Enig, han har åbenbart aldrig hørt om C++ stdlib eller CPAN (indsæt selv flere for andre sprog end C++ og Perl) hvis han mener at man aldrig genbruger ting man ved virker.....

Jeg sagde ikke, at man ikke genbrugte kode. Men problemet er ikke genbrug af kode - det er hele softwareområdet som er "sygt", med mindre, at du udvikler elektronik til transport, space, eller visse dele af industrien.

Man genbruger masser af kode, som man "mener" virker. Men, der er intet bevis. Først starter man med et operativsystem, som er defekt. Så bruger man en compiler, med indbyggede bugs. Og herefter skriver man et program, der ikke fungerer sikkert. Men, for enhver softwaremand "mener" at det fungerer.

Jeg har arbejdet, i en virksomhed, hvor vi brugte Java - for det skulle da fungere... Du fatter ikke hvor mange fejl, at der var i sun's java. Kan noget være mere usikkert?

@Jens

Er du nu sikker på at det var Sun's skyld at koden ikke virkede ????

Debatører om software

Jeg er ikke software-ingeniør eller nørd indenfor dette område
Men der er vist nogle er som kan bruges i Copenhagen Suborbitals Softwaregruppe for at få opdateret eller forbedret teknologien

P.M. har vist også masser og lave de næste mange dage på HI-messen i Herning.

Re: @Jens

Jeg tror, at Thomas Scherrer har gjort et udmærket arbejde, og at det ikke er softwaren som fejler. Hverken Windows CE, C++, eller JAVA, vil kunne løse noget problem. Faktisk tror jeg, at jeg kunne finde på at gøre det på samme måde som ham. Eneste, jeg vil gøre derudover, er måske at bruge en watch-dog (hvis han ikke har gjort det), og udfylde hukommelsen med jumps der går til et sted i koden, således funktionen fortsætter, uanset IP pointeren skulle hoppe et forkert sted hen, på grund af støj, som alligevel ikke må forekomme, og forhåbentligt ikke kommer. Men, under alle omstændigheder, tror jeg ikke, at fejlene findes i softwaren. Jeg er mere nervøs for, om der kan smutte kraftigt elektrisk støj ind af nogle ledninger og forstyre mikrocontrollerne. Dette skal naturligvis helst løses, f.eks. med modstande i ledningerne, optokoblere på ind og udgange osv. Hvis, at der altså er problemer. Indtil videre, har intet dog overbevist mig om, at der er noget problem. Men ellers er løsningen naturligvis et bedre elektrisk design, fremfor f.eks. watch-dogs, og "software løsninger".

Derudover, er det også vigtigt, at det virker med fugt, kulde, rystelser osv. Jeg tror, at der er større risiko for den type fejl, end for fejl i softwaren - også fordi, at den metode han har valgt, burde være forholdsvis nemt at garantere fungere.

Determinisme

Når der anvendes 6 CPU'er, som måske kommunikere med hinanden, så er systemet ikke deterministisk, med mindre at processorerne kører på samme klok, og resettes samtidigt. Et nemt system kunne resette processorerne forholdsvis ofte - f.eks. når de alle er kommet igennem løkken, eller hvis der går for lang tid, således at de hele tiden kører synkront, og i samme løkke. På den måde sikres deterministisk funktion, da det vil ske det samme ved hvert gennemløb. I mange tilfælde, er periodisk software, nemmere at håndtere.

Deterministisk funktion er ikke decideret nødvendigt, for at få ting til at fungere, men det bliver oftest nemmere at teste. Er det ikke deterministisk, skal i princippet tages højde for enhver forsinkelse imellem systemerne, som skyldes at de ikke er synkron med hinanden. Hvis tingene er designet til, at være forsinkelsesuafhængigt (og det findes der regler for), så kan det godt fungere, selvom det ikke er deterministisk. Funktionen, vil alligevel være deterministisk, da systemet sikrer det - hvis det overholdes. Desværre, så er det ikke almindeligt, at softwarefolk designer parallelisme til at fungere forsinkelsesuafhængigt - og programmeringssprog som C og Java lægger ikke op til det. Når det ikke er designet til forsinkelsesuafhængighed, så ses af parallelismen medfører indeterminisme - også i resultatet - f.eks. ses det i Windows OS, hvor at tingene der sker, kan afhænge af rækkefølgen som det tilfældigvis udføres under opstart. Den slags, er umuligt, når der bruges reglerne for forsinkelsesuafhængighed. Jeg plejer at sige, at der findes parallel programmeringssprog, som windows ikke kan programmeres i, med mindre der lægges tilfældighedsfunktioner i.

Re: @Jens

Jeg er mere nervøs for, om der kan smutte kraftigt elektrisk støj ind af nogle ledninger og forstyre mikrocontrollerne. Dette skal naturligvis helst løses, f.eks. med modstande i ledningerne, optokoblere på ind og udgange osv. Hvis, at der altså er problemer.

Med et ben i begge lejre (HW/SW-design), så forekommer det mig at man i begge discipliner skal genbruge designs, bruge sin intuition og gennem erfaring akkumulerede tommelfingerregler, når man skal skrue en ny løsning sammen.

Ligeledes hænger man i begge verdener på ens teknologivalg. HW-drengene er begrænset af prototypeproduktions- og testomkostninger, SW-drengene er (f.eks i IT) begrænset af den platform de udvikler til, som er svær at skifte, når man først har været ude og swipe det store kreditkort hos Oracle, Netezza, IBM eller andre.

Re: @Jens

Jeg er mere nervøs for, om der kan smutte kraftigt elektrisk støj ind af nogle ledninger og forstyre mikrocontrollerne. Dette skal naturligvis helst løses, f.eks. med modstande i ledningerne, optokoblere på ind og udgange osv. Hvis, at der altså er problemer.

Med et ben i begge lejre (HW/SW-design), så forekommer det mig at man i begge discipliner skal genbruge designs, bruge sin intuition og gennem erfaring akkumulerede tommelfingerregler, når man skal skrue en ny løsning sammen.



Ligeledes hænger man i begge verdener på ens teknologivalg. HW-drengene er begrænset af prototypeproduktions- og testomkostninger, SW-drengene er (f.eks i IT) begrænset af den platform de udvikler til, som er svær at skifte, når man først har været ude og swipe det store kreditkort hos Oracle, Netezza, IBM eller andre.

Ja, men når du indenfor software, netop har fået løst problemerne ved hjælp af work-arounds, så kommer en opgradering, så det ikke mere fungerer. Fordi, at softwaren er rettet... Og nu kan du så lave det hele om igen, og må rette alt endnu engang, fordi der er nye fejl, der skal work-aroundes. Software er designet til at være ustabil - og ellers, vil der komme en upgrade, der nok skal få det ustabilt.

Sådan er det ikke indenfor HW. Der virker tingene - og de vedbliver at fungere. Man laver det så det fungerer.

Efter min opfattelse, så mangler der forskere indenfor SW. Der er alt for mange, som producerer på livet løs. Og alt for få der forsker. Jeg havde gerne set, at man ombyttede antallet som producerede (udvikler) - og antallet som forsker, så vi havde fået langt mere forskning. Problemet med softwareområdet, er at der mangler grundlæggende forskning. Dem, der arbejder med området, er desværre ikke forskere. Kun "kodere".

Men sjovt nok, så betragter mange middelmådige udviklere sig som forskere.

.

"Det er umuligt!", sagde tvivlen,
"Det er farligt!", sagde frygten,
"Det er unødvendigt!", sagde fornuften,
"Gør det alligevel!", sagde hjertet.

Re: @ Jens

Software er designet til at være ustabil - og ellers, vil der komme en upgrade, der nok skal få det ustabilt.

Hvornår lægger du alle de konspirationsteorier på hylden - at software med vilje laves, så det fejler, og at amerikanerne har specielle funktioner i deres mikrocomputere, der får dem til at fejle eller opføre sig anderledes under visse omstændigheder?

Sandheden er vel bare, at efterhånden som kompleksiteten stiger, er der færre og færre der magter at bevare overblikket, hvilket fører til mange fejl og store forsinkelser og budgetoverskridelser på f.eks. offentlige IT systemer. Derfor er det så vigtigt at gøre tingene simpelt - K.I.S.S. eller endnu bedre: "Everything should be made as simple as possible, but not simpler" (Albert Einstein). Mange af vor tids programmører - isæt i PC verdenen - er nok også alt for fokuseret på fancy grafik og "skins" og alt for lidt på den "kedelige" funktionalitet nedenunder.

Re: @Jens

Ja, men når du indenfor software, netop har fået løst problemerne ved hjælp af work-arounds, så kommer en opgradering, så det ikke mere fungerer. Fordi, at softwaren er rettet... Og nu kan du så lave det hele om igen, og må rette alt endnu engang, fordi der er nye fejl, der skal work-aroundes. Software er designet til at være ustabil - og ellers, vil der komme en upgrade, der nok skal få det ustabilt.

Jeg har ved selvsyn som projektleder set hvordan en omhyggelig, fremadrettet og gennemarbejdet SW-arkitektur fra en gruppe virkelig dygtige ingeniører m/k har reddet dagen, da nye vanvittige krav pludselig dukkede op. Flere gange.

Hvis man lader dygtige folk arbejde godt og grundigt, og bruge den nødvendige tid på det, kommer der som oftest et godt produkt ud af det. Uanset om det er SW eller HW.

Møde med Peter Madsen

Jeg havde i går et udmærket og meget konstruktivt møde med Peter på H.I. messen.

Det, der bragte mig til tasterne i denne tråd, var, at abort- og styresystemet i Heat-1X ikke var fejlsikkert og oven i købet muligvis (ikke helt klarlagt) havde vist svaghedstegn ved bl.a. at kræve genstart (muligvis under generalprøven?) og først tænde i 2. forsøg. Et abortsystem er jo at sammenligne med et nødstop på en maskine, og her duer det naturligvis ikke, at stort set lige meget hvilken komponent i kæden, der fejler, vil nødstoppet ikke virke.

Det viser sig imidlertid, at abortsystemet i Heat-1X egentlig blot var beregnet som et styresystem til bl.a. at muliggøre styring og afbrydelse af motor og udløsning af faldskærme. Da Heat-1X havde for lidt LOX til at nå uden for skydeområdet, var et egentligt abortsystem unødvendigt, lige som det også vil være unødvendigt (og slet ikke forefindes) ved afprøvningen af LES i 2012. På en mission, hvor et abortsystem er unødvendigt, er det jo en fordel IKKE at gøre det fejlsikkert, idet det øger risikoen for, at missionen mislykkes.

Peter's planer for abortsystemet til Heat-2X i 2013 omfatter imidlertid nøjagtig den samme kontinuerte udsendelse af dummytelegrammer med tilhørende watch-dog, som jeg har foreslået tidligere i denne tråd. På et enkelt punkt går han endog videre, end hvad jeg ville anse for tilstrækkeligt, idet han overvejer at lade det inertisystem, som beregner rakettens position, automatisk kunne foretage abort, hvis raketten kommer uden for skydeområdet, så der ikke nødvendigvis skal en manuel ordre til. Hvis CS på et tidligt tidspunkt i denne tråd havde fortalt mig, at man ikke agtede at videreføre abortsystemet fra Heat-1X til de efterfølgende raketter med meget større rækkevidde, kunne denne diskussion have stoppet meget tidligt! Med det påtænkte abortsystem vil jeg faktisk anse det for sikkert at skyde vest for Ringkøbing fjord, som Peter egentlig helst ville - men som endog landets statsminister ikke kan give ham lov til.

Peter og jeg er faktisk rørende enige om rigtig mange ting og har derfor aftalt at holde kontakten. IEC 61508 er oven i købet ikke længere så meget et fyord, som det har været!

Egentlig havde vi aftalt, at Peter skulle fortsætte denne tråd; men pga. en pludselig opstået mekanisk defekt på et trådløst modem som følge af manglende internetforbindelse, er han måske ikke online de næste dage :-)

Re: @Jens

Hvis man lader dygtige folk arbejde godt og grundigt, og bruge den nødvendige tid på det, kommer der som oftest et godt produkt ud af det. Uanset om det er SW eller HW.

Vi er helt enige.

Sandheden er vel bare, at efterhånden som kompleksiteten stiger, er der færre og færre der magter at bevare overblikket, hvilket fører til mange fejl og store forsinkelser og budgetoverskridelser på f.eks. offentlige IT systemer. Derfor er det så vigtigt at gøre tingene simpelt - K.I.S.S. eller endnu bedre: "Everything should be made as simple as possible, but not simpler" (Albert Einstein). Mange af vor tids programmører - isæt i PC verdenen - er nok også alt for fokuseret på fancy grafik og "skins" og alt for lidt på den "kedelige" funktionalitet nedenunder.

Vi er ikke uenige. Når hardware har større tendens til at fungere end meget software, så skyldes det også K.I.S.S. og at man gør det så simpelt som muligt (men dog ikke mere simpelt end muligt).

Grunden til, at jeg efterforsker forskning i softwareverdenen, er at jeg mener, at god forskning, kan løfte niveauet. Løftes niveauet, kan meget af det, som idag er kompliceret, måske gøres simpelt. Som eksempel, har jeg set, hvordan at det var muligt at rode totalt rundt i parallel programmering, og lave ting der var upålidelige, og fungerede tilfældigt - fordi man ikke havde metoderne, som skulle bruges til at opnå determinisme. Havde udviklerne kendt metoderne, måske haft programmeringssprog til det, osv. så havde meget af det, der var besværligt for dem, fungeret langt nemmere, og uden mulighed for ikke determisme, og mangel på testbarhed. Ofte, så er de ting, som programmørerne laver, i virkeligheden ting, som kunne laves automatisk. Eller, programmeringssprogene, kunne være designet på en måde, så det er lettere for programmørene, at lave deres ting uden fejl.

Jeg synes, vi går lidt vidt, i forhold til det aktuelle problem. Her kan det laves simpelt - og er lavet simpelt. Og jeg mener ikke, at der er et større problem, med hverken softwaren eller hardwaren. Hvis der er problemer, så tror jeg, at de relativt nemt vil kunne løses.

Ofte, bruger man i øvrigt en gnisttænder, og sætter lige over hardwaren, eller anden ekstremt støjende ting. Måske, laver støj direkte på ledningerne, ved at forbinde den til. Overlever skidtet, og laver ikke fejl, så er det ok. Så det burde muligt at teste.

Re: Møde med Peter Madsen

Carsten Kanstrup:

Hvis CS på et tidligt tidspunkt i denne tråd havde fortalt mig, at man ikke agtede at videreføre abortsystemet fra Heat-1X til de efterfølgende raketter med meget større rækkevidde, kunne denne diskussion have stoppet meget tidligt!

Desværre ikke:

30. august 10:28:
Når vi engang har udviklet aktiv guidance, FÅR GUIDANCE SIKKERT OGSÅ NOGET AT SKULLE HAVE SAGT MHT. ABORT.
Men alle disse ting er under fortsat udvikling.

31. august 15:59:
systemet virkede og VIL IKKE BLIVE BRUGT IGEN. HEAT havde ikke fløjet ud af området uden abort, og havde den havde den stadig kun ramt tomt hav.

Kan man vurdere fremtidige raketter systemer ved at kikke på tidligere raketters systemer ?

Vi skal ikke være gode til at flyve 1X næste gang, vi skal være gode til at flyve 2X, og DET ER EN HELT ANDEN MASKINE MED HELT ANDRE SYSTEMER.

2. sept. 11:37:
Men som det hele tiden har været vores intention, gør vi os konstant umage for at forbedre sikkerheden, hvor vi kan. Bl.a. ved udvikling af guidance- og abortsystemerne. Herunder vha. såvel transmission som ON-BOARD løsninger. Der er absolut intet nyt i vores holdning dér.

Re: Møde med Peter Madsen

Fint nok Niels, men ikke ét eneste ord om f.eks. fejlsikre systemer, sikkerhedsnormer eller lignende.

"Får sikkert også noget at skulle have sagt", "Vil ikke blive brugt igen", "Helt andre systemer" siger jo ikke så meget konkret; men vi er jo også i en valgkampsperiode :-)

Så venner...

Abort debatten vil sikkert fortsætte - men jeg kan 100 % bekræfte at Carsten og jeg har snakket konstruktivt sammen og for 117 gang fastslået at mails eller debatindlæg er en rigtigt god måde at tale forbi hinanden på

Carstens referat er meget nøjagtigt.

Man kan diskutere hvornår eller hvor man har kunnet orientere sig om 2X planer - se f.eks. her:

http://ing.dk/artikel/120132-a...r-os

Men - alle læser jo nu engang ikke alt -

Det heller ikke så vigtigt hvornår dette eller hint var ude - det er sundt at snakke om dette emne - og det er helt sikkert at vi kan blive bedre ved at dele vores overvejelser er ude offentligt her.

Mandag er jeg tilbage i HAB og så der bygges LES motor.

Peter Madsen