Airbus A330 crashte bijna door softwarefout

Reacties

« 1 2 3 4 5 »

Door luuklsl, dinsdag 20 december 2011 17:23

Beter laat dan nooit een oplossing voor zoiets.

Door Nas T, dinsdag 20 december 2011 18:51

waardoor de onderzoekers er vrij zeker van zijn dat soortgelijke incidenten niet meer zullen voorkomen.

Het is dus niet met (nagenoeg) 100% zekerheid vast te stellen dat het probleem is opgelost.
Ik ben benieuwd hoeveel mensen weer gaan roepen:
"Dit zou niet moeten kunnen". Waar mensen zijn, worden nu eenmaal fouten gemaakt. Er zitten zeker weten nog meer fouten in het ontwerp van de airbus, al zullen deze nooit worden ontdekt of geen tot weinig problemen opleveren.

Door Red_inc, dinsdag 20 december 2011 19:06

dit is gewoon slodig geprogrameerd.
iedereen weet gewoon als je met sensors omgaat dat ze wel eens foute informatie kunnen versturen. dit moet je dan in de software opvangen. zeker in dit soort situaties!

Ook had de auto piloot niet het vliegtuig een duikvlucht mogen laten maken. deze had door de soft ware gewaarschuud moeten worden en deze had de piloten moeten waarschuuwen ik weet het niet maar volgens mij klopt er iets niet met de sensors
snelheid verandering van sensors moet binnen natuurlijk redelijke limiten blijven
doet deze dat niet als het vliegtuig in de lucht is dan moet je gewoon uit gaan van sensor failure en gewoon crew waarschuwen dat de auto piloot iets erg afwijkens will doen

Door mrdemc, dinsdag 20 december 2011 19:24

Als jij het zo goed kan, waarom werk je dan niet bij Airbus als progammeur? Volgens mij krijg je daar een redelijk riant salaris hoor

Ik verwijs je daarbij trouwens ook graag door naar deze reactie:
Garyu in 'nieuws: Airbus A330 crashte bijna door softwarefout'

[Reactie gewijzigd door mrdemc op dinsdag 20 december 2011 19:26]

Door W3ird_N3rd, dinsdag 20 december 2011 22:11

Als jij het zo goed kan, waarom werk je dan niet bij Airbus als progammeur? Volgens mij krijg je daar een redelijk riant salaris hoor
Ik verwijs je daarbij trouwens ook graag door naar deze reactie:
Garyu in 'nieuws: Airbus A330 crashte bijna door softwarefout'

Toch zijn er dan dus plekken in de software waar men hier niet goed naar heeft gekeken. Denk even terug aan Turkish Airlines Flight 1951 op Schiphol: de hoogtemeter gaf aan dat ze op -8 voet zaten. Dat kan dus niet. Terwijl al die tijd alle andere hoogtemeters andere (correcte) waardes gaven. Op dat moment had de software toch ècht in moeten zien dat die -8 niet kàn kloppen. En volgens het protocol zou hier dus ook rekening mee gehouden moeten worden, maar dat is bij die 737 dus blijkbaar toch niet gedaan.

Op dat specifieke punt is dat dan toch wel degelijk slordig. Er zal best een hoop aandacht zijn besteed, maar zulke dingen mogen eigenlijk niet voorkomen. Ik vraag me op zulke momenten ook wel eens af hoe zulke fouten erin kunnen sluipen en waarom dat bij testen niet naar voren is gekomen.

[Reactie gewijzigd door W3ird_N3rd op dinsdag 20 december 2011 22:13]

Door Stoney3K, dinsdag 20 december 2011 23:39

[...]

Toch zijn er dan dus plekken in de software waar men hier niet goed naar heeft gekeken. Denk even terug aan Turkish Airlines Flight 1951 op Schiphol: de hoogtemeter gaf aan dat ze op -8 voet zaten. Dat kan dus niet. Terwijl al die tijd alle andere hoogtemeters andere (correcte) waardes gaven.

Nuancering: Bij Turkish 1951 was het de radiohoogtemeter die aangaf dat het vliegtuig zich op -8 voet (8 voet onder zeeniveau) bevond. De andere hoogtemeters, vanuit de barometrische meting (de Air Data Computers) gaven wel de voor de weersomstandigheden correcte waarden aan.

Voor een aanvliegprocedure op de automatische piloot (in dit geval, een LAND3, categorie III ILS approach) mag er echter volgens de procedures niet vertrouwd worden op de barometrische metingen alleen. Dan is de radio-hoogtemeter vereist.

Voordat je argumenteert dat '-8' een ongeldige waarde is: De landingsbanen van Schiphol liggen op 20 meter, ofwel 60 voet, onder zeeniveau. -8 voet MSL is voor een normale hoogtemeter dus een prima aanduiding, voor Schiphol betekent het zelfs dat je nog in de lucht bent en nog ongeveer 17 meter te gaan hebt voordat je vaste grond tegenkomt!

Voor een radiohoogtemeter is -8 mogelijk niet een geldige waarde, maar dat ligt er maar net aan of die radiohoogtemeter op dat moment AGL (Above Ground Level) of MSL (Mean Sea Level) aanduidt. -8 voet boven grond is natuurlijk onzin, terwijl -8 voet MSL (wat logisch is als de radio-hoogtemeter gelijk geijkt is met de ADC's) een prima waarde kan zijn.

Turkish 1951 was ook zeker een geval van human error. De piloten kregen tegenstrijdige informatie en de automatische piloot werd op een gegeven moment wél uitgeschakeld omdat er conflicterende meetwaarden waren vanuit de ADC's, ILS- en radiohoogtemeter-ontvangers. Het probleem was alleen dat de automatische gashendelregeling in die situatie níet uitschakelde, dat zijn in een Boeing namelijk 2 gescheiden systemen.

Later, the safety board's preliminary report modified this analysis, indicating that the flight data recorder history of the captain's radio altimeter showed 8191 feet (the maximum possible recorded) until the aircraft descended through 1950, then suddenly showed negative 8 feet.

Dat klinkt vanuit een programmeurs-oogpunt zelfs als een klassiek gevalletje integer overflow. 8191 voet is namelijk de maximale waarde voor een 12-bits integer, en één voet meer zou betekenen dat je een bitje extra nodig hebt, die in gebruik is door de Sign-Status Matrix (SSM) in het ARINC 429 protocol. Dan zou de waarde verspringen naar 'No Computed Data', iets wat de instrumenten van een 737 voor een radio-hoogtemeter niet kunnen weergeven.

Door no-sense, woensdag 21 december 2011 10:18

Prima verhaal, hier nog een paar correcties:

- een radio of radar hoogtemeter geeft per definitie de hoogte AGL aan. Een waarde van -8 is dus altijd een ongeldige waarde. Wikipedia entry

- Het laagste punt in Nederland is ongeveer 6 meter (+/- 20ft) onder NAP en dat is de Willem-Alexander Polder bij Rotterdam. Volgens Wikipedia ligt Schiphol 3 meter/ 11 ft. onder zeeniveau. Toegegeven, nog steeds lager dan -8

Wat ook nog denk ik vermeld dient te worden zeker in dit artikel was dat dankzij die ene foute waarde de 737 op (relatief) grote hoogte in "flare" mode ging (voor de leken, vlak voor de landing zie je altijd de neus van het vliegtuig omhoog gaan en de gashendels gaan dicht. Dat is flare mode") Dus het is niet alleen Airbus die last heeft van gevaarlijke acties aan de hand van 1 foute sensor.

Door wmnl, woensdag 21 december 2011 10:37

- Het laagste punt in Nederland is ongeveer 6 meter (+/- 20ft) onder NAP en dat is de Willem-Alexander Polder bij Rotterdam. Volgens Wikipedia ligt Schiphol 3 meter/ 11 ft. onder zeeniveau.

Nope, volgens Wikipedia was dat die polder maar is het nu in de Zuidplaspolder. Komt kennelijk door bouwwerkzaamheden in de Willem-Alexander Polder

Door pietervanderlub, woensdag 21 december 2011 12:16

In werkelijkheid ligt het verhaal nog iets anders (wat is ieders bron?).

De radio-hoogtemeter werkt simpelweg met radiogolven en bekijkt dus de absolute hoogte tussen het vliegtuig en het onderliggende terrein. Mede hierdoor werkt het dus ook alleen op relatief lage hoogte (<2500 ft Boeing 737-800).

De waarde -8 ft wordt alleen op de grond weergegeven, wanneer het toestel met het volledige gestel op de grond staat. Wanneer het dan wel nul is? Op het moment dat het vliegtuig in de flare (een maneuvre waarbij de verticale snelheid wordt omgezet in horizontale snelheid door de neus op te trekken) met het hoofd landingsgestel de baan raakt (en het neuswiel dus nog ver boven de baan hangt). Je bent immers geinteresseerd in de resterende hoogte TOT de landing (door het hoofdlandingsgestel).

Je snapt nu ook dat deze hoogte dus kan verschillen per type vliegtuig (afgaande op de "normale" touch-down stand) en niks te maken heeft met de hoogte van het veld (iets waar de baro-hoogtemeter wel mee heeft te maken).

Door Texamicz, woensdag 21 december 2011 08:10

Dit is geen simpel een taaltje kennen en programmeren. Het gaat om complexe wiskundige algoritmes...

Zoals Sensor fusie algoritmes en Kalman filters en zorgen dat alles ten alle tijde goed werkt. Ook door fout berekening als je meerdere sensoren hebt waardoor hier dus 1 faalt.

Door smonjirez, woensdag 21 december 2011 13:13

Wauw, ik had oprecht niet verwacht op Tweakers.net reacties / drogredeneringen in de trend van "Als jij het zo goed kan, waarom doe je het dan niet zelf?" aan te treffen.

Door Denni, dinsdag 20 december 2011 19:32

Typisch geval van "de beste stuurlui staan aan wal" deze reactie. Het zijn nog steeds mensen en geloof me de software in een airbus is zeer ingewikkeld. Als je zien hoe makkelijk het is om met bepaalde simpele zoek algoritmen(binary search doet minder dan 15% van de professionele programmeurs en twee uur helemaal goed) iets fout te doen kan ik me goed voorstellen dat hier een foutje in is geslopen. Achteraf gaan roepen van dit is heel slordig geprogrammeerd etc. is totale onzin. Mensen die dat zeggen hebben meestal wat C(oid) kennis en menen dat zei geen enkele fout maken in hun software. Geloof me Red_inc, in jou software zitten ook tientallen zonet honderden of duizenden fouten.

Ik ben blij dat ze het hebben opgelost en hopelijk komt zoiets niet nog een keer voor. Sowieso is het aantal crashes door softwareproblemen nog steeds veel en veel lager dan het aantal menselijke fouten die lijden tot een crash...

Door Uniciteit, dinsdag 20 december 2011 19:50

Het is inderdaad mooi om te horen dat het is opgelost. Echter mag naar mijn mening de software nooit zomaar de besturing overnemen. Herinnert me aan het incident met de Airbus waarbij de piloot wou stijgen, maar dat de software dit voorkwam vanwege een stall warning en toen dus in de bossen naast het vliegveld terechtkwam.

Het enige wat de Airbus, naar mijn mening, op 'eigen houtje' mag doen is als er een waarschuwing is dat er te laag wordt gevlogen en dus automatisch omhoog gaat (je kan er vrij zeker van uitgaan dat het gebied boven het vliegtuig alleen maar uit lucht (en wellicht wat vogels) bestaat).

Piloten zijn natuurlijk ook gevoelig voor fouten, maar zolang de software nog zo nieuw is vind ik niet dat de software mag ingrijpen op eigen houtje.

Edit Air Crash Investigation aflevering waarbij Airbus software ook ingreep wat leidde tot een crash.

http://www.youtube.com/watch?v=ImVjkf9pjQI

[Reactie gewijzigd door Uniciteit op dinsdag 20 december 2011 19:52]

Door mgroen81, dinsdag 20 december 2011 21:35

De software is meestal degene die de kist bestuurd. De piloot hoeft bijna niets meer te doen. Ook landen en opstijgen.
Dus het is logisch dat zon lucht schip op zijn eigen houtje ingrijpt.

Door YopY, dinsdag 20 december 2011 22:21

Het enige wat de Airbus, naar mijn mening, op 'eigen houtje' mag doen is als er een waarschuwing is dat er te laag wordt gevlogen en dus automatisch omhoog gaat (je kan er vrij zeker van uitgaan dat het gebied boven het vliegtuig alleen maar uit lucht (en wellicht wat vogels) bestaat).

En dat is nu juist iets waar een bug in kan ontstaan: als de hoogtemeter stuk is of niet goed gecalibreerd, denkt de computer 'ZOMG je vliegt te laag, kom, laat ik eens omhoog gaan'... en als de piloot dat niet merkt of te laat ingrijpt kan het vliegtuig in de problemen komen.

Door gp500, dinsdag 20 december 2011 23:38

Maar als het in het artikel correct staat.

Is er in het programeren en daarna testen.
Een fout door gelopen, die echt opgevangen had moeten worden.

1 van 3 indicatoren was fout.
Dan moet de software in 1e instantie die andere 2 indicatoren geloven.

En dus een positieve werking doorgeven.
En een alarm aan de piloot co-piloot en boordwerktuigkundige geven, dat er een foute meting is.

En deze situatie had ook in een software test moeten worden gegeven.

Het was dus een IF any > dalen .

Door feuniks, woensdag 21 december 2011 11:40

En daar zit hem nu het punt. TESTEN. Je kunt nooit 100% testen. En statistisch zit er ik geloof elke 1000 regels (geteste) code nog een behoorlijke fout in.

In dit specifieke geval hebben we maar weinig informatie om na te gaan of er goed of slecht getest is. Wellicht zijn er meer variabelen die een rol spelen. Misschien speelt het alleen boven een bepaalde hoogte en alleen als het een specifieke sensot is en als de andere twee sensoren een verschil van meer dan 5000 voet aangeven met de foute etc. etc. etc.
Dit soort software kan zo complex zijn, dat je nooit alle mogelijke permutaties kunt testen. Daar komt bij dat je vaak alleen dingen kunt testen waarmee je weet dat iets mis kan gaan. Een goed voorbeeld daarvan is de Commet. Dat was het eerste commerciele straalvliegtuig en bleek uiteindelijk last te hebben van de constructie van de ramen. Niemand wist dat dat type ramen op den duur voor metaalmoeheid zou leiden en pas na vele uren vliegen begon het zich te manifesteren.

Ik ben er zeker van dat in ieder vliegtuig en iedere auto, die er nu van de band rolt minstens één serieus probleem zit, wat alleen in uitzonderlijke situaties optreedt en daarom mischien nooit ontdekt wordt.

Door Garyu, woensdag 21 december 2011 14:23

En toch moet je 100% tests bewijzen. En als je dat niet kan, gaat je software dat vliegtuig niet in. En daarom is het ook zo ingewikkeld om code voor een vliegtuig te schrijven, je bent enorm gelimiteerd in wat je kan gebruiken, omdat het allemaal (o.a.) testable moet zijn.

Door smartsys, woensdag 21 december 2011 12:02

In dat specifieke geval, was het niet de software, maar de piloot die een enorme blunder had begaan.
Hij wilde een extreme low altitude fly by doen en was in zijn planning er vanuit gegaan dat dit boven een asvalt baan zou plaatsvinden.
Het plan werd echter tijdens de vlucht aangepast waardoor hij over een veel kortere grasbaan moest vliegen. Hij had daarop zijn plan moeten aanpassen om geen risico te lopen, maar hij besloot door te zetten en zag plotseling dat hij te laag zat en dat zijn ruimte aanzienlijk beperkt werd door een bos.
Doordat hij op zicht vloog en niet zijn hoogte meter in de gaten hield kwam hij onder een bepaalde hoogte en "dacht" het toestel dat hij ging landen. Het toestel nam daarop gas terug en verloor nog meer hoogte en belande in de bomen aan het eind van de veel kortere baan.
In dit geval was het de piloot die onnodig risico's heeft genomen en de software in het toestel die de uiteindelijke crash tot gevolg had.

Door Stoney3K, woensdag 21 december 2011 12:53

Het is inderdaad mooi om te horen dat het is opgelost. Echter mag naar mijn mening de software nooit zomaar de besturing overnemen. Herinnert me aan het incident met de Airbus waarbij de piloot wou stijgen, maar dat de software dit voorkwam vanwege een stall warning en toen dus in de bossen naast het vliegveld terechtkwam.

Het is alleen wel weer zo dat juist fly-by-wire de landing in de Hudson van een A320 tot een goed einde heeft gebracht. Het voordeel daar was dat de piloten door de FBW continu op het randje van de flight envelope konden blijven en de kist dus bestuurbaar in de lucht konden houden. Uiteindelijk resulterende in een textbook landing op een plas water.

Als je de video's van die A320 landing ook bekijkt dan neem je je pet af voor die lui, als er in plaats van water asfalt had gelegen en het hoofdlandingsgestel was uitgeklapt hadden ze voor hun vliegexamen spontaan een 10 gekregen.

Door ncoesel, dinsdag 20 december 2011 20:43

Misschien wel, maar dit geval had door goed testen boven water moeten komen.

Door latka, dinsdag 20 december 2011 22:12

Dit is wel het soort software wat je niet gewoon "even test". Dit leent zich uitermate goed voor formele verificatie (zoals veel embedded systemen) waardoor dit soort zaken uit te sluiten zijn. Is echter wel moeilijk en tijdrovend en zal wel geschrapt zijn in de drive om time-to-market te halen. Dus dit soort functionele fouten mag niet meer in dit soort applicaties zitten.

Door Garyu, woensdag 21 december 2011 14:24

Formeel testen is voor dit soort dingen ook niet echt een oplossing, omdat je al heel snel een enorme state explosion hebt die je formeel ook niet meer fatsoenlijk op kan lossen.

Door taag, dinsdag 20 december 2011 21:51

Door YopY, dinsdag 20 december 2011 22:18

dit is gewoon slodig geprogrameerd.
iedereen weet gewoon als je met sensors omgaat dat ze wel eens foute informatie kunnen versturen. dit moet je dan in de software opvangen. zeker in dit soort situaties!

Neen: Dit soort situatie moet je als ontwikkelaar en leidinggevende voorzien, dus van te voren doorhebben 'Hmm, wat zou er gebeuren als maar één van de drie sensoren een foutieve melding geeft?'. Daar moet aan gedacht worden, die situatie moet nagebootst worden, en dat moeten ze bij elke nieuwe versie van de software opnieuw controleren.

En nee, je kunt niet alle situaties voorzien; menselijke fouten komen nu eenmaal voor, en zelfs dan heb je nog situaties die je als ontwikkelaar nooit kunt voorzien.

[/zelfverdediging]

Door timonb, dinsdag 20 december 2011 23:03

Wie zegt dat die ene sensor een foutieve waarde geeft. Het kan immers ook zijn dat de twee andere sensors kapot zijn.

Door mjtdevries, woensdag 21 december 2011 08:51

De kans dat van de drie sensoren er twee tegelijkertijd kapot gaan is extreem klein. Daarom dat je er dan vanuit gaat dat die ene afwijkende waarde de kapotte sensor is.

Dat is ook precies de reden dat er drie sensoren ingebouwd worden. Dat is het minimum aantal dat je nodig hebt om te bepalen welke sensor waarschijnlijk kapot is.

Daarom is het ook lachwekkend dat er mensen zijn die denken dat ze niet aan die situatie gedacht zouden hebben. Dat is juist de reden waarom er drie ingebouwd zijn. natuurlijk hebben ze aan die situatie gedacht!

Door Garyu, woensdag 21 december 2011 14:25

Je eigen hypothese is dat je een single point of failure kan opvangen. Als er twee kapot zijn, dan beweeg je je buiten je fault hypothesis en kan het vliegtuig neerstorten

.

Aan de hardware (sensors) worden overigens ook extreem strenge eisen gesteld, dus die vallen ook niet zomaar uit (kans 10^-9 per uur).

[Reactie gewijzigd door Garyu op woensdag 21 december 2011 14:40]

Door Cergorach, woensdag 21 december 2011 09:50

dit is gewoon slodig geprogrameerd.

En dat weet je te vertellen door je jaren lange ervaring als storingsmonteur? Je kan je code heel net programmeren, dat neemt niet weg dat er fouten in kunnen zitten. En omdat het een software fout is betekent het nog niet dat het een programmeer fout is bij de software ontwikkelaar die de software voor airbus heeft geschreven. Je heb namelijk ook nog eens te maken met fouten in compilers.

Door hangro, woensdag 21 december 2011 10:58

Met zoveel spelfouten lijk jij mij niet de aangewezen persoon om kritiek te leveren op slordige programmeurs.

Door trogdor, dinsdag 20 december 2011 22:40

Ik vraag me af waarom er 3 hoogte meters zijn, maar maar een display. En dan door een systeem laten bepalen welke er gelijk heeft.
Is het te simpel gedacht of zou het misschien zin hebben om de data van alle drie weer te geven, en ook een indicatie als ze het niet met elkaar eens zijn?

Door humbug, woensdag 21 december 2011 03:11

Je wilt gebruikers (in dit geval piloten) niet te veel informatie geven. Drie keer hetzelfde geeft in 99% van de situaties niet meer info dan enkel 1 waarde. Ook moeten drie displays ingebouwd worden en aangezien hoogte meting redelijk belangrijk in een vliegtuig moeten ze op een goed zichtbare plaats zitten. Resultaat minder ruimte voor andere balangrijke instrumenten. Je zult dan een afweging moeten maken welke informatie het meest relevant is voor de piloot en meestal is dat niet drie keer hetzelfde tonen

Wat natuurlijk wel een optie is om in het geval van afwijkingen in de metingen het display aan te passen of een apart display voor afwijkende data (van alle systemen) in te bouwen De vraag is echter hoe goed men foutieve waarden kan herkennen. Is dat goed mogelijk neemt de waarde van het tonen van de individuele (foutieve) waardes alleen maar meer af en kan het zelfs negatief uitpakken omdat dan de piloot moet gaan "gokken" welke klopt. Ik ga er maar vanuit dat men redelijk goed weet welke informatie nodig is en hoe die het beste kan worden weergegeven. En dus zal de cockpit van een Airbus doordacht en efficiënt in elkaar zitten.

Door Cergorach, woensdag 21 december 2011 09:52

Heb je wel eens een cockpit gezien van een commercial airliner? En je wilt nog meer info daar in gaan proppen, ik denk dat je dan eerder ongelukken gaat krijgen omdat je mensen overspoelt met nog meer info.

Door Garyu, woensdag 21 december 2011 14:42

Natuurlijk kan dat, en dat wordt soms ook gedaan, maar het is een zwaktebod. Je moet dan overigens ook garanderen dat de piloot dit in een noodsituatie ook op een correcte en tijdige manier kan controleren, vergelijken, en de juiste conclusie trekken. En dat doe je wéér met behulp van tests, waar je dus een groep piloten moet hebben om dat uit te proberen.

In dit specifieke geval lijkt me een redelijke no-go, omdat het een continue variabele is waar je flight control wezenlijk sneller op moet kunnen reageren dan een piloot dat ooit zo kunnen bevestigen.

Door Astennu, dinsdag 20 december 2011 17:24

Toch wel een kwalijke zaak. Maar dat krijg je helaas met steeds complexere software.
Er zitten gelukkig al wel meerdere sensors in. Maar als de software vervolgens niet kan concluderen dat een niet klopt en die data gaat gebruiken gaan er natuurlijk rare dingen gebeuren

Door rsbroer, dinsdag 20 december 2011 17:37

Maar het ergste is dat dit helemaal geen complexe software zaken zijn

2 out of 3 selectie is zo'n beetje de basis van fault tolerant systemen.
Ongelovelijk dat dit niet getest wordt, je moet bij iedere sensor ervanuit gaan dat hij stuk gaat of een verkeerde waarde aangeeft tov de andere. Dat moet ten alle tijden een veilige aktie tot gevolg hebben.
We hebben het hier nog niets eens over meervoudige fouten.

Door AlexanderB, dinsdag 20 december 2011 17:54

Dat moet ten alle tijden een veilige aktie tot gevolg hebben.

in principe ging dat dus precies goed, want op t moment dat t vliegtuig stilstaat in de lucht, valt het als een steen naar beneden. de enige manier om de controle terug te krijgen is de neus naar beneden drukken en weer snelheid opbouwen, en dat is precies wat de computer (onterecht) deed. alleen, wat je al zegt, die 2 out of 3 faalde blijkbaar..

Door player-x, dinsdag 20 december 2011 18:47

Aan de andere kant is het eigenlijk best raar dat deze vliegtuigen geen noodknop hebben om alle sensors te negeren en alleen de acties van de piloot uit te voeren, door het vliegtuig dom te maken en te laten reageren als een pre computer, mechanisch bestuurd vliegtuig.

Want de software is zo complex, en word met elke generatie weer meer complex, een noodsysteem dat terugval op de ervaring van de piloten is denk zeer wenselijk imho.

@Ricochet

Dit soort grote vliegtuigen kun je simpelweg niet mechanisch besturen.

Dat is niet wat ik zij.

door het vliegtuig dom te maken en te laten reageren als een pre computer, mechanisch bestuurd vliegtuig.

Niet de computer uitzetten, maar in een stand te zetten dat de piloot 100% controle heeft over wat het vliegtuig doet, en van de computer geen zelfstandige correcties toe te laat.

[Reactie gewijzigd door player-x op woensdag 21 december 2011 03:48]

Door Nextron, dinsdag 20 december 2011 19:07

Eens, maar dan introduceer je weer een situatie waar de computer de noodknop verkeerd interpreteert en zichzelf ongewenst uitschakelt. Dus op naar 3 van de 5 noodknoppen.

Door mrdemc, dinsdag 20 december 2011 19:23

Die is er wel. De auto-pilot uitschakelen

Dan moet de piloot alles zelf doen, wat ze uiteindelijk ook hebben gedaan, en handmatig gaan landen.

Door GoTUser, dinsdag 20 december 2011 19:26

kan, gewoon automatische piloot uitzetten. op de airbus heb je nog alternate- en direct law. Dat is vliegen zonder de computerbeveiligingen. maar geen piloot die dat handmatig zou inschakelen, want je kunt er "op het randje" mee vliegen zonder te crashen.
edit: dit was dus niet de automatische piloot maar de bijwerkingen van de beveiligingen in normal law met foute inputs. info hier:http://www.avherald.com/h?article=40de5374/0010&opt=0

[Reactie gewijzigd door GoTUser op dinsdag 20 december 2011 19:34]

Door Ricochet, dinsdag 20 december 2011 19:42

Als die zelfde noodknop ervoor zorgt dat je gelijk een BWK aan boord hebt, die voor jou (als piloot zijnde) al je vlieg kritische systemen in de gaten houdt en je ook gelijk waarschuwt als er iets mis is, ja dan heb je helemaal gelijk.

Maar de werkelijkheid is niet zo eenvoudig. Dit soort grote vliegtuigen kun je simpelweg niet met spierkarcht besturen. De krachten op de besturingsvlakken zijn dermate groot, dat je die met spierkracht niet in beweging krijgt. Alles is servo gestuurd.

Dat Airbus er toevallig voor kiest om zijn vliegtuigen met fly-by-wire uit te rusten, maakt dat principe niet meer of minder (on)veilig.

Als je het orginele eind rapport doorleest, zul je ook merken dat het de AoA sensor was, die het niet goed deed. Daarnaast wist ADIRU #1 dat de meeste data invalid was. Toch is er een situatie opgetreden waarop ADIRU #1 zelf het hoogteroer heeft aangestuurd ivm AoA pieken. Orginele rapport hier, samenvatting hier

Overigens zijn er nog 2 van deze incidenten voor gekomen, ook beide bij Qantas. Nu is alles onderzocht en er is geen reden om aan te nemen dat manuals en / of procedures van Qantas hebben bijgedragen aan deze incidenten. Een ander detail, het is niet Airbus, maar de fabrikant van de ADIRU, die de software schrijft. Voor dit soort componenten worden altijd 3e partijen ingehurd, immers een vliegtuig bouwer, bouwt echt niet meer alles zelf.

@ S0epkip hieronder:

Je hebt helemaal gelijk, ik druk me volledig verkeerd uit. Ik bedoel te zeggen, dat een vliegtuig geen directe mechanische verbinding met de cockpit meer heeft, maar alleen nog een indirecte, immers er zit servo besturing tussen (en hoe die servo's dat doen, kan inderdaad hydraulisch zoals by Boeing en Airbus.)

[Reactie gewijzigd door Ricochet op woensdag 21 december 2011 06:59]

Door freaq, dinsdag 20 december 2011 19:55

desalniettemin wil je de servo's handmatig kunnen besturen, het is geen supermanouvreerbare jet die je zonder computer niet onder controle kan houden, maar een stabiel vliegtuig en handmatige controle (by wire of niet) is gewoon wenselijk.

Door S0epkip, dinsdag 20 december 2011 21:34

Met behulp van hydraulica (Boeing) is een vliegtuig zeker nog wel mechanisch te besturen, handmatig (op spierkracht) gaat inderdaad niet lukken.

Door Anonnymous!, dinsdag 20 december 2011 19:52

Sensoren zitten in een vliegtuig omdat de zintuigen en waarnemingen van een mens bij lange na niet in staat zijn om de positie, snelheid en richting van het vliegtuig te bepalen op een hoogte van 10km, laat staan s'nachts.
En die ''Noodknop" zit er zeker wel op genaamd de Auto-Pilot overide, maar wat heeft dat voor nut in dit geval? de beslissing die de computer maakt in een fractie van een seconde kan je niet voorkomen voordat dat uitgevoerd word.

Door player-x, woensdag 21 december 2011 03:49

Niet de eerste keer maar wel om te ver komen dat het een tweede keer gebeurd.

Door neelespn, dinsdag 20 december 2011 21:44

ze hebben wel degelijk een noodknop, ze noemen dat ook wel gewoon de autopilot uit zetten, en op basis van standby instrumenten te werk gaan

Door Stoney3K, dinsdag 20 december 2011 23:47

ze hebben wel degelijk een noodknop, ze noemen dat ook wel gewoon de autopilot uit zetten, en op basis van standby instrumenten te werk gaan

Je instrumentarium staat helemaal los van je autopilot hoor.

Bovendien heeft een Airbus ook nog een fly-by-wire systeem wat het vliegtuig beschermt tegen wat minder slimme vliegbewegingen van een piloot, en dat is een systeem wat iets lastiger (maar niet onmogelijk) is uit te schakelen.

Door mjtdevries, woensdag 21 december 2011 08:56

Aan de andere kant is het eigenlijk best raar dat deze vliegtuigen geen noodknop hebben om alle sensors te negeren en alleen de acties van de piloot uit te voeren

Wat je je moet realiseren is dat een piloot de sensors niet kan negeren om een vliegtuig te besturen.
Een piloot kan en mag niet alleen op zijn zicht naar buiten vertrouwen, dat zou juist extra ongelukken veroorzaken. De orientatie van de vlieger zit er veel vaker naast dan de instrumenten.

Door timberleek, dinsdag 20 december 2011 17:56

2 out of 3 is inderdaad al iets waar het systeem mee verder zou moeten kunnen.

maar waarom moet hij alles zelf doen. waarom niet meteen een melding op het scherm toveren om de piloten in te lichten dat de sensoren van elkaar afwijken. dan is de piloot op de hoogte van het probleem en kan deze eventueel een juiste sensor selecteren om verder te gebruiken.

Door johnkessels87, dinsdag 20 december 2011 18:46

Toch niet! Wanneer er slecht 1 foutieve/andere waarde wordt geregistreerd zal de auto-pilot/fd niet meer mogen funcioneren maar zal moeten worden gevolgen doormiddel van raw-date ofwel op het handje.

Door scsirob, dinsdag 20 december 2011 18:13

2 out of 3 werkt goed als er 1 duidelijk foutieve informatie geeft. Het wordt een ander verhaal als de sensors informatie afgeven die binnen de design spec vallen maar toch fout zijn.

Door ari, dinsdag 20 december 2011 19:25

Ook dan kun je eenvoudig constateren dat twee van de drie meters één waarde geven, en de derde afwijkt. Welke dan foutief is laat zich raden. Wil je helemaal fail-safe werken, dan schakel je de hele boel uit en laat je de piloot op de hand verder vliegen.

Door hackerhater, dinsdag 20 december 2011 22:30

Het probleem is alleen als er 2 van de 3 defect zijn
dan concludeerd de computer onterecht dat de werkende sensor fout zit.........

if something can go wrong, it will go wrong

Door Texamicz, woensdag 21 december 2011 08:26

Tenzij natuurlijk die 2 foutieve ook nog niet dezelfde waarden van elkaar aangeven....

Stel voor je hebt een Snelheids sensor waarvan je gebruik maakt in de lucht van een Accelerometer die je integreert of 2x weet zo ff nie meer uit mijn hoofd.

Dan heb je één correcte sensor die aangeeft van 500km/u
Twee foute welke één 200 en 400 aangeven. Dan weet de computer inderdaad niet meer welke nou de correcte waarde is omdat je 2 sensoren nodig hebt die ongeveer dezelfde waarden moet hebben.

De software kan ook naar de TIJD kijken. Hey welke sensor faalde als eerste? Want twee sensoren die tegelijk op de nanoseconde stuk gaan is onmogelijk.
Je zet een microcontroller op die van alle drie een sample neemt per... zoveel uS.

Dan kun je dus ook dit omzeilen en duidelijk zien welke als eerste faalt. Een vliegtuig heeft geen plotselingen snelheids verminderingen. En als een sensor defect is kan dat dus wel gebeuren. Als dit gedetecteerd wordt door het samplen met tijd dan kun je dus ook met 3 sensoren feilloos fout correctie toepassen. Ook al falen er 2.

Ik denk gewoon dat het inderdaad een menselijke software fout is want je kan dit soort algoritmes wel goed waterdicht krijgen met allerlei controle posten. Die ook dubbel zijn uitgevoerd met verschillende soort werkingen.

Door indigo79, dinsdag 20 december 2011 22:48

Er zijn geen drie dezelfde sensoren waarvan twee dezelfde waarden doorgeven en één iets anders. Er zijn drie verschillende sensoren, liefst gebaseerd op verschillende meetprincipes die altijd verschillende waarden doorgeven en om te beslissen welke waarde juist of fout zou kunnen zijn wordt ook nog gekeken naar wat andere (niet-snelheids) sensoren meten

En in dat geval is een sensor die een beetje maar net teveel afwijkt al heel wat lastiger te detecteren.

Een modern vliegtuig 'op de hand' besturen is trouwens niet bepaald evident en vaak veel risicovoller dan de automatische piloot z'n werk laten doen. Daarom dat die systemen zich niet voor elke futiliteit uitschakelen.

Door carlo, dinsdag 20 december 2011 18:53

Maar het ergste is dat dit helemaal geen complexe software zaken zijn

In dit sterk vereenvoudigde nieuwsartikel klinkt het inderdaad als een stomme fout die eenvoudig voorkomen had kunnen worden, toch hebben ze er drie jaar over gedaan om de oorzaak van het probleem te vinden...
Blijkbaar zijn de zaken toch iets ingewikkelder dan dit nieuwsartikel doet geloven.

Door latka, dinsdag 20 december 2011 22:14

Of moest er een 'politiek wenselijk antwoord' komen en wilde Airbus de boel eerst ff. fixen voordat het bekend werd?

Door Garyu, dinsdag 20 december 2011 18:58

Dit wordt in principe ook getest, wat denk je hoe een software-ontwikkelproces eruit ziet als je dit in de boordcomputer wil implementeren?

Even als achtergrond: boordcomputersoftware moet volgens DO-178B DAL-A (hoogst mogelijke niveau) ontwikkeld worden, wat betekent dat je hele proces enorm gedetailleerd wordt. Dit betekent onder andere:

hazard analysis en failure-analysis: wat gebeurt er als er iets niet werkt, en hoe ga je daarmee om. Van elke mogelijke bitflip (radiation, etc) moet beschreven worden hoe je ermee omgaat en waarom dat niet tot een failure kan leiden
je hele concept moet fail-operational en 3x- (onafhankelijk) redundant zijn.
3x redudant betekent meestal niet alleen hetzelfde systeem 3x inbouwen, maar drie verschillende systemen die hetzelfde doen, om een design-failure uit te kunnen sluiten.
van elke requirement moet precies beschreven worden in welke line-of-code(s) die requirement afgehandeld wordt
van elke line-of-code moet precies beschreven worden welke requirement(s) het afhandelt
je moet middels tests -alles- bewijzen, maar dan ook -alles-.
je moet je code door meerdere collegae laten controleren, en bij elke review waar fouten gevonden worden, moeten de requirements aangepast worden
etc, etc.

Bugs zijn onvermijdelijk, maar ze moeten niet tot een crash leiden. In dit geval schijnen ze er eentje te hebben gevonden - als dat alle 10.000 jaar gebeurt (is omgerekend je statistisch toelaatbare kans ongeveer (10^-9), dan hoop ik dat dat niet nog vaker gaat gebeuren.

[Reactie gewijzigd door Garyu op dinsdag 20 december 2011 19:05]

Door latka, dinsdag 20 december 2011 22:15

Formele verificatie is geen onderdeel van die standaard? Bizar: met testen kun je helemaal niet de afwezigheid van fouten aantonen, alleen de aanwezigheid...

Door Garyu, woensdag 21 december 2011 14:45

Nee, dat bestond ten tijde van de ontwikkeling van de standaard nog niet. Er wordt al jaren geknutseld aan de opvolger (DO-178C) waar model-based verificatie en formele verificatie wel beschreven zijn.

Door Myrdreon, dinsdag 20 december 2011 19:22

Maar hoe weet je dan dat de 2 out of 3 moet zijn, niet 1 out of 3? Dat is juist het probleem met dit soort algoritmes, bepalen welke goed/fout zit onder sterk variabele omstandigheden. Zie ook:

Bovendien viel kortstondig de cabinedruk weg.

De piloten zouden tijdens het incident zijn overstelpt met incorrecte waarschuwingen en onjuiste indicaties van de hoogte en de snelheid

Als ik het goed begrijp, bepaalde de software in dit geval dat juist de overige 2 incorrect waren (waarschijnlijk door een vergelijking op basis van andere meetinstrumenten). Daarop volgde de rekensom dat onder andere ook de hoogte foutief was met als gevolg veel alarmen (immers werd de verkeerde sensor als correct verwerkt, waardoor andere waarden onveilig werden en ingrijpen door de computer vereist was).

Probleem in de software was dus niet het 2 out of 3 selectie in de basisvorm, maar de onderliggende criteria waarmee in dit geval onjuist werd vastgesteld welke er kapot was. Dan zit je al een aardig stuk complexer in de randvoorwaarden. Vooral als je het hebt over een fout die 0,000001% keer voorkomt (als ik het zo zie slechts 3 fouten over de miljoenen vluchten) zal zelfs een doorgewinterde expert of zelfs menig computerprogramma de fout niet kunnen ontdekken.

[Reactie gewijzigd door Myrdreon op dinsdag 20 december 2011 19:26]

Door hidden, dinsdag 20 december 2011 19:45

Mocht het zo zijn dat er 2 "stuk" zijn lijkt het mij sterk dat ze dan samen de zelfde snelheid aangeven.

Door indigo79, dinsdag 20 december 2011 22:52

Als ze correct werken geven ze ook niet dezelfde snelheid weer. Vergelijk in je auto bijvoorbeeld eens de snelheid van je teller met de snelheid van je GPS. In een vliegtuig zijn verschillende sensoren liefst ook gebaseerd op verschillende meetprincipes, dus daar heb je dat probleem ook. OK, ze zijn beter geijkt, maar er blijft een belangrijk verschil tussen zitten.

Door pe1dnn, dinsdag 20 december 2011 22:16

Er worden massa's fouten gemaakt met software. Bekende anekdotes over bijvoorbeeld de 1e Airbus proeven die op Schiphol op de landingsbaan stuiterden omdat het fly by wire systeem niet lager wou dan 11 meter boven de baan, dat omdat het systeem dacht dat lager dan 0 meter niet kan; Schiphol ligt op 11 meter beneden NAP. Een andere over een F16 die bij een testvlucht de evenaar kruist naar het zuidelijk halfrond en meteen op z'n kop gaat vliegen: foutje in het teken in het navigatie systeem. Dit zijn de smaakmakende voorbeelden bij cursussen defensief programmeren; of ze kloppen weet ik niet.

Wat in elk geval wel klopt zijn de zeer vele incidenten die worden gemeld in Usenet nieuwsgroep comp.risks, een nieuwsgroep over computer gerelateerde risico's. Soms erg treurig wat je daar leest, echt de meest stompzinnige bugs in echt kritieke applicaties. Ik denk dat in de volgende editie ook deze Airbus bug aan de orde zal komen. Oude edities nalezen kan hier: http://catless.ncl.ac.uk/Risks/. Er is ook een zoekfunctie, zoek eens op Airbus en je ziet dat dit bepaald niet het eerste software probleem is van Airbus.

Door zeeg, woensdag 21 december 2011 08:03

Het laagste punt van Nederland is 1) niet Schiphol en 2) 6.76m onder NAP. Zie ook http://nl.wikipedia.org/wiki/Laagste_punt_van_Nederland

Door elteck, dinsdag 20 december 2011 18:01

Ja inderdaad. Een collega van mij was betrokken bij de ontwikkeling van een sensor systeem voor het monitoren van vibratie in de turbine motor. Dit was een opdracht van GE. Hij vertelde me dat er maar liefst 7000 vibratie sensoren in 1 turbine zitten. Het gaat om monitoren van ombalans en slijtage in de lagering.
Het schijnt dat er de laatste decenia een "sensor revolutie" in de vliegtuig industrie heeft plaats gevonden. Alleen zijn de kwalificatie testen verouderd, die stammen nog van voor die "sensor revolutie", en testen onvoldoende op falende sensoren.

Door Wulfklaue, dinsdag 20 december 2011 19:03

Het probleem is dat deze zelfde sensor revolutie, zich niet enkel voorgedaan heeft in de Vliegtuig industrie, maar ook op allerhande apparatuur.

Bekijk een auto van de jaren 90, en een nieuwe "moderne" auto. De elektronica, met de 1001 sensors is zo gegroeid, dat tegenwoordig je meer in panne staat wegens een sensor / elektronica probleem, dan een echt mechanische probleem.

Ergste van al is, dat mensen dit blijven slikken.

Je wasmachine stopt ineens met werken... 1 slechte sensor in gans het geheel, en de reparatiekosten zijn zowat 50% van wat je wasmachine kost.

Printers ... zelfde zooi. Hebben in het verleden op mijn bedrijf, meerdere keren een technieken laten komen, om uiteindelijk te ontdekken, dat 1 dom sensor lastig deed, met enorm productie verlies, en natuurlijk kosten. Zou actueel bijna goedkoper geweest zijn om een nieuwe te kopen, dan de reparatie kosten.

Ergste van al is, dat men natuurlijk geen deftig handleidingen meer meegeeft. Je toestel piept, of blinkt een waarschuwing ... en je denkt ... WFT betekend dat nu.

Ik rij met een bijna antieke auto, maar die rijd perfect. Bijna geen sensors, en elektronica. Als ik zie de problemen dat mensen om mij al gehad hebben met hun voertuigen, vaak wegens de elektronica ...

Soms vind ik dat men gewoon te ver gaat. Het is niet omdat je kunt een sensor installeren voor x, dat je moet. Zeker als x niet "belangrijk" is.

Nu, bij zaken zoals wasmachine, printers, auto's is de schade nog "beperkt", maar als men idd ziet dat bij vliegtuigen, bij een beetje sensor probleem, het vliegtuig bijna gaat crashen...

En dan was er daar ene van RyanAir, of welke goedkope vliegmaatschappij dat het ook weer was, dat, omdat vliegtuigen toch zo geautomatiseerd zijn, dat men de co-piloot wilde afschaffen. Beeld je in. Piloot moet naar WC, vliegtuig sensor fout, ...

Door VNA9216, dinsdag 20 december 2011 18:43

Doet me een "mop" denken:

"At a recent software engineering management course in the US the participants were given an awkward question to answer. "If you had just boarded an airliner and discovered that your team of programmers had been responsible for the flight control software how many of you would disembark immediately?"

Among the ensuing forest of raised hands, only one man sat motionless. When asked what he would do, he replied that he would be quite content to stay onboard.

With his team's software, he said, the plane was unlikely to even taxi as far as the runway, let alone take off. "

Je zal toch de verantwoordelijkheid hebben....

Door wildhagen, dinsdag 20 december 2011 17:25

Op deze site staat iets meer info, met o.a. meer technische achtergronden.

Software waar het ging was al best oud, begin jaren 90 is die code al geschreven.

Door himlims_, dinsdag 20 december 2011 17:37

Door ThaDiggah, dinsdag 20 december 2011 17:51

Dan zou je haast denken dat die code zich als betrouwbaar kan laten bestempelen. Kennelijk hebben ze toch iets met de code gedaan waardoor zijn algoritmes op hol slaan

Door Iblies, dinsdag 20 december 2011 18:04

Het kan ook andersom,
materiaal wordt steeds opnieuw geproduceerd en er enkele units doorheen zijn geglipt die niet binnen de normen zijn waarvoor de software geschreven is.
Als ik de media kan geloven is de luchtvaartindustrie eentje die snel een probleem achterhaald en vervolgens oplost zodat hetzelfde probleem niet meer kan voorkomen.

Door Garyu, dinsdag 20 december 2011 19:05

Die kans acht ik praktisch 0. De certificering stelt dermate hoge eisen dat de kans dat dit gebeurt echt minimaal is.

Daarnaast hebben ze schijnbaar uitgesloten dat het om een hardware-error gaat. Dat die sensor de mist ingaat, kan gebeuren. Daar wordt het systeem ja ook voor gemaakt, daarom zitten er ook meerdere sensoren in (per flight computer 2, in totaal 6 voor de 3 redundant flight computers), daarnaast is er ook nog een secondary flight control die de boel van de primary flight control overneemt, mocht de eerste kapot gaan of niet genoeg data hebben. Als de primary-flight-control geen airspeed heeft of heeft vastgesteld dat zijn sensoren verkeerde informatie afleveren, gaat hij offline en neemt de secondary flight control over. Die kan zijn werk ook zonder airspeed doen, en de piloot krijgt het wat drukker want die moet dan het vliegtuig in de lucht houden.

Maar goed, het gaat dus om een software of hardware bug in de flight control unit, en dat is natuurlijk vrij ernstig. Niet uit te sluiten dat een bug niet ontdekt wordt, daarvoor is die software al te complex (ondanks dat het niet om heel veel code gaat bij de A330). Als je dan bedenkt dat de A350 een vééél complexere flight-code heeft dan ga je natuurlijk wel nadenken over wat er allemaal kan gaan gebeuren met die toekomstige machines.

Door Kveli, dinsdag 20 december 2011 22:32

die certificering zet ik soms ook mn twijfels bij. kent u het verhaal van de "gecertificeerde" schroeven die ook in airforce one werden aangetroffen? allemaal inferieure kwaliteit ondanks certificering, en allemaal om de centen.

Door pe1dnn, dinsdag 20 december 2011 22:33

Er zal misschien ook een verschil zijn in hoe een sensor kapot gaat. Wat ik maar wil zeggen is dat dingen op vele manieren stuk kunnen gaan en dat het best zo kan zijn dat de software op vrijwel alle fouten goed reageert maar dat nu toevallig een sensor op zo'n manier kapot is gegaan dat net die fout niet is voorzien. Misschien zelfs wel omdat oudere sensoren nooit op die manier stuk konden en de software nooit is aangepast voor een afwijkende nieuwere sensor. En zo kan software die jaren als goed en betrouwbaar is beschouwd zich opeens misdragen.

Speculatie natuurlijk maar in dergelijke complexe en samenhangende systemen is een fout snel gemaakt. De kans is misschien praktisch 0 maar nooit helemaal. Je kan onmogelijk alles testen. Dat is het grote probleem van testen: bewijzen dat iets goed is kan je daarmee niet, je kan alleen bewijzen dat iets fout is als je een fout hebt gevonden.

Door mjtdevries, woensdag 21 december 2011 09:07

Daarnaast hebben ze schijnbaar uitgesloten dat het om een hardware-error gaat. Dat die sensor de mist ingaat, kan gebeuren.

Wat word er hiet toch een hoop onzin uitgekraamd.
Natuurlijk hebben ze niet uitgesloten dat er een sensor de mist in gaat. Als dat waar was, dan zouden ze gewoon maar 1 sensor ingebouwd hebben, ipv 3 verschillende sensors.
De enige reden dat er drie sensors in zitten is juist om te detecteren wanneer een sensor de mist in gaat.

Er is een zeer uitzonderlijke bug in geslopen die in zeer zeldzame gevallen optreedt. Dat blijkt wel uit de cijfers:

The air-speed sensor malfunction was one of only three such malfunctions known worldwide in 128 million operating hours

Shit happens!

Al die mensen die hier zo lekker blaten over slordig werk mogen eens vertellen hoeveel systemen zij geschreven hebben die in 128 miljoen werkuren maar 3 fouten hebben gehad.

[Reactie gewijzigd door mjtdevries op woensdag 21 december 2011 09:08]

Door Garyu, woensdag 21 december 2011 14:49

Ik bedoel dan ook niet de sensor hardware, maar de boordcomputer hardware met een bug in zijn CPU. Zoiets is hééél moeilijk te bewijzen, en is ook bijvoorbeeld de reden dat dit soort CPUs enorm achterhaald zijn qua performance, omdat de nieuwere CPUs gewoon praktisch niet te verificeren zijn.

Maar goed, dat er een hoop onzin uitgekraamd wordt is duidelijk - dat ik daarvan beschuldigd wordt, terwijl onze apparatuur in zowel de nieuwe Boeings als Airbussen meevliegt, vind ik wel een beetje jammer..

Door Ex-Lekkerlander, dinsdag 20 december 2011 18:46

Dan zou je haast denken dat die code zich als betrouwbaar kan laten bestempelen

leeftijd van software zegt niets over de betrouwbaarheid. Al zou microsoft door zou zijn gegaan met de support van windows98 dan hadden we nu nog steeds geen uitermate betrouwbare windows98 versie tot onze beschikking

Door S0epkip, dinsdag 20 december 2011 18:09

Zo oud vind ik code uit de jaren 90 helemaal niet... overigens zou dit m.i. helemaal niets over de 'robuustheid' van een code/algoritme mogen zeggen, hooguit over de snelheid of bijv. geheugengebruik.

Dit

"The failure mode was probably initiated by a single, rare type of trigger event combined with marginal susceptibility to that type of event within the CPU (central processor unit) module's hardware," investigators said.

Vind ik nogal nietszeggend. Helemaal gezien deze zin schijnbaar 50% van de verklaring is.

"er is waarschijnlijk een enkel, zeldzaam incident opgetreden waarvoor de hardware van de cpu marginaal vatbaar is" uhu, dat had ik ook best uit mn mouw kunnen schudden...

Door Ramon, dinsdag 20 december 2011 17:25

"vrij zeker" hmm? lekker dan...

Door Pixeltje, dinsdag 20 december 2011 17:50

Dat heeft met verantwoordelijkheden te maken.. als ze zeggen dat het nooit meer voorkomt, en het gebeurt toch krijgen ze de halve wereld achter zich aan natuurlijk.

Door Cheezus, dinsdag 20 december 2011 17:25

... waardoor de onderzoekers er vrij zeker van zijn dat soortgelijke incidenten niet meer zullen voorkomen.

Vrij zeker? Bij een vliegtuig met 300+ mensen aan boord mogen ze er wel absoluut zeker van zijn voordat ze er weer mee gaan vliegen lijkt me

Door wildhagen, dinsdag 20 december 2011 17:27

Garanties heb je nooit, zeker niet bij zulke complexe software.

Dan kan je dus nooit meer vliegen, want geen enkele bedrijf kan een 100 procents garantie afgeven...

Lijkt me dus niet praktisch. Een 'aan zekerheid grenzende waarschijnlijkheid' lijkt me het hoogst haalbare.

Door wootah, dinsdag 20 december 2011 17:38

Nee, maar je maakt als zo'n bedrijf wel testcases...
Testen of een algoritme adhv 1 sensor of 2 sensoren de juiste snelheid kan meten lijkt mij een erg goede testcase.

of ze dat ook gedaan hebben, of niet goed gedaan is een 2e.
Bij dit soort software is het gewoon belangrijk dat je veel test, heel veel, voordat je gaat vliegen

Door F!SH, dinsdag 20 december 2011 17:43

Zoals steeds mag je aannemen dat de deadlines ervoor gezorgd hebben dat x aantal tests niet geschreven konden worden (of incorrect geschreven zijn) omdat er nu eenmaal opgeleverd moest worden.

Wat dat betreft kan je misschien zeggen, jammer dat er niets erger gebeurd is dan zou het management er misschien iets uit geleerd hebben... maar zelfs in die situatie zouden ze enkel leren "die developer moet buiten, mezelf valt niets te verwijten want ik heb de code niet geschreven"

[Reactie gewijzigd door F!SH op dinsdag 20 december 2011 17:44]

Door fynrd1, dinsdag 20 december 2011 17:57

Aan de twee reacties hierboven, enig idee hoe zo'n "snelheidsmeter" werkt? Weet vrijwel zeker van niet, het probleem ligt in het algoritme en komt waarschijnlijk 1*10^10 voor ofzo, als het niet meer is. Gelukkig is het probleem ontdekt zonder dat daar een fatale oorzaak aan is vooraf gegaan. Vraag me af of de link gelegd kan worden met AF447..

Door mjtdevries, woensdag 21 december 2011 09:12

of ze dat ook gedaan hebben, of niet goed gedaan is een 2e

Tuurlijk niet joh. De vliegtuigindustrie staat daarom ook als zeer onveilig bekend...

Nu weer even je verstand gebruiken. Er is geen veiliger manier van reizen dan vliegen. En dat komt omdat ze heel erg goed testen en ontzettend veel redundantie inbouwen.
Maar het blijft mensenwerk, dus er zullen altijd bugs in blijven zitten die in zeer uitzonderlijke situaties naar boven komen.

Door pe1dnn, dinsdag 20 december 2011 22:39

En zelfs als je nooit vliegt kun je toch alsnog bij een vliegtuigongeluk betrokken raken. Leven is een risico, het is ook niet voor niets dat er in het leven maar 2 zekerheden zijn.

Door Cpt Placeholder, dinsdag 20 december 2011 17:26

3 instrumenten die het niet met elkaar eens zijn maar de software doet daar niks mee? Crash van Turkish Airlines bij Schiphol werd ook mede mogelijk gemaakt door zo'n programmeer fout. Vraag me toch sterk af wat voor mensen die software maakt en door hoeveel mensen het gecontroleerd wordt.

Door IceM, dinsdag 20 december 2011 17:33

Die software wordt vast niet gecontroleerd en getest, als de programmeur het stukje software goed acht wordt het gecommit en uitgerold.....

Natuurlijk wordt die software tot in den treuren getest en er zullen allerlei (test)procedures zijn om incidenten en fouten zoveel mogelijk uit te sluiten. Bugvrije software is echter een utopie, fouten maken is menselijk en dat zal bij menselijke arbeid ook altijd blijven gebeuren. In dit soort gevallen kunnen die fouten echter grote gevolgen hebben, het is een beetje hetzelfde verhaal als chirurgen die fouten maken; onmogelijk om volledig uit te sluiten maar helaas wel met grote gevolgen.

Door Cpt Placeholder, dinsdag 20 december 2011 17:39

Als een vliegtuig 2 hoogtemeters heeft, lijkt het mij niet een programmeerbugje als de software helemaal niets doet met de informatie van de tweede hoogtemeter, zeker als beide hoogtemeters een totaal andere waarde door geven. Dat noem ik een hele grote ontwerpfout. In dit geval had de autothrottle uit moeten gaan en de landing volledig over moeten laten aan de piloten.

Door Moartn, dinsdag 20 december 2011 17:42

Met 2 meters is het nog best lastig, want als er 1 stuk gaat, welke van de 2 geeft de correcte waarde? Dat is moeilijk te bepalen. Met 3 zou het toch te doen moeten zijn: als er 1 waarde afwijkt van de andere 2 moet die genegeerd worden.

Maargoed, we versimpelen het hier natuurlijk gigantisch met z'n allen: die systemen zijn gigantisch complex en het ontwikkelen en testen van software van vliegtuigen kost tienduizenden manuren (zo niet meer), en fouten komen nauwelijks voor. Vliegen blijft toch een van de meest veilige manieren van vervoer

[Reactie gewijzigd door Moartn op dinsdag 20 december 2011 17:43]

Door corl, dinsdag 20 december 2011 17:54

Toch zou het in de basis! niet zo moeilijk moeten zijn. Het blijft gewoon een vliegtuig dat onder normale omstandigheden gewoon in de lucht blijft vliegen.

Indien er een hoogte sensor afwijkt en de software heeft geen andere waarmee een goede waarde verkregen kan worden dient de software de volledige controle aan de vliegers over te laten. Die kunnen dan de beste afweging maken.

De software mag op dat moment niet zomaar een duikvlucht inzetten.

Door tiranofice, dinsdag 20 december 2011 18:27

Maar daar zit je in een cirkelredenering. Hoe moet de software in godsnaam weten dat de sensor afwijkt zonder dat hij de correcte waarde weet? Je zou er wel probabiliteit ofzo kunnen opzetten (kans dat het vliegtuig 100m zakt op 10 sec op dit punt in de vlucht is klein) maar dan kan je nog altijd gevallen tegenkomen die er net tussen glippen.

Door johnkessels87, dinsdag 20 december 2011 18:52

Daarom wordt er ook nog ge-cros-checked met de gps'. Llaag boven de grond kan dat ook nog met de radio-hoogte-meter.

Door mjtdevries, woensdag 21 december 2011 09:14

Een gps is ontzettend onnauwkeurig wat betreft hoogte meting. Het lijkt me extreem onwaarschijnlijk dat ze dat in een verkeersvliegtuig gebruiken.

Door johnkessels87, donderdag 22 december 2011 17:16

Bij 6 of meer sattelieten is dit naukeurig op enkele meters.

Door timberleek, dinsdag 20 december 2011 18:56

waarom niet een 'simpele' inclinometer erin.

als de hoogtemeter ineens een enorm verschil in hoogte ziet moet dat ook te zien zijn op de verticale versnelling.

Door timberleek, dinsdag 20 december 2011 18:00

maar wie zegt dat het systeem het op moet lossen?

waarom niet input vragen van de piloot.
ik krijg 2 afwijkende waardes van de hoogtemeter:
meter 1: 20.000 voet
meter 2: 8.000 voet

welke te gebruiken?

de piloot zal wel weten op welke hoogte hij hoort te zitten (al dan niet via analoge meter) of hij kan het opvragen bij de luchtverkeersleiding. zo'n beetje elke moderne toren ziet ook oa hoogte en snelheid van de toestellen. of is dat info die doorgestuurd wordt uit het toestel?

Door AlexanderB, dinsdag 20 december 2011 18:05

wrong, de hoogte van t toestel word afgelezen van de hoogtemeter van t toestel en opgestuurd via de beacon van t toestel.. zo zijn dr in de jaren 80 nog n paar flink gecrashed..

Door timberleek, dinsdag 20 december 2011 18:37

dat wist ik dus niet zeker, vandaar de vraag.

dan valt die optie dus af

Door VNA9216, dinsdag 20 december 2011 18:46

Hoeft niet, op veel plaatsen kunnen ze je met actieve radar ook nog wel peilen. Alleen moet je wel weten waar je mee bezig bent, en het is natuurlijk veel minder precies. maar in een noodgeval zou het best nog wel haalbaar kunnen zijn om via die route je hoogte iig "in te schatten"

Door Mischa_NL, dinsdag 20 december 2011 20:32

Primary rader bedoel je dus. Dat is een passief systeem.
Secondary radar werkt dmv transponders in een vliegtuig, en deze sturen de informatie richting de grond. Fout in vliegtuig = fout op de grond.

Door johnkessels87, dinsdag 20 december 2011 18:53

Ofwel via mode C of S van de transponder

Door Permutor, dinsdag 20 december 2011 18:08

Die kennen we! Dan leest de luchtverkeersleiding de hoogte op die op het radarbeeld bij het betreffende vliegtuig staat. Laat dat getal nu juist de meting zijn dat de transponder van het vliegtuig zelf heeft doorgegeven aan de verkeersleiding.

Door Niosus, dinsdag 20 december 2011 18:21

Hoe weet de piloot dat nu in gods naam? het verschil tussen 8k en 20k is duidelijk, maar als het minder is dan kan je dat echt niet zomaar raden.

Door timberleek, dinsdag 20 december 2011 18:38

dergelijke grote afwijkingen zijn er dan al makkelijk uit te halen. en als het kleiner is is het alsnog verstandig om de piloot op de hoogte te stellen, dan kan hij (m/v)het in de gaten houden.

Door Jegorex, dinsdag 20 december 2011 18:49

Op dat moment geef je aan de verkeersleiding door dat er problemen zijn met de hoogtemeting en de verkeersleiding zal zorgen dat andere vliegtuigen uit de buurt blijven.
Vervolgens ga je naar het dichtstbijzijnde vliegveld waar je op zicht kunt landen en het zou mogelijk moeten zijn zonder exacte hoogtemeting.

Door Stoney3K, dinsdag 20 december 2011 23:58

Hoe weet de piloot dat nu in gods naam? het verschil tussen 8k en 20k is duidelijk, maar als het minder is dan kan je dat echt niet zomaar raden.

Daar heeft hij, naast de twee hoogtemeters op de PFD's (Primary Flight Displays) die hun informatie halen uit de GNADIRU's, digitale hoogtemeters, dus ook een standby hoogtemeter voor.

Dat is een ouderwetse, mechanische hoogtemeter die niks anders is dan een veredelde barometer. Als die dus door de piloot goed is ingesteld (1013 millibar boven transition altitude, weersafhankelijk onder transition altitude), dan zal die altijd de juiste waarde aan de piloot doorgeven.

Is dat nu 20.000 voet in plaats van 8.000, dan kan de piloot ervoor kiezen om allebei de PFD's vanuit de GNADIRU van informatie te voorzien die juist is. De foutieve unit wordt dan door de piloot zelf uitgezet.

Moderne verkeersvliegtuigen hebben mede om die reden ook 3 units, als er 1tje een afwijkende waarde geeft wordt die naar de piloot gemeld als defect.

Door Ximinez, dinsdag 20 december 2011 18:20

Je hebt waarschijnlijk het rapport van de De Onderzoeksraad Voor Veiligheid niet gelezen wat die Turkish Airlines crash was niet het gevolg van een software fout.

Dan is er nog een wezenlijk verschil tussen de betreffende toestellen. Boeing is geen voorstander van volledige fly by wire en past dat dan ook niet zo ver toe als Airbus. Airbus toestellen zijn volledig fly by wire. De software heeft hier nadrukkelijk een veel prominentere rol.

Reden waarom er een type en class ratings bestaan voor het mogen besturen van een bepaald type toestel.

Maar mocht je de AOPA stukken lezen dan is recent een interessant artikel verschenen dat namelijk de piloten in de commerciële burgerluchtvaart zijn "vergeten" hoe ze moeten vliegen. Dat klinkt wat vreemd maar de jonge generatie is "opgevoed" met ver gevorderde automatisering en is in interactie met die automatisering en niet meer met de basis vaardigheden van het vliegen. Hoe herken en corrigeer je een overtrek. Er zijn genoeg voorbeelden van noodlottige crashes die het gevolg zijn van een te groot vertrouwen in de automatische piloot. Maar goed dit is niet waar het bovengenoemde artikel over gaat.

Ik wilde alleen duidelijk maken dat die vergelijking met de crash van de Turkish Airlines in dit geval mank gaat.

Door Stoney3K, woensdag 21 december 2011 00:00

Maar mocht je de AOPA stukken lezen dan is recent een interessant artikel verschenen dat namelijk de piloten in de commerciële burgerluchtvaart zijn "vergeten" hoe ze moeten vliegen. Dat klinkt wat vreemd maar de jonge generatie is "opgevoed" met ver gevorderde automatisering en is in interactie met die automatisering en niet meer met de basis vaardigheden van het vliegen. Hoe herken en corrigeer je een overtrek. Er zijn genoeg voorbeelden van noodlottige crashes die het gevolg zijn van een te groot vertrouwen in de automatische piloot. Maar goed dit is niet waar het bovengenoemde artikel over gaat.

En daar tegenover staat nog steeds dat de industrie te weinig vliegers heeft én de selectie voor het opleiden van nieuwe vliegers veel te streng is. Ze willen duidelijk wel voor een dubbeltje op de eerste rang zitten.

Door Cpt Placeholder, woensdag 21 december 2011 00:33

Ik zal niet zeggen dat ik alle rapporten volledig heb gelezen, maar wat ik er wel van heb gelezen zegt mij genoeg om te kunnen zeggen dat een software fout de crash mogelijk gemaakt heeft. De piloten hadden in de gaten moeten hebben dat het toestel te langzaam vloog. Het toestel vloog langzaam omdat de autothrottle uit ging van een hoogte van -7 voet. Deze waarde kwam van een van de 2 hoogtemeters, die op een eerdere vlucht ook al had gefaalt en vervangen had moeten worden.

Daar stopte het rapport ongeveer. Conclusie > fout piloten/Turkish Airways. Toch vind ik het vreemd dat het flightsystem dus geen input van de piloot vraagt op het moment dat de instrumenten sterk afwijkende waarde meten.

Door rapture, dinsdag 20 december 2011 18:27

Het is gemakkelijk om een scriptje aan 1 instrument te hangen om iets te automatiseren ipv eerst controleren of er een instrument raar aan het doen is.

Naast 3 pitotbuizen, kan je ook GPS, gronddetectieradar, gyroscopen,... als informatiebronnen gebruiken. Het is belangrijk dat je andere technologieën gebruikt om een single point of failure zoals het bevriezen van pitotbuizen uit te sluiten. De ene bron is accurater dan de andere. Je kan andere gewichten en/of boven/ondergrenzen van acceptabele meetwaarden eraan hangen.

Als 1 instrument te ver afwijkt van de rest, dan gooi je die uit de vergelijking om te voorkomen dat het boeltje scheef te trokken wordt. Je kan het verdachte instrument nakijken en indien nodig manueel heractiveren.

Nu trekt de software een rare conclusie uit 1 defect instrument, bv gooi het vliegtuig tegen de grond bij Turkish Airlines crash bij Schiphol.

Door S0epkip, dinsdag 20 december 2011 21:49

Wat me ook slim lijkt is steeds vergelijken met de vorige (gemiddelde) waardes voor hoogte (en positie van de roeren etc.) als hier voor EEN sensor opeens grote stappen worden gemaakt in een klein tijdsbestek (wellicht zelfs buiten de fysieke stijg- en daalvermogens van het toestel) dan kan de informatie van deze sensor vanaf dat moment als onbetrouwbaar worden aangeduid.

Door MadButcher, dinsdag 20 december 2011 17:26

Zijn er hier nog informatici die zich bezig houden met Numerieke Methoden?
Wiskunde van het doorrekenen van meet- en afrondingsfouten.
Aanpassen van algorithmes zodat deze een nauwkeuriger resultaat geven.

Door Permutor, dinsdag 20 december 2011 18:10

Heb ik gedaan, maar dat is al 26 jaar geleden.
Ik verwacht overigens niet dat de methoden van nu heel veel verschillen van toen. Alleen zijn de computers ontzettend veel sneller en realtime te gebruiken, i.t.t. toen.

Door tiranofice, dinsdag 20 december 2011 18:31

Krijgt niet iedere degelijk opgeleide student computerwetenschappen numerieke methoden? Bij ons in Gent alleszinds wel

Door Sir Isaac, dinsdag 20 december 2011 22:03

En iedere wis- of natuurkunde student.

Door Tijgert, dinsdag 20 december 2011 17:26

Gutgutgut, wanneer leert men eens wat minder sensatiezuchtig te zijn en een voorzorgslanding een voorzorgslanding te noemen.

Door eMCee®, dinsdag 20 december 2011 17:31

Met allerlei incorrecte waarschuwingen en 119 gewonden waarvan 12 ernstig, en daar bovenop ook nog raar vlieggedrag van het toestel zelf kun je dit geen voorzorgslanding noemen.
Dit is een regelrechte noodlanding en een geluk dat er verder niets is gebeurd.

Door Mischa_NL, dinsdag 20 december 2011 20:35

De vraag is: Is het ook een emergency landing? In my opinion is dit een precautionary landing. Van een emergency landing is alleen sprake als je naar de grond MOET, wat wil zeggen -> geen motoren. Een precautionary landing is een landing met engine power.
Zo wordt het in de luchtvaart gebruikt.
Uiteraard is dat compleet onafhankelijk van het feit of dit een emergency was! Een mayday call maakt het een emergency maar zeer zeker geen noodlanding.

Door Glashelder, dinsdag 20 december 2011 17:27

Behalve het defect aan de snelheidssensor constateerden de onderzoekers dat een algoritme in de boordcomputer die de snelheidsinformatie moet verwerken, niet in staat was om de incorrecte snelheidsinformatie van slechts één sensor op een juiste manier te verwerken

Dit is overigens ook een probleem bij Boeing (in ieder geval bij de 737). Het gaat dan alleen niet om de snelheidsmeter maar om de hoogtemeter.

Erg slordig in ieder geval en in begrijp niet helemaal dat het niet in het hoofd van de ontwikkelaars op komt om in ieder geval standaard een waarschuwing te geven als instrumenten afwijkende metingen doen. Al is dit volgens mij nu wel het geval bij de 737

Door Ximinez, dinsdag 20 december 2011 18:28

Als je de static ports of de pitot port afplakt (wat ooit is gebeurd waardoor een vliegtuig is gecrashed), wat is dan je referentie waarde om te constateren dat er een afwijking is. Zonder referentie is afwijkend gedrag niet te constateren.

Hoogte meting berust nog steeds op een zeer basaal principe. Met de komst van GPS is een extra parameter in de evaluatie mogelijk echter GPS is niet nauwkeurig in de verticale dimensie. Wel bruikbaar maar de basis is nog steeds luchtdruk en temperatuur voor de bepaling van de hoogte.

Om meteen maar te roepen dat de ontwikkelaars daar niet over nadenken is erg kort door de bocht.

Door Glashelder, dinsdag 20 december 2011 19:10

Ik verwacht ook niet dat de softwareontwikkelaars hier een oplossing voor hadden moeten bedenken. Ze hadden vanaf het begin af aan moeten doen wat ze nu doen: de piloot attenderen op de verschillende metingen. Dat daar behoefte aan is hadden ze toch wel eerder kunnen bedenken?

Door Mischa_NL, dinsdag 20 december 2011 20:37

Ik kan je mededelen dat als jij in IMC conditions aan het vliegen bent, je gevoel je heel erg in de war kan brengen zelfs als je weet dat al je instrumenten werken. Op het moment dat ze elkaar gaan tegenspreken is het erg lastig om te bepalen wat correct en incorrect is.

Door Glashelder, woensdag 21 december 2011 00:39

Is dat echt je argument om geen waarschuwing te geven dat een belangrijke instrumenten (waar je automatische piloot afhankelijk van is) tegenstrijdige waardes geven?

Het lijkt me een goede zaak dat je daar in ieder geval op geattendeerd wordt. Dan zie je maar wat je ermee doet als piloot..

Door Derice, dinsdag 20 december 2011 17:27

Tja, Airbus... die laten veel te veel door computers regelen i.t.t. Boeing.
Daar gaat men er vanuit dat de piloot nog moet kunnen vliegen als de computers 't niet meer weten.
"If it ain't boeing, I'm not going!".

Door wildhagen, dinsdag 20 december 2011 17:29

Jij denkt dat een Boeing geen computers bevat, of dat die computers geen enkele controle uitvoeren?

Newsflash: een Boeing is ook best wel volgestopt met computers, net zoals elk groot passagierstoestel tegenwoordig

En ook Boeings bevatten fouten. Iets met Turkish Airlines een tijdje geleden die neerstorte bij Schiphol. Was een Boeing, met o.a. (technische) fouten van o.a. de automatische piloot. Laat die nou net computergestuurd zijn...

De tijd dat een toestel alleen door de piloot bestuurd werd, zonder enige mechanische/electronische hulp (noodgevallen uitgesloten) ligt al tientallen jaren achter ons...

[Reactie gewijzigd door wildhagen op dinsdag 20 december 2011 17:32]

Door Derice, dinsdag 20 december 2011 17:43

Waar lees jij dat ik denk dat een Boeing helemaal geen computers bevat of geen controle uitvoeren

Aannames...

Ik vind het systeem van Airbus téveel afhankelijk van computers, er worden beslissingen gemaakt zonder dat een piloot er zich al te bewust van wordt gemaakt.
Boeing gaat er net even wat anders mee om in mijn optiek (zo limiteerd airbus bijv. standaard de maximale bank van een toestel (is uit te schakelen), goed voor de veiligheid, maar ik heb toch liever dat een piloot een goed doordachte beslissing maakt dan een computer die bepaald dat er een duikvlucht gemaakt moet gaan worden).
Ik zie dan ook liever een stuurtje dan een joystick in een cockpit.

Turkish Airlines was voor een heel groot gedeelte pilot error, die niet reageerde op waarschuwingen die (ruim van te voren) werden afgegeven doordat 1 van de hoogtemetersystemen het niet juist deed. Ding was nog prima te landen geweest zodra men correct had gehandeld en het toestel zelf aan de grond had gezet (desnoods op een veld waar het zicht beter was dan op Schiphol), de fuel was er, de skills ook, alleen de uitvoering niet.

Door kaasboer09, dinsdag 20 december 2011 17:58

Boeing bevat natuurlijk weldegelijk 'computers'. Groot verschil is dat Airbus de filosofie heeft dat computers het 'beter weten' dat piloten. Deze filosofie uit zich in dit geval als volgt: de piloot kan in een airbus de computer niet uitschakelen (overrulen) zoals dat wel kan in een boeing. Airbus maakt gebruik van zogenaamde laws (normal-law, alternate-law en direct-law). Deze laws geven aan in hoeverre de piloot controle heeft over het vliegtuig. Direct law wordt meestal (automatisch) geactiveerd als het toestel zich in een ongewone situatie bevindt. Klinkt natuurlijk alsof de piloot in direct law volledige en directe controle heeft over het vliegtuig maar niks is minder waar. Bovendien kan de direct law niet zomaar handmatig geactiveerd worden. Dus als hij in de normal-law blijft zal de computer voorkomen dat het toestel voorbij zijn operational limits gestuurd wordt (dus geen 'gekke' dingen doen zoals loopings, stalling etc). Als een snelheidsmeter aangeeft dat je te langzaam vliegt, wilt de boordcomputer voorkomen dat je gaat stallen. Resultaat: emergency decent. Oftewel een duikvlucht waarbij je ogen uit je schedel worden gedrukt.

Dit is dus NIET het geval bij een boeing. Een boeing geeft alleen (erg overtuigende) waarschuwingen. Maar laat de uiteindelijke beslissing over aan de piloot. (het systeem grijpt wel in maar dit kan altijd overruled worden)

EDIT: En wat betreft het turkish airlines hoogtemeter incident; het probleem daar was dat het toestel slechts 2 radiohoogtemeters bevatte. Als één stuk is, weet het algoritme niet welke stuk is en welke niet. In dat geval gaat het systeem uit van het slechtste scenario (dus die de laagste hoogte aangeeft) In het geval van airbus hoogtemeters zijn er 3 aanwezig. Als ééntje stuk is hoort een juist geprogrammeerd algoritme te beseffen dat twee identieke waarden (van de werkende meters) de juiste zijn. Maar dit was dus hier niet echt het geval denk ik ...

[Reactie gewijzigd door kaasboer09 op dinsdag 20 december 2011 18:09]

Door SanderHG, dinsdag 20 december 2011 18:04

Direct law wordt meestal (automatisch) geactiveerd als het toestel zich in een ongewone situatie bevindt. Klinkt natuurlijk alsof de piloot in direct law volledige en directe controle heeft over het vliegtuig maar niks is minder waar.

Je haalt de 'normal law' en de 'direct law' door elkaar.

Tijdens 'normal law' zijn inderdaad die berschermingen ingebakken die niet te overrulen zijn door de vlieger.

Bij 'alternate law' valt de pitch bescherming en de roll bescherming weg, alleen de low speed, high speed, load factor limitation en yaw demping blijven actief. Je kan in alternate law dus een barrel roll doen mocht je daar zin in hebben (lijkt me niet handig).

Tijdens 'direct law' zijn er geen enkele beschermingen meer, het is dus feitelijk een Boeing geworden. Hij gaat bijvroorbeeld in direct law als alle (verschillende) fly-by-wire computers niet meer werken. De control inputs worden rechtstreeks doorgegeven aan de flight controls. In direct law kan je dus wel degelijk het vliegtuig over z'n operating limits heen krijgen.

[Reactie gewijzigd door SanderHG op dinsdag 20 december 2011 18:11]

Door kaasboer09, dinsdag 20 december 2011 18:26

Ja, maar probeer maar eens een barrel roll als je het systeem niet in direct law krijgt... Daar ligt het probleem.. het zijn geen computersystemen die falen. Het was een hoogtemeter dus het systeem zag geen aanleiding om naar alernate law of direct law te gaan. Maar misschien ik heb het inderdaad een beetje onzorgvuldig geformuleerd

Door SlasZ, dinsdag 20 december 2011 19:44

Allemaal goed en wel maar dan moeten de piloten wel op de hoogte zijn van die verschillende 'laws'. Blijkbaar was dat een van de oorzaken van de Air France crash in 2009: http://www.popularmechani...ance-447-6611877?page=all
Andere waren natuurlijk weersomstandigheden, geen duidelijke command structure en pech

Door SanderHG, dinsdag 20 december 2011 21:19

Al die laws hoor je als piloot van op de hoogte te zijn ja, hoort allemaal bij de typerating die je moet halen om op een bepaald vliegtuig te mogen vliegen

Door worldcitizen, dinsdag 20 december 2011 19:11

Dit is dus NIET het geval bij een boeing. Een boeing geeft alleen (erg overtuigende) waarschuwingen. Maar laat de uiteindelijke beslissing over aan de piloot.

Naar aanleiding van je reactie. Ik heb je strekking verkeerd begrepen.
IMO kijk je door een erg rose bril c.q. wat veel Nederlanders hebben wat uit de VS komt is goed wat uit Nederland / Europa komt niet.

Kijk ook even naar deze link.
nieuws: FAA: Boeing 787 Dreamliner gevoelig voor hackers

En een reportage over de A380 kijk tot het einde c.q. mis de laatste minuten niet. Daar wordt het waarde oordeel over de A380 gegeven.
Qantas A380 pilot speaks about 'finest landing'.

Ik denk dat alle vliegtuigbouwer zo goed mogelijk vliegtuigen proberen te bouwen.

[Reactie gewijzigd door worldcitizen op dinsdag 20 december 2011 23:51]

Door kaasboer09, dinsdag 20 december 2011 19:43

Ik heb nergens een waardeoordeel gegeven volgens mij.. Ik ben juist voorstander van de Airbus-filosofie. Ook ik heb minder vertrouwen in mensen dan in computers. Ik denk dat het fly-by-wire law systeem zichzelf dubbel en dwars heeft bewezen. De menselijke piloot zit op zijn operationele top. Bij computers zijn de haalbare groeimogelijkheden nog erg groot (misschien zelfs oneindig groot). Een combinatie van de twee lijkt op het eerste gezicht misschien de beste oplossing maar de recente vooruitgangen zijn te groot om de noodzaak van stevigere integratie te onderkennen als volgende stap. Bovendien heeft Boeing zijn filosofie meer bijgesteld richting Airbus dan andersom (dreamliner, of nieuwe generatie B777, etc). "

Door S0epkip, dinsdag 20 december 2011 21:58

Hoe wil je oneindige groeimogelijkheden van computers definiëren?

Door kaasboer09, woensdag 21 december 2011 12:33

Gedefinieerd als dat ik voorlopig nog geen beperkingen zie voor computers waarin zij de piloten zouden kunnen vervangen. Ethisch gezien is het voorlopig nog ondenkbaar maar dat zal veranderen naar mijn mening. Het merendeel van de crashes tegenwoordig wordt veroorzaakt voor human error als response op een "non-normal" situatie.

Door ChicaneBT, dinsdag 20 december 2011 17:30

Dat is een standpunt wat je kunt innemen. Je kunt ook stellen dat als er iets misgaat in een Boeing de piloot te veel handelingen moet uitvoeren en daardoor het overzicht sneller verliest.

Door foobar79, dinsdag 20 december 2011 17:40

Ja, maar deze fout is er nu wel voor altijd uit.

In tegenstelling tot een piloot, die kan altijd zijn dag niet hebben en een miscalculatie maken.

Veel mensen maken een onrealistische vergelijking:
Een automaat mag onder geen geval een fout maken terwijl dat bij een mens makkelijker wordt geaccepteerd.

Door Navi, dinsdag 20 december 2011 17:45

En die automaat is geprogrammeerd door mensen..

Dus als de automaat het fout doet, is dat ofwel een hardwarematig defect waardoor hij het niet goed kan doen, of een softwarefout wat dus uiteindelijk weer menselijk is.

Door S0epkip, dinsdag 20 december 2011 17:57

En hoe ontstaat die hardwarefout dan? Daar is zeker geen invloed van de mens geweest...?

Door Navi, dinsdag 20 december 2011 18:48

Als je doorzoekt kom je daar meestal wel uit ja, bijvoorbeeld door slecht onderhoud of matige controle.

Hoewel het doorbranden van elektronica onverwachts kan gebeuren.

Door furby-killer, dinsdag 20 december 2011 18:55

Uit mijn hoofd zijn veruit de meeste vliegrampen toch echt gebeurd door menselijk falen, dan kan je beter een computer het laten doen. Vreemd genoeg echter wordt van een computer ineens verwacht dat hij 100% juist geprogrammeerd is en er mag absoluut geen enkele fout in zitten, en anders moet een mens (piloot) het maar doen, terwijl die een hoop meer fouten maken.

Door drib83, dinsdag 20 december 2011 20:32

Klopt, de laatste tientalen jaren blijft het aandeel menselijke fouten (zowel direct als indirect) rond de 70% bij ongevallen met vliegtuigen, en dit cijfer blijkt te stagneren.

Door S0epkip, dinsdag 20 december 2011 22:00

Op zich heb je een punt, de oosterscheldekering wordt ook niet voor niets door een computer (BOS) gestuurd, mensen worden o.a. gedreven door emotie, kunnen vermoeid raken, etc.

« 1 2 3 4 5 »

Op dit item kan niet meer gereageerd worden.

18:10	Archos brengt budget-tablet onder eigen naam uit
16:58	Simpel koppelt prijs databundel los van belminuten

Nieuws I/O

Shortcuts

Categorieën

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

27-05 Nieuws

07:28 Productreviews

08:05 Vraag & Aanbod

25-05 Jobs

20:30 Etc.

07:44 Reacties

08:05 Forum

25-05 Gesponsorde acties

01:46 Tweakblogs

26-05 Computable headlines

25-05 CRN headlines