NASA: Starliner-missie mislukte door softwareproblemen en gebrek aan toezicht

De NASA heeft een grondig onderzoek naar de mislukte Starliner-missie van eind vorig jaar afgerond. De conclusie is dat softwarefouten en een gebrek aan voldoende toezicht hierbij een belangrijke rol hebben gespeeld. De capsule slaagde er niet in om het ISS te bereiken.

De NASA zegt dat het grote onderzoeken naar de mislukte onbemande Orbital Flight Test-missie van december 2019 heeft afgerond en dat wordt doorgegaan met de voorbereidingen voor een nieuwe poging om het ISS te bereiken. Die nieuwe vlucht zal aangeduid worden met de naam Orbital Flight Test-2, waar overigens nog geen lanceerdatum voor is vastgesteld. Steve Stich, de NASA-manager van het Commercial Crew Program, gaf wel aan dat die lancering waarschijnlijk zal plaatsvinden in het laatste deel van dit jaar, schrijft Spaceflightnow op basis van zijn uitspraken tijdens een persconferentie. Kathy Lueders, eerder deel van het programma en nu de baas van Human Exploration and Operations bij de NASA, gaf aan dat er voortgang wordt gemaakt, maar in tegenstelling tot Stich gaf zij aan dat 'vliegen met Boeing' pas volgend jaar zal plaatsvinden.

Het gaat om een afronding van een drietal onderzoeken waarbij de NASA en Boeing gezamenlijk naar meerdere problemen en onderdelen hebben gekeken. Bij het laatste onderzoek werd gekeken naar een probleem bij de periodieke communicatie vanuit de ruimte naar de aarde, wat het vluchtcontroleteam belemmerde om de Starliner tijdens de missie te controleren en commando's te geven. Ook zou dit issue kunnen leiden tot de belemmering van een betrouwbare stemcommunicatie met eventuele toekomstige astronauten.

Eerder berichtte de NASA al over de twee andere afwijkingen die tijdens een test zijn geconstateerd, waar eerder twee aparte onderzoeken aan gewijd zijn. Dat betrof een probleem met de Mission Elapsed Timer-klok, waarbij Starliner door een fout in de code zijn klok synchroniseerde met de raket, voordat de laatste aftelling was begonnen. Daardoor dacht de capsule dat het zich tijdens de afscheiding van de raket op een ander punt in de missie bevond. Het tweede probleem betrof de Service Module Disposal Burn, waarbij het om softwarefouten ging die van invloed kunnen zijn op andere fases van de vlucht. Stich zei dat het van groot belang is dat Boeing de softwareaanbevelingen doorloopt, de juiste aanpassingen doorvoert en de software ook test.

In totaal zijn er 80 aanbevelingen opgesteld, waarbij NASA en Boeing naar eigen zeggen al aardig op weg zijn met de benodigde actieplannen. De volledige lijst met alle details wordt door de NASA gezien als bedrijfsgevoelige informatie en die wordt dan ook niet vrijgegeven, maar in zijn algemeenheid verschaft de NASA wel enige informatie. Zo zijn er 21 punten die gaan over de grotere noodzaak voor betere tests ten aanzien van de integratie van software en hardware, en is er bijvoorbeeld een vereiste van een beoordeling van alle software-eisen met multiple logic conditions. Verder zijn er onder meer zeven aanbevelingen ten aanzien van het updaten van de softwarecode en de fouten met betrekking tot de Mission Elapsed Timer en de Service Module Disposal Burn, aangevuld met de aanbeveling om het antenneselectiealgoritme robuuster te maken.

Tijdens de persconferentie heeft de NASA aangegeven dat het niet voldoende toezicht hield tijdens Boeings softwareontwikkelingsfase voor de Starliner-capsule, schrijft The Register. Dat komt omdat het ruimteagentschap vertrouwen had in de 'meer traditionele' ingenieursmethoden van Boeing en de NASA dacht dat het een goede mate van grip had op het proces van Boeing. De NASA heeft zich tijdens deze fase meer gericht op SpaceX, de tweede speler in het Commercial Crew Program, mede omdat dit bedrijf nieuwere programmeertechnieken gebruikte. Als gevolg hiervan werden de code en de programmeurs van SpaceX meer gemonitord dan die van Boeing.

Het Commercial Crew Program is een programma van de NASA waarbij Boeing 4,2 miljard dollar kreeg toegekend en SpaceX kreeg 2,6 miljard dollar. Hun taak is om elk een eigen manier op poten te zetten om astronauten naar het ISS te kunnen lanceren vanaf Amerikaanse bodem. Elk bedrijf heeft daarvoor zijn eigen capsule en methode ontwikkeld. SpaceX ligt nu ver voor op Boeing, mede omdat het bedrijf er op 31 mei in slaagde om zijn Crew Dragon-capsule aan het ISS te koppelen. Daarmee slaagde het bedrijf van Elon Musk erin om Bob Behnken en Doug Hurley in het ruimtestation te krijgen. Boeing heeft tot op heden nog geen soortgelijke geslaagde onbemande of bemande vlucht uitgevoerd.

Reacties (77)

Hoe goed is de software van SpaceX, zou NASA daar een ander toezicht hebben gehouden?

Er was een AMA op Reddit net na de docking van Crew Dragon 2. Software zit goed elkaar, de UI is met Chromium gemaakt, en ze gebruiken een Linux kernel met code in C++. Real time draait op verschillende micro-controllers.

SpaceX test z'n software met echte hardware, zoals het zou moeten. Dat hoef niet met een echte hardware, maar je kan een opstelling bouwen die lijkt op de real thing.

Boeing maakt een traditionele fout door de testen in stukjes op te hakken. Geloof dat ze elke fase van de vlucht van Starliner apart getest hadden.

EDIT: die AMA is hier te vinden: https://www.reddit.com/r/...are_team_ask_us_anything/

[Reactie gewijzigd door loekf2 op 8 juli 2020 17:17]

Als aanvulling: omdat de software met chromium is gemaakt kunnen ze ook eenvoudig leuke dingen op internet doen. Hier kun je bijvoorbeeld een simulatie van het docking proces uitvoeren:
https://iss-sim.spacex.com/

Volgens spacex is dit de echte interface zoals je deze ook in de dragon capsule vindt. Als is dit natuurlijk handmatig en zou dit alleen in noodgevallen nodig moeten zijn.

Die sim is gewoon een stunt, de gui lijkt welliswaar op de echte, maar het is niet alsof ze de code uit de dragon gui ff een server hebben gezet voor ons om mee te spelen.

Dat we die sim hebben om mee te spelen is niet het gevolg van het feit dat ze chromium hebben gebruikt voor de echte gui. Dat is wat ik probeer te zeggen.

Wel leuk om mee te spelen trouwens.

[Reactie gewijzigd door stereohead op 8 juli 2020 19:49]

Ik denk persoonlijk dat de drempel om de GUI op internet werkende te maken wel een stuk kleiner is als deze op Chromium draait dan wanneer deze met traditionele methoden (zoals Boeing doet) gemaakt is.

Maar inderdaad leuk om mee te spelen

Unit testen zijn in principe ok. Maar blijken opnieuw niet de vervanger te zijn voor volledige regressie tests.

Tenminste, dat is wat ik zo uit het artikel begrijp. Strookt ook met mijn ervaring in software ontwikkeling.

Zelfs in een discipline als Formule 1 zie je steeds terug dat mechanische/aerodynamische onderdelen apart uitstekend door de (geautomatiseerde) tests heen rollen, maar uiteindelijk als onderdeel van het geheel niet goed zijn.

SpaceX is (nog steeds) een vrij nieuw bedrijf te noemen, Naar alle waarschijnlijkheid is er dus sprake van een "verse" code-base, dus niet opgezadeld met technische schuld. Van Boeing verwacht ik dat zij wel hun al eerder ontwikkelde software hebben gebruikt en te weinig rekening hebben gehouden met de technische schuld daarin.

Ik denk dat je wel erg aan het speculeren bent. Zonder bronnen weet je niet hoeveel systemen Boeing wel of niet heeft overgenomen uit andere voertuigen. We weten wel dat Crew Dragon gebaseerd is op Cargo Dragon en daar bestaande (vlucht)systemen van heeft overgenomen. Sure, Cargo Dragon heeft geen 'handmatige' besturing / UI voor astronauten aan boord, maar dan moet er nog steeds geïntegreerd worden met de bestaande vluchtsystemen. Daar kunnen exact dezelfde problemen bij ontstaan zoals je die schetst.

Over Boeing weten we simpelweg minder omdat ze meer gesloten zijn in hun handelen dan dat SpaceX dat is. Wat je inmiddels wel mag concluderen is dat software ontwikkeling in het algemeen bij Boeing wat te wensen lijkt over te laten (737MAX en Starliner als recente voorbeelden). Of dat ligt aan de testaanpak, technical debt of andere factoren valt van buitenaf vrij moeilijk te beoordelen.

Dat 737max debacle had ook temaken met ongetreende programeurs die geen kennis hadden van veilige software. Het was uitbesteed naar een goedkoop bureautje in India:

https://www.businessinsid...ced-737-max-report-2019-6

Moet sterk spul zijn geweest dat die mamagers rookte...

Boeing en ULA zijn echte papieren organisaties. Volgens mij werd tijdens de Demo-2 launch nog een indirecte steek naar ULA gemaakt dat ze daar altijd met het handje de go/no-go moeten doen

Echter, de goede lancering van SpaceX betekent natuurlijk geen afwezigheid van fouten. Het betekent alleen dat in dit geval, dus bij deze condities, alles goed is gegaan.

Ik kan me dit niet voorstellen. Alle grote ingenieurs bedrijven doen zowel unit tests als integration tests. Vaak pleuren ze er nog een encyclopedie aan testen daarachter aan. Ook testen ze allemaal op de hardware zelf.

Of er is iets goed mis bij Boeing op het moment, of die AMA klopt van geen kanten. Maar ik geloof niet dat Boeing ooit vliegtuigen heeft kunnen bouwen met zulke gebrekkige methodieken.

Volgens mij ligt de waarheid dichter bij wat NASA nu zelf zegt: ze hebben niet nauw genoeg samengewerkt met Boeing, en hebben SpaceX veel meer bij de hand genomen om het in goede banen te leiden. Door geen tegengas te hebben gekregen van NASA heeft Boeing waarschijnlijk een verkeerd beeld gekregen van hoe goed ze op weg waren.

Als je dit niet gelooft moet je maar eens opzoeken wat de oorzaak was van de 737 MAX crashes, dat was echt heel erg... En bovenstaande Starliner onderzoek geeft het toch ook aan?

Boeing deed het vroeger prima, toen het nog een bedrijf gebouwd door ingenieurs, geleid door ingenieurs was. Maar toen fuseerde Boeing met McDonald Douglas, om de bedrijfsstructuur en aandelen positie te verbeteren.

De leiding werd toen overgenomen door McDonald Douglas mensen, die gefocust waren op kosten omlaag brengen in plaats van gedegen ontwerpen. De bedrijfscultuur veranderde, het hoofdkantoor werd verplaatst naar Chicago, ver weg van de ingenieurs in Seattle, waardoor de leiding van het bedrijf nog verder gescheiden raakte van de daadwerkelijke bedrijfsvoering.

In plaats van alles zelf te doen, begonnen ze uit te besteden als "kosten besparing", en dat leidde al tot enorme problemen. Maar toch gingen ze er mee door.

https://youtu.be/EESYomdoeCs?t=440

Vroeger testen ze prima, maar toen werd de leiding vervangen door iemand die niet een absoluut veilig systeem ziet, maar het prijskaartje van het testen, en die prijs omlaag wilt dringen.

[Reactie gewijzigd door wild_dog op 9 juli 2020 15:38]

Steek je hoofd dan maar in het zand.

Er zijn 2 vliegtuigen gecrasht door gebrekkig testen en gebrekkige communicatie. En dat is geen wijsmaken maar iets waar je met een paar minuten zoeken al heel veel informatie over kunt vinden.

Dat in het verleden iets anders was maakt niet dat het nu nog steeds automatisch zo is.
En zoals ieder bedrijf heeft Boeing al eerder ook wel eens steken laten vallen of problemen moeten oplossen zoals met de "rudder issues". Het lijkt echter de laatste jaren qua controle heel erg slecht te zijn bij Boeing, en niet alleen in hun vliegtuigdivisie.

Boeing doet dat geloof ik om kosten te besparen. Dat is ook een van de redenen waarom de JSF zoveel fouten had.

Je bedoeld B737MAX, een passagier toestel waarvan er 2 gecrasht zijn vanwege software problemen.

JSF ofwel F35 komt van de concurrent Lockheed Martin.

Afgezien van dat de JSF ergens anders gemaakt wordt,
Dat is een ontwikkel traject geweest. De eerste JSF uit de fabriek kon net vliegen, er moest nog van alles bij gebouwd worden, het was niet een gereed, uit ontwikkeld produc, maar een test platform.
De werkelijke productie is pas recent werkelijk gestart. (en zal ook nog wel een paar updates krijgen...).

[Reactie gewijzigd door tweaknico op 9 juli 2020 12:56]

SpaceX gebruikt zoveel mogelijk normale hardware en software, terwijl NASA/Boeing meestal de neiging hebben om specifieke talen te gebruiken, die niet zou mogen falen. SpaceX gaat er van uit dat het kan falen, maar dat wordt opgelost met extra hardware.

Dit klopt maar gaat nog verder.

SpaceX gebruikt bij de Falcon-9, zoals jij het inderdaad noemt, normale hardware; normaal gesproken is dit een no-go in de ruimtevaart gezien de straling een bit-flip kan veroorzaken en zo de berekening een verkeerd resultaat kan laten geven met alle gevolgen van dien.

Echter heeft SpaceX ervoor gekozen om hun flight hardware tolerant te maken voor dergelijke berekenfouten door de berekening drie keer paralel uit te laten voeren; hierdoor kan een fout worden gedetecteerd en de berekening over worden gedaan.

Van oudsher had men in de ruimtevaart het doel om de hardware juist te beschermen tegen de straling, dit vroeg om zeer specifieke, vaak dure, oplossingen.

Het bijkomende voordeel (naast de lagere kosten) is dat elke SpaceX engineer een stapel processoren ,zoals die in de uiteindelijke toepassing op z'n bureau kan hebben liggen en er desnoods een paar kan opbranden. Bij nasa zou een applicatie eerst op test-hardware moeten worden gedemonstreerd voordat deze zeer voorzichtig op de uiteindelijke en zeer kostbare hardware kan worden getest.

SpaceX gebruikt bij de Falcon-9, zoals jij het inderdaad noemt, normale hardware; normaal gesproken is dit een no-go in de ruimtevaart

Het is natuurlijk ook een feit dat SpaceX nog niet ver van de aarde is gegaan en feitelijk nog nooit met dat probleen heeft moeten omgaan. Waar SpaceX vliegt is de beschermende invloed van de aarde nog zeer groot. Bijvoorbeeld, in het ISS is nog NOOIT een bitflip gezien en gebruikt men dezelfde laptops en tablets als jij en ik.

Zodra SpaceX verder gaat dan de maan weten ze donders goed dat ze dat niet met de huidige computers kunnen. Daar hebben ze ook nooit een geheim van gemaakt.

Hmm nog nooit ?
Bitflips gebeuren overal, echter als het maar een paar zijn dan is een checksum genoeg om het weer te fixen.
Zelfs hier op aarde komen bitflips door straling met regelmaat voor. (Werk zelf met automotive hardware en heb dit een paar keer meegemaakt)
Bitflips worden pas een probleem als het continu blootgesteld staat en je dus niet meer hebt aan een checksum maar constant moet controleren of je data nog intact is.
Een Gopro , arduino of een laptop werkt prima in low orbit, echter verwacht niet dat ze erg lang meegaan.
Het ISS zelf biedt iets van bescherming heb geen ide of ze ook ECC geheugen in die laptops hebben zitten.
Zou je die zelfde hardware dieper de ruimte in sturen houden ze het mischien wel minder dan een dag vol.

Het was in de jaren 70 een uitdaging om DRAM te maken. (4Kbit) omdat daarin steeds bitflips optraden. Een beter naam is overigens Soft Errors omdat ook signalen verstoord kunnen worden tijdens transport.
Het is jaren een probleem in de ontwikkeling geweest. Het probleem bleek uiteindelijk te liggen in het materiaal van de behuizing.
De oplossing kwam van iemand die na een stage in een nucleaire installatie, een stage bij Intel doorliep.
en toen een overeenkomst zag in afmetingen van alpha-deeltjes en de afmetingen van items in een 4Kbit DRAM chip.

Zie ook:
https://ntrs.nasa.gov/arc....nasa.gov/20160009771.pdf
https://en.wikipedia.org/wiki/Soft_error

Achter een paywall:
https://www.sciencedirect...abs/pii/S0969804397001607

[Reactie gewijzigd door tweaknico op 9 juli 2020 13:20]

TMR ofwel triple memory redunancy wordt vrijwel altijd toegespast in de ruimtevaart, SpaceX is hier zeker niet mee begonnen, kijk maar naar de Apollo missies.

Ik betwijfel of SpaceX geen Radiation hardered componenten gebruikt, voor DeepSpace is dat echt nodig, of je moet heel veel shielding toe kunnen passen

Nope, Spacex doet het net iets anders: https://en.wikipedia.org/wiki/Falcon_9#Design

SpaceX uses multiple redundant flight computers in a fault-tolerant design. Each Merlin rocket engine is controlled by three voting computers, each of which has two physical processors that constantly check each other. The software runs on Linux and is written in C++.[69] For flexibility, commercial off-the-shelf parts and system-wide radiation-tolerant design are used instead of rad-hardened parts.[69] Each stage has stage-level flight computers, in addition to the Merlin-specific engine controllers, of the same fault-tolerant triad design to handle stage control functions. Each engine microcontroller CPU runs on a PowerPC architecture.[70]

The Falcon 9 rocket can lose up to two of the engines and still complete the mission. The Merlin 1D engines can vector thrust for greater control to the rocket. Each Merlin engine produces 854 kN (192,000 lbf) of thrust.

Vooral het redundante motor ontwerp is slim (maar niet nieuw). Straks hebben ze op BFR meer dan 30 motoren en daarvan kunnen er gewoon een paar falen of zelfs ontploffen en toch moet de raket nog verticaal kunnen landen. Ondertussen kijken we naar naar de ontploffende prototypes

Een techniek wat al in de Apollo gebruikt werd.
Willen ze dieper in space gaan hebben ze toch echt nog radiation hardered cpus nodig

Hier wat interessants van hoe en wat met electronica in de ruimte
https://arstechnica.com/s...mputing-power-into-space/

[Reactie gewijzigd door itcouldbeanyone op 8 juli 2020 20:59]

De doel van dit project is de ISS bereiken en dan ga je voor de meest efficiënte en werkende oplossing.

Deep Space heeft er dan nog niet heel veel ermee te maken. Denk dat SpaceX er wel over heeft gedacht en uiteindelijk heeft gekozen voor de huidige oplossing voor de huidige missie.

Wat Boeing dacht is dan.. zou het niet weten.

zoals itcouldbeanyone al zei: toegepast in apollo, en de spaceshuttle had ook 7 boordcomputers die eenstemming moesten bereiken. Allemaal met andere OS'en / code. Als ik het me goed herinner (geen garantie :-p), was een er van het RTOS QNX, wat tegenwoordig van blackberry is en veel gebruikt wordt in auto's voor het infotainment system.

Ik wil het ook niet tegenspreken dat ze er mee bezig moeten gaan in de toekomst maar zoals acers2k al uitlegde hoeven ze nu niet zo ver .

Het besturingssysteem dat je bedoelt is QNX inderdaad. Het RTOS staat voor RealTime Operating System. Ik was nieuwsgierig na je uitspraak (dank daarvoor ) en het is een mooi verhaal. Ze hebben de (canade)arm gebruikt met QNX om een 3D map te maken van de spaceshuttle inflight. Indrukwekkend!

[Reactie gewijzigd door dycell op 10 juli 2020 23:52]

De beelden komen in ieder geval van GoPro's. Prachtige plaatjes en natuurlijk bizar goedkoop tov professionele oplossingen. En waarschijnlijk beter en lichter.

Nee, SpaceX is niet beursgenoteerd, en meneer Musk heeft genoeg aandelen en/of stemrecht om zelf de scepter te zwaaien. Ze overtuigen klanten zoals NASA de portemonnee te trekken door waar te maken wat ze beloven. Ook al is dat regelmatig flink vertraagd, toch zijn zij het die tot tweemaal een capsule aan het ISS hebben gekoppeld en Boeing nog niet. Vergelijk het dus niet met Elons andere bedrijven (bv Tesla), waar de aandeelhouders en toezichthouders wel wat te roepen hebben.

Nee, SpaceX is niet beursgenoteerd, en meneer Musk heeft genoeg aandelen en/of stemrecht om zelf de scepter te zwaaien.

Klopt, maar dat neemt niet weg dat bijna 82% van SpaceX betaald is door investeerders. Dat hoeft natuurlijk niet via de beurs. Tommy_K heeft een een goed punt als ie zegt dat marketing enorm belangrijk is voor SpaceX. Ze geven er niet voor niets veel aan uit. Ze moeten de NASA en de andere investeerders blijven overtuigen om te investeren.

Elon Musk heeft een zeer grote invloed maar als NASA niet meer wil meespelen of de andere 26 eigenaren besluiten een andere kant op te willen, zal Musk niet veel keus hebben. Voorlopig weet hij ze nog te overtuigen. Met feiten en resultaten. Ik ben een groot fan.

Ik vind het nogal grote uitspraken die je zo doet...

maar dat neemt niet weg dat bijna 82% van SpaceX betaald is door investeerders.
Nu is bekend dat NASA een van de grootste investeerders is maar ik twijfel zeer aan je verhaal. Heb je misschien een bron die dat ondersteund want volgens mij maakt Spacex helemaal niet openbaar waar het geld vandaan komt (anders dan Nasa wat ze zelf heel duidelijk maken)

Tommy_K heeft een een goed punt als ie zegt dat marketing enorm belangrijk is voor SpaceX. Ze geven er niet voor niets veel aan uit.
Welke marketing? Hoe kom je hierbij? Net alsof ik een satelliet heb die nog gelanceerd moet worden? Ik neem aan dat als ik dat had, ik letterlijk niet naar marketing zou kijken maar naarhele andere factoren. Marketing lijkt me totaal nutteloos voor Spacex. De publieke opinie is wel belangrijk maar dat is hier niet de doelgroep..

Elon Musk heeft een zeer grote invloed maar als NASA niet meer wil meespelen of de andere 26 eigenaren besluiten een andere kant op te willen, zal Musk niet veel keus hebben.
Hij is chief engineer dus dat hij een grote invloed heeft is een understatement . En uiteraard is het verhaal voorbij als NASA er mee kapt want dat is hun grootste klant. Dat is eigenlijk zo bij ieder groot bedrijf in de ruimtevaart. Echter geeft Wikipedia wel het volgende: Elon Musk Trust (54% equity; 78% voting control). De andere investeerders hebben uiteraard veel macht en inspraak maar ik denk dat duidelijk is wie de sleutels in handen heeft..

De publieke opinie is wel belangrijk maar dat is hier niet de doelgroep..

Ik denk dat je daar mis zit. De publieke opinie over SpaceX zal belangrijk zijn voor NASA. Wat haar funding weer van de overheid krijgt. Als SpaceX uit de gratie valt, en NASA er geld in blijft pompen, zal de president dat moeten verantwoorden. Doorgaands zijn politici niet zo happig om tegen de publieke opinie in te gaan. Zeker niet als het verkiezingstijd is.

Omgekeerd, hoe beter SpaceX bij het grote publiek ligt, hoe groter de kans dat NASA meer budget krijgt, hoe groter de kans dat SpaceX daar ook profijt van heeft

Dat zou kunnen maar NASA en SpaceX zijn niet getrouwd en het zijn geheel andere organisaties. Er is geen garantie dat SpaceX daadwerkelijk opdrachten krijgt van NASA (anders dan de afspraken die ze nu al hebben).

Ik werk ook dagelijks (niet fysiek) bij klanten en hoop dat ze een goede reputatie hebben/krijgen. Dat betekend namelijk ook meer werk voor mij. Het betekend echter niet dat ik reclame voor hun moet gaan maken(al gebeurd dat soms onbewust).

Wat betreft de publieke opinie denk ik dat SpaceX zijn geld liever in goede oude corruptie lobby stopt dan marketing. De normale burger heeft echt geen idee wat er op ruimtevaart gebied gebeurd. De meeste mensen hebben nog nooit een spacex raket zien landen.

Investeerders investeren juist in SpaceX omdat ze geloven in Elon Musk's visie.
Zolang SpaceX een gigantische voorsprong heeft op andere bedrijven/overheden in de moderne "space race", gaan die investeerders ook niet reclameren

Marketing is altijd belangrijk geweest in de ruimtevaart. Waarom denk je dat astronauten al sinds mensenheugenis een cursus fotograferen krijgen? En in plaats van wat extra maanstenen ging er camera apparatuur mee terug na de maanlandingen. Da's voor de mooie kiekjes in de krant, want daar hangt de funding vanaf.

Wat zal een groter invloed hebben,
- NASA of een ander eigenaar kapt ermee.
- Elon Musk kapt er zelf mee.

Met dit antwoord weet je waarschijnlijk wie de belangrijkste rol speelt in SpaceX.

Het zou me echt verbazen mochten ze bij Boeing vandaag de dag nog altijd het wiel opnieuw willen uitvinden. Men is bij Boeing, sinds de overname van McDonnel Douglas toch echt meer en meer gaan inzetten op meer stroomlijning en minder over engineering om kosten te drukken. Ik kan me niet voorstellen dat men dan bij de ruimtevaart afdeling nog altijd gaat kiezen voor eigen oplossingen wanneer er common, of the shelf alternatieven zijn.

Het zou me echt verbazen mochten ze bij Boeing vandaag de dag nog altijd het wiel opnieuw willen uitvinden. Men is bij Boeing, sinds de overname van McDonnel Douglas toch echt meer en meer gaan inzetten op meer stroomlijning en minder over engineering om kosten te drukken. Ik kan me niet voorstellen dat men dan bij de ruimtevaart afdeling nog altijd gaat kiezen voor eigen oplossingen wanneer er common, of the shelf alternatieven zijn.

Het is juist zeer waarschijnlijk dat ze nog grotendeels op de oude manier bezig zijn: de mensen die daar werken zijn nog steeds dezelfde mensen als die er al jaaaaren lang op die manier werken. Die zijn niets anders gewend, en mensen doen bij voorkeur wat ze altijd al deden, en vinden het moeilijk om ineens naar een andere manier van werken om te schakelen. En die oude manier is 'cost-plus', waarbij de kosten feitelijk niet uitmaken, én waarbij zelfs de winst omhoog gaat als de kosten stijgen. Het enige wat ze nu moetsen doen, is vooraf de kosten schatten, ipv achteraf berekenen.

En voor zover ze hun werkwijze veranderd hebben is dat misschien juist de oorzaak van de problemen. Met de veranderde manier van werken hebben ze dan dus weinig ervaring, en dus ook weinig ervaring met de problemen die je daarbij in de praktijk tegenkomt. Dus is de kans dat er fouten gemaakt worden veel groter.

En wat de overname door Mc Donnel Douglas (alhoewel niet in naam, schijnt dat wel in de praktijk zo geweest te zijn) betreft: de nadruk kwam, zo ik gehoord heb, inderdaad véél meer op management en kostenbesparing te liggen, ten koste van degelijke engineering. Met de bekende gevolgen. Het doel daarbij was primair winsten verhogen. De ruimtevaartafdeling zal daar dus weinig last van gehad hebben, juist omdat daar de winst niet afhankelijk was van kostenbesparing. Dat was zelfs eerder andersom.

Dat ligt aan de manier van ontwikkelen van SpaceX. Ik ga even voor het gemak vanuit dat het toezicht op beide partijen gelijk is. Als je beter borgt en controleert in je eigen proces dan kan de software SpaceX alsnog vele malen beter in elkaar zitten die van Boing. Gezien het type bedrijf denk ik zelf dat je bij SpaceX beter zit. Ze hebben iig al veilig het iss gehaald en een flink aantal satellieten de lucht in geschoten.

[Reactie gewijzigd door jdh009 op 8 juli 2020 17:14]

Het toezicht was dus niet gelijk, volgens wat NASA nu naar buiten brengt. Ze waren meer gefocussed op SpaceX omdat die een nieuwe methode van SW ontwikkeling gebruiken, tegenover het oude proces zoals Boeing dat al decennia gebruikt.
Ze dachten dat ze voldoende ervaring hadden met de methodiek van Boeing en ze hen dus hun gang konden laten gaan terwijl ze bij SpaceX met hun neus bovenop de ontwikkeling wilden zitten.

Tja, boeing en software. Kijkend naar de Max vliegtuigen software problemen dat leidde tot 2 dodelijke crashes. Ik ben ervan overtuigd dat bij Boeing goede software ontwikkelaars rond lopen. Als je de debacle van Max volgt dan was er van hogerhand druk alles snel af te rafelen. Dus de nu vrijgegeven bevindingen van Nasa dat er meer controle moet zijn op het proces onderschrijft het alleen maar. De vraag is of het met het huidige team van managers gaat lukken en of deze mensen niet vervangen moeten worden.

Niet allen Boeing en Software, maar meer algemeen in Boeing en Toezicht volgens mij.

MCAS is alleen niet ontwikkeld door Boeing maar door een externe partij. Het was dan ook niet direct de schuld van de programmeurs die een systeem hebben gemaakt naar de specs zoals opgegeven door Boeing. Je moet eerder kijken naar die specificaties en de motivatie om ze zo op te stellen.

Mijn IT ervaring bij grote bedrijven zijn erg divers. Bij de ene is alles van architectuur tot development tot testen verdeeld over kleine, enthousiaste teams en worden er prima producten neergezet. Bij de andere is alles strak uitgedacht vanuit een clubje architectuur experts (70% zzp), vervolgens gaat het management iedereen controleren of ze het wel precies volgens schema implementeren op de manier zoals die is uitgedacht. Met als gevolg dat niemand gemotiveerd is, iedereen bang is om fouten te maken en daarom geen risico's durft te nemen en de creatieve en meer ruimdenkende developers vertrekken (of niet solliciteren, waardoor de salarissen omhoog moeten om voldoende personeel te hebben)

Ik kan me goed voorstellen dat dat laatste op Boeing van toepassing is. Er worden veel onnodige kosten gemaakt door alles van te voren te willen plannen en vervolgens te managen, en de gebouwde oplossing is iets te maken wat er allang was. Terwijl een bedrijf als SpaceX werkt met een visie, en hun personeel toestaat om met nieuwe ideeën te komen om dat doel te bereiken.

Ik denk dat je het bij het goede eind hebt.
Te veel managers en directeuren met daaronder veel te weinig handjes die daadwerkelijk het werk moeten verrichten.

Tja, eigen aandelen opkopen ipv investeren in R&D, software outsourcen, en dadelijk de pensioenen geplunderd. Bekend patroon in VS, het systematisch uithollen van bedrijven. Erg lucratief, alleen niet voor bedrijf en gewone personeel.

[Reactie gewijzigd door gepebril op 9 juli 2020 11:26]

"de 'meer traditionele' ingenieursmethoden van Boeing"... Geinig, verschil waterval en agile?

Ik denk meer de grootte van de laag managers.

Maar het is wel vreemd. Een relatief jong bedrijf krijgt een grote pak met geld en krijgt het voor elkaar.
Een traditioneel bedrijf krijgt 1,5 keer zoveel en hen lukt dat niet.
Is de opdracht voor Boeing anders? groter? Of toch niet zo competent als verwacht?

En waarom krijgen ze niet dezelfde bak met geld? ik heb nooit goed begrepen waarom de bedragen anders zijn terwijl de doelen hetzelfde zijn.
Het is toch een commercial crew program? of zegd Boeing gewoon: 'onze managers moeten ook betaald worden dus geef maar een miljard meer' Commercieel zijn ze in ieder geval wel.

[Reactie gewijzigd door The_Woesh op 8 juli 2020 18:52]

En waarom krijgen ze niet dezelfde bak met geld?

NASA vraagt aan diverse partijen: "Doe je mee? Zo ja, quanta costa?" SpaceX zegt bedrag X, Boeing zegt bedrag X maal 1,5, NASA zegt tegen beide: Ok, hier heb je het bedrag wat je hebt genoemd.

Ja precies dit. NASA heeft geselecteerd op meerdere criteria neem ik aan. De benodigde subsidie was (slechts) één van die criteria. Waarschijnlijk wel een zwaarwegende.
Wel tekenend dat Boeing zoveel meer geld nodig vond te hebben. Ik hoop dat ze zich daar beseffen dat ze echt achter beginnen te lopen. SpaceX kan het immers blijkbaar goedkoper en beter. Al is dit natuurlijk nog maar 1 project. We moeten niet te snel conclusies trekken.

[Reactie gewijzigd door fruitbakje op 8 juli 2020 17:57]

Dus het is een aanbesteding waarbij de twee beste voorstellen geselecteerd zijn.
Ik denk dat SpaceX dan, achteraf gezien, te weinig gevraagd heeft. Maargoed, dat wisten ze misschien niet en musk was misschien bang dat de opdracht naar z'n vriend Bezos zou gaan en spaceX naast de boot zou vallen.

[Reactie gewijzigd door The_Woesh op 8 juli 2020 18:56]

Aan de andere kant zou je kunnen stellen dat deze prijsstelling ze scherp houdt en ze daardoor, gecombineerd met het succes, waarschijnlijk ook sneller meer belangrijke opdrachten zullen binnenslepen.

[Reactie gewijzigd door vickypollard op 8 juli 2020 19:53]

Boeing is mogelijk ook georganiseerd als een ouderwets bedrijf, met veel en veel te veel managementlagen. Waarbij elk poppetje weer iets er over wil zeggen en dat lager management fouten niet wil erkennen naar hoger management. Met andere woorden belangrijke gegevens komt niet waar het moet liggen.

[Reactie gewijzigd door _Dune_ op 8 juli 2020 17:20]

Boeing krijgt dit soort opdrachten, omdat ze in leven moeten blijven voor andere overheidsopdrachten. Die lager ingeschat worden, zodat ze door het Congres heen komen.

Het leest alsof NASA minder vertrouwen had in SpaceX, is dat ook de reden van het veel lagere budget?

Ik heb de aanbestedingen e.d. helemaal niet gevolgd, maar ik denk dat SpaceX gewoon heeft gezegd dat ze minder geld nodig hadden om de opdracht voor NASA uit te kunnen voeren. Het is niet zozeer NASA die zegt 'Oké we selecteren jullie en jullie krijgen dit geld', maar meer van 'Oké jullie hebben dit plan ingedien en gezegd dat jullie dit geld er voor nodig hebben, en dat samen is door ons als beste beoordeeld en daarom krijgen jullie het geld wat jullie er voor nodig hebben'.
Ze hadden blijkbaar wel minder vertrouwen in de manier van werken, daarom was er bij SpaceX meer toezicht.

Wie denkt dat meer toezicht ervoor gaat zorgen dat software beter gaat worden heeft een management bord voor z'n kop.

Planning onrealistisch maken en verhullen door ze obscuur te maken en uiteindelijk de sleutelfiguren indekken door ze niet met naam en toenaam op te nemen in zo'n planning.

Zodra technische problemen juridisch worden uitgelegd moet je eigenlijk al weten waar het probleem zit.

Echt een geweldige beslissing van NASA om redundantie te kiezen voor het Commercial Crew Program. Door twee aanbieders te selecteren heeft NASA nu jarenlange vertraging van het programma ontweken. Als er één aanbieder gekozen zou zijn dan was het namelijk zonder twijfel Boeing geweest.

Dit systeem van meerdere aanbieders wordt gelukkig ook gebruikt voor het nieuwe maanlandingsprogramma, waar aanbieders ongetwijfeld ook met setbacks te maken gaan krijgen.

Wow dus eigenlijk zegt NASA dat ze de waterfall en sterk verouderde ontwikkel trajecten van Boeing meer vertrouwden dan de Agile ontwikkelmethode van SpaceX...

Nu kun je roepen en dit bewijst dat Agile beter is maar zo als Nasa zelf aangeeft keek het veel meer mee met SpaceX en lieten ze Boeing meer hun eigen ding doen. Het kan dus heel goed zijn dat de extra aandacht die SpaceX kreeg soortgelijke problemen heeft voorkomen bij Dragon. We zullen het nooit zeker weten maar ik vermoed dat het met name een les zal zijn voor Nasa dat oude jongens krentebrood verhaal werkt gewoon niet met commerciele bedrijven. En toezicht is nu eenmaal noodzakelijk...

Nu denk ik persoonlijk dat voor een systeem zo complex als een ruimteschip het misschien toch goed is om dit via een Agile process te ontwerpen omdat het je de mogelijkheid geeft veel eerder fouten te vinden, dit helpt in het beter plannen van waar je de tijd nodig hebt om dingen op te lossen. Iets dat veel moeilijker is in te schatten bij een waterfall methodiek waardoor je vaak tegen het einde van het traject tegen dingen aanloopt die je waarschijnlijk veel eerder op een simpele wijze op had kunnen lossen maar die nu onder grote tijdsdruk moeten worden opgelost in een veel complexer systeem. (complexer in de zin dat alles eigenlijk af is en iedere verandering invloed kan hebben op andere onderdelen van het systeem, waar je bij Agile het probleem eerder ziet de systemen nog niet af zijn en dus veranderingen vaak simpler doorgevoerd kunnen worden)

Toch is er veel te zeggen voor waterfall, het is een fixed budget het is een fixed timeline (nou ja dat zou het moeten zijn) en je weet dankzij de zeer uitgebreide en expliciete specificaties precies wat je mag verwachten als het product af is.
Al denk ik wel dat het zeker wat software betreft misschien niet de beste oplossing is. Als je een gebouw ontwerpt en bouwt lijkt het me wel haast noodzakelijk omdat even een draagmuur verplaatsen nu eenmaal niet mogelijk is, nog kun je er toch maar een paar extra verdiepingen op bouwen. Waar vergelijkbare aanpassingen in software een stuk makkelijker te doen zijn.

Lijkt me leuk om eens te kunnen zien wat de interactie tussen SpaceX en Nasa was. Was het alleen hey kun je laten zien dat dit ook in deze gevallen werkt of was het meer een ja leuk dat je dit zo wil doen maar dat gaat helemaal fout omdat je dan ook dit en dat...
Met andere worden was het een controle als in heb je alles wel echt goed getest of is het meer een peer programming effort waar de Nasa engineers actief meewerkte aan het oplossen van problemen?

Waterfall was in de jaren 70 al als een slecht idee neergezet, maar daar werd overheen gelezen: https://pragtob.wordpress...ading-the-original-paper/

Je hebt natuurlijk waterfall en watwerfall.
ZOals hierboven reeds aangegeven doet spaceX veel op 'echte'hardware testen.
Als je puur agile zou gaan werken is dat ook niet 123 te bewerkstelligen, want dan zijn de projecten /modules nog steeds op elkaar aan het wachten.
Ik schat in dat het voornamelijk een betere systeem decompositie is, waardoor Agile uberhaupt mogelijk is...

--> Zelf met een transitie van waterval naar Agile bezig en daar loop ik tegen de issues van systeem brede definities op, die bij agile juist sterker aan het licht komen (maar niet noodzakelijkerwijs erdoor opgelost worden).
Ben er nog niet uit of het nu 'beter' werkt voor een extreem complex product...

Mijn ervaring is dat je het prima kunt combineren bij complexe producten. De architectuur moet waterfall-achtig worden gemaakt. Eerst heel goed nadenken hoe dingen moeten werken, daarna de basis daadwerklijk bouwen. Vervolgens kun je meer agile te werk gaan bij het invullen van de puzzel, bovenop de architectuur.

Een goede architectuur komt gewoon niet tot stand met puur agile werken. Dan ben je continue je architectuur aan het aanpassen omdat je nieuwe feature er niet in past. Vergelijk het met het bouwen van een gebouw. Als je begint met een schuurtje, daar steeds dingen op moet maken als extra verdiepingen enzo, dan komt er elke keer een verzwaring van het fundament bij kijken.

En die verzwaring van het fundament maak je dan slechts toepasselijk voor de feature die je op dat moment aan het maken bent. Niet voor de wolkenkrabber waar je mee eindigt.

Als je dus vanaf het begin ontwerpt voor een wolkenkrabber (denk aan materiaalkeuze, fundering) dan kun je prima elke keer een extra verdieping er op bouwen en per verdieping de mogelijkheden bepalen.

Gewoon alles in een elektron app gooien, zoals de rest van de wereld.

Je maakt een grapje, maar de touchscreens van de SpaceX Dragon draaien dus gewoon vrolijk een chromium browser met daarin een HTML/CSS/Javascript applicatie.

Klopt - maar is een fallback naar knoppen als het moet

npm install spaceflight

Draaien in een Docker.

Snap je ‘m? Docken? ISS?

zo slecht en toch vind ik m leuk

Boeing en software ontwikkeling, geen gelukkige combinatie.

Trouwens > 'Daardoor dacht de capsule dat het zich tijdens de afscheiding van de raket op een ander punt in de missie bevond.'

Zover zijn we ( gelukkig) nog niet.

Inderdaad, zodra capsules kunnen gaan denken willen wij naar Mars, weg van hier

Lijkt me slimmer om de denkende apparaten naar Mars te sturen en dat deze apparaten alle voorbereidingen treffen voor habitatie of beter nog, terra-forming.

Tegen de tijd dat we dan hier de reisproblemen naar Mars hebben opgelost, is er op Mars al een leuk gespreid bedje aanwezig voor de reizigers.

Boeing en software ontwikkeling, geen gelukkige combinatie.

Inderdaad, 737 Max anyone?
Wordt tijd dat Boeing meer toezicht gaat houden op haar personeel.