Při prosincové nepilotované testovací misi lodi Starliner se po startu objevily celkem dvě softwarové chyby. O jedné z nich jsme věděli od začátku – právě ta způsobila, že se loď zpožděným zážehem motorů připravila o možnost spojení s Mezinárodní kosmickou stanicí, jak bylo původně v plánu. NASA v pátek přiznala, že pokud by podobné chyby nebyly podchyceny včas, mohlo by v extrémním případě dojít i ke zničení lodi. Společný vyšetřovací tým NASA a Boeingu „objevil dva kritické softwarové defekty, na které se nepřišlo před startem ani přes vícečetnou kontrolu,“ stojí v prohlášení agentury, kde se dále dočteme: „V obou případech zabránil ztrátě lodi zásah pozemního personálu.“
Zdroj: https://www.nasa.gov/
Loď Starliner vyrazila na svou první kosmickou misi na raketě Atlas V 20. prosince z Mysu Canaveral. Cílem mise bylo vystavit soukromou kosmickou loď určenou pro dopravu posádky skutečným letovým podmínkám – od startu, přes setkání s ISS a spojení až po návrat do atmosféry a přistání. Zjednodušeně řečeno měla tato mise vyzkoušet všechny systémy a prověřit jejich funkci před pilotovanou testovací misí.
Jenže po oddělení lodi od horního stupně Centaur, se začaly události odklánět od plánovaného průběhu. Loď zcela zbytečně prováděla korekční manévry a plýtvala pohonné látky, které měla využít pro zážeh, kterým dosáhne stabilní oběžné dráhy. Po vyřešení komunikačních potíží se inženýrům konečně podařilo získat nad lodí kontrolu a dostat ji na stabilní dráhu. V té době už ale měl Starliner z nádrží vyplýtváno příliš mnoho pohonných látek, které tak nestačily na plánované setkání s ISS.
Místo toho se pozemní týmy zaměřily na náhradní řešení – provést na oběžné dráze co možná nejvíc zkoušek systémů, než dva dny po startu přijde přistání v Novém Mexiku. Výše popsaná chyba časovače však nakonec nebyla jedinou anomálií v počítačovém kódu této kosmické lodi. Před vstupem do atmosféry inženýři odhalili další softwarovou chybu, která ovlivňovala zážehy korekčních trysek, které jsou nezbytné pro bezpečné odhození servisního modulu lodi Starliner.
Zdroj: https://live.staticflickr.com/
Telemetrie ukázala, že první závada měla svůj původ ještě před startem, když letový počítač Starlineru špatně přečetl čas z hodin řídícího letového systému na raketě Atlas V. Je nutné poznamenat, že Atlas v tom byl nevinně. Starliner si však myslel, že je o 11 hodin méně, než ve skutečnosti bylo. Jakmile se loď oddělila od horního stupně rakety, Starliner zjistil, že je ve špatný čas na špatném místě. Proto začal provádět korekce, aby vyřešil neexistující problém.
V případě druhé závady, která souvisela s oddělením servisního modulu, si řídící počítač „nesprávně přeložil“ pokyny k sekvenci zážehů trysek po oddělení modulu. Podle NASA by obě chyby mohly vést i k destrukci lodi. Zatímco o problému s časovačem jsme se dozvěděli jen pár desítek minut po startu, závada související se servisním modulem nebyla zveřejněna až do čtvrtečního zasedání bezpečnostního a poradního výboru NASA. Jakmile se o tom dozvěděla veřejnost, okamžitě se tato zpráva rozšířila po sociálních sítích a nezřídka se objevovala kritika transparentnosti celého programu na dopravu astronautů soukromými loděmi.
Zdroj: https://mk0spaceflightnoa02a.kinstacdn.com/
NASA se proto rozhodla na pátek svolat telekonferenci pro média, které se zúčastnili manažeři Boeingu a vrcholní představitelé státní agentury. Jim Bridenstine, administrátor NASA, hned na začátek uvedl, že vyšetřovací tým je momentálně v polovině své práce a jeho výsledky by měly být představeny do konce února. Pak prý bude možné říct mnohem víc. „Není obvyklé, abychom dělali konferenci pro média o vyšetřování, které ještě probíhá, ale rozhodli jsme se tak v zájmu transparentnosti,“ uvedl administrátor NASA. Ten dále uvedl, že v rámci mise OFT nastalo několik anomálií, ale vyšetřovatelé tvrdě pracují na jejich odhalení a i na návrzích, jak jim příště předejít.
Zdroj: https://mk0spaceflightnoa02a.kinstacdn.com/
Douglas Loverro, přidružený administrátor NASA pro pilotovaný průzkum a provoz uvedl, že softwarové chyby, jsou pouze symptomy. Skutečným problémem bylo podle něj „několik procesních pochybení“. Kathy Lueders, programová manažerka programu CCP (Commercial Crew Program), uvedla, že chyba časovače nastala i proto, že nebyly splněny softwarové požadavky pro danou situaci. „Byly vyžadovány dva parametry, ale pouze jeden byl zakódován do letového softwaru,“ uvedla Lueders, která se vyjádřila i ke druhé programové chybě: „Pokyny pro přípravy na vstup do atmosféry byly špatně naprogramovány.“
Zdroj: https://i.ytimg.com/
Ze všech mluvčích asi nejvíce detailů přinesl Jim Chilton z Boeingu. Ten hned na začátek uznal, že by si všichni v jeho firmě přáli, aby ten software udělali lépe. Z jeho slov vyplynulo, že na druhou softwarovou chybu (související se servisním modulem) by se nepřišlo, pokud by se neobjevil problém na časovači. Po první objevené závadě totiž začala zevrubná analýze kódu, která odhalila i druhý zmíněný problém.
Chilton také vysvětlil, kde se vzal jedenáctihodinový rozdíl v čase u první chyby. Starliner měl za úkol přečíst aktuální čas ve chvíli, kdy je zastaven odpočet v čase 4 minuty do startu. Vinou chyby v kódu ale přečetl čas dříve než měl – přesně o 11 hodin. Druhá softwarová chyba souvisela s kódem pro řízení ventilů. Vinou této chyby by trysky na servisním modulu nebyly po oddělení aktivní a nemohly by volný servisní modul odstrčit od návratové kabiny – v extrémním případě by se mohla obě tělesa srazit. Jak dodala Kathy Lueders, to mohlo způsobit i ztrátu lodi Starliner. „Z toho by nebylo nic dobrého,“ potvrdil její slova i Jim Chilton.
Zdroj: https://www.nasaspaceflight.com/
Kromě dvou zmíněných softwarových závad se objevil i jeden problém na pomezí softwaru a hardwaru, který souvisel s anténou. Zatímco první dvě zmíněné chyby už mají odhalené důvody, u této závady prozatím zůstává příčina nejistá. Víme však, že spojení pozemního střediska s lodí bylo přerušované. Na konferenci zaznělo i předběžné naznačení podstaty problému. Ten byl přirovnán k frekvenčnímu rušení, které se někdy objevuje u mobilních telefonů. Boeing na konferenci potvrdil, že se vrátí zpět ke kódu. Proběhne tedy analýza několika milionů řádků kódu a NASA zase zreviduje své požadavky na testování softwaru firmy Boeing.
Zdroj: https://mk0spaceflightnoa02a.kinstacdn.com/
„Chyby ve fázi návrhu a kódování byly prvotními viníky obou chyb,“ uvedla NASA v online prohlášení, kde dále píše: „Kromě toho nastaly chyby v testovací a ověřovací fázi, která měla odhalit nesrovnalosti ještě před startem. Ačkoliv obě chyby mohly vést ke zvýšenému riziku nebo ztrátě lodi, akce týmů z NASA a Boeingu ale dokázaly tyto problémy vyřešit a dostat loď Starliner bezpečně na Zemi.“
Inženýři zatím stále vyšetřují příčinu problémů v komunikaci, který znemožnil letovým řídícím rychleji opravit chybu s časovačem. „Softwarové chyby, zvláště u komplexního programu kosmické lodi nejsou nečekané,“ najdeme v prohlášení NASA, kde se hned vzápětí píše: „Ale bylo tu hned několik úrovní kontroly. Procesy kontroly kvality firmy Boeing měly, nebo aspoň mohly odkrýt tyto závady. Kvůli těmto problémům nalezeným v designu, kódu i samotném testování softwaru, budou vyžadována systémová nápravná opatření. Tým již identifikoval sadu 11 nápravných opatření, která dostala nejvyšší prioritu. V dalším průběhu vyšetřování bude identifikováno více.“
Zdroj: https://www.nasaspaceflight.com
Od vyřazení raketoplánů z provozu v roce 2011, je NASA nucena kupovat křesla v ruských lodích Sojuz, aby se na ISS (a zase zpět na Zemi) dostali američtí astronauti, ale i jejich kolegové ze „západního“ segmentu stanice. Aby skončila závislost na ruských lodích, vybrala NASA v roce 2014 Boeing a SpaceX, které si mezi sebe rozdělily 6,8 miliardy dolarů na vývoj nezávislých kosmických lodí, které se stanou prvními novými americkými prostředky schopnými vozit posádku na oběžnou dráhu od 70. let, kdy se zrodily raketoplány.
Zdroj: https://pbs.twimg.com/
V rámci kontraktu za 2,6 miliardy dolarů vyvíjí SpaceX loď Crew Dragon, kterou bude na oběžnou dráhu vynášet raketa Falcon 9 patřící stejné firmě. Boeing připravuje loď Starliner v rámci kontraktu za 4,2 miliardy amerických dolarů. SpaceX provedla úspěšnou nepilotovanou testovací misi v březnu 2019, ale v dubnu pak utržila významné zpoždění když stejný exemplář Crew Draognu, který pobýval u ISS explodoval při pozemní zkoušce před testem únikového systému za letu. Muskova firma se z nehody vzpamatovala a v lednu úspěšně provedla zkoušku únikového systému za letu. Očekává se, že by Crew Dragon mohl vynést dva americké astronauty — Douglase Hurleyho a Roberta Behnkena — na jejich zkušební misi k ISS někdy během letošního jara.
Zdroj: https://www.nasa.gov/
Nepilotovaná testovací mise Starlineru z loňského prosince dopadla ve srovnání s obdobnou misí v podání SpaceX o poznání hůře a je hodnocena jen jako částečný úspěch – vinou v článku zmíněných softwarových chyb a komunikačního problému. Zatím stále není jisté, zda NASA Boeingu nařídí opakování nepilotované testovací mise, nebo zda firma dostane povolení jít rovnou na pilotovanou testovací misi. V takovém případě by ale k letu s lidskou posádkou muselo dojít až poté, co budou do Starlineru implementována příslušná korekční doporučení. Ta budou mít za úkol zajistit, aby se nemohly opakovat chyby, které nastaly při nepilotované testovací misi.
Zdroj: https://live.staticflickr.com
Zdroje informací:
https://spaceflightnow.com/
https://blogs.nasa.gov/
https://twitter.com/
https://www.nasa.gov/
http://forum.kosmonautix.cz/
Zdroje obrázků:
http://spacenews.com/wp-content/uploads/2016/10/cst100-orbit-879×485.jpg
https://www.nasa.gov/sites/default/files/thumbnails/image/cms_ksc-20191121-ph-csh02_0080.jpg
https://live.staticflickr.com/65535/49205202267_2279f574fc_k.jpg
https://mk0spaceflightnoa02a.kinstacdn.com/…/48958095431_d124b7660c_4k.jpg
https://mk0spaceflightnoa02a.kinstacdn.com/wp-content/uploads/2020/01/starliner1.jpg
https://i.ytimg.com/vi/mmoMjEgeFKM/maxresdefault.jpg
https://www.nasaspaceflight.com/wp-content/uploads/2020/01/OFT-landing-3-1200×807-1.jpg
https://mk0spaceflightnoa02a.kinstacdn.com/wp-content/uploads/2019/11/roll1.jpg
https://www.nasaspaceflight.com/wp-content/uploads/2019/02/201915-115808.jpg
https://pbs.twimg.com/media/EOhBvZOX0AAEdqQ?format=jpg&name=medium
https://www.nasa.gov/sites/default/files/thumbnails/image/49258250868_0e5795b4a9_3k.jpg
https://live.staticflickr.com/65535/48720076396_e508466494_k_d.jpg
Fakt by ma zaujimal suvis s MCSA v 737, lebo tam dosli na velmi podobne chyby, teda nie samotne chyby v kode(ako je napisane v clanku tym sa vyhnut neda), ale v procese kontroly.
A teda je to systemove zlyhanie firmy a jej manazmentu.
Inak po tomto sa budem velmi divit ak im nasa nenariadi opakovat let bez posadky. A ak nie, tak astronautom co do toho sadnu.
Ospravedlnujem za sa flame, ale k tejto teme sa to asi velmi inak neda, uvidime ake porblemy bude mat 777x.
Však také kvůli několika závažným problémům napříč firmou byl sesazen CEO Boeingu. Upřímně si myslím, že Boeing bere stát až moc jako svou dojnou krávu a nedělá tak důslednou práci jako kdysi dělal.
Už několik let pracuji jako softwarový vývojář a vím jak lehce lze udělat chyba, obzvlášť pokud na vás někdo tlačí s deadlinem. Návrh i vývoj je vždy iterativní proces. Téměř nikdy napoprvé nevytvoříte nejoptymálnější řešení. Pokud je ale firma dobře nastavena, má všechny články (lidi + procesy) v pořádku, pak se musí přijít na všechny problémy. Obzvláště u tak kritických systémů, které prostě musí fungovat perfektně, testování pak klidně může probíhat i déle, než vývoj kódu samotného.
Ještě jedna zajímavá poznámka; zevrubné testování by nikdy neměl dělat člověk, nebo tým, který danou věc vyvýjel.
Toto je trocha iny druh programovania. To su kriticke systemy, tam by malo byt dost vela veci dost striktne nalinkovanych este skor, nez sa k veci dostane programator. Velmi zjednodusene a nadsadene by sa dalo povedat, ze kazdy riadok kodu by mal byt „pokryty“ jednou, mozno aj dvoma stranami poziadaviek, analyz a testov.
Jako hlavní problém vidím to, že kulturu této firmy řídí byznys a finanční manažeři, namísto toho, aby pro firmu byla primární oblast rozvoje technologií.
Jinými slovy, Boeing se stal z technologické firmy víceméně burzovní byznys společností, kde finanční (dotační) a byznys procesy mají nejvíc pozornosti a technický a vývojářský personál je odsunutý (včetně rozhodování o termínech a potřebných financích) na druhou kolej. Z toho vyplývají i procesní chyby týkající se technologií, protože o nich rozhodují nekompetentní lidi.
Bude to mít Boeing ještě velmi těžké v konkurenci, ale samozřejmě ho stále drží nad vodou obrovský vojenský rozpočet, kam žádná komerční konkurence nedosáhne.
@Mattonius: bylo by dobré si občerstvit pravidla, jak psát y/i, přece jen vyvÝjel nebo nejoptYmálnější trhá uši i oči….
Nojo, v ČR už nějakou dobu nežiju 😀 Vynasnažím se
K tomu slovu ještě jedna poznámka: pokud je něco optimální, nemůže to být „více“ optimální. Slova „optimálnější“ nebo dokonce „nejoptimálnější“ nemají smysl (i když je bohužel často vidíme, a to i v odborném tisku).
Tady šlo o něco jiného než u 737 MAX. Tam to byla spíš chyba návrhu (nedostatečná redundance a velký rozsah regulace). U Starlineru to vypadá na čistě softwarové chyby. Samozřejmě to může mít společný jmenovatel ve formě procesních pochybení, což není nepravděpodobné.
Aj navrh, ale aj programovanie.
Ked proti mcas zasiahol pilot tak standardne by sa mcas malo deaktivovat. Nedaktivovovalo a piloti bojovali proti sw, a boli bez sance. Hlavne ked o nejakom mcas ani netusili.
Ale ano, navrh bol este tragickejsi, a aj ten navrh mal podliehat kontrole. Ktora tiez bola evidentne slaba.
Zas pozor. Ono je teď v módě házet všechno na Boeing, ale to není úplně spravedlivé. Ano, MCAS nebyl navržený ideálně. Nicméně není to jediný systém, který stabilizátor ovládá. Proto už od prvních sedmičkových Boeingů existuje postup pro případ, kdy se automatické ovládání stabilizátorů „zblázní“ („runaway stabilizer“). Je dokonce tak důležitý, že je v kategorii „memory items“, tedy postup, který musí pilot umět provést zpaměti, bez konzultace s příručkou.
Ten postup funguje samozřejmě i pro případ, kdy se zblázní MCAS. Pilot nemusí detekovat, že se mu zbláznil MCAS, dokonce ani nemusí vědět, že tam nějaký MCAS je, stačí provést tenhle postup. Ostatně, těch případů, kdy MCAS zazlobil bylo víc. Jenže v nich posádka zareagovala správně postupem pro runaway stabilizer a situaci vyřešila. Takže se o nich v novinách nedočtete.
Jak říká klasik, letecká nehoda má málokdy jen jednu příčinu, většinou jde o nahromadění nešťastných událostí. A nejinak tomu bylo i u těch nehod. Třeba když si rozeberu tu druhou:
1) MCAS nebyl nadesignovaný moc dobře.
2) MCAS, respektive čidlo náběhu zazlobilo už při předchozím letu, ale technici nad tím mávli rukou a poslali letadlo na další let.
3) Při něm začal zlobit v poměrně nízké výšce (tuším, když se zasunuly klapky), tedy piloti měli dost malý manévrovací prostor.
4) Chvíli jim trvalo, než pochopili, že jde o runaway stabilizátor. Spustili proceduru, která dalším pohybům stabilizátoru zabránila.
5) Pokusili se stabilizátor vrátit ručně. Jenže s časem se letadla a tedy i síly, které na VOP působí zvětšily, zatímco ovládací kolo se nezvětšilo a tak je na pohnutí s nim potřeba dost síly. (Protože ten postup se moc často nepoužívá, tak to nikomu doteď až tak moc nevadilo.)
6) Řešením by bylo provést „rollercoaster“ manévr, kdy by letadlu povolili klesat, VOP by se odlehčily a bylo by možné stabilizátorem pohnout. Proč jej neprovedli je otázka. Prý se při výcviku už moc neučí, nebo se možná báli, že mají příliš malou výšku (?)
7) Tedy zvolili znovu zapnout automatický trim, ačkoli to procedura pro runaway stabilizátor výslovně zakazuje. Čímž porouchaný MCAS opět spustili a ten poslal stroj definitivně k zemi.
Hodit to celé na Boeing je sice lákavé, ale jak ukazuje situace výše, těch selhání bylo v tom případu víc.
Tedy:
– Piloti proti MCAS nebyli bez šance, naopak, byli vycvičeni si se situací poradit, nebo tak alespoň podle manuálů Boeingu vycvičeni být měli.
– MCAS je určený pro úpravu charakteristik letadla v určitém letovém režimu, tedy že by „pilot zasahoval proti MCAS“ nedává moc smysl.
Ok, tak slabsi piloti su bez sance.
A ano dobre pisete ze problem sa prejavil velakrat predtym a boeing o tom vedel a nic. Pohodicka.
To ma tom stve asi najviac.
Doteraz nikoho nevysetruju kvoli takemu obrovskemu zlyhaniu.
Byvaly ceo si zobral za dobru robotu 60milionov, namiesto pobytu za mrezami.
Chápu, že to souvisí s Boeingem, ale zkuste, prosím, vrátit debatu trochu blíže Starlineru, díky! 😉
Zpovzdálí sleduji dění v létání. Tak třeba že je potřeba mnoho dopravních pilotů a kde vzít a nekrást, tak se zjednodušuje výcvik (snad se o tom občas píše na http://www.aeroweb.cz).
Připomíná mi to článek „piloti nebo strojníci“, snad se ještě najde na internetu, svého času se tvrdilo, že to není pravda.
Co se týká síly potřebné k ručnímu ovládání něčeho – svého času mne to zajímalo v oblasti průmyslové automatizace, když třeba je potřeba honem něco zavřít kvůlu hrozící katastrofě a dálkové ovládání nefunguje, tak jakou silou nebo momentem se může točit klikou (jednak, aby to normální člověk zvládl, jednak aby se vědělo, kdo za to může, když si někdo pomůže, na kliku připevní násadu od krumpáče, zabejčí a něco ulomí). Nevím, zda to definuje nějaká norma nebo předpis – já jsem hledal a nic nenašel.
Yarda pro představu kolik síly je potřeba doporučuju tohle video.
https://youtu.be/aoNOVlxJmow?t=712
A tento článek to celé hezky shrnuje.
https://www.nytimes.com/2019/09/18/magazine/boeing-737-max-crashes.html
Je to tak smutné, že mi nezbývá než to trochu odlehčit:
Od vzniku firmy SpaceX je jaksi celosvětově těžší najít špičkové programátory. A to nemluvím o tom, kolik jich schlamstli v Tesle, kde se píšou software pro autonomní řízení 🙂
Věřte, vím o čem mluvím – zrovna jsem instaloval jakýsi velmi populární operační systém z originálního média na fungl nový počítač, a vyšlo to až na čtvrtý pokus. U Boeingu věřím, že jim to vyjde na ten druhý.
Nemyslím si, že je to kvůli Tesle a Space X. Spíš kvůli průmyslové revoluci 4.0. Automatizace proniká do všech odvětvích a hlad po programátorech tak neutěšeně sílí. Bohužel, v USA i v EU frčí trend humanitních oborů, takže místo abychom vypěstovali novou generaci konstruktérů a programátorů, tak školství produkuje řady ekonomů, právníků a filozofů. A ti letadlo do vzduchu nedostanou.
No hlavně dnešní SW je mnohem rozsáhlejší (složitější) než před 20-ti lety. A požadavky udávají manažeři kteří často nemají ani technické vzdělání a běžně vymýšlí spoustu zbytečných věcí a funkcí které se v reálu ani moc nevyužijí, zato vše brutálně zkomplikují. Není divu že je vše plné chyb. SpaceX má zásadní výhodu že tam inženýr znamená víc než manažer. A jak je vidět, software tam umí opravdu lépe. Pro mě pokud manažer nemá technické vzdělání, je na úrovni ostatního humanitního vzdělání.
SpaceX má zásadní výhodu že tam inženýr znamená víc než manažer. A jak je vidět, software umí opravdu lépe. Pro mě pokud manažer nemá technické vzdělání, je na úrovni ostatního humanitního vzdělání.
Souhlas, tohle bude jádro pudla. Souvisí to i s hlubokým navázáním na dotace, stát a politiku.
Děkuji za skvělý článek. Jsem zvědav na výsledky vyšetřování. Odhaduji, že dojde k významnému zpoždění u Starlineru. Možná rok. A to není dobré. Nevěřím, že příště již pošlou lidi na ISS. Ztrátu posádky si nemohou dovolit riskovat. Dle článku je problém hlubší než jen ty zatím odhalené SW chyby. Chyb v SW (které nedostaly šanci se projevit) tam bude rozhodně víc. Skutečná příčina v procesech je komplikovaný problém. A ty jsou prvni věcí, co se musí změnit, zabere to čas a znamená to „zásah“ do vývojového týmu. Je vidět, jak je vývoj v kosmonatice komplexní a že to je ten nejvyšší možný level jak v technice, tak SW, tak v lidech…
No, okrem toho, ze by si NASA malo dat pozor do akeho stroja posadi posadku, by si mali dat pozor aj na PR. Pri kauze Boeingu a MAX737 si nakoniec okrem Boeingu samotneho svoj podiel obvineni zlizla aj FAA za to, ze na problemy mala prist, kedze certifikuje lietadla.
NASA tiez, pokial viem, nejake audity odlozila s tym, ze nie su potrebne a to by sa im spatne mohlo vypomstit. Niekto by to mohol dat dokopy a prehlasit, ze ak by sa audit spravil, mozno by sa na problemy prislo.
Inac ale z toho, ze ten test nedopadol dobre si tazku hlavu nerobim. Je to test a testy su na testovanie. Zavazne je tam to, o aky druh zavad sa jedna. Takyto druh problemu v SW by mal byt na simulatore odhalitelny.
Takže ofociálně máme 2 chyby a 1 problém/chybu. Tedy 3anomálie, o kterých víme.
Pokud budou nyní dělat onu hloubkovou kontrolu, tak nevím nevm, zda to do konce května stihnou (ST mise s testoposádkou) nebo jim nařídí opakování, a pak je zpoždění jisté.
Nezávidím NASA lidem rozhodování. Pokud bude opakování budou kritizování za zpoždění a někdo jistě použije argumentaci na jejich mírnější přístup a pokud poletí na ostro a něco se semele, tak budou v NASA padat hlavy.
jak dlouhe jsou objednaci lhuty Sojuzu?
Tak nevím. Když pominu počet chyb které přiznali tehdy (1 chyba) a kolik je jich zatím přiznáno/nalezen o teď (3 chyby), tak hlavní argument proč by se možná nemusela opakovat mise OFT byl ten že by posádka nebyla ohrožena, pouze by se nedostala na ISS. Nyní přiznali hned několik ohrožení posádky a i tak stále uvažují o tom že by se mise OFT nemusela opakovat a rovnou by mohla následovat pilotovaná mise. Přijde mi to hodně zvláštní…
hlavna otazka ani nie je ci opakovat alebo neopakovat misiu, ale ci je potrebne uplne zmenit manazment vyvoja softveru pre starliner. pocet a zavaznost chyb, ktore sa objavili pocas OFT svedci o vaznych nedostatkoch v tejto oblasti.
ak jeden let stoji radovo sto milionov dolarov a v buducnosti bude nosit aj ludi, tak testovanie a opravovanie „za pochodu“ nie je nastastnejsia cesta.
pri citani clanku som si hned spomenul na tuto humornu scenku: https://www.youtube.com/watch?v=75wa8Lx4yc4
No já bych za dost riskantní považoval i opakování mise. Takovýhle bastl bych teď k ISS rozhodně nepustil. Aspoň dokud neudělá několik cvičných příletů a odletů někde daleko v pustém vesmíru, kde nemůže nic rozbít.
Jedine SpaceX!!!!!!!!
Takovéhle výkřiky naznačuji myšlenkový postup, který se nedá označit za logicky správný.
Jako fanda prohlasuju, trosku vic a rozumem a kriticky. V pripade techniky nikdy neni dobre opustit vlastni rozum.
Celý svet není logický,takže ma Váš názor fakt nezaujíma….
No a ostatní zase ten váš… a troufám si tvrdit, že budou v přesile.
No a hlavne ten váš,hovorím,že mi to je jedno…
Tímhle stylem nemá cenu chodit do internetových diskuzí. A pokud někde je potřeba logika a střízlivé myšlení, je to raketová technika.
No jo no, to je tak když si manažeři Boeingu myslí, že když přesunou vývoj SW do Indie, že tím ušetřili …
Jenom pro odlehčení:
Můj kamarád, angličan žijící tady v ČR, pracuje v zahraniční firmě a má na starost vývoj celkem složitého SW – vedení firmy hlavní vývoj přesunul do Indie a od té doby když se s ním vidím, tak jenom nadává, jak je to s nimi hrozný – Indové nepochopitelně (bývalá britská kolonie) nerozumí anglicky, jsou arogantní, nafoukaný a vůbec nechápou co mají dělat. Takže všechno co od nich dorazí vůbec nefunguje nebo blbě a pak to tady musí šikovní český kluci po nich opravovat 🙂 Takže jak se s ním vidím, srší kromě nadávek typickým černým britským humorem na téma Indové a vývoj SW 🙂
Nechci se kolegu z Indie zastávat, ale z mé nekolikaleté zkušenosti spolupráce s nimi mi většinou vyplývá že se jedná o chyby v nastaveni procesu popisu práce firmy, která práci do Indie zadává a zároveň o nepochopení, jak v Indii pracují.
Je potřeba si uvědomit, že na obsazení jednoho pracovního místa je tam velká nabídka dalších potenciálních pracovníků, kteří rádi práci převezmou a čekají na svou příležitost. Nejen díky tomu si zaměstnanec nedovolí udělat cokoliv mimo nastavený proces a když je v procesu chyba a nám to nedává smysl, protože výsledkem vykonané práce je paskvil, oni jsou svými nadřízenými, svou výchovou a obavou ze ztráty zaměstnání, nuceni jet přesně podle nastaveného procesu. V čechách se zamyslíme, změníme si to tak, aby výsledek byl správně, ale v Indii je takovýto přístup považován za hrubé porušení pracovních povinností.
Dále pak funguje je to, že když se zaměstnanec osvědčí, že je na něj spoleh a vykonává svou práci na výtečnou, postupuje v hierarchii výše, což je dobré pro zaměstnance, ale většinou špatné pro projekt, protože neexistuje způsob jak přesvědčit povýšeného zaměstnance, aby předal své zkušenosti nástupci a většinou jste opět na začátku a vše se takto opakuje.
Souhlasím s Vámi, že je taková spolupráce těžká a někdy si v duchu říkám, že i nesmyslná, ale i tato mince má dvě strany.
Osobně jsem se setkal s Indy v jedné velké korporaci velikostí podobné Boeingu. Po určitém čase jsem zjistil, že když po nich něco chci tak musím mail napsat:
1. pokud chci dvě věci tak vyřeší pouze tu která je uvedena jako první. A to tím neblbějším způsobem.
2. pokud jeden z úkolů byl obtížnější, tak ho nevyřeší nikdy.
Tohohle jsem začal využívat a psal jsem jim maily tak aby ten úkol, který chci nutně vyřešit, byl jednodušší a psaný v první větě. Prostě voňaví medvídci. (takhle jsem jim řikal)
Také toto dobře znám a jsem názoru, že zde by mohl být kámen úrazu v tom, jak jsou hodnocení, jestli za vyřešení a nebo za úkon…
To sa teda vobec nezhoduje s mojou skusenostou. Je mozne, ze je to tym, ze som pracoval priamo s ludmi z indickej pobocky velkej US firmy a nie outsourcingovou firmou.
Kazdopadne tito boli tvrdohlavi, ignorantski, robili si vsetko po svojom (co vacsinou znamenalo cestu mensej snahy u nich, aj ak sa mal zvysok ludi postavit na hlavu) a ked to teda nakoniec nevyhnutne padlo na hubu, tak radovo desiatky hodin pred deadlajnom zhanali pomoc kade-tade.
A kedze samozrejme pretlacame timoveho ducha, bolo nekorektne im povedat nie, do tohto pruseru ste sa dostali sami.
Pánové, neuniklo vám téma dnešního článku? Proč musíte tlacháním o zkušenostech s indickou pracovní morálkou plevelit diskuzi o Starlineru?
Co takhle se pod ta moudra podepsat a přenést tu debatu na FCB atp.?
Nemyslím si, že vývoj software Starlineru zadali někam např. do Indie. Jsou to klíčové technologie národního zájmu a pochybuji, že to nebude smluvně ošetřeno. I kdyby ten Ind dělal na nějakém anonymním bloku kódu, tak pořád je to chráněná technologie – tohle není komerční letadlo .
Boeing začal jít špatným směrem od převzetí McDonell Douglas, do té doby to byla firma inženýrů. Následně se z toho stala korporace se vším všudy.
Kdo někdy programoval tak ví , že napsat samotný kód je to nejmenší – zásadní je to otestovat a dodat 100% funkční kód.
A jak je vidět z úniků vyšetřování a vlastně i oficiálních sdělení, tak tam jsou naprosto zásadní boty, které v software tohoto účelu v de fakto finální verzi (pro OFT) nemají absolutně co dělat. Jasně můžou tam být nějaké chyby, nicméně zde jsou ty chyby systémové a potencionálně fatální pro posádku.
Jako jak může někdo nepřijít na chybu v kódu při testech , když ji pak odhalí během 26 hodin na orbitě, „blbým“ procházením kódu a to měli štěstí, že díky první chybě s časovačem začali ten kód vůbec procházet…
A tady je názorně vidět ten rozdíl mezi SpaceX a Boeing. Ve SpaceX dostaneš vyhazov ani nevíš jak, stačí když nejsi užitečný – protože Musk chce a snaží se dělat s nejlepšími lidmi v oboru a nabízí jim volnost a chce výsledky, ale zároveň rozumí tomu co po lidech chce a klidně s nima ten problém řeší – když to situace žádá. Nedělám si iluze , že to bude lidumil – stejně jako Jobs nebyl – ale oba mají společný tah na branku a schopnost obklopit se schopnými lidmi.
V Boeingu je to hold korporátní klasika, hlavně nevyčnívat , místo mám jisté , peníze tečou, no stress…, pošlu report, že vše OK … jsme přece Boeing a „If it ain’t Boeing, I ain’t going“
To je skoro až neuvěřitelné.
Od začátku mi připadá problém s „časovačem“ podivný a tohle vysvětlení o načtení špatného času z Atlasu je ještě divnější. Ten software v sobě nemůže mít snad ani jednu vnitřní kontrolu. To i ta automatická pračka…
A evidentně to ani jednou pohromadě neotestovali.
Fakt má software několik milionů řádků? To by ledacos vysvětlovalo.
S těmi řádky bych to neviděl jako nereálné ( 20% – 30% budou klidně komentáře v kódu) . I nějaký menší řídící automat pro průmysl typu Logo má klidně řádově vyšší tisíce řádků a to dělá docela jednoduché věci…
Ale ono jít řádek po řádku, je sice v tomto případě už důležité. Akorát by měli hlavně zapracovat na testovacím oddělení a scénářích pro testy. Např. synchronizování hodin z nosiče „facepalm“ .
A nebo se nakonec ukáže, že to postavili na Windows Embedded 😀 , v lepším případě nějaké volné distribuci Linuxu (vtip)
Tak ta loď taky nedělá nic extra složitého. Před padesáti lety Apollu stačilo 72 kB paměti, novějšímu Sojuzu tuším 256 kB. Ale netuším, kolik řádků kódu tomu zhruba může odpovídat. Ale miliony to asi nebudou, ne?
Ono tehdy se v programovalo o dost „chytřeji“ a počítač dělal přesně to co programátor chtěl. Používal se jazyk assembler. Dnes se používají většinou v rámci urychlení práce vyšši programovací jazyky a složité systémy / objekty, v kterých se snadno chyba ztratí 🙁
Jinak celý apollo system i naváděcí program je volně k disposici na githubu:
https://github.com/chrislgarry/Apollo-11/
Souhlasím. Kód, který dělal totéž, se dal v assembleru naprogramovat na několik řádků, tak ve vyšších programovacích jazycích mnohonásobně narostl. Já začal ještě za totality na Attari s několika kB paměti a tak jsem musel bojovat o každý B! Prostě nouze nás naučila programovat úsporně a přehledně, takže chyba se brzy našla.
Ještě větším problémem je týmové programování, zejména sladění individualit spolupracujících programátorů. Zde je asi největší zdroj programových chyb
To sa neda porovnavat. Program na Atari nerobil „totez“, co robia dnesne programy. Staci sa pozriet napr. do knihy Kernighan Ritchie: System Unix a jazyk C a clovek velmi rychlo zisti, ze aj nieco ako rekurzivne zmazanie adresara bol v tej dobe luxus. Programy (spociatku napisne v ASM, C prislo az neskor) to proste nevedeli.
To iste plati aj pri roznych embedded systemoch. Kontroller elektrickych okien u koncernu, kym sa stal sucastou komfortnej jednotky mohol mat nejaky hlupy 8bitovy mikrokontroller a radovo jednotky kB kodu. Lenze okrem hybania oknom a naucenia dobehu nic nevedel.
Dnesny kontroller elektrickej strechy na kabriolete bude mat radovo okolo pol MB kodu a z uzivatelskeho pohladu robi tiez v podstate stale to iste – otvara a zatvara strechu.
Podstatny rozdiel je v tom, ze z toho 20 rokov stareho kontrollera elektrickych okien nedostanem absolutne vobec nic, zatial co na moderny kabriolet ide napojit diagnostiku a vytiahnut si z neho live prevadzkove data, testovat ho a tak celkovo si lepsie pokecat.
Mozete mi kludne verit, ze toto by fakt nikto, ale nikto nechcel programovat v assembleri, pretoze aj v C-cku je to hromada kodu. Milion riadkov asi nie, ale vyssie stotisice urcite.
K ventYl 10:51:
Pravda je poněkud jinde, samozřejmě programy na Attari a dnešních počítačích jsou naprosto rozdílné. Ale všechny ty dnešní programy končí přímo nebo nepřímo ve vygenerování „strojních“ programů pro procesory. V tom nejvnitřnějším jádře je to pouze v přesouvání mezi registry, v rolování registrů a jednoduchých logických operacích. Takže když jsem to naprogramoval ve „strojáku“ je to stejné po překladu z vyššího programu, jen kratší.
Samozřejmě dnes to pro rozsáhlost nároků na programy nejde a není účelné, v tom máte pravdu.
Dnešní doba je fakt řádově jinde, zrovna jsem procházel kód od VW rádia kvůli češtině a ten firmware má cca 260MB a to je jen hloupé autorádio (ano nejde to úplně srovnávat protože na základní vrstvě běží linux a rádio je nadstavba – ale názorně to ukazuje jak se dnes programuje).
Prostě dnes se píše software naprosto jinak a napsat řídící software v ASM v dnešní době je časově nereálné 🙂 a zoufale neefektivní.
Takže ten jejich „milion řádků“ je vlastně OK 🙂
Samozřejmě je jiná doba, ale ty programy dělají téměř to samé a vytvoření programů pro mise Apollo určitě nebylo časově náročnější než dnes – viz rychlost realizace programů Apollo a Artemis.
Když něco podobného dnes v pohodě zvládají zásobovací lodě pro ISS několika států a firem tak ty problémy se Starlinkem svědčí o tom, že v Boeingu něco není v pořádku.
Ještě bych zmínil automatické testy, ty by na takovémto projektu měli zabírat určitě víc, než funkční řádky kódu, 60-75% klidně i víc. Dost řádků zabere i to grafické zobrazení letových údajů pro posádku.
Tak zrovna ovládací systém pro posádku bude úplně zvlášť než samotný řídící systém lodi a nemusí s ním mít moc společného, kromě nějaké komunikační sběrnice/rozhraní.
Tak pod řídící systém to patří – na základě toho se dá loď pilotovat ručně. Víme ale pendrek co do toho Boeing počítá a co ne, takže jen spekulace (jak moje, tak Vaše).
vola sa to „too big to fail“ a zda sa ze tato choroba sa netyka uz len financnych institucii
akonahle si niekto zacne mysliet, ze sa mu vsetko prepecie, a ze vztahy so statom, regulatormi a kongresmanmi su viac ako poctiva konkurencia kvalitou, tak prusvih je na obzore
nie je dovod, preco by aerokozmicke a zbrojarske firmy nemohli zazit svoj „detroit-moment“. Stat ich dokaze chranit len do urcitej chvile.
Konstrukčně je asi Starliner robustnější a bezpečnější, což je ovšem celkem nanic, pokud mají v SW zásadní chyby ! Takže uvidíme co bude dál, jestli udělají nějaké další testy plus prověření SW a budou opakovat misi, jak se to celé protáhne. Ono je vidět že stavět pilotované loďi není žádná sranda. Ty zásadní pochybení s možností zničení lodě měli teď jak Boeing i SPACEX, dříve Apollo, Sojuz i STS. Proto tedy nevěřím že třeba něco ještě složitějšího a krkolomějšího jako Starship bude v nejbližších desetiletích pilotované.
Myslím že boeing má oveľa vetsi problém ako malo SpaceX. Pretože nehoda SpaceX bola nečakaná a nikto nevedel že titán sa v istých prípadoch správa neštandardne. Ale boeing má problém ktorý by sa dal dôkladnou kontrolou odhaliť. Ale bohužiaľ to vyzerá že celá firma má zlý manažment nie len letecká divízia. V prípade 737 Max jeden zamestnanec napísal že to lietadlo navrhli klauni na ktorých dohliadajú opice. Chápem že SpaceX funguje úplne inak ale boeing je oveľa drahší a očividne šetrí všade kde sa dá aj na miestach kde sa to neoplatí. Manažment vidí len čísla a absolútne nechápu potreby inžinierov a nevedia kde sa dá kopu ušetriť. SpaceX síce nemá hlavný cieľ zisk ale ajtak ho dosahujú a funguje to tam lepšie keďže všetci spolu komunikujú a nevznikajú zbytočné náklady. Ako keď jeden tím vyrieši problém spravila úpravu ale zároveň spôsobia problém inej skupine ktorá to znova rieši samostatne.
1) ta reakce překvapení nebyla. Překvapení byla ta kapička co poškodila ventil a obnažila čistý titan
2) výrok ohledně opic se měl týkat simulátoru
3) vy znáte výroční zprávy SX, že je v plusu? To by EM asi nemusel ukajovat že svého koláče akcií
O tom, že Boeing má problémy s kontrolou se ale nepřu.
Jen technicky:
Ad 2) “This airplane is designed by clowns, who are in turn supervised by monkeys,” an employee wrote in an exchange from 2017.
Taky to beru zpět, k simulátoru byla hláška „Jedi mind tricks“