Airbus A400M crashte als gevolg van softwareprobleem

Het op 9 mei verongelukte militaire transportvliegtuig Airbus A400M stortte neer vanwege een softwareprobleem. Dat meldt Der Spiegel op basis van bronnen bij de fabrikant. De motorregeleenheden zouden door een bug drie motoren kort na de start hebben uitgezet.

De Duitse krant Der Spiegel bericht dat Airbus-ingenieurs het probleem met de motoren dat tot de crash leidde lijken te hebben opgespoord. Door een softwarefout in de motorregeleenheden werden kort na het opstijgen tegenstrijdige opdrachten verzonden aan drie van de vier motoren. Daarop schakelden de drie motoren zich uit. De piloten probeerden nog om het toestel terug te laten keren naar de luchthaven, maar verloren de controle. Het toestel raakte drie minuten na het opstijgen een hoogspanningsmast en stortte vervolgens neer in een veld, circa vier kilometer van de luchthaven.

Het ging om een nieuw militair transporttoestel van Airbus Defence and Space, een dochter van de vliegtuigfabrikant, dat op 9 mei verongelukte. De in Spanje gebouwde A400M stortte neer tijdens een testvlucht vanaf de luchthaven van Sevilla. Het was de eerste crash met het toestel, dat geleverd gaat worden aan de luchtmachten van onder andere Duitsland, Frankrijk, het Verenigd Koninkrijk en België. De neergestorte A400M was bedoeld voor de luchtmacht van Turkije. In het vliegtuig zaten zes Spaanse medewerkers van Airbus. De crash kostte aan vier van hen het leven; twee anderen liggen nog steeds met zware verwondingen in het ziekenhuis. Een van de overlevenden vertelde al eerder dat motorproblemen de oorzaak waren van het ongeval.

Volgens Der Spiegel gaat het waarschijnlijk om een probleem in de desbetreffende installatie van de software, geen structurele ontwerpfout. Dinsdag had Airbus desondanks een oproep gedaan aan gebruikers van het toestel, een zogenaamde Alert Operator Transmission. Daarin schreef het bedrijf dat operatoren eenmalige checks moeten uitvoeren op motorregeleenheden, "om mogelijke risico's tijdens een volgende vlucht te voorkomen". Daarbij bevat het document ook andere controles die uitgevoerd moeten worden wanneer een motor of regeleenheid wordt vervangen.

Omdat nu een test bestaat die kan aanwijzen of een motor dezelfde softwarefout bevat als het verongelukte toestel, hoopt de fabrikant dat het na het ongeval opgelegde Spaanse testvliegverbod voor de A400M binnenkort wordt opgeheven, schrijft Der Spiegel. De fabrikant zou het Europees Agentschap voor de veiligheid van de luchtvaart ervan hebben kunnen overtuigen de vergunning van het toestel niet in te trekken. De Franse luchtmacht zou binnenkort weer willen gaan vliegen met de A400M. In Duitsland wacht men volgens Der Spiegel liever de resultaten van het officiële onderzoek af.

De ontwikkeling van de A400M verliep ook voor de crash verre van soepel. Het 20 miljard euro kostende project stond bekend om zijn eindeloze vertragingen, veroorzaakt door allerlei technische problemen. De nieuw ontwikkelde turbopropmotoren van het toestel zorgden al eerder voor hoofdbrekens. Zo leidde vertraging in de ontwikkeling van de motorsoftware in 2009 mede tot zo veel uitstel, dat Zuid-Afrika zijn order cancelde. In de afgelopen maanden werd het management van de Spaanse Airbus-dochter gereorganiseerd na nieuwe vertragingen.

Reacties (91)

Ter info:
Airbus Defence and Space is geen Spaanse dochter van Airbus. Het is een tak van het bedrijf dat is uitgespreid over de hele wereld, waaronder in Leiden (voorheen Dutch Space).
Het vliegtuig wordt overigens wel in Spanje gebouwd.

Dank voor je opmerking! Ik heb het even aangepast.

Niet goed getest dus? Doen ze soms niet aan geautomatiseerde testen met elk vorm van input die mogelijk is? De motorregeleenheden besluiten de motor uit te zetten aan de hand van bogus informatie die ze kregen, dan zit de fout toch niet daar in maar in het gedeelte wat die informatie aanlevert? Dus als 3 motoren verschillende input krijgen besluiten ze maar uit te gaan, dit is toch wel erg knullig hoor.

Niet goed getest dus? Doen ze soms niet aan geautomatiseerde testen met elk vorm van input die mogelijk is?

Dat is onmogelijk. Als je systeem 50 binaire inputkanalen heeft die elkaar onderling kunnen beinvloeden, heb je al een quadrillioen mogelijke combinaties. Test je er 100.000 per seconde, dan ben je meer dan driehonderd jaar bezig. In werkelijkheid zijn er natuurlijk veel meer dan 50 inputkanalen op een vliegtuig, dus je moet aannames doen over hoe ze elkaar beinvloeden. Alle mogelijke combinaties testen is niet te doen.

Ik snap wat je bedoelt, maar bij "tegenstrijdige opdrachten" hoef je er helemaal niet veel van te testen lijkt mij. Bovendien moet je het per subonderdeel bekijken om de testen gelimiteerd te houden. Lijkt me sterk dat een motor 50 binaire inputkanalen heeft. Blijkbaar zit in de motor ook iets slims, die als een failsafe bij tegenstrijdige berichten zichzelf uitschakelt.

Volgens mij moet daar ook naar gekeken worden, want op zijn minst moet de piloot te kunnen overrulen, als het in de lucht gebeurd (bogus info richting motoren), is dus de beste oplossing om de motoren dan maar stil te zetten? Volgens mij zijn hier meerdere dingen aan de hand. Architectuur welke nog niet uitontwikkeld is, en aanweizgheid van knullige bugs, geheel in de lijn van hoe het project eigenlijk verloopt en niet gek dat een aantal klanten al een aantal jaar geleden er uit zijn gestapt. Enkele zeer complexe ontwikkellingen van de laatste jaren (JSF o.a) hebben laten zien dat men de ontwikkeling toch nog ernstig onderschat, voornamelijk omdat de sw component tegenwoordig eigenlijk het grootste gedeelte van de ontwikkeling is, en daar nog steeds lichtzinnig over gedaan wordt. Dit gebeurd zowel bij overheidsprojecten als bij private bedrijven. Ingeschat altijd te laag, uiteindelijk is het minstens een factor 2 duurder kwa tijd/geld.

Het testen van alle mogelijke invoer is slechts 1 mogelijke strategie om de correctheid van software aan te tonen. Er zijn tal van gedocumenteerde methode, andere methode gaan bijvoorbeeld automatisch door code heen en produceren een lijst van mogelijke eindcondities van een routine, dit kan geautomatiseerd, waarna de kwaliteitsinspecteur kan nagaan of er een mogelijk ongewenste eindconditie tussen zit.

Een probleem is vaak dat dit soort systemen vrij low-level geprogrammeerd worden, wat correctheidsanalyse kan bemoeilijken.

Het is heel wat complexer dan dat. Je moet ook met dying nodes rekening houden. Namelijk dat onderdelen kapot kunnen.

Wat je nodig hebt is niet een dom programma dat op alle situaties goed reageert. Je hebt liever een slim programma, dan hoef je veel minder te testen namelijk.

Zo'n slim programma bouwen heb je gewoon de meest briljante AI programmeurs voor nodig. Zeg maar gerust UITVINDERS. Die zijn gewoon niet goedkoop. Ik ken er 1 die verdient een ton of 6 per jaar gemiddeld in New York. Het gros zit bij de NSA (=GOOGLE) @ 150k+ dollar per jaar en sommigen die enkel onderzoek willen doen vertrekken zelfs daar niemand ze een onderzoeksrol aanbiedt. Zo vertrokken er een paar richting China, ook geen goedkoop salaris overigens - maar ze mogen doen wat ze willen aldaar in HongKong.

Veel zitten thuis en verhuren zichzelf en proberen nieuwe producten op te zetten.

Geen van allen is goedkoop. In dit soort grote luchtvaartbedrijven doen ze simpelweg 0 moeite om zulke gasten binnen te krijgen. Laten we simpelweg zeggen: YOU GET WHAT YOU PAY FOR.

Het is heel wat complexer dan dat. Je moet ook met dying nodes rekening houden. Namelijk dat onderdelen kapot kunnen.

Een vaak gebruikte methode is om het hardware-platform en het OS afzonderlijk van het programma (hoog niveau gedrag) te certificeren.

Zo hoeft het high-level applicatieprogramma zich niet bezig te houden met hardware-failures maar hoeft er alleen getest te worden op problemen en bugs binnen dat programma, niet hoe het andere programma's of het OS beïnvloedt. Want die veiligheidslaag is al door het OS of door de hardware zelf afgehandeld.

Klopt veel te testen, maar uitzetten van de motoren zou je moeten kunnen overschrijven. Bij bij stert, te weinig snelheid waardoor uitzetten dit als gevolg kan hebben.

Wat je nu ziet is software die zelfstandig ingrijpt. Motoren uitzetten zou normaal altijd handmatig moeten gebeuren door de piloot lijkt me. Daarbij kun je dan ook nog denken eerst waarschuwing voor pilooot, deze moet dan binnen x sec ingrijpen en computer overulen. Zo niet kan de computer na x sec toch ingrijpen.

Het probleem is eerder dat alles willen automatiseren de complexiteit nog verder verhoogd. Het klinkt leuk de computer alles te laten doen zonder ingrijpen echter dan krijg je dus dit soort problemen.

Wat je nu ziet is software die zelfstandig ingrijpt. Motoren uitzetten zou normaal altijd handmatig moeten gebeuren door de piloot lijkt me. Daarbij kun je dan ook nog denken eerst waarschuwing voor pilooot, deze moet dan binnen x sec ingrijpen en computer overulen. Zo niet kan de computer na x sec toch ingrijpen.

Dat klinkt heel leuk maar heeft niet altijd veel zin, bijvoorbeeld als er brand ontstaat in een motor, of er een hydraulisch-, smeerolie- of brandstoflek ontstaat, moet zo'n computer gelijk de boel uitschakelen om een onveilige situatie (een ontploffende motor) te voorkomen. Een mens die moet reageren op een lampje in de cockpit, is dan niet snel genoeg.

Uit veiligheidsoogpunt deed de computer het juiste, namelijk de motoren uitschakelen als er iets verkeerds werd geregistreerd, alleen werd er geen rekening gehouden met het feit dat die motoren een voorwaarde waren om de kist in de lucht te houden.

Bot gezegd: Als er tijdens de start een probleem optreedt in de motoren, dan kiest zo'n computer er ook voor om neer te storten in plaats van de kist uit elkaar te laten knallen.

Je gaat hier voorbij aan het feit dat een brandende motor vaak alsnog een deel van zijn vermogen kan leveren. Vermogen dat je juist tijdens en net na het opstijgen hard nodig kunt hebben. Ikzelf word getraind om bij een engine fire tijdens take off de brandende motor te blijven gebruiken tot een veilige hoogte is bereikt en hem dan pas gecontroleerd uit te schakelen.
Ook worden vliegtuigmotoren gebouwd om een explosie tot op zekere hoogte te kunnen weerstaan (contained engine failure). Daarnaast wordt het overgrote deel van de uncontained engine failures niet vooraf gegaan door extreem abnormale readings die een engine shutdown nodig maken. Ze zijn vaker het gevolg van bijvoorbeeld metaalmoeheid waardoor de motor opeens uit balans raakt en zelfs een computer met uitzetten al te laat is.

Voor zover ik weet is dit bij Airbus niet anders. De enige automatische shutdown die ik daar ben tegen gekomen is in geval van APU fire on ground, voor het geval er niemand in de cockpit is op dat moment.

AI schrijven is gewoon niet zo simpel. De grootste AI experts werken echter niet in de luchtvaart. Men doet het minimum om iets goed werkend te krijgen in plaats van software schrijven die iets slimmer is. Dit laatste is niet eenvoudig en Airbus doet daar al meer dan Boeing - maar men trekt er niet hard genoeg aan.

Het probleem bij Airbus is dat ze vliegtuigen (willen) maken die zichzelf vliegen en alleen gemonitord worden door de piloten. Bij Boeing daarintegen zijn ze wat kritischer ten opzichte van computers en ondersteunen ze liever de piloot en laten die de finale beslissingen nemen.

Dacht ik ook al software design probleem...

De Airbus software is opgebouwd uit basismodules. Daarboven op worden patches aangebracht.
Bij een nieuw model worden de basismodules gebruikt....
euh...kan je gelijk weer alle patches erop zetten. (zijn er honderden...)

Dat het regelmatig fout gaat met het software management heeft regelmatig tot crashes of near-accidents geleid bij Airbus.

Wat ik zelf ellendig vindt is dat de stick input 'verminderd' wordt bij landen/opstijgen...als de wielen nog grondcontact hebben. Dit om te voorkomen (dacht Airbus designteam) dat een piloot door extreme roeruitslagen het vliegtuig op zijn zij krijgt....
Wanneer je zijwind(-stoten) hebt reageert je toestel dus niet zoals je verwacht. Ja kan gewoon niet meer maximaal corrigeren.
Als je joystick adaptief gaat reageren dan weet jij dus niet wat er gaat gebeuren.

Laat de piloot het laatste woord hebben. En niet de computer.
Uiteindelijk moet je iets vertrouwen. Mens of Machine?

http://www.kls2.com/[e-mail]%3E

http://www.fastcodesign.c...airbus-killing-228-people

Het mooiste verhaal kan ik niet meer terugvinden. Bij een Airbus op kruishoogte besloten 3 van 4 vliegcomputers dat het vliegtuig op zijn kop vloog.

Met als resultaat een rol om de as van 180 en het vliegtuig dus echt op zijn kop. De bemanning was zo slim om de boordcomputers uit te schakelen (voor zover mogelijk) en handmatig de controle terug te krijgen van het vliegtuig.

Boeing is tenminste zo slim geweest om naar het efficiente 'Fokker' ontwerp proces gekeken en heeft deze methode overgenomen en verbeterd.
Maak de software in modules. Corrigeer de modules en optimaliseer ze, niet met patches werken. En optimaliseer het ontwerp gezamelijk aan iedereen die met het vliegtuig moet werken. Piloten, BWK, Monteurs, Programmeurs, Staf, Klanten etc.

[Reactie gewijzigd door kwakzalver op 20 mei 2015 18:25]

Het is tijdens een testvlucht dat dit gebeurde!
Testvluchten zijn er om systemen te testen en helaas gaat het dan soms mis. Zelden echter zo mis als deze ramp.

Er moet wel aangetekend worden dat dit om een leveringstest ging. Het toestel wordt al een tijdje geleverd en verscheidene landen vliegen er al mee.

Het was dan ook geen testvlucht om een nieuw model of nieuwe technologie te testen. Het was een QA vlucht. Een routine test tussen het van de lopende band af rollen en de levering aan de klant.

Dat maakt het overigens ook interessanter aangezien het dus waarschijnlijk komt door een vrij zeldzame samenloop van omstandigheden. Als dit probleem zich nooit heeft voor gedaan in testvluchten tijdens de ontwikkeling en nooit tijdens gewoon gebruik door de verschillende legers moet het vrij uitzonderlijk zijn.

<quote>Volgens Der Spiegel gaat het waarschijnlijk om een probleem in de desbetreffende installatie van de software, geen structurele ontwerpfout.</quote>
Dit is dus gewoon onderdeel van de leveringstest, controleren of de specifieke configuratie klopt.

Wat ik vreemd vind is dat et in de directe omgeving van en test faciliteit blijkbaar hoogspanningsmasten staan ...

Vliegtuigen vliegen in de regel hoger dan zo'n mast, niet ertussen en fabrieken vliegvelden durven nogal wel eens wat elektriciteit verbruiken.

Het is een onacceptabele fout van de software simpelweg.

Dus als 3 motoren verschillende input krijgen besluiten ze maar uit te gaan, dit is toch wel erg knullig hoor.

Niet noodzakelijk, dat is ook nodig (feature dus) voor een gevechtsmanoevre, bijv. een "Defensive spiral". U moet geen burgerluchtvaart en militaire luchtvaart door elkaar halen! --> Het gaat hier om een toestel dat militaire manoevres moet kunnen uitvoeren, en ja, daarvoor moeten de motoren soms uit. Eisen lijken me hierbij complexer dan bij burgerluchtvaart. Het liefst moeten ze daarna ook weer aan, mogelijk is het daar fout gegaan.

[Reactie gewijzigd door kidde op 20 mei 2015 16:13]

Ook voor dat soort acties wil je geen motor uitzetten. Het opnieuw aanzetten kost nogal veel tijd (seconden) en dat is juist in die omstandigheden onacceptabel.

in plaats daarvan zet je de propellorbladen in de vaanstand, zodat ze netto geen voorwaartse kracht meer leveren. Ze blijven wel draaien, en hebben nog wel enige luchtweerstand, dus je turbine blijft draaien, maar op 10% vermogen en 90% RPM. Vanuit deze stand kun je veel sneller terug naar vol vermogen.

Een defensive spiral met een vrachtvlieguig? Kan ik me bij de A400 niet zo goed voorstellen. HIj is leeg voor een vrachtvliegtuig wel heel erg wendbaar, maar ik zie hem volgeladen tot max take-off weight zo'n maneuvre niet maken.

Er is ooit eens een beademingtoestel voor tijdens operaties op de markt geweest dat crashte als 1 van de usb-poorten werd gebruikt om een telefoon op te laden. Software-kwaliteit is gewoon een giga probleem in verschillende industrieën en veel heeft te maken met het te grote aanbod aan studierichtingen waarbij iedereen zich programmeur noemt en het feit dat bedrijven er niet genoeg budget voor uittrekken...
Triestige zaak, temeer omdat er slachtoffers bij gevallen zijn

Ik denk wel dat software in medische en andere kritische apparatuur veel beter getest wordt dan consumenten elektronica firm / software, maar 100% garantie heb je nooit, dat blijkt hieruit weer. Bij consumentensoftware worden veel te snel nieuwe updates uitgerold terwijl de bestaande versie nog niet eens af is. Marketing druk zorgt er vaak voor dat nieuwe functionaliteit / mooiere user interface prioriteit hebben boven niet of slecht werkende bestaande functionaliteit.
Als de software in vliegtuigen of medische apparatuur zo brak zou zijn als PC of smartphone software zouden er veel meer doden zijn gevallen.

Aan de andere kant zien we nu, anno 2015 nog steeds nieuwe apparatuur met XP uitgerold worden in het ziekenhuis. Reden van de fabrikant: het is stabiel en het toestel heeft hiermee de conformiteitsverklaring verkregen. Hetgeen betekent dat zelfs windows updates niet toegepast mogen worden omdat dit een wijziging in het beproefde ontwerp zou kunnen betekenen. (tenzij getest en goedgekeurd, maar dit gebeurd niet zo heel vaak)

Ik wil hiermee aangeven dat dit soort problemen vaak twee kanten hebben. Enerzijds heb je een bak met exploits en vulnerabilities, die in het beste geval in een VLAN hangt, maar je mag niet updaten omdaten je toestel dan niet meer voldoet aan de wettelijk gestelde eisen.

Apparatuur? Ik neem aan dat je de computer als HMI bedoeld? Ik zou geen enkel proces gerelateerd systeem met XP laten besturen. Behalve secundaire niet kritische logging en een HMI.

Verder heb je nog op Windows CE geschoeide mini embeddet PLC's. Voor kleine processen, maar daar draait geen XP op.

[Reactie gewijzigd door BUR op 20 mei 2015 13:31]

Er bestaat ook zoiets als XP Embedded. Dat is nog wel ondersteund, juist omdat er hele delen ontbreken (geen IE, bijvorbeeld) en die delen dus ook geen security risks met zich meebrengen.

Nee. Helaas niet altijd als HMI. Als voorbeeld patienten bewaking. De bedzijdige monitoren draaien allemaal een embedded variant van linux. Geen problemen daar. De centrale posten, waarop alle alarmen binnenkomen draaien op XP met daarover een softwarepakket van de fabrikant. Deze computer word door de instanties getest als een medical device en moet als zodanig aan de hieraan gestelde eisen voldoen. Vanaf dat moment is het dus geen standaard PC meer. Dit betekent dat je niet een netwerk naar eigen inzicht kunt gaan inrichten omdat de fabrikant dan niet kan garanderen dat alarmen real-time binnenkomen. Hetzelfde geld voor securitypatches; je verandert wezenlijk iets aan een medical device. Het zal je verbazen wat er allemaal op windows draait. Van GE zijn er zelfs ECG toestellen die op NT draaien. Het gaat niet altijd om de gevaren van het internet. Het is niet voor niets dat de meeste ziekenhuizen tegenwoordig ACL's, 802.1X en certificaten gaan toepassen.

Zolang die XP bakken niet met internet verbonden zijn lijkt me dat geen probleem.

Als de software in vliegtuigen of medische apparatuur zo brak zou zijn als PC of smartphone software zouden er veel meer doden zijn gevallen.

Je zou daar wel eens van kunnen verschieten. In europa is dit niet zo gekend omdat die onderzoeken niet publiek zijn, maar in VS wel. Je moet maar eens googlen op insulin pomp software (en ik heb het niet over de beveiligingslekken)

Voor safety critical software wordt in de vliegtuigindustrie geen Windows-XP toegepast. Ook niet de embedded varianten (XPE of CE). Dat is niet te certificeren.
Dergelijke safety critical software draait of
- op geen operating system, men spreekt dan meer over service layers
- op gespecialiseerde operating systemen, zoals bv. de DO-178B versie van GreenHills Integrity.

Er is ooit eens een beademingtoestel voor tijdens operaties op de markt geweest dat crashte als 1 van de usb-poorten werd gebruikt om een telefoon op te laden.

Wat maar weer aangeeft dat je als ontwikkelaar of tester echt met alle onwaarschijnlijke situaties rekening moet houden. Wie haalt het in z'n hoofd om z'n telefoon op een dergelijk apparaat aan te sluiten

Dat is inderdaad het geval. Als je er vanuit gaat dat iedereen je software gebruikt op de manier waarop jij het bedoelt hebt dan ben je naïef. Het is bijna onmogelijk om alle situaties te testen. Maar het is niet verkeerd om een willekeurige gebruiker zonder instructies even aan te laten knoeien. Een soort monkey test, maar dan niet geautomatiseerd.

Ook als je geen telefoon aansluit maar iets voordehandliggenders had dat wel fout kunnen gaan. De implementatie van een USB poort hoort in alles dat binnen de USB spec is, en mogelijk nog wat dingen erbuiten, te voorzien.

Als die poort daar niet tegenkan, dan gebruik je een andere connector waar geen standaardapparaten op passen.

Dat zijn echt basis-ontwerpregels.

[Reactie gewijzigd door mae-t.net op 21 mei 2015 02:21]

Het is onmogelijk om letterlijk *elke* situatie te testen die ooit mogelijk zou kunnen voorkomen. Dat zie je ook vaak terug in die docu's over crashes, vaak is de oorzaak een specifieke combinatie van factoren die voorheen dus niet voorzien waren.

Je moet een situatie kunnen voorzien om erop te kunnen testen. Voorzie je een specifieke situatie niet, dan kun je er dus ook niet op testen...

Elke stituatie is onmogelijk, maar elke inhoud van een variabele die mogelijk is, is wel geautomatiseerd te testen, dat is waar ik op doelde.

Je bent dan al vrij snel een onrealistische hoeveelheid aan waardes aan het testen. Ter illustratie, neem aan 32bit adder (Iets dat twee 32bit getallen kan optellen en een 33bit getal produceert).

Met 64inganegen (32+32) zijn er 2^64 mogelijke combinaties om te testen. Stel je zou input combinaties kunnen testen met 100MHz (100'000'000 combinaties per seconden) dan zou je 140'386 jaar bezig zijn om ALLE combinaties te controleren. [1]

En dit geld dus al voor een compleet triviaal circuitje. Dan moet je je proberen voor te stellen hoe dat gaat met een complex circuit of met echte software. Je zal ergens moeten scopen naar wat je wilt testen en wat niet.

[1]: 2^64 / 100e6 / 3600 / 365 = 140386,180

[Reactie gewijzigd door zerokill op 20 mei 2015 11:43]

En dit geld dus al voor een compleet triviaal circuitje. Dan moet je je proberen voor te stellen hoe dat gaat met een complex circuit of met echte software. Je zal ergens moeten scopen naar wat je wilt testen en wat niet.

Je moet er bij een 32-bit adder natuurlijk rekening mee houden dat de inputs van die adder wel onafhankelijk zijn,. Die zitten hooguit paarsgewijs (inputs A en B ) aan elkaar gekoppeld.

Uiteindelijk kun je dat opbreken in een aantal adders waar 1-bits inputs in gaan (a, b en carry) die relatief eenvoudig te analyseren zijn.

Het wordt een stuk ingewikkelder bij afhankelijke ingangen.

[Reactie gewijzigd door Stoney3K op 20 mei 2015 15:46]

Leuk bedacht maar een firma als airbus heeft natuurlijk een tuintje met supercomputers. Stel ze gooien er 1 peta-instructie per seconde tegenaan dan is die adder in 5 dagen getest.

maar dan moet je serieus gaan opletten dat de hardware waarop je test, dezelfde is als waar het product gaat uit gemaakt worden. De ene cpu is de andere niet...

Klopt, en volgens mij wordt daar ook rekening mee gehouden.
Nu is het ook nog zo dat dit soort stuursystemen met integers worden doorgerekend en die zijn niet zo complex als floating points. Er valt dus makkelijker zekerheid te krijgen over de systemen.

Daarom zoek je vantevoren een set kritische- en randwaardes bijelkaar om mee te testen. Als die set een beetje fatsoenlijk gekozen is, is de test vrijwel even goed als alle combinaties testen.

Het aantal mogelijke inputs is een factoriale functie. Die kan je nooit allemaal testen. Ik denk dat individuele modules grondig getest worden, maar als er een fout zit in de onderlinge communicatie kan het alsnog fout gaan. Ook dat is lastig te testen omdat ook daar de mogelijke combinaties van inputs snel groeit.

Neem maar aan dat die software uitgebreid getest wordt. Het is makkelijk om te testen op situaties die je kunt voorzien. Veel moeilijker om te testen op onvoorziene interacties van verschillende situaties. Je doet een aantal simpele aannames over de logica in de motorregeleenheden terwijl de werkelijke code vele malen complexer is.

wat ik niet begrijp is dat er dan 3 van 4 "geraakt" worden door de bug. Zijn er dan 4 verschillende systemen aanwezig? en is dan niet alles geupdate? bugs zijn dus niet 100% fail-proof?

Niet perse hier van toepassing, maar op het gebied van Functional Safety (IEC/ISO/MIL) kan er geeist worden dat een implementatie dubbel uitgevoerd wordt door verschillende partijen. Dat betekent dat op basis van dezelfde specs er meerder implementaties gemaakt worden die naast elkaar bestaan en gecontroleerd worden. Een veiligheidsmechanisme zorgt voor afhandeling van verschillen tussen de implementaties.

Het probleem is dat veiligheidsmechanisme. Die heeft de metacontrole en moet concluderen dat als je nog in de lucht zit dat je dan niet zo snel motoren moet uitschakelen.

Kortom je verlegt het probleem dan naar een 'zwarte doos' die heel slim moet zijn.

Dat stukje slimme software is dan ook net wat ontbreekt in de luchtvaart. Dat gaat niemand pennen natuurlijk zonder dat er enorm veel geld ingestoken wordt.

Dat wordt er niet ingestoken.

Het probleem is dat veiligheidsmechanisme. Die heeft de metacontrole en moet concluderen dat als je nog in de lucht zit dat je dan niet zo snel motoren moet uitschakelen.

Kortom je verlegt het probleem dan naar een 'zwarte doos' die heel slim moet zijn.

Dat stukje slimme software is dan ook net wat ontbreekt in de luchtvaart. Dat gaat niemand pennen natuurlijk zonder dat er enorm veel geld ingestoken wordt.

Dat is ook niet altijd mogelijk, als je bijvoorbeeld bij de start een motorbrand krijgt of een olielek, dan kun je ervoor kiezen om óf de motoren door te laten draaien en het toestel brandend neer te laten storten (of al dan niet te laten exploderen) met de kleine kans dat het er heelhuids uitkomt en je kan landen, óf de motoren uit te schakelen zodat het toestel zeker weten neerstort.

Dat is een beslissing tussen twee kwaden waar een hoop ethiek bij komt kijken - iets wat je niet aan een computer overlaat.

Nee, dat veiligheidsmechanisme moet helemaal niet controleren dat je nog in de lucht bent. Veel te complex. De supervisor moet alleen de outputs van meerdere beslissers vergelijken, en de beste conclusie kiezen. Vaak genoeg is dat een simpele 2-uit-3 keuze. "Brand-Brand-Niet brand" -> kies optie "brand".

De omstandigheden zijn natuurlijk niet exact hetzelfde. Op het moment dat er al 1, 2 of 3 motoren uit gaan/staan dan is de situatie al weer anders dan op het begin toen ze allemaal draaiden.

Simpel gezegd zou het kunnen zijn dat de bug niet optreed als er nog maar 1 motor draait.

Ja door een of andere integer die dan opeens wel de null check passeert(ik zeg maar wat).

Kan ook zijn dat er na de 3 motoren een noodsysteem aan werd gezet waardoor de bug niet meer optreedde.

Hte probleem met bugs is dat ze niet-bedoeld zijn, en dus een heel scala aan onvoorspelbaar gedrag kunnen vertonen. Stel bijvoorbeeld dat je een regel hebt dat je een motor uitschakelt als deze 200 graden boven de gemiddelde temperatuur komt, en de bug is dan je een 0 vergeet. Dan schakelt een motor dus uit bij 20 graden boven temperatuur. En als bij een start de motoren net iets harder draaien kan het goed zijn dat ze 15 tot 25 graden warmer zijn. Het is dan onvoorspelbaar welke motoren er boven de (foute) 20 graden grens komen.

Nu is het onwaarwchijnlijk dat het zo'n simpele fout is, maar het algemene idee (verkeerde verwerking van inputs) kan verklaren waarom niet alle motoren hetzelfde reageren : ze producreren niet allemaal dezelfde inputs voor de zelfde software.

helder.

goed punt. Draaien allemaal andere software kennelijk, of misschien is er 1 master en de rest slave.
Kennelijk is de motor afzetten een soort 'or' funktie. Als 1 van de 300 sensoren een probleem aangeeft; schakel de motor uit.

Lijkt me stug dat er andere software op gedraaid wordt.. Men moet denken aan verschillende parameters.

Ik weet absoluut niks van vliegtuigbouwkunde, maar wellicht stonden die 3 motors iets dichterbij een bepaalde leiding.. waardoor ze net een graadje warmer werden en een andere procedure (binnen dezelfde software) werd getriggerd.

Het kan aan zo verschrikkelijk veel dingen liggen, maar ik neem wel echt aan dat dezelfde revisies van dezelfde software wordt gedraaid.

bugs zijn dus niet 100% fail-proof?

Dat lijkt me by design toch; dat een bug niet 100% fail-proof is. Juist andersom; je hebt een grotere kans op 100% fail doordat er een bug in het systeem is.

Er zijn 4 regeleenheden op een A400, 3 daarvan kregen de verkeerde info en stuurden verkeerde info terug. De centrale computer koos er toen voor om alle 3 de motoren uit te zetten.

Het lijkt me dus meer dat de computer een bug bevat die ervoor kiest om 3 motoren tegelijk uit te zetten terwijl een A400 met 1 resterende motor per definitie naar beneden zou komen; er is dus geen keuze gegeven aan de bemanning (aanname) om motor 2 of 1 te overriden en handmatig te bedienen, waar mogelijk.

Er staat dat de motoren zichzelf uitschakelden omdat ze tegenstrijdige opdrachten kregen. Dat lijkt me voor de motor niet wenselijk. Het is echter raar dat ze van verschillende kanten opdrachten krijgen. Dan lijkt het alsof er op verschillende manieren gestuurd kan worden en dat lijkt me nooit wenselijk. Sowieso is het beter om te werken met een systeem waarin je, als je al tegenstrijdige opdrachten kan krijgen, je één bron als belangrijkste beschouwt.

Ik kan me wel voorstellen dat je zaken meervoudig uitvoert om als fail-safe te kunnen dienen. Echter, meestal is het in het geval van fouten zo dat de meerderheid beslist en het foute systeem gemarkeerd wordt. Als je niet meer kan beslissen lijkt het me ook niet handig om dan maar de motoren uit te zetten. Het blijft natuurlijk gissen, ik werk niet in de luchtvaartindustrie maar in de software.

De grootste bug lijkt mij dat een computer bepaalt of motoren 'zomaar' worden uitgeschakeld zonder dat het voor piloten vervolgens uberhaupt nog mogelijk is deze handmatig te herstarten indien er ogenschijnlijk niets aan de hand is.

Ik weet niet of je dat nog vol kunt houden, gezien in moderne motoren de computer niet enkel bepaalt of de motor aan of uit is, maar direct controle heeft over de injectiesystemen en kleppen van de motor. Computers en software zijn onderdeel van de motor geworden... zonder software geen aandrijving.

zonder software geen aandrijving.

Zonder software geheel geen besturing van het vliegtuig. Dit heet Fly-By-Wire, denk een vliegtuig versie van stuurbekrachtiging. Het is al heel, heel lang niet meer mogelijk om zonder electronica en software een vliegtuig te besturen.

@dmantione:
Je bedoelt dus gewoon backup systemen.

[Reactie gewijzigd door Cergorach op 20 mei 2015 14:52]

Ik denk dat dmantione naar de "FADEC" verwijst. Dit is de "Full Authority Digital Engine Control", de digitale motoraansturing. Een moderne motor heeft veel te veel onderdelen om individueel aangestuurd te worden. De FADEC vertaalt het high-level commando van de piloot (meer vermogen) in individuele commando's (3% meer brandstof door primaire brandstofpomp, 2% meer olie, etc ... )

Als dat waar is dan:

FADEC verlicht dus de werklast van de piloot; deze kan trouwens niet meer ingrijpen in de controle van de motoren (daarom is het "full authority"). Voor de veiligheid is het uiteraard essentieel dat FADEC zo betrouwbaar mogelijk is; als het systeem uitvalt, valt ook de motor uit. Een FADEC-systeem is voorzien van ingebouwde redundantie: er zijn minstens twee ECU's, die elk afzonderlijk kunnen functioneren. Ook de sensoren zijn dubbel uitgevoerd. De software in de regelaar moet fouttolerant zijn. Voor de energievoorziening moet er een back-up systeem zijn dat onafhankelijk werkt van de primaire voeding.

Dat is dus geen handbediening, het is de backup van de FADEC. Ik betwijfel trouwens of de piloot enig benul heeft hoe hij de brandstof moet regelen in zijn motoren...

Ja en nee. De piloten kunnen hun de computers in de cockpit gerust rebooten en als die computers niet werken, dan is de handbediening gewoon functioneel. De handbediening werkt echter met elektronica en het zou me verbazen als er onderweg niet ook weer ergens software tussen zit.

'Even herstarten' is er helaas niet bij, bij dit soort motoren. Dat duurt even wat langer, en waarschijnlijk hebben ze daar sowieso geen tijd voor gehad.

Standaard procedure is de autopilot uitzetten en dan herstarten.

Standaard procedure is de autopilot uitzetten en dan herstarten.

Dat had prima gewerkt als ze niet te dicht bij de grond zaten.

Aan de andere kant, als ze genoeg hoogte hadden gehad dan hadden ze op één motor kunnen omkeren en landen. Daaruit kun je al concluderen dat er iets fout is gegaan bij óf het opstijgen óf het klimmen naar kruishoogte toe.

[Reactie gewijzigd door Stoney3K op 20 mei 2015 15:20]

Autopiloot? De elektronische systemen van een AIrbus zijn complexer dan dat, er zijn een heleboel subsystemen. En je gaat niet alles meteen rebooten om een probleem met een enkel subsysteem op te lossen.

Een gebruikelijkere ingreep in een Airbus is dat je naar alternate mode terugschakelt, waarin de piloot vliegt en de elektronica controleert.

Waarom draaide die ene motor nog ? En was die ene motor niet meer voldoende om een gecontroleerde (crash-) landing uit te voeren ? In principe hoeft de langdingsbaan niet eens bereikt te worden door dit type toestel. De A400M zou zo ook op een veld kunnen landen ...

Dit vroeg ik me ook al af. Het is niet alsof door het uitvallen van drie motoren het vliegtuig spontaan uit de lucht valt. Ze zullen vast niet voldoende voorwaartse kracht meer hebben gehad waardoor ze snel zouden dalen, als dan juist er een stroom mast in de weg staat heb je een probleem, want je heb niet de kracht in huis om deze te ontwijken. Het is vier maal pech, 3x een motor die uitvalt en dan nog eens een stroom mast in de weg. Ik vermoed dat ze op twee motoren wel redelijk hadden kunnen landen (hoewel de veiligheidsmarges op militaire vliegtuigen wel iets lager liggen dan in de civiele luchtvaart).

Waarom draaide die ene motor nog ? En was die ene motor niet meer voldoende om een gecontroleerde (crash-) landing uit te voeren ? In principe hoeft de langdingsbaan niet eens bereikt te worden door dit type toestel. De A400M zou zo ook op een veld kunnen landen ...

Naar beneden was niet zo moeilijk geweest, maar je hebt wel een probleem als je net opgestegen bent en de motoren uitvallen als je de wielen nog amper hebt ingetrokken.

Je zou toch verwachten dat er voor de absolute basis onderdelen om een vliegtuig überhaupt in de lucht te houden en te laten landen een soort manual override is, die gewoon mechanisch te bedienen is en elke mogelijke software negeert?

Ja en nee.. Die dingen om vliegtuigen in de lucht te houden zijn ook al vele malen de oorzaak geweest van een ongeluk.
Dus bij bepaalde inputs moeten deze uitgeschakeld worden (brand, extreme vibraties, onderdelen die gewoon niet meer werken etc). Je zou dan nog kunnen denken aan dat de piloten een specifieke checklist moeten afwerken om hem misschien weer aan de praat te krijgen.

Maar het uitschakelen van die dingen valt natuurlijk in de categorie: ramp voorkomen. Wel ironisch dat juist door een bug nu een ramp is ontstaan..

Lijkt me lastig als tegenwoordig veel vliegtuigen fly-by-wire/fly-by-computer zijn. Het is dus niet meer mogelijk alleen analoog/mechanisch te vliegen. Dit heeft in de burgerluchtvaart vooral met gewichtsbesparingen te maken.

Heeft niet vooral met gewichtsbesparing te maken, heeft te maken dat de piloot mechanisch niet voldoende kracht heeft om de flappen te 'besturen'. In sommige gevallen is het vliegtuig zo 'onstabiel' dat het niet gevlogen kan worden door een mens zonder assistentie van elektronica/software. Dezelfde reden waarom de meeste voertuigen tegenwoordig stuurbekrachtiging hebben.

"Instabiel" is een eigenschap van gevechtsvliegtuigen. Die moeten heel snel van koers kunnen veranderen. Dan helpt het bepaald niet als je vliegtuig van nature stabiel is. Maar vrachtvliegtuigen zijn geen gevechtsvliegtuigen, en kunnen geen 9G bochtjes trekken of de afterburner aanzetten om omhoog te schieten. Dan is het ontwerpcriterium juist stabiliteit, zodat je niet uit de lucht valt als er iemand een paar kogelgaten in je vleugel erbij maakt.

Dat zijn inderdaad de meeste gevechtsvliegtuigen, maar ook een aantal civiele vliegtuigen (denk de supersonische vliegtuigen zoals de Concorde en kornuiten, maar ook een aantal business class vliegtuigen). En ik geloof dat een aantal transport vliegtuigen ook niet geheel onder de 'stabiel' noemer konden worden gezet, volgens mij waren dat ook Airbus modellen.

Oh, in het algemeen worden de staartvlakken etc niet zo groot ontworpen dat ze het vliegtuig compleet stabiel maken; stabiel genoeg om door een mens gevlogen te worden is goed genoeg. Een té grote staart geeft alleen maar nodeloze luchtweerstand.

Van de architect tot de ingenieur tot de programmeur, allemaal even belangrijk.

Je zal maar te horen krijgen als engineer of tester, dat een bug die je over het hoofd hebt gezien een aantal levens heeft gekost... Moet er niet aan denken.

Je zag het ook bij AF447. De stall-warning ging daar uit omdat het vliegtuig zo langzaam vloog dat de computer daar niet meer in voorzag.
De ontwikkelaars hadden er geen rekening mee gehouden dat een Airbus330 langzamer zou gaan vliegen dan een Cessna.

Uit deze situatie blijkt dat het té ingewikkeld wordt. Als een software combinatie niet meer op alle vlakken getest kan worden is er iets mis. Je moet het kunnen onder controle houden, het complete project.
Keep it small and simple is één van de slogans die op IT zeker van toepassing blijft.
Het is duidelijk dat ze in de uitwerking van deze software daar te weinig rekening mee gehouden hebben. Waarschijnlijk in verschillende blokken software ontwikkeld en deze later niet voldoende op mekaar afgesteld en/of getest. Is een groot risico als de coördinatie niet goed gebeurt, de projectleiding de fout in gaat.
Ik vind dit geen goede ontwikkeling.