|
citace:
citace:
citace:
Proboha a to nemají dost času na to, aby tu chybu v počítačích opravili?!
Pokud je opravitelna... Treba to neni chyba, ale "vlastnost".
Počítač není člověk- u počítače se i vlastnost dá změnit 
Samozřejmě se to dá a testuje se to. Celý problém YERO (Year End Rollover) spočíval v následujícím:
Všechny hlavní elektronické hodiny raketoplánu, tzv. MTU (Master Timing Unit) se 31. prosince o půlnoci světového času UTC překlopí na den 1, 00 hodin 00 minut 00 sekund, ale primární řídicí software PASS (Primary Avionics System Software) řízení systémů raketoplánu normálně inkrementuje den z hodnoty 365 na 366. V tu ránu dojde k nesouladu mezi údaji hodin a řídicích počítačů a systém program stopne; mohlo by dokonce dojít k úplnému výpadku hlavních počítačů GPC (General Purpose Computer), které by musela posádka raketoplánu znovu rebootovat. Zatím nikdy raketoplán přes Silvestra a Nový rok nebyl ve vesmíru a dokumenty požadují, aby se přes konec roku prostě nelétalo. Taď ale jde o každý den při výstavbě ISS a proto se možnost vyřešení problému YERO začala testovat a výsledek testů měl být projednán na koordinační schůzce, která se měla konat 2006-10-31, tedy minulý týden. Pokud by se problém nevyřešil, znamenalo by to, že Discovery by nemohl startovat po 2006-12-16, protože pak by raketoplán přistával při prodloužení letu až v roce 2007. V současnosti se počítá se startem 2006-12-07 (místního času, ve světovém a našem středoevropském by už mělo být po půlnoci ráno 2006-12-08), takže startovní okno by bylo 10 dní dlouhé, i při omezení v důsledku YERO.
Jak schůzka 2006-10-31 dopadla, zatím nevím, ale pokusím se něco zjistit.
____________________
Antonín Vítek |
|
citace:
citace:
citace:
Proboha a to nemají dost času na to, aby tu chybu v počítačích opravili?!
Pokud je opravitelna... Treba to neni chyba, ale "vlastnost".
Počítač není člověk- u počítače se i vlastnost dá změnit
Ale pri slozitosti raketoplanu, prislusnych narocich na bezpecnost a spolehlivost a zcela jiste i pak potrebny audit, mozna i nekolikanasobny, je proste jednodussi to neresit a posunout start. Take je otazka, jestli jeste nekdo po tech letech vi, jak je to naprogramovane.
Pokud by to znamenalo rok dva vyvoje a testovani, tak pri planovanem doziti STS to nema cenu. A urcite jste uz slysel v IT oblibenou vetu "Kdyz to funguje, tak na to nehmatej". :-) |
|
citace:
A urcite jste uz slysel v IT oblibenou vetu "Kdyz to funguje, tak na to nehmatej". :-)
OT: Tři základní Murphyho zákony IT:
1. Každý program obsahuje nejméně jednu instrukci chybnou.
2. Každý program obsahuje nejméně jednu instrukci zbytečnou.
3. Odstraněním jedné chyby v programu se do něj vnese chyba jiná, stejné významnosti.
Důsledek: Jediný správný program je takový, který neobsahuje žádnou instrukci (a nic nedělá a tím nic nezkazí - dodávám já).
Programátoři NASA v SAL (Shuttle Avionics Laboratory) vědomi si zákona č. 3, raději dříve do programů nešťourali, i když si byli vědomi té chyby, aby z chodících programů neudělali nechodící.
[Upraveno 08.11.2006 poslal avitek] ____________________
Antonín Vítek |
|
citace:
citace:
A urcite jste uz slysel v IT oblibenou vetu "Kdyz to funguje, tak na to nehmatej". :-)
OT: Tři základní Murphyho zákony IT:
1. Každý program obsahuje nejméně jednu instrukci chybnou.
2. Každý program obsahuje nejméně jednu instrukci zbytečnou.
3. Odstraněním jedné chyby v programu se do něj vnese chyba jiná, stejné významnosti.
Důsledek: Jediný správný program je takový, který neobsahuje žádnou instrukci (a nic nedělá a tím nic nezkazí - dodávám já).
Programátoři NASA v SAL (Shuttle Avionics Laboratory) vědomi si zákona č. 3, raději dříve do programů nešťourali, i když si byli vědomi té chyby, aby z chodících programů neudělali nechodící.
[Upraveno 08.11.2006 poslal avitek]
Ano, to sedí
V jiné podobě se ten Murphy používá takto: Kdo pracuje, dělá chyby. Kdo nedělá nic, nic nezkazí. Kdo nic nezkazí, zasluhuje odměnu! |
|
Mě přijde, že v NASA se drží tradic z dob, kdy programování prostě byla velká alchymie, a i největší experti se dopouštěli hrubých chyb. Jenže svět je od té doby někde hodně jinde... chyby v programech se opravují, a většinou to nemá žádné další negativní důsledky.
Je pravda, že "debugovat" raketoplán s lidmi na palubě je problematické, ale na druhou stranu: nemyslím, že raketoplán létá díky vší té byrokracii okolo (spíše navzdory ní).
Je pravda, že spousta raket NASA i ESA v minulosti spadla díky banálním softwarovým chybám. A řekl bych, že lidé, kteří ovládali všechnu tu matematiku týkající se kosmických letů byli historicky zřejmě hodně nezkušení programátoři, a nikdy rutině neřešili každodenní programátorské problémy, se kterými se potýkají autoři masově používaných operačních systémů i velkých aplikací. I když samozřejmě: problém bude v tom, že STS používá nějaký historický 8bit, sice ultraodolný vůči radiaci - ale lidé co to uměli programovat zřejmě už jsou dávno v důchodu. A dnes se všichni děsí toho, že by
na to museli sáhnout: "nesahejte na nic, co funguje". Podobný problém se řešil i u Concorde: navzdory veškeré dokumentaci to je tak, že když odejde do důchodu generace inženýrů co nějaké podobné zařízení znala nazpaměť do posledního šroubečku, tak najednou začne být nebezpečné to provozovat.
Rusové sice zdánlivě pořád používají rakety odvozené z první R-7: ale ve skutečnosti to během těch let už celé několikrát překopali, pořád vyměňují elektroniku, software, upgradují motory, apod. Takže si to tam tímhle způsobem zřejmě "osahá" nová generace techniků.
Skutečně si nemyslím, že třeba vehikly, které bastlí doma na koleni programátor John Carmack, by jednou mohly mít tenhle druh problémů (samozřejmě že budou mít jiné problémy: ale troufám si říct, že nebudou softwarového charakteru, a když ano, tak se nebudou týkat nemožnosti "přelétnout" konec roku...). Prostě programování počítačových her zřejmě není tak špatná průprava pro programování navigačních systémů kosmických lodí... ale asi ani on nebude chtít
palubní SW debugovat během "pilotovaných" letů...
|
| 08.11.2006 - 12:13 - J2930 | |
|
citace:
....ani on nebude chtít palubní SW debugovat během "pilotovaných" letů...
Coz by mnelo byt u dobreho SW normalni... a bez restartu 
Nikdy totiz zadny system neotestujete kompletne. Nebo ano?
Chce snad NASA naznacit ze pri pripadnem vypadku vsech SW na palube behem letu nema zadne rozumne krizove reseni? |
| 09.11.2006 - 17:13 - J2930 | |
|
Discovery je na rampe (Launch Pad 39B)
http://mediaarchive.ksc.nasa.gov/search.cfm?cat=69
... |
| 09.11.2006 - 18:10 - J2930 | |
|
mapa 39B:
http://www-de.ksc.nasa.gov/dedev/maps/pad_b.html
Index of KSC Maps:
http://www-de.ksc.nasa.gov/dedev/maps/maphome.html
pri vstupu pisou: internal users only a datum psledni revize 1997. Tak nevim. |
|
citace:
mapa 39B:
http://www-de.ksc.nasa.gov/dedev/maps/pad_b.html
Na Google Earth jsou startovací rampy a celá oblast okolo s maximálním rozlišením. Dá se tak krásně porovnat mapa se skutečností. |
|
citace:
Mě přijde, že v NASA se drží tradic z dob, kdy programování prostě byla velká alchymie, a i největší experti se dopouštěli hrubých chyb. Jenže svět je od té doby někde hodně jinde... chyby v programech se opravují, a většinou to nemá žádné další negativní důsledky.
Je pravda, že "debugovat" raketoplán s lidmi na palubě je problematické, ale na druhou stranu: nemyslím, že raketoplán létá díky vší té byrokracii okolo (spíše navzdory ní).
Je pravda, že spousta raket NASA i ESA v minulosti spadla díky banálním softwarovým chybám. A řekl bych, že lidé, kteří ovládali všechnu tu matematiku týkající se kosmických letů byli historicky zřejmě hodně nezkušení programátoři, a nikdy rutině neřešili každodenní programátorské problémy, se kterými se potýkají autoři masově používaných operačních systémů i velkých aplikací. I když samozřejmě: problém bude v tom, že STS používá nějaký historický 8bit, sice ultraodolný vůči radiaci - ale lidé co to uměli programovat zřejmě už jsou dávno v důchodu. A dnes se všichni děsí toho, že by
na to museli sáhnout: "nesahejte na nic, co funguje". Podobný problém se řešil i u Concorde: navzdory veškeré dokumentaci to je tak, že když odejde do důchodu generace inženýrů co nějaké podobné zařízení znala nazpaměť do posledního šroubečku, tak najednou začne být nebezpečné to provozovat.
Rusové sice zdánlivě pořád používají rakety odvozené z první R-7: ale ve skutečnosti to během těch let už celé několikrát překopali, pořád vyměňují elektroniku, software, upgradují motory, apod. Takže si to tam tímhle způsobem zřejmě "osahá" nová generace techniků.
Skutečně si nemyslím, že třeba vehikly, které bastlí doma na koleni programátor John Carmack, by jednou mohly mít tenhle druh problémů (samozřejmě že budou mít jiné problémy: ale troufám si říct, že nebudou softwarového charakteru, a když ano, tak se nebudou týkat nemožnosti "přelétnout" konec roku...). Prostě programování počítačových her zřejmě není tak špatná průprava pro programování navigačních systémů kosmických lodí... ale asi ani on nebude chtít
palubní SW debugovat během "pilotovaných" letů...
Náhodou dělám software pro stroje a linky a mohu říci: je to stále alchymie!!!
... teda ono to samozřejmě jde i "sofistikovaně" a s použitím "moderních" programátorských nástrojů. ALE je to STRAŠNĚ nákladné a výsledek není tak jistý!
... pro představu: i s použitím specializovaných jazyků vychází obsluha jednoho výstupu se zpětným čidlem na 3 instrukce, ovšem při použití "prediktivní logiky" (což je asi způsob, kterým by se to mělo dělat) potřebujete na stejnou úlohu (jeden výstup) zhruba 120 instukcí plus blok paměti.
... tedy nárůst rozsahu, pracnosti a i příležitosti udělat chybu (což by ve výsledku negovalo zamýšlený cíl snížení chybovosti) je obrovský -> takže se to většinou udělá na ty tři instrukce. ;-(
... v reálném stroji jsou ovšem desítky a stovky vstupů a výstupů, které navíc spolu různě souvisejí, což situaci ještě víc komplikuje a prodražuje.
... ještě poznámku k STS: V době vývoje nebyly k dispozici dostatečně výkonné počítače (a s dostatečně velkou paměťovou kapacitou), takže většina vstupů je "na 3 instrukce". A to přesto, že původní odhady rozsahu programového vybavení byly výrazně překročeny.
PS: pro zájemce o řídící počítače kosmických lodí doporučuji třeba: http://www.hq.nasa.gov/office/pao/History/computers/Part1.html
obzvláště kapitolu 4, kde je uvedena evoluce systému počítačů v raketoplánu.
zdravím
Honza
|
|
... ještě dodám, že programovací jazyk vyvinutý pro SST se jmenuje HAL/S.
Pres wikipedii, stránku http://en.wikipedia.org/wiki/HAL/S si můžete stáhnout dokumentaci.
zdravím
Honza
|
| 12.11.2006 - 11:39 - Olda | |
|
| V roce 1989 se měl uskutečnit let STS-32 (11 denní mise se zachycením LDEF. Zahájení odpočítávání byli 15. prosince kvůli nedodělkům na 39A odloženo nejprve o 5 dny a 15. prosince ještě o den. Z toho vyplývá plánované datum startu nejdříve 19.prosince. Z toho vylývá přistání nejdříve 29.12.1989 (let se jak známo uskutečnil nakonec v lednu byl o den prodloužen). To by ohledně těch počítačů na přelomu roku bylo dost na hraně. Jak to, že se tenkrát nikdo problémy s počítači nevzrušoval? |
| 12.11.2006 - 12:52 - Adolf | |
|
citace:
Náhodou dělám software pro stroje a linky a mohu říci: je to stále alchymie!!!
Já mám o programování strojů následující představu. Existují dva základn% typy:
1. Programování typu jako pro chemickou či energetickou výrobu. To se moc neliší od programování třeba takové banky. Běží to na výkonných počítačích, naprogramované v běžných universálních vývojových prostředích a tak nějak to řídí procesy, při čemž k tomu má různá místní PID a bezpečnostní elektrické obvody – vše s určitou vlastní inteligencí.
2. Programování CNC strojů ve strojírenství atp., což je úplně jiný programátorský svět s jakousi jednoduchou, nízkoúrovňovou specializovanou logikou. Když programujeme universálu k soustruhu, tak ne žádné programování v universálních programovacích jazycích, nýbrž v nějakých Siemensovo povelech pro čelisti. Člověk jako by se opět ocitl 70. letech, ale je to dostatečně chytré i s inteligencí trhovecké kalkulačky.
Já jsem si vždy představoval, že takový řídící systém třeba pro bojové letadlo se víc podobá systému, co řídí chemickou výrobnu, než systému, co řídí universální soustruh. Po těchto sděleních mám dojem, že ale takový systém pro raketoplán se víc podobá balící lince nebo obráběcímu stroji než třeba systému řízení hydrocrackingu nebo hydroformylace.
Je to tak nějak nebo se mýlím?
 |
| 12.11.2006 - 14:40 - Pavel | |
|
citace:
Idnes=Blesk
nekde jsem sice cetl, ze NASA mohla mit vyhrady ohledne raketoplanu na obezne draze pri zmene roku, ale podle SpaceFlightNow.com jde zatim vsechno podle planu. Naklad by mel byt presunut na startovaci rampu v utery a vlastni Shuttle Stack by se mel zacit presouvat o pulnoci EST ve ctvrtek. NASA dokonce uvazuje o posunuti startu ze 7. prosince na 6. prosince.
ze SpaceFlightNow.com:
Space shuttle Discovery has been mated to its external fuel tank and twin solid rocket boosters inside Kennedy Space Center's Vehicle Assembly Building. Rollout to launch pad 39B is now scheduled to begin around midnight Thursday morning. The payload is expected to be delivered to the pad in a special canister on Tuesday. Liftoff is scheduled for December 7, but NASA is looking at the possibility of moving up the launch to December 6.
Může mi někdo osvětlit jak je to s nákladem. Na videu jsem viděl velkou "krabici" jak ji nastojato přepravuje nějaký tahač k rampě a pak ji zvedl jeřáb do konstrukce. Předpokládám, že tato se do raketoplánu nedává. Jak tam potom ten náklad překládájí? Myslím i to, že pokud se nákladní prostor otevře, tak se tam mohou dostat nečistoty z okolí. Děkuji za odpověď |
|
citace:
citace:
Náhodou dělám software pro stroje a linky a mohu říci: je to stále alchymie!!!
Já mám o programování strojů následující představu. Existují dva základní typy:
1. Programování typu jako pro chemickou či energetickou výrobu. To se moc neliší od programování třeba takové banky. Běží to na výkonných počítačích, naprogramované v běžných universálních vývojových prostředích a tak nějak to řídí procesy, při čemž k tomu má různá místní PID a bezpečnostní elektrické obvody – vše s určitou vlastní inteligencí.
2. Programování CNC strojů ve strojírenství atp., což je úplně jiný programátorský svět s jakousi jednoduchou, nízkoúrovňovou specializovanou logikou. Když programujeme universálu k soustruhu, tak ne žádné programování v universálních programovacích jazycích, nýbrž v nějakých Siemensovo povelech pro čelisti. Člověk jako by se opět ocitl 70. letech, ale je to dostatečně chytré i s inteligencí trhovecké kalkulačky.
Já jsem si vždy představoval, že takový řídící systém třeba pro bojové letadlo se víc podobá systému, co řídí chemickou výrobnu, než systému, co řídí universální soustruh. Po těchto sděleních mám dojem, že ale takový systém pro raketoplán se víc podobá balící lince nebo obráběcímu stroji než třeba systému řízení hydrocrackingu nebo hydroformylace.
Je to tak nějak nebo se mýlím?
Domnívám se že od obojího něco. Na "dolní" úrovni systému to bude
MNOHO specializovaných jednotek které dělají onu nízkoúrovňovou
specializovanou logiku ale také "lokální" regulaci a kontrolu
(třeba kompy u SSME), pak spusta multiplexerů které to asi v
nějakém odpovídacím režimu přes sbernice posílají nahoru
přes všechny vrstvy a to pak vyhodnocují soft. procesy na hlavních
kompech které jsou již psány v univerzálních jazycích(ale to
jsou distrubuované jednotky často též), procesy mají různou
prioritu a nekteré mají statut procesů reálného času, jiné
ne. Ale celý ten systém opravdu není o nějaké té "inteligenci"
ale musí být tvrdě predikovatelný a hlavně podřízené jednotky
si nemohou "vyskakovat".  |
| 12.11.2006 - 18:11 - Martin K. | |
|
Jméno Martin Hakel u posledního přispěvku neplatí,
server to doplnil sám. Platí jenom Martin.
Takhle by to tedy na sts asi fungovat nemohlo. |
|
citace:
citace:
Náhodou dělám software pro stroje a linky a mohu říci: je to stále alchymie!!!
Já mám o programování strojů následující představu. Existují dva základní typy:
1. Programování typu jako pro chemickou či energetickou výrobu. To se moc neliší od programování třeba takové banky. Běží to na výkonných počítačích, naprogramované v běžných universálních vývojových prostředích a tak nějak to řídí procesy, při čemž k tomu má různá místní PID a bezpečnostní elektrické obvody – vše s určitou vlastní inteligencí.
2. Programování CNC strojů ve strojírenství atp., což je úplně jiný programátorský svět s jakousi jednoduchou, nízkoúrovňovou specializovanou logikou. Když programujeme universálu k soustruhu, tak ne žádné programování v universálních programovacích jazycích, nýbrž v nějakých Siemensovo povelech pro čelisti. Člověk jako by se opět ocitl 70. letech, ale je to dostatečně chytré i s inteligencí trhovecké kalkulačky.
Já jsem si vždy představoval, že takový řídící systém třeba pro bojové letadlo se víc podobá systému, co řídí chemickou výrobnu, než systému, co řídí universální soustruh. Po těchto sděleních mám dojem, že ale takový systém pro raketoplán se víc podobá balící lince nebo obráběcímu stroji než třeba systému řízení hydrocrackingu nebo hydroformylace.
Je to tak nějak nebo se mýlím?
Nemýlíte se. Raketoplán je jen taková větší balící linka. ;-) Nastojato. ;-)
ještě připojím pár poznámek:
- klasický mechanický sekvencer, co ho á doma Vaše pračka (kromě několika nejnovějších modelů), byl původně vymyšlen a doladěn pro raketu V2. A také s ním většina raket lítala a lítá (i když dnes už je realizace elektronická).
- jedna z hlavních inovací rakety Sojuz2 je právě náhrada řízení se sekvencerem za digitální řídící systém.
- aby měl smysl inteligentnější řídící systém, musí mít možnost získávat přesné informace o svojí poloze, rychlosti, atd. Což je možné až poslední dobou s použitím přesných akcelerometrů, GPS družic, ...
zdravím
Honza
|
| 12.11.2006 - 18:46 - Adolf | |
|
citace:
Domnívám se že od obojího něco. Na "dolní" úrovni systému to bude
MNOHO specializovaných jednotek které dělají onu nízkoúrovňovou
specializovanou logiku ale také "lokální" regulaci a kontrolu
(třeba kompy u SSME), pak spusta multiplexerů které to asi v
nějakém odpovídacím režimu přes sbernice posílají nahoru
přes všechny vrstvy a to pak vyhodnocují soft. procesy na hlavních
kompech které jsou již psány v univerzálních jazycích(ale to
jsou distrubuované jednotky často též), procesy mají různou
prioritu a nekteré mají statut procesů reálného času, jiné
ne. Ale celý ten systém opravdu není o nějaké té "inteligenci"
ale musí být tvrdě predikovatelný a hlavně podřízené jednotky
si nemohou "vyskakovat".
Takhle nějak funguje ta chemická linka a myslím si, že i letadlo. Dokud mě nepoučil pan Baštecký, tak bych si myslel, že i raketoplán. S tou predikovatelností to asi občas musí být zajímavé. Svého času mi povídal jeden, co dělal na SW pro kardiostimulátor, že pro testovací postupy musí mít matematické důkazy, že test je fakt to pravý vořechový.
Na druhou stranu jsem kdysi četl ve Vesmíru článek, kde autor tvrdil, že jeho notebook, na kterém to píše, je natolik složitý systém, že jej z principu nelze otestovat na naprostou spolehlivost, neboť k modelu všech cest, kam se můžou vydat programy v něm, by nestačil vesmír, neboť je v něm málo částic. Prostě notebooka na vesmíru nenamodeluješ, potřebuješ něco většího.
Takže s tou predikcí to asi bude všelijaké. |
| 12.11.2006 - 18:59 - Adolf | |
|
citace:
Nemýlíte se. Raketoplán je jen taková větší balící linka. ;-) Nastojato. ;-)
Moc děkuji za velice zajímavou odpověď!
Nicméně utvrzuje mě to v domněnce, že kosmonautika je v současnosti extrémně technicky konzervativní obor. Když někdo postavil elektrárnu nebo loď v 60. či 70. letech, tak jsou to sice ošuntělé muzeální stroje starší než jejich obsluha, ale řídící, měřící a regulační systém je nějaký současný. Kosmický stroj ale pořád taková "parní lokomotiva" a jeho řídící systém je obdoba toho, jaký byl v té automatické pračce blahé paměti, co ji bývalo nutno při ždímání stabilizovat lidskou silou, aby nezbourala koupelnu.
Inerciálním navigačním systémem se v 80. letech pyšnilo každé éro, co mělo o kousek náročnější určení než práškování polí. A teprve teď - o 20 let později - to začíná být aktuální u kosmických nosičů? |
| 12.11.2006 - 19:25 - Martin Kolář | |
|
citace:
citace:
Takhle nějak funguje ta chemická linka a myslím si, že i letadlo. Dokud mě nepoučil pan Baštecký, tak bych si myslel, že i raketoplán. S tou predikovatelností to asi občas musí být zajímavé. Svého času mi povídal jeden, co dělal na SW pro kardiostimulátor, že pro testovací postupy musí mít matematické důkazy, že test je fakt to pravý vořechový.
Na druhou stranu jsem kdysi četl ve Vesmíru článek, kde autor tvrdil, že jeho notebook, na kterém to píše, je natolik složitý systém, že jej z principu nelze otestovat na naprostou spolehlivost, neboť k modelu všech cest, kam se můžou vydat programy v něm, by nestačil vesmír, neboť je v něm málo částic. Prostě notebooka na vesmíru nenamodeluješ, potřebuješ něco většího.
Takže s tou predikcí to asi bude všelijaké.
A to si ještě vemte, že podle matematika Kurta Godela
v libovolném formálním systému jsou výroky které jsou
pravdivé protože jsou nedokazatelné...ach jo. 
(tím nechci říct že jeho důkazu rozumím)
jinak pro umístění el.mechanického sekvenceru v raketoplánu
navrhuji použít nákladový prostor. snad bude stačit.... |
| 12.11.2006 - 19:44 - Martin Kolář | |
|
| Ale ten poslední smajla měl být takhle a ne takhle |
| 12.11.2006 - 19:47 - Adolf | |
|
| Ještě potrhlíka Gödela a jeho pesimistické teorémy? No naštěstí, když se vyndá z pračky sekventor, tak raketa na něj poletí. |
| 12.11.2006 - 19:57 - Martin Kolář | |
|
citace:
Ještě potrhlíka Gödela a jeho pesimistické teorémy? No naštěstí, když se vyndá z pračky sekventor, tak raketa na něj poletí.
Zajímavé je že já jeho teorii vnímám spíše jako optimistickou pro
neklidnou lidskou duši. Kdyby to Hilbert vyhrál v matematice a
jiní podobní potom v jiných oborech, člověk by si sáhnul na
jakési meze složitosti světa. A to raději ne.. |
|
| no myslim ze pri raketoplane ide o cosi komplikovnejsi system ako v pripade pracky .. ale iste ma to nieco do seba. Kedysi ked este neexistovali pocitace s dostacujucim vykonom (do 80tich rokov) sa vsetko tocilo okolo davkoveho spracovania ani riadiaci system Apolla nieje cistokrvny realtime. Skor sa to podoba na nejake procesne riadenie ktore je mozne celkom spolahlivo otetovat. Pri Raketoplane sa ale zaslo (ako pozeram) omnoho dalej. Kedze STS je velmi velmi zlozity system nepostacuje mu jednoduche procesne riadenie aj ked je velmi spolahlive. Tu sa ale zaslo az tak daleko ze kazda jednotka systemu ma vlaste riadenie ktore je mozno na urovni procesneho riadenia (a mozno nie ale u takeho SSME ci APU asi ano - zjednodusene: zapni motor -> doslo palivo? [nie] -> {-> 516s po starte -> vypni motor} [ano] -> vypni motor [porucha] -> vypni motor ). Procesne riadenie je vzdy na niecom zavysle teda chcem tym povedat ze nasledujuci krok je pevne spaty s predoslim a vysledky sa drzia iba vramci nastaveni procesu. Takze chybovost procesneho riadenia je minimalna (ak nieje zly proces - ale to sa lahko otestuje)... Ibaze Raketoplan by neletel keby vsetky jednotky nemalo co riadit ... nieco co im dava prikazi alebo udaje z cidiel (ale uz spravne spracovane) na to sluzi prave tych 5 pocitacov ktore maju za ulohu 1. zbierat data z cidiel (toto sa deje v davkach) 2. pocitat z nich predpokladane nasledujuce udaje a porovnat ich so starymi predpovedami 3. porovnavat si data medzisebou (tiez v davkach) 4. predavat prikazi a data podriadenym systemom (nasim jednotkam) 5. kontrolovat cinnost ostatnych pocitacov. ... preco sa pouzilo zcasti davkove spracovanie? no lebo vtedy nic rychlejsie nebolo a niektre vpocty trvaju menej ine viac .. tak sa aspon celkovy cas spracovania spriemeroval. Nastastie je tych sysemov 5 (4 su aktyvne pri normalnom stave) takze jedenmoze zasiahnut vzdyor ako ostatne .. inak ked s pritom riadiacom systeme STS skuste si precitat co o nom napisal R.Faynmann .. sice sa casi zmenili a hlavne po havarii Calengeru a pocitace doznali zmien ale dakove spracovanie a kvazi realtimove riadenie ostalo .. STS je tak konstruovany a inak to ani moct nemoze byt ... konecnom dosldku j riadiaci system STS velmi podobny riadeniu jadrovej elektrarne a tak sa bude aj programovat .. a to by sa jeden cudoval co sa pacmagy jazyky sa pouzivaju na taketo veci ale su jednoduche a spolahlive... |
|
citace:
Ještě potrhlíka Gödela a jeho pesimistické teorémy?
Nechápu co je na nemožnosti existence bezrosporných logických systémů "pesimistického" ? Vždyť vnitřní rozpory jsou někdy docela vtipné nebo romantické...
|
|
citace:
Na druhou stranu jsem kdysi četl ve Vesmíru článek, kde autor tvrdil, že jeho notebook, na kterém to píše, je natolik složitý systém, že jej z principu nelze otestovat na naprostou spolehlivost, neboť k modelu všech cest, kam se můžou vydat programy v něm, by nestačil vesmír, neboť je v něm málo částic. Prostě notebooka na vesmíru nenamodeluješ, potřebuješ něco většího.
Ne náhodou je úskalí v programech - ne v hardwaru. Pravděpodobnost že dojde k nějaké hardwarové chybě během běžně očekávané životnosti notebooku je překvapivě malá: a většinou jde o chybu typu "systém běží" vs. "systém neběží".
V běžném programování vznikají nelinearity, jejichž stavové prostory se prakticky nedají prozkoumat, především z těhle základních důvodů:
- metodika používání pointerů do paměti vs. běžně používané strategie alokace, dealokace a realokace paměti. Na úrovni, na které jsou běžně naprogramovány kritické součásti sytému a systémových knihoven, se u pointerů běžně netestuje, zda opravdu ukazují na nějaká smysluplná data. (Systém jako celkem max. ukončí konkrétní program , pokud pointer ukazuje do takové části paměti, kam daný program nemá přístup)
- metodika používání rekurze: většinou se nijak nehlídá maximální počet vnoření při rekurzi, přitom může dojít místo na stacku, apod.
- zacyklení na neplatných vstupných datech
- alokace většího množství logické paměti, než kolik má systém reálné fyzické paměti vede ke swapování ... a u některých algoritmů pak ke zpomalení běhu celého systému pod přijatelnou hranici.
Naštěstí od první éry rozmachu výpočetní techniky a programování v 50. a 60.letech se už dnes všeobecně nepostupuje tak, že by se pro specializované "kritické" aplikace vyvíjely zcela specializované jednoúčelové systémy, u kterých by bylo "matematicky dokázané", že jsou bezchybné. Nevýhodou takových systémů je totiž omezená srozumitelnost pro kohokoliv kromě jejich autorů - a nesmírná obtížnost dokázat, že jakýkoliv sebemenší zásah do systému nepovede ke ztrátě této "bezchybnosti".
Operační systémy typu Unix poskytují docela slušné záruky co se týká celkové stability systému i v případě, že jednotlivé dílčí aplikace mají nějaké problémy.
NASA ne náhodou patří mezi masivní propagátory Linuxu. Je pravda, že třeba vozítka Spirit a Opportunity mají vlastní palubní operační systém - u kterého se projevily různé specifické problémy už v prvních týdnech provozu - ale i tenhle systém je podle dílčích zpráv o celé světelné roky napřed proti tomu, co používá raketoplán.
Dá se předpokládat, že většina počítačových systémů řídících kosmické lodě potřebuje v zásadě vykonávat zhruba stejné činnosti, jako běžný desktopový počítač, na kterém píšu tento článek. Jde o nějakou správu paměti, běžících procesů, komunikaci s jinými systémy, vstupně-výstupní operace... nic, co by se na zemi dnes už nedělalo zcela rutině.
Jestliže v případě kosmického hardware věřím tomu, že je důležité brát ohledy na to, že bude pracovat v extrémních podmínkách (radiace, vibrace při startu, stav beztíže) - tak u kosmického software jsem extrémně skeptický vůči představě, že by na to v zásadě neměl stačit obyčejný "pozemský" software. Jasně: na některé dílčí úlohy asi bude potřeba realtimový systém - ale i takový systém může pomocí běžné počítačové sítě komunikovat s nějakým "obyčejnějším" systémem.
|
| 13.11.2006 - 00:05 - Blaza | |
|
[quotehttp://www.hq.nasa.gov/office/pao/History/computers/Part1.html by Honza
Super link. Vubec jsem treba netusil, ze srdcem ridici jednotky SSME Block II je legendarni Motorola 68000.
P.S.
Take jste pred cca dvaceti lety paril na Atarku s M68K Packmana? :-) |
| 13.11.2006 - 11:36 - Martin Kolář | |
|
Trochu info o původním řešení :
http://science.ksc.nasa.gov/shuttle/technology/sts-newsref/sts-av.html#sts-dps
|
| 14.11.2006 - 00:51 - Adolf | |
|
citace:
Nechápu co je na nemožnosti existence bezrosporných logických systémů "pesimistického" ? Vždyť vnitřní rozpory jsou někdy docela vtipné nebo romantické...
Toto označení vymysleli v 60. letech tehdejší matematici. Byla to doba, kdy propukla obrovská důvěra v matematizaci a algoritmizaci. Tyto teorémy položily meze pro matematizaci a algoritmizaci, takže asi přinesly určitý pesimistický šok. ____________________
Áda |
| 19.11.2006 - 00:05 - J2930 | |
|
aby nezapadlo :-) naklad je nalozen (SPACEHAB a P5), kosmonauti trenuji, fotografuji se v hornich polohach startovaci rampy (39B), a tak...
http://mediaarchive.ksc.nasa.gov/search.cfm?cat=69
rutina |
|
