Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 88 reacties

De crash van een Airbus A400M, begin vorige maand bij het vliegveld van Sevilla, kwam door slecht geconfigureerde software. Dat stelt Airbus zelf. Het vliegtuig, dat was besteld door het Turkse leger, crashte tijdens een testvlucht.

Eerder deed het bericht al de ronde dat het vliegtuig was neergestort door een softwareprobleem, al werd dat later weer tegengesproken door het Duitse leger, dat over hetzelfde vliegtuig beschikt. Volgens Airbus zelf gaat het echter wel degelijk om een softwarefout, al was er met de software zelf volgens het bedrijf niets mis. In plaats daarvan zou de software verkeerd geconfigureerd zijn, schrijft Handelsblatt.

De verkeerd geconfigureerde software zou de motoren van het toestel hebben moeten aansturen. Eerder meldde Der Spiegel al dat door een softwareprobleem tegenstrijdige opdrachten aan drie van de vier motoren werden verstuurd. Of dat klopt, is niet duidelijk.

De Airbus A400M, een vrachtvliegtuig, stortte neer tijdens een testvlucht. Het toestel, dat over propellers in plaats van straalmotoren beschikt, was besteld door het Turkse leger. Bij de crash kwamen drie mensen om het leven.

Moderatie-faq Wijzig weergave

Reacties (88)

Bizar, vroeger was in een vliegtuig (mechanisch) alles dubbel uitgevoerd.
Met de fly by wire systemen is dat niet meer mogelijk?
Nergens een backup computer met versie 1.0 of iets dergelijks?
Of een altijd werkende test basis/backupversie waarnaar je in iedergeval kan booten waarmee basic functies zoals motoren roeren e.d. kan worden bediend.
Thuis word je ermee om de oren geslagen, backup je tel/tablet, zet je pc in decloud voor backup enz.
Tja bizar....
:/
De A400M heeft vierdubbele redundantie in z'n fly by wire systeem, deze heeft 3 (of 4) werkingsmodi:
- Normal law: normale werking met alle toeters en bellen
- Alternate law: werking met minimale beveiliging tegen stalls, bank angles etc (beveiligings zijn gesplits in a & b)
- Direct law: joystick inputs worden rechtstreeks vertaald naar het hydraulisch systeem of elektrisch backup systeem

Het hydraulisch systeem bestaat uit 2 onafhankelijke, redundante systemen. En er is ook nog een elektrisch backup systeem.

Dit biedt voldoende veiligheid maar in het geval van een software probleem moet de piloot uiteraard het probleem kunnen vaststellen en switchen naar een andere mode, wellicht is dit hier niet gelukt.
De verantwoordelijke module FADEC (full authority digital engine control (unit)) heeft weinig te maken met deze 'laws'. De centrale aansturing van deze FADECs kent vanuit de laws slechts twee mogelijke inputs: piloot of auto-piloot. Verder zijn het enkel omgevingsinputs van toepassing (temperatuur, N1, N2 etc). De autopilot kan deze modules niet apart aansturen, dus overschakelen van modus zou niks hebben uitgehaald.

Ter illustratie, een gebruikelijke set-up bij een tweemotorig commercieel toestel is dat elke motor over een (onafhankelijke) FADEC beschikt. Elke FADEC heeft twee modules die zowel als backup als actieve referentie wordt gebruikt.

De FADEC is als elk ander basaal I/O systeem afhankelijk van zijn configuratie. En als je daarin essentiele zaken omdraait, gaat het mis.
Ik heb niks van de crash gezien, echter als ik het zo lees vraag ik me wel af als het een software probleem is, wie of wat bepaald dan wanneer er op een back up systeem moet worden overgeschakeld? Kan me voorstellen dat het met het hele human error verhaal niet zo 1 2 3 door de piloot om te schakelen is?
De exacte werking van de computers is nogal een ingewikkeld gedoe met alle statistiek erachter om te bewijzen dat het inderdaad een veiliger systeem is dan klassieke mechanische systemen. Het komt erop neer dat de computers elkaar controleren door te berekeningen apart uit te voeren en te controleren of ze hetzelfde uitkomen en door te controleren of de waardes realistisch zijn. Mocht de computer hier een fout ontdekken wordt er automatisch overgeschakeld op alternate law. De computer zal echter nooit automatisch overschakelen op direct law omdat in deze mode teveel beveiligingen wegvallen en bepaald besturingen enkel nog mogelijk zijn door de trim controls te gebruiken. Er is overigens wel een knop aanwezig waarmee de piloot een werkingsmode kan forceren.
Wat ik me dan afvraag, als de sensoren die de input voor de onafhankelijke systemen 'kapot' waren en verkeerde data afgeven, dan kan het dus prima zijn dat de systemen correct gehandeld hebben met de data voor handen, maar dat ze simpelweg verkeerde data te verwerken kregen en het probleem dus uiteindelijk bij de motoren (lees: data aanvoer) lag?

Of heeft ieder systeem een eigen sensor-reeks ter beschikking om zo over onafhankelijke data te beschikken om zo een gegronde keuze te kunnen maken over het controleren van andere systemen?

(ps, geen ervaringsdeskundige, maar hou wel van 'ingewikkeld gedoe' :) )
Ieder systeem heeft zijn eigen sensoren, er zijn 3 hoofdcomputers:
- die van de piloot
- die van de first officer
- die van de autopiloot

De vierde computer dient als backup, de 3 hoofdcomputers hebben hun eigen sensoren zo is er een pitot tube aan de kant van de piloot, een pitot tube aan de kant van de copiloot en nog eentje onder de cockpit voor de autopiloot. Indien er 1 defect is verschijnt er een waarschuwing en kan de piloot kiezen om 1 van de sensoren te gaan gebruiken voor 2 computers.
Naast die redundantie worden ook verschillende systemen met elkaar vergeleken zo wordt de input van de inertial navigation systemen en gps met elkaar vergeleken alsook de snelheid van de gps en pitot tubes etc.
Waarschijnlijk een technieker die opgeleid wordt om aan zo'n toestel onderhoud te doen.
Ikzelf heb zo jaren aan een C-130 gewerkt.
@Janssuh het antwoord is 'ja' op je vraag, wel is er wat redundancy ingebouwd.

De software is echter niet SLIM.

Dat is ook heel lastig om te bouwen. Bijna precies een jaar geleden heb ik onderhandeld om een robotauto op te zetten. Het gaat dan met name om de software. Een autofabrikant die wilde had ik in no time geinteresseerd,
de overheid wilde ook meedenken, maar je hebt een zak geld nodig om iets op te zetten.

Zo'n project hoort eigenlijk wel thuis in Nederland, want het barst hier van de experts in de AI die heel goed zijn in dit soort software. Echt heel goed.

Wel willen ze allemaal een enorme zak met geld (en terecht).

Je vindt gewoon geen investeerder voor goede AI software en al helemaal niet in Nederland.

Het lukt gewoon niet behalve als je zelf een enorme zak met geld erin steekt - en als je die enorme zak met geld bezit - dan heb je niks te zoeken in Nederland als verblijfplaats. As simple as that...
Ja joh, zei ik direct al toen het crashte.

Ontzettend veel crashes van nu hebben te maken met software die gewoon niet zo goed is als zij hoort te zijn.

Artificial intelligence is gewoon heel lastig om te bouwen en you get what you pay for.

Men bouwt hardware en verkoopt hardware. Software wordt gewoon gezien als een 'onkostenpost' die snel even gehackt wordt - snel intern gecertificeerd - en gaan met die banaan.

Daar is die hardware echter te complex voor ondertussen.
De A400M heeft vierdubbele redundantie in z'n fly by wire systeem, deze heeft 3 (of 4) werkingsmodi:
- Normal law: normale werking met alle toeters en bellen
- Alternate law: werking met minimale beveiliging tegen stalls, bank angles etc (beveiligings zijn gesplits in a & b)
- Direct law: joystick inputs worden rechtstreeks vertaald naar het hydraulisch systeem of elektrisch backup systeem

Het hydraulisch systeem bestaat uit 2 onafhankelijke, redundante systemen. En er is ook nog een elektrisch backup systeem.

Dit biedt voldoende veiligheid maar in het geval van een software probleem moet de piloot uiteraard het probleem kunnen vaststellen en switchen naar een andere mode, wellicht is dit hier niet gelukt.
Wat vind jij van deze uitspraak: "Door meer te automatiseren krijgt de eindgebruiker het idee dat het proces relatief eenvoudig van aard is, terwijl er onder de motorkap veel afhankelijkheden zijn. Dat maakt dat automatisering het probleem complexer maakt om te begrijpen".
En merken piloten daar in de praktijk iets van?
Piloten zijn in de laatste 25 jaar eerder computerbedieners geworden dan vliegeniers. Zo vliegen de meeste piloten nog zelden zelf. 95% van te tijd vliegen ze op autopiloot, zelfs al kan zelf vliegen vaak minder belastend zijn dan je computer programmeren. Zo zijn er veel piloten die tijdens het aanvliegen last minute veranderingen van de verkeersleiding nog snel proberen in hun computer te krijgen. Dit terwijl gewoon de autopiloot afzetten en het vliegtuig zelf in handen nemen veel gemakkelijker zou zijn. Momenteel zijn er allerhande programma's die piloten verplichten om vaker zelf te vliegen en ook heel wat simulator oefeningen.

Op gebied van hoe alles effectief werkt is er niet zo veel verandert, piloten hadden vroeger ook geen echte kennis over hoe hun toestel precies werkt. Mechanische en elektrische systemen zijn vaak even moeilijk dan software- en computer systemen. Ze moeten gewoon procedures volgen die op voorhand ingeoefend werden of in de handleiding staan. Indien er echt iets misloopt zijn er vandaag de dag wel meer diagnose mogelijkheden zo kunnen technici op de grond perfect alle parameters zien en de piloten helpen met problemen.
Het probleem is dat piloten vaak niet zelfstandig *mogen* vliegen en verplicht worden door hogerhand om op autopiloot te vliegen. Brussels Airlines is een van de weinige maatschappijen waar piloten wel nog zelf mogen vliegen.

Bij een gemiddelde vlucht is het opstijgen en de landing nog steeds de meest arbeidsintensieve taak en die worden voor zover ik weet wel altijd manueel gedaan.
De reden dat piloten vrijwel de gehele vlucht op auto piloot moeten uitvoeren heeft grotendeels met kostenbesparingen te maken en dan vooral op de brandstof. Denk alleen al hoeveel brandstof jij bespaart door op de cruise control te rijden. Bij het rijden op cruise control rijdt je ook niet per ongeluk te hard of te langzaam.

Cockpit automatisering kan inderdaad voor nieuwe problemen zorgen, maar het zorgt voor minder problemen dan de piloten zelf. Pilot error is nog steeds de voornaamste reden voor vliegtuig ongelukken. Daarin tegen is de vliegtuig industrie door de automatisering juist veel veiliger geworden. En bij elk incident worden onderzocht waardoor het kwam en hoe men dat in de toekomst bij andere vliegtuigen en/of maatschappijen kunnen voorkomen.

De landings is de meest intensieve fase van een vlucht. Men moet van alles regelen, communicatie volgen (ook welke niet voor hen is bedoeld (situational awareness) ), verschillende checklists en natuurlijk de configuratie van het toestel voor de landing. Juist door het gebruik van ILS wordt de workload van de piloot ontlast zodat deze meer oog kan hebben voor veiligheid.

Opstijgen gebeurt altijd manueel (hoewel ondersteund door automatisering) zodat men bij elke vorm van twijfel direct de start kan afbreken (mits men nog niet V1 heeft bereikt). De meeste piloten willen wel graag de landing doen omdat ze dan nog het gevoel behouden dat ze een vliegtuig besturen. Maat het verschilt per maatschappij welke procedures hiervoor zijn ingesteld.
Helamaal akkoord hoor.

Mijn punt was eigenlijk dat de uitspraak "piloten vliegen 95% op automatische piloot" een vertekend beeld geeft van het werk dat piloten moeten doen. Landen en opstijgen zijn (in normale omstandigheden) de meest intensieve taken en die moeten wel degelijk manueel gebeuren. Dus dat ze 95% op automatische piloot vliegen, vind ik een beetje een denigrerende uitspraak.
Daar is niks denigerends aan... Sterker nog, het is de visie van de gehele luchtvaart industrie dat de piloten 'managers of flight' zullen worden. Wellicht een enge gedachte maar men doet er alles aan om de piloot overbodig te maken. Tot op heden lukt dat aardig maar we zijn daar nog lang niet.

Toch denk ik dat het niet lang meer zal duren. Een belangrijke tussenstap zal zijn dat we vliegen met een eenkoppige bemanning, en dat op elk moment vanaf de grond de controle kan worden overgenomen. Als deze technologie doorontwikkeld, beproefd is en geaccepteerd wordt, dan pas zullen we overstappen naar een volledig (automatisch >< autonoom) vliegtuig. Daarom dat de grote fabrikanten zo inspringen op de drone technologie. Dat is echt niet enkel voor militaire doeleinden interessant.

Terug naar het topic;
Als ik het bronartikel lees heeft de crash weinig tot niks te maken met menselijk falen. Op aerodynamisch vlak zijn we vrijwel uit-geinnoveerd. We zijn bezig met de huidige technieken te optimaliseren. Op het moment kunnen wij enkel nog verder met behulp van computergestuurde systemen. Zo ook de motor aansturing. Het is zelfs niet eens meer mogelijk handmatig controle over te nemen over de motor aansturing Dat zijn echt de computers. Of de piloot nou op het handje vliegt of niet. Het enige verschil dat de piloot nog kan maken is de autothrottle aan/uit kan schakelen. Maar zo te horen zou dat in het geval van deze A400M geen verschil hebben uitgemaakt.
het is de visie van de gehele luchtvaart industrie dat de piloten 'managers of flight' zullen worden
Onzin. Dat is slechts de visie van Airbus, en enige maatschappijen.
De visie van Boeing, en veel andere maatschappijen is juist tegengesteld, en steld de piloot altijd in het centrum.

Er is absoluut geen consensus hierover, sterker er beginnen steeds meer geluiden tegen té verre automatisering te komen, omdat het lastiger wordt voor piloten om in te grijpen wanneer dat nodig is. Denk daarbij o.a. aan technische problemen, zoals bij die Turkisch Airlines crash bij Schiphol, waarbij de autothrottle op de verkeerde momenten gas terug nam, en de piloten het niet in de gaten hadden, omdat ze teveel aan het managen waren, en te weinig aan het vliegen.
Zoals jij het zegt is het en een kennis-probleem van de piloot, en een software fout?
Een crash heeft nooit 1 oorzaak, uiteraard had de piloot kunnen overschakelen op direct law maar waarschijnlijk is het gewoon niet realistisch om dit te verwachten van een mens. Hij had enkele seconden om een onbekend probleem te troubleshooten, iets dat zowel mechanisch, elektrisch, software, configuratie of omgevingsgerelateerd zou kunnen zijn.
Hele foute manier van denken. Het vliegtuig moet zo ontworpen worden, en de piloot zo opgeleid zijn, dat er binnen zeer korte tijd de juiste beslissing genomen kan worden.

Daarnaast hebben we het hier over een vliegtuig dat dient om mensen te vervoeren, en niet over een gevechstvliegtuig waarbij je liever hebt dat ie onstabiel is zodat de performance beter is. Je moet gewoon eisen dat de piloot kan vliegen met redudant uitgevoerde mechanische instrumenten.

Verder zou iemand eens moeten uitzoeken dat, als het fout gaat, in hoeveel gevallen is het dan niet beter om alles uit te schakelen en zelf te vliegen zonder software.

Overigens: 'There are no structural defects, but we have a serious quality problem in the final assembly' en 'The error was not in the code itself, but in configuration settings programmed into the electronic control unit (ECU) of the engines'. Bron: http://arstechnica.com/in...error-caused-plane-crash/
Die mening is vrij zwart-wit waar deze situatie nu juist toont dat het niet zo is.

Vergeet ook niet dat een vliegtuig ten alle tijden door de piloot overgenomen moet kunnen worden. Dat heeft dan weer met aansprakelijkheid te maken (en dus opgenomen in de FAA regelgeving).

Ik deel zeker de mening dat een piloot met de redundant systemen, of wat makkelijker gesteld, direct law moet kunnen vliegen. Persoonlijk acht ik dat een piloot een certificering per vliegtuig zou moeten halen op dat specifieke punt, maar in tegenstelling tot MCvarial heb ik wat minder lang bij L&R gezeten. Dus kijk hem even aan voor de details ;) (@MCvarial, welke richting heb je gedaan?)

Als aanvullende verbetering zou het protocol om te bepalen óf je nog wel in een bepaalde mode mag vliegen bij problemen misschien ook onder de loep genomen kunnen worden, al twijfel ik of het hier had uitgemaakt.
Bij de Belgische defensie verlies je kwalificaties als je niet genoeg uren op een berpaalde modi gewerkt hebt. Dus tis niet van 1 maal gehaald en dan ok voor de rest van je leven.
Nergens wordt ook de hoogte vermeld van het optreden van de software glitch, wat me wel belangrijk lijkt om te kunnen ingrijpen.
Je moet maar eens uitrekenen wat er gebeurd als 1 van die motoren negatieve torque begint te leveren. Het toestel gaat niet meer in as vliegen gevolg nog meer lift voor de nog werkende motor en minder voor de slecht werkend motor een rolbeweging wordt ingezet en dat is zeer slecht voor vrachtvliegtuig, want het is er niet voor ontworpen.
Sorry, bij teruglezen zag ik dat ik inderdaad niet geheel duidelijk was in dat punt.

Nee, ik weet dat je genoeg uren moet blijven maken voor het aanhouden van je kwalificaties. Ik zat meer richting een specifiek toestel kwalificering te denken, ook voor burgerluchtvaart. Ondanks dat dit een testpiloot was en deze echt zal hebben beschikt over uitzonderlijke kwaliteiten, kan iemand niet alle systemen van elk toestel kennen. Zoals je zelf ook aangeeft kan software uitzonderlijke problemen leveren (en nee, ik ga het niet uitrekenen. Die studie was me veel te droog. LR faler zonder schaamte!) en daarmee zouden we juist de dagelijkse piloot meer moeten beschermen.

Je kan niet verwachten dat een piloot die zijn dagelijkse routine in zijn werk doet dit kan opvangen. Ja er zijn prachtige verhalen van uitzonderingen, maar eerlijk gesteld zijn er ook genoeg piloten waar ik blij bij ben als ik de eerste stap buiten het toestel zet (en serieus mensen, als je in de auto zit met 260 km/h, @737, klappen jullie ook niet, dus houdt er mee op! Enige piloot die ik ooit bedankt heb was een Turkse piloot waar het halve personeel de zweetpegels nog van had staan bij uitstappen... Iets met zijwind en het feit dat ik echt te recht naar het einde landingsbaan kon kijken uit zijraam voordat hij hem bijna 30 graden bijdraaide na contact achterwielen. Nee, amper geklap want het was wel ruw... Verdraaid, letterlijk, landen op niveau ++)

Software blijft software, dus ik ben zeker voor meer fysiek vliegen en verplichte direct law kwalificeringen per toestel voordat je passagiers mee mag nemen. Niet omdat er slechte piloten kunnen zijn, maar omdat problemen steeds complexer en moeilijke te herkennen gaan zijn.
De Airbus A400M is een militair vrachttoestel, dus bestuurd door militaire piloten. Zeker in conflict gebieden zijn deze mensen gewend om snel te kunnen handelen. Maar in dit geval was het een testvlucht, en testvluchten zijn er niet voor niets.
Je hebt blijkbaar begrepen wat hij je probeerde te vertellen, mooi zo dat is nou de bedoeling van taal. Ik denk trouwens dat je eerste zin ook wat verbetering kan gebruiken.
Nederlands is niet m'n moedertaal maar volgens mij is vierdubbel gewoon standaardtaal :)

Ken de precieze omstandigheden van de crash niet maar als ik het me goed herinner deed het probleem zich voor om een hoogte van 100m en had de piloot slecht luttele seconden om een zeer ingewikkeld systeem te troubleshooten. Overigens kon het probleem net even goed mechanisch, hydraulisch elektrisch, iets met de configuratie van het vliegtuig of zelfs iets van buitenaf zijn.
http://www.vrt.be/taal/driedubbel

In dit geval was het ingewikkelde systeem een vloek, in veel meer gevallen is het een zege. Vliegtuigongelukken door softwarefouten zijn zeldzaam, ongelukken door bijvoorbeeld stalls komen vaak voor.
Je link naar VRT netjes
offtopic:
Nederlands advies
Nieuw is het niet dat driedubbel 'driemaal' of 'drievoudig' betekent. Al in de eerste editie van Van Dale, uit 1864, staat driedubbel omschreven als "drievoudig", en bijvoorbeeld tiendubbel als "tien maal zoo veel".
Dit soort redundantie beschermt je enkel tegen hardware issues.

Als je tweede flight computer dezelfde software en configuratie bevat als de eerste, hoe gaat het overschakelen naar het backupsysteem dan je probleem oplossen? Nou, dat gebeurt dus niet.

[Reactie gewijzigd door Peetz0r op 2 juni 2015 12:28]

Kritisch, en misschien bij het rechte eind.

Hetzelfde vraag ik me vaak af bij (vracht)wagens met automatisch remsysteem en veel andere realtime systemen. In wezen is een (vracht)auto 2D: voor- en achteruit, links en rechts. Een vliegtuig is 3D, en zoveel complexer. Meteen neemt die niet-lineariteit een pak toe. Dat wordt niet "opgelost", maar benaderd door de onboard-computers.

Wat P.E.T.E.R. hierboven opmerkt, is beknopt maar wellicht niet zo gek. Immers, in de operationele 'realtime forecasting' wereld zie je vaak ontdubbelde, of quad, systemen die precies hetzelfde doen. Als die twee systemen net hetzelfde doen EN dezelfde fout maken, dan ben je idd de klos, TENZIJ de hardware op een van de systemnodes het laat afweten.

Bedenking: Vliegtuigen gaan steeds meer op het randje vliegen (lift vs weight), waardoor de fouttolerantie steeds krapper wordt. Niet alleen bij het vliegen, maar bij waarschijnlijk veel zaken, denk maar tunnels, bruggen, skyscrapers, ...
Je moet verder ook weten dat de fout in software op een vrij laag niveau zat. Het ging in dit geval niet om de besturing van het vliegtuig maar om de ECU. Dat is een soort firmware in de motor.

De boardcomputers en al hun backupsystemen kunnen prima hebben gewerkt, als op heel laag niveau de motor zelf de signalen verkeert interpreteert of een oververhittingsbeveiling veel te vroeg aanslaat gaat het nog steeds mis.

Vergelijk het met een fout in de firmware van je harde schijf. Je kunt nog zo'n geavanceerd OS draaien dat extreem weinig fouten bevat. Een bug in de firmware kan alsnog voor problemen zorgen.

In dit geval lijkt het te gaan om een configuratiefout bij het laden van die firmware. Er wordt gespeculeerd dat klanten zelf de motoren mogen configureren en dat daar mogelijk iets mis is gegaan (niet door de klant maar wel in dat systeem). Aangezien het een militair vliegtuig is bestaat de kans dat de exacte details nooit bekend gemaakt worden buiten militaire kringen.

[Reactie gewijzigd door Maurits van Baerle op 2 juni 2015 08:31]

Zo eenvoudig is het allemaal niet.
Even terug naar een back-up computer of even dit en dat en zus en zo.

Het is iets meer als een back-up van je tablet !!
Begrijp alle ideeën wel en dat we denken dat het anders kan en beter, maar echt stom zijn ze ook niet bij Airbus.

Zoals bijna bij alle vliegtuig ongelukken is het een op een stapeling van gebeurtenissen (wet van Murphy)
Nou ik weet vrij goed hoe computer systemen werken maar ook vliegtuigen. Zo moeilijk is het niet om een 2de systeem ernaast te leggen. Doekoes zal het wel om gaan.

In air crash investigation heb ik wel eens gezien dat sommige vliegtuigen een kale backup/boot hebben die in geval van nood alle basis functies aansturen. Maar welk merk en type, dat zijn die vage Zondag ochtend/middagen he?
;)
Je kan niet zomaar terug vallen op een back-up systeem als je niet weet wat er op dat moment speelt. Gaat het back-up systeem je wel helpen ?
Wordt het niet erger ? etc. etc.

Voor ons nu lijkt het eenvoudig, want wij weten nu op achteraf basis hoe het is verlopen. (helaas niet goed)

Elke beslissing kan een goede of zelf een slechtere zijn.
Ik laat het maar aan Airbus over eerlijk gezegd. :)

[Reactie gewijzigd door 634684 op 1 juni 2015 21:31]

Helemaal mee eens.

In dit geval moest men ook in zéér korte tijd beslissingen maken. Die Airbus is ontzettend complex en het is onmogelijk om in een splitsecond te beslissen dat een "reset" nodig is.
En het backup systeem kan uiteraard in dezelfde fout verslikken.
Je moet ook niet vergeten dat het om een test gaat bij een test, mogen, hoe cru dat ook klinkt, dingen misgaan. Stel dat ze juist een backup systeem aan het testen waren, dan weten ze nu dat hij niet werkt.

Alles gaat in de luchtvaart trouwens om geld. Een vliegtuig kost behoorlijk veel, de brandstof, het onderhoud, het personeel, belastingen ook. Het grote besparen zit hem in de brandstof en dat wordt gedaan door de massa van het vliegtuig te verminderen, de motoren efficiënter te maken en het toestel aërodynamischer te maken. Fly by wire is daarom ook interessant, een modern gevechtsvliegtuig is instabiel maar daardoor ook heel wendbaar. Zonder fly by wire valt een JSF direct uit de lucht. Verkeersvliegtuigen zijn vaak wel stabiel gebouwd, fly by wire is dan om andere redenen interessant, zoals gewichtsbesparing, uitgebreide functies voor een automatisch piloot, lichtere besturing. Als je alles in 2-voud wilt uitvoeren gaat dat dus extra kosten, 2 kabelbomen, 2 APU's, 2 cockpits, 2 piloten, 6 landingsgestellen, 2 rompen. Sommige dingen zijn dubbel uitgevoerd: piloot, motoren andere dingen, zoals de APU en de romp, niet. Een softwarefout kan ook 2, 3 of x keer in een toestel zitten. Wordt die constante 1 keer ingevoerd en dan door verschillende software uitgelezen? Of juist meerdere keren los van elkaar ingevoerd? In het tweede geval kan het natuurlijk zo zijn dat er ook in de backup systemen de verkeerde constante is ingevuld. Hoe dan ook, er zijn zat opties om een fout te maken die ook door je backups niet wordt opgevangen.
In air crash investigation is een Tv programma ik noem dat zelfs geen documentaire.

Net zoals ik bij het ongeluk op Eindhoven van onze C-130 talloze vliegtuig experten op TV in Belgie en Nederland het Fuel Tank systeem zagen uitleggen wat in geen enkel vliegtuig zou zitten.
Weet je ik heb jaren op C-130 gewerkt als FTR (Fuel Tank Repair ) specialist en na 10 jaar een switch gemaakt naar de communicatie dienst bij defensie en alzo de TV wereld leren kennen.
Ook de burger TV wereld en documentaires? reality? nou nou het ontspant goed maar waarheids getrouw moet je het zeker niet altijd noemen.
Vergeet niet dat die vliegtuigen in de lucht worden gehouden door de boardcomputer. Met enkel basisfuncties ben je er dan nog niet, de complete jet moet bestuurd worden.

Daarnaast moet je wel eerst doorhebben dat de aansturing niet goed werkt. Een brandende motor zie je wel, maar een verkeerd signaal naar de motor heb je niet meteen door lijkt mij.
Het is meer denk ik dan beta testing. Die software wordt toch wel getest aan een soort dummy systeem hoop ik ? Dat gaat toch echt niet in een keer live ? Redundance is natuurlijk leuk, maar als het verkeerd wordt aangestuurd dan helpt het niet veel :) Ene piloten denken toch zelf ook nog wel een beetje na, al is het uiteraard lastig te zien of een motor verkeerd wordt aangestuurd, maar je moet toch wel wat merken en gaan denken ?!
Ja, maar zelfs als je alles redundant hebt, dan kun je het nog steeds verkeerd aansturen, 2x fout is nog steeds fout.. hij was verkeerd ingesteld dus blijkbaar..
Mss is dat er wel, maar je moet als piloot wel eerst weten dat je vliegtuig niet goed vliegt omdat er iets mis is met de software (en niet een mechanisch probleem) zodat je kan beslissen om de backup te gebruiken.
Het is inderdaad zo dat je met 3 meer in het oog kan houden dan met 2 maar indeze vlucht zaten in de cargo nog mensen op schermpjes te kijken als ik het goed heb.
Hoe kan er niets met de software aan de hand zijn als het toestaat dat er tegenstrijdige opdrachten aan drie van de vier motoren wordt gestuurd?

Als er een configuratiefout is, zou aangegeven moeten worden dat er iets niet goed is ingesteld. Nu lijkt het alsof dit ook in het vervolg (met opzet) gedaan kan worden. En daar zit geen enkele afnemer op te wachten lijkt me.

[Reactie gewijzigd door kaphot op 1 juni 2015 21:07]

Als het vliegtuig weet dat er iets niet goed is ingesteld door de configuratie. Is de configuratie dus ook niet nodig en kan dat ook geautomatiseerd worden. :P LOL
De opdrachten naar de motoren was vermoedelijk correct. Maar die motoren hebben een FADEC computer met eigen software die de opdrachten ontvangt en toepast. 3 van de 4 motoren begrepen de opdracht verkeerd.

Als je bij de motoren kunt, dan is software-sabotage niet de meest voor de hand liggende mogelijkheid.
Ze spreken over eindmontage, wat het inhoudt weet ik niet en wie daar verantwoordelijk voor is, zal wel onderhoudspersoneel zijn niet de piloten?
Vermoedelijk zijn er sensoren of actuatoren op de verkeerde positie geconfigureerd. Dus als voorbeeld, de computer wil als correctie de rechter buitenste motor 10% minder vermogen geven , en de linker 10% meer. Maar het resultaat is dan net omgekeerd. Het signaal voor de rechter motor komt aan bij de linker motor en visa versa.
Zo'n simpele fout zal het niet zijn maar wel iets soortgelijks.
Ik ben geen deskundige. Maar ik kan mij voorstellen dat als er bijvoorbeeld een gierhoeksensor in de linker en één in de rechter zit. Waarvan de readings omgewisseld worden. Hele bizarre beslissing zullen geven.

[Reactie gewijzigd door engibenchi op 2 juni 2015 08:32]

Het toestel, dat over propellers in plaats van straalmotoren beschikt
Om nauwkeuriger te zijn: het toestel beschikt wel degelijk over straalmotoren, echter in plaats van 2 turbines achter de verbrandingskamer is er nog een 3e die de propeller aandrijft. Dit geheel wordt ook wel turboprop genoemd. Hierbij wordt de voortstuwing voor 90-95% door de propeller veroorzaakt en de rest door de uitstromende lucht achter de motor, in tegenstelling tot normale straalmotoren die de gehele voortstuwing zelf tot hun rekening nemen.
Inderdaad en de spoed op de rotor bladen zorgt voor de kracht....De hoofdreden waarom men bij militare vrachtvliegtuigen zoals dit toestel en de C-130 voor schroeven kiest is dat hierdoor er snel veel voortstuwing is en men dus op veel kortere landingsbanen kan opstijgen en landen (reverse ).
Jammer dat het tekst niet heeft vermeld... door wie werd het software geconfigureerd?
Door Turkse leger of Airbus?
Normaal levert Airbus een standaard software, omdat het toestel een militaire vliegtuig is, is het heel mogelijk dat het Turkse leger het software misschien iets aangepast heeft. Omdat ik niet geloof dat Airbus een toegang tot militaire configuratie instellingen heeft.
Daar krijg je al voor het opstijgen al een melding van
en alles wordt dubbel gechecked pilot / co
Hmm, een welles - nietes verhaal. Over een paar dagen vast het bericht dat het toch niet aan de software lag. (alweer).
Dit gaat niet over instellingen, vrees ik, maar eerder over assimilatie van gegevens en het adequaat reageren van de computers.
Weercomputers werken gelijkaardig, met het verschil dat vliegtuigen dit realtime doen (zoals fabrieksrobots), terwijl weerrobots enkele minuten tot uren tijd hebben. Ergens moet op basis van een statistische verdeling/kans/... een keuze (beslissing) gemaakt worden door de computer en dan wordt die keuze (beslissing) gevolgd door het toestel.

Als de operator/piloot/... dit niet opmerkt, dan kan het fout lopen
Sorry hoor Tweakers. Nu weet je eigenlijk nog niks.

"De verkeerd geconfigureerde software zou de motoren van het toestel hebben moeten aansturen. Eerder meldde Der Spiegel al dat door een softwareprobleem tegenstrijdige opdrachten aan drie van de vier motoren werden verstuurd. Of dat klopt, is niet duidelijk."

Wie of wat had die software dan wel goed moeten "configureren"?
Om je eventjes met je neus op de feiten te drukken en aan te geven dat dit een onjuiste stelling is:

http://www.hartvannederla.../5-feiten-de-airbus-a320/
Je vliegt daarom ook nooit meer Boeing omdat er een keer een in Amsterdam op een flat is beland?

Dan blijft er niet heel veel over, vrees ik. Dat wordt treinen.
Zoals de Fyra nou bedankt heeft ons veel gekost.

Piloten en mekanikers betrokken bij de A400M hebben heus wel bedenkingen bij het vliegtuig.
Het is trouwens ook een militair vliegtuig en daar wil de piloot iets meer nog het zelf in de hand houden, of het op zijn minst kunnen.

[Reactie gewijzigd door Forssux op 2 juni 2015 09:28]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True