Boeing 787 moet gereboot worden om te beschermen tegen integer overflow

De Boeing 787 Dreamliner heeft een tamelijk opvallende softwarebug. Er ontstaan problemen als de systemen van het vliegtuig niet eens per 248 dagen worden 'gereboot'. Als dat niet gebeurt kunnen de elektrische generators uitvallen.

The Guardian meldt dat de Amerikaanse luchtvaartautoriteiten een waarschuwing hebben uitgegeven. Er zit namelijk een probleem in de vier elektrische generators die de Boeing 787 aan boord heeft. Als zij meer dan 248 dagen achter elkaar ingeschakeld staan kunnen ze naar een 'failsafe mode' overschakelen en dat betekent dat alle elektriciteit in het vliegtuig uit kan vallen. Uiteraard kan dat catastrofale gevolgen hebben als het vliegtuig op dat moment in de lucht hangt.

Dat er na 248 dagen problemen optreden heeft waarschijnlijk te maken met een 32-bit-integer overflow. Omgerekend naar het aantal honderdsten van seconden wordt bij 248,55 dagen namelijk het aantal van 2³¹ overschreden. Overigens heeft Boeing niet bevestigd dat een integer overflow de oorzaak van het probleem is.

Er is een tijdelijke oplossing, en die is tamelijk simpel: het systeem moet namelijk gereboot worden. Zolang er af en toe opnieuw opgestart wordt is de Dreamliner veilig om te gebruiken, zo luidt het oordeel van de luchtvaartautoriteiten. Boeing meldt dat het zijn vliegtuigen inmiddels allemaal een keer uit en weer aan heeft gezet.

Tot het vierde kwartaal van dit jaar moeten vliegtuigmaatschappijen hun Dreamliners nog rebooten. Daarna moet een softwareupdate uitkomen die het probleem permanent repareert. Of die update over-the-air binnenkomt is niet duidelijk.

Boeing 787 Dreamliner

IT-banen

Reacties (239)

JeroenH 3 mei 2015 11:10

Ik heb dit bericht al talloze malen gekopieerd zien worden, zonder enige toevoeging aan het oorspronkelijke bericht, en nu ook hier op Tweakers. Prima, dat is het internet anno 2015.

Wat ik echter nergens terug kan vinden is hoe groot dit probleem in de praktijk is? Ik neem aan (maar weet niet zeker) dat vliegtuigen eens in de 248 dagen wel eens een keertje uitgezet worden en geparkeerd staan. Of is het een specifiek systeem dat "up" blijft? Dergelijk informatie zou ik wel eens van iemand met kennis van zaken willen horen.

EDIT

@JeroenH • 3 mei 2015 13:03

Ik ben dan weliswaar geen piloot en heb al helemaal geen kennis van vliegtuigen (ik weet nog net dat die dingen schijnen te kunnen vliegen), maar als ik kijk naar moderne treinen dan worden de systemen daarvan maar zeer zeer zelden echt uitgezet of opnieuw opgestart.
Bijvoorbeeld de sprintertreinen van het type SLT zijn rijdende computersystemen en worden wel regelmatig in een sluimerstand gezet waarin dingen als verlichting, infotainment-systemen en ventilatie/verwarming uit staan, maar de mainframe gewoon aan blijft staan, samen met dingen als een compressor voor het op peil houden van de luchtdruk in de leidingen en een omzetter voor het laden van de batterijen. Slechts zeer zelden krijgt dat systeem een volledige "shutdown" (in een wat morbide term wordt die systeemstatus ookwel "dood" genoemd). Sterker nog, zelfs als bijvoorbeeld een stroomafnemer omgewisseld wordt (dus er geen hoogspanning meer geleverd wordt aan de trein) blijft dit systeem gewoon actief met voeding van de batterijen.
Ook bij bijvoorbeeld de periodieke controles blijven deze systemen draaien (uiteraard worden de systemen wel gecontroleerd op goede werking).
Ik kan mij dus voorstellen dat er bij vliegtuigen ook systemen zijn die eigenlijk vrijwel nooit uitgezet worden. Als dit onderdeel van zo'n systeem is, dan lijkt het mij mogelijk dat dit theoretisch wel degelijk een probleem zou kunnen vormen.

[Reactie gewijzigd door EDIT op 23 juli 2024 19:06]

Unimproved @EDIT • 4 mei 2015 00:27

Heb zelf nog geen dreamliner gezien, maar de 737s gaan gewoon helemaal uit. Na de laatste vlucht van de dag vraagt de checklist ook om standby power en batteries te ontkoppelen.

Tozz @Unimproved • 4 mei 2015 09:23

Maar hoe vaak gebeurt dat? Er zijn ook vliegtuigen die gewoon nagenoeg constant in de lucht hangen. bv. de KLM vlucht van Amsterdam naar Aruba en terug is een vlucht van 11 uur die gewoon rondjes vliegt met een andere crew.

Dus het is zeker niet zo dat alle vliegtuigen na een dag allemaal stil staan.

Unimproved @Tozz • 4 mei 2015 11:07

Hier vliegt vaak niet hetzelfde toestel (aankomst van Aruba gaat vandaag naar New Delhi) en vaak blijft het toestel op de grond enkele uren wachten ivm tijdzones.

En anders gebeurt dit zeker tijdens de B-check (elke 6 maanden) waarbij het toestel in de hangar overnacht.

Anoniem: 57381 @Unimproved • 5 mei 2015 21:55

Lijkt me beter dat ze dat rebooten niet met alle generators tegelijk doen. Anders neemt de kans dat ze tegelijk uitvallen toe. Die dingen zijn redundant uitgevoerd. Dus 1 uitvaller is nog geen probleem (maar wel een goede waarschuwing), alle 4 wel....

Ook kunnen ze beter het software development proces eens onder de loep nemen. Zoiets had gezien moeten worden.

Unimproved @Anoniem: 57381 • 5 mei 2015 22:42

De 787 heeft er 6, waarvan 4 in de motoren. Mochten deze uitvallen kan alsnog de APU gebruikt worden.

En zlefs al zouden ze alle 6 uitvallen, het toestel heeft batterijen en kan in de lucht ook gewoon gereboot worden.

cedal

@EDIT • 3 mei 2015 19:38

Kleine toevoeging op je verhaal: moederborden van PC's gaan ook niet helemaal uit. Deze hebben ook een batterij (penlite) aan boord om een geheugenchip op spanning te houden...

Edit: Thanks mgeevers, natuurlijk geen penlite maar een knoopcel

[Reactie gewijzigd door cedal op 23 juli 2024 19:06]

fantafriday @cedal • 3 mei 2015 23:19

Cmos-ram van de bios word daarmee inleven gehouden

fiepfiep @fantafriday • 4 mei 2015 00:18

om gegevens zoals de tijd en bios settings in te bewaren!

db I Delirium @cedal • 3 mei 2015 19:56

Meestal een knoopcel, cr2032

Room42 @EDIT • 3 mei 2015 19:04

Ik ben dan weliswaar geen piloot en heb al helemaal geen kennis van vliegtuigen (ik weet nog net dat die dingen schijnen te kunnen vliegen),

Ze kunnen helemaal niet vliegen. Je moet ze hartstikke hard door de lucht gooien en op snelheid houden, willen een beetje op hoogte blijven. Dat kost gigantisch veel kerosine.

Vogels kunnen vliegen!

[Reactie gewijzigd door Room42 op 23 juli 2024 19:06]

geerttttt @Room42 • 4 mei 2015 10:26

Ben ik de enige die het grappig vind dat de update wellicht over-the-air komt?

trogdor @geerttttt • 4 mei 2015 10:35

Ja. Dat is een nogal flauwe poging tot grappige punchline.

hvwees @geerttttt • 5 mei 2015 10:22

Ik zag hem ook... En dacht grin..

Rico1984 @geerttttt • 5 mei 2015 21:38

Ik dacht al tijdens het lezen van de comments, wie begint er over!! Ik vond m ook best goed eigenlijk (grote grijns).

NMe @Room42 • 4 mei 2015 01:25

Ja, want vogels hoeven daar inderdaad geen energie in te stoppen, gaat vanzelf.

84hannes @NMe • 4 mei 2015 10:21

offtopic:
Afgezien van vogels die niet kunnen vliegen (kippen) of nauwelijks kunnen vliegen (als ik een eend zie opstijgen heb ik hetzelfde gevoel als bij een 20 jaar oude Fiat Panda op de snelweg: okay, het kan, het mag, maar het lijkt e rniet voor bedoeld) zijn vogels een stuk energieefficienter dan lijnvliegtuigen. Zweefvliegtuigen, die weten goed met hun energie om te gaan. Straaljagers zijn nog erger, maar als we niet zoveel haast hadden zou je een vliegtuig kunnen ontwerpen dat meer draagkracht heeft en minder energie per kg per km gebruikt, maar dan duurt het ons reizigers allemaal te lang. Ik weet echter niet of vliegtuigen en straaljagers daarmee niet kunnen vliegen, alleen omdat ze niet zo goed als arenden zijn in zweven.

Sylph-DS

@84hannes • 4 mei 2015 17:10

http://en.wikipedia.org/wiki/Gossamer_Condor anyone? Vliegen op een boterham met pindakaas

bogy @NMe • 4 mei 2015 12:44

dat klopt ... vogels kunnen zonder energie op thermiek vliegen ... dat kan een vliegtuig niet.... een zweefvliegtuig kan het enigzins.

trogdor @Room42 • 4 mei 2015 10:34

Een helium balon kan vliegen, een vogel moet hardstikke hard met zijn vleugels slaan en dat kost gigantisch veel rupsen.

P_Tingen @Room42 • 4 mei 2015 14:12

Mensen kunnen wel vliegen volgens Douglas Adams: flying is learning how to throw yourself at the ground and miss.

Het is alleen verhipte moeilijk (check)

Remie @JeroenH • 3 mei 2015 11:16

Met je eens, heb ooit gezien dat bij de first checks op discovery al vrij snel een reboot wordt gedaan na de eerste check omdat bij het opnieuw opstarten alles nog een x wordt getest.
Maar helaas kan ik hier geen zekere uitspraken over doen.

Ben erg benieuwd of er een Dreamliner Piloot op tweakers rondzwerft of anders een Boeing monteur?

Double-X-L @Remie • 3 mei 2015 12:39

Ik ken de intervals en systemen niet op de Dreamliner, maar in de 12 jaar dat ik bij Transavia heb gewerkt aan de 737's is bovenstaande situatie van 255 dagen ondenkbaar.
De turnarounds zijn inderdaad kort maar de inspecties en smeer intervallen in de hangar maken een dergelijke situatie vrijwel onmogelijk. Dan heb je nog de dagelijkse overnights waarbij het vliegtuig in de meeste gevallen 'dood' wordt gemaakt.

Het enige wat ik dan zou kunnen bedenken is dat de kist nooit helemaal op zwart gaat maar op de zgn. 'Ground service' modus. Daarbij blijft er spanning op voor verlichting voor schoonmaak en/of onderhoud in cabine waarbij geen andere systemen nodig zijn.
Die spanning wordt normaliter extern aangeleverd middels een GPU (Ground Power Unit). Daarbij zou het software deel van de Dreamline generatoren dus actief moeten blijven. Zelfs in die situatie lijkt het mij zeer onwaarschijnlijk om de kist niet binnen 255 dagen minimaal 1 keer op zwart te hebben gehad.

Nu heeft de dreamliner een behoorliijk afwijkend systeem met o.a. starter/generatoren i.p.v. separate pneumatische starters en generatoren, maar bovenstaande situaties wanneer de kist aan de grond staat, lijkt mij globaal hetzelfde. De Dreamliner zal eerder een vorm van spanning over zijn GCU's (Generator Control Units) hebben/houden om een engine start te kunnen initieren, dit is bij de 737 pneumatisch waarbij de motoren een x toerental moet hebben alvorens de generatoren online gezet, en dus gebruikt, kunnen worden. Dit wordt ook gedaan door die GCU's maar die doen niks in ground service, wel tijdens de pneumatische engine start cyclus.

Ik kan alleen niet bedenken waarom de software/aansturing hiervan tijdens ground service geactiveerd blijft. Het zou betekenen dat deze systemen direct aan de zgn 'HOT BAT BUS' zijn gehangen en ook gedurende ground service actief blijven.
Wellicht is het geintergreerd in 1 Control unit voor alle power modes??

Binnen die 255 dagen kan ik mij ook niet voorstellen dat hij niet minimaal 1 smeer interval tegen gaat komen voor de mechanisch delen waarvoor hij de hangar in zou moeten. Dan moet zo'n kist naar binnen en wordt hij gesleept met een trekker en heeft de kist spanning van de APU (Aux. Power Unit, aparte motor met generator in de staart). Die mag niet met draaiende APU de hangar in gezet worden dus wordt deze voor aankomst uitgeschakeld waarna je de laatste meters op zwart gaat of BAT bus via de accu. Lijkt mij ook een moment, maar is te omzeilen door de kist met de neus naar binnen te rijden waarbij je van APU direct over kunt naar GPU power in de hangar of via genoemde BAT bus naar GPU.

Het lijkt mij dan ook eigenlijk zo goed als onmogelijk om 255 dagen lang niet op zwart te gaan, of je moet daar om een andere reden heel bewust rekening mee houden. Als die reden zou zijn om andere issues te voorkomen wordt het lijstje weer iets langer.

[Reactie gewijzigd door Double-X-L op 23 juli 2024 19:06]

Stoney3K @Double-X-L • 3 mei 2015 13:09

(heel technisch verhaal)

Als die generator-sturing op de noodbatterijen is aangesloten (de HOT BAT BUS zoals jij aanhaalt), wat me alleen logisch lijkt als ze ook ingezet worden als ram-air turbines, dan wordt het 100% koud starten van die units ook een stukje lastiger.

Ik weet niet of er voor die bus namelijk schakelaars of circuit-breakers voorzien zijn in de cockpit, of dat de kist dan de hangar in gesleept moet worden en de batterijen fysiek moeten worden losgetrokken.

Als het niet zo is, dan is de kans dat een kist langer dan 248 dagen achter elkaar op spanning blijft te staan inderdaad behoorlijk klein. Vroeg of laat zal ie ergens worden geparkeerd voor onderhoud of een schoonmaakbeurt.

[Reactie gewijzigd door Stoney3K op 23 juli 2024 19:06]

Double-X-L @Stoney3K • 3 mei 2015 13:36

True, ik denk dan ook dat het een minimale stuurstroom zal zijn om ze bij te zetten of dat ze alsnog een control/monitor functie houden, maar er blijft dus iets actief waardoor er geen reboot wordt gedaan.

Daarom stel ik ook:

Wellicht is het geintergreerd in 1 Control unit voor alle power modes??

Als diverse controllers of delen samengevoegd zijn (GCU's-BPCU-AGCU-SPCU en misschien zelfs SPCU) tot 1 master ELEC control unit dan zal daar altijd spanning op blijven, ook gedurende ground service. Vanuit 737 perspectief incl overzicht van genoemde afkortingen, zie pagina 7 van het 737 schema.
Hierbij zijn de IDG's de generatoren aan de motor.

De Dreamliner heeft 4 generatoren (5 incl APU) dus een dubbele centrale aansturing ipv 4 separate lijkt mij niet ondenkbaar en ook hier terug te zien in de vorm van remote power distribution units.

Ik kan mij voorstellen dat die zo goed als altijd online blijven en die zelfs via CB's (Circuit Breaker) gereset zouden moeten worden.

Ik benader het vanuit mijn ervaring met een ander type en kan van daaruit verder niks verzinnen waardoor ze een dergelijke termijn zonder reboot kunnen doen.
Zodoende kan ik je dus ook niet vertellen wat er wel en niet zit in dit type zonder alle schematics erbij te gaan pakken en laat ik daar nou net geen zin in hebben

[Reactie gewijzigd door Double-X-L op 23 juli 2024 19:06]

Tijgert @Double-X-L • 3 mei 2015 18:51

Hmm.. RPDU's... dat verzin je vast niet, da's loterij lucky. Wat doe je en waar?

Durandal @Double-X-L • 3 mei 2015 14:12

Goed en wel allemaal, maar als het zo bijzonder is hoe zijn ze er dan in de eerste plaats achter gekomen dat na 248 dagen de electriciteit uit valt?

Double-X-L @Durandal • 3 mei 2015 14:56

Zoals hierboven geschreven zou:

Ik kan mij voorstellen dat die zo goed als altijd online blijven en die zelfs via CB's (Circuit Breaker) gereset zouden moeten worden.

een optie kunnen zijn.

Ik twijfel er heus niet aan dat het gebeurt, lijkt mij prima duidelijk en aangetoond in de praktijk gedurende het operationeel zijn van de Dreamliner.
Aangezien hij sinds 2010 operationeel is, in relatief beperkte oplage, zijn er tot nu toe iets meer als 7 cycles van 248 dagen verstreken. We mogen dan toch aannemen dat het niet bij alle maatschappijen voor komt, oftewel de procedures zullen onderling verschillen. Die verschillen zullen moeten zitten in de overnights en/of onderhouds procedures waar je een reboot kunt verwachten.

De vraag die ik moeilijk vind is hoe een kist gedurende 248 dagen niet 1 keer helemaal spanningsloos wordt gemaakt. En als dat dus wel gebeurt, blijft er dan iets actief waardoor er alsnog geen reboot is.

[Reactie gewijzigd door Double-X-L op 23 juli 2024 19:06]

MSalters

Economie en maatschappij

@Durandal • 3 mei 2015 15:48

Niet zo bijzonder. De standaarden die gehanteerd worden voor safety-critical software zijn een stuk hoger. Lees de licentie van Windows maar eens: daarin staat expliciet dat het niet geschikt is voor zulke toepassingen, juist omdat de relevante standaarden niet gevolgd zijn.

Eén van de eisen is bijvoorbeeld dat alle software changes gereviewed worden, met een checklist van bekende risico's. Blijkbaar is in de eerste review over het hoofd gezien dat de integer overflow een probleem opleverde. Je kunt waarschijnlijk niet meer achterhalen waarom het toen niet als risico is geïdentificeerd. Misschien dachten de auteur en reviewers dat geen enkele vlucht 248 dagen duurde, en dat er na elke vlucht een reset zou zijn.

Waarom is het dan nu wel gevonden? Goede kans dat er ergens in de buurt van deze code een change is geweest, en dat de reviewers alsnog de overflow hebben gespot. Of iemand heeft een testscenario geschreven waarin dit ontdekt werd.

thegve @Durandal • 3 mei 2015 20:21

Testen van losse componenten, mag je aannemen. Misschien zelfs onderdelen die in heel andere toepassingen gebruikt worden.

rolandverh @Double-X-L • 3 mei 2015 17:18

Ik snap het verhaal, maar....
Aks ik kijk naar een auto (vergelijking gaat natuurlijk niet echt op, maar ik kijk er toch maar even naar), dan constateer ik dat de accu eigenlijk nooit losgenomen wordt. Autoradio, boorcomputer, motormanagement, anti-blokkeer systemen, traction control, air-bags.... al die systemen zijn vrijwel allemaal, altijd met de accu verbonden en houden dus vrijwel allemaal, altijd een vorm van 'operationeel' zijn.
De keren dat ik de klok in de auto opnieuw moest instellen, is alleen maar na het vervangen van de accu, of als ik een keer de lichten vergeet uit te doen. (als je dat tegenwoordig al lukt)

Kortom, ik geloof wel dat er systemen in een vliegtuig zitten die gewoon nooit spanningsloos komen te staan.

timmiej93 @rolandverh • 3 mei 2015 21:14

Verschil is echter dat jouw auto (op die ene keer na) altijd zelfstandig opstart, door je accu. Een vliegtuig kan opstarten door:
Met accuspanning de APU aan te zetten, en met de spanning van de APU de motoren aan te zetten;
Met grondspanning (GPU, vergelijkbaar met een stekker aan je auto) hetzelfde verhaal als met de accu;
Met perslucht. Ik weet niet precies hoe dat werkt, dat kan je beter aan experts zoals Double-X-L vragen.

Fredi @rolandverh • 4 mei 2015 04:31

Volgens mij wordt er hier dan ook gereset bedoeld en niet gereboot. Bij aan-uitdoen van de boordcomputers wordt er geboot maar de tellers worden niet op nul gezet omdat er spanning blijft opstaan. Pas wanneer je de accu loskoppelt en er dus geen spanning meer opstaat worden de systemen gereset en de tellers op nul gezet..

Franko P. @Double-X-L • 3 mei 2015 13:03

Dit is dan natuurlijk ook gewoon indekken.

Als later blijkt dat er toch op de een of andere manier 248 dagen continu systemen online zijn gehouden en er gebeurd iets met alle nare gevolgen van dien, (een crash in het ergste geval) dan kunnen ze in ieder geval zeggen dat ze het probleem wereldkundig hebben gemaakt. En dat de klant zijn onderhoud niet goed heeft uitgevoerd.

Als ze niets hadden gemeld en er was iets gebeurd dan wordt het een ander verhaal natuurlijk.

Anoniem: 475099 @Double-X-L • 3 mei 2015 17:53

Zo zie je maar hoe automatisering een probleem alleen maar complexer maakt om te begrijpen

Tijgert @Remie • 3 mei 2015 18:49

Ja hier, chefke 787 bij de enige club in NL die ze heeft

Ze worden met regelmaat 'dood' gemaakt, ruim RUIM binnen de 248 dagen.
Dit is een theoretisch probleem wat lekker wordt uitgemolken in de meest sensationele manier zoals het de media betaamt.

Dat gezegd hebbende, dankzij Tweakers weet ik waarom het zou gebeuren

timmiej93 @Tijgert • 3 mei 2015 21:16

Hoe dood als ik vragen mag? Master switch uit? Accu eruit en alles losgekoppeld? Die grote vogels zijn zo interessant

Tijgert @timmiej93 • 4 mei 2015 16:38

Op zich is de external power in de flightdeck uitschakelen en de battery uit doen al genoeg. Als de kist een of ander computer probleem heeft haalt men vaak ook fysiek de external power connectors los omdat het toch stiekem aan enkele systemen stroom levert.
Laatst nog, CDU database wou niet updaten -> stroom eraf.

kidde @JeroenH • 3 mei 2015 18:21

Wat ik echter nergens terug kan vinden is hoe groot dit probleem in de praktijk is?

Zoeken op Google levert vrij snel een artikel van NY-Times op van 3 dagen geleden:

Boeing said the problem had occurred only in lab simulation and no airplane had experienced it. Boeing said that powering the airplane down would eliminate the risk that all power generators would shut down at the same time.

Anoniem: 315662 @JeroenH • 3 mei 2015 11:18

Ja dit vroeg ik me ook al af. Het lijkt me toch niet dat een vliegtuig het hele jaar door aan staat.

Remie @Anoniem: 315662 • 3 mei 2015 11:21

Vaak genoeg gemerkt dat je je vliegveld ziet landen, er gaat voor 15 minuten een schoonmaakploeg doorheen en je mag weer boarden.
In de tussentijd staat het vliegtuig toch te draaien, het kan dus goed zijn dat een vliegtuig dat helemaal geen manco's heeft toch nog even 255 dagen staat de draaien

MSalters

Economie en maatschappij

@Remie • 3 mei 2015 16:01

Manco's of niet, het reguliere onderhoud moet elke 1000 vluchturen gebeuren. Dat maakt meteen duidelijk waarom het niet zo'n issue is. Bij het gebruik wat jij schetst (>20 uur/dag) is het onderhoud elke 50 dagen. Zelfs bij een laag gebruik van 10 uur/dag is er elke 100 dagen onderhoud. En welke luchtvaartmaatschappij gaat z'n nieuwe, zuinige 787's maar 10 uur per dag gebruiken?

ro8in @Remie • 3 mei 2015 13:13

Lijkt me dat een vliegtuig zo nu en dan wel even onderhouds beurtje krijgt.. Niet na elke vlucht nee, maar een jaar lang zo aan een stuk door vliegen lijkt me nou ook weer niet hoop ik xD

trogdor @Remie • 4 mei 2015 10:45

Ik heb nog nooit een vliegveld zien landen...

Rico1984 @trogdor • 5 mei 2015 21:49

Nee?! Moet je een keer zien, echt heel gaaf...

wildhagen

Economie en maatschappij
Luchtvaart

@Anoniem: 315662 • 3 mei 2015 11:22

Ook al staat een toestel een tijdje te wachten op bijv een nieuwe vlucht, wil dat nog niet automatisch zeggen dat alle systemen compleet uit hoeven te staan. Denk aan de APU die bijvoorbeeld gewoon stroom kan blijven leveren om bepaalde systemen online te houden om wat voor reden van dan ook.

Of dat voor de generatoren waar het hier over gaat ook opgaat weet ik overigens niet.

Blokker_1999

Economie en maatschappij

@wildhagen • 3 mei 2015 11:44

Misschien niet, maar dat betekend nog niet dat de sturing van die generatoren volledig uit gaat.

SunnieNL

@JeroenH • 3 mei 2015 11:14

In de praktijk is dit niet zo groot. Bij regulier onderhoud wordt het hele systeem al gereset.
Overigens kwam ik ergens anders tegen dat de generatoren uitgezet 1x per 248 dagen uitgezet moeten worden om dit te voorkomen. Maar mogelijk dat dit een systeemreboot triggered.

jip_86 @JeroenH • 3 mei 2015 11:33

Wat er uit gaat zijn de motoren. Las ergens dat de kans groot is dat de elektrische systemen dan gewoon blijven draaien om de airco, verlichting etc te laten werken.

sprankel @JeroenH • 3 mei 2015 23:53

Geparkeerd staat niet gelijk aan uit. Vliegtuigen worden bij aankomst met de grond gekoppeld of als hij niet aan een gate staat met een mobiele generator.
Je kan je wel inbeelden dat er tegenwoordig heel wat computers in zo een toestel zitten die vanalles en nog wat doen. Al die systemen afsluiten en opstarten kost redelijk wat tijd. Bovendien kost het ook nog extra controles om te kijken of alles wel goed is opgestart.
Of ik zal het anders zeggen, als je op de luchthaven werkt en je zet een vliegtuig even zonder stroom zal de piloot er niet mee kunnen lachen als hij toekomt. Ik heb er ooit eentje een vertraging moeten laten oplopen omdat we de stroom niet konden ontkoppelen en de piloten er nog niet waren, generator stond in de weg en valt automatisch uit als je hem verplaatst.

Zolang dat het vliegtuig in roulatie zit word er niets gereboot tenzij het nodig is. Bij onderhoud is dat een paar andere mouwen, en vliegtuigen hebben gigantisch veel onderhoud nodig op heel regelmatige basis. Maar bij een klein onderhoud zou het mij niet verbazen dat er geen echte reboot is geweest.

Maar met 248 dagen is hij al redelijk veel op onderhoud geweest en dat maakt de kans heel klein, maar dat is de luchtvaart, veiligheid boven alles. Het moet maar 1 keer fout gaan en het hek is van de dam. En als dit probleem de reden van het ongeluk zou zijn is, dat wil je echt niet gaan uitleggen aan de overlevende families. En dan heb je nog de verzekering, geloof mij, verzekeringen in de luchtvaart is nog iets anders dan de verzekering dat je gewoon bent omdat het bij het minste over gigantische bedragen gaat.

lllustrious @JeroenH • 3 mei 2015 15:40

Ik zou ook wel willen weten hoe ze er eigenlijk achter zijn gekomen? Niet dat ik veel verstand heb van software...

boontje1994 @JeroenH • 4 mei 2015 03:26

Het ergste wat zou kunnen gebeuren is dat de piloot geen controle meer heeft over z'n vliegtuig. De Dream)Liner is uitgerust met een fly-by-wire systeem wat stroom nodig heeft. Mochten de generatoren tegelijk uitvallen kan er nog even worden doorgewerkt op de accu's maar die blijven het ook niet uren volhouden, evt kan er nog een RAT(ram air turbine) worden ingezet maar onder een bepaalde airspeed levert deze niet meer genoeg kracht om alles bestuurbaar te houden.

dmantione 3 mei 2015 11:06

Een integeroverloop is niet hetzelfde als een bufferoverloop?

pe1dnn @dmantione • 3 mei 2015 12:22

Nee. Bij een buffer overloop kom je buiten het aan het buffer toegewezen gebied en overschrijft je dus gegevens die achter het toegewezen gebied liggen.

Bij integer overflow wordt een getal zo groot dat je een deel van de waarde verliest. Neem een 2 bit integer en ga tellen 00, 01, 10, 11. Als je nu nog 1 getal verder wil krijg je 100, maar er zijn maar 2 bitjes, dus staat de teller weer op 00. Je telt dus 0, 1, 2, 3, 0... Tot 4 tellen is niet mogelijk.

Nou zou dit geen probleem zijn, want 00 is ook waar hij mee begin na een reset en dus een geldige waarde. De hypothese hier is dat het om een signed integer gaat. Daar wordt het bovenste bitje gebruikt om aan te geven of het een positieve of negative waarde heeft. Dan tel je dus 00, 01 en dan gaat het mis want de volgende is 10. In two's complement is dat -2. Dus 0, 1, -2...

Die -2 wordt niet verwacht, de software ontspoort en de beveiliging grijpt is en brengt het systeem in een veilige toestand zodat het apparaat geen gekke dingen kan doen.

Dit voorbeeld gebruikt 2 bits, in dit geval gaat het over 32 bits, dus de overgang van (hex)
0x7FFFFFFF naar 0x80000000 oftewel van decimaal 2.147.483.647 naar -2.147.483.648.

Durandal @pe1dnn • 3 mei 2015 14:14

Alleen is die safe mode dus niet zo safe (alle electriciteit uit -> toestel gaat neer), dus daar is ook nog wat werk te doen.

johnkeates @Durandal • 3 mei 2015 15:51

Nouja, als je in safe mode een complete operationele mode gaat implementeren moet je daar ook weer een safe mode overheen zetten. Safe mode in dit soort apparaten (vliegtuigen) is anders dan consumenten-safe-mode, waarbij dingen werken, maar met gereduceerde functionaliteit. Safe mode betekent ook echt safe mode: er mag niks verkeerd gaan.

De software die sowieso al draait is al verschrikkelijk betrouwbaar gebouwd, dus als er daar dan iets mis gaat mag je er van uit gaan dat een safe mode geen functionerend apparaat hoeft op te leveren, maar er alleen voor hoeft te zorgen dat er niemand dood gaat.

bogy @johnkeates • 4 mei 2015 13:05

ok ...
safe mode: we leggen de motoren stil; dan kan er niemand sterven...

hmmz ... nu zijn we safe; we vallen omlaag ... (ttz, we zijn veranderd in een zweefvliegtuig)

johnkeates @bogy • 4 mei 2015 14:03

Het gaat over generatoren he. De safe mode voor motoren zal ongetwijfeld anders zijn.

pe1dnn @Durandal • 4 mei 2015 13:35

Alleen is die safe mode dus niet zo safe (alle electriciteit uit -> toestel gaat neer), dus daar is ook nog wat werk te doen.

Het is de beste optie. Jij weet nu wat er stuk is en dat het gewoon had kunnen werken, maar op het moment dat de software geen idee meer heeft in wat voor toestand het te controleren apparaat zich bevind dan wordt het moeilijk. Want als je het zo maakt zoals jij zegt dan gaat het ding misschien elektriciteit maken terwijl er ergens een forse kortsluiting is. En dan had je gezegd: had jezelf maar uitgeschakeld.

Het is dus nooit goed en platleggen is de beste optie, zeker omdat er normaal backups zijn die het over kunnen nemen. Maar omdat het hier een harde fout is, treft dit net zo hard de backups en heb je in dit geval een probleem.

Andere mogelijkheid zijn 3 controllers die alle 3 volkomen onafhankelijk van elkaar gemaakt zijn; als er dan 1 een fout meld maar de andere 2 niet dan kun je afgaan op een meerderheidsstem. Dat wordt gedaan in de ruimtevaart met board computers. Uiteraard moet het tellen van "stemmen" dan wel goed werken. Maar dan moet je natuurlijk ook niet dezelfde bibliotheek functies of een gemeenschappelijk OS gebruiken. Met de huidige complexiteit is kruisbestuiving praktisch niet te voorkomen en heb je dus wel weer gemeenschappelijke code die collectief kan falen...

elect-ron @pe1dnn • 3 mei 2015 19:10

Tot vier tellen is dus onmogelijk. Vergeet niet de root. 0 = 1 en 3 = 4

elect-ron @elect-ron • 7 mei 2015 20:09

Jullie zeggen:

0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8

Ik zeg:

000 = 1
001 = 2
010 = 3
011 = 4
100 = 5
101 = 6
110 = 7
111 = 8

Snow_King

3 mei 2015 11:06

Ik zou eigenlijk verwacht dat deze moderne systemen ook dáár al 64-bit zouden zijn? Iemand die hier iets meer van weet waarom het niet het geval is?

stappel_ @Snow_King • 3 mei 2015 11:15

NetBSD is pas sinds 2012 over op 64bits ipv signed 32-bit time_t integer.
Veel systemen draaien een afgeleide van NetBSD. Ook bijvoorbeeld storage controllers.

johnkeates @stappel_ • 3 mei 2015 12:19

Storage controllers draaien volgens mij nog steeds op RT embedded systemen zoals VxWorks

Net als veel vliegtuigen vaak doen.

Stoney3K @johnkeates • 3 mei 2015 13:18

Storage controllers draaien volgens mij nog steeds op RT embedded systemen zoals VxWorks Net als veel vliegtuigen vaak doen.

In de luchtvaart wordt zelfs veel gebruik gemaakt van microcontrollers en ASICs die nog op 8-bits instructiesets draaien.

Waarom? Vaak is er ook niet veel meer nodig, voor bijvoorbeeld de uitlezing van een motortoerental in de cockpit heb je aan een resolutie van 8 bits (248 stappen, plus wat overhead) meer dan genoeg, want dat geeft je een uitlezing die op een half procent nauwkeurig is.

Niet alleen kosten kleinere chips minder gewicht, het betekent ook dat je software simpeler wordt en er dus minder functies door bugs fout kunnen gaan.

In de luchtvaart moet elke functie én elke fout-toestand uitgebreid worden getest en gecertificeerd, dus dan duurt het certificeringsproces een stuk korter als je met minder toestanden werkt -- een 8-bits register heeft maar 255 toestanden, terwijl een 64-bits register er véél meer heeft.

Tijgert @Stoney3K • 3 mei 2015 18:55

Waarom? Vaak is er ook niet veel meer nodig, voor bijvoorbeeld de uitlezing van een motortoerental in de cockpit heb je aan een resolutie van 8 bits (248 stappen, plus wat overhead) meer dan genoeg, want dat geeft je een uitlezing die op een half procent nauwkeurig is.

Een half procent is bij lange na niet genoeg.
Toerentallen worden gemeten in honderdsten procenten en gepresenteerd in tienden.

Stoney3K @Tijgert • 3 mei 2015 21:37

[...]

Een half procent is bij lange na niet genoeg.
Toerentallen worden gemeten in honderdsten procenten en gepresenteerd in tienden.

Dat was ook maar een voorbeeld hoewel het niet helemaal juist is natuurlijk. Er zijn genoeg waarden waarvan je makkelijk alle relevante informatie in 8 bits kwijt kan (een simpel aan-uit bitje bijvoorbeeld).

Als piloot heb je er niet altijd bijzonder veel aan om je toerentallen in procentpunten af te lezen. Zo nauwkeurig kun je de motoren namelijk toch niet sturen, tenzij je handen precies genoeg zijn om die gashendel op de tienden van graden nauwkeurig te zetten.

bogy @Stoney3K • 4 mei 2015 13:09

jij niet, maar de autopiloot kan dit wel, en je wil wel kunnen nakijken of die correct vliegt (en dus de systemen nog correct werken)

Stoney3K @bogy • 4 mei 2015 14:44

jij niet, maar de autopiloot kan dit wel, en je wil wel kunnen nakijken of die correct vliegt (en dus de systemen nog correct werken)

Die haalt zijn gegevens ook niet van de aanduiding in de cockpit, maar van een instrument-computer die wél met nauwkeuriger waarden werkt.

Tijgert @Stoney3K • 4 mei 2015 16:42

Als piloot heb je er niet altijd bijzonder veel aan om je toerentallen in procentpunten af te lezen. Zo nauwkeurig kun je de motoren namelijk toch niet sturen, tenzij je handen precies genoeg zijn om die gashendel op de tienden van graden nauwkeurig te zetten.

Als je een trend goed wilt kunnen zien moet je juist in groot detail de procenten kunnen zien veranderen. Haperingen daarin kunnen vroegtijdig aanduiden dat er een probleem gaat komen.

Ook om tijdens de vlucht te kunnen zien of er gas bij of af gaat, om te zien of en hoe hij reageert heb je de resolutie van tienden procenten wel nodig. Althans, ik vind het heel fijn en zou me bijzonder ergeren aan springende cijfers en nalden.

MSalters

Economie en maatschappij

@Stoney3K • 3 mei 2015 16:21

Ik denk dat je niet eerder met zulke validatie-software hebt gewerkt? 255 toestanden is al onhandig veel, en 4 miljard onhandelbaar. Maar dat is niet het aantal toestanden wat uitmaakt. Verificatie-software kijkt naar wat de software met de waardes doet. Als jij een test "if X < 10 or X > 20" hebt, dan heb je 3 toestanden voor X: kleiner dan 10, groter dan 20 of er tussen in. Oók als X een 64 bits waarde heeft. Alleen hierdoor is formele validatie mogelijk.

joker1977 @MSalters • 4 mei 2015 18:53

Wat als X nu true is ? Of undefined? Of "0xD" ? Of 3i ? Of "52.444E, 16.883N, 3000ft" ?

MSalters

Economie en maatschappij

@joker1977 • 4 mei 2015 23:55

Maakt zo goed als niets uit. "true" is een boolean, dus twee states. "Undefined" is 1 extra state. 0xD is hexadecimale notatie; notatie is relevant. 3i is een complex getal? C.q. 0 + 3i? Dat is simpelweg een paar van getallen, en state combineert. Zelfs een triplet x,y,z is niet bijzonder.

Stoney3K @MSalters • 5 mei 2015 22:04

Maakt zo goed als niets uit. "true" is een boolean, dus twee states. "Undefined" is 1 extra state. 0xD is hexadecimale notatie; notatie is relevant. 3i is een complex getal? C.q. 0 + 3i? Dat is simpelweg een paar van getallen, en state combineert. Zelfs een triplet x,y,z is niet bijzonder.

Het maakt natuurlijk wel uit, als je een 'true + 3i' in de test 'if X < 10 or X > 20' gaat stoppen.

Dat binnen het functioneren van de software zelf nu X netjes binnen het integer-bereik blijft en je dus maar 3 beslissings-toestanden kent, wil niet zeggen dat dat in de hardware-implementatie ook zo is.

Wat nu als er een programma iets anders schrijft door bijvoorbeeld een buffer overflow of een hardwarematig defect? Hoe vangt je software dan af dat je 'true + 3i' niet in die conditie kan stoppen? Daarom zie je in de luchtvaart ook vaak strong typing (bij voorkeur zelfs in de programeertaal) en zwaar gebruik van checksumming.

Dat gedrag moet je dus ook vastleggen, samen met de risico's. Je kan probleemloos een FMEA maken van programma's die je zelf hebt geschreven met het gedrag dat je ervan verwacht, maar wat doe je met een programma waar je een zootje random bits op afvuurt? Want dat levert je heel veel onvoorspelbare (en mogelijk gevaarlijke) toestanden op als je daar niet op berekent.

[Reactie gewijzigd door Stoney3K op 23 juli 2024 19:06]

MSalters

Economie en maatschappij

@Stoney3K • 5 mei 2015 22:56

Gelukkig zijn de meeste programmeertalen, én de verificatiesoftware slimmer dan dat. "true + 3i" is onzinnig in genoeg programmeertalen, en < is al helemaal ongedefinieerd voor complexe getallen.

Buffer overflows zijn behoorlijk triviaal voor verificatie-software. Die gebeuren namelijk pas nadat je een verificatie-probleem hebt met de buffer index.

Hardware defecten zijn een zinloos argument. Verificatie bewijst vooraf eigenschappen van een programma, zoals de afwezigheid van buffer overflows.

Stoney3K @MSalters • 6 mei 2015 15:28

Hardware defecten zijn een zinloos argument. Verificatie bewijst vooraf eigenschappen van een programma, zoals de afwezigheid van buffer overflows.

Wel als je het over verificatie van uitsluitend software hebt. Maar dan heb je nog de hardware waar dat op draait, en het onderliggende besturingssysteem en communicatieprotocollen.

Nogmaals: Ik heb het niet over de verificatie van het gedrag van je eigen software, maar over de uitvoerbare stroom aan bitjes die de compiler ervan maakt en die via een OS op de chip draait. Je houdt altijd de kans dat er, buiten je software om, een bitje omdondert in een register (daarom zijn chips en software in de ruimtevaart nóg conservatiever opgezet, want die moeten tegen kosmische straling kunnen).

Kun je volgens de geldende norm afzonderlijke bouwstenen certificeren en die bouwstenen combineren tot een systeem wat daardoor als veilig kan worden beschouwd, dan heb je gelijk: Dan kun je de applicatiesoftware apart verifiëren, naast het gebruikte OS, compiler en de chip waar het op moet draaien.

Kan dat niet, dan zul je de hele keten van microprocessor(s), besturingssysteem, applicatie en communicatieprotocollen als één geheel moeten beschouwen, en als je het systeem niet simpel houdt is dat onbegonnen werk.

Als je het bijvoorbeeld over een norm als EN61508 hebt, dan schrijft die een systeembrede risico-analyse voor met alle relevante foutkansen en alle diagnostische mogelijkheden om die fouten af te vangen. Strikt genomen zou dat dus betekenen dat je alle mogelijke toestanden door zou moeten rekenen.

Nu valt daar in een embedded systeem gelukkig een hoop in te strepen omdat toestanden die niet relevant zijn, ook gelijk afgevangen worden als 'veilig' of 'fout', Maar in bijvoorbeeld een desktop met 4GB aan RAM-geheugen is het al totaal niet te doen, want dat betekent dat je elk van die miljarden mogelijke toestanden afzonderlijk zou moeten analyseren.

johnkeates @Stoney3K • 3 mei 2015 15:48

Precies, en daarnaast is het certificeringstraject zo duur en tijdrovend dat er vaak met oudere ontwerpen gewerkt worden die al jaren geleden hun certificering gehad hebben. Er is ook geen reden om iets nieuws te maken als het gewoon werkt.

Om dezelfde reden zal je geen, of nauwelijks x86 tegen komen, CISC biedt in dit soort setups geen, of nauwelijks voordeel, en zou compleet opnieuw een certificeringstraject moeten doorlopen. Door de belachelijk hoge hoeveelheid states die je kan berekenen voor een CISC-based setup kan je daar lekker 10 jaar mee zoet zijn

en aan het eind van de rit win je er ook nog eens niks mee.

Wat wel interessant is, is dat qua DMA bus FireWire erg populair is, dat is vast iets wat gezien de tweakers-haat tegenover alles wat niet USB is vast verassend

Miglow @Snow_King • 3 mei 2015 11:07

K.I.S.S? Hoe simpeler de hardware, hoe minder kans op storingen. Niet zo extreem als in de ruimtevaart, maar toch...

Citroentjuh @Miglow • 3 mei 2015 11:13

Ja precies dit. In de luchtvaartsector is men -terecht- vrij conservatief. Als het niet perse nodig is om iets nieuws te implementeren waarom zouden ze het dan doen? Wat al jaren goed werkt kun je beter niet veranderen ivm kans op nog niet ontdekte bugs.

dmantione @Citroentjuh • 3 mei 2015 11:19

Dat speelt mee, maar in embedded zijn 8-bit en 32-bit de norm. Je hebt veel meer 8-bit processoren in je huis rondslingeren dan je denkt.

En dan nog iets: Op onze x86_64-systemen is het gebruik van 32-bit nog altijd ietsje efficiënter dan 64-bit. De instructies voor het manipuleren van 32-bit getallen zijn korter en vermenigvuldigen en delen kosten minder klokpulsen. Het gevolg is dat een integer op de meeste compilers 32-bits groot is, je moet expliciet een variabele als 64-bit declareren (in C bijv. als long) voordat de compiler met 64-bit getallen gaat rekenen.

Zoijar @dmantione • 3 mei 2015 11:51

Dat klopt niet helemaal; 64 bit instructies op zich zijn net zo snel als hun 32 bit tegenhangers op moderne x86_64 systemen. Wat wel mee speelt is dat een data set van 32 bit getallen twee keer zo klein is als dezelfde van 64 bits. Als je de precisie dus niet nodig hebt, kost het je performance door geheugen throughput en vooral het nodeloos vullen van je cache.

dmantione @Zoijar • 3 mei 2015 12:32

Een 64-bit vermenigvuldiging en deling is echt trager dan een 32-bit vermenigvuldiging/deling. De meeste overige instructies zijn even snel.

Wat nog wel een complicatie is bij x86_64 is dat er weinig instructies zijn met 64-bit immedeate:

add rax,4

.... kan, wat de 4 is in 32 bits te encoderen, maar:

add rax,4444444444h

.... bestaat niet.

Je moet de constante dan eerst in een register zetten (daar bestaat immedeate wel):

mov rbx,4444444444h
add rax,rbx

In zo'n situatie heb je dus opeens twee instructies nodig om het werk te doen.

Overv @dmantione • 3 mei 2015 14:06

"Een 64-bit vermenigvuldiging en deling is echt trager dan een 32-bit vermenigvuldiging/deling. De meeste overige instructies zijn even snel."

In een moderne architectuur die voor 64-bit ontworpen is, zal dat niet het geval zijn. Zie deze post:

http://stackoverflow.com/...-bit-vs-64-bit-arithmetic

En deze benchmark:

http://www.passmark.com/f...amp-integer-maths-amp-PT8

Voor de rest heb je wel gelijk.

[Reactie gewijzigd door Overv op 23 juli 2024 19:06]

dmantione @Overv • 3 mei 2015 15:19

Ik heb een betere bron

De Intel optimization guide:

http://www.intel.com/cont...s-optimization-manual.pdf

Ga naar blz. 631 ofwel C-25 en verder. Je ziet dat de latenties van 32- en 64-bit instructies verschillen. Wel merkwaardig hier is de "imul r64,r64", die uitzonderlijk snel is.

Bij AMD is het niet anders, AMD's optimization guide:

http://support.amd.com/TechDocs/47414_15h_sw_opt_guide.pdf

Ga naar blz. 248, ook daar zie je dat de 64-bit versies hogere latenties hebben.

Wat wel mogelijk is, is dat je latenties kunt verbergen door je code goed voor te bereiden op pipelining: Een "imul reg64" kost weliswaar 6 klokpulsen terwijl dat reg bij een reg32 maar 4 zijn, maar je kunt iedere klokpuls een nieuwe vermenigvuldiging opstarten. Als je niet teveel afhankelijkheden in je code inbouwt, kan je het klaarspelen dat iedere vermenigvuldiging netto nog maar 1 klokpuls kost en dat geldt voor zowel 32 als 64 bit.

Dat kan een verklaring zijn voor de resultaten van de microbenchmarks waar je naar linkt.

Zoijar @dmantione • 3 mei 2015 16:32

Het is inderdaad moeilijk te zeggen in daadwerkelijke executie vanwege pipelining etc., maar je ziet ook in deze handleiding duidelijk dat 32 bit instructies voor het grootste deel of even snel, of trager zijn dan de 64 bit varianten. Voor de 64 bit imul staat er ook een noot bij dat het resultaat niet groter dan 64bit mag zijn anders is hij trager. De verklaring is dat hij dan een enkel 64 bit reg kan gebruiken, daar de 32 bit variant twee keer 32 bits nodig heeft voor het resultaat.

Overigens worden de meeste 32 bit ops ook geimplementeerd door de 64 bit op uit te voeren en dan de hoogste 32 bits af te masken.

Het is dus (met uitzondering van fdiv!) niet zo dat een 64 bit arithmetic op langer duurt: de cpu rekent het "in een keer" uit ongeacht hoeveel bitjes.

Uiteindelijk is 32 bit code wel vaak sneller vanwege kleinere data; dat meldt intel hier ook. Verder zijn de vectorized versies ook even snel, echter doet een vector op op 32 bit fields twee keer zo veel werk!

Maar ik zei dit vooral omdat men vaak denkt dat 64 bits getallen groter zijn en dus "meer werk" om te vermenigvuldigen, en dat is niet zo in moderne architectures (behalve bij divs) De speed up van 32 bits komt van kleinere data en meer elementen in je vectors.

[Reactie gewijzigd door Zoijar op 23 juli 2024 19:06]

Anoniem: 475099 @dmantione • 3 mei 2015 17:59

Een 64-bit vermenigvuldiging en deling is echt trager dan een 32-bit vermenigvuldiging/deling. De meeste overige instructies zijn even snel.

Als je twee 64-bits getallen vermenigvuldigt, dan kan dat toch even snel gebeuren als twee 32-bits getallen vermenigvuldigen? Ik heb het niet over de snelheid uitgedrukt in tijd, maar uitgedrukt in machine cycles. Een 64-bits processor kan 64 bits tegelijkertijd inlezen (parallel) en een 32-bits processor kan ook parallel 32 bits tegelijkertijd inlezen. Dat maakt ze, uitgedrukt in machine cycles, toch even snel? Of vergis ik me nauw?

edit:
Pipelining, cache en dergelijke truucjes even niet meegerekend uiteraard.

[Reactie gewijzigd door Anoniem: 475099 op 23 juli 2024 19:06]

dmantione @Anoniem: 475099 • 3 mei 2015 19:17

Doe eens een vermenigvuldiging van twee grote getallen met de hand: Ze de getallen boven elkaar en maak de vermenigvuldiging zoals je op de basisschool geleerd hebt.

Als de getallen nu twee keer zo groot worden, dan ben je veel langer bezig. Je kunt zo'n berekening maar beperkt paralleliseren: Je moet rechts beginnen met de individuele cijfers vermenigvuldigen en dan naar links werken, omdat die afhankelijk zijn van de vorige.

De processor verdeelt het werk dat jij met de hand doet over meerdere klokpulsen. Om het te versnellen doet de processor dat niet met decimale getallen zoals jij doet, ook niet binair, maar in bijvoorbeeld een 256-tallig stelsel. Hoeveel 91*201 is, leest de processor uit een tabel. Hoe groter het stelsel, hoe minder klokpulsen nodig zijn, maar hoe groter de tabellen die in processor moeten worden gestopt.

Hoe dan ook, 64 bit blijft meer werk dan 32. Het is technisch niet onmogelijk om 64-bit even snel te doen als 32-bit. Dat betekent dat je per klokpuls een groter deel van de berekening moet uitvoeren. Het nadeel is, dat er per klokpuls veel werk verzet moet worden, en dat is weer nadelig voor de kloksnelheden die je met de processor kunt behalen.

Voor delen geldt iets gelijksoortigs als voor vermenigvuldiging: De processor doet een soort staartdeling. Maar in tegenstelling tot vermenigvuldigen is het niet letterlijk wat jij op papier doet: Er zijn nog wat extra truukjes die toegepast kunnen worden.

Anoniem: 475099 @dmantione • 3 mei 2015 19:44

Hmm... ik begrijp het nog steeds niet. Ik begrijp wel dat 64 bits meer werk oplevert als ik daarmee handmatig een berekening zou maken. Een handmatige berekening levert meer werk op omdat de cijfers 1 voor 1 verwerkt moeten worden. Een computer leest 64 bits in 1 klokpuls uit, gebruikt een multiply-instructie van 64 bits, dus dan is die per definitie toch even snel als 32-bits processor die een 32-bits register uitleest etc (als je denkt in klokpulsen in plaats van absolute tijd)?

dmantione @Anoniem: 475099 • 3 mei 2015 21:03

De computer leest alle 64 bits in 1 keer uit, dat klopt, want dat kan parallel: Door gewoon 64 draadjes in de processor te leggen, kunnen ze alle 64 tegelijk uitgelezen worden.

Het daadwerkelijk vermenigvuldigen kan niet parallel. Net zoals je op papier rechts moet beginnen en dan naar links werken, moet een processor dat ook en voor het daadwerkelijk uitvoeren van de vermenigvuldiging neemt hij ook meerdere klokpulsen de tijd: In het geval AMD 4 klokpulsen voor 32-bit en 6 klokpulsen voor 64-bit.

Het is wel zo dat als je een MUL-instructie hebt, je direct de volgende klokpuls een nieuwe instructie kunt uitvoeren (pipelining van instructies). Het resultaat van de vermenigvuldiging is echter pas na 4 of 6 klokpulsen beschikbaar. Als je het resultaat eerder gebruikt, dan wacht de processor domweg totdat hij de vermenigvulding heeft afgerond.

Anoniem: 475099 @dmantione • 3 mei 2015 21:17

Het daadwerkelijk vermenigvuldigen kan niet parallel. Net zoals je op papier rechts moet beginnen en dan naar links werken, moet een processor dat ook en voor het daadwerkelijk uitvoeren van de vermenigvuldiging neemt hij ook meerdere klokpulsen de tijd: In het geval AMD 4 klokpulsen voor 32-bit en 6 klokpulsen voor 64-bit.

Oh jah, je hebt gelijk. Ik begrijp het. Thnx!

snelwegkat @Citroentjuh • 3 mei 2015 12:57

Ja precies dit. In de luchtvaartsector is men -terecht- vrij conservatief. Als het niet perse nodig is om iets nieuws te implementeren waarom zouden ze het dan doen? Wat al jaren goed werkt kun je beter niet veranderen ivm kans op nog niet ontdekte bugs.

Men heeft met zijn conservatieve houding toch kans gezien een splinternieuwe bug te introduceren

. Ik neem aan dat tijdens de ontwikkeling van een vliegtuig als de dreamliner een hele hoop nieuwe code is gemaakt.

Naar mijn idee is het gebruik van een 32-bits compiler meer een gevolg van de lengte van het ontwikkeltraject. Volgens de wiki http://en.wikipedia.org/w...787_Dreamliner#Background is de eerste ontwikkeling eind 90er jaren gestart. Toen was 64-bits computing nog geen gemeengoed. Om halverwege een ontwikkeltraject van compiler te wisselen is nogal wat. Alle tot dan toe opgeleverde software moet dan opnieuw getest worden. In dat licht vind ik de keuze voor een 32-bits compiler niet heel vreemd.

player-x @snelwegkat • 3 mei 2015 14:56

Naar mijn idee is het gebruik van een 32-bits compiler meer een gevolg van de lengte van het ontwikkeltraject.

Imho onzin, zelfs als men was begonnen met het ontwikkelen in de 90er jaren, dan nog kan het programma gewoon door een 64bit compiler gewoon 64bit gemaakt worden.

Er zijn maar twee goede redenen om 32bit te gebruiken, dat als de betreffende hardware 32bits is, want in de industrie wordt er veel speciale hardware gebruikt, dat op PowerPC, MIPS of andere specialistische (inbeded) CPU draait.

Of dat men software gedeeltelijk hergebruikt, en overtuigt is dat er geen problemen mee zijn, en zo een hoop debuging en test tijd te besparen, uiteraard kunnen om wat voor redenen dan ook, er nieuwe bugs ontstaan, die gewoon bijna niet te voorzien zijn, zoals een bug die pas na 248 dagen optreed.

Maar zover ik kan zien zijn er geen goede redenen om tegenwoordig nog nieuwe programma's in 32bit mode te laten draaien, want wat men in 32bit kan compileren kan men ook in 64bit compileren.

Garyu @player-x • 3 mei 2015 15:29

Vanuit de luchtvaart wordt de vraag andersom gesteld, waarom zou je 64 bit gebruiken als 32 genoeg is? Op een embedded systeem heb je voor de luchtvaart sowieso nog geen 64 bits CPU die gecertificeerd is voor gebruik in dit soort bedrijfskritische systemen.

player-x @Garyu • 3 mei 2015 16:07

Vanuit de luchtvaart wordt de vraag andersom gesteld, waarom zou je 64 bit gebruiken als 32 genoeg is?

Nee er wordt afgevraagd welke veiliger is.

Op een embedded systeem heb je voor de luchtvaart sowieso nog geen 64 bits CPU die gecertificeerd is voor gebruik in dit soort bedrijfskritische systemen.

Veel ervaring in de luchtvaart met missie-kritische systemen?

Ik werk in de Olie & Gas, en volgens mij beginnen we nu echt ook met 64bit systeem te werken, en denk dat het in de luchtvaart die ongeveer net zo conservatief is qua nieuwe systemen als in onze branche.

Of denk je dat in de Olie & Gas minder kritisch naar veiligheid wordt gekeken dan in de luchtvaart?, omdat de gevolgen misschien minder groot zijn?

MossMan @Citroentjuh • 3 mei 2015 15:49

Iets wat ik nog niet heb gelezen hier - alles in de luchtvaart moet gecertificeerd worden... en dat betekent:

- veel documentatie
- veel theoretisch bewijs
- veel test bewijs
- veel tijd
- veel geld

en dat alles aangenomen de luchtvaartautoriteiten in eerste instantie mee eens zijn met de principes(*).

Dat is goed voor de veiligheid, maar slecht voor de vooruitgang. Daarom is bijna alles al eerder in andere industrieën terecht te vinden (of militaire vliegtuigen) voordat dat in een passagiersvliegtuig verschijnt.

Iets als 64-bits v 32-bits is ten eerste niet de moeite waard, en ten tweede het zou zowieso tien jaar later op een vliegtuig zitten dan in je thuis PC vanwege alle certificatie rompslomp.

(*) en al is het een keer gebeurd dat de luchtvaartautoriteit in de VS (FAA) voor Boeing door de vingers heen keek omtrent bewijs van de veiligheid van Li-ion accus, het vervolg (ontploffende / brandende batterijen op de 787) betekent dat ze tegenwoordig strikter zijn dan ooit...

[Reactie gewijzigd door MossMan op 23 juli 2024 19:06]

player-x @Miglow • 3 mei 2015 11:31

64bit is meer K.I.S.S, dan 32 bit, daar het niks meer complex maakt, maar juist beperkingen/grenzen verplaatst naar waar ze irrelevant worden.

Een programma geprogrammeerd in C++ draait net zo goed in 64bit mode als in 32bit, het enige verschil is de 64bit ipv 32bit compiler die men daar voor gebruikt.

wjn @player-x • 3 mei 2015 13:59

64bit is meer K.I.S.S, dan 32 bit, daar het niks meer complex maakt, maar juist beperkingen/grenzen verplaatst naar waar ze irrelevant worden.

Dat dachten ze ook bij de overstap van 8/16 naar 32 bit, grote valkuil.

player-x @wjn • 3 mei 2015 14:58

Hoe is dat ook maar enig zins relevant voor een embeded systeem dat niet terug waards competible moet zijn???

wjn @player-x • 4 mei 2015 13:59

Zie hieronder:

dmantione @wjn • 3 mei 2015 22:52

Nou, de bug gaat niet weg als je er een 64-bit integer van maakt. Het duurt alleen opeens onrealistsich lang voor hij optreedt. De insteek moet zijn foutloze software te schrijven en de echte fout is dan ook dat de software de integeroverloop niet netjes afvangt.

De kilometerteller van je auto kan ook maar een eindig aantal kilometers registereren. Als je er doorheen best, begint hij weer bij nul. Je wilt niet dat de auto dan onbruikbaar is (ook al is hij tegen die tijd zo oud dat hij sloopwaardig is).

Op dezelfde manier moet deze software zorgen dat de stroom actief blijft. Dat er ergens een teller bij 0 begint is geen probleem, maar de stroom moet gewoon aanblijven.

Kortom, de programmeurs moeten gewoon nadenken wat er gebeurt als een integer overloopt en niet denken "hij is wel groot genoeg dus het komt toch nooit voor".

Garyu @player-x • 3 mei 2015 15:31

En je denkt dat je C++ op een vliegtuig computer kan draaien? Dream on

Mijzelf @Garyu • 3 mei 2015 15:45

Waarom niet? Misschien niet direct C++, maar de kans is zeer groot dat de software in C is geschreven.

MSalters

Economie en maatschappij

@Garyu • 3 mei 2015 16:10

Niet alleen kan het, het is zelfs de nieuwe militaire standaard voor de JSF. En die hebben met alle wapensystemen aan boord nog complexere software ook. Een 787 in vergelijking is een luchtbus.

De reden is vrij simpel: je hebt gecertificeerde compilers nodig. Historisch had je alleen C en Ada compilers, maar een C++ compiler is nauw verwant aan een C compiler. Dat maakt certificatie simpel. Voor Java zou je niet alleen de compiler moeten certificeren, maar zelfs de hele JVM.

Mijzelf @player-x • 3 mei 2015 15:43

In C is een 'int' 32 bits, of ik het nou op een 32 of 64 bits compiler compileer. Natuurlijk kan ik 64 bits 'afdwingen', door 'long long' te declareren, maar goede kans dat het dan niet meer op een embedded 32 bits (of zelfs 8 bits) wil draaien. Dus in het geval van protable libraries zal het toch al gauw een 'int' zijn.

EddoH @Mijzelf • 3 mei 2015 21:52

Onzin. De grootte van een int is afhankelijk van het platform, de C specificatie definieert alleen ranges die in een int moeten passen, niet de daadwerkelijke size in bits.

Mijzelf @EddoH • 3 mei 2015 22:16

Hoewel ik het in theorie met je eens ben, ben ik in de praktijk nog geen 64 bits int's tegen gekomen. Wel 16 bits, wat volgens de standaard de kleinst mogelijk maat is, maat alleen op 8 of 16 bits platforms.

Dus in de praktijk klopt mijn stelling In C is een 'int' 32 bits, of ik het nou op een 32 of 64 bits compiler compileer.

Patrickkkk @Snow_King • 3 mei 2015 11:17

64 bit systeem wil niet zeggen dat alle integers ineens 64 bit zijn. Dus je kan uit dit verhaal niet afleiden of ze op 32 of 64 bit systemen vliegen.

Boy @Patrickkkk • 3 mei 2015 12:08

Volgens mij juist wel!?

TheekAzzaBreek @Boy • 3 mei 2015 12:16

Het hoeft niet: als de code een 32-bits int specificeert is-ie dat nog steeds als er voor 64-bits gecompileerd wordt. Die int neemt wel 64 bits ruimte, de rest is verlies.

halofreak1990 @TheekAzzaBreek • 3 mei 2015 15:11

Die int neemt wel 64 bits ruimte, de rest is verlies.

Alleen op de stack, waar alles 64-bits is. In data structuren, zolang de 32-bit int het grootste veld is, is 32-bit gewoon 32-bit. Alleen als die samenzit met bijvoorbeeld een double of long, wordt er padding toegevoegd, en heb je last van 'verlies'.

jj71 @Snow_King • 3 mei 2015 12:03

Of de processor in het relevante systeem een 32-bit of 64-bit processor is heeft er niet direkt iets mee te maken.

Het standaard datatype voor integers in programmeertalen zoals C, C++, C# en Java is "int" en is meestal 32 bits, ook op 64-bit systemen. Als je expliciet een 64-bit integer wilt gebruiken dan moet je het type "long" gebruiken. De meeste programmeurs gebruiken "int" zonder er verder heel hard over na te denken. Het ligt dus aan hoe het programma is geschreven.

[Reactie gewijzigd door jj71 op 23 juli 2024 19:06]

MSalters

Economie en maatschappij

@jj71 • 3 mei 2015 16:24

Als je expliciet een 64 bits integer wil gebruiken in C of C++, dan gebruik je int64_t. Het aantal bits van long is tenminste 32. En volgens dezelfde logica is int tenminste 16 bits lang.

Martinspire @Snow_King • 3 mei 2015 18:30

Maar dan zou je niet 248 dagen tot bug hebben maar een x aantal dagen daarna. Lijkt me dat je het probleem dan alleen verplaatst ipv oplost. Granted, je hebt wat meer tijd.

[Reactie gewijzigd door Martinspire op 23 juli 2024 19:06]

guzzo @Martinspire • 3 mei 2015 21:03

Dan zou je ongeveer 2^63/100/3600/24/365 ~= 2.9 miljard jaar hebben voor je tegen dezelfde bug aan loopt. Lijkt me dat het vliegtuig dan al is omgesmolten tot wat anders.

Remie @Snow_King • 3 mei 2015 11:17

Is er een noodzaak om over te stappen naar 64 bit?

Antipater @Snow_King • 3 mei 2015 11:52

Ik zou eigenlijk verwacht dat deze moderne systemen ook dáár al 64-bit zouden zijn? Iemand die hier iets meer van weet waarom het niet het geval is?

Als je het over een 64-bit systeem hebt, dan slaat dat op de geheugen adressering. Voor 32-bit systemen worden 32-bit eenheden gebruikt om te verwijzen naar een plek in het geheugen, vandaar de limiet van 4GB die in dat soort systemen (zonder workarounds) ondersteunt wordt. Een systeem wat 64 bit als geheugenadres gebruikt heeft daarentegen een praktisch oneindige hoeveelheid virtueel geheugen ter beschikking.

Echter, voor normale numerieke waarden is 32-bit het meest gebruikt en ook afdoende, ook in 64-bit systemen. In programmeertalen als C en C++ is dat doorgaans de standaard als je om een numerieke waarde vraagt, terwijl je 64-bit waarden expliciet moet aangeven. De meest gebruikte getallen zijn niet zo groot dus dat is meestal geen probleem. Tenzij dat wel een keer het geval is, zoals hier, en de programmeurs daar geen rekening mee hebben gehouden of iets over het hoofd hebben gezien.

EDIT: dit zegt dus niets over welk systeem er wordt gebruikt. Kan 32 of 64 bit zijn.

[Reactie gewijzigd door Antipater op 23 juli 2024 19:06]

Anoniem: 22438 @Snow_King • 3 mei 2015 12:22

Ik zou sowieso niet vliegen met een dreamliner na het kijken van deze documentaire.

De dreamliner is ontwikkeld als cashcow. Er is afgeweken van vele kwaliteitsnormen om het ding op tijd de fabriek uit te krijgen.

Geld is belangrijker dan veiligheid...

Dit is alleen maar een zoveelste bevestiging dat dit toestel niet betrouwbaar is.

Edit: Grappig om te zien dat mensen mijn post als ongewenst aangeven of irrelevant. Ik heb nog nooit gehoord van een vliegtuig dat gereboot moet worden vanwege een software bug. Dit past toch helemaal in het plaatje van gebrek aan kwaliteitscontrole ten behoeve van winst?

[Reactie gewijzigd door Anoniem: 22438 op 23 juli 2024 19:06]

Enai @Anoniem: 22438 • 4 mei 2015 09:19

Maar elk vliegtuig is een cashcow. Als er een kilo bezuinigd kan worden dan doet men dat. Alle marges zijn er al uit bespaard, net als bij elk ander vliegtuig.

In het verleden had je zulke problemen als "laaddeur sluit niet maar het metertje zegt van wel" -> ene met veel moeite geland, een andere neergestort. Was dat ook om geld te besparen of gewoon een stomme designfout?

QuintMidas @Anoniem: 22438 • 4 mei 2015 11:38

Ik heb nog nooit gehoord van een vliegtuig dat gereboot moet worden vanwege een software bug.

Het zal waarschijnlijk niet dezelfde oorzaak hebben, maar ik zat vorige week nog in een Boeing 777 waarvan na overleg met maintenance het backup-systeem voor de elektriciteit aan boord gereset moest worden. Althans, dat was wat de gezagvoerder ons passagiers meldde toen we weer invoegden in de rij met voor takeoff wachtende vliegtuigen nadat we een kwartiertje aan de kant waren gezet...

mad_max234 @Snow_King • 3 mei 2015 12:55

Ik zou eigenlijk verwacht dat deze moderne systemen ook dáár al 64-bit zouden zijn? Iemand die hier iets meer van weet waarom het niet het geval is?

32bit systeem kan prima de 64bit integer gebruiken, dan pakt die gewoon twee registers van 32bit om in te rekenen, 32bit systeem beteken niet dat je ook niet per definitie dat je vast zit aan 32bit integers.

Zelfs simpele 8bitters zoals AVR cpu's kunnen ook gewoon 32bit of 64bit getallen verwerken.

SuperDre @Snow_King • 3 mei 2015 20:28

Omdat dit soort vliegtuigen al jaren in ontwikkeling zijn? En om je eerlijk te zeggen vraag ik me af wat het voordeel van 64bit zou zijn. 64-bit klinkt leuk, maar is verre van een noodzaak..

mae-t.net @Snow_King • 4 mei 2015 02:02

Een 32 bit signed integer is 64 bit lang, dus dat kan opzich ook nog wel.

Overigens heeft de grootte van de datastructuur in principe niet te maken met de breedte van een processorwoord. Op een 16-bits processor kon je ook gewoon 32-bits berekeningen maken, alleen had je dan 2 registers nodig. Bij gebruik van een hogere programmeertaal merk je er zelfs helemaal niets van.

[Reactie gewijzigd door mae-t.net op 23 juli 2024 19:06]

gamezfreak @Snow_King • 3 mei 2015 11:11

IMO is 32 bits wat stabieler dan 64 bits. Soms zelfde met Windows maar ik kan het ook fout hebben. Heb hetzelfde gehad met WIndows 7, 32 bits was stabiel en 64 bits had nog wat problemen.

The Third Man @gamezfreak • 3 mei 2015 18:53

Ja en dieselauto's zijn allemaal sloom want tractors rijden ook op diesel... Wat heeft Windows 7 en zijn stabiliteit met vliegtuigen te maken

Soldaatje 3 mei 2015 11:10

Bizar.
Terwijl elk boutje en moertje 100x zoveel kost door alle testen en certificaten, geldt dat blijkbaar niet voor de software aan boord.

Anoniem: 315662 @Soldaatje • 3 mei 2015 11:17

Tjsa beetje kort door de bocht vind ik, software 248 dagen laten draaien omdat het dan misschien problemen oplevert lijkt me geen standaard test.

spanx @Anoniem: 315662 • 3 mei 2015 17:50

Misschien het systeem zo instellen dat de tijd x1000 of 10.000 loopt zodat dit op korte termijn getest kan worden? Denk ik dan te simpel?

Blokker_1999

Economie en maatschappij

@Soldaatje • 3 mei 2015 11:46

Noem eens 1 stuk software waar je zeker van bent dat er geen bugs in zitten ... . Software word nog altijd door mensen geschreven, en mensen schrijven fouten. Zelfs in kritieke systemen worden gemiddeld nog altijd 10 fouten per 1000 lijnen geschreven. In de software aan boord van de space shuttle was dat nog altijd 5 fouten per 1000 lijnen. Dit terwijl het gemiddelde voor gewone software ergens tussen de 15 en 50 ligt.

TunderNerd @Soldaatje • 3 mei 2015 12:44

Ik kan je er van verzekeren dat de software is bekeken etc door een certificerende organisatie. Ik weet niet precies welke norm er wordt gebruikt in de vliegtuigwereld; maar de kans is zeer groot dat de IEC 61508 de moedernorm is. In deze norm zelf is men al zeer bewust van het gevaar van software, maar hoe kan je dit beperken? op dit moment zijn er de volgende maatregelen (afhankelijk va het SIL niveau):
- Projectmanagment; eisen aan ervaring, posities binnen project, review onafhankelijkheid etc
- Documentatie, van Overal safety Plan tot plannen voor Interim Changes
- Testen zoals Black box, white box, static code analyse etc.
- enz

Het grote probleem is; hoe kan ik garanderen dat er geen fouten meer in zitten? Hardware is "makkelijker", dit bereken je door het failure rate data op component niveau.
De certificerende partij doet zijn uiterste best om kwaliteit te bewaken mbv normen, good engineering en jaren ervaring. Ja, er worden zeer veel fouten uit gehaald, maar alles? Dat is onmogelijk

MSalters

Economie en maatschappij

@TunderNerd • 3 mei 2015 16:37

De bovenliggende norm in de luchtvaart is DO-178B. Er wordt niet gewerkt met Safety Integrity Levels (SIL) maar met Design Assurance Levels (DAL).

Er zijn geen formele voorschriften welk proces je precies gebruikt om je software te certificeren, dit soort normen staan op een hoger nivo en beschrijven alleen wat je certificatie-proces moet inhouden.

TommieW @Soldaatje • 3 mei 2015 12:01

En je denkt dat een audit dit soort problemen er ook uit haalt?

Citroentjuh @Soldaatje • 3 mei 2015 11:14

Nou dat is wel erg kort door de bocht. Voor de software zal zeker ook strenge controle gelden, maar een bug kan nou eenmaal altijd voorkomen.

Tonko Boekhoud @Soldaatje • 3 mei 2015 14:16

Je kunt niet op situaties testen waar je niet aan hebt gedacht.

BillyTheClit 3 mei 2015 11:16

Ook al lijkt deze bug gevaarlijk (en is het ook wel onvorstelbaar dom).
Er zijn in een vliegtuig nog genoeg andere "single points of failure", om van het menselijke aspect nog maar te zwijgen.
Windows heeft hier ook last van (v7 en ouder, Server 2008 en ouder), misschien heeft Boeing wel Windows gebruikt en niet gepatched?

Mr_gadget @BillyTheClit • 3 mei 2015 11:31

Windows heeft hier ook last van (v7 en ouder, Server 2008 en ouder), misschien heeft Boeing wel Windows gebruikt en niet gepatched?

Mag hopen dat de control systemen op iets anders dan Windows draaien! Neem aan een QNX of VXworks.

[Reactie gewijzigd door Mr_gadget op 23 juli 2024 19:06]

wildhagen

Economie en maatschappij
Luchtvaart

@Mr_gadget • 3 mei 2015 11:57

Of een proprietary OS oid, een voorbeeld van een OS wat in vliegtuigsystemen wordt gebruikt is bijvoorbeeld Integrity

Sowieso moet software die in vliegtuigen gebruikt worden (voor de besturing etc, dus even los van in-flight entertainment systemen) voldoen aan standaarden (bijv DO-178B), en ik betwijfel of de meeste desktop/server-OSen als Windows, Linux, MacOS aan die standaard voldoen (weinig nuttig voor die OS-en bijvoorbeeld)

Citroentjuh @BillyTheClit • 3 mei 2015 11:23

Er zijn in een vliegtuig nog genoeg andere "single points of failure",

Zoals? Ik ben wel benieuwd waar je hier op doelt? Iets roepen kunnen we allemaal, onderbouwing graag.

BillyTheClit @Citroentjuh • 4 mei 2015 09:06

Een piloot

Citroentjuh @BillyTheClit • 4 mei 2015 11:28

Ten eerste zeg je in je post 'naast het menselijke aspect', dus je doelt kennelijk op iets anders in het vliegtuig dan de piloot, en daar vroeg ik je naar. Ten tweede is de piloot ook geen single point of failure zoals dasiro terecht opmerkt. Kortom; zoals ik al verwacht had roep je maar wat.

dasiro @BillyTheClit • 3 mei 2015 12:13

misschien heeft Boeing wel Windows gebruikt en niet gepatched?

ja, want vliegtuiggenerators vereisen een verouderde 32b windows.

Het menselijke aspect is al geen single point of failure meer, want je hebt al een co-piloot die het vliegtuig aan de grond kan zetten en daar bovenop heb je nog autoland.
Een vliegtuig heeft meer backupsystemen dan eender welk ander transportmiddel.
Als de reboot in de A-check wordt geïntegreerd (elke 4 maanden voor een dreamliner), dan moet je er al 2 hebben overgeslagen vooraleer dit een probleem zou kunnen worden.

MSalters

Economie en maatschappij

@BillyTheClit • 3 mei 2015 16:27

In een vliegtuig zijn geen single point of failures. Dat is een fundamenteel concept, wat zelfs tot in de cockpit is doorgevoerd (twee piloten). Het lijkt misschien alsof de staart een single point of failure is, maar zelfs die heeft vaak twee afzonderlijk bewegende delen.

Anoniem: 398486 3 mei 2015 11:08

Is een reboot niet het zelfde als toestel uitzetten? wat neem ik aan wel een keer gebeurd als het toestel niet wordt gebruikt na een vlucht voor paar uur

Anoniem: 40104 @Anoniem: 398486 • 3 mei 2015 11:17

Dat is ook wat ik me afvroeg. Ondanks dat vliegtuigen en zeker longhaul machines vrijwel permanent in gebruik zijn heb je minimaal elke 248 dagen een check of waarschijnlijk andere reden om het ding tijdelijk uit te schakelen. Er is elke 6 maanden een B-check bijvoorbeeld waarbij zo'n vliegtuig 3 dagen in een hangaar staat.

Afgezien van de bespottelijke programmeerfout waarvan ik hoop dat de persoon is ontslagen, lijkt dit een zeer onwaarschijnlijk probleem dat ook daadwerkelijk voor zal komen.

cire @Anoniem: 40104 • 3 mei 2015 22:55

Elke fout is achteraf bespottelijk... Maar of we er met zijn allen beter van worden om iedereen meteen te ontslaan, vraag ik mij af...

RocketKoen @Anoniem: 398486 • 3 mei 2015 11:14

Zo'n Dreamliner is duur. Die hebben ze dus het liefst helemaal niet stilstaan.
Eigenlijk gaan ze alleen "uit" voor onderhoud en reparatie. Dus als zo'n vliegtuig een half jaar geen onderhoud heeft gehad, dan gaan het licht uit. Ook als dat toevallig op 10km hoogte is...

Op 10km heb je waarschijnlijk wel genoeg tijd om opnieuw op te starten. Maar tijdens opstijgen of landen is het wel vervelend als je een minuut lang niet kan sturen.

wildhagen

Economie en maatschappij
Luchtvaart

@RocketKoen • 3 mei 2015 11:18

Zo'n Dreamliner is duur. Die hebben ze dus het liefst helemaal niet stilstaan.
Eigenlijk gaan ze alleen "uit" voor onderhoud en reparatie. Dus als zo'n vliegtuig een half jaar geen onderhoud heeft gehad, dan gaan het licht uit. Ook als dat toevallig op 10km hoogte is...

Eh.... een vliegtuig *moet* zeer regelmatig (gemiddeld om de 250 uur of 200-300 cycles (1 cycle is een combinatie van 1 landing + 1 start)) minimaal een A-Check ondergaan waar hij dus even buiten dienst gesteld wordt.

Of dan de generatoren ook uitgeschakeld worden weet ik niet, maar de kans dat een toestel als een 787 een halfjaar lang geen enkele controle gehad heeft is de facto dus 0.

MSalters

Economie en maatschappij

@wildhagen • 3 mei 2015 16:40

De A-check van een 787 is elke 1000 uur. Dat is 1 van de redenen waarom er gekozen is voor een heleboel elektrische oplossingen in plaats van hydraulische of anderzinds mechanische: elektrische systemen hebben betere zelf-test functionaliteit waardoor er minder preventief onderhoud nodig is.

wildhagen

Economie en maatschappij
Luchtvaart

@Soldaatje • 3 mei 2015 11:51

Het zal niet de eerste keer zijn dat een gepland onderhoud om kostentechnischeredenen overgeslagen wordt en dat het vliegtuig daardoor crasht waarbij iedereen aan boord omkomt. Vooral bij de budgetmaatschappijen komt dat nog wel eens voor.

Dit klinkt eerlijk gezegd toch wel vrij onwaarschijnlijk, want zo'n maatschappij is dan binnen de korte keren kapot als zoiets bekend wordt. Boetes, reputatieschade, plaatsing op de zwarte lijst van de EU, etc etc.

Wellicht dat het in Afrika soms voorkomt, maar in het westen en het grootste deel van Azië lijkt me dat toch vrij stug gezien de strenge regelgeving...

Heb je overigens een voorbeeld van een vliegtuig dat door het skippen van maintenance checks is verongelukt (los van Afrika dan)?

[Reactie gewijzigd door wildhagen op 23 juli 2024 19:06]

Double-X-L @wildhagen • 3 mei 2015 13:09

Alaska Air vlucht 261 lijkt mij daarin het meest duidelijke voorbeeld.
http://nl.wikipedia.org/wiki/Alaska_Airlines-vlucht_261

Het meest simpele onderhoud, smering van het stabilo spindel systeem waardoor de hele kist onbestuurbaar werd.

Vergis je niet dat overal waar geld aan vast hangt direct te lijden heeft aan meerdere vormen van druk van buitenaf. Veiligheid, regels, procedures ten spijt. Je ziet het recentelijk bv. ook aan MH17 en de NAM in groningen.
Beide konde veiliger en waren zeer waarschijnlijk gebonden aan regels.
Toch heeft economisch aspect in die zaken de bovenhand gehad.

Hou daarbij in je achterhoofd dat er heel wat mis moet gaan voordat het fataal wordt, incidenten zullen er genoeg zijn, nieuwswaardig wordt het pas als het serieus fout gaat.

[Reactie gewijzigd door Double-X-L op 23 juli 2024 19:06]

Warpozio @Soldaatje • 3 mei 2015 11:38

248dagen is bijna 8 maanden.
Elke 2 weken een A-check en elke 6 maanden een B-check.
Veel fuzz, weinig gevaar.
Zelf een budgetmaatschappij laat niet graag een toestel van 200 miljoen $ naar beneden vallen als ze dit kunnen opvangen door ff te rebooten

Anoniem: 670884 @Warpozio • 3 mei 2015 12:29

A check: Meestal overnight
B check: Verschillende onderdelen kunnen in A checks meegenomen worden.

Zie Wikipedia.

Het is dus zeer goed mogelijk dat de systemen niet gereboot worden tijdens de checks.
De extra instructie van Boeing lijkt me dus wel zeker van belang, al ben ik met je eens dat het veel fuzz is.

Powermage @Anoniem: 670884 • 4 mei 2015 09:30

Boeing heeft al gemeld dat wanneer de normale onderhoudsprocedures gevolgd zijn met de normale checks de kisten allemaal 'gereboot' zijn.

Citroentjuh @Soldaatje • 3 mei 2015 11:38

Heb je daar een bron voor? Het lijkt mij een broodje aap verhaal, want er is (in elk geval in de westerse wereld) strenge wet- en regelgeving voor. Een maatschappij zou een enorm risico lopen om daar mee te sjoemelen. Zelfs budgetmaatschappijen zullen dat wel uit hun hoofd laten.

Soldaatje @Citroentjuh • 3 mei 2015 11:41

Discovery Channel - Aircrash Investigation, welke weet ik niet meer.
Het was een VS budgetmaatschappij.

[Reactie gewijzigd door Soldaatje op 23 juli 2024 19:06]

Citroentjuh @Soldaatje • 3 mei 2015 11:44

Ja en waar ging dat dan precies over? Een budgetmaatschappij ergens in Afrika? De verplichte checks zoals door Wildhagen ook al aangehaald zullen in westerse landen niet zomaar overgeslagen kunnen worden, en als dat wel zou gebeuren en het was bekend (wat jij dus suggereert) dan zou dat enorm veel ophef veroorzaken.

ninjazx9r98 @Soldaatje • 3 mei 2015 11:52

Komt dat nog wel eens voor baseer je dus op één aflevering van Aircrash Investigation die je je niet meer kunt herinneren. Aflevering onbekend, hoe lang dat geleden is onbekend, maatregelen naar aanleiding van de crash onbekend en dan gewoon suggereren dat er met enige regelmaat vliegtuigen naar beneden komen door overgeslagen onderhoud...

Soldaatje @ninjazx9r98 • 3 mei 2015 12:16

Ja, dan heb je me verkeerd begrepen, ik zei dat het missen van onderhoud regelmatig voorkomt, niet dat daardoor perse al die toestellen uit de lucht vallen.
Goed, misschien had ik het anders moeten zeerzetten.
Ontbreken van bron is inderdaad jammer, maar die moet ik je schuldig blijven.

[Reactie gewijzigd door Soldaatje op 23 juli 2024 19:06]

Blokker_1999

Economie en maatschappij

@Soldaatje • 3 mei 2015 11:48

Bij westerse luchtvaartmaatschapijen word zeer streng toegezien op het naleven van de onderhoudsvoorschriften. We zijn al zo ver dat wanneer een maatschapij betrapt word op het niet naleven van die voorschriften zij mogelijks het luchtruim niet meer inkomen.

Soldaatje @Blokker_1999 • 3 mei 2015 12:04

Klopt, wil niet zeggen dat het niet gebeurt:
http://www.experiencethes...-news-southwest-airlines/
Dit is van 25-2-2015.
128 Boeings 737-700 uit de vaart genomen door gemist onderhoud.
Southwest Airlines is een budgetmaatschappij, zoals Ryan Air.

[Reactie gewijzigd door Soldaatje op 23 juli 2024 19:06]

wildhagen

Economie en maatschappij
Luchtvaart

@Soldaatje • 3 mei 2015 12:07

Klopt, wil niet zeggen dat het niet gebeurt:
http://www.experiencethes...-news-southwest-airlines/
Dit is van 25-2-2015.

Maar daar staat nergens dat het bewust gedaan is ivm kostenbesparing. Kan evengoed een administratieve fout geweet zijn. Tevens is er geen ongeluk door gebeurd.

En toen het ontdekt was zijn de betreffende toestel ook acuut aan de grond gehouden. Wat héél wat meer kost dan het opzettelijke skippen van zo'n check zou opleveren aan besparing.

Soldaatje @wildhagen • 3 mei 2015 12:19

Ja het zou ook kunnen dat ze het gewoon 'vergeten' zijn.
Feit is wel dat onderhoud zeer veel geld kost, want het ding levert niets op als het niet vliegt.

huntedjohan @Anoniem: 398486 • 3 mei 2015 11:51

als ik kijk naar mijn simpele vrachtwagen, ding gaat elke avond uit, en word smorgens weer gestart. Als ik daar een elektrische storing in heb, word deze ook niet verwijderd als de auto uit staat. zodra ik de hoofdschakelaar uitzet waardoor de computer dus tijdelijk geen enkele spanning krijgt zijn de storingen wel weg. Vraag me niet waarom, maar ook daar werkt resetten pas als er volledige spanning onderbreking plaats vind.

Menesis 3 mei 2015 11:09

Als ik het goed heb moeten belangrijke mechanische onderdelen altijd dubbel worden uitgevoerd en driedubbel bij vliegtuigen die transatlantisch vliegen. Hoe zit dat dan met software nu dat ineens zo belangrijk is geworden? Lijkt me onacceptabel dat een heel vliegtuig uitvalt door één buffer overflow!?

[Reactie gewijzigd door Menesis op 23 juli 2024 19:06]

wildhagen

Economie en maatschappij
Luchtvaart

@Menesis • 3 mei 2015 11:14

Dit is ook dubbel uitgevoerd, of eigenlijk zelfs vierdubbel, want er zijn maar liefst 4 generatoren aan boord.

Zolang er minimaal één van de vier korter dan die 248 dagen online is, is er dus in de praktijk (los van verlies of vermindering van redundancy) nog weinig aan de hand.

[Reactie gewijzigd door wildhagen op 23 juli 2024 19:06]

pe1dnn @wildhagen • 3 mei 2015 12:05

Dat is nu juist een risico met zo'n soort bug en lijkt me nu juist in de praktijk heel ernstig. Er is een dikke kans dat alle generatoren ongeveer op de zelfde tijd gestart zijn, bijvoorbeeld na een laatste onderhoudsbeurt. Als het inderdaad een overflow is na 248 dagen dan falen dus al die generatoren ongeveer op hetzelfde moment of kort achter elkaar.

Als dat in een lucht gebeurt heb je wel een probleem, de piloot ziet dan de ene na de andere generator uitvallen (in volgorde waarin ze zijn ingeschakeld 248 dagen geleden). Het lijkt me niet voor de hand liggend dat dit een bekend scenario is waarvoor is geoefend, eerder dat een piloot geen idee heeft wat hem overkomt en dus ook de controle kan verliezen als ook de 4e en laatste generator uitvalt.

Dat het 4 dubbel is uitgevoerd helpt niet bij een harde fout als deze, dat helpt bij random fouten en dat is dit nu juist niet. Je kan de klok er op gelijkzetten.

MSalters

Economie en maatschappij

@pe1dnn • 3 mei 2015 16:43

Uitval van elektrische systemen is onderdeel van de routine-training. Dit zijn de generatoren die de batterijen voeden, dus je hebt niet acuut een probleem. Sowieso heb je een Ram Air Turbine voor noodstroom. En aangezien je de generatoren blijkbaar in de lucht kunt rebooten, is het al met al niet zo'n paniekgeval.

Baseboy @wildhagen • 3 mei 2015 12:15

Dit vond ik er over!
http://787updates.newairp...ems/787-Electrical-System

Wist ook van Discovery Air crash investigation dat die generatoren in de motoren zaten.
Wat ik nu niet snap hoe kunnen die nu uitvallen? Zelf vermoed ik dat ze elektronisch uitgezet worden. Daar zijn dan die ups accu's voor waar eerder problemen mee waren. Dan is het toch terwijl ze vliegen alleen die Generatoren resetten of ben ik nu mis?

*edit*

Laat maar de computer crasht op zichzelf lees ik net

[Reactie gewijzigd door Baseboy op 23 juli 2024 19:06]

preske @wildhagen • 3 mei 2015 12:08

Ik heb begrepen dat het een overkoepelend probleem is zodat alle 4 uitvallen op het zelfde moment.

Citroentjuh @Menesis • 3 mei 2015 11:12

Ik vermoed dat er wel meerdere systemen zijn, driedubbel is inderdaad redelijk standaard, maar wellicht dat die fout gewoon in al die systemen terugkomt?

osmosis 3 mei 2015 11:54

Dus softwarematig kan de stroomvoorziening stop gezet worden?
Waarom zou je dat überhaupt softwarematig willen aansturen.

Bij zulke cruciale schakelingen zou ik toch liever "beter be safe than sorry" aanpak zien.
Analoog schakelaar met een safeguard (sleutel ofz) in de cockpit.

ATS @osmosis • 3 mei 2015 16:51

Moderne vliegtuigen hebben compleet verglaasde cockpits. De oude plaatjes met panelen vol schakelaars en metertjes zijn precies dat: verouderd. Het wordt er ook niet veiliger van: het houdt niet op bij één zo'n schakelaar, je krijgt er al snel tientallen of honderden. Daar het overzicht in houden in een noodsituatie is ook niet eenvoudig en zorgt ook voor fouten.

osmosis @ATS • 4 mei 2015 11:01

Nee dat snap ik compleet.
Bedoel meer de meest cruciale zoals brandstof pompen, stroomgeneratoren, luchttoevoer. Dat lijkt me wel iets wat je liever analoog hebt aanzien een softwarematige storing daarin heel erg onaangenaam kan worden.

Of in ieder geval een analoge fail-safe

Zelfs mijn softwarematige aangestuurde wekker weigert soms dienst.
Me analoge heeft nog nooit een alarm moment gemist.

[Reactie gewijzigd door osmosis op 23 juli 2024 19:06]

ATS @osmosis • 4 mei 2015 11:43

Er zijn vele systemen als crusicaal te kwalificeren. Waar trek je de grens?

osmosis @ATS • 6 mei 2015 11:53

wel/niet uit de lucht vallen als een baksteen.
Lijkt me een redelijke grens.

ATS @osmosis • 6 mei 2015 11:56

Een vliegtuig valt niet zomaar als een baksteen uit de lucht. Die dingen hebben een best redelijke glijhoek. En is bijvoorbeeld kunnen landen niet ook zo'n redelijke grens? Zonder het landingsgestel uit te klappen val je niet uit de lucht, maar je hebt wel een probleem om veilig weer aan de grond te komen...

mad_max234 @osmosis • 3 mei 2015 13:02

Alles kan softwarematig in deze vliegtuigen, hele vliegtuig kan aangestuurd worden door software. Zit nergens meer hendel die iets direct bedient. Als er brand/kortsluiting is kan vliegtuig of piloot de generators uitschakelen om meer schade te voorkomen. Zo zijn er vast nog wel tig redenen te bedenken waarom je ze zou willen uitschakelen.

Anoniem: 532024 3 mei 2015 11:08

Beter nu er achter komen dan in de lucht

moet je je voorstellen op een paar kilometer hoogte in de lucht eventjes moeten rebooten

Pure_evil @Anoniem: 532024 • 3 mei 2015 11:23

Liever op een paar kilometer hoogte dan tijdens opstijgen/landen lijkt me

Heb je tenminste nog tijd om wat te doen.

ATS @Pure_evil • 3 mei 2015 16:42

Precies. In de luchtvaart geldt: hoogte is leven. Dicht bij de grond zijn problemen vaak fataal, op hoogte kan je vaak nog corrigeren.

mphilipp @Anoniem: 532024 • 3 mei 2015 19:34

Da's helemaal geen probleem. Ooit is er een toestel uit Canada, op weg naar Europa, zonder brandstof gekomen (heel verhaal...) die hebben nog naar de Azoren kunnen zweven en daar te landen. Dat landen was wel lastig omdat je niet kunt afremmen zonder de straalomkeerders, dus hebben ze volop geremd bij touchdown zodat de banden klapten. Zo konden ze op de velgen beter afremmen. Alternatief was bidden dat ie binnen 3km stil zou komen te staan, want dan was het einde runway en klip in de zee...

Ergo: het kan allemaal best. Geen idee of het erg is als de boel uitvalt als je net op 100m hoogte zit, want dan heb je toch wel al je gadgets nodig denk ik. Maar goed, statistisch gezien is de kans het grootst op hoogte. En nu men weet van de reboot gaat het (hopelijk) helemaal niet meer voorkomen. Ik mag hopen dat er een patch komt...

Stoney3K @Anoniem: 532024 • 3 mei 2015 13:28

Beter nu er achter komen dan in de lucht moet je je voorstellen op een paar kilometer hoogte in de lucht eventjes moeten rebooten

De generatoren zijn ook verantwoordelijk voor het starten van de motoren.

Als je dan de spreekwoordelijke sleutel omdraait terwijl de boel op de grond is gecrasht gebeurt er dus niets (behalve een boze foutmelding in de cockpit).

Anoniem: 405071 @Stoney3K • 3 mei 2015 20:06

Grootste bullshit wat jij nu zegt. Het gaat namelijk niet om de Auxillary Power Unit, maar om de normale generators. Die gevallen die de stroom leveren aan alle systemen vanaf de motor. Op elke motor zitten 2 generators voor de stroom. En dan zit er in de staart nog een APU, die er voor zorgt dat er genoeg stroom en bleed is om de motoren te starten. Dus nee dit is niet de sleutel omdraaien op de grond. Echt wat een bullshit.

Het is dus wel degelijk een groot probleem als alles uitvalt, Gelukkig zal men als dit gebeurt het snel genoeg door hebben, om te dalen naar minder dan 24000ft om daar de APU te starten, mits de motoren uit gevallen zijn, anders is het waarschijnlijk alle generator knoppen recyclen. Of in het ergste geval de circuitbreaker.

Stoney3K @Anoniem: 405071 • 3 mei 2015 21:33

Grootste bullshit wat jij nu zegt. Het gaat namelijk niet om de Auxillary Power Unit, maar om de normale generators. Die gevallen die de stroom leveren aan alle systemen vanaf de motor. Op elke motor zitten 2 generators voor de stroom. En dan zit er in de staart nog een APU, die er voor zorgt dat er genoeg stroom en bleed is om de motoren te starten.

Dat klopt in een 737, maar niet in een 787: Daar zijn de startmotoren en generatoren gecombineerd als één unit die aangestuurd wordt via een frequentieregelaar, en daar zitten er 2 van op per motor (een 737 heeft per motor maar één generator via een constante-snelheid tandwielkast).

De motoren op een 787 worden dan ook elektrisch gestart, tegenover pneumatische startmotoren die lucht krijgen van de APU (of grondaansluiting) zoals op een 737.

Het software-probleem zit in de units die de vermogens-overdracht regelen van elk van die generatorparen, en die stuurt dus ook de startmotoren aan. Wil je dus op de grond de motoren starten, dan zal er niets gebeuren.

Als er tijdens de vlucht problemen in de software optreden dan loop je het risico dat alle 4 de generatoren offline gaan (want die worden immers door 2 identieke units aangestuurd die allebei uitvallen), en dan blijft in het gunstigste geval de batterijstroom, samen met de APU, over. Dat is meestal geen directe man overboord maar wel een ernstig mankement en reden om het dichtstbijzijnde vliegveld op te gaan zoeken.

mphilipp 3 mei 2015 11:47

Uiteraard kan dat catastrofale gevolgen hebben als het vliegtuig op dat moment in de lucht hangt.

Dat is ook weer een klein beetje sensationeel gebracht. Hoewel het niet gewenst is, is het niet zonder meer fataal. Een vliegtuig op kruishoogte kan echt heel erg lang zonder motoren in de lucht blijven. Het is echt niet zo dat ie meteen als een baksteen uit de lucht valt. Dus voordat ie in gevaar komt, kan ie een reboot uitvoeren en is de boel weer ok. Natuurlijk niet zo leuk voor de passagiers, want die denken dat hun laatste uur geslagen heeft, maar dat is dan niet het geval.

Ik zie dit alleen maar als gevaar bij start of landing. Statistisch gezien heb je dus meer kans dat het je overkomt op hoogte. Evengoed geen fijn idee dat dit kan gebeuren.

Citroentjuh @mphilipp • 3 mei 2015 11:53

Eens, maar dat geldt niet voor lagere hoogten of als het bijvoorbeeld tijdens de landing of start zou gebeuren. Bovendien zou het goed kunnen dat bij de 787 ook de besturing dan uitvalt, hoewel ik vermoed dat daar wel een backup voor beschikbaar is in de vorm van een Ram Air Turbine.

MiloLemmy @mphilipp • 3 mei 2015 14:22

Ja en nee: het gaat hier niet alleen om de motoren, maar met het "uitvallen" (hierover later meer) van de stroom, vallen ook de hydraulische systemen stil, waardoor ook de besturing uitvalt. Inderdaad, geen fijn idee.

Maarrrr: de vier generatoren die deze GCU's aansturen, zijn niet de enige bron van elektriciteit op een 787. Naast die generatoren is er de APU, eigenlijk een bak batterijen, die gevoed wordt door een eigen turbine in de staart.
En als de poep echt de ventilator raakt, is er altijd nog de RAT, een windmolentje dat onder de romp uit kan klappen en door de voorwaartse beweging (en de daardoor gegenereerde luchtstroom) stroom opwekt.

Bij testvluchten met de 787 waarbij vijf van de bovengenoemde stroombronnen uitgeschakeld waren, lukte het prima de kist nog dik vijf uur in de lucht te houden, meer dan genoeg tijd om veilig te landen.

Op dit item kan niet meer gereageerd worden.

Boeing 787 moet gereboot worden om te beschermen tegen integer overflow

Lees meer

IT-banen

Reacties (239)

Sorteer op:

Weergave: