Mislukte Starliner-missie had last van tweede 'bijna catastrofale' softwarefout

De NASA wil nog meer tests uitvoeren met Boeings Starliner-capsule dan aanvankelijk gepland. Tijdens de deels mislukte test van vorige maand blijkt er nog een andere grote softwarefout te hebben plaatsgevonden die tot 'een catastrofe had kunnen leiden'.

Dat zei de Amerikaanse ruimtevaartorganisatie tijdens een persconferentie, waar onder andere Spacenews over schrijft. Tijdens de persconferentie beschreef een veiligheidspanel van NASA de fouten die er gemaakt waren, en de voortgang van het onderzoek daarnaar. NASA bracht vandaag zelf de eerste resultaten naar buiten van het onderzoek naar de eerste vlucht van Starliner. Die vlucht ging in december vorig jaar grotendeels mis toen de capsule in een verkeerde baan terecht kwam. Hoewel de capsule heelhuids terugkwam op aarde, bereikte Starliner zijn bestemming van het International Space Station niet. Nu zeggen NASA en Boeing dat er nog een ander probleem was dat niet eerder bekend was. Het ging om een softwareprobleem in de Service Module Disposal Sequence, het proces waarbij de servicemodule van de capsule wordt afgestoten voor die weer terug naar aarde komt. Er zijn niet veel details bekend over de exacte aard van het probleem. Het veiligheidspanel maakte bekend dat de fout tijdens de testvlucht ontdekt werd door het grondteam. Dat kon de fout ter plekke herstellen. "Als deze afwijking niet tijdens de vlucht hersteld was, zou het tot onnodige ontsteking van de aandrijving en tot ongecontroleerde beweging tijdens het afstoten van de servicemodule hebben geleid", zei onderzoeker Paul Hill tijdens de persconferentie. "Dat had mogelijk tot een catastrofale fout in het ruimtevaartuig kunnen leiden."

Door de twee softwarefouten waardoor de missie bijna volledig faalde, raadt het veiligheidspanel van NASA aan een uitgebreider onderzoek te doen naar de capsule. Met name het verificatieproces van Boeing moet daarbij nader worden bekeken. Dat zou moeten gebeuren voordat NASA een formele flight readiness-review van de capsule doet, voordat daarmee een tweede testvlucht zonder astronauten plaatsvindt. Boeing gaf eerder al aan dat het 410 miljoen dollar opzij zet voor een tweede testvlucht. Het bedrijf hoopt dat die eind februari kan plaatsvinden.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (82)

Vanavond om 21.30 onze tijd is er een telefonische persconferentie van NASA en Boeing samen, zie https://www.nasa.gov/pres...bital-flight-test-reviews

Edit: Directe link naar de livestream: https://www.nasa.gov/nasalive (op het moment van schrijven, 21:35, is de werkelijke conferentie nog niet begonnen maar luisteren we naar wachtmuziek).

[Reactie gewijzigd door TommyboyNL op 7 februari 2020 21:34]

Ik vond een tweede testvlucht al eind februari een beetje ongeloofwaardig, dus de bron er maar even op nagelezen:
Er wordt niet zoals in dit artikel staat gehoopt dat een tweede (onbemande) testvlucht eind februari plaats zal vinden. Er wordt gehoopt dat eind februari een beslissing hierover genomen kan worden.

Gaat goed bij Boeing met de veiligheid

Dat krijg je wanneer je van technologie gemotiveerd naar financieel gemotiveerde cultuur gaat. Erg interessant artikel over wat er bij Boeing is gebeurd. Ik meen mij te herinneren dat een mede Tweaker deze ooit gepost heeft waarvoor nog dank

[Reactie gewijzigd door Floor op 7 februari 2020 21:12]

MWa, denk dat het eerder te maken heeft met de huidige gedachte gang van agile development. Niet alle software development is geschikt voor de agile methode.. Maargoed daar zullen natuurlijk een heleboel agile adapten het niet mee eens zijn..

Heb je het artikel gelezen?
Dit soort projecten kun je op geen enkele manier "agile" doen. Dit zijn niets zeggende termen die vaak volstrekt verkeerd gebruikt worden. Net zo als "lean" een erg zwakke afgeleide is van het Kaizen. Lean is slechts een management methode met een heleboel hocuspocus en interessant doennerij ,"green and black belt (zelfs in stoomcursus verkrijgbaar), kortom zandstrooien met interessant klinkende termen met een laagje vernis terwijl het een inhoud heeft van de diepte van een A4tje terwijl Kaizen veel verder reikt tot in de maatschappij en in je leefwijze.

Ik heb een broertje dood aan dit type managers en bedrijfsculturen (The Golgafrinchans ) die alleen maar kijken naar korte termijn. Dodelijk voor (hightech) bedrijven.
Gebruik liever je boerenverstand en gelukkig werk ik in zo'n bedrijf.

Gebruik liever je boerenverstand en gelukkig werk ik in zo'n bedrijf.

Helaas zijn zulke firmas echt een zeldzaamheid geworden. Het gebrek aan boerenverstand door enkel en alleen in hokjes te denken is een probleem.

Oh God het komt allemaal terug: cursus lean six sigma "green belt". Zelden zo'n hoeveelheid bullshit gezien in 4 uur tijd...

Ach, als het bij GB en BB zou blijven. Op een gestruktureerde manier dingen aanpakken helpt. Ook in gezel/meester vorm, het heeft meewaarde.

Voor iedere industrie (IT, productie, transport, marketing) noem je t wel anders, met inhoudelijk kleine verschillen.

Om de cursusindustrie draaiende te houden zijn er wel tig kleuren bij gekomen die niets algemeens toevoegen behalve BS.

Natuurlijk kun je dit soort projecten prima Agile doen. Sterker nog, dit zijn projecten met veel onzekerheden die je juist Agile moet aanpakken. Probleem is dat bij veel mensen het idee heerst dat je bij Agile geen designs nodig hebt en niet hoeft te testen......

Dat er bedrijven zijn die Agile niet snappen staat buiten kijf, maar ik zie ook veel Agile development teams die dat eigenlijk niet zijn.

Ik heb het artikel gelezen en zie veel overeenkomsten met volgende artikel uit 2010:
https://forum.politics.be/showthread.php?t=145665
(Het originele artikel staat achter een betaalmuur maar de tekst komt overeen).

Een ander linkje dat er zijdelings mee te maken heeft maar wel leuke overeenkomsten laat zien:
https://youtu.be/eRX4fgFM98M

Je kan Agile nog steeds combineren met verificaties etc.
Je ontwikkeld Agile, (maar dan ook het volledige concept, inclusief geautomatiseerd testen, testen gemaakt door ander team, etc. etc,) en verifieert het resultaat daarnaast.

Er bestaat Agile voor SIL geclassificeerde software.

ja je kan agile wel combineren in een hybride project vorming maar dat doen de meeste managers niet, het liefst gooien ze met de termen agile en scrum en dan volledig onrealistische planningsdata en geen revisions op de planning en herimplementaties/revisies voor stukken van de software die niet goed zijn

Hier is meer info: https://link.springer.com....1007/978-3-319-33515-5_8

MWa, denk dat het eerder te maken heeft met de huidige gedachte gang van agile development. Niet alle software development is geschikt voor de agile methode.. Maargoed daar zullen natuurlijk een heleboel agile adapten het niet mee eens zijn..

Ik denk dat je gewoon nog geen goede ervaring met agile gehad hebt, en niet goed weet waar agil om draait.

Even kort door de bocht:

Agile is geen framework, het beschrijft niet hoe je iets moet doen. Agile geeft je een aantal principes die je kan volgen of aanpasen aan wat je denkt dat nodig is. Je kan dus onmogelijk zeggen dat agile verantwoordelijk is voor een uitkomst.

Agile geeft een team veel meer verantwoordelijkheid, de manier waarop ze iets aanpakken moeten ze zelf beslissen. Het team is dus verantwoordelijk voor de uitkomst.

Ik geloof niet dat dit project agile benaderd is. Indien het agile was, hadden ze de fouten juist vroeger ontdekt. Een belangrijke troef van agile is dat je snel fouten ontdekt, als je bedrijfscultuur niet goed met fouten omkan en dit niet aanmoedigt, is agile niets voor het bedrijf en moet daar eerst aan gewerkt worden.

En een andere misvatting die ik hieronder lees; het is niet omdat je iets agile doet, dat je niet kan plannen of budgetisseren. In mijn ervaring kan je met stabiele agile teams veel beter plannen en budgetisseren. Het zijn juist lange, complexe projecten die je niet juist kan budgetisseren en plannen met waterfall.

Probleem van tegenwoordig is dat agile, scrum, kaizen... buzzwoorden zijn en een enorme hype. Ik ken heel weinig pragmatische coaches met ervaring. De meeste scrum masters/ coaches hebben een of andere online cursus of 2 dagen seminarie gevolgd en zijn ineens expert. Die worden dan met tientallen binnengehaald in grote bedrijven (want serieus tekort aan goede profielen) en proberen dan volgens de theorie iets te implementeren en dat loop vaak slecht af. Meestal bekvechten de coaches onder henzelf omdat bvb Scrum zo vaag is (dit is geen slecht punt, maar ga ik nu niet op in) dat iedereen iets anders begrijpt en zijn/haar visie wil doordrukken ipv naar de teams te luisteren.

Agile krijgt daardoor een slechte naam, spijtig want ik heb zelf zeer grote transformaties gedaan die succesvol waren (ik heb er ook gedaan die gefaald zijn, maar meestal aan het begin van mijn carriere door gebrek aan ervaring).

Volledig akkoord. Agile is eigenlijk een mindset, terwijl velen denken dat het een vorm van project management is (ie scrum).

Ik zeg zelf altijd graag dat er een verschil is tusen agile zijn en agile doen: je kan bv perfect alle rituelen van scrum uitvoeren (=agile doen), maar zolang je niet de juiste mindset hebt, ben je nog niet agile.

Ik vind agile voor de meeste software niet geschikt als ik eerlijk ben, agile is leuk als je script op een bestaand platform maar zeker niet als je complexe programma's en besturingen programmeerd

Agile developement is interessant wanneer je incrementeel kan ontwikkelen. Zodra het om kritische systemen gaat is er een minimum qua veiligheid. Tot aan daar kun je niet agile ontwikkelen, maar moet je altijd dat minimum maken. Wanneer je daar minder kritische functies bovenop wil, kun je die gerust agile ontwikkelen. Praktisch voorbeeld: flight controls en dergelijke moet gewoon altijd werken, camera feeds kunnen minder kritisch zijn.

Interessant dit, wanneer wel of niet het toepassen van Agile. Merk ook dat dit methode wordt toegepast voor het ontwerpen van nieuwe netwerk infrastructuren, opzich kan dat goed werken ipv waterfall methode, maar de meeste organisaties kunnen daar niet me omgaan, Agile. Bang, lead times onbekend, vooral kosten zijn niet 100% inzichtelijk, want een verandering in de infra kan al gauw aardig in de kosten lopen. Vraag mij soms wel af, of Agile voor dit soort opdrachten wel de methode is.

Dan Boeing, ik zie alleen overeenkomsten met de MAX, interessante studie opdracht lijkt mij dit.

edit: typos

[Reactie gewijzigd door sokolum01 op 8 februari 2020 09:47]

https://speld.nl/2018/02/...s-agile-aan-het-scrummen/
Voordeel van Agile zit hem in bewijs dat er al iets draait (geen verschuilen mogelijk) en aanpassen aan veranderende eisen (als het project af is dan is het alweer verouderd) of inzichten (hey, de mensen gebruiken onze app niet om te daten, maar ze bestellen er maaltijden mee).
Een raket zou ik toch bedenken als concept, en daarna 100% invullen qua 'vliegeigenschappen'. Al kunnen daar best 'agile' methoden bij komen. Opa vertelt: vroeger werd dat 'samenwerken' en 'brainstormen' genoemd.

Dit klinkt niet als een ontwikkelprobleem maar een validatieprobleem.

Ik ken agile scrum etc niet, maar als er slecht gedocumenteerde aanpassingen bij komen kijken wordt validatie bij enige complexiteit praktisch onmogelijk.

Je kan ze prima Agile ontwikkelen. Echter is “the customer” voor het grooste gedeelte intern en gebruik je Agile om voortgang te tracken. Je moet dan ook meer het Agile principe zoals het gedoeld is volgen en niet dat circus dat er omheen bedacht is.

Ik heb medische apparaatontwikkeling gewerkt en daar werd ook Agile software ontwikkelt. Dat kon prima. Een MVP is alleen eentje die heeeeeeeeeeeel laat in het project komt en voldoet aan alle harde strenge eisen. Maar alle interne sprints zijn puur voor het hanteerbaar maken de complexiteit, het tracken van de voortgang en juiste afstemming tussen parallelle trajecten. Het ontwikkelen van een dure meet en testopstelling is niet Agile te doen, dus dan is het wenselijk dat dure prototypes alvast met een soort van representatief stuk software kunnen werken in het medisvhe apparaat.

Ah ja, je kunt inderdaad wel veel tools lenen van de agile methodiek voor het inzichtelijk maken en afstemmen inderdaad, dat werkt wel prima. Het heeft alleen minder zin om het fundamentalistisch in te zetten zoals je volgens mij tussen de regels door ook zegt. Alleen al als ik MVP al lees word ik kriebelig , dat werkt niet bij complexe apparaten.

Agile is niet een methode die in steen is gebeiteld, maar je kan het aanpassen naar wat voor jou nodig is. De gedachte is dat het proces jou moet helpen met best practices om efficiënt te werken en zoveel mogelijk fouten zo vroeg mogelijk op te lossen.

Het is wel duidelijk dat het oude waterval proces verre van ideaal is, Agile is ook niet perfect maar wel een stuk efficiënter.

Een beetje zoals DSDM dus. Het is ook maar net wat hot is denk ik zelf.

SpaceX lijkt voor de ontwikkeling van hun Starship platform wel agile principes te gebruiken en dat deden ze ook voor Falcon 9 en Crew Dragon. Ze bouwen MVP, testen heel veel in de praktijk en hebben snelle iteraties van nieuwe versies. Soms ontploft er dan wel eens wat, maakt niet uit zolang dat op het land gebeurt. Het probleem zit 'm mijns inziens niet zozeer in de methodiek, maar in hoe je die toe past. Agile werkt niet zolang alleen je software afdelingen op die manier werken. Het moet in het DNA van je bedrijfsvoering worden opgenomen, dan heeft het kans van slagen. En dan moet je alsnog goed kijken wat wél goed voor je werkt en wat niet; iets wat de methode ook stimuleert (retrospectives bijvoorbeeld) maar vaak niet echt goed wordt uitgevoerd.

Wacht. Die batterij in de dreamliner die in de fik vloog kwam door Agile development?

Serieus, je praat echt kul. Want je weet niet of Boeing echt Agile toepast voor hun Software Development. En misschien is dit niet eens alleen maar een software probleem.

Maar het maakt blijkbaar van alles los bij mensen. Dus tip. Maak eens een keer een paar succesvolle Agile projecten mee, een paar mislukte. En vergelijk ff wat er goed ging en wat er mis ging. En leg dan nog eens uit waarom Agile echt niet past. Ligt het aan de mensen en cultuur of aan het proces?

Je moet natuurlijk alles in context plaatsen. Decennia lang was geld geen enkel probleem. Projecten kwamen in principe vanuit de overheid die gewoon eisen stelden voor nieuwe vliegtuigen en de kosten van ontwikkeling dragen. Dat is iets wat vandaag niet meer haalbaar is. Maar in zo een setting kan je wel focussen op ontwikkeling en dingen proberen zonder al te veel naar de kosten te moeten kijken. Maar toen de markt gedereguleerd werd en concurentie begon te spelen moest Boeing ook op zijn geld gaan letten. Uiteindelijk moet je nog altijd winstgevend worden als bedrijf.

Alleen zie je vandaag dat dat ook weer te ver is doorgeslagen waarbij je als personeel schrik begint te krijgen als je achter begint te lopen op schema, of kritiek durft leveren waarbij de oplossing geld zal kosten. En dat is nu voor Boeing een dure les aan het worden. 1 waarvan ik hoop dat Airbus ze niet moet leren.

Interessant, gebeurt dit niet bij heel veel bedrijven? Ik ga hier is meer over opzoeken

Inderdaad een erg goed artikel. En ja, je hoeft niet buiten Nederland te zoeken voorbeelden van ‘techbedrijven met een ingenieurscultuur’ naar ‘winstmaximalisatie voor aandeelhouders’ vanuit een sexy nieuw hoofdkwartier ‘buiten de campus’ ;-)

Het is niet voor niets dat veel mensen zeggen dat McDonnell Douglas Boeing heeft gekocht met hun eigen geld.

Ik snap je gedachte, maar het gaat hier wel om twee losse onderdelen van Boeing. Daarnaast zijn dergelijke fouten juist de reden dat er getest wordt. Niet te vergeten dat de SpaceX crew dragon op de launch pad explodeerde.

Dergelijke fouten wordt ontzettend veel van geleerd en zijn puur bedoeld om bemande ruimtevaart veiliger te maken. Natuurlijk hopen de engineers dat het in een keer goed gaat, maar hier is over het algemeen meer van te leren

Dat zijn twee heel verschillende problemen. SpaceX was een mechanische fout die door engineering gemaakt is die zeker voorkomen had kunnen worden omdat het niet de eerste keer in de geschiedenis is dat een dergelijk probleem zich voor heeft gedaan (al is dat wel al weer erg lang geleden)

Boeing daar in tegen heeft mechanisch alles onder controle maar de software kant is rond uit slecht. En het diepere onderzoek dat NASA wil doen is niet omdat men denkt alle problemen al te hebben gevonden maar omdat men uit wil sluiten dat er niet nog een lading andere problemen zijn die in dit eerste onderzoek niet aan het licht gekomen zijn.

Als je kijkt naar de laatste paar grote projecten die Boeing heeft opgeleverd dan zijn die allen door software problemen geplaagd en dan hebben we het alleen over de problemen die groot genoeg waren om ook zichtbaar te zijn voor het grote publiek.
Nu is software tegenwoordig erg complex en zijn er heel erg veel meer inputs en dus heel erg veel meer situaties waar in dingen mis kunnen gaan. Maar zeker met de lucht en ruimtevaart is het eigenlijk niet acceptabel dat er flinke fouten worden gemaakt door de developers.
Dit had voorkomen kunnen en moeten worden. Dingen als: "Oh oops..." daar had ik even niet aan gedacht of: "Het zal vast wel goed gaan, toch?" zijn geen dingen die je je kunt veroorloven.

Helaas is Boeing in haar honger naar meer (voor al geld) steeds minder aandacht gaan besteden aan de kwaliteit van de software, en in middels heeft dat het bedrijf al miljarden gekost met de 737 MAX. En dit starliner project zou wel eens heel goed in de prullenbak kunnen verdwijnen want een flink uitstel, alle code door moeten lopen en verbeteringen maken wat weer opnieuw getest en bewezen moet worden . Ik kan me heel erg goed voorstellen dat Boeing uit het commercial crew program stapt omdat het op dit moment de kosten voor een al flink beschadigd bedrijf moeilijk te dragen zijn.

Het enige kleine licht puntje voor Boeing marketing is dat het Boeing wel gelukt is om het milieu vriendelijkste vliegtuig ooit te maken... zero carbon emissions in 2020 after all

Dit had voorkomen kunnen en moeten worden. Dingen als: "Oh oops..." daar had ik even niet aan gedacht of: "Het zal vast wel goed gaan, toch?" zijn geen dingen die je je kunt veroorloven

Dat is veel te simpel. Daarmee doe je een heleboel mensen te kort die waarschijnlijk met hart en ziel en met de beste bedoelingen aan dit systeem hebben gewerkt. We weten nog niet precies hoe het kon dat deze twee fouten in de software door de kwaliteitscontrole zijn gekomen. Neem van mij aan dat bij het ontwikkelen en testen van deze software ontzettend veel mensen betrokken zijn geweest en dat je er van uit mag gaan dat dit professionals zijn die nooit collectief zullen zeggen "Het zal vast wel goed gaan". De problemen die Boeing de afgelopen jaren heeft gehad, hebben niets te maken met de professionaliteit van de mensen op de werkvloer, maar met de verschillende belangen die het management moet dienen en de foute beslissingen die daar het gevolg van zijn.

Ik heb nooit gezegd dat het de ontwikkelaars zijn geweest nog de testers... het kan heel goed zijn (gebeurt bijna nooit ) dat management simpel weg besloten heeft minder tijd in te ruimen voor het testen dan wel minder mensen in te zetten tijdens de ontwikkeling (of beide natuurlijk) waardoor de kwaliteit minder wordt.

Dit het mooie van het hele optimaliseren... als jij 3 uur nodig hebt om bepaalde code te schrijven en jouw collega 5 uur (maar wel een stuk betere kwaliteit) dan is het in de ogen van veel managers logisch dat jij het werk doet en dat die langzame collega misschien maar eens op zoek moet naar een baan die beter past bij zijn of haar werk tempo.
Het grote probleem is dat erg veel mensen die dit soort beslissingen maken helaas weinig kaas hebben gegeten van het werk waar zij over beslissen of door druk van de top het gevoel hebben dat ze niet anders kunnen. En dat is echt niet alleen in de IT het geval dit zie je ook in ziekenhuizen bij de afval, verwerking om het even welk productie process dan ook. Dit heeft alles te maken met het altijd maar meer moeten leveren met de zelfde mensen. Op een bepaald moment is de rek er uit en moet de kwaliteit om laag om de targets te halen. En dat heeft niets met de professionaliteit van de mensen te maken maar wel met de verkeerde doelen stellen en uit het oog verliezen waarom het bedrijf in het verleden altijd zo veel success heeft gehad en de klanten er niet over twijfelden of ze klant zouden blijven of niet.

De explosie van de SpaceX Crew Dragon (overigens NIET op de launch pad, maar op een test stand) had meer te maken met nog niet eerder geziene (en verwachte) reacties tussen twee stoffen, dan met incompetentie.
In de 50+ jaar dat er met hypergolics gewerkt wordt, was de reactie tussen N2O4 en titanium nog nooit eerder waargenomen.

Deze failure is dus in de verste verte niet te vergelijken met de fuckups van Boeing m.b.t. StarLiner.

Sorry maar volgens mij is dat niet waar. Er zijn genoeg onderzoeken die naar die reactie hebben gekeken. Oa in 1961 beschreef men die reactie al:
http://contrails.iit.edu/reports/6932

Heb je dat rapport gelezen? Daarin wordt expliciet aangegeven dat titanium geweekt in N2O2 inderdaad ontbrand als er met een metalen pin op geslagen wordt, maar dat de reactie niet verder progageert, ookal is er voldoende N2O2 aanwezig.
Bij SpaceX had het titanium in de eerste plaats al niet geweekt in N2O2, was er geen metalen pin aanwezig om de ontbranding te starten, en propageerde de ontbranding wel degelijk. Dit matcht dus totaal NIET met het door jou gelinkte rapport.

[Reactie gewijzigd door TommyboyNL op 7 februari 2020 23:37]

Space X's iteraties zijn erg interessant om te zien, ben geen insider maar verwacht dat het fail fast principe wel hoog in het vaandel staat.

Ik kijk de streams van 'what about it' op YouTube, Felix geeft elke week updates van de ruimtevaart en daar zie je dat op Space X gebied er altijd weer iets boeiends gebeurt. Laatst weer met betrekking tot de nose cone en brandstof tanken.

Space X's iteraties zijn erg interessant om te zien, ben geen insider maar verwacht dat het fail fast principe wel hoog in het vaandel staat.

Ik kijk de streams van 'what about it' op YouTube, Felix geeft elke week updates van de ruimtevaart en daar zie je dat op Space X gebied er altijd weer iets boeiends gebeurt. Laatst weer met betrekking tot de nose cone en brandstof tanken.

Wat je zegt klopt wel inderdaad. Iedere keer als er een flacon 9 niet lande, werd dat niet gezien als falen, maar als leerzaam. Nu landen die dingen alsof het routine is. (Is het niet, uiteraard).

Spacex blaast liever 3 falcons of dragons op, om er snel van te kunnen leren. En werpt zijn vruchten af, ze lopen mijlen voor op Boeing als je dragon 2 en spaceliner vetgelijkt, en dan hebben ze nog hun eigen launch platform ook.

So what. Hoeveel raketmotoren heeft het Gemini project gekost voordat ze die raket goed kregen.

So what. Hoeveel raketmotoren heeft het Gemini project gekost voordat ze die raket goed kregen.

Klopt, NASA snapt het wel. Maar Boeing een stuk minder blijkbaar,

Boeing heeft alles uitbesteed sinds 2001. De batterij van de dreamliner kregen ze ook niet goed. Amerikaanse bedrijven wilden er niet aan. Uiteindelijk is een Japans bedrijf gevonden en is uiteindelijk de batterij in een soort Vault geplaatst en nam Boeing de verantwoordelijkheid. van de oplossing op zich.

Hun software is nog nooit zo goed geweest

Dat maakt me erg bezorgd.

Tja, meer elektronica/software is meer problemen.
Dit zien wij ook heel erg in onze branche.
Ik ben bedrijfswagen monteur/APK keurmeester en bij oudere opleggers en trekkers heb je aanzienlijk minder problemen dan al dat nieuwe spul, zelfs sommige fabrikanten geven dit eerlijk toe op een training/cursus.

Meer mogelijke problemen ...
Lijkt me logisch, aangezien elke (ook elek) component potentieel kan stuk gaan

Alle bedrijven worden meer en meer software bedrijven. Kijk maar bv. naar Volkswagen. Hun CEO heeft al gewaarschuwd.
nieuws: Ceo: Volkswagen moet versneld techbedrijf worden om niet als Nokia te...

Software wordt meer en meer belangrijk.

Boeing en software... lijkt niet de beste combi de laatste tijd...

Software schrijven die aan SIL2 of hoger voldoet is echt een vak apart. Dan kom je in het territorium van rekenen met de kans op een bitflip in je data, en hoe je de gevolgen kan beperken.
Niet iets waar een programmeur zich normaal zorgen om maakt.

helemaal niet als die programmeur in india zit...

En bovendien is het iets waar programmeurs zich helemaal niet mee bezig houden. En iets wat dus helemaal niet uitbesteed was aan India.

Dus je opmerking slaat nogmaals helemaal nergens op.

Bron?

Die ga je niet krijgen en dat weet je best.
Wij, als beste stuurlui op de wal, krijgen echt geen inzicht in de kwaliteitscontroles die Boeing doet op zijn software. Dat betekent dat iedereen die roept dat het allemaal bagger geregeld is bij Boeing, dat roept zonder kennis van (interne) zaken, alleen gebaseerd op het kale feit dat Boeing de laatste tijd negatief in het nieuws is gekomen vanwege fouten in de software.

De meest intelligente uitspraak die je nu kunt doen is: Er is een softwarebug door de kwaliteitscontroles geslopen. Dat is alles. Je zou zelfs kunnen zeggen dat nog niets zegt over Boeing, want het kan best zijn dat andere grote fabrikanten ook dit soort problemen ondervinden, maar die hebben puur toevallig nog niet geleid tot spectaculaire ongelukken. Vergeet niet dat de problemen met de 737 max ook pas in het nieuws kwamen toen puur toevallig de AOA-sensor het begaf.

Bron?

Bron? Gewoon logisch nadenken: je kunt het berekenen van de kans op een bitflip (een elektrotechnisch / natuurkundig / statistisch probleem) niet over laten aan iemand die gespecialiseerd is in niets anders dan code kloppen. Het is een compleet andere mix van vakgebieden dan alleen code kloppen. Hetzelfde geld voor alle andere faalkansen.

Niet iedereen kan alles weten.

Bij het schrijven van software voor vliegtuigen heb je hele software architectuur afdelingen die niets anders doen dan software ontwerpen / definiëren op papier zonder zelf ook maar 1 regel code te typen. Die kijken naar veiligheidsregelgeving (certification engineers) en matchen die aan wat er technologisch mogelijk is (software architecten en hardware ontwerpers op alle niveaus van chip tot board tot power tot mechanisch).

Pas als het ontwerp en de specificaties af zijn beginnen de software engineers te typen en te testen. Pas op dan heb je een kans dat "een goedkope Indiërs" de software schrijft zoals voorgeschreven door de ontwerpers.

Het probleem bij Boeing kwam 100 % uit de top. Die hebben in feite de ontwerpers iets opgedragen dat gewoon samengevat kan worden als een veel te snel afgeraffelde hack om een nieuw vliegtuig als oud vliegtuig door te laten gaan (zonder herkeuringen e.d.). Dat was een onmogelijke en ronduit ethisch foute opdracht en daar betaald Boeing nu de prijs voor.

[Reactie gewijzigd door GeoBeo op 8 februari 2020 16:00]

het is inmiddels algemeen bekend dat boeing grotendeels goedkope programmeurs uit india gebruikt. en die kloppen gewoon in wat ze gezegd worden.

Jij koppelt dus het inhuren van goedkope programmeurs uit India aan de bugs die de software van Boeing nu plagen.

Je kunt de fundering van je huis prima laten storten door een bejaarde, half-blinde oostblok-arbeider. Waar het uiteindelijk om gaat is of je opdracht helder is, hoe je het werk controleert tijdens de uitvoering, wie het werk controleert, en vooral: hoe je je eindcontrole doet. Controle, controle, controle en het eindresultaat is altijd volgens jouw specificaties.

Jij weet helemaal niets van de interne processen die Boeing heeft ingericht om de kwaliteit van de software te bewaken. Ik weet het ook niet, maar ik ga hier dan ook niet lopen roepen dat Boeing dom is en dat ik weet hoe het wèl moet.

gezien letterlijk de vliegtuigen uit de lucht flikkeren en hun ruimteschepen het er niet veel beter van af brengen en het feit dat boeing heeft toegegeven dat ze flight critical software hebben uitbesteed aan de laagste indase bieder om vervolgens de FAA jarenlang te paaien met "wij controleren onzelf" (en de nodige -legale- gouden handdrukjes die daarbij horen) praat je niet meer over controle, maar over cultuur. en daar gaat geen vorm van controle tegen helpen. totdat de overheid ingrijpt.

en aangezien jij niet mijn achtergrond of (voormalige) werkgevers kent zou ik dusdanige uitspraken voor je houden.

[Reactie gewijzigd door flippy op 8 februari 2020 20:22]

praat je niet meer over controle, maar over cultuur.

Waarmee je mijn argument ondersteund dat het weinig te maken heeft met het outsourcen naar lage-lonen-landen, maar met de manier waarop er met controle wordt omgegaan (dat is namelijk onderdeel/gevolg van de cultuur).
Het gaat mij niet om jouw achtergrond. Ik pretendeer namelijk ook niet dat ik weet hoe de vork in de steel zit en ik ben ook maar een simpele applicatiebeheerder. Waar ik een bloedhekel aan heb is goedkope na-praterij.

nee, outsourcen HOEFT niet slecht te zijn. maar dan moet je de toko wel op orde hebben EN je moet competente outsourcing firmas hebben, boeing heeft beide niet.

Ah, we komen er wel.... Nog een klein stapje: Boeing heeft een verziekte bedrijfscultuur, heeft zijn interne besluitvorming niet op orde en dat is dodelijk in combinatie met een te grote focus op het tevreden houden van de aandeelhouders. Dat is wat er uit de media en uit rapportages te halen valt, die allemaal opgesteld zijn nadat het fout ging en zich concentreerden op de processen die hebben geleid tot de fout. En die dus (waarschijnlijk) maar een deel van Boeing beschrijven. Maar goed, terug on-topic:

Het gebruik maken van incompetente leveranciers (waaronder software-leveranciers) is een gevolg van de verkeerde focus, niet de oorzaak. In een competente organisatie, met de juiste focus en bedrijfscultuur, kunnen incompetente partners niet gedijen. Ze komen al niet door de eerste selectie en vallen zowiezo af bij de eerste opleveringen.
Daarnaast: heel veel bedrijven maken gebruik van lagelonenlanden en veel van die bedrijven steken erg veel energie en geld in het opkrikken van de kwaliteit van de producten uit dat land. Soms onder druk van de publieke opinie, maar vaak ook simpelweg vanwege de voordelen die je als bedrijf kunt halen: als je het voor elkaar krijgt de kwaliteit op een hoog niveau te krijgen, terwijl de lonen en andere kosten nog steeds laag blijven, dan ben je spekkoper. Ook hieruit blijkt: goedkoper programmeurs betekent helemaal niet slechte resultaten.

Één rotte CEO kan meer kapot maken dan 10 goeie kunnen opbouwen.

software is geschreven door indiers tegen minder dan miniumloon. CEO zit daar echt niet bovenop...

software is geschreven door indiers tegen minder dan miniumloon. CEO zit daar echt niet bovenop...

Snel al die Indische schoolverlaters de gevangenis in, alleen dan wordt vliegen weer veilig


De CEO zat daar niet bovenop? Wie heeft er in godsnaam anders besloten om goedkope Indiers in te huren dan?

Bovendien waren de Indiers en hun code het probleem niet. Het probleem in de 737 MAX was een probleem in het mechanische ontwerp en software ontwerp. En met ontwerpen hebben die ingehuurde Indiers helemaal niets te maken. Ontwerpen gebeurt gewoon in Amerika en daar is de CEO ook echt wel bij betrokken voor het nummer 1 meest belangrijkste product van het bedrijf.

[Reactie gewijzigd door GeoBeo op 8 februari 2020 11:20]

Als je geen drone-Indiers had gebruikt maar je eigen opgebouwde kennis dan had er wel iemand aan de bel getrokken omdat die uit ervaring een red-flag op zag komen. Die zombies tikken echter dom wat in met minimale kennis en ambitie en al helemaal geen feeling met hun werk. Who cares? Zij alvast niet.

De definitie van het 737 MAX probleem is zo ongeveer *leiders luisterden niet naar engineers met verstand van zaken*.

Als je je erin verdiept had, dan had je kunnen weten dat er intern meerdere malen door meerdere mensen bij Boeing gewaarschuwd en geklaagd werd over het inhuren van goedkope krachten.


Dat gezegd hebbende heeft het inhuren van goedkope krachten helemaal niets te maken met de kern problemen die tot de 737 MAX rampen geleid hebben. Die problemen zijn er nog steeds en dat zijn de problemen van management, bedrijfscultuur en corruptie in de VS.

Kern van het probleem: ze hadden geen zin in herkwalificatie van een nieuw toestel, dus hebben ze een airframe van meer dan 40 jaar oud aangepast zodat het nog net door kan gaan voor een 737, zonder piloten extra training te geven (terwijl het toestel wel anders reageerde en software had waar niemand vanaf wist). Via foute software hacks en volledig gebrekkige niet-redundante vlucht kritieke hardware die ze door de qualificatie heen gesjoemeld hebben is het ding op de markt gekomen. Met software die crashes veroorzaakt (door hardware fouten), zonder dat de piloten wisten dat die software bestond.

Dat heeft nogmaals met goedkope Indiers echt helemaal niets te maken. Die goedkoop ingehuurde Indiers zijn een gevolg van kansloos bestuur. Niet de oorzaak ervan.

Totale onzin.
In elke grote organisatie werken mensen die doen wat ze moeten doen zonder dat ze bezig zijn met de kwaliteit van het eindproduct. In elk groot project vindt je mensen die iets heel bijzonders kunnen, maar die weinig benul hebben van wat hun stukje inbreng nu werkelijk bijdraagt. En dat is helemaal niet erg. Ergens is er iemand bezig geweest om de bouten te produceren waarmee de dynamo van mijn Fiat is vastgezet aan het motorblok. Ik kan van die man niet verwachten dat hij zich druk gaat maken over het feit of de lengte van de bout die hij produceert wel voldoende is voor het gebruik in mijn Fiat.
Het bekt lekker om te spreken over "drone-Indiers", maar die denigrerende term kun je net zo makkelijk ombouwen naar "drone-Nederlanders" die op knoppen drukken, hendels overhalen, greppels graven en de telefoon beantwoorden.

Nou ja, betrokken... Met het hoofdkantoor 1200 mijl van de fabriek vandaan...

Nee, die besluit die lui in te huren en fatsoenlijke controle achterwege te laten.

Dat is interessant. Ik kan nergens iets vinden over het outsourcen van de software voor Starliner. Heb je een link?
En waar ik dan ook benieuwd naar ben is hoe Boeing die constructie heeft ingericht. Als je de normale processen volgt, wordt software gereviewed en getest. Deed Boeing dat zelf, of gebeurde dat ook in de lage lonen landen? De software werd getest in simulaties, werden deze simulaties ook gebouwd door diezelfde goedkoper programmeurs?
Dat zijn toch vragen die jij zou moeten kunnen beantwoorden als je zo stellig iets beweerd.

Ben benieuwd!

boing heeft slechts een erg klein kantoor (relatief gezien) in chicago waar een slordige 100~150 programmeurs werken. de rest van het werk gaat naar india. valt allemaal na te lezen op de financien van de shareholder meetings.

Ik heb het jaarverslag van Boeing van hun website geplukt en doorgesnuffeld. Geen enkele referentie naar het outsourcen van software development. Ik heb ook gekeken of er informatie uit de Shareholders meeting komt, maar ook daar "no dice". Ik heb mijn best gedaan en vraag nu nederig om een link waar ik die informatie wel kan vinden.

Wat ik ondertussen wel vond:
Boeing heeft ongeveer 5000 software engineers in dienst er staan vacatures open voor locaties in Missouri, California en Florida.

Over dat outsourcen kan ik wel wat vinden, maar voornamelijk krantenartikelen die elkaar napraten. Op Arstechnica, waar vaak erg goede artikelen staan, ook niets wezenlijks. In de comment-secties toch voor verwijzigen naar de cultuur waarbij geld en aandeelhouders belangrijker zijn dan kwaliteit. Maar dat wijst vooral op een foute cultuur, niet op foute programmeurs. Ook zijn er verschillende posters die verwijzen naar het feit dat je met een paar honderd programmeurs nooit kunt verwachten dat ze goed weten waar ze mee bezig zijn.

Wat ik ook ontdekte is dat Airbus de afgelopen jaren ook problemen heeft gehad met software, waardoor een aantal vliegtuigen uit de lucht zijn gevallen. Airbus wordt geproduceerd in Europa... Zou het misschien, heel misschien, zo kunnen zijn dat Boeing en Airbus niet zo heel verschillend zijn maar dat Airbus zijn vliegtuigen net even beter in de lucht weet te houden? Of zijn problemen uit de wind?

[Reactie gewijzigd door multikoe op 9 februari 2020 07:39]

Een aantal Airbussen uit de lucht gevallen. Interssant. Kan je me even doorverwijzen naar waar dat staat?

Chuckle:

What is the safest plane in the world?
The 737 Max will be the safest plane in the skies once it starts flying again.

What is the safest airplane?
1. Airbus 340. The A340 has approximately the same number of flying hours as the 777 and remains accident-free, making it number one is safety. Number in service: 355.
2. Boeing 777. At one accident per eighteen-million hours of flying, the Triple-Seven is number two in safety.


Moet je wel een HEEL goede verkoper zijn wil je een kist met twee crashes vlak na introductie veiliger noemen dan een kist met nul crashes op zijn naam
In tegenstelling tot wat Boeing graag doet geloven zetten wat modificaties de teller namelijk niet opeens op nul.

Jaren 60 tech, verschroten en opnieuw beginnen.

[Reactie gewijzigd door Tijgert op 9 februari 2020 18:39]

[/ignore]
Misschien... waarschijnlijk... toeval... dan weer wel een ongeluk dan weer niet. En dan vraag je je af waarom ik geen discussie aan ga?
[ignore]

Multikoe, ken je de wet van de grote getallen? Uit jouw post lijkt in elk geval van niet als je blijft spreken van toeval.
Als er per type vliegtuig honderden miljarden tot een biljoen kilometers per jaar wordt gevlogen dan speelt toeval nauwelijks meer een rol wanneer het gaat om systeemveiligheid.

Edit: typo

[Reactie gewijzigd door N0lan op 10 februari 2020 11:07]